Databricks、LTAP で OLTP と OLAP を統合し AI エージェントの制約を打破

ジョナサン・カッツは、データ業界の多くが「仕方ない」と受け入れてきた境界線の両側でキャリアを築いてきました。長年の Postgres コントリビューターであり、現在は Databricks のシニアスタッフプロダクトマネージャーとして活躍する彼は、運用系と分析系のシステムが別々の世界として存在し、パイプラインやコピー、妥協点によってのみ繋がれてきた様子を目の当たりにしてきました。

今回の対談では、なぜかつてこの分離が存在したのか、そしてなぜ AI エージェントがその境界を崩す要因となっているのか。さらに、LTAP が単一のエンジンではなく、統合されたストレージ層において両者の接点を再定義することで、この格差をどう埋めるのかについて解説します。

AI エージェントが崩した前提

業界は数十年にわたり、運用系と分析系のデータベースシステムを厳密に分離してきました。では、自律型 AI エージェントの台頭がなぜ、この分離を崩し始めたのでしょうか？

データの世界には大きく分けて 2 つの領域があります。運用データ は、クレジットカード決済の処理や不正検出を行う際に扱うデータで、行単位を高速に走査する非常に短く速いクエリが特徴です。一方、分析データ は数週間から数年かけて蓄積されたもので、クエリを実行するとデータセット全体を横断して参照します。

両者ともできるだけ早く回答を得ようとしていますが、そのアプローチは根本的に異なります。この違いは偶然ではなく、物理的な制約によるものです。データを行単位で保存すれば、単一の高速な回答を即座に返すのに最適です。一方、列単位で保存すれば、データ全体をスキャンして集計する処理が最も効率的になります。

設計思想の違いも大きいです。分析クエリは、膨大なデータセットから回答を得るために並列化されたシステムのリソースをすべて使い切ることを前提としています。対照的に、運用クエリは素早く回答を出す一方で、消費するリソースを最小限に抑えるように設計されています。

この違いが、データシステムの設計や管理における考え方を 2 つの異なる方向へと導き、それぞれに適した最適化手法が必要となる理由です。

世界中で最も広く導入されているデータベースの一つである Postgres は、運用ワークロードに最適化されているため行ベースの構造を持っています。一方、分析用エンジンはその逆の理由から列ベースで構築されています。この根本的な物理的な違いにより、両システムは常に分離せざるを得ず、運用データを分析したい場合でも、別の場所にデータを送る必要がありました。

AI エージェントの台頭は、私たちがデータベースに求めるものを大きく変えました。これが Lakebase のアーキテクチャ が存在する理由の一つでもあります。エージェントが実際に動作する方法に合わせて設計されたデータベースです。例えば、エージェントには不正検出や異常の発見といったタスクが与えられますが、これらの事象は数百ミリ秒という短い時間内で発生します。しかし、そのシステムは同時に膨大な量の書き込みと短時間の読み取りも処理する必要があります。単一のエージェントなら、必要なクエリを賢く判断できるかもしれません。しかし、ガードレールがなければ、多数のエージェントが運用システムを一気に押しつぶす可能性があります。

LTAP とは何か

*LTAP とは具体的に何者で、その内部ではどのように動作しているのでしょうか？*

Jonathan Katz: LTAP（Lake Transactional/Analytical Processing）を使えば、データを移動させることなく、トランザクション処理を行うシステムに負荷をかけることもなく、生きた運用データに対して直接分析クエリを実行できます。これは、パイプラインで接続された別々のシステムを経由させるのではなく、トランザクションデータと分析データを単一の論理ストレージ層内で統合することで実現されています。

LTAP が可能になっている背景には、Lakebase 自体のアーキテクチャがあります。Lakebase はステートレスでエフェメラルな計算リソースであり、湖（lake）内のストレージとは完全に分離されています。この分離は Neon から継承されたもので、永続的なストレージ層が高スループットの書き込みを処理し、定期的にオブジェクトストレージにフラッシュして永続化します。これは、その瞬間に実行されている計算リソースの種類に関係なく独立して行われます。すでにクラウドストレージ向けに最適化されているデータを、Lakehouse が既に採用しているカラム形式で表現すれば、Apache Spark や SQL などのエンジンが直接読み込んで、コピーを作成することなく高性能な分析クエリを実行できるはずです。

最も難しかったのは、データが翻訳の過程で失われないようにすることでした。Postgres には独自のデータ型とエンコーディングがあり、Iceberg や Delta のようなオープンフォーマットにもそれぞれ固有のものがあります。私たちは、元の Postgres データの物理的な表現を 1 ビットも変えずに、そのまま Parquet ファイルとして書き出す必要がありました。これこそが、同じデータの運用面と分析面の表現を一つに統合できる鍵となったのです。

実際には、ストレージ層は 2 つの階層で動作します。ホットな階層ではデータを行形式で保持し、高速な運用アクセスを実現します。一方、コールドな階層では列形式で保存し、分析クエリを効率的に処理できるようにしています。これにより、それぞれのニーズに応じて必要なデータに素早くアクセスできます。

HTAP が立ち止まった場所で LTAP が成功する理由

*HTAP は数年前からリアルタイム分析の解決を試みてきましたが、行き詰まっていました。なぜ湖屋ストレージ層でこのアプローチが、従来の HTAP の失敗を乗り越えて成功したのでしょうか？*

Jonathan Katz: HTAP システムを動作させることは可能ですが、コストがかかります。システムは重く、運用も難しく、一般的にオープンではありません。LTAP モデルの決定的な違いは、サーバーレスの運用計算リソースとサーバーレスの分析計算リソースが独立して提供される点です。一つのシステムで両方の仕事を同時にこなそうとするのではなく、各ワークロードに対して必要な計算リソースを細かく調整できます。

データシステムのどこでも言えることですが、ストレージは安価な部分です。コストがかかるのは計算リソースの方なのです。

ストレージ層を統一するのではなく、エンジン層を統一すべきだという主張の核心は、それぞれの業務に特化した効率的なエンジンを維持できる点にあります。そして、計算リソースが必要な場所にのみコストをかければよく、すべてにおいて優れた単一の高価なシステムを稼働させる必要はありません。

エージェントが古いデータを元に行動したときに何が壊れるか

*今日、古いデータを参照して行動することで破綻したり性能が低下したりする具体的なエージェントワークフローを詳しく説明してください。具体的に何が問題になるのでしょうか？*

Jonathan Katz: 不正検出が最も明確な例です。クレジットカード取引の決済は数百ミリ秒以内に行われます。もし不正を検知するエージェントが、数分あるいは数時間前のバッチコピーされたデータを元に動作しているなら、取引が完了してしまう前に何らかの対策を講じることはもはや不可能です。そのため、そのエージェントは運用システムに直接接続して動作させる必要があります。

しかし、運用システムは継続的な書き込みと短時間の読み取りを処理するために設計されており、重い分析クエリも同時に受け入れることは想定されていません。エージェントが異常検知のために顧客の全購買履歴をスキャンするクエリを実行すると、これは逆のワークロードに最適化されたシステムに対して非常にコストのかかる処理となります。その結果、同時に処理しようとする他のすべてのトランザクションのパフォーマンスが低下する恐れがあります。

現代のアーキテクチャでは、良質な意思決定のために運用側と分析側の双方からデータを取得する必要があります。そのため、エージェントは両方のソースから情報を引き出す必要があります。一つのエージェントであれば責任を持って対応できるかもしれませんが、同じようなクエリを同時に実行する多数のエージェントが制御なくシステムに負荷をかければ、運用システムは一瞬でパンクしてしまいます。

ガバナンス、オープン性、そしてエンタープライズ向けの実用性

*Databricks は現在、LTAP を具体的にどのように実装しているのでしょうか？また、HTAP の限界を理解している人に対して、その仕組みをどう説明すればよいでしょうか？*

ジョナサン・カッツ氏: 保存メカニズムの他にもう一つの重要な要素がカタログです。レイクハウス の真の革新の一つは、組織に対してすべてのデータへの中央集権的で統一されたビューを提供した点にあります。誰が何にアクセスできるのか、全体的に一貫したポリシーを適用し、許可されたグループに属さない人が社会保障番号のような機密情報を読み取れないようにする仕組みです。

しかし、これは運用システムにはこれまで適用されてきませんでした。運用システムは最初からデータサイロとして構築されていたからです。運用データと分析データの関係性は昔ながらの「パイプラインを構築し、データを転送し、その後はご愁傷様」というものでした。下流で何が起こっても責任を持つ人はいなかったのです。

LTAP はこの構造を一変させます。すべてのデータを一つの統一されたストレージモデルにまとめ、単一のカタログの下に管理します。誰かが分析のために運用データを取り出す必要があっても、ガバナンスの境界を越えてしまうことを心配する必要はありません。

また、この仕組みがオープンな基盤の上に構築されるべきであるという理由もあります。DB-Engines のランキングでは、Postgres が「感情的に最も支持されているデータベース」の第3位に迫っています。これは必ずしも採用率を直接示すものではありませんが、技術の行方を示す強力なシグナルであり、柔軟性と選択肢の価値を浮き彫りにしています。オープンソースは過去数十年にわたり、世界中で最も重要なシステムの原動力となってきました。LTAP もこの原則を引き継ぐものです。

Postgres 内においても、データは Postgres システム間でポータブルですが、結局は Postgres という枠組みに縛られます。しかし LTAP の統合ストレージ層を使えば、適切なエンジンを選ぶためにデータを移動させる必要はありません。むしろ、エンジン側をデータのもとへ持っていくのです。

コアとなる転換：統合ストレージ

*LTAP がもたらす核心的な変化を一言で表現するなら、どのように説明しますか？*

Jonathan Katz：一言で言えば「統一ストレージ」です。分析担当者にこの言葉を投げかければ、すぐに理解してくれますが、運用担当者の場合は「何を指しているのか」と聞き返すかもしれません。

しかし、同じデータについて、移動もせず、ビット単位での変更も一切行わずに、運用側と分析側の両方の表現を一つに統合できれば、これまで避けられないと思っていた多くの課題が一気に解消されます。データをブロンズ層やシルバー層へ取り込むためにパイプラインを実行する必要はもうありません。データが書き込まれた瞬間から、すぐに分析を開始できるのです。

逆の視点も重要です。これは何か新しいものを発明することではなく、本来分ける必要のなかった二つの世界を再び結び直すことに他なりません。データはただのデータです。そのように扱うほど、人間だけでなく、AI エージェントにとっても扱いやすくなります。パイプラインを介して調整する必要がなくなるからです。

両方の世界を再び結びつける

40 年もの間、運用データと分析データの境界線は、ストレージの物理的な制約によって維持されてきました。しかし、エージェントワークロードはこの境界線が生む遅延に耐えられない最初のケースです。

LTAP はトランザクションと分析クエリの違いを消し去ろうとするわけではありません。同じデータを対象に運用と分析の両方を行う際に発生していた「コスト」を取り除くのです。

アジェンシーワークロードがこのアーキテクチャパターンを本当に必要としているかを評価するデータアーキテクトにとって、ジョナサンが示すテストは非常に有用です。「エージェントの次の判断が、まだ確定していないデータに依存している場合」や「データを近接かつ保護するために設計されたシステムに依存している場合」、従来のパイプラインとコピーを繰り返すモデルでは速度が追いつきません。LTAP はまさにこの課題を解決するために構築されました。

LTAP についてさらに詳しく知りたい場合は、以下の記事をお読みください。

*From monolith to Lakebase to LTAP: rethinking the database from storage up.*