リリース 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倍高い同時実行能力

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

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

これらの最適化により、Apache Doris 2.0は16コア64GのクラウドサーバーにYCSBで4×1Tハードドライブを使用してノードあたり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のしいバージョンはAggregate Keyモデルでreplace_if_not_nullによる部分列更新を実装していました。2.0.0では、Unique Keyモデルでの部分列更新を可能にしました。これにより、複数のソーステーブルからのデータを、Flinkを使用して一つの出力ストリームに連結してから書き込む必要なく、フラットテーブルに直接書き込むことができます。この方法により、複雑な処理パイプラインと追加のリソース消費を回避できます。更新が必要な列を単純に指定するだけです。
• 条件付き更新と削除：単純なアップデートと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クラスターのバックエンドノードにタグが付けられ、同じタグのものが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作成時に、クエリキューの最大クエリ数を設定できます。その制限を超えるクエリはキューで実行を待機します。これは、高負荷下でのシステム負担を軽減するためです。

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

計算とストレージリソースに関して、ユーザーは何を望んでいるでしょうか？

• 計算リソースの弾力的スケーリング：ピーク時にリソースを迅速にスケールアップして効率を向上させ、ロー時間にスケールダウンしてコストを削減する。
• より低いストレージコスト：低コストのストレージメディアを使用し、ストレージと計算を分離する。
• ワークロードの分離：異なるワークロードの計算リソースを分離して先取りを回避する。
• データの統一管理：カタログとデータを一箇所で簡単に管理する。

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

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

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

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

1. Compute nodes。バージョン2.0でステートレスcompute nodesを導入しました。ミックスノードとは異なり、compute nodesはデータを保存せず、クラスタースケーリング時のデータタブレットのワークロードバランシングに関与しません。そのため、ピーク時にクラスターに迅速に参加して計算負荷を共有することができます。また、データレイクハウス分析では、これらのノードがリモートストレージ（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ベースで通信するため、POD IPドリフトを引き起こすKubernetesデプロイメントでのホスト障害はクラスターの利用不可につながります。現在、バージョン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チェックがバックエンド起動スクリプトに追加され、不適切なシステム設定によりバックエンド障害が発生する可能性があります；
• localhostでフロントエンドにアクセスする際、パスワードなしログインは許可されません；
• システムにMulti-カタログがある場合、information schemaをクエリする際にデフォルトで内部カタログのデータのみが表示されます；
• 式ツリーの深さに制限が課されました。デフォルト値は200；
• 配列文字列の戻り値の単一引用符が二重引用符に変更されました；
• DorisプロセスがDorisFEとDorisBEに名前変更されました。
• 2つの引数を持つAESとSM4関数の動作が変更されました。詳細情報については関連する関数ドキュメントを参照してください

2.0.0の旅を始める

Apache Doris 2.0.0をプロダクション対応にするために、数百のエンタープライズユーザーをテストに参加させ、より良いパフォーマンス、安定性、使いやすさのために最適化しました。次のフェーズでは、アジャイルリリース計画でユーザーニーズに応え続けます。8月下旬に2.0.1、9月に2.0.2のローンチを予定しており、バグ修正と新機能追加を続けます。また、いくつかの