本記事は「Apache Doris 5.0 Preview(1): A Unified Multimodal Lakehouse for Real-Time Analytics」（https://doris.apache.org/blog/apache-doris-5-multimodal-lakehouse-preview/ ）を日本語に翻訳・再構成したものです。
この記事のポイント
- コンセプト：統合検索（Unified Search）をオープンなデータレイクハウスまで拡張し、Doris をマルチモーダル分析の統合プラットフォームとして使えるようにします。
- オープンフォーマットとの読み書き統合：Apache Iceberg、Apache Paimon、Lance に対応します。
- マルチモーダルなデータ型：Variant、Vector、GEO、Blob。
- ユースケース：AI向けのリアルタイム・マルチモーダル分析（エージェントのコンテキスト構築、エンボディドAIなど）。
はじめに
これまで多くのデータ基盤は、構造化テーブルと SQL を中心に設計されてきました。データウェアハウスがバッチ処理と OLAP レポーティングを担う、という構成です。
AI はこの前提を変えつつあります。企業はテーブル、JSON、ログ、ドキュメント、画像、音声、動画、埋め込み（Embedding）、モデルの出力をまとめて扱う必要があり、データの利用者も人だけでなくアプリケーションや AI エージェントへと広がっています。
典型的なリクエストは、次のような処理が1つに混ざったものです。
- 構造化された条件によるフィルタリング
- 全文検索とベクトル検索
- 現在の業務ステータス、権限、過去の指標との JOIN
従来は、オブジェクトストレージ、データレイクハウス、検索エンジン、ベクトルデータベース、OLAP システム、アプリケーションコードにこの処理を分散させていました。その結果、一貫性の確保、バージョンの整合、アクセス制御、結果のマージ（Result Fusion）をユーザー自身が担う必要がありました。
一方で、オープンフォーマット自体も、動的な属性、Blob、埋め込み、モデルの推論結果を扱えるように拡張されています。Iceberg は長期的な分析用ファクト、Paimon はリアルタイムに更新されるデータ、Lance は AI 用データセットをそれぞれ担います。
本記事では、構造化データ、半構造化データ、マルチモーダルデータをオープンフォーマットでまとめて保存する構成を「マルチモーダルレイクハウス」と呼びます。Doris 5.0 は、すべてのデータを1つのストレージに移すことを求めるのではなく、クエリと実行のレイヤーで統合することに注力しています。
図1：オープンフォーマットによるマルチモーダルレイクハウスの全体アーキテクチャ。Iceberg、Paimon、Lance、Fluss がそれぞれ異なる種類のオープンデータ資産を保持し、Doris は各フォーマットのセマンティクスを理解したうえで、ハイブリッド検索、ソース横断の JOIN、MPP OLAP、リアルタイムサービング、アクセス制御を1つのパイプラインで結び付けます。
提供時期について（原文公開時点の情報）
Iceberg、Paimon、Lance 向けの機能は Doris 4.2 のリリースブランチに含まれており、9月末の正式リリースが予定されていました。Doris 5.0 全体の取り組みはまだプレビュー段階です。
4.x から 5.0 へ：統合検索をオープンレイクハウスへ
Doris 4.x はすでに、内部テーブルに対して統合 SQL、全文検索、ベクトル検索、リアルタイム更新を提供しています。一方、Iceberg や Paimon に対しては、主に構造化クエリのサポートにとどまっていました。
Doris 5.0 はこれらの機能をオープンレイクハウスへ拡張します。具体的には、統合パイプラインでの Variant の読み書き、Paimon と Lance に対するネイティブな全文検索・ベクトル検索、そしてリアルタイムデータと履歴データを横断してクエリできる新しい Fluss Catalog です。
図2：4.x から 5.0 への機能の進化。Doris 5.0 は Variant の読み書きやネイティブなベクトル検索などにより統合クエリをオープンレイクハウスへ拡張し、Fluss のリアルタイムデータと Paimon の履歴データを合わせたクエリにも対応します。
5.0 で提供予定の主な機能は以下のとおりです。
| 対象 | 5.0 での主な機能 |
|---|---|
| Iceberg | 成熟した読み書き、タイムトラベル、行レベル更新、ライフサイクル管理をベースに、Iceberg V3 の Variant データの読み書きを追加（通常（plain）レイアウトと shredded レイアウトの両方） |
| Paimon | 読み取り専用からフル読み書きへ。INSERT、INSERT OVERWRITE、UPDATE、DELETE、MERGE、DDL、Variant、全文インデックス、ベクトルインデックスに対応 |
| Lance | マルチモーダル AI 向けのネイティブな読み取りと検索。Catalog 対応、並列スキャン、カラムプルーニング、述語プッシュダウン、ベクトル検索・全文検索、ベクトルインデックス管理 |
| Fluss | 新しい Fluss Catalog。ログテーブルと主キーテーブルに対応し、Union Read により Fluss のリアルタイムデータと Paimon に階層化された履歴データを組み合わせて読み取り |
| Doris の統合実行 | 内部テーブル、オープンレイクテーブル、全文検索・ベクトル検索、ソース横断の JOIN、集計、ウィンドウ関数、権限フィルタリングを1つの SQL パイプラインで実行 |
複数システムから統合プラットフォームへ
複数システムを組み合わせた構成が難しいのは、同じエンティティでも、システムごとに更新時刻、バージョン、権限が異なりうるからです。たとえば、販売終了した商品、メンテナンス中の設備、取り下げられたドキュメントが古いベクトルインデックスに残ったままになり、それがエージェントに渡ってしまう、といったことが起こります。
クエリと実行のレイヤーで統合すると、役割分担が明確になります。
- オープンフォーマット：長期的なデータと資産を保存する
- Doris の内部テーブル：高同時実行・低レイテンシが求められるリアルタイムのファクトを保持する
- MPP エンジン：検索、フィルタリング、JOIN、分析を1つのクエリで処理する
- 同じレイヤーで：業務ステータスと権限のチェックを適用する
図3：マルチモーダルレイクハウスのデータアーキテクチャの進化。従来の複数システムの寄せ集めから、Doris による統合実行へ移行します。データは用途に合ったオープンフォーマットに置いたまま、Doris がクエリ、計算、サービングを担います。
OLAP：候補の検索から業務上の結論へ
ベクトル検索や全文検索は「候補」を見つけてくれますが、業務上の答えを出すには JOIN、集計、ウィンドウ関数、多次元でのランキングが必要です。
- 画像による商品検索では、在庫、地域ごとの販売可否、価格、コンバージョン、返品を考慮する必要があります。
- 設備の故障診断では、機種、ファームウェア、センサー指標、修理結果を比較する必要があります。
Doris は内部テーブルやオープンレイクテーブルに対する検索結果を、そのまま MPP OLAP のパイプラインに渡せます。これにより「似ている」結果を、「現時点で有効で、コンプライアンスを満たし、実行可能な」結論へと変換できます。
Variant・全文検索・ベクトル検索：異なる種類の根拠を1つの SQL で
OCR の出力、キャプション、ラベル、ツール呼び出しのパラメータ、評価結果など、モデルが生成するデータはモデルのバージョンとともに変化するため、固定スキーマのワイドテーブルにはなじみません。
それぞれの役割は次のとおりです。
- Variant：柔軟な半構造化データを保存する
- 全文検索：正確なキーワードやルールのマッチングを担う
- ベクトル検索：セマンティックな想起（リコール）の範囲を広げる
- 構造化条件：時間、ステータス、権限、範囲を絞り込む
Doris 5.0 では、オープンレイクテーブル内の Variant データ、全文インデックス、ベクトルインデックスを、別のインデックスシステムにデータをコピーすることなく、1つの SQL 文でクエリできるようになる予定です。
Physical AI：単一レコードから Episode 全体へ
自動運転、ロボティクス、産業機器は、「観測 → 判断 → 行動 → フィードバック」という連続したストリームを生み出します。ここでの分析の基本単位は Episode になります。Episode には、時間、空間、デバイスの状態、モデルのバージョン、業務上の結果が含まれます。
たとえば、ロボットアームが把持に失敗した1回の事象には、RGB-D 画像、3D ポーズ、関節・トルクのデータ、軌跡、制御コマンド、モデルの出力、デバイスログ、仕分け結果などが含まれます。
オープンフォーマットを使えば、チームはこれらのデータを長期にわたって保持・共有できます。Doris はこれらの根拠を Episode 単位でまとめ、インタラクティブなクエリとして扱います。
- 時間、デバイス、ステータスでフィルタリングする
- 全文検索とベクトル検索で類似した状況を探す
- モデルのバージョンや業務上の結果と JOIN し、失敗率、リトライ率、タスク所要時間を比較する
図4：Doris は複数センサーの根拠、モデルのコンテキスト、業務上の結果を、再利用可能なデータのフィードバックループとしてまとめます。
Agentic AI：リアルタイム分析でモデルと業務コンテキストをつなぐ
LLM は一般的な知識は理解していますが、企業の「現在の状態」は知りません。最新のデータにアクセスできなければ、注文がキャンセルされたか、在庫が足りているか、設備がオンラインか、顧客がまだ権限を持っているか、異常が急増しているか、といったことを判断できません。
エージェントにとっての課題は、SQL を生成することだけではありません。新鮮で、信頼でき、説明可能で、権限ルールに準拠したデータコンテキストを、継続的に供給する必要があります。
リアルタイム書き込み：業務の変化をそのままオープンレイクハウスへ
Doris の Iceberg 連携は、クエリだけでなく効率的な書き込みへと進化しています。INSERT、INSERT OVERWRITE、CTAS、行レベル更新はすでに利用可能です。Doris 5.0 では同等の書き込み機能を Paimon にも追加し、さらに Iceberg と Paimon の両方に Variant の書き込みを追加します。
ユーザーは統合 SQL で構造化データや Variant データをオープンテーブルに直接書き込めます。Doris の内部テーブルに一度ステージングしたり、別途同期パイプラインを構築したりする必要はありません。業務イベント、ツール呼び出しのパラメータ、変化し続けるモデルの結果を、オープンなデータ資産として保存できます。
実行パイプラインでは、Doris の BE が分散並列実行でデータファイルを生成し、FE がスナップショットとアトミックなコミットの調整、冪等なリトライ、障害時のクリーンアップを担います。効率的な書き込み、コミットの一貫性、スキーマ進化を共通の実装でカバーするため、アプリケーション側でオープンテーブルのトランザクションを組み立てる必要はありません。
リアルタイム分析：最新のオープンデータからエージェントのコンテキストを構築
Iceberg や Paimon に書き込まれた注文、設備の状態、行動イベント、モデル由来の結果は、複数の計算エンジンで共有できます。Doris は最新データを直接クエリし、内部テーブルのリアルタイムなファクトと組み合わせ、テーブル横断の JOIN と権限フィルタリングを適用して、エージェント向けに新鮮で検証可能なコンテキストを構築します。
さらに鮮度要件の厳しいイベントストリームに対しては、新しい Fluss Catalog が Union Read を使い、Fluss のリアルタイムな増分と Paimon に階層化された履歴を1つのテーブルとして見せます。これにより、エージェントのコンテキストには全履歴と直前に起きた変化の両方が含まれます。
図5：ワークロードごとに選んだオープンフォーマットの上に構築する、Agentic AI のリアルタイムなフィードバックループ。Doris はユーザーが選んだ Iceberg または Paimon に対して読み書きと Variant を、Lance に対して読み取りとマルチモーダル検索を提供し、統合 SQL と MPP OLAP でエージェントのコンテキストを構築します。
Doris によるマルチモーダルレイクハウスのユースケース
シナリオ1：カスタマーサービス・エージェントのリアルタイムな意思決定
- データ配置：ナレッジドキュメント、商品画像、類似障害のサンプルは Lance に保存します。注文、サポートチケット、過去の対応データは Iceberg と Paimon に置きます。最新の在庫、保証、顧客ステータスは Doris の内部テーブルにロードします。
- クエリの流れ：顧客の質問がエージェントに届くと、Doris がセマンティック検索とキーワードマッチングを実行し、権限とステータスでフィルタリングしたうえで、修理成功率や在庫データと JOIN します。出力されるのは「最も似ているドキュメント」ではなく、その顧客が今すぐ実行できる解決策です。
シナリオ2：Physical AI 向けに価値の高い Episode を選別する
- データ配置：自動運転やロボティクスのチームは、動画、点群、埋め込みを Lance に保存します。変化し続けるモデルの出力やタスク結果は Variant データとして Paimon に書き込み、過去の評価結果は Iceberg に保持します。
- 問い：知りたいのは「どの Episode が似ているか」だけではなく、「どの Episode にアノテーション、学習、レビューのコストをかける価値があるか」です。
- クエリの流れ：フィルタリング後、確信度の高い異常は学習用・回帰テスト用のデータセットへ、根拠に矛盾がある Episode は人手によるレビューへ回します。モデルのバージョンごとに失敗率や介入率を集計すれば、新しい戦略が特定のシナリオで改善したかどうかがわかります。
シナリオ3：産業品質検査で「類似欠陥」から根本原因分析へ
- クエリの流れ：品質エンジニアが欠陥画像をアップロードすると、Doris は Lance から見た目の似たサンプルを検索し、Variant と全文検索のフィールドで欠陥の説明文をマッチングします。そのうえで、Paimon で継続的に更新される設備イベントや、Iceberg にあるロット、工程、修理の履歴と JOIN します。
- 得られる結果：欠陥が集中しているか、どの設備やロットが影響を受けているか、各モデルバージョンがその欠陥をどの程度正確に識別しているか、後続ロットで歩留まりが回復しているかを判断できます。類似画像検索を、クローズドループの品質分析へと発展させられます。
まとめ：データはオープンフォーマットに、検索と分析は Doris で
Doris は、統合検索とリアルタイム分析を内部テーブルから Iceberg、Paimon、Lance、Fluss 上のデータへと拡張していきます。データはオープンフォーマットに置いたままで、構造化データ、Variant、全文、ベクトルのデータを別々のシステムに分ける必要はありません。Doris はその上で統合された実行・サービングレイヤーを提供します。
- 統合 SQL で、Doris の内部テーブルと複数のオープンフォーマットを横断して扱う
- Variant、全文検索、ベクトル検索、構造化フィルタリングで、さまざまな形のデータをクエリする
- MPP OLAP で、検索結果を業務指標や意思決定に変える
- リアルタイム書き込みで、エージェントに欠けている最新の業務状態を供給する
- 統合された権限フィルタリングで、アプリケーションやエージェントには許可されたデータだけを見せる
今後、Doris 5.0 のシリーズ記事として、Iceberg、Paimon、Lance、Fluss それぞれの技術的な仕組み、性能ベンチマーク、代表的な導入シナリオが公開される予定です。
なお原文公開時点では、Iceberg、Paimon、Lance 向けのマルチモーダルレイクハウス機能は Doris 4.2 のリリースブランチにマージ済みで、9月末に正式リリース予定とされていました。Fluss 対応を含むその他の機能はメインブランチにあり、年末の Doris 5.0 で提供される計画です。