Apache Doris 2.0 ベータ リリース: ブラインド テストのパフォーマンスが 10 倍向上し、より統合されたマルチシナリオ分析エクスペリエンスが実現

コミュニティの皆様、Apache Doris 2.0 ベータ版が 2023 年 7 月 3 日に正式にリリースされたことをお知らせできることを嬉しく思います。2.0 ベータ バージョンでは、255 人を超える寄稿者が Apache Doris の 3500 以上の最適化と修正を提出しました。ダウンロードして使用することを歓迎します。

ダウンロードリンク: https://dris.apache.org/download

GitHub ソースコード: https://github.com/apache/dris/tree/branch-2.0

今年初めに開催された年次ドリス サミットで、私たちは Apache Doris の 2023 年ロードマップを発表し、次のような新しいビジョンを提案しました。

ユーザーが Apache Doris に基づいてさまざまなシナリオでデータ分析サービスを構築し、オンラインおよびオフラインのビジネス ロード、高スループットの対話型分析、および高同時実行ポイント クエリをサポートし、一連のアーキテクチャを通じてレイクとウェアハウスの統合を実現できることを期待しています。データレイクと各種異種ストレージをベースとしたシームレスかつ超高速な分析サービスを提供するとともに、データ分析需要に応じたログ/テキストなどの半構造化データや非構造化マルチモーダルデータの一元管理・分析により、より多様なニーズに対応します。

これが、Apache Doris がユーザーにもたらすことを期待する価値です。ユーザーが複数のシステムを比較検討するのではなく、1 つのシステムだけでほとんどの問題を解決でき、複雑なテクノロジー スタックによってもたらされる開発、運用、保守、および使用コストを削減できます。生産性を最大化します。 。

大量のデータのリアルタイム分析に直面して、このビジョンを実現するには、特に実際のビジネス シナリオの真の要求に対処する際に、間違いなく多くの困難を克服する必要があります。

• ユーザークエリの安定性を確保しながら、アップストリームデータがリアルタイムかつ高頻度で書き込まれることを保証する方法。
• 上流のデータを更新し、テーブル構造を変更しながら、オンライン サービスの継続性を確保する方法。
• 構造化データおよび半構造化データの統合ストレージと効率的な分析を実現する方法。
• ポイント クエリ、レポート分析、アドホック クエリ、ETL/ELT などのさまざまなクエリ負荷を同時に処理し、負荷を確実に相互に分離するにはどうすればよいでしょうか?
• 複雑な SQL ステートメントの実行の高効率性、大規模なクエリの安定性、および実行プロセスの可観測性を確保するにはどうすればよいでしょうか?
• データレイクやさまざまな異種データソースをより便利に統合し、アクセスするにはどうすればよいでしょうか?
• データ ストレージとコンピューティング リソースのコストを大幅に削減しながら、高パフォーマンスのクエリを考慮するにはどうすればよいでしょうか?
• ……

「使いやすさはユーザーに任せ、複雑さは我々自身に任せる」という原則を堅持し、理論的基礎からエンジニアリング実装まで、理想的なビジネスシナリオから極端な異常事態まで、社内テストの合格から大規模なテストまで、上記の一連の課題を克服します。大規模な生産が可能であり、機能の開発、検証、継続的な反復と卓越性により多くの時間とエネルギーを費やします。半年近くの開発、テスト、安定性調整を経て、Apache Doris がついにバージョン 2.0 ベータ版の正式リリースを迎えたことは祝う価値があります。そして、このバージョンのリリースが成功したことで、私たちのビジョンは現実に一歩近づきました。

ブラインドテストのパフォーマンスが10倍以上向上！

新しいクエリ オプティマイザー

Apache Doris は高いパフォーマンスを常に追求しています。過去 1 年間の Clickbench や TPC-H などの公開テスト データセットでの優れたパフォーマンスは、実行レイヤーとオペレーターの最適化において業界をリードするパフォーマンスを達成していることを証明していますが、ベンチマークと実際のビジネス シナリオの間にはまだ一定の距離があります。 :

• ベンチマークは、実際のビジネス シナリオの抽象化、洗練、簡素化に重点が置かれており、実際のシナリオでは、テストではカバーできない、より複雑なクエリ ステートメントに直面することがよくあります。
• ベンチマーク クエリ ステートメントは列挙でき、的を絞った方法で調整できますが、実際のビジネス シナリオの調整はエンジニアの精神的コストに大きく依存しており、調整効率が比較的低いことが多く、エンジニアの人的資源を多大に消費します。

これに基づいて、最新のアーキテクチャ向けの新しいクエリ オプティマイザーの開発を開始し、Apache Doris 2.0 ベータ バージョンで完全に有効化しました。新しいクエリ オプティマイザーは、より高度な Cascades フレームワークを採用し、より豊富な統計情報を使用し、よりインテリジェントな適応チューニングを実現します。ほとんどのシナリオで、チューニングや SQL の書き換えを行わずに究極のクエリ パフォーマンスを達成できると同時に、より完全で複雑なクエリをサポートします。 SQL をサポートしており、TPC-DS の 99 個の SQL すべてを完全にサポートできます。

新しいクエリ オプティマイザーの実行パフォーマンスについてブラインド テストを実施しました。TPC-H 22 SQL を例にとると、新しいオプティマイザーは手動チューニングや SQL 書き換えを行わずに クエリに長時間かかり、ブラインド テストのパフォーマンスが向上しました。 10回！ただし、数十のバージョン 2.0 ユーザーの実際のビジネス シナリオでは、ほとんどの元の SQL の実行効率が大幅に向上し、手動チューニングの問題点が本当に解決されました。

参考ドキュメント：https://dris.apache.org/zh-CN/docs/dev/query-acceleration/nereids

有効にする方法: SET enable_nereids_planner=trueApache Doris 2.0 ベータ バージョンでは、新しいクエリ オプティマイザーがデフォルトで有効になっており、Analyze コマンドを呼び出すことによって統計情報が収集されます。

適応型パイプライン実行エンジン

以前は、Apache Doris の実行エンジンは従来の火山モデルに基づいて構築されていましたが、マルチマシンとマルチコアの同時実行機能をより有効に活用するには、実行同時実行数を手動で設定する必要がありました。 (たとえば、このパラメータをデフォルト値 1 から 8 または 16 に手動で設定しますparallel_fragment_exec_instance_num)、クエリ タスクが多数ある場合、一連の問題が発生します。

• 大規模なクエリと小規模なクエリでは異なるインスタンスの同時実行性を設定する必要があり、システムは適応的な調整を行うことができません。
• インスタンス オペレーターがスレッドを占有して実行をブロックし、多数のクエリ タスクによって実行スレッド プールがいっぱいになり、後続のリクエストに応答できなくなったり、論理デッドロックが発生したりすることがあります。
• インスタンス スレッド間のスケジューリングはシステムのスケジューリング メカニズムに依存し、スレッドの切り替えを繰り返すと追加のパフォーマンス オーバーヘッドが発生します。
• 異なる分析負荷が共存すると、インスタンス スレッド間で CPU リソースの競合が発生する可能性があり、これにより大小のクエリが発生し、異なるテナント間で相互に影響を与える可能性があります。

上記の問題に対応して、Apache Doris 2.0 ではクエリ実行エンジンとしてパイプライン実行モデルが導入されました。パイプライン実行エンジンでは、クエリの実行は制御フローを変更するデータによって駆動されます。各クエリ実行プロセスのブロック演算子は異なるパイプラインに分割されます。各パイプラインが実行をスケジュールする実行スレッドを取得できるかどうかは、事前データに依存します。が準備できているため、次のような効果が得られます。

• パイプライン実行モデルは、ブロッキング ロジックを通じて実行プランをパイプライン タスクに分解し、タイムシェアリング方式でパイプライン タスクをスレッド プールにスケジュールすることで、ブロッキング操作の非同期を実現し、インスタンスが単一のスレッドを長時間占有する問題を解決します。時間。
• さまざまなスケジューリング戦略を使用して、大規模なクエリと小規模なクエリおよびさまざまなテナント間での CPU リソースの割り当てを実現し、システム リソースをより柔軟に管理できます。
• パイプライン実行モデルでは、単一のデータ バケットにデータをプールするデータ プーリング テクノロジーも採用されており、これによりインスタンス数に対するバケット数の制限がなくなり、Apache Doris のマルチコア システムの利用能力が向上し、頻繁なスレッドの作成と破壊の問題。

パイプライン実行エンジンにより、混合負荷シナリオにおける Apache Doris のクエリ パフォーマンスと安定性がさらに向上します。

参考ドキュメント: https://dris.apache.org/zh-CN/docs/dev/query-acceleration/pipeline-execution-engine

有効にする方法:Set enable_pipeline_engine = trueこの機能は Apache Doris 2.0 でデフォルトで有効になり、BE はクエリ実行を実行するときにデフォルトで SQL 実行モデルをパイプライン実行モードに変更します。parallel_pipeline_task_numこれは、SQL クエリの同時パイプライン タスクの数を表します。Apache Doris はデフォルトで設定されています0。このとき、Apache Doris は各 BE の CPU コア数を自動的に認識し、同時実行数を CPU コア数の半分に設定します。ユーザーは実際の状況に応じて調整することもできます。古いバージョンからアップグレードするユーザーの場合は、このパラメータを古いバージョンの値に設定することをお勧めします。parallel_fragment_exec_instance_num

クエリの安定性がさらに向上

マルチサービスリソースの分離

ユーザー規模の急速な拡大に伴い、Apache Doris を使用して企業内に統合分析プラットフォームを構築するユーザーが増えています。Apache Doris は、より大規模なデータ処理と分析を行う必要がある一方で、Apache Doris は分析負荷というより多くの課題に対処することも求められており、異なる負荷をどのように実行できるようにするかが鍵となります。一つのシステムで安定して動作します。

Apache Doris バージョン 2.0 では、パイプライン実行エンジンに基づいたワークロード マネージャーが追加され、ワー​​クロードをグループで管理してメモリと CPU リソースをきめ細かく制御できます。

以前のバージョンでは、Apache Doris はリソース タグによるマルチテナント リソースの分離を実装し、ノード リソースの分割を通じて異なるサービス間の相互干渉を回避でき、ワークロード グループはより洗練されたリソース管理および制御方法を実装しました。 BE ノード上の 1 つのクエリの CPU およびメモリ リソースの割合、およびリソース グループのメモリ ソフト リミットを構成できます。クラスターのリソースが不足している場合、クラスターへの負荷を軽減するために、グループ内で最大のメモリを占有するいくつかのクエリ タスクが自動的に強制終了されます。クラスター リソースがアイドル状態の場合、ワークロード グループによって使用されるリソースが事前設定値を超えると、複数のワークロードがクラスターの利用可能なアイドル リソースを共有し、自動的にしきい値を超え、安定した実行を保証するためにシステム メモリを使用し続けます。クエリタスク。

create workload group if not exists etl_group
properties (
  "cpu_share"="10",
  "memory_limit"="30%",
  "max_concurrency" = "10",
  "max_queue_size" = "20",
  "queue_timeout" = "3000"
);

Show作成されたワークロード グループは、次のコマンドを使用して表示できます。

ジョブキューイング

同時に、ワークロード グループにクエリ キューイング機能も導入され、ワー​​クロード グループ作成時にクエリの最大数を設定でき、最大同時実行数を超えたクエリはキューに入れられて実行されます。

• max_concurrency現在のグループで許可されているクエリの最大数、および最大同時実行数を超えるクエリはキュー ロジックに入ります。
• max_queue_sizeキューの長さを問い合わせます。キューがいっぱいになると、新しいクエリは拒否されます。
• queue_timeoutキュー内のクエリの待機時間。クエリ待機時間が待機時間を超える場合、クエリは拒否されます。時間単位はミリ秒です。

参考ドキュメント: https://dris.apache.org/zh-CN/docs/dev/admin-manual/workload-group/

OOM に完全に別れを告げる

メモリが十分な場合、通常、メモリ管理はユーザーの影響を受けませんが、実際のシナリオでは、特にメモリ リソースの大量消費に直面して、メモリのパフォーマンスと安定性に課題をもたらすさまざまな極端なケースがよくあります。大規模なジョブでは、メモリ OOM によるクエリの失敗により、BE プロセスがダウンする可能性もあります。

そのため、メモリ データ構造を徐々に統一し、MemTracker をリファクタリングし、クエリ メモリのソフト リミットのサポートを開始し、プロセス メモリが制限を超えた後の GC メカニズムを導入し、同時実行性の高いクエリのパフォーマンスを最適化しました。バージョン 2.0 では、まったく新しいメモリ管理フレームワークを導入し、効果的なメモリ割り当て、統計、制御を通じて、ベンチマーク、ストレス テスト、および実際のユーザー ビジネス シナリオからのフィードバックにおけるメモリ ホットスポットと OOM による BE ダウンタイムの問題を基本的に排除しました。 OOM が発生した場合でも、通常はログに従ってメモリの場所を見つけて調整できるため、クラスタを安定した状態に復元できます。また、クエリとインポートのメモリ制限もより柔軟になるため、ユーザーはメモリの制限を行う必要がありません。メモリが十分な場合にメモリ使用量を認識します。

上記の一連の最適化により、Apache Doris バージョン 2.0 は、複雑な計算や大規模な ETL/ELT 操作を処理する際にメモリ リソースを効果的に制御できるようになり、システムの安定性がより高いレベルに向上しました。

詳細な紹介: https://mp.weixin.qq.com/s/Z5N-uZrFE3Qhn5zTyEDomQ

効率的かつ安定したデータ書き込み

リアルタイムデータ書き込み効率の向上

インポートパフォーマンスがさらに向上しました

リアルタイム分析に重点を置き、過去数バージョンでリアルタイム分析機能を継続的に強化してきましたが、エンドツーエンドのリアルタイムデータ書き込み機能は最適化の重要な方向性であり、Apache Doris 2.0ではさらに強化されました。この能力。スキップリストを使用しない Memtable、並列ダウンロード、単一コピーのインポートなどの最適化により、インポートのパフォーマンスが大幅に向上しました。

• Stream Load を使用して、TPC-H 144G ラインアイテム テーブルの元のデータのコピーを 3 つ作成し、それを 48 バケットを含む Duplicate テーブルにインポートすると、スループットが 100% 増加します。
• Stream Load を使用して、TPC-H 144G ラインアイテム テーブルの元のデータのコピーを 3 つ作成し、それを 48 バケットを含む一意のキー テーブルにインポートすると、スループットが 200% 向上します。
• insert into select を使用して、48 バケットの Duplicate テーブルを TPC-H 144G lineitem テーブルにインポートすると、スループットが 50% 増加します。
• Insert into select を使用して、TPC-H 144G ラインアイテム テーブルを 48 バケットを含む一意のキー テーブルにインポートすると、スループットが 150% 増加しました。

高頻度のデータ書き込みがより安定します

高頻度のデータ書き込みプロセスでは、小さなファイルのマージと書き込み増幅の問題、およびその後のディスク I/O と CPU リソースのオーバーヘッドがシステムの安定性を制限する鍵となるため、バージョン 2.0 では垂直方向を導入しました。コンパクションとセグメント コンパクションは、書き込みプロセスにおけるコンパクション メモリと多すぎるセグメント ファイルの問題を完全に解決するために使用されます。リソース消費量は 90% 削減され、速度は 50% 向上し、メモリ使用量はわずか 10% です。オリジナル。

詳細な紹介: https://mp.weixin.qq.com/s/BqiMXRJ2sh4jxKdJyEgM4A

データテーブル構造の自動同期

以前のバージョンではミリ秒レベルでのスキーマ変更を導入していましたが、Flink-Doris-Connector の最新バージョンでは、MySQL などのリレーショナル データベースから Apache Doris へのデータベース全体のワンクリック同期を実現しました。実際のテストでは、単一の同期タスクで数千のテーブルのリアルタイムの並列書き込みを実行できます。これにより、これまでの退屈で複雑な同期プロセスに完全に別れを告げ、上流のビジネス データベースのテーブル構造とデータ同期を実現できます。簡単なコマンドで実現できます。同時に、上流のデータ構造が変更された場合、スキーマの変更を自動的にキャプチャし、DDL を Doris に動的に同期して、ビジネスのシームレスな運用を保証します。

詳細な紹介: https://mp.weixin.qq.com/s/Ur4VpJtjByVL0qQNy_iQBw

主キーモデルは部分的な列の更新をサポートします

Apache Doris バージョン 1.2 では、Unique Key モデルの Merg-on-Write モードを導入しました。これにより、上流のデータが頻繁に書き込まれ更新される一方で、下流のビジネスの効率的かつ安定したクエリが保証され、リアルタイムの書き込みと非常に高速な統合が実現されます。クエリの数。バージョン 2.0 では、一意のキー モデルが完全に強化されました。機能面では、新たに部分列更新機能をサポートし、複数の上流ソーステーブルを同時に書き込む際に、事前に広いテーブルに加工する必要がなく、部分列更新による結合を直接完了できます。これにより、幅の広いテーブルの書き込みプロセスが大幅に簡素化されます。

性能面では、バージョン2.0ではUnique KeyモデルMerge-on-Writeの大容量データの書き込み性能と同時書き込み機能が大幅に強化され、バージョン1.2と比較して大容量データのインポート性能が50％以上向上しました。 、高同時インポートにより 50% 以上のパフォーマンス向上、効率的な同時処理メカニズムによりパブリッシュ タイムアウト (エラー -3115) 問題を完全に解決し、Doris 2.0 の効率的な圧縮メカニズムにより、パフォーマンスが 10 倍向上しました。 、バージョンが多すぎる (エラー 235) 問題は発生しません。これにより、より幅広いシナリオで Merge-on-Read を Merge-on-Write に置き換えることができるようになり、同時に部分的な列更新機能も使用して UPDATE および DELETE ステートメントの計算コストを削減し、全体的なパフォーマンスが向上します。約50％改善されました。

部分的な列更新 (ストリーム ロード) の使用例:

たとえば、テーブル構造は次のようになります

mysql> desc user_profile;
+------------------+-----------------+------+-------+---------+-------+
| Field           | Type           | Null | Key   | Default | Extra |
+------------------+-----------------+------+-------+---------+-------+
| id               | INT             | Yes | true | NULL   |       |
| name             | VARCHAR(10)     | Yes | false | NULL   | NONE |
| age             | INT             | Yes | false | NULL   | NONE |
| city             | VARCHAR(10)     | Yes | false | NULL   | NONE |
| balance         | DECIMALV3(9, 0) | Yes | false | NULL   | NONE |
| last_access_time | DATETIME       | Yes | false | NULL   | NONE |
+------------------+-----------------+------+-------+---------+-------+

過去 10 秒間に変更されたユーザーの残高とアクセス時間を一括更新したい場合、データは次の CSV ファイルに整理できます。

1,500,2023-07-03 12:00:01
3,23,2023-07-03 12:00:02
18,9999999,2023-07-03 12:00:03

次に、Stream Load を使用して Header を追加しpartial_columns:true、インポートする列名を指定して更新を完了します

curl --location-trusted -u root: -H "partial_columns:true" -H "column_separator:," -H 
"columns:id,balance,last_access_time" -T /tmp/test.csv http://127.0.0.1:48037/api/db1/user_profile/_stream_load

極めて高い柔軟性とストレージと計算の分離

これまで、Apache Doris は、使いやすさの点で多くの設計により、ユーザーがコンピューティングおよびストレージ リソースのコストを大幅に節約するのに役立ちました。そして、私たちは未来志向のクラウド ネイティブ アーキテクチャにおいて確実な一歩を踏み出しました。

コスト削減と効率向上の傾向から出発して、コンピューティング リソースとストレージ リソースに対するユーザーの要件は次のように要約できます。

• コンピューティング リソースの弾力性: ビジネス コンピューティングのピークに直面した場合は、リソースを迅速に拡張して効率を向上させることができ、コンピューティングが低下した場合には、コストを削減するためにリソースを迅速に縮小できます。
• ストレージ コストの削減: 大量のデータに直面しても、ストレージとコンピューティングを相互に干渉することなく個別に設定しながら、より安価なストレージ メディアを導入してコストを削減できます。
• ビジネス負荷の分離: 異なるビジネス負荷が独立したコンピューティング リソースを使用して、相互リソースのプリエンプションを回避できます。
• 統合されたデータ管理と制御: 統合されたカタログと統合されたデータ管理により、より便利なデータ分析が可能になります。

ストレージとコンピューティングの統合アーキテクチャには、弾力性要件が低いシナリオではシンプルで保守が容易であるという利点がありますが、弾力性要件が強いシナリオでは一定の制限があります。ストレージとコンピューティングの分離アーキテクチャの本質は、リソースの弾力性を解決するための技術的手段です。リソースの弾力性においては明らかな利点がありますが、ストレージにはより高い安定性要件があり、ストレージの安定性は OLAP の安定性にさらに影響します。では、キャッシュ管理、コンピューティングリソース管理、ガベージデータ収集などの一連の仕組みが導入されています。

Apache Doris コミュニティのユーザーとのコミュニケーションの中で、ストレージと計算の分離に対するユーザーのニーズは次の 3 つのカテゴリに分類できることがわかりました。

• 現時点では、シンプルで使いやすい統合ストレージとコンピューティングのアーキテクチャが選択されており、リソースの柔軟性は当面求められていません。
• 安定した大規模ストレージが不足しているため、Apache Doris に基づいた弾力性、負荷の分離、低コストが必要です。
• 安定した大規模ストレージでは、リソースの急速なスケーリングの問題を解決するために非常に柔軟なアーキテクチャが必要となるため、より徹底的なストレージとコンピューティングの分離アーキテクチャも必要になります。

最初の 2 つのタイプのユーザーのニーズを満たすために、Apache Doris 2.0 は、アップグレードと互換性のあるストレージとコンピューティングの分離ソリューションを提供します。

1 つ目のタイプはコンピューティング ノードです。バージョン 2.0 では、データ レイク分析に特別に使用されるステートレス コンピューティング ノード Compute Node を導入しました。ストレージとコンピューティングを統合した独自のハイブリッド ノードと比較して、コンピューティング ノードはデータを保存せず、クラスターの拡張または縮小時にデータの断片化の負荷分散を実行する必要がないため、データ レイク分析などの明らかなピークがあるシナリオで、柔軟かつ迅速に拡張できます。クラスターに参加してコンピューティング圧力を共有します。同時に、ユーザー データは HDFS/S3 などのリモート ストレージに保存されることが多いため、内部クエリと外部クエリの間でコンピューティング リソースが横取りされるのを避けるために、クエリ実行中にクエリ タスクが優先的にコンピューティング ノードにディスパッチされて実行されます。

参考ドキュメント: https://dris.apache.org/zh-CN/docs/dev/advanced/compute_node

2 番目のタイプは、ホットとコールドのレイヤリングです。ストレージに関しては、ホット データとコールド データではクエリ頻度や応答速度の要件が異なることが多いため、コールド データは通常、低コストのストレージ メディアに保存できます。過去のバージョンでは、Apache Doris はテーブル パーティションのライフサイクル管理をサポートし、バックグラウンド タスクを通じてホット データを SSD から HDD に自動的に冷却しましたが、HDD 上のデータは複数のコピーに保存されるため、コスト削減は最大化されません。コールド データ ストレージのコストを最適化する余地はたくさんあります。ホットおよびコールド データ階層化機能は、 Apache Doris 2.0 で導入されました。ホットおよびコールド データ階層化機能により、Apache Doris は、より低いストレージ コストでコールド データをオブジェクト ストレージにシンクできるようになります。同時に、コールド データをオブジェクト ストレージに保存する方法も可能になります。また、マルチコピーからシングルコピーに変更され、ストレージコストがさらに3分の1に削減され、同時にストレージによる追加のコンピューティングリソースコストやネットワークオーバーヘッドコストも削減されました。実際の試算によれば、保管コストが最大 70% 削減できます。

参考ドキュメント：https://dris.apache.org/zh-CN/docs/dev/advanced/cold_hot_separation

後続のコンピューティング ノードは、コールド データとストレージ ノードのデータのクエリをサポートし、アップグレードと互換性のあるストレージとコンピューティングの分離ソリューションを実現します。

3 番目のタイプのユーザーのニーズを満たすために、私たちは SelectDB Cloud ストレージとコンピューティングの分離ソリューションもコミュニティに貢献します。このソリューションは、数百社の本番環境でのパフォーマンス、機能の成熟度、システムの安定性のテストを経験しており、その後の機能統合の実際の進捗状況も同期させます。

10倍以上のコスト効率を実現したログ分析ソリューション

これまでのリアルタイム レポートやアドホックなどの典型的な OLAP シナリオから、ELT/ETL、ログの取得と分析などのより多くのビジネス シナリオまで、Apache Doris はアプリケーション シナリオの境界を常に拡張し、統合されたストレージと分析を提供します。ログ データはまさに私たちが行っていることです。バージョン 2.0 における重要な進歩です。

これまで、業界の一般的なログ ストレージと分析のアーキテクチャでは、高スループットのリアルタイム書き込み、低コストの大規模ストレージ、高性能のテキスト検索と分析を同時にバランスさせることが困難で、 1 つまたは複数の側面でトレードオフを行います。Apache Doris バージョン 2.0 では、文字列型の全文検索と、一般的な数値/日付型の同等および範囲検索を満たす新しい逆インデックスを導入し、同時に、逆インデックスのクエリ パフォーマンスをさらに最適化しました。ログデータ分析のシナリオ要件にさらに適合し、大規模データの書き込みと低コストのストレージにおけるこれまでの利点と組み合わせることで、よりコスト効率の高いログ分析ソリューションを実現します。

同じハードウェア構成とデータセットのテストパフォーマンスでは、ElasticSearch と比較して、Apache Doris はログデータの書き込み速度で 4 倍の向上、ストレージ容量の 80% 削減、クエリパフォーマンスの 2 倍の向上を達成しました。 Apache Doris 2.0 によって導入されたホットおよびコールドと組み合わせると、データ階層化機能により、全体的なコスト パフォーマンスが 10 倍以上向上します。

ログ分析シナリオの最適化に加えて、複雑なデータ型に関して、新しいデータ型 Map/Struct を追加しました。これには、上記の型の効率的な書き込み、保存、分析機能のサポート、および型間の相互ネストのサポートが含まれます。マルチモーダルなデータ分析のサポートをさらに強化します。

詳細な紹介: https://mp.weixin.qq.com/s/WJXKyudW8CJPqlUiAro_KQ

より包括的で高性能なデータレイク分析機能

Apache Doris バージョン 1.2 では、メタデータの自動マッピングや複数の異種データソースの同期をサポートし、データレイクのシームレスな接続を実現するマルチカタログ機能をリリースしました。データ読み取り、実行エンジン、クエリ オプティマイザーにおける多くの最適化に依存しており、標準的なテスト セット シナリオでは、レイク データに対する Apache Doris のクエリ パフォーマンスは、Presto/Trino のクエリ パフォーマンスよりも 3 ～ 5 倍高くなります。

バージョン 2.0 では、データ レイク分析機能をさらに強化し、より多くのデータ ソースをサポートするだけでなく、ユーザーの実際の運用環境に合わせて多くの最適化を行いました バージョン 1.2 と比較して、実際のワークロード条件で使用できるようになりました パフォーマンスが大幅に向上しました。

さらなるデータソースのサポート

• Hudi Copy-on-Write テーブルのスナップショット クエリと Merge-on-Read テーブルの読み取り最適化クエリをサポートし、後で Incremental Query と Time Trival もサポートする予定です。参考ドキュメント：https://dris.apache.org/zh-CN/docs/dev/lakehouse/multi-catalog/hudi
• JDBC カタログは、Oceanbase のサポートを新たに追加し、現在、MySQL、PostgreSQL、Oracle、SQLServer、Doris、Clickhouse、SAP HANA、Trino/Presto、Oceanbase を含む 10 近くのリレーショナル データベースをサポートしています。参考ドキュメント：https://dris.apache.org/zh-CN/docs/dev/lakehouse/multi-catalog/jdbc

データ許可制御

• Apache Range を介した Hive カタログの認証をサポートしており、ユーザーの既存の権限システムとシームレスに接続できます。同時に、任意のカタログにカスタム認証方法を実装するための拡張可能な認証プラグインもサポートします。参考ドキュメント：https://dris.apache.org/zh-CN/docs/dev/lakehouse/multi-catalog/hive

パフォーマンスがさらに最適化され、最大で数十倍の向上

• 多数の小さなファイルのシナリオと広いテーブルのシナリオの読み取りパフォーマンスを最適化しました。小さなファイルのフルロード、小さな IO のマージ、データの事前読み取りなどのテクノロジーにより、リモート ストレージの読み取りオーバーヘッドが大幅に削減され、そのようなシナリオではクエリのパフォーマンスが最大数十倍向上します。
• ORC/Parquet ファイルの読み取りパフォーマンスが最適化され、バージョン 1.2 と比較してクエリ パフォーマンスが 2 倍になりました。

• レイク上のデータのローカル ファイル キャッシュをサポートします。ローカル ディスクは、HDFS やオブジェクト ストレージなどのリモート ストレージ システム上のデータをキャッシュするために使用でき、同じデータにアクセスするクエリはキャッシュを通じて高速化できます。ローカル ファイル キャッシュにヒットした場合、Apache Doris を介してレイク上のデータをクエリするパフォーマンスは、Apache Doris の内部テーブルのパフォーマンスと同等にすることができ、この機能により、レイク上のホット データのクエリ パフォーマンスが大幅に向上します。参考ドキュメント：https://dris.apache.org/zh-CN/docs/dev/lakehouse/filecache
• 外観に関する統計収集をサポートします。Apache Doris 内部テーブルと同様に、ユーザーは Analyze ステートメントを通じて指定された外部テーブルの統計情報を分析および収集できます。新しい Nereids クエリ オプティマイザーと組み合わせることで、複雑な SQL のクエリ プランをより正確かつインテリジェントに最適化できます。TPC-H 標準テスト データ セットを例にとると、SQL を手動で書き直すことなく、最適なクエリ プランとより優れたパフォーマンスを得ることができます。参考ドキュメント：https://dris.apache.org/zh-CN/docs/dev/lakehouse/multi-catalog/
• JDBC カタログのデータ ライトバック パフォーマンスを最適化しました。PrepareStmt とバッチ モードにより、ユーザーが INSERT INTO コマンドと JDBC カタログを通じて MySQL、Oracle、およびその他のリレーショナル データベースにデータを書き戻すパフォーマンスが数十倍向上します。

大量の同時データ サービスのサポート

複雑な SQL や大規模な ETL 操作とは異なり、銀行取引伝票番号クエリ、保険代理店ポリシー クエリ、電子商取引履歴注文クエリ、特急運送状番号クエリなどのデータ サービス シナリオでは、多数のクエリが発生します。第一線のビジネス担当者や C エンド ユーザーは、主キー ID に基づいてデータの行全体を取得する必要があります。以前は、このようなニーズには、ポイント クエリを処理するための Apache HBase や Redis などの KV システムの導入が必要になることがよくありました。高い同時実行性によって引き起こされるシステムの負荷を共有するためのキャッシュ レイヤーとして使用します。

列指向ストレージ エンジン上に構築された Apache Doris の場合、このようなポイント クエリは数百列幅のテーブルでのランダム読み取り IO を増幅し、実行エンジンはそのような単純な SQL の解析と配布にも大きなメリットをもたらします。より効率的かつ簡潔な実行方法が必要です。したがって、新しいバージョンでは、新しい行と列のハイブリッド ストレージと行レベルのキャッシュを導入し、一度にデータ行全体を読み取る効率を高め、ディスク アクセス数を大幅に削減しました。同時に、ポイント クエリのショート パス最適化が導入され、実行エンジンがスキップされます。また、高速で効率的な読み取りパスを直接使用して必要なデータを取得し、プリペアド ステートメントを再利用して SQL 解析を実行することで FE オーバーヘッドを削減します。

上記の一連の最適化により、Apache Doris 2.0 バージョンでは同時実行性が桁違いに向上しました。標準 YCSB ベンチマーク テストでは、16 コア 64G メモリと 4*1T ハードディスク仕様を備えた単一のクラウド サーバーが、単一ノード 30,000 QPS の同時パフォーマンスを達成しました。これは、以前のバージョンのポイント クエリ同時実行数の 20 倍以上です。上記の機能に基づいて、Apache Doris は、同時実行性の高いデータ サービス シナリオのニーズをより適切に満たし、そのようなシナリオで HBase の機能を置き換え、複雑なテクノロジ スタックによって発生するメンテナンス コストとデータの冗長ストレージを削減できます。

参考ドキュメント：https://dris.apache.org/zh-CN/docs/dev/query-acceleration/hight-concurrent-point-query

詳細な紹介: https://mp.weixin.qq.com/s/Ow77-kFMWXFxugFXjOPHhg

CCR クラスタ間データ同期

複数のクラスタ間でデータを同期したいというユーザーのニーズを満たすためには、従来はバックアップ/リストアコマンドを使用してデータを定期的にバックアップおよびリストアする必要があり、操作が複雑で、データ同期の遅延が大きく、中程度の遅延が発生していました。保管が必要でした。複数のクラスタ内のデータベース テーブルの自動同期に対するユーザーのニーズを満たすために、バージョン 2.0 ベータでは、ソース クラスタのデータ変更をターゲット クラスタに同期できる CCR クラスタ間データ同期機能が追加されました。ライブラリ/テーブル レベルでオンライン サービスを向上させます。 データの可用性と、読み取り/書き込み負荷の分離とマルチルーム バックアップの実装を改善します。

Kubernetes コンテナ化されたデプロイメントのサポート

以前は、Apache Doris は IP 通信に基づいていました。K8s 環境にデプロイする場合、ホスト障害による Pod IP ドリフトにより、クラスターが使用できなくなります。バージョン 2.0 では、FQDN をサポートしているため、Apache Doris は IP 通信なしで実装できます。ノードの自己修復機能により、K8s 環境の展開や柔軟な拡張や縮小にうまく対応できます。

参考ドキュメント：https://dris.apache.org/zh-CN/docs/dev/install/k8s-deploy/

その他のアップグレードに関する考慮事項

• 1.2-lts は 2.0-beta にロールでき、2.0-alpha はダウンタイムを含めて 2.0-beta にアップグレードできます。
• クエリ オプティマイザー スイッチはデフォルトで有効になっています。
• ベクトル化されていないコードはシステムから削除されたため、パラメータenable_vectorized_engineは無効になります。
• 新しいパラメータenable_single_replica_compaction;
• デフォルトでは、datev2、datetimev2、および decmalv3 はテーブルの作成に使用されますが、datev1、datetimev1、および decimalv2 はテーブルの作成ではサポートされていません。
• Decimalv3 は、JDBC および Iceberg Catalog でデフォルトで使用されます。
• 日付タイプ AGG_STATE が追加されました。
• バックエンドテーブルからクラスター列を削除します。
• BI ツールとの互換性を高めるため、show create table が表示されるときに、datev2 と datetimev2 が日付と日時として表示されます。
• BE 起動スクリプトに max_openfiles とスワップ チェックを追加したため、システム構成が不当である場合、BE が起動に失敗する可能性があります。
• ローカルホスト上の FE にアクセスする場合、パスワードなしでログインすることは禁止されています。
• システムにマルチカタログがある場合、クエリ情報スキーマのデータはデフォルトで内部カタログのデータのみを表示します。
• 式ツリーの深さを制限します。デフォルトは 200 です。
• 配列文字列の戻り値の一重引用符が二重引用符になります。
• Doris のプロセス名を DorisFE および DorisBE に変更します。

2.0 の旅に乗り出しましょう

Apache Doris 2.0-alpha バージョンのリリースから 1 か月半が経過しましたが、この間、コア機能の開発を加速する一方で、Apache Doris 2.0 アルファ版についての個人的な経験や数百社からのリアルなフィードバックも得てきました。これらは実際のビジネスから得られたものであり、現場からのフィードバックは、機能の磨き上げとさらなる改善に大いに役立ちます。したがって、2.0 ベータ バージョンは、機能の整合性とシステムの安定性の点で優れたユーザー エクスペリエンスを備えており、バージョン 2.0 の新機能を必要とするすべてのユーザーは、導入およびアップグレードを歓迎します。

バージョン 2.0 の調査、テスト、展開、アップグレードのプロセス中に質問がある場合は、アンケート情報を送信してください。その時点で、コア コミュニティの貢献者が 1 対 1 の特別なサポートを提供します。また、バージョン 2.0 では、コミュニティ内のより多くのユーザーにリアルタイムの統合分析エクスペリエンスが提供されることも期待されており、Apache Doris バージョン 2.0 がリアルタイム分析シナリオにおいて理想的な選択肢となると考えています。

人民大学の卒業生らが全学生の情報を盗んで美人採点サイトを構築、刑事拘束された NTアーキテクチャをベースにしたWindows版QQが正式リリース 米国は中国の利用を制限トレーニング AI モデルを提供する Amazon、Microsoft などのクラウド サービスの オープンソース プロジェクトが機能開発を停止すると発表 2023 年に最も高給の技術職であるLeaferJS がリリース: オープンソースの強力な 2D グラフィックス ライブラリである Visual Studio Code 1.80 が サポート端末画像機能 . スレッド登録数3,000万突破 「変化」 deepin、7月のApple M1データベースランキングに合わせてAsahi Linux採用 ：Oracle急上昇、再びスコア拡大

{{名前}}

{{名前}}