リリース 2.0.0

6か月間のコーディング、テスト、調整を経て、Apache Doris 2.0.0がプロダクション対応になったことを発表できることを大変嬉しく思います。プロジェクトに合計4100以上の最適化と修正を貢献した275名のコミッターの皆様に特別な感謝を申し上げます。

この新バージョンの特徴：

• データクエリの10倍高速化
• ログ分析と連携クエリ機能の強化
• より効率的なデータ書き込みと更新
• 改善されたマルチテナントとリソース分離メカニズム
• リソースの弾性スケーリングとストレージ・コンピュート分離の進歩
• より高いユーザビリティのためのエンタープライズ向け機能

ダウンロード: https://doris.apache.org/download

GitHubソースコード: https://github.com/apache/doris/releases/tag/2.0.0-rc04

10倍のパフォーマンス向上

SSB-FlatとTPC-Hベンチマークにおいて、Apache Doris 2.0.0はApache Dorisの初期バージョンと比較して10倍以上高速なクエリパフォーマンスを実現しました。

これは、よりスマートなクエリオプティマイザ、転置インデックス、並列実行モデル、および高並行ポイントクエリをサポートする一連の新機能の導入により実現されました。

よりスマートなクエリオプティマイザ

全く新しいクエリオプティマイザであるNereidsは、より豊富な統計ベースを持ち、Cascadesフレームワークを採用しています。ほとんどのクエリシナリオで自動調整が可能で、TPC-DSの99のSQLすべてをサポートするため、ユーザーは微調整やSQLの書き換えなしに高いパフォーマンスを期待できます。

TPC-Hテストでは、人の介入なしにNereidsが旧クエリオプティマイザを大幅に上回る性能を示しました。100名以上のユーザーがプロダクション環境でApache Doris 2.0.0を試し、その大多数がクエリ実行の大幅な高速化を報告しています。

Doc: https://doris.apache.org/docs/dev/query-acceleration/nereids/

NereidsはApache Doris 2.0.0でデフォルトで有効になっています：SET enable_nereids_planner=true。NereidsはAnalyzeコマンドを呼び出すことで統計データを収集します。

転置インデックス

Apache Doris 2.0.0では、曖昧キーワード検索、等価クエリ、範囲クエリをより良くサポートするために転置インデックスを導入しました。

あるスマートフォンメーカーがユーザー行動分析シナリオでApache Doris 2.0.0をテストしました。転置インデックスを有効にすることで、v2.0.0はクエリをミリ秒以内で完了し、クエリ並行レベルが上がっても安定したパフォーマンスを維持することができました。この場合、旧バージョンより5～90倍高速でした。

20倍高い並行処理能力

ECサイトの注文クエリや配送追跡などのシナリオでは、膨大な数のエンドユーザーが同時に特定のデータレコードを検索します。これらは高並行ポイントクエリと呼ばれ、システムに大きな負荷をかける可能性があります。従来のソリューションは、このようなクエリにApache HBaseなどのKey-Valueストアを導入し、負荷を軽減するためにRedisをキャッシュレイヤとして使用することでしたが、これは冗長なストレージとより高いメンテナンスコストを意味します。

Apache Dorisのような列指向DBMSでは、ポイントクエリのI/O使用量が乗算されます。よりすっきりした実行が必要です。そこで、列ストレージをベースに、行読み取り効率を向上させる行ストレージフォーマットと行キャッシュ、データ取得を高速化するショートサーキットプラン、フロントエンドオーバーヘッドを削減するプリペアドステートメントを追加しました。

これらの最適化により、Apache Doris 2.0は16コア64Gクラウドサーバー（4×1Tハードドライブ）でのYCSBにおいてノードあたり30,000 QPSの並行レベルを達成し、旧バージョンと比較して20倍の改善を示しました。これによりApache DorisはHBaseの高並行シナリオにおける良い代替手段となり、ユーザーは複雑な技術スタックがもたらす追加のメンテナンスコストと冗長なストレージに耐える必要がなくなります。

詳細はこちら: https://doris.apache.org/blog/High_concurrency

自己適応型並列実行モデル

Apache 2.0では、ハイブリッド分析ワークロードでの高効率と安定性のためにPipeline実行モデルを導入しました。このモデルでは、クエリの実行はデータによって駆動されます。すべてのクエリ実行プロセスでブロッキングオペレータがパイプラインに分割されます。パイプラインが実行スレッドを取得するかどうかは、関連するデータが準備できているかどうかに依存します。これにより非同期ブロッキング操作とより柔軟なシステムリソース管理が可能になります。また、システムがそれほど多くのスレッドを作成・破棄する必要がないため、CPU効率も向上します。

Doc: https://doris.apache.org/docs/dev/query-acceleration/pipeline-execution-engine/

Pipeline実行モデルの有効化方法

• Pipeline実行エンジンはApache Doris 2.0でデフォルトで有効になっています：Set enable_pipeline_engine = true。
• parallel_pipeline_task_numは、SQLクエリで並列実行されるパイプラインタスクの数を表します。デフォルト値は0で、これはApache Dorisが各バックエンドノードのCPU数の半分に並行レベルを自動的に設定することを意味します。ユーザーは必要に応じてこの値を変更できます。
• 旧バージョンからApache Doris 2.0にアップグレードする場合、parallel_pipeline_task_numの値を旧バージョンのparallel_fragment_exec_instance_numの値に設定することをお勧めします。

複数の分析ワークロードのための統合プラットフォーム

Apache Dorisは境界を押し広げ続けています。レポート用のOLAPエンジンとして始まり、現在はETL/ELTなどに対応するデータウェアハウスとなっています。バージョン2.0では、ログ分析とデータレイクハウス機能において進歩を遂げています。

10倍費用対効果の高いログ分析ソリューション

Apache Doris 2.0.0は半構造化データをネイティブサポートします。JSONとArrayに加えて、複合データ型であるMapもサポートします。Light Schema Changeに基づいてSchema Evolutionもサポートし、ビジネスの変化に応じてスキーマを調整できます。フィールドやインデックスの追加・削除、フィールドのデータ型の変更が可能です。転置インデックスと高性能テキスト分析アルゴリズムを導入することで、ログの全文検索と次元分析をより効率的に実行できます。より高速なデータ書き込みとクエリ速度、より低いストレージコストにより、業界内の一般的なログ分析ソリューションより10倍費用対効果が高くなります。

強化されたデータレイクハウス機能

Apache Doris 1.2では、異種ソースからのデータの自動マッピングと自動同期を可能にするMulti-カタログを導入しました。バージョン2.0.0では、サポートするデータソースのリストを拡張し、プロダクション環境でのユーザーのニーズに基づいてDorisを最適化しました。

Apache Doris 2.0.0は、Hive、Hudi、Iceberg、Paimon、MaxCompute、Elasticsearch、Trino、ClickHouse、そしてほぼすべてのオープンレイクハウスフォーマットを含む数十のデータソースをサポートします。Hudi Copy-on-WriteテーブルでのスナップショットクエリとHudi Merge-on-Readテーブルでの読み取り最適化クエリもサポートします。Apache Rangerを使用したHive カタログの認証をサポートし、ユーザーは既存の権限制御システムを再利用できます。さらに、任意のカタログにユーザー定義認証メソッドを有効にする拡張可能な認証プラグインをサポートします。

TPC-Hベンチマークテストでは、Apache Doris 2.0.0がHiveテーブルでのクエリにおいてPresto/Trinoより3～5倍高速であることが示されました。これは、この開発サイクルで完了した全方位の最適化（小ファイル読み取り、フラットテーブル読み取り、ローカルファイルキャッシュ、ORC/Parquetファイル読み取り、Compute Nodes、外部テーブルの情報収集）とApache Dorisの分散実行フレームワーク、ベクトル化実行エンジン、クエリオプティマイザによって実現されました。

これらすべてによりApache Doris 2.0.0はデータレイクハウスシナリオで優位性を持ちます。Dorisを使用すると、複数の上流データソースの増分または全体同期を一箇所で実行でき、他のクエリエンジンよりもはるかに高いデータクエリパフォーマンスを期待できます。処理されたデータはソースに書き戻したり、下流システムに提供したりできます。このようにして、Apache Dorisを統一データ分析ゲートウェイにすることができます。

効率的なデータ更新

データ更新はリアルタイム分析において重要です。ユーザーは常に最新のデータにアクセスでき、行や数列の更新、指定データのバッチ更新や削除、データパーティション全体の上書きなど、柔軟にデータを更新できることを求めているからです。

効率的なデータ更新は、データ分析における別の難題でした。Apache Hiveはパーティションレベルでの更新のみをサポートし、HudiとIcebergはMerge-on-ReadとCopy-on-Write実装により、リアルタイム更新ではなく低頻度バッチ更新により適しています。

データ更新に関して、Apache Doris 2.0.0は以下が可能です：

• より高速なデータ書き込み: オンライン決済プラットフォームでの負荷テストにおいて、20の並行データ書き込みタスク下で、Dorisは毎秒300,000レコードの書き込みスループットを達成し、10時間以上の連続書き込みプロセスを通じて安定性を維持しました。
• 部分列更新: DorisのdすバージョンはAggregate Keyモデルでreplace_if_not_nullによる部分列更新を実装していました。2.0.0では、Unique KeyモデルでPrtial Column アップデートを有効にします。これは、複数のソーステーブルからのデータを書き込み前にFlinkを使用して1つの出力ストリームに連結することなく、フラットテーブルに直接書き込めることを意味します。この方法は複雑な処理パイプラインと追加のリソース消費を回避します。更新が必要な列を単純に指定するだけです。
• 条件付き更新と削除: 単純なアップデートとDelete操作に加えて、Merge-on-Writeに基づいて複雑な条件付き更新と削除操作を実現します。

より高速、より安定、よりスマートなデータ書き込み

データ書き込み速度の向上

Apache Dorisのリアルタイム分析機能を強化する継続的な取り組みの一環として、バージョン2.0.0のエンドツーエンドリアルタイムデータ書き込み機能を改善しました。ベンチマークテストでは、さまざまな書き込み方法でより高いスループットが報告されました：

• Stream Load、TPC-H 144G lineitemテーブル、48バケットDuplicateテーブル、3重レプリカ書き込み: スループット100%向上
• Stream Load、TPC-H 144G lineitemテーブル、48バケットUnique Keyテーブル、3重レプリカ書き込み: スループット200%向上
• Insert Into Select、TPC-H 144G lineitemテーブル、48バケットDuplicateテーブル: スループット50%向上
• Insert Into Select、TPC-H 144G lineitemテーブル、48バケットUnique Keyテーブル: スループット150%向上

高並行データ書き込みでの安定性向上

システム不安定性の要因には、小ファイルマージ、書き込み増幅、それに伴うディスクI/OとCPUオーバーヘッドがよく含まれます。そのため、バージョン2.0.0でVertical CompactionとSegment Compactionを導入し、コンパクション中のOOMエラーを解消し、データ書き込み中の過度なセグメントファイル生成を回避しました。これらの改善により、Apache Dorisは以前使用していたメモリのわずか10%を使用しながら、50%高速にデータを書き込めるようになりました。

詳細はこちら: https://doris.apache.org/blog/Compaction

テーブルスキーマの自動同期

最新のFlink-Doris-Connectorにより、ユーザーは1つの簡単なステップでデータベース全体（MySQLやOracleなど）をApache Dorisに同期できます。テスト結果によると、1つの同期タスクで数千のテーブルのリアルタイム並行書き込みをサポートできます。Apache Dorisがプロセスを自動化したため、ユーザーはもはや複雑な同期手順を経る必要がありません。上流データスキーマの変更は自動的に捕捉され、シームレスにApache Dorisに動的更新されます。

詳細はこちら: https://doris.apache.org/blog/FDC

新しいマルチテナントリソース分離ソリューション

マルチテナントリソース分離の目的は、重い負荷の場合にリソースの横取りを回避することです。そのため、Apache Dorisの旧バージョンでは、Resource Groupを特徴とするハード分離プランを採用していました：同じDorisクラスタのBackendノードにタグが付けられ、同じタグのものがResource Groupを形成します。データがデータベースに取り込まれると、異なるデータレプリカが異なるResource Groupに書き込まれ、それぞれが異なるワークロードを担当します。例えば、データの読み取りと書き込みは異なるデータタブレットで実行され、読み書き分離を実現します。同様に、オンラインとオフラインビジネスを異なるResource Groupに配置することもできます。

これは効果的なソリューションですが、実際には一部のResource Groupが大きく占有される一方で、他は遊休状態になることがあります。リソースの空室率を減らすより柔軟な方法が欲しいのです。そこで、2.0.0でWorkload Groupリソースソフトリミットを導入しました。

アイデアは、ワークロードをグループに分けてCPUとメモリリソースの柔軟な管理を可能にすることです。Apache DorisはクエリをWorkload Groupと関連付け、バックエンドノードで単一クエリが使用できるCPUとメモリの割合を制限します。メモリソフトリミットはユーザーが設定・有効化できます。

クラスタリソース不足時、システムは最大メモリ消費クエリタスクを終了します；十分なクラスタリソースがある場合、Workload Groupが予想以上にリソースを使用すると、アイドルクラスタリソースがすべてのWorkload Group間で共有され、システムメモリを最大限に活用し、クエリの安定実行を保証します。リソース割り当てに関してWorkload Groupに優先順位を付けることも可能です。つまり、どのタスクに十分なリソースを割り当て、どれにそうしないかを決めることができます。

同時に、2.0.0でQuery Queueを導入しました。Workload Group作成時に、クエリキューの最大クエリ数を設定できます。その制限を超えるクエリは、キューで実行を待機します。これは重いワークロード下でのシステム負担を軽減するためです。

弾性スケーリングとストレージ・コンピュート分離

計算とストレージリソースに関して、ユーザーが求めるものは何でしょうか？

• 計算リソースの弾性スケーリング: ピーク時にリソースを迅速にスケールアップして効率を高め、オフピーク時にスケールダウンしてコストを削減する。
• より低いストレージコスト: 低コストストレージメディアを使用し、ストレージとコンピュートを分離する。
• ワークロードの分離: 異なるワークロードのコンピュートリソースを分離して横取りを回避する。
• データの統一管理: カタログとデータを1箇所で簡単に管理する。

ストレージとコンピュートを分離することは、リソースの弾性スケーリングを実現する方法ですが、ストレージ安定性の維持により多くの努力が必要で、これがOLAPサービスの安定性と継続性を決定します。ストレージ安定性を確保するため、キャッシュ管理、コンピュートリソース管理、ガベージコレクションなどのメカニズムを導入しました。

この点で、調査後にユーザーを3つのグループに分けています：

1. リソーススケーリングを必要としないユーザー
2. リソーススケーリング、低ストレージコスト、Apache Dorisからのワークロード分離を要求するユーザー
3. すでに安定した大規模ストレージシステムを持っており、効率的なリソーススケーリングのための高度なコンピュート・ストレージ分離アーキテクチャを要求するユーザー

Apache Doris 2.0は、最初の2つのタイプのユーザーのニーズに対応する2つのソリューションを提供します。

1. Compute nodes。バージョン2.0でステートレスコンピュートノードを導入しました。mixノードとは異なり、コンピュートノードはデータを保存せず、クラスタスケーリング中のデータタブレットのワークロードバランシングに関与しません。そのため、ピーク時にクラスタに迅速に参加し、コンピュート負荷を共有できます。さらに、データレイクハウス分析では、これらのノードがリモートストレージ（HDFS/S3）でのクエリを最初に実行するため、内部テーブルと外部テーブル間でリソース競合がありません。
   1. Doc: https://doris.apache.org/docs/dev/advanced/compute_node/
2. ホット・コールドデータ分離。ホット/コールドデータとは、頻繁に/めったにアクセスされないデータをそれぞれ指します。一般的に、コールドデータを低コストストレージに保存する方が理にかなっています。Apache Dorisの旧バージョンはテーブルパーティションのライフサイクル管理をサポート：ホットデータが冷却されると、SSDからHDDに移動されました。しかし、データはHDD上で複数レプリカで保存され、これはまだ無駄でした。現在、Apache Doris 2.0では、コールドデータをオブジェクトストレージに保存でき、これはさらに安価で単一コピーストレージが可能です。ストレージコストを70%削減し、ストレージに伴うコンピュートとネットワークオーバーヘッドを削減します。
   1. 詳細はこちら: https://doris.apache.org/blog/HCDS/

よりすっきりしたコンピュートとストレージの分離のため、VeloDBチームはCloud Compute-Storage-SeparationソリューションをApache Dorisプロジェクトに貢献予定です。そのパフォーマンスと安定性は、数百の企業のプロダクション環境でテストに合格しています。コードのマージは今年10月までに完了予定で、すべてのApache Dorisユーザーが9月に早期体験できる予定です。

強化されたユーザビリティ

Apache Doris 2.0.0は、エンタープライズ向け機能も特徴としています。

Kubernetesデプロイメントのサポート

Apache Dorisの旧バージョンはIPベースで通信するため、Kubernetesデプロイメントでの任意のホスト障害によるPOD IPドリフトはクラスタ利用不能を引き起こします。現在、バージョン2.0はFQDNをサポートします。これは障害したDorisノードが人の介入なしに自動回復できることを意味し、Kubernetesデプロイメントと弾性スケーリングの基盤を築きます。

クロスクラスタレプリケーション（CCR）のサポート

Apache Doris 2.0.0はクロスクラスタレプリケーション（CCR）をサポートします。ソースクラスタのデータベース/テーブルレベルでのデータ変更がターゲットクラスタに同期されます。増分データまたは全体データの複製を選択できます。

DDLの同期もサポートし、ソースクラスタで実行されたDDLステートメントもターゲットクラスタに自動複製されることを意味します。

DorisでCCRを設定・使用するのは簡単です。この機能を活用して、読み書き分離とマルチデータセンターレプリケーションを実装できます

この機能により、より高いデータ可用性、読み取り/書き込みワークロード分離、クロスデータセンターレプリケーションをより効率的に実現できます。

動作変更

• 1.2-ITSから2.0.0へのローリングアップグレード、2.0のプレビューバージョンから2.0.0への再起動アップグレードを使用；
• 新しいクエリオプティマイザ（Nereids）がデフォルトで有効：enable_nereids_planner=true；
• すべての非ベクトル化コードがシステムから削除されたため、enable_vectorized_engineパラメータは機能しなくなりました；
• 新しいパラメータenable_single_replica_compactionが追加されました；
• datev2、datetimev2、decimalv3がテーブル作成でのデフォルトデータ型；datav1、datetimev1、decimalv2はテーブル作成でサポートされません；
• decimalv3はJDBCとIceberg カタログのデフォルトデータ型；
• 新しいデータ型AGG_STATEが追加されました；
• clusterカラムがbackendテーブルから削除されました；
• BIツールとのより良い互換性のため、show create table時にdatev2とdatetimev2がdateとdatetimeとして表示されます；
• max_openfilesとswapsチェックがbackend起動スクリプトに追加され、不適切なシステム設定がbackend障害を引き起こす可能性があります；
• localhostでフロントエンドにアクセスする際のパスワードなしログインは許可されません；
• システムにMulti-カタログがある場合、デフォルトでinformation schemaをクエリする際に内部カタログのデータのみが表示されます；
• 式ツリーの深度に制限が課されました。デフォルト値は200です；
• array stringの戻り値の単一引用符が二重引用符に変更されました；
• DorisプロセスがDorisFEとDorisBEに名前変更されました。
• 2つの引数を持つAESとSM4関数の動作が変更されました。詳細は関連する関数ドキュメントを参照してください

2.0.0の旅の始まり

Apache Doris 2.0.0をプロダクション対応にするため、数百のエンタープライズユーザーにテストに参加していただき、より良いパフォーマンス、安定性、ユーザビリティのために最適化しました。次のフェーズでは、アジャイルリリース計画でユーザーニーズに応え続けます。8月下旬に2.0.1、9月に2.0.2のローンチを計画し、バグ修正と新機能追加を続けます。また、長らく要望されていたいくつかの機能をお届けするため、9月に2.1の早期バージョンリリースも計画しています。例えば、Doris 2.1では、Variantデータ型が半構造化データのスキーマフリー分析ニーズにより良く対応し、マルチテーブル マテリアライズドビューがデータスケジューリングと処理リンクを簡