1コピー、1エンジン、継ぎ目なし

融合は現実のものであり、AIこそがそれを緊急なものにした

私たちは40年間、当時としては理にかなっていた分断体制で生きてきました。運用データベースは、一度に1行ずつビジネスを処理し、分析システムは、過去のデータに関する大きな疑問に答えていました。私たちは、パイプラインやレプリカ、そして誰もが費用を負担しながらも誰も好まなかったETLレイヤーで、両者を繋いでいました。人間が人間のスピードでソフトウェアを開発していた時代は、それは妥当なトレードだったのです。

エージェントはトレードを破壊しました。エージェントは人間のようには動作しないし、人間向けに作ったアプリのようにも動作しません。エージェントはコンテキストを読み取り、ループし、何かを試み、書き戻し、それを人間がコーヒーを飲み終える前に何百回、何千回も繰り返します。このペースでは、ライブシステムと分析システム間のあらゆるホップが、すべてを遅くする原因となります。エージェントは、現在の状態と詳細な履歴を同時に必要とし、両者が一致している必要があります。問題提起に関しては、Databricksと私は意見が一致しています。

「HTAPが失敗した」という主張について

レイノルズははっきりとこう述べました。「HTAPはほぼ失敗に終わった」。システムは独自仕様で、エコシステムもなく、単一のエンジンを目指したことで、トランザクションと分析の両方で妥協を強いられたと。彼はマイケル・ストーンブレーカーの著書『One Size Fits All: An Idea Whose Time Has Come and Gone』（万能なエンジン：時代遅れのアイデア）を引用し、単一のエンジンですべてを完璧にこなすことはできないと主張しました。これは彼らの売り込みの根幹を成す主張なので、詳しく検証する価値があります。

彼は10年前のHTAPについて述べていますが、当時のシステムに関しては彼の言う通りです。確かに妥協はありました。多くは独自のシステムで、エコシステムは脆弱でした。しかし、それはある世代の製品に対する評価であって、その理念に対する評価ではありません。そして、その評価が、その理念を葬り去るために利用されているのです。

しかし、「万能なソリューションはもはや時代遅れ」というのは、あらゆる機能を一つの汎用エンジンに詰め込んで、結局どの機能も中途半端になってしまうことへの反論でした。ポイント書き込みとビッグスキャンの両方が高速になるように、ストレージフォーマットを意図的に設計することへの反論では決してありませんでした。その違いこそが全てであり、私たちが10年かけて構築してきたものです。SingleStoreのUniversal Storageは、分析機能を後付けした汎用エンジンではありません。最初から両方に対応できるように設計された単一のフォーマットです。「難しいから、代わりに3つのエンジンと共有バケットを使うことにしよう」というのは、正当なエンジニアリング上の選択ですが、物理法則ではありません。

そして、ここでレイノルズ氏に直接、敬意を込めて申し上げたいことがあります。HTAPを失敗作と断言しておきながら、その後20分かけて、世界がまさにHTAPが約束した機能を必要としている理由を説明するのは筋違いです。OLTPとOLAPを統合し、エージェントが1か所で読み書きできるようにするのがHTAPの目標であり、スライドに何と書いていようと変わりません。LTAPと名称変更しても、マーケティング戦略変わるだけで、根本的な原理は変わりませんし、議論の的となる問題も解決しません。

その批判の中で、私が真っ向から反論したい言葉が一つあります。それは「独自規格」です。HTAPに対する批判は、システムが独自規格でエコシステムが脆弱であるという点でした。結構です。では、新しいアーキテクチャにも同じ基準を適用すべきです。Reydenは完全に独自規格でクローズドな全く新しいエンジンであり、この市場においてエコシステムは非常に若いと言えます。つまり、まだエコシステムは存在しないのです。そして、LakebaseはPostgresのオープンソースというイメージを借りることはできません。マネージドLakebase製品（サーバーレス制御プレーン、レイク統合、エンタープライズレイヤー）は、Postgresに対応したDatabricks独自のソフトウェアです。「オープンなPostgres」ではありません。基盤となるオープンテーブル形式は確かに存在し、重要ですが、ディスク上のオープンファイルと、それを読み書きするオープンエンジンは同じではありません。独自規格のエンジンがHTAPに対する批判点であったとしても、その基盤となるデータがたまたまIcebergであるからといって、それが美徳になるわけではありません。

共有ストレージは統合エンジンとは違う

レイノルズ氏は、核心にある問題をまさに私と同じように捉えていました。OLTP（オンライン・トランザクション処理）では、膨大なデータの中から必要なデータを見つけ出し、迅速に更新するために、行指向のストレージが必要となります。一方、分析では、広範囲のデータを検索するために、列指向のストレージが必要となります。この二律背反は紛れもない事実であり、あらゆる処理の根幹を成すものです。問題は、この二律背反にどう対処するかです。

LTAPの解決策は、ストレージ層での統合です。トランザクション処理にはPostgres（Lakebase）、大規模分析にはSparkとPhoton、リアルタイム読み取りには新しいReydenエンジンをそれぞれ別々に用意し、それらすべてをオブジェクトストレージ内の単一のオープンコピーに向けます。同じデータのコピーを4つのシステムに分散して保持していた経験がある人にとっては、これは安心材料に聞こえるでしょうし、確かに改善と言えるでしょう。その点は認めます。

しかし、「1つのコピー」というのはストレージに関する主張であって、エンジンに関する主張ではありません。3つのエンジンが依然としてその上にあり、それぞれが独自のキャッシュ、データの鮮度に関する独自の認識、そして最悪のタイミングで障害を起こす独自の方法を持っています。また、Databricksの枠組みでは、行レイアウトと列レイアウトは異なるものです。Postgresの行表現に書き込みが行われ、アナリティクスが列表現を読み取る場合、同じデータの2つの物理的な形状が存在することになり、それらを同期させる何かが必要になります。その変換を何と呼ぶかは自由です。私はその「何か」を自分の手で維持してきました。鮮度に遅延があり、最終的には、たいていは金曜日に壊れます。

そして、この特定の形状がなぜ私の首筋の毛を逆立たせるのか、率直にお話ししましょう。私は長年、Hortonworks、そしてClouderaでHadoopの世界に身を置いていました。私たちはあらゆる用途に対応するエンジンを持っていました。SQLにはHive、キーバリューにはHBase、高速クエリにはImpala、ストリーミングにはStorm、検索にはSolr、そしてSparkが急速にその後ろに迫っていました。それぞれが担当分野で本当に優れていました。しかし、それらが組み合わさると悪夢のような状態になりました。それは、どのエンジンも単体で弱いからではなく、すべての問題がそれらの間の継ぎ目に存在していたからです。統合はずれを生じ、セキュリティモデルは決して完全に整合せず、データはエンジンからエンジンへとシャッフルされ、ある部分が他の部分よりバージョンが遅れると午前3時にページングされる始末でした。業界全体が最終的にその広がりから脱却し、統合へと向かいました。ですから、1つの問題を解決するために3つのエンジンが共有ストレージに取り付けられているのを見ると、私は画期的な進歩だとは思いません。むしろ、すでに最後まで見た映画の、より小さく整ったバージョン、Hadoop v2のように見えます。私はそれに反対しているわけではありません。チャンネルを変えたのには理由があります。

私たちの現状とその理由

私たちは別の道を選びましたが、正直に言うと、構築するのはより困難でした。エンジンは1つ、ストレージレイアウトも1つ。真の統合はエンジンの問題であり、それをバンドル化して解決することはできないため、私たちはその賭けに出ました。この全体を支えているのは3つのアイデアです。

トランザクションと分析用のデータコピー1つ

Universal Storageは単一のフォーマットです。カラムストアファイルの上にインメモリの行ストア層が配置され、単一のレイアウトになっています。同じバイト数からカラムストアのスキャン速度と行ストアの書き込み速度を実現します。運用コピーと分析コピーを照合する必要はなく、睡眠中にシャドウテーブルが密かに同期を失うこともありません。トランザクションとクエリは同じデータを参照します。なぜなら、データは1つしかないからです。 

データが到着してからクエリ可能になるまでの期間に差はない

これは私が最も重視している点です。なぜなら、エージェントの成否を左右するからです。SingleStoreでは、書き込みがコミットされた瞬間にクエリ可能になります。同期後でも、マテリアライゼーションジョブが追いついた後でもありません。まさにその瞬間です。リアルタイムには書き込みパスを含める必要があります。そうでなければリアルタイムではなく、少し古いデータの高速読み取りに過ぎません。注目すべき点として、Databricks自身がLakehouse//RTを「読み取り専用ワークロードから開始する」と述べています。読み取りが先です。これは正直な告白であり、まさに私が言いたいギャップです。エージェントがアカウントを更新し、同時にそのアカウントを1年分の履歴と関連付ける質問をする場合、自身の書き込みを確認する必要があります。両方のワークロードが1つのエンジンで1つのコピーで実行される場合は、それがノーコストで得られます。コミットがフォーマット境界を越えて別のエンジンに移動し、順番を待たなければならない場合は、それを実現するために努力し、多くの場合、負けてしまいます。

同一エンジンで複数モデルに対応

実際のアプリケーションは、ずっと前に純粋なリレーショナルではなくなり、エージェントがそれをクリティカルパスに組み込みました。それらは、リレーショナルテーブル、JSONドキュメント、セマンティック検索用のベクトル、全文検索、時系列データなど、場合によってはこれらすべてを単一のクエリ内で処理することを求めています。私たちはそれらを1つのエンジンでネイティブに実行するため、1つのSQLステートメントで列をフィルタリングし、ベクトル類似性検索を実行し、結果をJSONフィールドと結合しても、データベースから離れることはありません。優秀なチームが、本来1つのクエリで済むはずだった処理を実行するために、データウェアハウス、ベクトルストア、検索クラスタを寄せ集め、その後1年間かけて3つすべてを相互に整合性を保つようにしているのを見てきました。統合とは、OLTPとOLAPを組み合わせるだけではありません。それは、本来互換性を持つはずのない5つのシステムを、従業員が監視し続けることを拒否することです。

解決したと断言する前に、私が尋ねるであろう4つの質問

これらは私がその場で提起したい質問です。議論に勝つためではなく、これらの質問を飛ばしたことで痛い目に遭った経験があるからです。Databricksはステージ上でこれらの質問に答えませんでしたが、それは当然のことです。基調講演であって、デザインレビューではなかったのですから。しかし、これらの質問こそが、アーキテクチャと発表を分けるものであり、Databricksがこれらの質問に的確に答えてくれれば、私たち全員にとってプラスになるでしょう。これは本心です。

Reydenは追記専用ですか、それとも更新や削除も処理できますか？

Reyden は単純な高同時実行読み取りでは高速です。しかし、Databricks 自身が言うように Lakehouse//RT は「読み取り専用ワークロードから開始」して発売されました。追記専用で読み取り中心のワークロードは高速化の最も簡単な方法であり、優れたベンチマークとなります。実際のデータは追記専用ではありません。注文のステータスは変更され、残高は変動します。顧客は忘れられる権利を行使し、GDPR は追記の速さには関心を持ちません。データレイク上では、変更処理は本当に困難です。Iceberg は、読み取り時に読み取り側が削除ファイルを調整し、行レベルの削除を行うマージ オン リード方式、または更新のたびにファイルを書き換えるコピー オン ライト方式を採用しています。どちらの方式も、低レイテンシが求められるまさにその瞬間に、読み取り増幅または書き込み増幅というコストを追加します。したがって、疑問は単純です。Reyden が書き込みを行うとき、更新および削除されるデータに対してミリ秒単位の数値を維持できるのか、それとも Reynolds 自身が言うように、まさにその箇所で HTAP が「失敗した」のか？運用ワークロードが実際に行う処理はまさにそれなので、私たちはインプレース更新と削除を最優先事項として扱うことにしました。

複数テーブル結合における一貫性の保証はどの程度ですか？

これは、良い意味で私を夜も眠らせない問題です。注文、支払い、在庫、顧客、イベントの 5 つのテーブルを結合する分析クエリを想像してみてください。単一の MVCC エンジンでは、このクエリは 5 つのテーブルすべてにわたって一貫したスナップショットを 1 つ読み取ります。トランザクションはどこにも存在するか、どこにも存在しないかのどちらかです。次に、これらの各テーブルを、トランザクション エンジンから非同期で独自のスケジュールで生成される独立したオープン フォーマット テーブルとして想像してみてください。これらのテーブルを結合したときに、一貫したスナップショット セットが取得されることを保証するものは何でしょうか。注文が 12:00:03 に、支払いが 12:00:05 に生成された場合、12:00:04 に実行される結合は、実際には存在しなかったビジネスの状況をつなぎ合わせる可能性があります。これは丸め誤差ではありません。これは間違った答えであり、誰も気づく前にエージェントがそれに基づいて動作します。Iceberg はテーブルごとにスナップショットの分離を提供します。Iceberg 自体は、非同期ライター間で一貫したマルチ テーブル スナップショットを提供するわけではありません。その質問には、構成によって答えます。つまり、1つのエンジン、1つのMVCCスナップショット、そして結合内のすべてのテーブルが同じストーリーを語るという仕組みです。

Lakebaseのデータは、どのエンジンでも読み取れる、仕様に準拠した真のIcebergデータですか？

レイノルズは、旧システムは独自仕様で、他の誰もそのデータを読み取ることができないというHTAP批判の中心に「エコシステム」を据えました。それはもっともです。では、新しいアーキテクチャにも同じ基準を適用しましょう。Lakebaseのデータはオープンであり、IcebergまたはDeltaを理解するリーダーであれば誰でも利用できるという約束です。私がそれを信じる前にテストするのは、ハードバージョンです。出力は、Icebergの正しいマニフェスト、パーティション仕様、v2/v3削除ファイル、スキーマ進化など、完全に仕様に準拠しており、Trino、Flink、Spark、DuckDB、またはSnowflakeが、削除と一貫性のあるスナップショットを含むライブで変化するテーブルを含め、完全な忠実度で読み取ることができるのでしょうか？それとも、Icebergフレーバーで、実際にはDatabricks内でしか機能しないのでしょうか？「Icebergを出力する」と「どのエンジンでも変更されるテーブルを正しく読み取ることができる」は2つの異なる約束であり、実際に必要なのは2番目の約束だけです。念のため申し添えておくと、SingleStoreはMySQL Wireに対応しており、オープンなIcebergとParquetの取り込みと出力に対応しているため、エコシステムに関する批判は検討に値する方向性を示しています。

Unityカタログの役割は何ですか？また、他のカタログはどうなるのでしょうか？

Unity Catalog は、2 つの役割を同時に果たしています。ガバナンス プレーンでは、ID、権限、データ系列、監査を管理し、テクニカル カタログでは、テーブルのメタデータとスナップショットを追跡します。Databricks 内部では、この統合が大きな強みとなっています。しかし、エンタープライズの実情はもっと複雑です。カタログを 1 つに標準化している企業はほとんどありません。AWS Glue、Hive Metastore、Snowflake の Polaris と Horizon、そして誰も触りたがらない独自のカタログがいくつか存在します。ですから、私が実際に尋ねたいのは、「Iceberg REST カタログをサポートしていますか」ではなく、「Databricks 以外のエンジンでも、同じデータに対して、御社のエンジンと同じセキュリティと一貫性のあるビューを取得できますか」ということです。答えが「いいえ」であれば、オープン フォーマットでありながら、入り口が閉ざされている状態であり、アーキテクチャに負荷がかかる前に、そのことを知っておく権利があります。

2つのアーキテクチャの比較

Reydenは高速で、彼らのガバナンスに関する主張は真実です。その2行は彼らのものです。リアルタイムアプリケーションを決定するすべての行（書き込み、鮮度、真実を伝える結合など）は、私たちのものです。

最後に一つだけ

Databricksは今週大きな話題を呼びましたが、その一部は当然のことでした。しかし、話題は統一されたエンジンではありませんし、新しい略語は解決された問題ではありません。私は基調講演の中心にある矛盾に何度も立ち返ります。HTAPを失敗と呼ぶこともできますし、HTAPが目指したものがまさに世界に必要な理由を20分かけて説明することもできます。両方を同時に行い、私たちが気づかないことを期待することはできません。この問題を解決するには、3つのエンジンを共有ストレージに取り付けて、継ぎ目が隠れることを願うだけではいけません。必要なのは、1つのコピー、1つのエンジン、継ぎ目のない状態です。書き込みが完了した瞬間にクエリを実行できる書き込み。常に真実を語る結合。チームが両手と祈りで支える必要のないプラットフォーム。これらは私にとってキャッチフレーズではありません。これらは私たちが10年間構築し、サポートし、そして（夜中に）呼び出しを受けながら守り続けてきたものなのです。

そして、週末を費やして2つのデータベースを繋ぐCDCパイプラインのメンテナンスに尽力し、他の社員がそのことを気にしなくて済むようにしてくれたすべてのエンジニアの皆さんへ。あなたの気持ちはよく分かります。私もかつて同じ立場でした。結局のところ、この議論の目的は、皆さんにその週末を取り戻してもらうことです。業界の他の人たちもようやくこの場に集まってくれたことを嬉しく思います。さあ、本当の疑問を声に出して問い、きちんとシステムを構築していきましょう。 

エージェント中心の世界において、HTAPやLTAPの必要性は紛れもなく現実のものであり、まさに今がその時です。Databricks、Snowflake、SingleStoreをはじめ、この分野で開発に携わるすべての企業にお願いしたいのは、協力し合い、私たちが掲げる基準に沿ったアーキテクチャを構築していくことです。オープンテーブル形式は確かに大きな前進です。しかし、コントロールプレーン、カタログ、セキュリティレイヤーがすべて独自仕様であれば、ディスク上のIcebergやDeltaだけでは不十分です。エージェント時代においては、データは顧客の信頼を得られるあらゆるエンジンで真にポータブル、読み書き可能でなければならず、閉ざされた扉の向こうにIcebergのようなデータ構造があってはなりません。エージェントは、誰も完全に予測できない方法でシステム間を横断して動作するでしょう。それに対する適切な対応は、好みのランタイムを囲む壁を高くすることではありません。Databricks、Snowflake、その他多くの企業の卓越した技術力と協力し、顧客のために正しいことを実現していきたいと考えています。さあ、始めましょう！