サマリー
- Databricks の最も強力なプロダクション上の主張は、ノートブックがデータを素早く探索できることではない。より困難な主張は、明日も同じアクセスポリシー、リネージ、テーブルセマンティクス、コスト帰属、モデルハンドオフ、リカバリーの証跡を伴って、管理されたジョブが再実行できることである。
- プラットフォームには、そのジョブを実現する信頼できる要素がある：Delta Lake テーブル、Spark と Photon のコンピュート、Unity Catalog のガバナンス、Lakeflow Jobs、サーバーレスワークフロー、システムテーブル、MLflow、モデルサービング、ソフトウェアデリバリーのツール群。これらの要素は、顧客が規律あるテーブル設計、権限付与、テスト、ジョブオーナーシップ、例外パスを設計したときに初めて価値を持つ。
- 公開されているエビデンスは、Databricks を本格的な運用プラットフォームとして支持しているが、受理されたジョブの発生率、リネージの完全性、権限エラー、再試行の安全性、モデルハンドオフの正確さ、有用な出力あたりのコストに関する独立した数値を提供しているわけではない。選ばれた顧客事例は、良好な条件がどのようなものかを示すことはできるが、すべての顧客がどの程度の頻度でそれを達成しているかは示さない。
- 購買上の問いは、Databricks が繰り返し行われる管理された作業の総コストを下げるかどうかである。その分子には、Databricks の使用料、クラウドコンピュートとストレージ、移行、プラットフォーム管理、テスト、監視、データスチュワードシップ、ロックインが含まれる。エンジニアをポリシー、リネージ、コストの手動調整に戻すような高速実行は、完全に節約されたジョブとは言えない。
ノートブックは価値の単位ではない
おなじみの Databricks の光景はノートブックから始まる。データエンジニアがテーブルを読み込み、変換を書き、結果を確認し、分析を同僚と共有する。データサイエンティストがモデルを訓練する。アナリストがレイクハウスデータに対して SQL クエリを試みる。この体験は流動的であり得るし、Databricks は長年にわたり、その探索を作業そのものに近い感覚にするために努力してきた。しかし、ノートブックは経済的な問いが終わる場所ではない。通常は、問いが始まる場所なのである。
有用なエンタープライズワークロードは退屈にならなければならない。午前2時に、最初にそれを書いた人物がいなくても実行されなければならない。どのアイデンティティがどの入力を読み取ることを許可されているかを把握していなければならない。テーブルの履歴を保持し、何が変更されたかを記録し、破損する書き込みを避け、通常の障害から回復し、障害が発生した場合に運用者にその理由を示さなければならない。結果を下流のダッシュボード、フィーチャーテーブル、機械学習モデル、規制レポート、顧客アプリケーション、またはその出力に基づいて行動する別のチームに渡さなければならない。それを一度だけではなく、繰り返し行わなければならない。
それが Databricks を評価するための適切な単位である。すなわち、動き続ける管理されたジョブである。ノートブックのデモは技術的なリーチを示せる。繰り返されるジョブは、プラットフォームが探索を運用上の信頼に変換できるかどうかを示す。ジョブには名前、所有者、入力、出力、権限、コンピュート、スケジュールまたはトリガー、実行履歴、再試行、コスト記録、そして下流の消費者がいる。その成功は、単にコードが実行されたことではない。正しいポリシー境界のもとで、次のシステムやチームが出力を受け入れることである。
この区別が重要なのは、Databricks が統合を売りにしているからである。同社は、データエンジニアリング、アナリティクス、機械学習、生成 AI、ガバナンス、そしてますますアプリケーション開発までも同じプラットフォームで保持したいと考えている。その魅力は明らかである。多くの組織は、10年にわたり、オブジェクトストア、ウェアハウス、ノートブック、機械学習プラットフォーム、オーケストレーションツール、カタログ、ダッシュボード、モデルエンドポイントの間でデータを往復させてきた。各ハンドオフがずれを生む。同じ顧客フィールドが、ウェアハウス、Spark ジョブ、モデルのフィーチャーセットで異なる名前を持つかもしれない。同じテーブルがアナリストには見えても、サービスプリンシパルには見えないかもしれない。モデルが、データガバナンスチームが説明できない場所に登録されているかもしれない。データパイプラインが、開発ノートブックでは安価だが、スケジュールされたジョブでは高価になるかもしれない。
Databricks は、より一貫性のある基盤を約束する。Delta Lakeは、クラウドオブジェクトストレージ上でテーブルセマンティクスを提供する。Spark とPhotonが実行を提供する。Unity Catalogは、データと AI アセットのガバナンス層を提供する。Lakeflow Jobsは、繰り返し作業をオーケストレーションする。システムテーブルは、運用および課金記録を公開する。MLflow とモデルサービングは、データ作業をモデル展開に接続する。サーバーレスコンピュートは、より多くのインフラストラクチャの決定を Databricks の管理下に移す。これはもっともらしい製品のテーゼである。
プロダクションの問いはより冷徹である。統合は、ジョブを正直に保つために必要な作業量を減らすのか？それとも、単により大きな一連の責任を1つのベンダー境界内に集中させるだけなのか？その答えは、Databricks の最良の機能よりも、データソースから受理された出力に至る繰り返しのパスに依存する。
Databricks が動かそうとしているもの
Databricks のようなプラットフォームが採用される前は、作業は通常、いくつかのグループに分かれている。データエンジニアは、Spark、Airflow、dbt、ウェアハウスのプロシージャ、またはクラウドネイティブサービス上でパイプラインを構築する。プラットフォームエンジニアは、クラスター、権限、ネットワークパス、ライブラリ、デプロイメントツールを管理する。アナリストは SQL ウェアハウスと BI ツールで作業する。データサイエンティストは、ノートブック、実験、モデルアーティファクトを別々の環境に保持する。ガバナンスチームは、カタログ、アクセスポリシー、リネージツール、監査記録を管理する。ファイナンスチームは、請求書が届いた後にクラウド支出をビジネスユニットに帰属させようとする。
その分離は高くつく。単にツールにライセンスコストがかかるから高くつくのではない。各境界で作業を変換しなければならないから高くつくのである。データサイエンティストが有用なノートブックを作成しても、別のチームがそれをスケジュールされたパイプラインに変換しなければならない。パイプラインがフィーチャーテーブルを書き込んでも、モデルサービングパスが同じガバナンスコンテキストを持たないかもしれない。ウェアハウスが BI にパフォーマンスを提供しても、生のレイクが信頼できる履歴を含んでいるかもしれない。カタログがテーブルの存在を示しても、どのジョブが昨日古いカラムを生成したかは示さないかもしれない。プラットフォームチームがコンピュートの請求額を知っていても、どの製品決定が再試行の嵐を引き起こしたかはわからないかもしれない。
Databricks は、その連鎖の中のいくつかのステップを置き換えようとしている。オブジェクトストアをステージング領域ではなく基盤にすることができる。Spark ワークロード、SQL ワークロード、モデルワークフローが、同じ管理されたテーブル上で動作できるようにする。ノートブックとパイプラインが存在する同じワークスペースでワークフローオーケストレーションを提供できる。テーブルや関数を管理するのと同じガバナンス層にモデルの登録を接続できる。オペレーターがどのジョブが実行され、どのジョブが失敗し、どのジョブが再試行され、どのコンピュートが使用され、どのようにコストが帰属されたかを問い合わせることができるジョブシステムテーブルを公開できる。
実際に置き換えられるステップは、データ運用の仕事のすべてではない。それらは機械的で統合の重いステップである。すなわち、ルーチンのコンピュートのプロビジョニング、タスクのスケジュール、パラメータの受け渡し、失敗したタスクの再実行、ジョブ履歴の追跡、テーブルバージョンの保存、権限の強制、リネージの公開、モデルの登録、エンドポイントのサービング、使用量とワークロードメタデータの結合である。これらは実際に労力の源であり、それらを減らすことは重要であり得る。
残る人間の作業はより頑固である。誰かが依然として、テーブルが何を意味するのか、どのデータが信頼できるのか、どのフィールドが機密であるのか、どの出力が十分に良いのか、どの実行を安全に再試行できるのか、どのコストが許容できるのか、どのモデルを昇格させるべきか、そしてどの下流の消費者が結果に依存する権利を持つのかを決定しなければならない。プラットフォームは、権限が設計された後にそれを強制できる。それ自体でデータのビジネス境界を決定することはできない。ワークフローシステムは、失敗したタスクを再実行できる。タスクがべき等であるかどうかは、顧客がそのように設計した場合を除き、知ることができない。リネージグラフは、アセットが登録されキャプチャされた場合に下流の依存関係を示すことができる。重要な出力をパス参照やサイドファイルを通じて書き込む文化を完全に救うことはできない。
これが、管理されたジョブが適切なテストである理由である。それによって、Databricks はその部品が交わる場所で評価されることを強いられる。ジョブは単なる Spark プログラムではない。それはポリシーイベント、コストイベント、リネージイベント、リカバリーイベント、そして時にはモデルハンドオフである。それらの部分が一体となっていなければ、統合プラットフォームは隠れた運用コストを伴うもう一つの魅力的なワークベンチになる。
Unity Catalog はコントロールプレーンであり、魔法の層ではない
Unity Catalogは、Databricks の現在のプラットフォームストーリーの中心である。それは Databricks におけるデータと AI アセットのガバナンス層である。アセットをセキュアブルオブジェクトとしてモデル化し、権限を適用し、リネージを追跡し、アクティビティをログに記録し、共有名前空間を通じてテーブル、ビュー、ボリューム、関数、モデル、サービスを管理する。プロダクションジョブの分析において、Unity Catalog は装飾ではない。それは単に実行されるジョブと、別のチームから信頼されることができるジョブとの違いである。
理由は単純である。繰り返し実行されるデータジョブは、人々が知ることや行うことを許される内容を変える。それは顧客記録、財務記録、ネットワークテレメトリ、製品使用状況、運用ログ、またはモデル入力を読み取る。アナリストがクエリし、ダッシュボードが表示し、アプリケーションが消費し、モデルが学習するテーブルを書き込む。そのジョブが黙ってポリシーを迂回するなら、プラットフォームはエンタープライズの問題を解決していない。問題をより速く動かしているに過ぎない。
Unity Catalog は、Databricks に信頼できる回答を与える。権限は、カタログ、スキーマ、オブジェクトに適用できる。モデルと関数は実行権限を持つことができる。リネージは、テーブル、ジョブ、ノートブック、ダッシュボード、モデルバージョンを接続できる。外部アセットは、より広範なリネージのために表現できる。アクティビティは監査可能である。これは、データエンジニアリングと AI 作業を1つのガバナンス表面の下に結合しようとする企業にとって正しいアーキテクチャである。
しかし、コントロールプレーンは条件的である。最も強力な公開ドキュメントは、要件について慎重である。リネージキャプチャのために、テーブルは Unity Catalog に登録されなければならない。ユーザーはリネージを表示するために適切な権限が必要である。ソースまたはターゲットがテーブル名ではなく直接ストレージロケーションを通じて参照される場合、一部のカラムリネージはキャプチャできない。ストリーミングとパイプラインのリネージにはランタイム要件がある。ネットワーキングが重要になることもある。外部ソースは外部メタデータ関係を必要とする。つまり、顧客は「Databricks 上にいる」にもかかわらず、チームが管理されていないストレージ参照、レガシーワークスペース、緩い外部ロケーション、または一貫性のないテーブル参照を使い続ける場合、不完全なガバナンスを持つ可能性がある。
これが最初の隠れたコストである。Unity Catalog は、混乱したデータ資産を管理されたものに変えるスイッチではない。それは採用されなければならない構造である。誰かがカタログをビジネスドメインにマッピングし、スキーマの慣習を選び、ワークスペースをバインドし、所有権を割り当て、レガシーテーブルを移行し、外部ロケーションを定義し、古い権限を整理し、誰がメタデータを閲覧できるかを決定し、サービスプリンシパルを管理しなければならない。移行が部分的であれば、ジョブは Databricks 内で実行されても、制御の証跡は部分的なままであるかもしれない。
これは、出力が機密性を帯びるときに最も重要になる。公開マーケティングテーブルを更新するデータジョブは、一つのリスクプロファイルを持つ。信用リスク、通信ネットワークの決定、ヘルスアナリティクス、ID 詐欺モデル、または規制報告に供給するジョブは、別のリスクプロファイルを持つ。そのような文脈では、成功した実行だけでは不十分である。オペレーターは、下流のダッシュボードが変更されたカラムに依存しているかどうか、モデルバージョンがもはや見えるべきでないデータを使用したかどうか、関数が誤ったグループによって実行される可能性があるかどうか、外部ツールがリネージ関係を持っているかどうか、そして監査記録が後の調査をサポートするかどうかを知る必要がある。
Databricks は、別個のカタログ、別個のワークフローシステム、別個のモデルレジストリ、別個のコンピュートエステートをつなぎ合わせるよりも、それを容易にすることができる。それがこの製品の本当の魅力である。それでもなお、顧客はガバナンス設計のコストを負担する。プラットフォームはその作業を排除しない。それはそれをより明示的にし、良好な展開においてはより強制可能にする。
Lakeflow Jobs はコードを義務に変える
Lakeflow Jobsは、ノートブックが安全な部屋を離れる場所である。ジョブは1つまたは多数のタスクを調整できる。ノートブック、Python スクリプト、dbt タスク、機械学習ワークフロー、その他のワークロードタイプを実行できる。依存関係、トリガー、条件付きロジック、ループを使用できる。UI、CLI、REST API、またはDeclarative Automation Bundlesを通じて設定できる。失敗またはキャンセルされた作業を修復して再実行できる。サーバーレスコンピュート、ジョブコンピュート、またはタスクに応じたその他のコンピュート選択肢を使用できる。
このオーケストレーション層が必要なのは、データ作業が繰り返しを通じて価値を生むからである。収益テーブルは、毎朝更新されるときに有用である。フィーチャーテーブルは、それを必要とするモデルと同期しているときに有用である。コンプライアンス抽出は、正しいレコードが正しいカットオフで含まれているときに有用である。製造トレーサビリティテーブルは、オペレーターが生産が停止する前に部品の経路を見つけられるときに有用である。モデルは、その入力データ、バージョン、サービングパスが、誰かが結果を信頼するのに十分なほど一貫しているときに有用である。
ジョブ記録は、オペレーターに検査すべき共有オブジェクトを与える。どのタスクが失敗したか？上流の依存関係が失敗したためにタスクがスキップされたか？再試行が発生したか？ユーザーによって実行がキャンセルされたか？実行がタイムアウトしたか？一部のタスクは成功したがリーフタスクが失敗したか？どのコンピュート ID が使用されたか？結果状態は何か？オペレーターはアカウント全体で最近の実行を監視できるか？ファイナンスチームは使用量をジョブメタデータに結合できるか？
これらは魅力的な質問ではないが、プラットフォームが労力を削減するかどうかを決定する質問である。答えが一箇所で見えるなら、より少ないエンジニアがログ、ノートブック、クラウド請求書、Slack メッセージ、ウェアハウス履歴からイベントを再構築する必要がある。答えが断片化しているなら、開発中のプラットフォームの利便性は、障害時の調査負担に変わる。
Lakeflow Jobs はまた、鋭いエッジを露呈する。再試行はリカバリーと等しくない。Databricks は、多くの障害が一時的であるため、再試行をサポートする。クラスターが失敗するかもしれないし、依存関係が再起動するかもしれないし、ストリーミングスキーマの変更が新しい環境を必要とするかもしれないし、サービスが一時的に作業を拒否するかもしれない。再試行は通常のインシデントを通常の実行に変えることができる。しかし、すべてのワークロードが再実行しても安全であるわけではない。よく設計されたマージを伴う Delta テーブルにべき等的に書き込むタスクは、ファイルを外部システムに投稿するタスク、カウンターを増加させるタスク、メッセージを送信するタスク、永続的なチェックポイントなしに状態を変更するタスクとは異なる。
ここで人間の設計が再び戻ってくる。顧客は、どのジョブを再試行できるか、何回の再試行が安全か、タスク境界をどこに置くべきか、部分的な失敗の後に下流タスクを実行すべきか、遅れて到着するデータをどのように扱うか、完了をどのように定義するか、出力を二重にカウントせずに実行を修復する方法を決定しなければならない。プラットフォームは修復を提供できる。事後にべき等でないプロセスを安全にすることはできない。
同じことがステータスにも当てはまる。Databricks は、ドキュメント化されたルールに基づいて、ジョブを成功、失敗、スキップ、タイムアウト、キャンセル、ブロック、または失敗を含む成功としてマークできる。それは運用上の真実である。それは必ずしもビジネス上の真実ではない。ジョブは、ソースファイルが誤ったセマンティクスで到着したために下流ユーザーが拒否するテーブルを生成しながらも成功する可能性がある。ジョブは、データを破損する前に安全に失敗する可能性があり、それは可能な限り最良の結果かもしれない。条件が満たされなかったためにタスクがスキップされる可能性があり、それは正しいか、見逃されたシグナルのいずれかである。受理された出力が有用な分母であり続ける。
Delta Lake はテーブルの信頼性を提供するが、データの判断は提供しない
Delta Lakeは、Databricks がレイクハウスをブランド以上のものとして売り込むことができる理由の一つである。オブジェクトストレージ内の単なるファイルは安価で柔軟だが、自然には信頼できるテーブルのように振る舞わない。Delta Lake は、トランザクションログ、ACID トランザクション、スケーラブルなメタデータ処理、データレイク上でのバッチとストリーミングのサポートを追加する。Databricks では、特に指定がない限り、Delta がデフォルトのテーブルフォーマットである。
管理されたジョブにとって、それは重要である。スケジュールされたパイプラインは、読み手を半分更新された状態に残すことなく出力を書き込む必要がある。ストリーミングワークロードはチェックポイントとテーブルセマンティクスを必要とする。ロールバックや監査の質問はテーブル履歴を必要とするかもしれない。スキーマ変更は、ダッシュボードが壊れた後に発見するのではなく、管理されなければならない。Delta のトランザクション層は、実際の運用上の問題に対する技術的な回答である。単独のオブジェクトストアは、多くのエンタープライズワークフローに十分なテーブルの規律を提供しない。
しかし、テーブルの信頼性はデータの信頼性と同じではない。Delta はコミット境界を保護できる。ソース値が正しいかどうかを決定することはできない。スキーマの強制と履歴を支援できる。フィールドがビジネスによって再定義されたかどうか、サプライヤーがコードリストを変更したかどうか、メトリックが誤解を招くようになったかどうか、プロセス変更後にモデルがフィーチャーを使い続けるべきかどうかを知ることはできない。テーブルは有効であり得ても、答えは依然として間違っている可能性がある。
この区別は、プラットフォームの購入においてしばしば見失われる。レイクハウスはストレージとアナリティクスを統合できるが、データスチュワードシップの作業を取り除くわけではない。誰かがブロンズ、シルバー、ゴールドのレイヤー、または顧客が使用する同等のものを定義しなければならない。誰かが保持、プライバシー、マスキング、所有権、鮮度、検証、下流の契約を決定しなければならない。誰かが、いつテーブルが BI 用に認定されるか、いつそれが単に実験的であるか、いつジョブの結果を隔離すべきかを決定しなければならない。
Databricks は、そのガバナンスのためのビルディングブロックを提供する。Unity Catalog は所有権と権限を管理できる。データ品質モニタリングは、テーブルをプロファイリングし、ベースラインに対するドリフトを比較し、時系列、推論、スナップショットデータにわたってメトリックを作成できる。リネージは下流の変更の根本原因を特定するのに役立つ。システムテーブルは、オペレーターが実行とコストを確認するのに役立つ。しかし、プラットフォームは依然として、顧客の品質の定義に依存する。ドリフトを示すダッシュボードは、誰かがどの程度のドリフトが重要で、誰が対応しなければならないかを知っている場合にのみ価値がある。
ここでも、管理されたジョブがテストである。テーブルへの書き込みは、Delta がコミットしたからといって受理されるわけではない。コミットされたテーブルが、その消費者が期待するポリシー、品質、ビジネス契約を満たしているために受理されるのである。Databricks はメカニクスを支援する。顧客は意味を所有する。
受理されたジョブあたりのコストは、単価よりも難しい
Databricks の価格設定は、使用量を中心に構築されている。公開ページは、従量課金、秒単位の粒度、クラウドプロバイダー別の製品/SKU 価格リスト、およびコミットメント契約を強調している。サーバーレスワークフローは、課金可能な使用量システムテーブルを通じて監視できる。ジョブのコストとパフォーマンスは、ジョブコンピュートまたはサーバーレスコンピュートで実行されるジョブについて、システムテーブル間で結合できる。価格設定システムテーブルは、過去の SKU 価格設定を公開できる。コンピュートポリシーは、リソース作成、時間あたりの最大 DBU、タグ、ライブラリを制限できる。
これにより、ファイナンスチームとプラットフォームチームは、生のクラウド請求書だけの場合よりも、コストを理解するより良い機会を得る。しかし、それはまた、受理された出力あたりのコストがなぜ難しいのかを示している。Databricks のジョブは、プラットフォームユニット、クラウドインフラストラクチャ、ストレージ、データ転送、サーバーレスまたはクラシックコンピュート、そして人間の注意を消費する。ジョブが失敗し3回再試行されれば、コストは可視化されるかもしれない。リネージが不完全なために2人のエンジニアが調査しなければならない場合、そのコストは DBU の数字には含まれない。誤ったモデルバージョンがロードされたためにモデルハンドオフが拒否された場合、コンピュートコストは損失の一部に過ぎない。
誠実なバイヤーは、実行あたりのコストではなく、受理された管理ジョブあたりのコストを計算すべきである。分母は「実行されたジョブ」ではない。「出力が、要求されたポリシーの下で下流の消費者に受理されたジョブ」である。分子には、Databricks の料金、クラウド料金、プラットフォームエンジニアリング、データエンジニアリング、ガバナンス管理、移行労働、監視、インシデント対応、テスト、ビジネスレビュー、再試行、失敗した実行、ロックインの機会コストが含まれる。
サーバーレスコンピュートはその計算を変えるが、消し去りはしない。Databricks はインフラストラクチャを管理し、インスタンスの選択を最適化し、オートスケーリングと Photon を有効にし、顧客がクラスターを設定する必要性を減らすことができる。多くのチームにとって、それは意味のある労働節約である。また、コンピュートをより消費しやすくする。ドキュメントは要件と制限を指摘している：Unity Catalog が有効でなければならない、ワークロードは標準アクセスモードをサポートしなければならない、一部のタスクタイプや機能はプレビューステータスである、大容量メモリや多数のタスクを持つジョブは起動時間が増加する可能性がある。サーバーレスは、Databricks のランタイム選択とサポートされるアクセスモードへの依存を増やしながら、インフラストラクチャの労苦を減らすことができる。
Photonも同様の点を提起する。サポートされている操作に対して SQL、DataFrame、ETL、ステートレスストリーミングワークロードを加速するネイティブベクトル化エンジンは、スループットを向上させることができる。サポートされていない操作に対しては Spark ランタイムにフォールバックできる。これは強力なパフォーマンスストーリーであるが、パフォーマンスはワークロード固有である。コストの問題は、より高速またはより管理された実行が、より少ない総労働で受理された出力を生成するかどうかである。30パーセント高速なジョブが権限の欠陥を隠す場合、それはより安価ではない。ガバナンスを保持し、再作業を避けるより遅いジョブのほうが、経済的に優れている可能性がある。
ここでシステムテーブルがマーケティングの主張よりも重要になる。成熟した Databricks の顧客は、どのジョブが最も消費したか、どのジョブが再試行されたか、どのジョブが失敗したか、どのワークスペースまたはリージョンが関与しているか、どのユーザーまたはサービスプリンシパルが使用量を発生させたか、どのタグが支出を帰属させるか、どの製品と機能が請求を駆動したかを尋ねることができるべきである。これらの質問に答えられない場合、プラットフォームは依然として有用かもしれないが、バイヤーは経済性を擁護できない。
危険は、探索と繰り返し作業が混ざり合う組織で特に高い。汎用コンピュートと共有ノートブックは初期の作業を容易にするが、コストの帰属を曖昧にし得る。専用のジョブコンピュートまたはサーバーレスコンピュートに昇格したジョブは、帰属させやすい。半分ノートブック、半分ジョブ、半分手動のままのワークロードは、隠れた課税を背負う。Databricks はその課税を減らすツールを提供する。ツールが使用されるかどうかは、顧客の運用規律が決定する。
モデルハンドオフはガバナンスの問題である
Databricks はもはやデータエンジニアリングプラットフォームだけではない。そのプラットフォームストーリーには、MLflow、モデルレジストリ、モデルサービング、ベクトル検索、AI アセットのガバナンス、内部および外部モデルプロバイダーへの管理されたアクセスが含まれる。これにより、管理されたジョブのテストが広がる。ジョブの出力は、ダッシュボード用のテーブルではないかもしれない。それはモデルバージョン、フィーチャーテーブル、埋め込みインデックス、リクエストログ、推論テーブル、またはビジネスアプリケーションが呼び出すエンドポイントかもしれない。
ここで製品の信頼性とモデルの能力が混同される可能性がある。モデルはベンチマークでは優れているかもしれないが、プラットフォームの問いは、正しいバージョンが登録され、管理され、提供され、監視され、正しいデータに正しいアクセスポリシーの下で接続されているかどうかである。予測は技術的に印象的でありながら、どの訓練データ、フィーチャーバージョン、モデルファイル、エンドポイント、クレデンシャルパス、下流の消費者が関与したかを誰も証明できない場合、運用上は使用不可能である。
Databricks はここで信頼できる部品を持っている。Databricks 上の MLflowは、モデルのログ記録と登録をサポートする。Model Serving は、Unity Catalog に登録されたモデルを REST エンドポイントとしてホストできる。外部モデルは、サービングエンドポイントを通じて、プロバイダーサポートと一元化されたクレデンシャル管理とともに構成できる。Unity Catalog はモデルと実行権限を管理できる。データ品質モニタリングは、リクエストログに基づいて推論プロファイルをカバーできる。リリースノートは、Databricks がガバナンスと AI サービス機能を拡張していることを示している。
残る作業は重い。チームは、モデルの昇格基準、検証データ、ロールバックパス、エンドポイント容量、監視閾値、リクエストログ記録、人間によるレビューの境界、プロバイダーのフォールバック、クレデンシャルストレージ、プライバシー処理、下流のビジネス受け入れを決定しなければならない。モデルエンドポイントが動作を変更した場合、ビジネス上の結果は、モデルサービングの UI 内に収まることは稀である。詐欺レビュー、在庫計画、カスタマーサポート、信用決定、メンテナンススケジュール、ネットワーク運用に影響を与える可能性がある。
これが、モデルハンドオフがデータジョブと同じ記事に属する理由である。現代の Databricks のエステートでは、モデルは多くの場合テーブルの下流にあり、決定の上流にある。リネージがモデルの前で止まれば、ガバナンスは不完全である。権限がテーブルを保護しても関数やモデルエンドポイントを保護しなければ、境界は多孔的である。コスト監視がパイプラインをカバーしてもモデルサービングをカバーしなければ、経済性は不完全である。モデルがあまりにも広範なグループによってロードできる場合、最小権限はデータがアクションになる瞬間に失敗している。
Databricks は、そのハンドオフを管理するために必要な別個のシステムの数を減らすことができる。これは、組み立てられたオープンソーススタックや古い分割プラットフォームに対する重大な利点である。しかしそれはまた、顧客が Databricks をより広範な運用基盤として信頼していることを意味する。リスクは単に調達上のベンダーロックインではない。それは運用上の依存である。データレイアウト、ジョブ定義、ガバナンスオブジェクト、システムテーブル、モデルレジストリ、エンドポイント、コスト管理が同じプラットフォームロジックの一部となる。
一部の顧客にとって、その依存は公正なトレードである。代替案は、異なるアイデンティティ、ログ、セマンティクスを持つ別個のツールの脆弱な連鎖を維持することである。他の顧客にとって、集中のコストは高すぎる可能性があり、特に組織が強力な既存のウェアハウス、オーケストレーションシステム、カタログ、またはモデルプラットフォームを持っている場合である。正しいテストは、Databricks がモデルを実行できるかどうかではない。ガバナンスとリカバリーがカウントされた後、データからモデル、出力へのパスが代替案よりも信頼性が高く、コストが低いかどうかである。
障害モードは奇抜ではなく日常的である
Databricks のリスクは、劇的な停止や高度な攻撃に限定されない。日常的な障害だけで十分である。作成者には動作するノートブックが、ライブラリ、パラメータ、またはクレデンシャルが暗黙的であったためにジョブとして失敗する。パスによって参照されるテーブルは、ガバナンスチームが期待したリネージキャプチャを回避する。サービスプリンシパルが、開発ワークスペースから権限がコピーされたために過剰なアクセスを持つ。サーバーレスジョブが、サポートされていない設定に依存するワークロードを実行できない。再試行が外部への書き込みを二重にする。スキーマ進化が、ダッシュボード所有者の準備ができる前に下流のフィールドを変更する。ストリーミングジョブが遅れる。モデルエンドポイントが、正しいモデルファイルをサービスしながら、入力データに関する誤った仮定で提供する。アドホックな実行から頻繁なスケジュールされた更新にチームが移行した後、コストの急増が現れる。
これらの障害のいずれも、Databricks が弱いことを意味するものではない。それらは、データプラットフォームがオペレーティングシステムになる際の通常の障害である。問いは、Databricks がそれらを予防、検出、修復しやすくするかどうかである。
いくつかの公開証拠は正しい方向を指している。ジョブには履歴、結果状態、タスクレベルの記録、修復パスがある。システムテーブルは運用データを公開できる。Unity Catalog はリネージとアクセス制御を追跡できる。Delta Lake はテーブルトランザクションを保護できる。コンピュートポリシーはリソースパターンを制限できる。サーバーレスは多くのチームからクラスター設定を取り除くことができる。BundlesとCI/CD ガイダンスは、データ作業をバージョン管理され、レビューされたデプロイメントに押し進めることができる。Status APIは、ベンダーレベルのサービス健全性を公開する。顧客事例は、企業がトレーサビリティとデータ標準化に投資したときに、管理された移行がどのように見えるかを示している。
同じ証拠が限界も明らかにする。リネージには要件がある。システムテーブルには権限、保持期間、リージョンに関する注意事項がある。コスト帰属はコンピュートタイプによって異なる。サーバーレスにはアクセスモードとタスクタイプの条件がある。リリースノートは、プラットフォームが急速に変化していることを示しており、顧客は追いつく必要がある。ステータスページはベンダーが報告するものであり、テナント固有の健全性を証明できない。顧客事例は選ばれたものであり、基本レートを示さない。ドキュメントは、顧客の条件下でどれくらいの頻度で成功するかを示さずに、機能を説明できる。
それが、Databricks をプラットフォーム作業を避ける方法として購入すべきでない理由である。プラットフォーム作業をより統一された場所で行うことを厭わないときにのみ購入すべきである。ジョブには依然として所有者が必要である。データには依然として契約が必要である。権限には依然としてレビューが必要である。モデルハンドオフには依然として受け入れテストが必要である。コスト記録には依然としてタグと解釈が必要である。インシデントプロセスには依然として、テーブル、ジョブ、下流の結果を理解する人々が必要である。
最も恩恵を受ける企業は、おそらく、規制された分析、製造トレーサビリティ、通信およびネットワークデータ、金融リスク、サイバーセキュリティデータ、小売予測、ライフサイエンスデータ、顧客データプラットフォーム、管理されたエンタープライズコンテキストに依存する AI アプリケーションなど、繰り返される高価値のワークロードを持つ企業である。これらの組織は、プラットフォームが重要になるのに十分な繰り返し作業と、ガバナンスが重要になるのに十分な結果を持っている。彼らはまた、プラットフォームがデモの表面として扱われる場合に失うものが最も多い。
展開条件が結果を決める
良好な Databricks の展開には認識可能な形状がある。Unity Catalog が有効化され、実際に使用されている。重要なテーブルは、管理されていないパスではなく、名前で参照される。ワークスペースは正しいカタログにバインドされている。サービスプリンシパルは、その場しのぎではなく設計されている。ジョブはバージョン管理された定義からデプロイされる。繰り返しのワークロードは、散逸したインタラクティブクラスターではなく、適切なジョブコンピュートまたはサーバーレスコンピュートで実行される。コスト帰属はタグ、ワークロードメタデータ、システムテーブルを使用する。データ品質モニタリングは、ドリフトが重要なテーブルをカバーする。モデルバージョンは、ガバナンスの下で登録、検証、提供される。下流の消費者は、どの出力が認定され、どの出力が実験的かを知っている。
その形状は自動的ではない。移行作業が必要である。レガシーテーブルはマッピングされなければならない。古いノートブックはジョブに変換されるか、廃止されなければならない。権限は整理されなければならない。チームは命名について合意しなければならない。エンジニアは、リネージが重要な場所ではパスのショートカットを管理された参照に置き換えなければならない。所有者は、ジョブが部分的な結果を生成した場合に何が起こるべきかを決定しなければならない。ファイナンスチームとプラットフォームチームはコストタグ付けについて合意しなければならない。セキュリティチームは、外部ロケーション、モデルエンドポイント、クレデンシャルをレビューしなければならない。ビジネスチームは、管理されたプラットフォームが、繰り返し作業をより安全にするために、いくつかの非公式な作業を遅くする可能性があることを受け入れなければならない。
HP Indigo の顧客事例は、Databricks をもっともらしくする条件の種類を示しているために有用である。この事例は、何千ものデータボリューム、数百のジョブとパイプライン、手動ファイル、切断されたシステム、トレーサビリティの問題を抱える企業を説明している。Databricks と Unity Catalog は、製造データを統一し、リネージを改善し、消耗品のトレーサビリティ時間を短縮し、予測モデルをサポートする方法として提示されている。これはベンダーが選んだ事例であり、監査ではない。それでも、正しい価値パターンを示している。すなわち、繰り返される運用上の問い、断片化されたデータ、高価な遅延、そしてビジネスにとって重要なガバナンス表面である。
間違ったパターンも明らかである。チームが主により良いノートブックを望むなら、プラットフォームは必要以上であるかもしれない。企業が貧弱なデータ所有権を持ち、それを修正する意欲がない場合、Databricks は混乱を維持するための高価な場所になり得る。バイヤーが AI 機能をデータエンジニアリングの近道として扱う場合、結果は不確かなデータに対する自信に満ちた回答になるかもしれない。ファイナンスがジョブをビジネス価値に結びつけられない場合、使用量ベースの価格設定は管理ツールではなく議論になり得る。ガバナンスがビジネス所有者なしで完全にプラットフォーム管理者に委任される場合、権限は技術的には整理されていても、運用上は間違っている可能性がある。
Databricks はいくつかの代替手段と競合する。一つは手動または半手動の作業である。ノートブック、スプレッドシート、一回限りのスクリプト、BI 抽出、会議。それは小規模なワークロードには安価であり得るが、繰り返される管理されたワークロードには悲惨である。もう一つは、Apache Spark、Delta Lake または Iceberg、Airflow、dbt、Kubernetes、Trino、オープンソースカタログ、MLflow、クラウドネイティブ監視から組み立てられた内部プラットフォームである。それはベンダー集中を減らし、制御を増やすことができるが、統合、サポート、アップグレードの労働を顧客に移す。もう一つはクラウドデータウェアハウスパスである。Snowflake、BigQuery、Redshift、Synapse および関連サービスは、アナリティクスと SQL 操作を簡素化できるが、より広範な ML、レイク、ガバナンス、オープンテーブルの要件は異なる。もう一つは AWS、Azure、または Google Cloud からのクラウドネイティブなオーケストレーションとアナリティクスであり、一つのクラウドに密接に連携しながらプロバイダー依存を増加させる。もう一つは、より狭いスライスをより少ないプラットフォーム野心で解決する従来の SaaS アナリティクスまたはデータプラットフォームである。
Databricks が勝つのは、その統合が繰り返される管理された出力の総作業を減らすときだけである。顧客の実際のボトルネックが、プロセス合意、ソースシステムの品質、ビジネスレビュー、または完全なプラットフォームを必要としない単純なウェアハウスユースケースである場合、それは負ける。また、バイヤーが統合された運用よりもオープンな可搬性を重視する場合にも負ける。Delta Lake とオープンソースの起源は可搬性の議論を助けるが、Databricks が管理するサービス、Unity Catalog の設定、ジョブ、システムテーブル、サーバーレスの動作、モデルサービングパスは依然としてプラットフォーム固有である。
評決
Databricks は、より豊富なメニューを持つノートブック企業としてではなく、管理されたデータと AI 作業のための運用プラットフォームとして評価されるに値する。その製品表面は、オーケストレーション、ポリシー、リネージ、テーブルの信頼性、コストの可観測性、モデルライフサイクル、管理されたコンピュートなど、エンタープライズデータ運用の困難な部分に成長している。これは、企業が実際にデータをどのように使用しているかに対する合理的な応答である。探索は価値があるが、繰り返される管理された出力こそが、資金とリスクが存在する場所である。
Databricks の最も強力なケースは、共有されたエンタープライズデータから繰り返しデータとモデル出力を生成する多くのチームを持つ企業であり、特にリネージ、アクセス制御、監査可能性、コスト管理がすでに痛手となっている場合である。そのような環境では、プラットフォームはノートブック、スケジューラー、クラスター、カタログ、モデルレジストリ、カスタムコストスクリプト、手動調査のパッチワークを置き換えることができる。チームが探索作業から繰り返し可能なジョブへと、より少ないハンドオフで移行できるようにする。障害をより可視化できる。コストをより帰属可能にできる。ガバナンスチームに、データからモデル、消費者までのパスのより多くをカバーする表面を与えることができる。
より弱いケースは、Databricks がガバナンスを消し去ることを期待する企業である。それはしない。それはガバナンスにより多くの機械を与える。ビジネス上の決定を供給するわけではない。アクセスを強制できるが、アカウンタビリティを定義できない。条件が満たされればリネージを示せるが、すべての重要な依存関係がモデル化されたことを保証しない。作業を再試行できるが、安全でない作業を安全にしない。モデルを提供できるが、予測を信頼すべきかどうかを決定できない。コストを公開できるが、出力がそのコストに見合う価値があったことを証明できない。
実際的な購買規律は、ストーリーを購入する前に受理されたジョブを特定することである。どの繰り返しのジョブが、ノートブックまたは断片化されたワークフローから Databricks へ移行するのか？誰がそれを所有するのか？どの入力テーブルを使用するのか？どの Unity Catalog 権限が適用されるのか？どのリネージが見えなければならないのか？どのタスク障害を安全に再試行できるのか？期待されるコスト範囲はどのくらいか？どの下流チームが出力を受理するのか？受理を証明する証拠は何か？ジョブが悪い結果を書き込んだらどうなるのか？Databricks が選択されなかった場合、企業はどの代替手段を使用するのか？
これらの質問は、プラットフォームをより小さく、より現実的にする。また、Databricks を誤った基準で判断されることから守る。これほど広範なプラットフォームには、常に印象的に見えるデモと、乱雑に見えるエッジケースがある。持続的な尺度は、より演劇的ではない。管理されたジョブが再び実行され、正しい出力を生成し、ポリシー境界を保持し、証跡を残し、説明可能なコストエンベロープ内にとどまり、次のチームに安全に使用できるものを与えた。
それが最も強力な Databricks のテーゼである。「すべてのデータと AI を一箇所に」というスローガンとしてではなく、より正確な取引として。ポリシー、リネージ、コンピュート、テーブル状態、モデルハンドオフ、リカバリーが一緒に管理できる場所に、繰り返し作業を置くこと。その取引は検討する価値がある。また、監視する価値もある。動き続ける管理されたジョブは機能ではない。それは運用基準であり、Databricks はノートブックの輝きが薄れた後、どのくらいの頻度で顧客がそれを満たせるかによって判断されるべきである。