Databricks連携で実現する DWHモダナイゼーション

「第1回 Youは何しにDatabricksへ！？」でお話いただいたマネーフォワード様の資料です

Transcript

1. Databricks連携で実現する DWHモダナイゼーション
2. Yamazaki Junya Data Strategy Office　 Data Engineering Division DRE Group 2021年2月マネーフォワードに入社 現在の分析基盤を構築。 最近はデータ・インフラの統合、最適化に注 力しています。
3. Agenda 1. Platform概要
 2. Project Raven
 3. アーキテクチャ Before & After
 4. Platform統合の上り方
 5. Ravenとは
 6. まとめ

4. 基盤概要
5. 分析基盤 概要 ３種類の基盤が存在
 - Crow, AWS databricks 
 - セキュアな環境
 - InfoDB, GCP Bigquery in tokyo 
 - 次にセキュアな環境
 - Fractal, GCP Bigquery in US 
 - カジュアルな環境

6. https://speakerdeck.com/databricksjapan/databricksniyorusekiyu adexiao-lu-de-nadetaenziniaringunoshi-xian
7. 分析基盤 概要 ３種類の基盤が存在
 - Crow, AWS databricks 
 - セキュアな環境
 - InfoDB, GCP Bigquery in tokyo 
 - 次にセキュアな環境
 - Fractal, GCP Bigquery in US 
 - カジュアルな環境

8. 同じETLを二箇所で実行している 
 - DatabricksとBigQueryは同じS3をデータソース としている
 - 同じテーブルがDatabricksではDatabricks jobsで、BigqueryではCloud composerで作成 されている
 分析基盤 イシュー
9. VDIからBigqueryへの参照がつらい 
 - セキュリティ上の理由により BigqueryはA5M2経 由でのみ提供
 - Service accountがクエリを発行するため個 人の区別がつかない
 - JDBC越しなのでBigquery Consoleの機能 は使えず
 分析基盤 イシュー
10. 転送コストが高い 
 - Storage Transfer Service をS3→GCSで利用
 - 実は保存コストより転送コスト (転送に利用す るlist, get APIリクエスト代含む)の方が高い
 分析基盤 イシュー
11. Databricksの環境が古い 
 - ３環境で一番古く、当時を知るものはいない 
 - Hive metastore使用
 - Databricksに関してはIaCなし
 - AWSのリソースに関してはある 
 分析基盤 イシュー
12. Databricks連携で実現する DWHモダナイゼーション
13. 古いDatabricks基盤の 移行奮闘記
14. Project Raven ~databricks統合~
15. Project Raven databricks統合 in Raven Poject
 • 統合化されたCrow+InfoDB environment
 ◦ New databricks workspace for Raven
 • リソースは全てコード管理
 ◦ インフラ、ジョブ共に
 • 環境はDatabricks
 • 閉塞環境での提供

16. 分析基盤 概要 ３種類の基盤が存在
 - Crow, AWS databricks 
 - セキュアな環境
 - InfoDB, GCP Bigquery in tokyo 
 - 次にセキュアな環境
 - Fractal, GCP Bigquery in US 
 - カジュアルな環境

17. Project Raven Difference 
 • For Crow User
 ◦ 以下が提供開始
 ▪ serverless SQL warehouse
 ◦ 管理がUnity Catalog移行
 ▪ Data lineage
 ▪ Data quority
 ▪ Permission control
 • For InfoDB User
 ◦ Databricks consoleが利用可能
 ▪ Auto complete
 ▪ Suggest
 ▪ Chat with LLM
 • Query optimization
 ▪ Save query
 ▪ Query history 
 ◦ それぞれのユーザ単位で Auditlogが 自動保存される

18. Architecture Before & After
19. 分析基盤 Before ３種類の基盤が存在
 - Crow, AWS databricks 
 - セキュアな環境
 - InfoDB, GCP Bigquery in tokyo 
 - 次にセキュアな環境
 - Fractal, GCP Bigquery in US 
 - カジュアルな環境

20. 分析基盤 After 2種類の基盤に統合
 - Raven, AWS databricks 
 - セキュアな環境
 - 次にセキュアな環境を兼ねる
 - Fractal, GCP Bigquery in US
 - カジュアルな環境

21. Platform 統合
22. Platform 統合 Phase 1 ３つにフェーズ分け
 - Phase 1:
 - Create new workspace
 - 既存の環境からデータを 読む
 - 既存の環境は触らない
 これで
 • 閉塞環境下での挙動の確認
 • 権限統制の確認

23. Platform 統合 Phase 2 - Phase 2:
 - CrowとInfoDBのETLを実施 
 - InfodbがFractalへの踏 み台に
 - S3→GCSは継続
 
 これで
 • 両環境の比較可能
 

24. Platform 統合 Phase 3 - Phase 3:
 - 統合
 - DWHの役割を完全移行
 - マートはBigqueryに
 - これはアナリスト、 マーケターなどの ユースケースに依存

25. Raven
26. Project Raven databricks統合 in Raven Poject
 • 統合化されたCrow+InfoDB environment
 ◦ New databricks workspace for Raven
 • リソースは全てコード管理
 ◦ インフラ、ジョブ共に
 • 環境はDatabricks
 • 閉塞環境での提供

27. Raven CI/CD ほぼ全てのリソースが IaC対象
 - Infra
 - Terraform
 - Job
 - Databricks Asset Bundle

28. Raven CI/CD ほぼ全てのリソースが IaC対象
 - Infra
 - Terraform
 - Job
 - Databricks Asset Bundle
 ※対象外
 - Terraformにない機能
 - Schema
 - 権限のバインディングはコード管理され ている

29. Raven Auth 権限管理
 - SSOでログイン
 - EntraIDでユーザグループを管理
 - 権限はグループ単位でバインディン グ
 - 個人単位の管理は不要

30. Raven Table structure テーブル構成 
 - 現状我々でマート作成は実施して いない
 - Goldは現在なし
 - カラム単位での制御のため Dynamic Viewでグループごとの 制御を実施

31. Raven Table structure テーブル構成 
 - 現状我々でマート作成は実施して いない
 - Goldは現在なし
 - カラム単位での制御のため Dynamic Viewでグループごとの 制御を実施
 
 ※Dynamic Viewはタイムトラベルを使 えないので一部silverを解放している

32. Raven AI/ML Ravenから様々な方式で連携 
 - Delta Sharingでテーブルを共有
 - ModelデータをS3経由で共有
 - DatabricksのAPIで共有
 - とかとか

33. Raven AI/ML Ravenから様々な方式で連携 
 - Delta Sharingでテーブルを共有
 - ModelデータをS3経由で共有
 - DatabricksのAPIで共有
 - とかとか
 
 ※統合予定

34. Raven Cluster management 閉塞環境下でもユーザが望む 
 環境を
 - 任意のDocker imageをPR経由で 利用可能
 - クラスタに関する権限もEntraIDの グループで管理

35. Raven 管理観点 - System tableが有用
 - 有効にするだけで勝手に収集
 - ディスクリプションも埋まってる
 
 

36. Raven 管理観点 - System tableが有用
 - 有効にするだけで勝手に収集
 - ディスクリプションも埋まってる
 
 Genieとの相性がいい！ 
 

37. Raven ユーザ調査
38. Raven ユーザ調査
39. まとめ
40. 統合のアプローチ フェーズに分けた統合作業 
 - 並列稼働によりリスク、ダウンタイムを軽減 
 権限管理の先進化 
 - 既存のEntraIDベースで権限構成を組み立て管理工数を節約 
 Infrastructure as Code (IaC)
 - 自動化によりミスが減り、効率が向上 
 

41. - Databricksのカタログ移行は一気に行わず平行稼働すべき - パーミッションなど変更範囲が広いため - Bigqueryのレイクハウスフェデレーションはとても便利だが、パフォーマン スには気をつけて - Genieをusageの調査に使うのは役に立った - System tablesとの組み合わせは再現性がある - エラーの自動解決は、BigQueryからのクエリを書き換える際にも役に立っ た。
 学び
42. We are hiring!