リリース 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のクラウドサーバーで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の旧バージョンは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により、ユーザーは一つの簡単なステップで（MySQLやOracleなどの）データベース全体をApache Dorisに同期できます。テスト結果によると、一つの同期タスクで数千のテーブルのリアルタイム並行書き込みをサポートできます。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作成時に、クエリキューの最大クエリ数を設定できます。その制限を超えるクエリは、キューで実行を待機します。これは高負荷下でのシステム負担を軽減するためです。

エラスティックスケーリングとストレージ・コンピュート分離

コンピューテーションとストレージリソースに関して、ユーザーは何を望むでしょうか？

• コンピューテーションリソースのエラスティックスケーリング: ピーク時に効率を上げるためにリソースを迅速にスケールアップし、オフピーク時にコストを削減するためにスケールダウン
• より低いストレージコスト: 低コストストレージメディアの使用とストレージとコンピュートの分離
• ワークロードの分離: 異なるワークロードのコンピューテーションリソースを分離してプリエンプションを回避
• データの統合管理: カタログとデータを一箇所で簡単に管理

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

この点で、調査後にユーザーを3つのグループに分けました:

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

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

1. コンピュートノード。バージョン2.0でステートレスコンピュートノードを導入しました。ミックスノードとは異なり、コンピュートノードはデータを保存せず、クラスタースケーリング中のデータタブレットのワークロードバランシングに関与しません。そのため、ピーク時にクラスターに迅速に参加し、コンピューティング負荷を共有できます。さらに、データレイクハウス分析では、これらのノードがリモートストレージ（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が追加されました
• backendテーブルからclusterカラムが削除されました
• BIツールとのより良い互換性のため、show create table時にdatev2とdatetimev2がdateとdatetimeとして表示されます
• max_openfilesとswapsチェックがバックエンド起動スクリプトに追加されたため、不適切なシステム構成がバックエンド障害につながる可能性があります
• 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データタイプが半構造化データのスキーマフリー分析ニーズにより良くサービスを提供し、マルチテーブルマテリアライズドビューがデータスケジューリングと