データ基盤の○層構造を独り歩きさせない データモデリング設計 2022/02/17 Sotaro Tanaka @__sotaron__ Data Ops Night #1

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 ４．誰が、いつ、なぜ、このような設計を考えるべきか？

5 Ubieデータ分析基盤の論理設計 5 論理的にはこのような設計を Ubieでは採用（prj名など入っているので、微妙に論理じゃない …） Ubieデータ基盤の現在の設計

6 物理設計 on BigQuery Ubieデータ基盤の現在の設計 6 layer dataset name table/view table name Interface if_{ソースデータセッ ト名} view ソーステーブル名 Component(fact) dc_{ドメイン名} view fact_{任意の名前} Component(dimension) 同上 view dim_{任意の名前} DWH dwh_{サービス名} table {任意の名前} DWH Intermediate 同上 view _itm_{任意の名前} DataMart dm_{サービス名} table {任意の名前} DataMart Intermediate 同上 view _itm_{任意の名前}

7 Interface層は、最低限のケアを施した分析向けの基本データ Ubieデータ基盤の現在の設計 先述のような汎用的な共通処理を施す層 データ分析をしたいときに、「細かいコトを考えずに使えるログテーブル」のようなもの 1/ 特定のデータモデルに依存しないような共通の処理 　 タイムスタンプのJST変換やカラム名の変換など 2/ 無効な値の排除 　重複、論理削除レコード、不正値などの排除 7

8 Component層は、再利用性を意識し、特定のデータモデルを表現 Ubieデータ基盤の現在の設計 複数のDWHで利用されることを意識した、再利用性が考慮された層 Ubieであれば、「問診」や「医療機関の検索」といったドメインのイベントを表現している 1/ Conformed Dimension 　 スタースキーマにおけるDimensionを、基盤内で互換性をもって利用できる形に整備したもの 　 キャンペーンコードのリストや、医療機関のリスト、疾患や症状のデータなど 2/ Conformed Fact 　スタースキーマにおけるFactを、基盤内で互換性をもって利用できる形に整備したもの 　 問診イベントレコードや、検索レコードなどが該当 8

9 DWH層は、Componentの結合により、分析のベースとなるテーブル群 Ubieデータ基盤の現在の設計 Componentを束ね、あるドメインの分析に必要な情報を集めたベースのテーブル 基本的に、分析者はこの DWHを利用して、分析・可視化を実施 1/ 可視化を意識しない 　 可視化を意識すると、テーブルサイズや集計軸が気になるが、 　ここではあくまで特定ドメインの分析に必要なComponentの結合や指標算出にとどめている 2/ 当該ドメインに詳しくなくても触れるテーブル群 　アナリストが、自身の担当ではない事業の分析をする際も、dbt docsやschemaを確認しながら、 　利用できるように整備されている 9

10 DataMart層は、特定の分析・可視化を用途に 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_utils tests) 鮮度 Freshness データが十分に新鮮か？ 主にInterface層に実装 - freshness testなど Ubieデータ基盤の現在の設計

12 目次 １．Ubieデータ基盤の現在の設計 ２．いわゆる「3層構造」のデータ基盤について ３．なにが違うのか？なにが同じなのか？ 12 ４．誰が、いつ、なぜ、このような設計を考えるべきか？

13 DataLake/DWH/DataMartの3層構造 ※ 図および以降の説明は『実践的データ基盤への処方箋 ※1』を参考に、発表者が作成しています 13 いわゆる「3層構造」のデータ基盤について ※1 : ゆずたそ, 渡部徹太郎 , 伊藤徹郎 著 『実践的データ基盤への処方箋』技術評論社 2021

14 このイベント参加者には 「釈迦に説法」 だと思いますが… 14

15 DataLake層は、さまざまなソースから1つのシステムにデータを集約したもの いわゆる「3層構造」のデータ基盤について 15 加工処理をする前のデータのコピー 1/ Excel, RDB, 外部サービスなど複数の出どころからなるデータを一箇所に集める 　 割愛 2/ あえて処理を加えないことで、問題調査等にも使える 　割愛

16 DWH層は、共通指標となるデータの置場 いわゆる「3層構造」のデータ基盤について DataLakeにあるデータを意味のある「情報」に変換する層 指標算出や、そのためのイベントレベルのテーブルなど 1/ Single Source of Truthの実現 　 ある指標値や実績値が、レポートをまたがって異なることのないように 2/ 一口に「DWH層」といってもいくつかの処理が集まっている 　データのクレンジング、ディメンショナルモデリング（等のモデリング）、共通指標の集計など 16

17 DataMart層は、特定の利用者 / 特定の用途向けに整理されたデータ いわゆる「3層構造」のデータ基盤について DWH層のデータをもとに、特定の利用者や用途を想定し、加工・集計されたデータの置場 1/ ユースケースと1対1の関係 　 修正・削除の影響範囲を狭めたり、似たようなユースケースでの再利用がしやすくなる 17

18 目次 １．Ubieデータ基盤の現在の設計 ２．いわゆる「3層構造」のデータ基盤について ３．なにが違うのか？なにが同じなのか？ 18 ４．誰が、いつ、なぜ、このような設計を考えるべきか？

19 必要とされる処理、およびデータの流れは同じ なにが違うのか？なにが同じなのか？ 先述のUbieにおけるデータ基盤設計と 3層構造の対応関係 レイクはソースデータのコピー、 DWHは意味のある情報を作り、マートは特定の用途へ 19

20 違いは、DWH層における処理を処理内容ごとにレイヤ分けした部分 なにが違うのか？なにが同じなのか？ DWH層がもつ処理の責務を明示的にレイヤに分解 クレンジングはInterface、ディメンショナルモデリングは Component、共通指標の算出は dwh 20

21 つまり、ほとんど同じッてコト …？！ 21

22 そうです 22

23 じゃあ、なんでわざわざ あんな設計に…？ 23

24 目次 １．Ubieデータ基盤の現在の設計 ２．いわゆる「3層構造」のデータ基盤について ３．なにが違うのか？なにが同じなのか？ 24 ４．誰が、いつ、なぜ、このような設計を考えるべきか？

25 誰が、いつ、なぜ、このような設計を考えるべきか？誰が、いつ、なぜ、このような設計を考えるべきか？ レイヤ分けの大きな目的は「保守性」や「テストのしやすさ」の維持 逆にいうと、以下のようなケースを除いては必要ないかもしれない 1/ データエンジニア、データアナリスト以外も複数人開発にコミットするケース 　 DWH層はどんな処理をすべきか、なにをテストすべきか、がよくわかっていない開発者は 　 責務とテストすべき内容が明示　 されたレイヤがあったほうが開発しやすい。 　 逆にデータエンジニアとデータアナリスト2~3人でやっているうちは、分けなくても保守性に大きな問題はないかも。 2/ 共通ドメイン、複数プロダクトなケース 　たとえば、「医学データ」「toC/toB双方のプロダクト」のケースで考えると、「医学データ」のような共通ドメインの　　 ディメンションは Componentとして切り出しておくと、toC/toB開発エンジニアがそれを使った指標算出のクエリを書き　 やすい（Component層に再 利用可能な形でデータがあるという期待） 「共通ドメイン、複数プロダクト、多くの開発者」そんなとき、必要かもしれない 25

26 Ubieでは、 先述の設計により、 責務の明確化と明示 ができた 26

27 結果として、 コミッターが増え、 開発も以前より活発に 27

28 独り歩きしないための、重要な問い 「○層がどうこう」という話を独り歩きさせず、自分たちにあった設計にするための問い 1/ そのデータ基盤の開発、運用には誰がどこまで関わるのか？ 　 データエンジニア、データアナリストだけなのか？ 　 データ基盤にそこまで明るくないバックエンドエンジニアもコミットするのか？エンジニア以外も触るのか？ 　 触るならどこまで触るのか？ 2/ その設計で、各層の責務は自明に分かるか？ 　開発をする自分たちが、それぞれの層でやるべき処理、 　およびその層のデータが満たすべき品質、性質を自明に理解しているのか？ 　 28 Key Takeaway

29 ところで 29

30 twitter: @__sotaron__ までDMどうぞ！！ 気になるけど、DMするほどでもないな〜という方はとりあえず以下から！ - Ubieってそもそもどんな会社なん？ 【Ubie説明資料一覧】Ubieの事業とチームが分かる 5つの資料をまとめました - どんな人を求めているの？（ Ubie Discovery） 3分でわかる Ubieness チェック Ubieで医療データのあれやこれや、やっていきませんか！ 30

31 おわり 31