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

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

E120f1fcd6d2811ea5e06d110566a543?s=47 Sotaro Tanaka
December 13, 2021

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

E120f1fcd6d2811ea5e06d110566a543?s=128

Sotaro Tanaka

December 13, 2021
Tweet

More Decks by Sotaro Tanaka

Other Decks in Technology

Transcript

  1. dbtを活用したデータ基盤の 論理・物理設計の現在地と振り返り 2021/12/13 Sotaro Tanaka @__sotaron__ Data Engineering Study #11

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

    Management & BI • Data Reliability • Like : Docker/k8s/Python/Go/小倉唯さん • Hobby : 🎮 / 🏂 / ⚽ / 小倉唯さん 自己紹介 Sotaro Tanaka @__sotaron__ Data Engineer @ Ubie, Inc. 2
  3. 3 今日お話すること Ubieでは、dbtを活用してどのようなデータ分析基盤を提供しているのか? 今回は特に設計面から、こちらをご紹介します( dbtそのものの話はほとんどしません) • まずは現在地 • 1年前のUbieのデータ分析基盤(v0)と課題 •

    v1 データ分析基盤とその課題 • v2 現在の構成 • この構成にして、良かった点、困っている点 3
  4. 4 Ubieデータ分析基盤の現在地 4 今日は、この設計に至るまでの紆余曲折をお話していきます

  5. 5 目次 1.1年前のUbieのデータ分析基盤とその課題 2.v1 データ分析基盤とその課題 3.v2 現在の構成へ 5

  6. 6 1年前のデータ分析基盤の論理設計 テーブル作成/更新はAirflowからのSQL実行により制御 6 1年前のUbieのデータ分析基盤とその課題

  7. 7 課題:再利用性が低く、拡がるニーズに応えられなくなった 1年前のUbieのデータ分析基盤とその課題 ソースデータから1つのSQLで特定の分析・可視化用途のマートを作成しており、 以下のような課題を抱えていた 1/ データ品質テストがしにくい   複数の条件の掛け合わせがあったり、そもそもSQLが長大でテストすべき条件の抽出が難しかった 2/

    利用者・分析者の増加に対して、作業が非効率に  ソースデータから一気にマートを作っているので、  「似たような処理だが少し違う」ケースのために同じようなデータマートを作り直したり… 7
  8. 8 再利用性/保守性を意識し、 次の設計へ… 8

  9. 9 目次 1.1年前のUbieのデータ分析基盤とその課題 2.v1 データ分析基盤とその課題 3.v2 現在の構成へ 9

  10. 10 v1 データ分析基盤の論理設計 テーブル作成/更新およびテストはすべて dbtで実行 10 v1 データ分析基盤とその課題

  11. 11 dbtと三層構造の採用で、再 利用性は一定向上、 dbtテストにより 保守性もあがった 11

  12. 12 しかし、次の課題が… 12

  13. 13 課題:複数の目的をもった加工処理が1つのSQLクエリに混在 v1 データ分析基盤とその課題 DWHに複数の目的をもった加工処理が集中したり、 「DWHとデータマートのどちらにこの実装をするべき?」の判断が難しくなった 1/ 汎用的な共通処理はどこで?   タイムスタンプのJST変換や欠損/nullチェック、uniqueチェック、不正な値の排除のための処理が散在

    2/ ドメイン特有の関心ごとはどこにまとめる?=どこでテストする?  分析では、Aという機能とBという機能双方を利用したユーザーを集計したいけど、   そういうときはDWHはどう作るの?データマートで結合するの?   DWHにAとB両方のドメインが表現されていると、再利用もしにくいし、テストもやりにくくない? 13
  14. 14 それぞれの加工処理の責務 を明確化すべく、再設計へ 14

  15. 15 目次 1.1年前のUbieのデータ分析基盤とその課題 2.v1 データ分析基盤とその課題 3.v2 現在の構成へ 15

  16. 16 Ubieデータ分析基盤の論理設計 テーブル作成/更新およびテストはすべて dbtで実行 16 v2 現在の構成へ

  17. 17 Interface層は、最低限のケアを施した分析向けの基本データ v2 現在の構成へ 先述のような汎用的な共通処理を施す層 データ分析をしたいときに、「細かいコトを考えずに使えるログテーブル」のようなもの 1/ 特定のデータモデルに依存しないような共通の処理   タイムスタンプのJST変換やカラム名の変換など

    2/ 無効な値の排除  重複、論理削除レコード、不正値などの排除 17
  18. 18 Component層は、再利用性を意識し、特定のデータモデルを表現 v2 現在の構成へ 複数のDWHで利用されることを意識した、再利用性が考慮された層 Ubieであれば、「問診」や「医療機関の検索」といったドメインのイベントを表現している 1/ Conformed Dimension  

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

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

    2/ 基本的なメトリクスはMetrics Martを用意  サービスの基本的なKPIは大きくは変わらないので、そのようなメトリクスは集計した状態のマートを用意   結果的に集計値の一貫性テストや、BIツールによる闇集計を回避 20
  21. 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_{任意の名前}
  22. 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 現在の構成へ
  23. 23 各層の責務が 明確化されたことで、 処理の実装漏れがなくなり より高品質なデータを提供で きるようになった 23

  24. 24 責務が明確である ということは、 テストも書きやすい 24

  25. 25 とはいえ、困っていることもあります 設計できたはいいものの、まだこの設計に則ってモデリングできているデータは一部 特にComponent層、DWH層のモデリング(特にこの 2つの境界)は難しく、 データ分析やデータエンジニアリングの知識・経験と事業理解の掛け合わせがないと大変 … さらに、同時に複数の事業を展開する Ubieには、何種ものデータがあります まだまだデータアナリストやデータエンジニアが必要

    なんです 25 v2 現在の構成へ
  26. 26 Key Takeaway 26

  27. 27 今日のお持ち帰り Ubieに入社して、 データ分析やデータエンジニアリングの知見・経験を活かして、最高の データモデリングしていきませんか?

  28. 28 twitter: @__sotaron__ までDMどうぞ!! 気になるけど、DMするほどでもないな〜という方はとりあえず以下から! - Ubieってそもそもどんな会社なん? 【Ubie説明資料一覧】Ubieの事業とチームが分かる 5つの資料をまとめました -

    どんな人を求めているの?( Ubie Discovery) 3分でわかる Ubieness チェック Ubieで医療データのあれやこれや、やっていきませんか! 28