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

dbtを活用したデータ基盤の 論理・物理設計の現在地と振り返り / data warehouse logic design by using dbt

Sotaro Tanaka
December 13, 2021

dbtを活用したデータ基盤の 論理・物理設計の現在地と振り返り / data warehouse logic design by using dbt

Sotaro Tanaka

December 13, 2021
Tweet

More Decks by Sotaro Tanaka

Other Decks in Technology

Transcript

  1. 2 • TypeScript + React / Kotlin ←最近コレ • Data

    Management & BI • Data Reliability • Like : Docker/k8s/Python/Go/小倉唯さん • Hobby : 🎮 / 🏂 / ⚽ / 小倉唯さん 自己紹介 Sotaro Tanaka @__sotaron__ Data Engineer @ Ubie, Inc. 2
  2. 13 課題:複数の目的をもった加工処理が1つのSQLクエリに混在 v1 データ分析基盤とその課題 DWHに複数の目的をもった加工処理が集中したり、 「DWHとデータマートのどちらにこの実装をするべき?」の判断が難しくなった 1/ 汎用的な共通処理はどこで?   タイムスタンプのJST変換や欠損/nullチェック、uniqueチェック、不正な値の排除のための処理が散在

    2/ ドメイン特有の関心ごとはどこにまとめる?=どこでテストする?  分析では、Aという機能とBという機能双方を利用したユーザーを集計したいけど、   そういうときはDWHはどう作るの?データマートで結合するの?   DWHにAとB両方のドメインが表現されていると、再利用もしにくいし、テストもやりにくくない? 13
  3. 18 Component層は、再利用性を意識し、特定のデータモデルを表現 v2 現在の構成へ 複数のDWHで利用されることを意識した、再利用性が考慮された層 Ubieであれば、「問診」や「医療機関の検索」といったドメインのイベントを表現している 1/ Conformed Dimension  

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

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

    2/ 基本的なメトリクスはMetrics Martを用意  サービスの基本的なKPIは大きくは変わらないので、そのようなメトリクスは集計した状態のマートを用意   結果的に集計値の一貫性テストや、BIツールによる闇集計を回避 20
  6. 21 物理設計 on BigQuery v2 現在の構成へ 21 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. 22 各層でのdbtテスト 代表的なもの 22 完全性 Integrity レコードは欠損していないか? Requiredなカラムに値があるか? 主にComponent層に実装 -

    user_idなどのnull,unique チェック (not_null, unique) - キャンペーンコードなどの値 チェック (relationships) 一貫性 Consistency ある値が、データセット内/間で 一貫しているか? 主にDataMart層に実装 - レポートAとレポートBでの同じ 指標値の一貫性 (dbt_utils tests) 鮮度 Freshness データが十分に新鮮か? 主にInterface層に実装 - freshness testなど v2 現在の構成へ