データ基盤の○層構造を独り歩きさせないデータモデリング設計2022/02/17Sotaro Tanaka @__sotaron__Data Ops Night #1
View Slide
2● Product Management ←最近ｺﾚ● TypeScript + React / Kotlin● Data Management & BI● Like : Docker/k8s/Python/Go/小倉唯さん● Hobby : 🎮 / 🏂 / ⚽ / 小倉唯さん自己紹介Sotaro Tanaka @__sotaron__Data Engineer @ Ubie, Inc.2
3今日お話すること昨年末、別イベントにて「 dbtを活用したデータ基盤の論理・物理設計の現在地と振り返り」というタイトルで登壇したとき、「 ○層構造」の話が独り歩きしてしまっているように感じ、その背景にあるWhyをうまく伝えられませんでした。なので今日は、以下を話します。● Ubieデータ基盤の現在の設計について● いわゆる「3層構造」のデータ基盤について● なにが違うのか？ / なにが同じなのか？● 誰が、いつ、なぜ、このような設計を考えるべきか？3
4目次１．Ubieデータ基盤の現在の設計２．いわゆる「3層構造」のデータ基盤について３．なにが違うのか？なにが同じなのか？4４．誰が、いつ、なぜ、このような設計を考えるべきか？
5Ubieデータ分析基盤の論理設計5論理的にはこのような設計を Ubieでは採用（prj名など入っているので、微妙に論理じゃない …）Ubieデータ基盤の現在の設計
6物理設計 on BigQueryUbieデータ基盤の現在の設計6layer dataset name table/view table nameInterface if_{ソースデータセット名}view ソーステーブル名Component(fact) dc_{ドメイン名} view fact_{任意の名前}Component(dimension) 同上 view dim_{任意の名前}DWH dwh_{サービス名} table {任意の名前}DWH Intermediate 同上 view _itm_{任意の名前}DataMart dm_{サービス名} table {任意の名前}DataMartIntermediate同上 view _itm_{任意の名前}
7Interface層は、最低限のケアを施した分析向けの基本データUbieデータ基盤の現在の設計先述のような汎用的な共通処理を施す層データ分析をしたいときに、「細かいコトを考えずに使えるログテーブル」のようなもの1/ 特定のデータモデルに依存しないような共通の処理 タイムスタンプのJST変換やカラム名の変換など2/ 無効な値の排除 重複、論理削除レコード、不正値などの排除7
8Component層は、再利用性を意識し、特定のデータモデルを表現Ubieデータ基盤の現在の設計複数のDWHで利用されることを意識した、再利用性が考慮された層Ubieであれば、「問診」や「医療機関の検索」といったドメインのイベントを表現している1/ Conformed Dimension スタースキーマにおけるDimensionを、基盤内で互換性をもって利用できる形に整備したもの キャンペーンコードのリストや、医療機関のリスト、疾患や症状のデータなど2/ Conformed Fact スタースキーマにおけるFactを、基盤内で互換性をもって利用できる形に整備したもの 問診イベントレコードや、検索レコードなどが該当8
9DWH層は、Componentの結合により、分析のベースとなるテーブル群Ubieデータ基盤の現在の設計Componentを束ね、あるドメインの分析に必要な情報を集めたベースのテーブル基本的に、分析者はこの DWHを利用して、分析・可視化を実施1/ 可視化を意識しない 可視化を意識すると、テーブルサイズや集計軸が気になるが、 ここではあくまで特定ドメインの分析に必要なComponentの結合や指標算出にとどめている2/ 当該ドメインに詳しくなくても触れるテーブル群 アナリストが、自身の担当ではない事業の分析をする際も、dbt docsやschemaを確認しながら、 利用できるように整備されている9
10DataMart層は、特定の分析・可視化を用途にUbieデータ基盤の現在の設計特定の分析・可視化を意図した層ドリルダウン前提のマートから、ヘルスチェック用のメトリクス集計済みマートまで1/ BIツールとの統合を意識 テーブルサイズやカラム名など、Tableau等のBIツールでの利用を前提に整備2/ 基本的なメトリクスはMetrics Martを用意 サービスの基本的なKPIは大きくは変わらないので、そのようなメトリクスは集計した状態のマートを用意 結果的に集計値の一貫性テストを実施したり、BIツールによる闇集計を回避10
11各層でのdbtテスト代表的なもの11完全性 Integrityレコードは欠損していないか？Requiredなカラムに値があるか？主にComponent層に実装- user_idなどのnull,uniqueチェック (not_null, unique)- キャンペーンコードなどの値チェック (relationships)一貫性 Consistencyある値が、データセット内/間で一貫しているか？主にDataMart層に実装- レポートAとレポートBでの同じ指標値の一貫性 (dbt_utilstests)鮮度 Freshnessデータが十分に新鮮か？主にInterface層に実装- freshness testなどUbieデータ基盤の現在の設計
12目次１．Ubieデータ基盤の現在の設計２．いわゆる「3層構造」のデータ基盤について３．なにが違うのか？なにが同じなのか？12４．誰が、いつ、なぜ、このような設計を考えるべきか？
13DataLake/DWH/DataMartの3層構造※ 図および以降の説明は『実践的データ基盤への処方箋 ※1』を参考に、発表者が作成しています13いわゆる「3層構造」のデータ基盤について※1 : ゆずたそ, 渡部徹太郎 , 伊藤徹郎 著 『実践的データ基盤への処方箋』技術評論社 2021
14このイベント参加者には「釈迦に説法」だと思いますが…14
15DataLake層は、さまざまなソースから1つのシステムにデータを集約したものいわゆる「3層構造」のデータ基盤について15加工処理をする前のデータのコピー1/ Excel, RDB, 外部サービスなど複数の出どころからなるデータを一箇所に集める 割愛2/ あえて処理を加えないことで、問題調査等にも使える 割愛
16DWH層は、共通指標となるデータの置場いわゆる「3層構造」のデータ基盤についてDataLakeにあるデータを意味のある「情報」に変換する層指標算出や、そのためのイベントレベルのテーブルなど1/ Single Source of Truthの実現 ある指標値や実績値が、レポートをまたがって異なることのないように2/ 一口に「DWH層」といってもいくつかの処理が集まっている データのクレンジング、ディメンショナルモデリング（等のモデリング）、共通指標の集計など16
17DataMart層は、特定の利用者 / 特定の用途向けに整理されたデータいわゆる「3層構造」のデータ基盤についてDWH層のデータをもとに、特定の利用者や用途を想定し、加工・集計されたデータの置場1/ ユースケースと1対1の関係 修正・削除の影響範囲を狭めたり、似たようなユースケースでの再利用がしやすくなる17
18目次１．Ubieデータ基盤の現在の設計２．いわゆる「3層構造」のデータ基盤について３．なにが違うのか？なにが同じなのか？18４．誰が、いつ、なぜ、このような設計を考えるべきか？
19必要とされる処理、およびデータの流れは同じなにが違うのか？なにが同じなのか？先述のUbieにおけるデータ基盤設計と 3層構造の対応関係レイクはソースデータのコピー、 DWHは意味のある情報を作り、マートは特定の用途へ19
20違いは、DWH層における処理を処理内容ごとにレイヤ分けした部分なにが違うのか？なにが同じなのか？DWH層がもつ処理の責務を明示的にレイヤに分解クレンジングはInterface、ディメンショナルモデリングは Component、共通指標の算出は dwh20
21つまり、ほとんど同じッてコト…？！21
22そうです22
23じゃあ、なんでわざわざあんな設計に…？23
24目次１．Ubieデータ基盤の現在の設計２．いわゆる「3層構造」のデータ基盤について３．なにが違うのか？なにが同じなのか？24４．誰が、いつ、なぜ、このような設計を考えるべきか？
25誰が、いつ、なぜ、このような設計を考えるべきか？誰が、いつ、なぜ、このような設計を考えるべきか？レイヤ分けの大きな目的は「保守性」や「テストのしやすさ」の維持逆にいうと、以下のようなケースを除いては必要ないかもしれない1/ データエンジニア、データアナリスト以外も複数人開発にコミットするケース DWH層はどんな処理をすべきか、なにをテストすべきか、がよくわかっていない開発者は 責務とテストすべき内容が明示 されたレイヤがあったほうが開発しやすい。 逆にデータエンジニアとデータアナリスト2~3人でやっているうちは、分けなくても保守性に大きな問題はないかも。2/ 共通ドメイン、複数プロダクトなケース たとえば、「医学データ」「toC/toB双方のプロダクト」のケースで考えると、「医学データ」のような共通ドメインの ディメンションはComponentとして切り出しておくと、toC/toB開発エンジニアがそれを使った指標算出のクエリを書き やすい（Component層に再利用可能な形でデータがあるという期待）「共通ドメイン、複数プロダクト、多くの開発者」そんなとき、必要かもしれない25
26Ubieでは、先述の設計により、責務の明確化と明示ができた26
27結果として、コミッターが増え、開発も以前より活発に27
28独り歩きしないための、重要な問い「○層がどうこう」という話を独り歩きさせず、自分たちにあった設計にするための問い1/ そのデータ基盤の開発、運用には誰がどこまで関わるのか？ データエンジニア、データアナリストだけなのか？ データ基盤にそこまで明るくないバックエンドエンジニアもコミットするのか？エンジニア以外も触るのか？ 触るならどこまで触るのか？2/ その設計で、各層の責務は自明に分かるか？ 開発をする自分たちが、それぞれの層でやるべき処理、 およびその層のデータが満たすべき品質、性質を自明に理解しているのか？ 28Key Takeaway
29ところで29
30twitter: @__sotaron__ までDMどうぞ！！気になるけど、DMするほどでもないな〜という方はとりあえず以下から！- Ubieってそもそもどんな会社なん？【Ubie説明資料一覧】Ubieの事業とチームが分かる 5つの資料をまとめました- どんな人を求めているの？（ Ubie Discovery）3分でわかる Ubieness チェックUbieで医療データのあれやこれや、やっていきませんか！30
31おわり31
tanakarian
mizunohiroaki
stefafafan
okunokentaro
tatematsu_san
nttcom
harukasakihara
carta_engineering
udzura
shimashima35
sumiren
bonjiri_niwa
tammielis
rasmusluckow
pedronauck
carmenintech
mojombo
eileencodes
bkeepers
lauravandoore
zakiwarfel
aki_iinuma
mongodb
philhawksworth