Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
dbtを活用したデータ基盤の 論理・物理設計の現在地と振り返り / data warehous...
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Sotaro Tanaka
December 13, 2021
Technology
16k
8
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
dbtを活用したデータ基盤の 論理・物理設計の現在地と振り返り / data warehouse logic design by using dbt
Sotaro Tanaka
December 13, 2021
More Decks by Sotaro Tanaka
See All by Sotaro Tanaka
データエンジニアリング 4年前と変わったこと、 4年前と変わらないこと
tanakarian
4
1k
ABEMAはなぜセマンティックレイヤーに挑戦しているのか?
tanakarian
0
1.3k
データ基盤の○層構造を独り歩きさせない データモデリング設計 Data Ops Night #1
tanakarian
3
5.8k
データ分析基盤の障害を未然に防ぐためのチェックリスト / checklist for preventing incidents of data management system
tanakarian
1
14k
データの価値を失わないためのData Reliability
tanakarian
7
12k
building-evolutionary-data-warehouse
tanakarian
2
11k
Other Decks in Technology
See All in Technology
OTel × Datadog で 「AI活用」を計測し、改善に繋げる
shihochan
2
630
スタートアップにAmazon EKSは早すぎる? マルチプロダクト戦略を加速する Platform Engineeringの実践 / Is Amazon EKS Too Soon for Startups? Practical Platform Engineering to Accelerate a Multi-Product Strategy
elmodev09
1
1.8k
FPGAの開発コンペでZephyrを使ってみた
iotengineer22
0
200
入門!AWS Blocks
ysuzuki
1
190
[AWS Summit Japan 2026]迷っているあなたへ_小さな一歩が、やがて自分を助けてくれる
sh_fk2
2
410
2026-06-24_人とAIの責務分離に基づく開発プロセスの提案.pdf
takahiromatsui
0
120
從開發到部署全都交給 AI:實作 AI 驅動的自動化流程
appleboy
0
160
千葉での単身赴任からAWSをやり続け、千葉に戻ってきた話
yama3133
1
120
BPaaSで進むAIオペレーションの現在地 AI実装が効く領域とスケーラビリティの選定と実装
kentarofujii
0
190
クラウドファンディング版StackChan 3体(4体)をインタラクティブな体験型作品にして展示もした話 / スタックチャンお誕生日会2026
you
PRO
0
180
感情と身体を置き去りにしない、エンジニアの生きのこり方 ──いまから、ここから「自分の状態」を扱うという選択
saorimurooka
0
340
Multi-Agent並列開発を 安全に回すための技術 / Technology for Safely Multi-Agent Parallel Development
tooppoo
0
170
Featured
See All Featured
Color Theory Basics | Prateek | Gurzu
gurzu
0
370
Measuring & Analyzing Core Web Vitals
bluesmoon
9
870
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
65
56k
Test your architecture with Archunit
thirion
1
2.3k
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
170
Heart Work Chapter 1 - Part 1
lfama
PRO
7
36k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.8k
A Soul's Torment
seathinner
6
3k
Exploring the relationship between traditional SERPs and Gen AI search
raygrieselhuber
PRO
2
4k
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
210
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4.3k
Code Reviewing Like a Champion
maltzj
528
40k
Transcript
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.1年前のUbieのデータ分析基盤とその課題 2.v1 データ分析基盤とその課題 3.v2 現在の構成へ 5
6 1年前のデータ分析基盤の論理設計 テーブル作成/更新はAirflowからのSQL実行により制御 6 1年前のUbieのデータ分析基盤とその課題
7 課題:再利用性が低く、拡がるニーズに応えられなくなった 1年前のUbieのデータ分析基盤とその課題 ソースデータから1つのSQLで特定の分析・可視化用途のマートを作成しており、 以下のような課題を抱えていた 1/ データ品質テストがしにくい 複数の条件の掛け合わせがあったり、そもそもSQLが長大でテストすべき条件の抽出が難しかった 2/
利用者・分析者の増加に対して、作業が非効率に ソースデータから一気にマートを作っているので、 「似たような処理だが少し違う」ケースのために同じようなデータマートを作り直したり… 7
8 再利用性/保守性を意識し、 次の設計へ… 8
9 目次 1.1年前のUbieのデータ分析基盤とその課題 2.v1 データ分析基盤とその課題 3.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.1年前のUbieのデータ分析基盤とその課題 2.v1 データ分析基盤とその課題 3.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