Upgrade to Pro — share decks privately, control downloads, hide ads and more …

データ基盤の○層構造を独り歩きさせない データモデリング設計 Data Ops Night #1

Sotaro Tanaka
February 17, 2022

データ基盤の○層構造を独り歩きさせない データモデリング設計 Data Ops Night #1

Sotaro Tanaka

February 17, 2022
Tweet

More Decks by Sotaro Tanaka

Other Decks in Technology

Transcript

  1. 2 • Product Management ←最近コレ • TypeScript + React /

    Kotlin • Data Management & BI • Like : Docker/k8s/Python/Go/小倉唯さん • Hobby : 🎮 / 🏂 / ⚽ / 小倉唯さん 自己紹介 Sotaro Tanaka @__sotaron__ Data Engineer @ Ubie, Inc. 2
  2. 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_{任意の名前}
  3. 8 Component層は、再利用性を意識し、特定のデータモデルを表現 Ubieデータ基盤の現在の設計 複数のDWHで利用されることを意識した、再利用性が考慮された層 Ubieであれば、「問診」や「医療機関の検索」といったドメインのイベントを表現している 1/ Conformed Dimension   スタースキーマにおけるDimensionを、基盤内で互換性をもって利用できる形に整備したもの

      キャンペーンコードのリストや、医療機関のリスト、疾患や症状のデータなど 2/ Conformed Fact  スタースキーマにおけるFactを、基盤内で互換性をもって利用できる形に整備したもの   問診イベントレコードや、検索レコードなどが該当 8
  4. 9 DWH層は、Componentの結合により、分析のベースとなるテーブル群 Ubieデータ基盤の現在の設計 Componentを束ね、あるドメインの分析に必要な情報を集めたベースのテーブル 基本的に、分析者はこの DWHを利用して、分析・可視化を実施 1/ 可視化を意識しない   可視化を意識すると、テーブルサイズや集計軸が気になるが、

     ここではあくまで特定ドメインの分析に必要なComponentの結合や指標算出にとどめている 2/ 当該ドメインに詳しくなくても触れるテーブル群  アナリストが、自身の担当ではない事業の分析をする際も、dbt docsやschemaを確認しながら、  利用できるように整備されている 9
  5. 10 DataMart層は、特定の分析・可視化を用途に Ubieデータ基盤の現在の設計 特定の分析・可視化を意図した層 ドリルダウン前提のマートから、ヘルスチェック用のメトリクス集計済みマートまで 1/ BIツールとの統合を意識   テーブルサイズやカラム名など、Tableau等のBIツールでの利用を前提に整備 2/

    基本的なメトリクスはMetrics Martを用意  サービスの基本的なKPIは大きくは変わらないので、そのようなメトリクスは集計した状態のマートを用意   結果的に集計値の一貫性テストを実施したり、BIツールによる闇集計を回避 10
  6. 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データ基盤の現在の設計
  7. 16 DWH層は、共通指標となるデータの置場 いわゆる「3層構造」のデータ基盤について DataLakeにあるデータを意味のある「情報」に変換する層 指標算出や、そのためのイベントレベルのテーブルなど 1/ Single Source of Truthの実現

      ある指標値や実績値が、レポートをまたがって異なることのないように 2/ 一口に「DWH層」といってもいくつかの処理が集まっている  データのクレンジング、ディメンショナルモデリング(等のモデリング)、共通指標の集計など 16
  8. 25 誰が、いつ、なぜ、このような設計を考えるべきか?誰が、いつ、なぜ、このような設計を考えるべきか? レイヤ分けの大きな目的は「保守性」や「テストのしやすさ」の維持 逆にいうと、以下のようなケースを除いては必要ないかもしれない 1/ データエンジニア、データアナリスト以外も複数人開発にコミットするケース   DWH層はどんな処理をすべきか、なにをテストすべきか、がよくわかっていない開発者は   責務とテストすべき内容が明示 

    されたレイヤがあったほうが開発しやすい。   逆にデータエンジニアとデータアナリスト2~3人でやっているうちは、分けなくても保守性に大きな問題はないかも。 2/ 共通ドメイン、複数プロダクトなケース  たとえば、「医学データ」「toC/toB双方のプロダクト」のケースで考えると、「医学データ」のような共通ドメインの   ディメンションは Componentとして切り出しておくと、toC/toB開発エンジニアがそれを使った指標算出のクエリを書き  やすい(Component層に再 利用可能な形でデータがあるという期待) 「共通ドメイン、複数プロダクト、多くの開発者」そんなとき、必要かもしれない 25