RedshiftからDatabricksへの移行と活用法

導入背景

会社について

弊社は伊藤忠、ファミリーマート、NTTドコモ、サイバーエージェント出資によるスタートアップで、ファミリーマートの購買データ、NTTドコモのdポイントクラブのデータ、サイバーエージェン トのデジタル広告のノウハウを活用し新しい広告配信サービスを提供しています。
その中で、広告配信のプランニング・広告配信結果の効果検証などのレポート作成等でデータ基盤を活用しています。

データ基盤について

親会社のNTTドコモが保有する約1億ユーザのdポイントクラブや2,000万DLを超えるファミリーマートのアプリ「ファミペイ」の会員データと、
ファミリーマート国内16,000超の実店舗から、レジ通過数一日約1500万の購買データ、
自社で保有する広告配信プラットフォームから1日約7億件のログを扱うデータ基盤を構築しています。
さらに、最近ではドン・キホーテなどを展開するPPIHグループや、レシートアプリ「ONE」を運営するWED社との協業によって取り扱うデータ量も増大しています。
既存のRedshiftを使用したデータ基盤では、ビジネスの拡大に伴うデータ量の増大と分析の複雑化により、負荷の高いクエリの実行時にパフォーマンスの問題が発生していました。 また、AWS利用料全体に占めるRedshiftの利用料の割合が大きかったため、クラスタをスケールアップしてパフォーマンス問題に対処するのはできれば避けたい状況でした。
そういった状況のなかで、パフォーマンスやコストが改善すること、今後さらにデータ基盤の需要が拡大しても対応できるようなツールを探していました。

セルフ分析環境について

別の課題として、基本的な分析は自動化されているものの、特殊な要件がある場合には営業からアナリストへ分析を依頼し、結果が返ってくるまで時間がかかるということがありました。
そのため、SQLを扱えなくてもある程度自由に分析できる分析環境も探していました。

比較検討したサービス

• Redshift Serverless
• Snowflake

比較した軸

• 既存のRedshiftと比較した際のコストの安さ、パフォーマンスの高さ
• 将来的な拡張性
• CSVやParquetでS3に構築していたデータレイクへの接続の容易さ
• 既存のRedshiftやAthenaとの相互利用が可能かどうか

選定理由

データ基盤として

PoCの際にRedshiftで負荷がかかっているクエリをとしてDatabricksで実行してみました。 その結果、Redshiftクラスタの半額ほどのコストのSQL Warehouseで、Redshiftで数時間かかっていたクエリが数分で完了し、コストパフォーマンスが優れていると判断しました。

セルフ分析環境として

社内でよくあるパターンの分析(ファミリーマートで一緒に買われている商品の組み合わせ(併買分析)や、セグメントのデモグラ分析など)を日本語でGenieに指示してみると、正しい回答を返してくれたため、問題なく使えそうだと判断しました。

導入の成果

主にETL/分析のパフォーマンス向上に効果を感じています。

• Redshift移行のきっかけとなった高負荷のクエリでパフォーマンス問題が発生することがなくなったことは勿論、その他のワークフローも全体的に高速化しました。
  特にParquetやCSVファイルをSpectrumでクエリしていた処理をDelta Lake + SQL Warehouseに移行するとかなり高速化しました。
• コストに関してもRedshift利用時より低く抑えることができています。

Genieの導入によって、営業がセルフ分析を行えるようになり、分析の待ち時間が短縮されました。
また、アナリストが担当する分析においても、GenieにSQLを生成してもらうことで分析業務の効率化ができています。
SQL生成の際にはUnity Catalogに登録されているテーブルのメタデータを自動で参照してくれるので、ChatGPT等を利用するよりもプロンプトを書くのが楽で、精度も高くなりました。

導入時の苦労・悩み

• PoCでのコスト計算はSQL Classicの料金を元に実施していましたが、 移行開始後にDatabricksからAuroraにクエリするためのLakehouse Federationを利用する場合はSQL Proが必要と判明しました。 コストを抑えるため、ClassicのWarehouseを1台、ProのWarehouseを1台ずつ用意し、Auroraへの接続が必要なクエリのみProを利用するような構成にしました。
• 移行期間中は、Redshift SpectrumやAthenaからもDelta Lake形式のデータをクエリできるようにする等、Databricksと相互利用する方法をとりました。 その際、manifestファイルの生成が必要になりますが、パーティション数が多い(数千～数万)テーブルだとmanifestファイルの生成に数十分かかってしまうという問題がありました。

導入に向けた社内への説明

よく使う機能

アーキテクチャ

アーキテクチャの意図・工夫

• Redshiftでデータ基盤を構築していたときから、 ETLのワークフロー管理にはDigdagを利用し、JDBCでRedshiftに接続する構成をとっていました。
  そのため、Databricks移行後も、Digdagを引き続き利用し、JDBCでSQL Warehouseに接続する構成をとっています。
• データ量が多いこともあり、Redshift利用時は、全てのデータをRedshiftのストレージにロードすることはせず、CVSやParquetファイルとしてS3に格納しているものをSpectrumを利用してクエリしていました。
  Databricks移行後は、生データを除いてDelta Lake形式で保存するようにしていっています。
• アドホックな分析に関してもSQL Warehouseを利用し、コンソールからSQLを実行しています。

ツールの良い点

ツールの課題点

ツールを検討されている方へ

• 単にDatabricksへ移行し、Delta LakeとPhotonエンジンを利用することでもパフォーマンスの向上が期待できますが、SparkのパラメータやSQLのチューニングによって、さらなるパフォーマンスの向上が可能なこともDatabricksの特徴の一つだと思います。
  弊社での実際の例として、JSTとUTCの変換の際にINTERVALの利用からfrom_utc_timestamp関数に切り替えたり、delta tableでoptimize + z-orderを利用した最適化を行うことでクエリが数倍高速化したこともあります。 これらのチューニングの相談も含めて、Databricksのソリューションアーキテクトの方のサポートも手厚いです。
• Genieはデータの民主化に向けて、強力なツールになると思います。

今後の展望

さらなるパフォーマンスの向上を目指して、Liquid Clustering等を利用したチューニングに取り組んでいきたいと思っています。
Genieでは参照できるテーブルを限定できるため、ユースケースごとに利用するテーブルを設定し、様々な分析要望に対応可能にしたいと思っています。
また、DatabricksではMLまわりのツールも整っているので、これらを利用して自分たちの保有するデータをさらに活用していきたいです