リリース 3.0.0

Apache Doris 3.0のリリースをお知らせできることを嬉しく思います！

バージョン3.0より、Apache Dorisはクラスターデプロイメントにおいて、従来のコンピュート・ストレージ結合モードに加えて、コンピュート・ストレージ分離モードをサポートします。コンピュート層とストレージ層を分離するクラウドネイティブアーキテクチャにより、ユーザーは複数のコンピュートクラスター間でのクエリ負荷の物理的分離、および読み取りと書き込み負荷の分離を実現できます。さらに、ユーザーはオブジェクトストレージやHDFSなどの低コストの共有ストレージシステムを活用して、ストレージコストを大幅に削減できます。

バージョン3.0は、統合されたデータレイクとデータウェアハウスアーキテクチャに向けたApache Dorisの進化におけるマイルストーンです。このバージョンでは、データレイクへのデータ書き戻し機能が導入され、ユーザーはApache Doris内で複数のデータソースにわたってデータ分析、共有、処理、ストレージ操作を実行できます。非同期マテリアライズドビューなどの機能により、Apache Dorisは企業の統合データ処理エンジンとして機能し、ユーザーがレイク、ウェアハウス、データベース全体でデータをより適切に管理できるよう支援します。また、Apache Doris 3.0ではTrino Connectorが導入されています。これにより、ユーザーはより多くのデータソースに迅速に接続または適応でき、Dorisのハイパフォーマンスコンピュートエンジンを活用してTrinoよりも高速なクエリ結果を提供できます。

バージョン3.0では、ETLバッチ処理シナリオのサポートも強化され、insert into select、delete、updateなどの操作に対する明示的なトランザクションサポートが追加されています。クエリ実行の可観測性も向上しています。

パフォーマンス面では、バージョン3.0でクエリオプティマイザーのフレームワーク機能、インフラストラクチャ、ルールを改善しました。これにより、より複雑で多様なビジネスシナリオでのブラインドテストによって実証された最適化されたパフォーマンスを提供します。

適応的Runtime Filterコンピュート手法により、実行中にデータサイズに基づいてフィルターを正確に推定し、大容量データと高負荷下でのより良いパフォーマンスを提供します。さらに、非同期マテリアライズドビューは、クエリ加速とデータモデリングにおいてより安定かつユーザーフレンドリーになりました。

バージョン3.0の開発中に、200名を超えるコントリビューターがApache Dorisに対して約5,000件の最適化と修正を提出しました。VeloDB、Baidu、Meituan、ByteDance、Tencent、Alibaba、Kwai、Huawei、Tianyi Cloudなどの企業のコントリビューターがコミュニティと積極的に連携し、実際のユースケースからのテストケースを提供してApache Dorisの改善を支援しました。このリリースの開発、テスト、フィードバックプロセスに関わったすべてのコントリビューターに心からの感謝を表します。

• GitHub: https://github.com/apache/doris/releases

• Website: https://doris.apache.org/download

1. コンピュート・ストレージ分離モード

V3.0より、Apache Dorisはコンピュート・ストレージ分離モードをサポートします。ユーザーはクラスターデプロイメント時にこのモードとコンピュート・ストレージ結合モードから選択できます。

コンピュート・ストレージ分離モードでは、BEノードはデータを格納せず、代わりに共有ストレージ層（HDFSおよびオブジェクトストレージ）が共有データストレージ層として導入されます。コンピューティングリソースとストレージリソースを独立してスケールできるため、ユーザーに複数の利点をもたらします：

• ワークロード分離: 複数のコンピュートクラスターが同じデータを共有でき、ユーザーは別々のコンピュートクラスターを使用して異なるビジネスワークロードやオフライン負荷を分離できます。

• ストレージコスト削減: 全データセットはより費用対効果が高く高信頼性の共有ストレージに保存され、ホットデータのみがローカルにキャッシュされます。3つのデータレプリカを持つコンピュート・ストレージ結合モードと比較して、ストレージコストを最大90%削減できます。

• 弾性コンピューティングリソース: BEノードにデータが保存されないため、負荷要件に基づいてコンピューティングリソースを柔軟にスケールできます。ユーザーは個別のコンピュートクラスターをスケールイン/アウトしたり、コンピュートクラスターの数を増減できます。これによりコスト削減にもつながります。

• システム堅牢性の向上: データを共有ストレージに保存することで、Dorisは複数レプリカ整合性の複雑なロジックを処理する必要がなくなり、分散ストレージの複雑さを簡素化し、システム全体の堅牢性を向上させます。

• 柔軟なデータ共有とクローニング: コンピュート・ストレージ分離モードの柔軟性は、単一のDorisクラスターを超えて拡張されます。あるDorisクラスターのテーブルを別のDorisクラスターに簡単にクローニングでき、メタデータの複製のみで済みます。

1-1. 結合から分離へ

コンピュート・ストレージ結合モードでは、Apache Dorisアーキテクチャは2つの主要なプロセスタイプで構成されます：Frontend（FE）とBackend（BE）。FEは主にユーザーリクエストアクセス、クエリ解析・計画、メタデータ管理、ノード管理を担当します。BEはデータストレージとクエリプラン実行を担当します。

BEノードはMPP（Massively Parallel Processing）分散コンピューティングアーキテクチャを採用し、マルチレプリカ整合性プロトコルを活用して高いサービス可用性と高いデータ信頼性を確保します。

パブリッククラウド、プライベートクラウド、Kubernetesベースのコンテナプラットフォームを含む新興クラウドコンピューティングインフラストラクチャの成熟により、クラウドネイティブ機能の需要が高まっています。ますます多くのユーザーが、より多くの弾性を提供するためにApache Dorisとクラウドコンピューティングインフラストラクチャのより深い統合を求めています。

このニーズに対応するため、VeloDBチームはコンピュートとストレージを分離するApache Dorisのクラウドネイティブバージョンを設計・実装しました。これはVeloDB Cloudとして知られています。長期間にわたる数百の企業での広範囲な本番テストと改良を経て、このクラウドネイティブソリューションがApache Dorisコミュニティに貢献され、コンピュート・ストレージ分離モードのApache Doris 3.0として現れています。

コンピュート・ストレージ分離モードでは、Apache Dorisアーキテクチャは3つの層で構成されます：

• メタデータ層: データベースとテーブル情報、スキーマ、rowsetメタ、トランザクションなどのメタデータサービスを提供する新しいMeta Serviceモジュールが導入されました。Meta Serviceはステートレスで水平スケーラブルです。V3.0では、BEのすべてのメタデータとFEのメタデータの一部がMeta Serviceに移行されました。今後のバージョンで残りの移行を完了する予定です。
• コンピュート層: ステートレスBEノードはクエリプランを実行し、クエリパフォーマンスを向上させるためにデータとタブレットメタデータの一部をローカルにキャッシュします。複数のステートレスBEノードをコンピューティングリソースプール（すなわちコンピュートクラスター）に編成でき、複数のコンピュートクラスターが同じデータとメタデータサービスを共有できます。コンピュートクラスターは必要に応じてノードを追加または削除することで弾性的にスケールできます。
• 共有ストレージ層: データは共有ストレージ層に永続化されます。現在HDFSのほか、S3、OSS、GCS、Azure Blob、COS、BOS、MinIOなどのS3プロトコル互換の様々なクラウドベースオブジェクトストレージシステムをサポートしています。

1-2 設計のハイライト

Apache Dorisのコンピュート・ストレージ分離モードの設計は、FEのインメモリメタデータモデルを共有メタデータサービスに変換することをハイライトしています。このアプローチはグローバルに一貫した状態ビューを提供し、任意のノードがFEを経由してパブリッシュする必要なく直接書き込みを送信できるようにします。書き込み操作中、データは共有ストレージに保存され、メタデータはメタデータサービスによって管理されます。これにより共有ストレージ内の小さなファイルの数を効果的に制御します。一方、個別のテーブルのリアルタイム書き込みパフォーマンスは、コンピュート・ストレージ結合モードとほぼ同等です。システムの全体的な書き込み容量は、単一のFEノードの処理能力によって制限されなくなります。

グローバルに一貫した状態ビューに基づいて、データガベージコレクションについては、正しさの証明がより容易で効率的なデータ削除の設計アプローチを採用しました。

具体的には、共有ストレージ内のデータが、共有メタデータサービスによって提供されるグローバルに一貫したビューに組み込まれます。データが生成されるたびに、それを独立した別々のトランザクションに結び付けます。同様に、メタデータ削除操作についても、独立した別々のトランザクションに結び付けます。このアプローチの目的は、削除と書き込み操作が同時に成功できないことを保証することです。ビューはどのデータを削除する必要があるかを記録し、非同期削除プロセスはトランザクション記録に基づいてデータの順方向削除を実行するだけで、逆方向ガベージコレクションの必要がありません。

FE内のタブレット関連メタデータが共有メタデータサービスに段階的に移行されると、Dorisクラスターのスケーラビリティは単一のFEノードのメモリ容量によって制約されなくなります。共有メタデータサービスと順方向データ削除技術に基づいて、データ共有や軽量クローニングなどの機能を便利に拡張できます。

1-3 代替ソリューションとの比較

業界におけるコンピュートとストレージ分離の別の設計は、データとBEノードメタデータを共有オブジェクトストレージまたはHDFSに保存することです。しかし、このアプローチは以下の問題をもたらします：

• リアルタイム書き込みをサポートできない: データ書き込み中、データはパーティショニングとバケッティングルールに基づいてタブレットにマッピングされ、セグメントファイルとrowsetメタデータが生成されます。書き込みプロセス中、FEを通じて2フェーズコミット（Publish）が実行されます。BEノードがPublishリクエストを受信すると、rowsetを可視に設定します。Publish操作は失敗してはいけません。rowsetメタデータが共有ストレージに保存される場合、リアルタイム書き込みプロセス中の小さなファイルデータの合計は実際のデータファイルサイズの3倍になります - データファイルの1つのレプリカ、rowsetメタデータの1つ、Publish中のrowsetメタデータ変更のもう1つ。Publish操作は単一のFEノードによって駆動されるため、単一のテーブルまたはシステム全体の書き込み容量がFEノードの能力によって制限されます。

  

  Apache Doris 3.0のリアルタイムデータ書き込みパフォーマンスを上記の解決策と比較しました。同じコンピューティングリソースを使用して、各500行の10,000データファイルを書き込む500の同時タスクと、各20,000行の250データファイルを書き込む50の同時タスクをシミュレートしました。

  結果は、50の同時タスクで、Apache Dorisのコンピュート・ストレージ結合モードと分離モードの両方のマイクロバッチ書き込みパフォーマンスがほぼ同一である一方、業界ソリューションはApache Dorisより100倍遅れていることを示しました。

  500の同時タスクでは、コンピュート・ストレージ分離モードでのApache Dorisのパフォーマンスはわずかに低下を示しましたが、それでも業界ソリューションに対して11倍の優位性を維持しました。公平なテストを確保するため、Apache DorisはGroup Commit機能を有効にしませんでした（業界ソリューションには不足）。Group Commitを有効にすると、リアルタイム書き込みパフォーマンスがさらに向上します。

  

  さらに、業界ソリューションはリアルタイムデータインジェストに関して安定性とコストの問題にも直面します：

  • 安定性の懸念: 大量の小さなファイルが共有ストレージ、特にHDFSに圧力をかけ、安定性リスクを生じさせる可能性があります。

  • 高いオブジェクトストレージリクエストコスト: 一部のパブリッククラウドオブジェクトストレージサービスは、Get操作と比較してPutおよびDelete操作に10倍多く課金します。大量の小さなファイルは、ストレージコストを超える可能性さえあるオブジェクトストレージリクエストコストの大幅な増加につながります。

• 限定的なスケーラビリティ: コンピュート・ストレージ分離モデルのユースケースは、より大きなデータストレージサイズを扱うことが多いため、FE（Frontend）メタデータが完全にインメモリであるため、タブレット数が特定の高いレベル（例：数千万）に達すると、FEのメモリ圧迫がシステム全体の書き込みスループットを制限するボトルネックになる可能性があります。

• 潜在的なデータ削除ロジックの問題: コンピュート・ストレージ分離アーキテクチャでは、データは単一レプリカで保存されます。したがって、データ削除ロジックはシステムの信頼性にとって重要です。差分を比較してクロスシステムデータ削除を行う従来のアプローチは困難になる場合があります。書き込みプロセス中、削除と書き込みが同時に成功することを完全に回避する方法がなく、データ損失につながる可能性があります。さらに、ストレージシステムに異常が発生した場合、差分計算に使用される入力が間違っている可能性があり、意図しないデータ削除につながる可能性があります。

• データ共有と軽量クローニング: 分離ストレージ・コンピュートアーキテクチャの柔軟性により、将来のデータ共有と軽量データクローニングが可能になり、企業のデータ管理負担を軽減できます。しかし、各クラスターが別々のFEを持つ場合、クラスター間でのデータクローニング後、どのデータがもはや参照されておらず安全に削除できるかを正確に判断することが困難になります。クラスター間参照の計算は意図しないデータ削除につながりやすいためです。

FEの完全インメモリメタデータモデルを共有メタデータサービスに進化させることで、Apache Doris 3.0は上記のすべての問題を回避します。

1-4 クエリパフォーマンス比較

コンピュート・ストレージ分離モードでは、データをリモート共有ストレージシステムから読み取る必要があり、主要なボトルネックはコンピュート・ストレージ結合モードでのディスクI/Oではなく、ネットワーク帯域幅になります。

データアクセスを高速化するため、Apache Dorisはローカルディスクに基づく高速キャッシュメカニズムを実装し、LRU（Least Recently Used）とTTL（Time-To-Live）の2つのキャッシュ管理ポリシーを提供します。新しくインポートされたデータは最新データへの初回アクセスを高速化するため非同期でキャッシュに書き込まれます。クエリに必要なデータがキャッシュにない場合、システムはリモートストレージからメモリにデータを読み取り、後続のクエリのため同期的にキャッシュに書き込みます。

複数のコンピュートクラスターを含むユースケースでは、Apache Dorisはキャッシュ事前ウォーミング機能を提供します。新しいコンピュートクラスターが確立される際、ユーザーは特定のデータ（テーブルやパーティションなど）を事前ウォーミングしてクエリ効率をさらに向上させることを選択できます。

この文脈で、TPC-DS 1TBテストデータセットを使用して、コンピュート・ストレージ結合モードと分離モードの両方で異なるキャッシュ戦略によるパフォーマンステストを実施しました。結果は以下のようにまとめられます：

• キャッシュが完全にヒットする場合（すなわち、クエリに必要なすべてのデータがキャッシュに読み込まれている）、コンピュート・ストレージ分離モードのクエリパフォーマンスは、コンピュート・ストレージ結合モードと同等です。

• キャッシュが部分的にヒットする場合（すなわち、テスト前にキャッシュがクリアされ、テスト中にデータが徐々にキャッシュに読み込まれ、パフォーマンスが継続的に向上する）、コンピュート・ストレージ分離モードのクエリパフォーマンスは、コンピュート・ストレージ結合モードより約10%低くなります。このテストシナリオは実際のユースケースに最も類似しています。

• キャッシュが完全にミスする場合（すなわち、各SQL実行前にキャッシュがクリアされ、極端なケースをシミュレート）、パフォーマンス損失は約35%です。それでも、コンピュート・ストレージ分離モードのApache Dorisは代替ソリューションよりもはるかに高いパフォーマンスを提供します。

1-5 書き込み速度比較

書き込みパフォーマンスに関して、同じコンピューティングリソース下で2つのテストケース：バッチインポートと高同時リアルタイムインポートをシミュレートしました。コンピュート・ストレージ結合モードとコンピュート・ストレージ分離モードの書き込みパフォーマンス比較は以下のとおりです：

• バッチインポート: 1TB TPC-Hと1TB TPC-DSテストデータセットをインポートする際、単一レプリカ構成下でコンピュート・ストレージ分離モードの書き込みパフォーマンスは、コンピュート・ストレージ結合モードよりもそれぞれ20.05%と27.98%高くなりました。バッチインポート中、セグメントファイルサイズは一般的に数十から数百MBの範囲です。コンピュート・ストレージ分離モードでは、セグメントファイルがより小さなファイルに分割され、オブジェクトストレージに同時アップロードされるため、ローカルディスクへの書き込みと比較してより高いスループットをもたらす可能性があります。実際のデプロイメントでは、コンピュート・ストレージ結合モードは通常3つのレプリカを使用するため、コンピュート・ストレージ分離モードの書き込み速度の優位性はさらに顕著になります。

• 高同時リアルタイムインポート: 「代替ソリューションとの比較」セクションで説明したとおりです。

1-6 本番環境のためのヒント

• パフォーマンス: リアルタイムデータ分析において、ユーザーはキャッシュのTTL（Time-To-Live）を指定し、新しく取り込まれたデータをキャッシュに書き込むことで、コンピュート・ストレージ結合モードと同等のクエリパフォーマンスを達成できます。クエリジッターを防ぐため、ユーザーはデータの使用頻度に基づいて、コンパクションやスキーマ変更などのバックグラウンドタスクによって生成されたデータをキャッシュできます。

• ワークロード分離: ユーザーは複数のコンピュートクラスターを使用して、異なるビジネスの物理的リソース分離を実現できます。単一のコンピュートクラスター内でのワークロード分離については、ユーザーはWorkload Groupメカニズムを利用して、異なるクエリのリソースを制限・分離できます。

1-7 注意事項

• Apache Doris 3.0は、コンピュート・ストレージ結合モードとコンピュート・ストレージ分離モードの共存をサポートしていません。ユーザーはクラスターデプロイメント中にいずれかを指定する必要があります。

• ユーザーがコンピュート・ストレージ結合モードを必要とする場合、デプロイメントとアップグレードについてはドキュメントに従ってください。迅速なデプロイメントとクラスターアップグレードにはDoris Managerの使用を推奨します。ただし、コンピュート・ストレージ分離モードはまだDoris Managerのデプロイメントとアップグレードをサポートしていません。今後のバージョンでより良いサポートのため継続的に改良を行います。

• 現在、Apache DorisはV2.1からV3.0のコンピュート・ストレージ分離モードへのインプレースアップグレードをサポートしていません。そのような目的には、ユーザーはコンピュート・ストレージ分離クラスターをデプロイした後、ツールを使用してデータ移行を実行する必要があります。将来、CCR（Change Data Capture）機能を通じてサービス中断なしの移行をサポートする予定です。

備考

ドキュメントを参照： https://doris.apache.org/docs/3.0/compute-storage-decoupled/overview/

2. データレイクハウス

Apache Dorisはリアルタイムデータウェアハウスとして位置付けられていますが、それ以上の存在です。以前のバージョンでは、従来のデータウェアハウス機能の境界を一貫して押し広げ、統合データレイクハウスに向けて進歩してきました。バージョン3.0はこの旅路におけるマイルストーンであり、レイクハウスアーキテクチャにおける機能が完全に成熟しています。統合レイクハウスは境界のないデータとレイクハウス融合によって識別されると考えています：

境界のないデータ: Apache Dorisは統合クエリ処理エンジンとして機能し、異なるシステム間のデータ障壁を打破します。データウェアハウス、データレイク、データストリーム、ローカルデータファイルを含むすべてのデータソースに対して一貫した超高速分析体験を提供します。

• レイクハウスクエリ加速: データをApache Dorisに移行する必要なく、ユーザーはDorisの効率的なクエリエンジンを活用してIceberg、Hudi、Paimon、Hiveなどのオフラインデータウェアハウスのデータレイクに保存されたデータを直接クエリでき、クエリ分析を加速します。

• フェデレーテッド分析: catalogとストレージプラグインを拡張することで、Apache Dorisはフェデレーテッド分析機能を強化し、ユーザーが単一のストレージシステムにデータを物理的に集約することなく、複数の異種データソースにわたって統合分析を実行できます。これにより外部テーブルクエリと内部・外部テーブル間のフェデレーテッドジョインが可能になり、データサイロを打破して

  BEGIN;
  DELETE FROM table WHERE date >= "2024-07-01" AND date <= "2024-07-31";
  INSERT INTO table SELECT * FROM stage_table;
  COMMIT;

• 失敗したタスクの処理を簡素化: 例えば、単一のトランザクション内で2つの insert into select 操作が実行される場合、いずれかの操作が失敗しても、直接再試行することができます。

  BEGIN WITH LABEL label_etl_1;
  INSERT INTO table1 SELECT * FROM stage_table1;
  INSERT INTO table SELECT * FROM stage_table;
  COMMIT;

Note

doc を参照: https://doris.apache.org/docs/3.0/data-operate/transaction/ 現在、Cross-Cluster Replication (CCR) では明示的なトランザクション同期はサポートされていません。

4-2. 可観測性の向上

• リアルタイムprofile取得: 以前のバージョンでは、実行プランやデータの問題により、一部の複雑なクエリでは計算要件が高くなる可能性があり、開発者はクエリの完了後にのみパフォーマンス分析用のクエリprofileにアクセスできました。これにより、本番環境の安定性を保証するためにクエリ実行の問題を迅速に特定することが困難でした。現在、リアルタイムprofileを取得する機能により、V3.0では、クエリの実行中にクエリの実行を監視することができます。また、各ETLジョブの進捗をより良く監視することも可能になります。

• backend_active_tasks システムテーブル: backend_active_tasks システムテーブルは、各BEノード上の各クエリのリアルタイムリソース消費情報を提供します。ユーザーはSQLを使用してこのシステムテーブルを分析し、各クエリのリソース使用量を取得できるため、大きなクエリや異常なワークロードを特定するのに役立ちます。

5. 非同期マテリアライズドビュー

V3.0では、非同期マテリアライズドビューはより高速で安定しています。また、クエリ高速化とデータモデリングシナリオにおいてよりユーザーフレンドリーになっています。透過的リライトのロジックを再構築し、その機能を拡張することで、2倍高速になりました。

5-1 更新

• パーティション別のマテリアライズドビューの増分更新とマテリアライズドビュー上でのパーティションロールアップをサポートし、異なる粒度での更新を可能にします。

• ネストしたマテリアライズドビューをサポートし、データモデリングシナリオで有用です。

• 非同期マテリアライズドビューでのインデックス作成とソートキー指定をサポートし、マテリアライズドビューがヒットした後のクエリパフォーマンスを向上させます。

• マテリアライズドビューの原子的置換をサポートし、マテリアライズドビューを利用可能な状態に保ちながらマテリアライズドビュー定義SQLの修正を可能にする、マテリアライズドビューDDLの使いやすさの向上。

• マテリアライズドビューで非決定的関数をサポートし、日次マテリアライズドビュー作成により良く対応します。

• トリガーベースのマテリアライズドビュー更新をサポートし、ネストしたマテリアライズドビューによるデータモデリングでのデータ一貫性を保証します。

• パーティション化されたマテリアライズドビューを構築するためのより広範囲のSQLパターンをサポートし、増分更新機能をより多くのユースケースで利用可能にします。

5-2 更新安定性

• V3.0では、マテリアライズドビュー構築用のWorkload Groupの指定をサポートしています。これは、マテリアライズドビュー構築プロセスで使用されるリソースを制限し、進行中のクエリに十分なリソースが利用可能な状態を維持するためです。

5-3 透過的リライト

• 派生Joinを含む、より多くのJoinタイプの透過的リライトをサポート。クエリとマテリアライズドビューの間でJoinタイプに不一致がある場合でも、マテリアライズドビューがクエリに必要なすべてのデータを提供できる限り、追加の述語で補償することで透過的リライトを実行できます。

• ロールアップのためのより多くの集約関数と、GROUPING SETS、ROLLUP、CUBEなどの多次元集約のリライトをサポート；マテリアライズドビューに集約が含まれていない場合の集約を持つクエリのリライトをサポートし、Join操作と式計算を簡素化します。

• ネストしたマテリアライズドビューの透過的リライトをサポートし、複雑なクエリでより高いパフォーマンスを実現します。

• 部分的に無効なパーティション化されたマテリアライズドビューについて、V3.0では、データ補完のためのベーステーブルのUnion Allをサポートし、パーティション化されたマテリアライズドビューの適用範囲を拡大します。

5-4 透過的リライトパフォーマンス

• 透過的リライトパフォーマンスを向上させるための継続的な最適化が行われ、バージョン2.1.0と比較して2倍の速度を達成しています。

Note

doc を参照:

https://doris.apache.org/docs/3.0/query/view-materialized-view/query-async-materialized-view

https://doris.apache.org/docs/3.0/query/view-materialized-view/async-materialized-view/

6. パフォーマンス向上

6-1 よりスマートなオプティマイザー

V3.0では、クエリオプティマイザーがフレームワーク機能、分散プランサポート、オプティマイザーインフラストラクチャ、ルール拡張の面で強化されています。より複雑で多様なビジネスシナリオに対してより良い最適化機能を提供し、複雑なSQLに対してより高いブラインドテストパフォーマンスを提供します：

• プラン列挙機能の改善: プラン列挙のキー構造であるMemoが再構築され正規化されました。これにより、Cascadesフレームワークのプラン列挙の効率と、より良いプランを生成する可能性が向上しています。さらに、古いバージョンでのJoin Reorderプロセス中の不完全な列プルーニングを修正し、Join演算子の不要なオーバーヘッドを削減することで、関連するシナリオでの実行パフォーマンスを向上させています。

• 分散プランサポートの改善: 分散クエリプランが強化され、集約、join、ウィンドウ関数操作が中間計算結果のデータ特性をより知的に識別し、無効なデータ再分散操作を回避できるようになりました。同時に、マルチレプリカ連続実行モードでの実行を最適化し、データキャッシュにより親和的にしました。

• オプティマイザーインフラストラクチャの改善: V3では、コストモデルと統計情報推定におけるいくつかの問題を修正しました。コストモデルの修正により、実行エンジンの進化により適応し、以前のバージョンと比較して実行プランがより安定になりました。

• Runtime Filterプランサポートの強化: Join Runtime Filterをベースに、V3.0では、TopN演算子を含むユースケースでより良いパフォーマンスを達成するために、TopN Runtime Filterの機能を拡張しました。

• 最適化ルールライブラリの充実: ユーザーフィードバックと内部テスト結果に基づいて、Intersect Reorderなどの最適化ルールを導入し、オプティマイザーのルールセットを充実させました。

6-2 自己適応Runtime Filter

以前のバージョンでは、Runtime Filterの生成は統計情報に基づくユーザーによる手動設定に依存していました。しかし、特定のケースでの不正確な設定は、パフォーマンスの不安定性を引き起こす可能性がありました。

V3.0では、Dorisは自己適応Runtime Filter計算アプローチを実装しています。データサイズに基づいて高精度でランタイムでRuntime Filterを推定することができ、大量のデータとハイワークロードを持つユースケースでより良いパフォーマンスを可能にします。

6-3 関数パフォーマンス最適化

• V3.0では数十の関数のベクトル化実装を改善し、一般的に使用されるいくつかの関数で50%以上のパフォーマンス向上を実現しました。
• V3.0ではnullableデータ型の集約に対して広範囲な最適化も行い、30%のパフォーマンス向上を実現しました。

6-4 ブラインドテストパフォーマンス向上

V3.0とV2.1での私たちのブラインドテストでは、新バージョンがTPC-DSとTPC-Hベンチマークテストでそれぞれ7.3%と6.2%高速であることが示されました。

7. 新機能

7-1 Java UDTF

バージョン3.0では、Java UDTFのサポートが追加されました。主な操作は以下の通りです：

• UDTFの実装: UDFと同様に、UDTFではユーザーがevaluateメソッドを実装する必要があります。UDTF関数の戻り値はArrayデータ型でなければならないことに注意してください。

  public class UDTFStringTest {
      public ArrayList<String> evaluate(String value, String separator) {
          if (value == null || separator == null) {
              return null;
          } else {
              return new ArrayList<>(Arrays.asList(value.split(separator)));
          }
      }
  }

• UDTFの作成: デフォルトでは、対応する2つの関数が作成されます - java-utdfとjava-utdf_outerです。_outerサフィックスは、テーブル関数が0行の出力を生成する際に、NULLデータの単一行を追加します。

  CREATE TABLES FUNCTION java-utdf(string, string) RETURNS array<string> PROPERTIES (
      "file"="file:///pathTo/java-udaf.jar",
      "symbol"="org.apache.doris.udf.demo.UDTFStringTest",
      "always_nullable"="true",
      "type"="JAVA_UDF"
  );

備考

ドキュメントを参照: https://doris.apache.org/docs/3.0/query/udf/java-user-defined-function/#udtf-1

7-2 Generated column

Generated columnは、ユーザーが直接挿入や更新を行うのではなく、他のカラムの値から計算される特別なカラムです。式の結果を事前計算してデータベースに保存することをサポートしており、頻繁なクエリや複雑な計算が必要なシナリオに適しています。

データのインポートや更新時に、事前定義された式に基づいて結果が自動的に計算され、永続的に保存されます。このようにして、その後のクエリでは、システムは複雑な計算を実行することなく、これらの計算済み結果に直接アクセスでき、クエリ性能を向上させます。

Generated columnはV3.0以降でサポートされています。テーブル作成時に、カラムをGenerated columnとして指定できます。Generated columnは、データ書き込み時に定義された式に基づいて値を自動計算します。Generated columnではより複雑な式を定義できますが、値を明示的に書き込んだり設定したりすることはできません。

備考

ドキュメントを参照: https://doris.apache.org/docs/3.0/sql-manual/sql-statements/Data-Definition-Statements/Create/CREATE-TABLE-AND-GENERATED-COLUMN/

8. 機能改善

8-1. Materialized view

Materialized viewの選択ロジックをリファクタリングし、ルールベースオプティマイザー（RBO）からコストベースオプティマイザー（CBO）に移行しました。これにより、選択ロジックが非同期Materialized viewのものと一致します。この機能はデフォルトで有効になっています。問題が発生した場合は、set global enable_sync_mv_cost_based_rewrite = falseを使用してRBOモードに戻すことができます。

8-2. Routine Load

以前のバージョンでは、Routine Load機能にいくつかの使いやすさの課題がありました。例えば、BEノード間でのタスクスケジューリングの不均衡、タスクスケジューリングの遅延、複雑な設定要件（最適化のために複数のFEとBE設定を変更する必要性）、全体的な安定性の不足（再起動やアップグレードでRoutine Loadジョブが頻繁に停止し、再開するために手動でのユーザー介入が必要）などです。

これらの問題に対処するため、Routine Load機能に対して広範囲な最適化を行いました：

• リソーススケジューリング: スケジューリングのバランスを改善し、タスクがBEノード間でより均等に分散されるようにしました。修復不可能なエラーが発生したジョブは、無駄なスケジューリング試行でリソースを浪費しないよう、迅速に停止されます。また、スケジューリングプロセスの適時性を改善し、Routine Loadのインポート性能を向上させました。

• パラメータ設定: ほとんどの環境でユーザーは最適化のためにFEとBE設定を変更する必要がなくなりました。クラスターの負荷が増加した際にタスクが絶えず再試行することを防ぐため、タイムアウトパラメータを持つ自動調整メカニズムを導入しました。

• 安定性: FEフェイルオーバー、BEローリングアップグレード、Kafkaクラスターの異常など、様々な例外的シナリオにおけるDorisの堅牢性を向上させ、継続的で安定した動作を保証しました。Auto Resumeメカニズムも最適化し、障害修復後にRoutine Loadが自動的に動作を再開できるようにし、手動でのユーザー介入の必要性を削減しました。

9. 動作変更

• cpu_resource_limitは今後サポートされなくなり、すべてのタイプのリソース分離はWorkload Groupsを通じて実装されます。

• Apache Doris 3.0以降のバージョンではJDK 17を使用してください。推奨バージョンはjdk-17.0.10_linux-x64_bin.tar.gzです。

Apache Doris 3.0を今すぐお試しください！

バージョン3.0の正式リリース前に、Apache Dorisのコンピュート・ストレージ分離モードは、数百の企業の本番環境でほぼ2年間にわたる広範囲なテストと最適化を経ました。多くの大手テクノロジー企業の貢献者がコミュニティと協力し、実際のビジネスニーズに基づく多数のテストケースを提供しました。これにより、バージョン3.0の使いやすさと安定性が厳密に検証されました。

コンピュート・ストレージ分離が必要なユーザーには、バージョン3.0をダウンロードして直接体験することを強く推奨します。

今後、すべてのユーザーにより安定したバージョン体験を提供するため、リリースのイテレーションサイクルを加速していきます。ぜひApache Dorisコミュニティにご参加いただき、コア開発者と直接交流してください。

クレジット

このバージョンの開発、テスト、フィードバック提供に参加された以下の貢献者の皆様に特別な感謝を申し上げます：

@133tosakarin、@390008457、@924060929、@AcKing-Sam、@AshinGau、@BePPPower、@BiteTheDDDDt、@ByteYue、@CSTGluigi、@CalvinKirs、@Ceng23333、@DarvenDuan、@DongLiang-0、@Doris-Extras、@Dragonliu2018、@Emor-nj、@FreeOnePlus、@Gabriel39、@GoGoWen、@HappenLee、@HowardQin、@Hyman-zhao、@INNOCENT-BOY、@JNSimba、@JackDrogon、@Jibing-Li、@KassieZ、@Lchangliang、@LemonLiTree、@LiBinfeng-01、@LompleZ、@M1saka2003、@Mryange、@Nitin-Kashyap、@On-Work-Song、@SWJTU-ZhangLei、@StarryVerse、@TangSiyang2001、@Tech-Circle-48、@Thearas、@Vallishp、@WinkerDu、@XieJiann、@XuJianxu、@XuPengfei-1020、@Yukang-Lian、@Yulei-Yang、@Z-SWEI、@ZhongJinHacker、@adonis0147、@airborne12、@allenhooo、@amorynan、@bingquanzhao、@biohazard4321、@bobhan1、@caiconghui、@cambyzju、@caoliang-web、@catpineapple、@cjj2010、@csun5285、@dataroaring、@deardeng、@dongsilun、@dutyu、@echo-hhj、@eldenmoon、@elvestar、@englefly、@feelshana、@feifeifeimoon、@feiniaofeiafei、@felixwluo、@freemandealer、@gavinchou、@ghkang98、@gnehil、@hechao-ustc、@hello-stephen、@httpshirley、@hubgeter、@hust-hhb、@iszhangpch、@iwanttobepowerful、@ixzc、@jacktengg、@jackwener、@jeffreys-cat、@kaijchen、@kaka11chen、@kindred77、@koarz、@kobe6th、@kylinmac、@larshelge、@liaoxin01、@lide-reed、@liugddx、@liujiwen-up、@liutang123、@lsy3993、@luwei16、@luzhijing、@lxliyou001、@mongo360、@morningman、@morrySnow、@mrhhsg、@my-vegetable-has-exploded、@mymeiyi、@nanfeng1999、@nextdreamblue、@pingchunzhang、@platoneko、@py023、@qidaye、@qzsee、@raboof、@rohitrs1983、@rotkang、@ryanzryu、@seawinde、@shoothzj、@shuke987、@sjyango、@smallhibiscus、@sollhui、@sollhui、@spaces-X、@stalary、@starocean999、@superdiaodiao、@suxiaogang223、@taptao、@vhwzx、@vinlee19、@w41ter、@wangbo、@wangshuo128、@whutpencil、@wsjz、@wuwenchi、@wyxxxcat、@xiaokang、@xiedeyantu、@xiedeyantu、@xingyingone、@xinyiZzz、@xy720、@xzj7019、@yagagagaga、@yiguolei、@yongjinhou、@ytwp、@yuanyuan8983、@yujun777、@yuxuan-luo、@zclllyybb、@zddr、@zfr9527、@zgxme、@zhangbutao、@zhangstar333、@zhannngchen、@zhiqiang-hhhh、@ziyanTOP、@zxealous、@zy-kkk、@zzzxl1993、@zzzzzzzs