カナダのオペレーター：データサイロ12個→lakehouse、リアルタイムKPI。

すべての部署が同じKPIに異なる数字を与えるとき、決定を下しているのではなく、意見間で調停しているのです。

コンテキスト

カナダの交通オペレータ、11,000人従業員、モントリオールハブ。12の歴史的データサイロ（運営、HR、財務、発券、メンテナンスなど）、老朽化Oracleデータウェアハウス、メールで送られるExcelダッシュボード。

問題

• 共通ガバナンスなしの12データサイロ
• 部署間で矛盾するKPI（同じ指標で最大18%のギャップ）
• 48時間遅れのダッシュボード、手動更新
• データカタログなし、重複と曖昧な定義
• SQL抽出で行き詰まったアナリスト、低い業務自律性

アプローチ

メダリオンアーキテクチャ（bronze/silver/gold）のDatabricksデータレイクハウス、Unity Catalogガバナンス、バージョン管理されたdbt変換、セマンティックレイヤー付きセルフサービスTableau BI。

柱

• Auto Loader経由のリアルタイム取り込み（Kafka + ファイル）
• dbt次元モデリング、必須品質テスト
• ガバナンス、リネージ、RBACのためのUnity Catalog
• Tableauに公開されたセマンティックレイヤー（集中化された業務定義）
• イネーブルメントプログラム：4か月でアナリストの60%トレーニング

スタック

• AzureのDatabricks Lakehouse Platform
• バージョン管理された変換のためのdbt Cloud
• ガバナンスとリネージのためのUnity Catalog
• セマンティックレイヤー付きTableau Cloud
• 取り込みオーケストレーションのApache Airflow

結果

1. 単一真実ソース：運用KPIの100%を調整
2. ダッシュボードレイテンシ：48時間からリアルタイム（KPIの80%で1分未満）
3. 自律アナリスト：4か月で60%（目標12）
4. データコスト：処理ボリューム3倍にもかかわらず-22%
5. データ品質問題：9か月で-76%

学んだこと

Unity CatalogはDatabricksの真の差別化要因で、Sparkエンジンではありません。dbtは800モデルまで非常によくスケールし、それを超えるとモジュラー化に投資する必要があります。間違い：silverを統合する前にgoldレイヤーを納品し、高価なロールバック。やり直すなら：dbtテストが90%グリーンになる前にアナリストアクセスを開かない。そうでなければ、信頼を失い、取り戻せません。