Lakehouse Federation によるプロダクト DB 連携の運用負荷ゼロ化

ツール導入前の課題

IVRy は電話自動応答サービスを中心とした対話型音声 AI SaaS で、飲食・医療・不動産など幅広い業種の店舗・企業に導入いただいています。社内分析基盤としては Databricks を利用しており、プロダクト DB（PostgreSQL）から分析基盤への取り込みは当初 dltHub によるバッチ同期 で運用していました。テーブルが増えるたびに「追加申請 → エンジニア対応 → ジョブ追加」の3段階の手作業が発生し、データ鮮度も日次バッチに律速され、ストレージとジョブのコストも線形に増えていく状態でした。

どのような状態を目指していたか

テーブル追加・削除に対する手作業がゼロで、最新のプロダクト DB をそのまま分析・LLM 用途で参照できる状態を目指しました。

• Databricks Lakehouse Federation
• dltHub（既存運用）

既存の Databricks 基盤と一体運用できること、同期ジョブを書かずに済むこと、Unity Catalog でガバナンスを一元化できることを重視しました。

Lakehouse Federation はデータをコピーせず Unity Catalog 経由で外部 DB を直接クエリできるため、ETL を組まずに連携できるのが決定打でした。同期ジョブとコピー先ストレージのコストが構造的に消えます。

改善したかった課題はどれくらい解決されたか

テーブル追加の手作業はほぼゼロになり、データ鮮度は日次バッチからクエリ時参照に変わりました。

どのような成果が得られたか

テーブル追加の運用作業が減り、データをリアルタイムで参照できるようになり、コストも抑えられました。

主に以下の3点で詰まりました。

• ネットワーク構成: NLB の PrivateLink 設定、NCC のバインド制約、Serverless / Classic の接続ルート統一
• 差分更新の扱い: Federation はクエリ時参照のため大規模テーブルへの全件スキャンが現実的でなく、どこを Federation に寄せてどこを ETL 同期で差分更新するかの切り分け設計が必要でした
• PII 情報の扱い: 個人情報を含むテーブルを Federation View としてそのまま露出させないため、メタデータテーブル側で skip 判定をかけ、対象を明示的に除外する運用にしました

詳細は Zenn 記事 を参照してください。

「すべてを Federation に置き換える」のではなく、Federation と ETL 同期の二層構造を最初から設計に入れるのがおすすめです。あわせて、テーブル追加・削除を自動化する仕組みを最初から組んでおくと、運用負荷が構造的にゼロに近づきます。

大規模テーブル側に残しているdltHubは、Lakeflow Connect の CDC 機能への移行の検討を進めていきます。