■ 1. 概要
- 筆者はデータエンジニアリング支援会社の代表であり、主にdbtを用いたDWHデータモデリングを複数社で支援している
- データモデリングにおいて重要と考える考え方として以下の4点を挙げる
- 機械的にやる
- コンポーネント化する
- 冪等性を担保する
- まず使える状態にする
■ 2. 機械的にやる
- データモデリングの本質はモデリングの規則・ルールを決めることであり、個別テーブルやデータの問題解決は二次的な作業
- 抽象的なレベルでデータ加工を考えることが重要
- 具体例:
- レコードの重複問題に対し、単にSELECT DISTINCTで解決するのではなく、「重複削除をどの層で行うべきか」という抽象的な問いを立てる
- 開発側RDBへの修正依頼、staging層での対応、snapshot取得前の対応など、複数の論点を整理してルールを定める
- 抽象化による目的はスケーラビリティの確保
- 個別対応を繰り返すと一貫性のない「スパゲッティ型パイプライン」になる
- dbt導入のみではスケーラビリティは担保されず、規則やルールの整備が不可欠
- 定めるべき基本ルールの項目:
- データモデリング手法（Dimensional Modeling、Data Vaultなど）
- レイヤ分け（Staging層、Warehouse層、Mart層など）
- 命名規則
- 各レイヤの責務の決定（重複削除を行う場所など）
- ルールは新たな問題が生じるたびに継続的に改定していくことが基本動作
■ 3. コンポーネント化する
- 長いデータ変換ロジックを、特定の目的に特化したSQLファイル単位のコンポーネントに分割して管理する
- 具体例:
- ユーザーディメンションテーブルを1つのSQLで作成すると数百行の巨大ファイルになる
- 年齢・住所・所属企業など、カテゴリごとにdbtモデルを分割すると処理内容が一目で把握できる
- 最終的には分析用途のために1つの「ユーザーテーブル」として統合する
- コンポーネント化のメリット:
- ディメンションの追加・削除が安全かつ容易になる
- 影響範囲が明確で、他のディメンションへの影響を考慮せずに変更できる
- ファイル増加によるコスト懸念はdbtのMaterializations機能（view、ephemeralなど）で管理可能
■ 4. 冪等性を担保する
- 冪等性の定義: ある操作を1回行っても複数回行っても結果が同じであること
- データエンジニアリングにおける冪等性の問題は主に「レポートの数値変動」として顕在化する
- 過去に確定した数値が変わると、わずかなズレでも数値全体への不信感につながる
- 結果としてレポート自体が使い物にならなくなるリスクがある
- 冪等性が崩れる主な原因:
- GA4ログなどのレイトヒット問題
- SCD Type1によるデータ上書き問題
- current_timestampなど実行時間に基づいた処理
- SCD Type1問題への対処: dbt snapshotを使用することで履歴を保持し、任意時点の情報を再現可能にする
- incrementalモデルによる履歴保持はアンチパターン:
- カラム追加やロジック変更の際にfull-refreshが必要となり、保持していた過去データが消失する
- コスト削減効果は高いが、冪等性を担保できない構成になりやすい「諸刃の剣」
■ 5. まず使える状態にする
- まずユーザーが使えるデータマートを作成することを優先し、その後にリファクタリングとして既存モデリングルールに整合させる
- この方針の目的:
- データエンジニアリングが事業の律速となることを防ぐ
- 使われないデータ基盤を作る無駄を排除する
- ソース側から順に構築すると、マート利用開始まで工数がかかりすぎる
- MVPの概念に近いアプローチで、先にデータマートを作成して実際の利用状況を確認する
- よく使われるデータマートを把握した上で、重要度の高い部分に絞ってリファクタリングを実施する
- 注意点:
- 数値が誤っているデータを提供してはならず、品質（正確性）は妥協しない
- 「使える状態にする」とは設計・構造上の問題を一時保留にするという意味であり、データの正確性を犠牲にするものではない
- 丁寧なモデリングにより修正コストが減り、結果として工数が短縮されるケースもある