GENDAデータ基盤へのDatabricks導入時の状況と現在

ツール導入前の課題

MLOpsにあたるものがまだ構築できていないという課題がありました。また、グループ企業の増加に対応できるデータ基盤を模索したい思いもありPoCに進むことになりました。

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

• MLOps基盤の構築（実験管理からモデルサービングまで一貫して行える環境、Model Servingの活用、MLflowによる実験管理）
• BIツールの改善（Redashの代替、ダッシュボードのSlack通知、細かい権限管理）
• 費用面（dbt platformのユーザー数課金の代替、ユーザー数に応じた課金体系、グループ企業への展開しやすさ）

• Snowflake
• dbt platform (旧 dbt Cloud)
• Redash
• Amazon MWAA
• Amazon SageMaker

• 統合基盤としての強み（BI、ML、ETLを単一基盤で実現）
• Lakehouse Federation（Snowflake既存データへのシームレスなアクセス）
• コスト面での優位性（閲覧ユーザーを増やしても費用が増えない、Databricks Jobsでdbt運用可能）
• アナリスト業務との適合度

統合基盤としての強み

• BI、ML、ETLを単一基盤で実現できる点が大きな決め手となりました。

Lakehouse Federation

• Lakehouse FederationによりSnowflake既存データへのシームレスなアクセスが可能だったため共存しつつ導入ができると判断しました。

コスト面での優位性

• 閲覧ユーザーを増やしても費用が増えない課金体系でした。
• dbtジョブ実行基盤についてDatabricks Jobsで運用可能と判断しました。

アナリスト業務との適合度

• PoCに参加したアナリストからもBIツールとしての機能は十分とフィードバックを受けました。

• グループインする企業の状況に応じて柔軟なデータパイプライン構築を行えるようになりました。
• 各社の業務に合わせたダッシュボードを整備し、Excelを用いた手作業のKPI集計・社内配信を自動化しました。
• 機械学習環境をAWSからDatabricksに移行し、実験管理からモデルデプロイまで一貫して管理できる体制を整えました。

• PoCが終わった後、フリートライアル期間後に自動的に料金が発生しないようにする必要がありました。
• Databricks on AWSであることとSnowflakeへの接続の兼ね合いでAWSやSnowflake側で権限変更など調整が必要でした。

• PoCでは実際に利用するユースケースを明確にして検証することが重要です。
• Snowflake既存環境がある場合、Lakehouse Federationによる連携が有効です。
• 費用面では、閲覧ユーザーを増やしても費用が増えない課金体系が訴求ポイントとなりそうです。
• PoCでは「誰が何を検証するか」の役割分担を明確にして進めることをお勧めします。当社ではBI機能・ML機能・dbt/ETL機能・全体統括をメンバーごとに分担し、並行して検証を進めました。
• フリートライアルの終了タイミングと課金開始条件は事前に必ず確認してください。PoC期間終了後に社内承認を取る際、フリートライアル期間終了後に自動で課金が始まらないか確認する手続きが必要でした。
• dbt platformはユーザー数に応じた課金体系のため、開発者数が増えると利用規模によってはコストが高くなります。Databricks Jobsで代替することで、ユーザー数に依存しないパイプライン実行環境を構築できました。