Databricks Genie Codeだけを使ったAI駆動開発でLakeflow SDPパイプラインを構築する

dmc_bank_lab                         ← Catalog
├── bronze                           ← Schema
│   └── dmc_bank_raw                  ← Volume：CSVの保存先
│       ├── customer/
│       │   └── customer_cdc_feed.csv
│       ├── account/
│       │   └── account_seed.csv
│       └── transaction/
│           └── transaction_seed.csv
├── silver                           ← Schema：整形後のデータの出力先
└── gold                             ← Schema：集計結果の出力先

DMC Bankのデータエンジニアリングプロジェクト向けに、エンドツーエンドのLakeflowパイプラインを構築してください。

重要事項：
- SQLだけを使用してください。Pythonは使わないでください。
- 現在のDatabricks Lakeflow PipelinesとApache Spark Declarative Pipelinesのベストプラクティスに従ってください。
- 必要な場合を除き、私にパイプラインのコードを手書きするよう求めないでください。
- まず利用可能なソースファイルとスキーマを調査し、その後パイプラインを作成してください。

入力元：
- Catalog: dmc_bank_lab
- Schema: bronze
- Volume: dmc_bank_raw
- 入力場所: /Volumes/dmc_bank_lab/bronze/dmc_bank_raw/

入力Volumeには、次のCSVデータセットがあります。
- customer/customer_cdc_feed.csv
- account/account_seed.csv
- transaction/transaction_seed.csv

アーキテクチャ：
次の完全なMedallion Architectureを実装してください。

Source Volume → Bronze → Silver → Gold

1. Bronze — メタデータ駆動の取り込み

- SQLを使用してください。
- 取り込みにはStreaming Tableを使用してください。
- read_files / Auto Loaderをストリーミングの読み取り方式で使用してください。
- 入力ごとに無関係な取り込みロジックを個別に手作業で作るのではなく、メタデータ駆動で再利用可能な方法で実装してください。
- CSVファイルを増分処理してください。
- 必要に応じて、入力ファイル・パス、取り込み時刻などの有用なメタデータを保持してください。
- 適切なスキーマ推論・スキーマ処理を使用してください。
- Bronzeの変換は最小限にし、元データに近い状態を保ってください。

2. Silver — クレンジングとデータ品質

BronzeからSilverのStreaming Tableを作成してください。
変換を設計する前に、実際のスキーマとデータの関係を調べてください。

以下を含む、適切な変換を適用してください。
- データ型の統一
- NULLの処理
- 重複の処理
- 参照整合性・データ整合性のチェック
- 業務ルールの検証
- 適切な列の標準化

SQLの制約を使って、Lakeflowのデータ品質Expectationを追加してください。
実際のDMC Bankのスキーマに基づいて、妥当なExpectationを選んでください。

各Expectationでは、次を行ってください。
- 意味の分かる名前を付ける。
- ルールを明確に示す。
- WARN、DROP ROW、FAIL UPDATEを適切に使い分ける。
- 適切な場合には明らかに不正なレコードを除外し、
  パイプラインの整合性に関わる重大な違反の場合だけ更新を失敗させる。

Expectationを確定する前に、選んだ品質ルールと、その理由を説明してください。

3. Gold — 業務KPI

Silverレイヤーに基づいてGoldのMaterialized Viewを作成してください。
銀行業務にとって意味のあるKPIを含む、業務で利用できるデータセットを作成してください。

少なくとも以下を含めてください。
- 総取引件数
- 総取引金額
- 平均取引金額
- アクティブ顧客数
- 時系列での取引傾向
- 必要に応じた顧客別または口座別の取引指標

入力データに実際に存在する列と関係を使用してください。
存在しない列を作り出さないでください。

4. 環境のパラメータ化

DEV → STAGE → PRODへ移行しやすいパイプラインにしてください。
カタログ名を固定値で埋め込まず、同じコードを複数環境へデプロイできるように、
カタログや環境固有の値をパラメータ化してください。

次を使用してください。
- 現在の開発環境にはdmc_bank_lab
- StageとProductionには設定可能なカタログパラメータ

変換ロジックの中に環境固有のカタログ名を固定値で埋め込まないでください。
スキーマやVolumeパスもパラメータ化すべきか判断し、本番向けに最も整理された方法を提案してください。

5. パイプラインの設計

- Lakeflowの宣言的な依存関係の解決を利用してください。
- データセットへの参照によって、Bronze → Silver → Goldの依存関係を明確にしてください。
- BronzeとSilverにはStreaming Tableを使用してください。
- Goldの集計にはMaterialized Viewを使用してください。
- 現在のLakeflowの命名規則とSQL構文に従ってください。
- 非推奨のDLT構文を使用しないでください。
- 従来のLIVEスキーマ構文を使用しないでください。

6. 検証

パイプラインを生成したら、次を行ってください。
- パイプラインを検証する。
- 実行する。
- パイプライングラフを確認する。
- データ品質の結果を確認する。
- Bronze、Silver、Goldの出力を検証する。
- エラーが発生したら、根本原因を調査し、パイプラインを修正して再実行する。
- エラー修正の際に何を変更したか説明する。

7. 最終的な出力

最後に、次を提示してください。
- パイプラインのアーキテクチャ
- 作成したテーブル・ビュー
- 実装したデータ品質Expectation
- 作成したGoldのKPI
- 作成したパラメータ
- 置いた仮定
- 本番デプロイに向けた推奨事項

目標は、SQLとGenie Codeだけを使って、実用的で本番を意識した
DMC BankのLakeflowパイプラインを作成することです。

Silverのcustomerテーブルは、SCD Type 1になるよう修正したいです。
operation、event_timestampを用いてAUTO CDCを使い、SCD Type 1で顧客の現在状態を保持してください。

Goldレイヤーには、以下の4つのMaterialized Viewを作成するように修正してください。
- transaction_type、transaction_status、direction別に集計した取引KPI
- 時系列分析のための日次取引動向
- ポートフォリオ分析のための口座単位の取引指標
- 口座・取引指標を含む顧客単位の360度ビュー