オープンデータレイク上に広がるデータとAIを活用するためのプラットフォーム
データブリックスの技術スタックは、オープンデータレイク（Microsoft AzureならADLS、AWSならS3、Google CloudならGCSなどのオブジェクトストレージからなるもの）の上で稼働するプロダクトで構成されている。
一般的にデータレイクだけではデータ品質管理が難しくなるので、オープンデータレイク上にロジカルにデータウェアハウス機能を付与した「Delta Lake」、さらに統合セキュリティ、ガバナンス、カタログの機能を持つ「Unity Catalog」を重ねることで、データ環境を固める。
その上で、データサイエンス＆AI「Databricks AI」、ETL＆リアルタイム分析「Delta Live Tables」、オーケストレーション「Workflows」、データウェアハウス「Databricks SQL」も実現している。これら全体を1つのプラットフォームおよびユーザーインタフェースで提供している。
これらのプロダクトがどう機能するか、処理の流れを表したのが下図のリファレンス・アーキテクチャだ。左側にあるデータソースから、いろいろと加工や処理が流れて右側の分析やアウトプットへとつながる。
今回はプラットフォームの上部にあるETL、オーケストレーション、データウェアハウスからはじまり、次にカタログ、そしてデータサイエンスの順で概要を紹介していく。
ETL、オーケストレーション、ウェアハウス
ここはデータエンジニアの仕事に関わる機能となる。データ処理において、データは収集したRAWデータからETL/ETLで整備し、変換し、分析に適したきれいな形にして、分析ツールや機械学習へと送られる。データエンジニアはこうした一連の処理を遂行するためにパイプラインを整備していく。
データインテリジェンスプラットフォームはAIを活用することで、データエンジニアの仕事を効率化する。例えばデータ処理の調整時にAIアシスタントがコードを修正したり、ほしいデータを取得するためのSQLが分からない時にData Roomsがレコメンドしたりなどだ。
実際に作業する様子を桑野章弘氏が披露した。例えばSQLを編集する画面でエラーが出ていたとする。ここでAIアシスタントを使い「エラーの修正」ボタンを押すと、修正の提案がなされる。ユーザーは内容を確認して、修正を適用する。桑野氏は「ユーザーはAIアシスタントと二人三脚で直していくことができます」と言う。
Data Roomは「こんなデータがほしい」と自然言語で指示するだけでAIがデータを整えてくれる。SQLを書く必要がない。使う時は、まず新しいData Roomを作成して、対象となるテーブルなどを指定する。後はユーザーが自然言語で「国別のユーザー数を出して」「年齢層別にユーザーの内訳を出して」「時系列で解約ユーザーの推移を表示して」と問い合わせればいい。ほしいデータがすぐ手に入る。またどのようなSQLを発行しているかも確認することができるのもメリットだ。
ガバナンスとカタログ（Unity Catalog）
次はUnity Catalogについて。北岡早紀氏は「企業でデータ活用が進まない原因は2つ考えられます」と言う。
1つは「サイロ化されたデータアプローチ」。部署ごとにデータを保有してしまい、プラットフォーム全体の可視化ができず、技術的な負債も発生してしまうパターンだ。もう1つは「中央集権的なデータアプローチ」、こちらはデータをデータレイクに集約するも、データ利用者と作成者が断絶していてボトルネックの発生やスケーラビリティの欠如といった制約が生じてしまうパターンになる。
どちらのパターンについても、データ利活用を推進するためには組織的なデータ基盤のスケーリングが不可欠になる。そこでデータブリックスでは、あらゆるデータとAI資産を「Databricks Unity Catalog」で一元管理し、仮想的な"Single Source of Truth"を実現する。ガバナンスを効かせつつ、自由に使えることを目指す。
Unity Catalogは管理画面（カタログエクスプローラー）から権限の設定、データベースのアタッチ、テーブルの管理などが行える。テーブルの依存関係（リネージュ）も追うことができるので、誰が作ったか不明なテーブルでも構造を把握することができるようになっている。
ビジネスインサイトと呼ばれる機能では、テーブルを頻繁に使用しているユーザーや、よく発行されているSQLも統計的に把握することができる。データ品質の観点では、テーブルのドリフトを自動的に監視しているため、ダッシュボードから特定のテーブルに対してどのようなドリフトが起きているかを確認できる。
データソースを登録するだけではなくローカルからデータをアップロードすることも可能だ。データの種類は構造化、非構造化を問わない。1つのカタログであらゆるデータを管理することができる。
さらにUnity Catalogにはデータソースだけではなく、AIモデルも登録が可能だ。組織内にどのようなAIモデルがあるか、そのバージョン管理もできるのも大きな特徴だ。
データサイエンス、AI/ML
データサイエンス領域でも頼りになる機能がデータブリックスプラットフォームには搭載されている。実際にAI/ML開発に携わると実感させられることだが、AI/MLでは運用ライフサイクルでやるべきステップはたくさんある。データの収集、加工、モデル開発、展開、モニタリング、ガバナンスなど。
データブリックスではこれらのすべてのステップを支援する機能が提供されている。データ収集ではDelta Lake、データ加工ではSparkがある。なおSparkは必須ではないものの、志賀優毅氏は「分散処理で高速に処理できるところがSparkの強みです」と話す。
AI開発・評価のうち、開発は外部のオープンAIモデルも同プラットフォームで提供しているFoundation Modelも自由に選べる。評価はMlflow Evaluationで管理することができる。AIモデルの展開ではModel Serving、データ展開ではVector indexやFeature Serving、モニタリングではMonitoringなどがある。
とても多岐にわたる機能がそろっている。全部紹介したいところだが、ここではAutoMLとプレイグラウンド（現在パブリックプレビュー中）をピックアップして紹介する。
まずはAutoML、数行のコードだけで機械学習のベースラインモデルを作成できる。コードを実行するとエクスペリエンスのリンクが発行され、データ探索用ノートブックが作成される。ここから機械学習モデルを生成していく。
# Spark Pandas API によるデータの読み込み import pyspark.pandas as ps train_df = ps.read_csv(train_csv_path) # AutoML による学習 summary = automl.regress( train_df.drop(columns=["Id"]), primary_metric="rmse", target_col="SalePrice", experiment_name=experiment_name, )
志賀氏は「我々のAutoML機能はブラックボックスではなく、モデルを再現するためのノートブックが生成されますので、ベースラインから本格的なモデル開発をすることが可能となっています」と話す。
続いてのプレイグラウンドはLLMを使ったプロダクト開発に便利な機能となる。例えばOSSモデル・GPT3.5・GPT4の3つを同時に比較することができるため、プロンプトチューニングなどで役立てることができそうだ。
最後に北村匡彦氏は「これでもまだデータブリックスプラットフォームが持つ機能の5〜10％しか紹介できていません」という。まだまだ多様な機能がプラットフォームに搭載されている。もし興味があれば、百聞は一見にしかずということで無償トライアルを試してみてはいかがだろう。「無料トライアルのほかにも、XやYouTube、ブログ、イベントなどでも情報発信を積極的にしておりますので、ぜひフォローしてください」と呼びかけた。
