DatabricksがHTAPを「LTAP」で再定義、イベントで示した「Agentic SoR」戦略

AI時代における「HTAP」の限界？　Databricksが掲げる「LTAP」のねらい

　今回、最も注目される発表の一つが、トランザクション処理（OLTP）と分析処理（OLAP）のデータ連携を合理化するための新アーキテクチャ「LTAP（Lake Transactional/Analytical Processing）」の発表だ。

　主に業務処理を担う行指向のデータベース（≒OLTP）と分析処理を担う列指向のデータベース（≒OLAP）をつなぐためには、CDC（Change Data Capture）やETLを用いたパイプラインを構築する必要がある。Databricksの共同創業者であるレイノルド・シン（Reynold Xin）氏は、この仕組みこそが脆弱だと指摘すると、「社内では、CDCは『Continuous Data Corruption（継続的なデータ破損）』の略だと冗談めかしている」と話す。

　LTAPは、オブジェクトストレージ上で稼働するサーバーレスPostgres「Lakebase」を基盤とする。Databricksが2025年に買収したNeonのサーバーレス技術をベースとするLakebaseのストレージ層は、分散合意のための“Paxosプロトコル”で書き込みを制御する「Safekeeper」と、読み取り用の「Page server」で構成されている。LTAPでは、これらストレージ層のCPUがアイドル状態になりやすい点に着目。データ書き込み時に、バックグラウンドの余剰CPUパワーを利用して、行指向から列指向（Delta LakeやApache Iceberg）へとフォーマットを自動変換するアプローチをとっている。

　シン氏は、このアーキテクチャの優位性を説明する際、単一エンジン内でOLTPとOLAPを処理する「HTAP」というカテゴリは、複雑化とパフォーマンスの妥協を招いたというマイケル・ストーンブレーカー氏の論文を引用し、「（業界の試みとしては）実質的な失敗に終わった」と主張した。もちろん、HTAPというアプローチ自体が完全に否定されたわけではない。リアルタイムの決済処理と不正検知を同時に実行するような、ミリ秒単位の同期が求められるミッションクリティカルな領域においては、HTAPは依然として機能している。シン氏が指摘したのは、あらゆるデータをデータレイクに集約してAIに活用しようとする、データプラットフォームの文脈において、従来的なHTAPによるアプローチは限界を迎えているという点だ。

　また、LTAPを支えるオープンフォーマットの統合については、懸念が残る読者もいるかもしれない。基調講演ではApache Icebergの生みの親（オリジナルクリエイター）であるライアン・ブルー（Ryan Blue）氏が登壇すると、Delta LakeとIcebergのオープンスタンダード化に向けたロードマップが示された。ロードマップでは、第一段階として「Iceberg v3」においてデータファイル層の共通化を実現し、次段階の「Iceberg v4」および「Delta 5」でメタデータ層（管理情報）の統合も成し遂げるという具体的なステップが明かされ、フォーマットの分断に終止符を打たんとする姿勢が強調された。

　これが実現すればフォーマットの分断は解消される。ただし、競合企業も関与するオープンソースコミュニティの主導権争いの中で、仕様策定や既存環境からの移行互換性の確保が予定通りに進行するかどうかには注視しておくべきだ。

超低遅延エンジンと自律運用の実効性に潜むリスク

　また、基調講演で注目されたもう一つの目玉が、データレイク上でのリアルタイム分析を高速化させる「Lakehouse//RT」の発表だ。

　まずは読み取り専用（参照系）のワークロード向けに提供されるLakehouse//RTには、新開発のクエリエンジン「Reyden」が搭載されている。最大の特徴は、AI（機械学習）がクエリ実行時に最も効率的なアルゴリズムを自律的に選択する点にある。基調講演のデモンストレーションでは、1,000人のユーザーが同時にダッシュボードを開き、計8,000個のクエリが秒間6,000回（QPS）という勢いで押し寄せる環境下において、最も遅い処理でもわずか37ミリ秒という応答速度を叩き出した。別のベンチマークでは、秒間12,000回という負荷にすら100ミリ秒未満で処理したという。

　さらに、データストリーミングでも、昨年オープンソース化された「Spark Realtime Mode」がSpark Declarative Pipelinesに統合された。これにより数十ミリ秒単位の低遅延処理が可能となり、「超低遅延のリアルタイム処理のため、データレイクとは別に専用システムを構築する」というアプローチを変えようとしている。

　もちろん、これらはあくまでもベンチマークの数値に基づいた評価となる。複雑なJOIN処理やデータに極端な偏りがある状態において、このレイテンシーがどこまで担保されるかは、実環境での詳細な検証を待たねばならない。

　一方、システム運用の領域では、データパイプラインの障害を検知し、自律的に修正を試みるエージェント「Genie ZeroOps」が発表された。注目すべきは、Lakebaseのブランチ機能（コピーオンライト〔CoW〕による差分管理）だ。これにより、本番環境のデータを複製した「シャロウクローン（Shallow Clone：隔離された検証環境）」を数秒で作成可能だ。AIは、この環境で実データを用いたコードの修正・検証を自動実行する。本番環境に影響を与えず、AIによる自律的なデバッグが完結し、エンジニアは最終的に提案されたプルリクエストを確認して承認するだけで済むため、運用負荷の削減が期待される。

　基調講演においてゴドシ氏は、AIのコストが膨らんでしまった実例として、米UberのCEOが「第1四半期だけで、1年分のAI予算を使い果たしてしまった」と語っていたエピソードを引き合いに出すと、「コスト管理を誤れば、企業は破産する」と強い危機感を示していた。たとえば、AIエージェントがバグを含む修正コードを生成し、エラー解決のために自動で試行錯誤のループを繰り返した場合、予期せぬコストのスパイクを引き起こす危険性は否定できない。自律的な修復プロセスにおいては、実行回数やトークン消費、コンピュートリソースの上限を厳格に制御できるポリシー設計が求められる。だからこそDatabricksは、今回これらを一元管理できるガバナンス機能をあわせて打ち出してきたといえるだろう