Databricks Lakehouse Federationで 運用負荷ゼロのデータ連携

Transcript

1. @IVRy Inc. All rights reserved. Databricks Lakehouse Federationで 運⽤負荷ゼロのデータ連携 株式会社IVRy データエンジニア 松⽥ 健司 JEDAI Meetup! AIエージェント特集 - Lakebase連携からセキュリティまで
2. ヤフー株式会社（2014 - 2016） 新卒⼊社し、広告配信システムのDMP開発に従事。 株式会社カケハシ（2016 - 2025）  薬局向けSaaSのスタートアップに6⼈⽬として参画。  ソフトウェア開発を起点に、データエンジニア、  エンジニアリングマネージャーまで、事業の成⻑に  合わせて幅広く経験。 株式会社IVRy（2025) データエンジニアとして、データ基盤の構築に従事。 松⽥ 健司 Data Engineer @ken_3ba 2
3. IVRとAIであらゆる電話対応を効率化 「アイブリー」 3 プロダクト
4. IVRy Data Hub をリリース 4
5. 5 オフィスの壁が拡張されました
6. @IVRy Inc. All rights reserved. 今⽇話すこと 6 https://zenn.dev/ivry/articles/databricks-lakehouse-federation-guide
7. @IVRy Inc. All rights reserved. アジェンダ 7 1. なぜ Lakehouse Federation を導入したのか 2. 導入後の構成と View の自動作成の仕組み 3. ハマったポイント 4. まとめと今後
8. @IVRy Inc. All rights reserved. Lakehouse Federationとは？ 8 外部データベースのデータをコピーせず に Unity Catalog 経由で直接クエリできる機能 メリット • データコピー不要 → ETLジョブ・ストレージコスト削減 • リアルタイム参照 → ソースDBの最新データを直接参照 • Unity Catalog でガバナンス統一 → アクセス制御・リネージを一元管理 なぜ Lakehouse Federation を導⼊したのか
9. @IVRy Inc. All rights reserved. IVRyのデータアーキテクチャ 9 なぜ Lakehouse Federation を導⼊したのか https://findy-tools.io/companies/ivry/90/76
10. @IVRy Inc. All rights reserved. 10 なぜ Lakehouse Federation を導⼊したのか 課題:テーブルが増えるたびに 人手が必要 な運用だった Created by Nano banana
11. @IVRy Inc. All rights reserved. アジェンダ 11 1. なぜ Lakehouse Federation を導入したのか 2. 導入後のアーキテクチャと View の自動作成の仕組み 3. ハマったポイント 4. まとめと今後
12. @IVRy Inc. All rights reserved. 12 導⼊後のアーキテクチャとView の⾃動作成の仕組み 導入後のアーキテクチャ パフォーマンスを考慮し、大規模テーブルはdltHubによる差分更新を維持
13. @IVRy Inc. All rights reserved. 13 導⼊後のアーキテクチャとView の⾃動作成の仕組み Viewを自動作成・削除するテーブルの選定 作成と削除はDatabricks SQLで、対象外はdbtで管理
14. @IVRy Inc. All rights reserved. アジェンダ 14 1. なぜ Lakehouse Federation を導入したのか 2. 導入後の構成と View の自動作成の仕組み 3. ハマったポイント 4. まとめと今後
15. @IVRy Inc. All rights reserved. 15 ハマったポイント その1: NLB の PrivateLink 設定 PrivateLink経由の通信はSGのチェックをスルーする必要があった https://docs.databricks.com/aws/en/security/network/serverless-networ k-security/pl-to-internal-network
16. @IVRy Inc. All rights reserved. 16 ハマったポイント その2: NCCの制約 ワークスペースが単一のNCCにしかバインドできなかったため、 全ワークスペースを 1つのNCCに統合する方針 で運用
17. @IVRy Inc. All rights reserved. 17 ハマったポイント その3: ServerlessとClassicで接続ルートが異なる 一部のジョブがClassicのままだったためFederationカタログを参照すると エラーが発生した →ServerlessはPricateLink、ClassicはVPC Pering経由に！ https://docs.databricks.com/aws/en/security/network/serverless-network-security/ pl-to-internal-network
18. @IVRy Inc. All rights reserved. アジェンダ 18 1. なぜ Lakehouse Federation を導入したのか 2. 導入後の構成と View の自動作成の仕組み 3. ハマったポイント 4. まとめと今後
19. @IVRy Inc. All rights reserved. 19 まとめと今後 まとめ: 導入の成果 大規模テーブルと PII テーブルは Federation から除外し、 安全かつパフォーマンスの良い構成に Before After テーブルの追加 Slack申請→手動対応 自動 データ鮮度 数時間に一度 リアルタイム コスト ジョブとストレージ ゼロ 運用負荷 ジョブ監視・障害対応 ほぼゼロ
20. @IVRy Inc. All rights reserved. 20 まとめと今後 今後 1. データ削除時の影響 ◦ PostgreSQLのデータが削除されると後続のデータ利用に影響が出る問題 への対応 2. 大規模テーブルの対応 ◦ dltHubをLakeflow Connectを利用してCDC 更新へ移行し、 よりリアルタイムかつコスト削減した連携を目指す
21. @IVRy Inc. All rights reserved. we are hiring 21