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

2 ● TypeScript + React / Kotlin ←最近ｺﾚ ● Data Management & BI ● Data Reliability ● Like : Docker/k8s/Python/Go/小倉唯さん ● Hobby : 🎮 / 🏂 / ⚽ / 小倉唯さん 自己紹介 Sotaro Tanaka @__sotaron__ Data Engineer @ Ubie, Inc. 2

3 今日お話すること Ubieでは、dbtを活用してどのようなデータ分析基盤を提供しているのか？ 今回は特に設計面から、こちらをご紹介します（ dbtそのものの話はほとんどしません） ● まずは現在地 ● 1年前のUbieのデータ分析基盤(v0)と課題 ● v1 データ分析基盤とその課題 ● v2 現在の構成 ● この構成にして、良かった点、困っている点 3

4 Ubieデータ分析基盤の現在地 4 今日は、この設計に至るまでの紆余曲折をお話していきます

5 目次 １．1年前のUbieのデータ分析基盤とその課題 ２．v1 データ分析基盤とその課題 ３．v2 現在の構成へ 5

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

7 課題：再利用性が低く、拡がるニーズに応えられなくなった 1年前のUbieのデータ分析基盤とその課題 ソースデータから1つのSQLで特定の分析・可視化用途のマートを作成しており、 以下のような課題を抱えていた 1/ データ品質テストがしにくい 　 複数の条件の掛け合わせがあったり、そもそもSQLが長大でテストすべき条件の抽出が難しかった 2/ 利用者・分析者の増加に対して、作業が非効率に 　ソースデータから一気にマートを作っているので、 　「似たような処理だが少し違う」ケースのために同じようなデータマートを作り直したり… 7

8 再利用性/保守性を意識し、 次の設計へ… 8

9 目次 １．1年前のUbieのデータ分析基盤とその課題 ２．v1 データ分析基盤とその課題 ３．v2 現在の構成へ 9

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

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

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

13 課題：複数の目的をもった加工処理が1つのSQLクエリに混在 v1 データ分析基盤とその課題 DWHに複数の目的をもった加工処理が集中したり、 「DWHとデータマートのどちらにこの実装をするべき？」の判断が難しくなった 1/ 汎用的な共通処理はどこで？ 　 タイムスタンプのJST変換や欠損/nullチェック、uniqueチェック、不正な値の排除のための処理が散在 2/ ドメイン特有の関心ごとはどこにまとめる？＝どこでテストする？ 　分析では、Aという機能とBという機能双方を利用したユーザーを集計したいけど、 　 そういうときはDWHはどう作るの？データマートで結合するの？ 　 DWHにAとB両方のドメインが表現されていると、再利用もしにくいし、テストもやりにくくない？ 13

14 それぞれの加工処理の責務 を明確化すべく、再設計へ 14

15 目次 １．1年前のUbieのデータ分析基盤とその課題 ２．v1 データ分析基盤とその課題 ３．v2 現在の構成へ 15

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

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

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

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

20 DataMart層は、特定の分析・可視化を用途に v2 現在の構成へ 特定の分析・可視化を意図した層 ドリルダウン前提のマートから、ヘルスチェック用のメトリクス集計済みマートまで 1/ BIツールとの統合を意識 　 テーブルサイズやカラム名など、Tableau等のBIツールでの利用を前提に整備 2/ 基本的なメトリクスはMetrics Martを用意 　サービスの基本的なKPIは大きくは変わらないので、そのようなメトリクスは集計した状態のマートを用意 　 結果的に集計値の一貫性テストや、BIツールによる闇集計を回避 20

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 各層での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

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

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

26 Key Takeaway 26

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

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