rawSQLからdbtへの移行プロセスについて

Transcript

1. rawSQLからdbtへの 移行プロセスについて DATUM STUDIO株式会社 向井 雄二 2022年8月23日
2. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 1 Whoami select * from employnee where name = ‘向井雄二’; name company role twitter job 向井雄二 DATUM STUDIO データエンジニア @ugmuka データ分析基盤の 受託開発
3. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 2 アジェンダ 1. Introduction
4. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 3 データ分析基盤のベストプラクティス 構築初期 ✓ データマートは直接データレイクを参照 ✓ ユースケースに合わせてデータマートを作成 > 初期段階ではデータウェアハウス層を作らない（「実践的データ基盤への処方箋」） データマート層 データレイク層 データマート層 データレイク層 データウェア ハウス層 構築中盤 ✓ スタースキーマなどでモデリングデータウェアハウス層を作成 ✓ 共通指標からデータマートを作成
5. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 4 今日の話題 構築初期 ✓ データマートは直接データレイクを参照 ✓ ユースケースに合わせてデータマートを作成 > 初期段階ではデータウェアハウス層を作らない（「実践的データ基盤への処方箋」） データマート層 データレイク層 データマート層 データレイク層 データウェア ハウス層 構築中盤 ✓ スタースキーマなどでモデリングデータウェアハウス層を作成 ✓ 共通指標からデータマートを作成 今日の話題：実際移行ってどうやる？
6. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 5 アジェンダ 2. よくあるケース
7. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 6 よくあるケース 改善ポイント ✓ 直接データレイク層からクエリ発行すると分析ロジックが複雑になりがち ✓ 分析ができるようにBIを構築したい RDSベースでの分析基盤からSnowflake, BQへの移行 データマート DB 基幹システムの DB アナリスト 基幹システムの DB S3 データレイク層 データウェア ハウス層 データマート層 BI ✓ Excel ✓ Redash etc… ユーザー ユーザー 移 行 前 移 行 後
8. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 7 rawSQLからdbtへの移行 SQLをワークフローエンジンで制御→dbtでHappyになる rawSQL dbt DRYさ ✓ jinjaでテンプレート化できるため簡潔 ✓ 大規模になると長大なコードになる ドキュメント化 ✓ とても大変 ✓ 自動でドキュメント生成される 依存関係 ✓ 実行順を考慮してワークフローエンジンを実 装する必要がある ✓ 考慮不要 可読性 ✓ 基本的に読みやすい ✓ 過度なテンプレート, macro化でなければ SQLと同等 ※DRY: Don‘t Repeat Yourselfの略
9. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 8 移行時の差分 AsIs コード実装 ✓ SQLを直書き ダッシュボード ✓ なし マート 作成方式 ✓ select + insertで追記 モデリング ✓ なし ToBe ✓ dbtで簡潔なコード ✓ TableauやLookerの開発が必要 ✓ 毎回全量テーブル作成 （incrementalであれば差分更新も可） ✓ スタースキーマ
10. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 9 アジェンダ 3. 移行のプラクティス
11. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 10 移行前に事前検証期間を設ける 事前にdbtでマートの仮組みを行って、これまでユーザーの見ていたもの（※重要）と一致しているか確認 ロジック実装 ダッシュボード マート 作成方式 モデリング AsIs ✓ SQLを直書き ✓ なし ✓ select + insertで追記 ✓ なし ToBe ✓ dbtで簡潔なコード ✓ Lookerの開発が必要 ✓ 毎回全量テーブル作成 ✓ スタースキーマ 事前検証 ✓ dbtで仮組み ✓ リファクタ前提 ✓ なし ✓ すべてビュー ✓ スタースキーマ
12. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 11 なぜ事前検証が必要？ ex) • 上流システムでバグが起きていて、分析クエリを書くときに常にク レンジングしている • 経理部門と事業部門で同じ指標を見ているが定義が違う 2. 実際にユーザーが使用している集計結果との 比較をリリース前に行う 1. 移行前に行われていた分析の暗黙知を抽出する ex) • 実際にユーザーにレポートされていた集計結果はマートから更に 担当者がExcelで加工したものだった • 「この数字いつもみてるやつと全然違うんですけど…」 →SQLの完全移行でないPJでも、急激な数値の変更は混乱 を招く
13. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 12 Good/Bad practice 事前検証→ToBeでの変更点が多くなると、数値のずれが発生しがち ロジック実装 ダッシュボード マート 作成方式 モデリング 事前検証（Good） ✓ dbtで仮組み ✓ リファクタ前提 ✓ なし ✓ すべてビュー ✓ スタースキーマ 事前検証（Bad） ✓ SQLを直書き ✓ なし ✓ すべてビュー ✓ なし pros • 最悪SQLをそのまま載せるだけで もよい。 • このビュー最新だっけ？問題が発 生しない。 pros • 本番と同じ構造だとデバッグしやすい。 • 最小粒度で集計するので色々な形で 検証できる（週次、月次、Qごと…）
14. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 13 Bad practice Badで進めるとこうなります ロジック実装 ダッシュボード マート 作成方式 モデリング AsIs ✓ SQLを直書き ✓ なし ✓ select + insertで追記 ✓ なし ToBe ✓ dbtで簡潔なコード ✓ Lookerの開発が必要 ✓ 毎回全量テーブル作成 ✓ スタースキーマ ✓ SQLを直書き ✓ なし ✓ すべてビュー ✓ なし 前述の実際の分析ロジックとの乖 離で燃えやすい。 担当者にヒアリングしないとわから ないこともあるため、回避は難し い。 事前検証→ToBeへの変更点が 多いと燃える。差分を減らすよう に事前検証の時点で実装すれば 回避できる。 事前検証（Bad）
15. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 14 アジェンダ 4. まとめ
16. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 15 今日の話題 構築初期 ✓ データマートは直接データレイクを参照 ✓ ユースケースに合わせてデータマートを作成 > 初期段階ではデータウェアハウス層を作らない（「実践的データ基盤への処方箋」） データマート層 データレイク層 データマート層 データレイク層 データウェア ハウス層 構築中盤 ✓ スタースキーマなどでモデリングデータウェアハウス層を作成 ✓ 共通指標からデータマートを作成 今日の話題：実際移行ってどうやる？ 冒頭のやつ
17. © 2022 DATUM STUDIO Co. Ltd. PROPRIETARY & CONFIDENTIAL. 16 まとめ データマート層 データレイク層 データマート層 データレイク層 データウェア ハウス層 データマート層 データレイク層 データウェア ハウス層 rawSQL きたないdbt きれいなdbt 2. 検証の比較元を決める ✓ 全社向けの経営レポート、etc… 3. dbtで仮に値を出す ✓ データ構造は本番と同じ形 （スタースキーマ、data vaultなど） ✓ 過度にtemplate化する必要はない 4. dbtonicなコードにリファクタ ✓ レガシーなSQLからdbtのSQLへのリファクタリング などが参 考になる 1. 事前検証期間を設ける ✓ 大体この期間で要件変更が起こる