はじめに
Wave チームの何でも屋さん 伊東です. 最近のハイライトは弊チームの AWS のコストを 約 30% 削減したことです. お給料マシマシにしてください 1
技術書典では 第5章 「Go で書かれた gRPC のBFF をRust に移行している話」を担当しました.
本記事では私が2023年6月末に参加した Data and AI Summit 2023 の概要と Wave チームでの Databricks の用途を紹介します.
Data and AI Summit 2023 とは
Data and AI Summit は Databricks という会社が主催するデータサイエンス・データエンジニアリングのグローバルイベントで、サンフランシスコの Moscone Center で開催されました.
本年度は Generation AI がキャッチコピーになっていたり、LLM のセッションがいくつも開かれいくつも満席になっていたり、キーノートでは MosaicML の買収や LLM を活用した AI アシスタント機能がアナウンスされたりと、「世はまさに LLM 時代...」 という印象を受けました.
Databricks について
日本では Databricks の情報が少ないと思うのでまずはざっくり Databricks について説明します.
Databricks はマネージドな Spark と delta というカラムナフォーマットの技術を軸に、データエンジニアリング、データサイエンス、分析やデータウェアハウスなど幅広いユースケースをカバーする統合的なプラットフォームを AWS・GCP・Azure を基盤とした SaaS として提供している会社及びそのサービス名です.
イベントの内容
イベントではキーノート(基調講演)やさまざまなトレーニングやセッションが開催されました.
キーノートでは、データの民主化や規格のオープンさが強調され、次のような機能がアナウンスされました.
- データへアクセスするハードルを下げるための機能(データウェアハウスの AI アシスタント、LLM を利用した英語での Spark 操作など)
- 高度な機能を実現するための施策や機能(MosaicML の買収、ベクトル検索、モデルレジストリやモデルの監視ダッシュボード、IDE とのインテグレーション改善など)
- データウェアハウスのための機能(外部テーブル、モデルやファイルの Unity Catalog への統合、クエリパフォーマンスの改善、Delta Uniform など)
キーノートを通して Databricks はデータ活用のための統合的なプラットフォームを目指している印象を受けました. Databricks を利用するとインフラ、運用や権限管理の負担を抑えつつ、そこで浮いたリソースを事業の面でより価値のあるところに投入できるメリットがあると思います. 一方でキーノートで取り上げられた機能は小さなコンポーネントとして使うよりもウェアハウスとまとまった機能群として利用する想定なので、有望だが漸進的な導入が難しく（とりわけデータウェアハウスは高くつくので）既に大きな基盤を持っている会社・組織では判断が難しそうだとも思いました.
セッションは、データサイエンス、データエンジニアリングやデータガバナンスなど幅広い分野のものが提供されました. これらのセッションは Databricks の利用事例だけではなく、より一般的な技術面の課題とその解決策やアカデミック色の強いものを扱ったものもありました.
セッションのピップアップ
Deep Dive Into Grammarly's Data Platform
Grammarly が Databricks を活用して自社のデータ分析基盤を構築し「データの民主化」を実現した事例が紹介されました.
Grammarly は元々自前の分析基盤を持っていたそうですが、その一部を Databricks にのせることで運用コストの削減や事業上価値のある部分への注力ができるようになったと述べられていました.
セッションでは多様なステークホルダーへのニーズへの対応、ログの受信から分析までのリードタイムの改善、データパイプラインの標準化などの観点で技術的な課題とその課題への解決方法が説明されました. 例えば、テーブルを Snapshot、Dimension や Dimension History などの概念で分け、DSL を定義してデータの変換処理を記述しやすく、合成しやすくする工夫が紹介されました.
概念のモデリングや処理の標準化によって限られたリソースを有効活用し多様なステークホルダーの期待に答えるという点では自社に当てはまることも多いので参考になりました.
Unleashing Large Language Models with Databricks SQL's AI Functions
この LT では SQL から Databricks のエンドポイントからサーブした機械学習モデルを呼び出してウェアハウスに保存された音声データのバイナリを文字起こしし要約するデモが紹介されました.
SQL からモデルを呼び出せるようにすることについて以下のメリットが提示されました.
- 分析とモデル作成・利用の障壁(環境構築、モデルのチューニング、デプロイなどの負担)を下げる
- マネージドなサービスを利用することによるコスト管理、モニタリングやセキュリティの改善
SQL で何でもやろうとすることには少し疑問を感じますが、その普及度やユースケースの幅広さから開発者、データサイエンティスト、アナリストの共通言語として利用できる点で SQL からの利用しやすさを改善する仕組みは本イベントのキーノートで強調されたデータの民主化に貢献すると思います.
また、開発者目線でも、SQL から呼び出せるようになることでアナリストからのフィードバックをモデル開発者やデータサイエンティストが受けやすくなり分業が捗りそうな印象を受けました.
Using NLP to Evaluate 100 Million Global Webpages Daily to Contextually Target Consumers
このセッションでは The Trade Desk が毎日1億のウェブページを処理できるように機械学習モデルをスケールさせた事例が紹介されました.
The Trade Desk は広告配信サービス(DSP)を手掛ける企業で、ウェブページのコンテンツにマッチした広告を表示することで広告のコンバージョンの改善や消費者のエンゲージメント向上をはかっています. 処理の対象のウェブページは1億にものぼり、コンテンツの言語も35以上に及び、Spark NLP のようなソリューションではコスト面でもパフォーマンス面でも不十分である、という難しさがあります. The Trade Desk は Spark の Pandas UDF や周辺の処理をチューニングして高いパフォーマンスとコストの問題を解決したそうです.
セッション中で紹介された、ウェブサイトを扱う上で一度英語に変換した上で処理を行うというアイディアは、多言語対応の面だけでなく日本語特有の難しさに悩まされることなくさまざまなモデルを利用することができるという面で自社での活用の参考になりました.
Wave チームでの Databricks の用途
Wave チームでは Databricks をアドホックな分析や将来の推薦・検索機能に利用する特徴量を生成するために使っています. PoC 自体は数年前にしていますが積極的に利用しているのはここ最近です.
GCP の BigQuery や AWS の Redshift のようなデータウェアハウスの機能に加えて Databricks には以下のメリットがあると考えています.
- オールインワンなサービスでインフラの管理の手間がかなり少ない.
- データリネージやアクセス制御機能(テーブルだけでなく計算用のクラスタ、分析用ノートブックやダッシュボードの権限管理も含む)が揃っている.
- データの取り込み・加工処理・保存があちこちに散らばらない.
1 は小規模 ~ 中規模なチームでETLや分析タスクをするケースや、各チームが非中央集権的な形でデータを管理・共有するデータメッシュを作るケースに向いていると思います.
また、2 は(我々のユースケースとは異なりますが)金融、医療や保険などアクセス制御を適切にしなければならないドメインのデータ管理に向いていそうです.
ユースケース:インタラクティブに実行可能なチュートリアル・ドキュメント
Wave チームは長期インターン生の主な受け入れ先になっています. そのため人の出入りがしばしば発生するのでオンボーディングの改善のためにドキュメントを整備しています. その一環として Databricks 上に実行可能なノートブック形式でいくつかのチュートリアル・ドキュメントを用意しています.
以下のスクリーンショットは Spark の Structured Streaming をデバッグするためのサンプルです.
ユースケース:バッチ処理・ストリーミング処理
Wave チームの Databricks ではログ収集基盤を開発するチームの Kinesis から分析用のデータを(ニア)リアルタイムで取得して分析用のテーブルに書き込んでいます.
以下はストリームの取り込み処理を一部抜き出したものですが、バッチもストリーミングもほとんど同じメンタルモデル・コードで書くことができます.2
Spark の DataFrame の API を使うことで SQL では複雑になりがちな処理も IDE の補完を受けながら比較的簡潔に書くことができると感じています. また, Scala や Python で定義したモデルや関数をサービス開発にも分析タスクにも使うことで作業の重複や仕様のずれを減らすことができます.
コードが書きやすいことに加えて、ストリーミング書き込みしたテーブルをそのままストリーミング読み込みしたりすることもできるのが嬉しいポイントです.
import spark.implicits._
import org.apache.spark.sql.types._
import org.apache.spark.sql.functions._
import org.apache.spark.sql.catalyst.ScalaReflection
import org.apache.spark.sql.streaming.Trigger
import com.nikkei.schema.atlas.Payload
// streaming-write from stream into table
val schema = ScalaReflection
.schemaFor[Payload]
.dataType
.asInstanceOf[StructType]
val df = spark.readStream
.format("kinesis")
.option("streamName", kinesisStreamName)
.option("region", kinesisRegion)
.option("initialPosition", "TRIM_HORIZON")
.option("maxFetchDuration", maxFetchDuration)
.option("fetchBufferSize", fetchBufferSize)
df
.where(...)
.select(...)
.repartition(...)
.writeStream
.format("delta")
.trigger(Trigger.ProcessingTime(...))
.outputMode("append")
.option("checkpointLocation", checkpointLocation)
...
.partitionBy(...)
.toTable(...)
// read from table(as batch)
spark.read
.table(...)
.where(...)
.select(...)
.limit(1000)
.show()
ユースケース:データリネージや権限管理などのデータマネジメント・ガバナンス
「データ分析・データサイエンスあるある」な話かもしれませんが、データがどこからきてどのように加工されているのかわからない問題があります. Wave チームのデータパイプラインは先任者が PoC 用途で作ったものをそのまま利用していたのでデータの追跡が困難になっている問題がありました. そこで、Databricks の機能の恩恵を受けられるようにパイプラインを整理してデータの関係性が一目でわかるようにしています.
テーブル間の関係性だけでなく、テーブルに書き込んでいるバッチ処理、テーブルを読み込んでいるノートブックやダッシュボードなども確認できます.
以下の画像は Databricks の Lineage のドキュメント にある Lineage の画像です. テーブル間の関係を有効グラフとして可視化したり、関連するバッチジョブやノートブックを紐付けたりする機能を Wave チームでも活用して、特徴量生成のパイプラインのメンテナンス性を改善しようとしています.
他にも、権限に応じたテーブルの行・列単位のマスキング、ノートブックやダッシュボードのアクセス制御などの機能を利用することで管理・開発・分析の分業が捗りそうだと考えています.
各種リソースの権限をきめ細かく管理できるので、GUI でポチポチしてセットアップできるツールにありがちな、ユーザーが無秩序にリソースを作って後から収拾がつかなくなる事態を未然に防ぐことができると考えています.
まとめ・おわりに
この記事では Data and AI Summit 2023 や Wave チームでの Databricks の用途を紹介しました.
本イベントでは LLM や生成 AI に限らず、データエンジニアリングやデータガバナンスなど幅広いトピックについて知見を得ることができました.
このイベントにかぎらず日々 LLM や生成 AI に関するニュースが話題になっていますが、セッションでの事例を聞いていると、それらをうまく活用するには自社にしかないデータがありなおかつそれが整理されていていることが重要だと思いました.
活字メディアは LLM や生成 AI の進歩に特に大きな影響を受ける分野ですが、質の高いテキストデータを大量に保持している強みをいかして新しいテクノロジーと共存して付加価値を出していきたいです.