エージェントが打ち破った40年来のデータベースのルール：LTAPがOLTPとOLAPのワークロードを統合する方法

ジョナサン・カッツ（Jonathan Katz）は、データ業界のほとんどが「そういうものだ」と受け入れてきた境界線の両側でキャリアを築いてきました。長年にわたり Postgres のコントリビューターを務め、現在は Databricks のシニアスタッフ・プロダクトマネージャーである彼は、業務システムと分析システムが、パイプライン、データのコピー、そして妥協によってのみ繋がれた、2つの異なる世界として機能する様子を見てきました。

この対談でジョナサンは、そもそもなぜそのような分断が存在したのか、なぜ AI エージェントがそれを最終的に打破する存在なのか、そして LTAP が2つの世界の接点を「単一のエンジン」ではなく「統合されたストレージレイヤー」として再考することで、どのようにそのギャップを埋めるのかを詳しく説明します。

AI エージェントが打ち破った前提

業界は何十年もの間、業務データベースシステムと分析データベースシステムの厳格な分断を受け入れてきました。自律型 AI エージェントの台頭が、なぜそれを打ち破ろうとしているのでしょうか？

ジョナサン・カッツ：データには2つの世界があります。業務データは、クレジットカードの決済処理や不正検知を行う際に触れるもので、データを1行ずつ確認する、非常に短時間で高速なクエリです。分析データは、数週間、数ヶ月、あるいは数年にわたって蓄積してきたもので、クエリを実行する際はデータセット全体を見渡します。どちらも可能な限り迅速に回答を返そうとしますが、そのアプローチはまったく異なります。

その違いは恣意的なものではありません。物理的な仕組みに起因しています。データを「行（ロー）」単位で保存すれば、単一の回答を可能な限り迅速に返すことができます。データを「列（カラム）」単位で保存すれば、データ全体をスキャンして集計する処理を可能な限り迅速に行うことができます。また、設計上、分析クエリは非常に大規模なデータセットから回答を得るために、大規模並列処理システムの全リソースを消費することがありますが、業務クエリは、迅速に回答を返しつつも、消費リソースを最小限に抑えるように設計されています。これにより、データシステムの設計や管理に関する考え方が大きく異なり、それぞれ異なる最適化が必要になります。

Postgres は、世界で最も広く普及しているデータベースの1つですが、業務ワークロード向けに最適化されているため、行指向で構築されています。分析エンジンは、その逆の理由から列指向で構築されています。この根本的な物理的違いにより、2つのシステムは常に切り離されて存在せざるを得ず、業務データを分析したいときはいつでも、別の場所にデータを転送する必要がありました。

AI エージェントの台頭により、データベースに求められる要件が変わりました。そもそも Lakebase のアーキテクチャが存在する理由の1つもここにあります。つまり、エージェントの実際の働き方に追従できるように構築されたデータベースなのです。例えば、エージェントは不正や異常の検知を課されますが、そうしたイベントは数百ミリ秒単位で発生します。しかし、そのシステムは同時に、膨大な量の書き込みや短い読み取りも処理しています。単一のエージェントであれば、実行すべきクエリを判断できるほどスマートかもしれません。しかし、ガードレールがなければ、大量のエージェントが業務システムを簡単にパンクさせてしまう可能性があります。

LTAP とは何か

LTAP とは何ですか？また、その内部の仕組みはどのようになっているのでしょうか？

ジョナサン・カッツ：LTAP（Lake Transactional/Analytical Processing）は、データをどこにも移動させることなく、またトランザクションを処理するシステムに負荷をかけることなく、稼働中の業務データに対して直接分析クエリを実行できるようにします。これは、パイプラインで接続された別々のシステムにデータを通すのではなく、トランザクションデータと分析データを単一の論理ストレージレイヤーに統合することで実現されます。

内部的には、LTAP は Lakebase 自体のアーキテクチャ（レイク内のストレージから完全に分離された、ステートレスでエフェメラルなコンピュート）によってのみ実現可能です。Neon から継承されたこの分離により、高耐久ストレージレイヤーは、その時点で実行されているコンピュートに関係なく、高スループットの書き込みを処理し、永続化のためにオブジェクトストレージに定期的にフラッシュできます。そのデータはすでにクラウドストレージ向けに最適化されているため、レイクハウス（Lakehouse）がすでに使用しているものと同じ列指向フォーマットで表現すれば、Apache Spark や SQL などのエンジンが直接読み取ることができ、データを複製することなく高性能な分析読み取りが可能になります。

最も困難だったのは、変換プロセスで何も失われないようにすることでした。Postgres には独自のデータ型とエンコーディングがあり、Iceberg や Delta などのオープンフォーマットにも独自のデータ型とエンコーディングがあります。私たちは、元の Postgres データの正確な物理的表現を1ビットも変更せずに維持し、Parquet ファイルに書き出す必要がありました。これによって、同じデータの業務表現と分析表現を1つに統合することが可能になりました。実際には、ストレージレイヤーは2つのティアで動作します。高速な業務アクセスのためにデータを行フォーマットで保持するホットなティアと、分析読み取りのために列フォーマットで保持するクールなティアです。これにより、どちらの側も必要なデータを効率的に取得できます。

HTAP が停滞した一方で、LTAP が成功する理由

HTAP は数年前にリアルタイム分析の解決を試みましたが、停滞してしまいました。従来の HTAP が失敗した一方で、レイクハウスのストレージレイヤーでこれを行うアプローチが成功するのはなぜでしょうか？

ジョナサン・カッツ：HTAP システムを動作させることはできますが、コストがかかります。扱いにくく、運用が難しく、一般的にオープンではありません。LTAP モデルが異なるのは、サーバーレスの業務コンピュートとサーバーレスの分析コンピュートを2つの別々のものとして利用できる点です。1つのシステムで両方の処理を同時に行おうとしてコストを支払うのではなく、ワークロードごとに使用するコンピュート量を個別に調整できます。データシステムにおいて、ストレージは安価な部分であり、コンピュートこそが高価な部分です。

これこそが、エンジンではなくストレージレイヤーを統合すべきだという最大の理由です。それぞれの処理に適した、特化型で効率的なエンジンを維持しながら、実際に必要な部分のコンピュート料金だけを支払うことができます。すべてを一度にこなそうとする高価なシステムを1つ稼働させる必要はありません。

エージェントが古いデータに基づいて行動すると何が破綻するか

古いデータを読み取って行動するために、現在破綻している、あるいはパフォーマンスが低下している具体的なエージェントのワークフローを教えてください。実際にはどのような問題が発生するのでしょうか？

ジョナサン・カッツ：不正検知が最も分かりやすい例です。クレジットカードの決済処理は数百ミリ秒以下で完了します。不正検知を担当するエージェントが、数分前や数時間前の古いバッチコピーデータに基づいて動作している場合、決済が完了する前に不正を検知するには遅すぎます。そのため、そのエージェントは業務システムに対して直接動作させる必要があります。

しかし、業務システムは絶え間ない書き込みや短い読み取りを処理しており、重い分析クエリを同時に受け入れるようには設計されていません。エージェントが異常をチェックするために顧客の全購入履歴をスキャンするクエリを実行する場合、それは逆のワークロード向けに最適化されたシステムにとっては非常に負荷の高いクエリになります。その結果、同時に処理しようとしている他のすべてのトランザクションのパフォーマンスが低下する可能性があります。また、現代のアーキテクチャでは、適切な意思決定を行うために業務側と分析側の両方のデータが必要になることが多いため、エージェントは両方からデータを取得する必要があります。単一のエージェントであれば適切に処理できるかもしれませんが、負荷を制限するガバナンスがなければ、同様のクエリを同時に実行する大量のエージェントが、業務システムをあっという間にパンクさせてしまう可能性があります。

ガバナンス、オープン性、そしてエンタープライズにおけるユースケース

Databricks は現在、LTAP を具体的にどのように実装していますか？また、HTAP が不十分である理由をすでに理解している人に対して、これをどのように説明しますか？

ジョナサン・カッツ：ストレージの仕組みだけでなく、もう1つの重要な要素はカタログです。レイクハウス（Lakehouse）の真の革新の1つは、組織にすべてのデータの集中化・統合化されたビューを提供したことでした。誰が何にアクセスできるか、すべてに一貫したポリシーを適用できるため、特権グループに属していない限り、社会保障番号のようなデータを読み取ることはできません。しかし、業務システムは最初からデータのサイロとして構築されていたため、これが適用されることはありませんでした。これまでの業務データと分析データの関係は、「パイプラインを構築してデータを転送し、あとは野となれ山となれ」というものでした。下流で何が起こるかについて、誰も責任を持っていませんでした。LTAP はそれを覆します。すべてのデータが、1つの統合ストレージモデルで、1つのカタログの下に管理されます。誰かが分析する必要があるからといって、業務データがガバナンスの境界線から外れてしまうことを心配する必要はもうありません。

また、これをオープンな基盤の上に構築する必要がある理由もあります。Postgres は、DB-Engines のランキングで「最も好まれているデータベース」の第3位に迫っています。これは必ずしも導入実績を示すものではありませんが、今後の方向性を示す強力なシグナルであり、柔軟性と選択肢の価値を示しています。オープンソースは何十年もの間、世界で最も重要なシステムのいくつかを支えてきました。LTAP も同じ原則を拡張したものです。Postgres 内であっても、データは Postgres システム間で移植可能ですが、依然として Postgres に縛られています。LTAP の統合ストレージレイヤーを使用すれば、適切なエンジンを適用するためにデータを移動させる必要はもうありません。エンジンをデータのある場所に持ってくるのです。

核心となる転換：統合ストレージ

LTAP がもたらす核心的な転換を1文で表現するとしたら、どのように表現しますか？

Jonathan Katz: 極めてシンプルに言えば、統合ストレージです。分析担当者にそう言えば、ほぼ瞬時に理解してもらえます。運用担当者に言えば、「どういう意味ですか？」と聞き返されるかもしれません。しかし、データを一切移動せず、1ビットも変更することなく、同じデータの運用表現と分析表現を統合できれば、かつては避けられないと思われていた多くの課題が一気に解消されます。ブロンズレイヤーやシルバーレイヤーにデータを取り込むためだけに、パイプラインを実行する必要はもうありません。データが書き込まれた瞬間に分析を開始できます。また、見方を変えれば、これは何か新しいものを発明するというよりも、本来分けるべきではなかった2つの世界を再び統合することに近いと言えます。データは単なるデータです。そのように扱えるようになればなるほど、人、そして今やエージェントにとっても、事前にパイプラインを介した調整をすることなく、データを扱いやすくなります。

2つの世界を再び統合する

40年もの間、運用データと分析データの境界線が維持されてきたのは、ストレージの物理的な制約によるものでした。エージェントは、その境界線が生み出す遅延を許容できない最初のワークロードです。LTAPは、トランザクションと分析クエリの違いをなくそうとするものではありません。同じデータに対して両方を実行する際に生じていた負荷を取り除くものです。エージェント型ワークロードにこのパターンが本当に必要かどうかを評価するデータアーキテクトにとって、Jonathanが説明するテストは有用な指標となります。もしエージェントの次の意思決定が、データを保護し近くに留めておくように構築されたシステム上で、まだ確定途中のデータに依存している場合、従来の「パイプラインとコピー」モデルでは十分な速度を得られません。それこそが、LTAPが解決するために構築された具体的な課題です。

LTAPの詳細については、モノリスからLakebase、そしてLTAPへ：ストレージからデータベースを再考するをご覧ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事