支援例
Delta Lake テーブル設計支援
業種: データ基盤
背景
複数部門がそれぞれ異なる粒度・命名・更新方式でデータを保持しており、分析やAI活用のたびに個別加工が発生していました。Lakehouse化に向けて、まずはDelta Lake上で再利用しやすいデータ構造を定義する必要がありました。
課題
部門ごとにデータ管理方式が異なり、分析用途に応じた再利用が難しい状態でした。
想定スコープ
- 既存DWH・ファイル連携・部門別マートを対象に、Lakehouseへ載せ替える前提データを整理。
- 業務別にRaw、標準化、集計、AI利用候補データを分類し、Delta Lake上のテーブル責務を定義。
- 日次・随時更新データを想定し、再処理、差分更新、履歴保持の設計観点を整理。
支援内容
Bronze / Silver / Gold のレイヤ設計、Delta Lake テーブル設計、更新方式、品質チェック方針を整理しました。
技術ポイント
- Bronze / Silver / Gold の責務を分け、Raw保持、標準化、業務集計の境界を明確化しました。
- Delta Lake のパーティション、更新キー、履歴保持、スキーマ進化を前提にテーブル設計を整理しました。
- 品質チェック、重複排除、再処理可能性をパイプライン設計に組み込み、AI利用時の信頼性を高めました。
進め方
- 既存テーブル、ジョブ、BI参照先を棚卸しし、業務上の共通エンティティと部門固有項目を切り分けました。
- 代表データを使ってDelta Lakeのテーブル粒度、更新方式、品質ルールを検証しました。
- 命名規約、レイヤ定義、運用時の変更手順をドキュメント化し、実装チームへ引き継ぎました。
成果物
- Bronze / Silver / Gold レイヤ定義書とテーブル命名規約。
- Delta Lake テーブル一覧、キー設計、更新方式、品質チェック項目の設計資料。
- 代表データを使ったサンプルDDL、更新SQL、再処理手順。
リスクと対策
- メダリオンレイヤの境界が曖昧になるリスクに対し、各レイヤで許容する加工範囲を明文化。
- スキーマ変更による下流影響を抑えるため、追加・変更・廃止時のレビュー手順を定義。
- 重複データや遅延到着データに備え、更新キーと再実行可能な処理単位を整理。
使用技術
成果
分析・BI・AI活用の前提となるデータ構造を標準化し、継続的なデータ活用に向けた基盤を整備しました。
- 分析・BI・AIで同じデータ定義を参照しやすくなり、個別加工の重複を抑えられる設計になりました。
- 新しいデータソース追加時も、どのレイヤに配置するか判断しやすい基準が整いました。
- 将来的なUnity Catalog管理やデータ品質監視につながるLakehouse基盤の土台を作りました。
次フェーズ
- Unity Catalogによるカタログ管理と権限設計へ接続。
- Databricks Workflowsでの本番パイプライン化。
- BI・AI利用を想定したGold層データマートの追加設計。