コミュニティの皆様、 Apache Dorisバージョン 2.0.0 が 2023 年 8 月 11 日に正式にリリースされたことを発表できることを嬉しく思います。また、 275 名を超える寄稿者がApache Doris 用に4,100以上の最適化と修正を提出しました。
バージョン 2.0.0 では、Apache Doris は、標準のベンチマーク データ セットでブラインド テスト クエリのパフォーマンスを 10 倍以上向上させ、ログ分析およびデータ レイク フェデレーション分析シナリオの機能を完全に強化し、データの更新効率と書き込み効率を向上させました。安定性が高く、より完全なマルチテナントとリソース分離メカニズムをサポートしており、リソースの弾力性とストレージとコンピューティングの分離の方向で新たなレベルにステップアップし、企業向けの一連の使いやすい機能を追加しています。ユーザー。約半年にわたる開発、テスト、安定性の調整を経て、このバージョンは正式に入手可能となり、安定したものとなっていますので、ぜひダウンロードしてご使用ください。
GitHubのダウンロード:
https://github.com/apache/dris/releases/tag/2.0.0-rc04
公式サイトのダウンロードページ：
https://dris.apache.org/download
リリースノート：
https://github.com/apache/dris/issues/22647
ブラインドテストのパフォーマンスが10倍以上向上
Apache Doris バージョン 2.0.0 では、新しいクエリ オプティマイザーと適応型並列実行モデルを導入し、ストレージ レイヤー、実行レイヤー、および実行オペレーター上の一連のパフォーマンス最適化メソッドと組み合わせて、10 倍を超えるブラインド パフォーマンスを実現しました。テストパフォーマンスの向上。SSB-Flat および TPC-H 標準テスト データセットを例にとると、同じクラスターとマシン構成の下で、新しいバージョンのブラインド テストのパフォーマンスは、ワイド テーブル シナリオでは前バージョンの 10 倍、13 倍高くなります。マルチテーブル関連付けシナリオの場合、パフォーマンスが大幅に向上しました。
01 よりスマートな新しいクエリ オプティマイザー
新しいクエリ オプティマイザーは、より高度な Cascades フレームワークを採用し、より豊富な統計情報を使用し、よりインテリジェントな適応チューニングを実現します。ほとんどのシナリオで、チューニングや SQL の書き換えを行わずに究極のクエリ パフォーマンスを達成できると同時に、より完全で複雑なクエリをサポートします。 SQL をサポートしており、TPC-DS の 99 個の SQL すべてを完全にサポートできます。新しいクエリ オプティマイザーを使用すると、より実際のビジネス シナリオの課題に対処し、手動チューニングによる人的資源の消費を削減し、ビジネス効率の向上に大きく役立ちます。
TPC-H を例に挙げると、手動チューニングや SQL の書き換えを行わなくても、ほとんどの SQL で手動チューニングを行った後でも、新しいオプティマイザーは古いオプティマイザーのパフォーマンスを上回っています。ただし、Baijia 2.0 を超えるユーザーが事前に体験した実際のビジネス シナリオでは、元の SQL 実行効率のほとんどが大幅に向上しました。
参考ドキュメント：https://dris.apache.org/zh-CN/docs/dev/query-acceleration/nereids
有効にする方法:SET enable_nereids_planner=true新しいクエリ オプティマイザーは、Apache Doris 2.0.0 でデフォルトで有効になっています。
02 転置インデックスのサポート
バージョン 2.0.0 では、多次元の高速検索のニーズを満たすために、既存のインデックス構造を強化し、転置インデックスを導入し、キーワードあいまいクエリ、等価クエリ、範囲クエリなどのシナリオで顕著な結果を達成しました。クエリのパフォーマンスと同時実行性。
ここでは、大手携帯電話メーカーのユーザー行動分析シナリオを例に挙げますが、以前のバージョンでは、同時実行数の増加とクエリ時間の消費量の徐々に増加に伴い、パフォーマンスの低下傾向がより顕著になりました。ただし、バージョン 2.0.0 で逆インデックスが有効になった後は、同時実行性が増加してもクエリのパフォーマンスはミリ秒レベルのままです。同じクエリの同時実行性の場合、バージョン 2.0.0 では、このユーザー行動分析シナリオで同時クエリのパフォーマンスが 5 ～ 90 倍向上しました。
03 クエリ同時実行能力が 20 倍に向上
銀行取引のシリアル番号クエリ、保険代理店の保険証券クエリ、電子商取引履歴注文クエリ、特急運送状番号クエリなどのデータ サービス シナリオでは、多数の最前線のビジネス担当者と C エンド ユーザーが、データ全体を取得する必要があります。主キー ID に基づいてデータ行を作成すると同時に、ユーザーのポートレートやリアルタイムのリスク管理などのシナリオでは、マシンに対する大規模なプログラムによるクエリにも直面することになります。ポイント クエリを処理するための Apache HBase や、高い同時実行性を共有するためのキャッシュ レイヤーとしての Redis などの KV システムの導入により、システムにプレッシャーがかかります。
列指向ストレージ エンジン上に構築された Apache Doris の場合、このタイプのポイント クエリは数百の列幅のテーブルに対するランダム読み取り IO を増幅し、クエリ オプティマイザと実行エンジンもそのような単純な SQL を解析して配布するのが困難になります。不必要な追加のオーバーヘッドが発生し、SQL 解析を担当する FE モジュールが同時実行性を制限するボトルネックになることが多いため、より効率的で簡潔な実行方法が必要です。
Apache Doris バージョン 2.0.0 では、まったく新しい行と列のハイブリッド ストレージと行レベルのキャッシュが導入されました。これにより、一度にデータ行全体を読み取る効率が向上し、ディスク アクセスの数が大幅に削減されます。また、ポイント クエリのショート パス最適化を導入し、実行エンジンを介してジャンプし、高速で効率的な読み取りパスを直接使用して必要なデータを取得します。また、プリペアド ステートメントの再利用を導入して SQL 解析を実行し、FE オーバーヘッドを削減します。
上記の一連の最適化により、Apache Doris 2.0.0 バージョンは同時実行機能の桁違いの向上を達成し、単一ノード 30,000 QPS の同時実行パフォーマンスを達成しました。これは、以前のバージョンのポイント クエリ同時実行機能よりも 20 倍以上高いです。 ！
上記の機能に基づいて、Apache Doris は、同時実行性の高いデータ サービス シナリオのニーズをより適切に満たし、そのようなシナリオで HBase の機能を置き換え、複雑なテクノロジ スタックによって発生するメンテナンス コストとデータの冗長ストレージを削減できます。
参考記事：Apache Doris 2.0の高同時実行機能の解釈、クエリ同時実行数20倍、ノード当たり数万QPS
04 適応型並列実行モデル
極めて高速な分析エクスペリエンスを実現しながら、複数の混合分析負荷の実行効率とクエリの安定性を確保するために、バージョン 2.0.0 ではクエリ実行エンジンとしてパイプライン実行モデルを導入しました。パイプライン実行エンジンでは、クエリの実行は制御フローを変更するデータによって駆動されます。各クエリ実行プロセスのブロック演算子は異なるパイプラインに分割されます。各パイプラインが実行をスケジュールする実行スレッドを取得できるかどうかは、事前データに依存します。準備ができているかどうかに関係なく、ブロック操作の非同期を実現し、システム リソースをより柔軟に管理し、スレッドの頻繁な作成と破棄によるオーバーヘッドを削減し、Apache Doris の CPU 使用効率を向上させます。したがって、混合負荷シナリオにおける Apache Doris のクエリ パフォーマンスと安定性が包括的に向上しました。参考ドキュメント: https://dris.apache.org/zh-CN/docs/dev/query-acceleration/pipeline-execution-engine
開け方 Set enable_pipeline_engine = true
- この機能は Apache Doris 2.0.0 ではデフォルトで有効になり、BE はクエリ実行時にデフォルトで SQL 実行モデルをパイプライン実行モードに変更します。
parallel_pipeline_task_numこれは、SQL クエリの同時パイプライン タスクの数を表します。Apache Doris はデフォルトで設定されています0。このとき、Apache Doris は各 BE の CPU コア数を自動的に認識し、同時実行数を CPU コア数の半分に設定します。ユーザーは実際の状況に応じて調整することもできます。parallel_fragment_exec_instance_num古いバージョンからアップグレードするユーザーの場合、このパラメータは古いバージョンの値に自動的に設定されます。
より統合された多様な分析シナリオ
Apache Doris は、もともとレポート分析のシナリオから生まれた OLAP システムとして、この分野の専門性を極限まで高めており、その優れた分析パフォーマンスと最小限のユーザーエクスペリエンスにより、多くのユーザーに認められています。ダッシュボード）、リアルタイム大画面、ビジネスレポート、マネジメントコックピットなどのリアルタイムレポートシナリオや、セルフサービスBIプラットフォームやユーザー行動分析などの即席クエリシナリオが広く利用されています。
ユーザー規模の急速な拡大に伴い、Apache Doris を使用して既存のヘビー データ テクノロジー スタックを簡素化し、複数のシステムによって発生する使用コストと運用保守コストを削減したいと考えるユーザーが増えています。したがって、Apache Doris は、これまでのリアルタイム レポートやアドホックなどの典型的な OLAP シナリオから、レイクとウェアハウスの統合、ELT/ETL、ログ取得、ログ取得分析とレイクとウェアハウスの統合も、Apache Doris の最新バージョンにおける重要な進歩です。
01 10倍以上のコスト効率を実現したログ取得・分析プラットフォーム
Apache Doris バージョン 2.0.0 では、ネイティブの半構造化データのサポートを提供し、既存の JSON と Array に基づいて複合型 Map を追加し、Light Schema Change の機能に基づいて Schema Evolution を実装します。同時に、バージョン 2.0.0 で新たに導入された転置インデックスと高性能テキスト分析アルゴリズムにより、ログ取得および分析シナリオにおける Apache Doris の機能が包括的に強化され、より効率的な任意次元分析と全文検索をサポートできるようになりました。 。大規模データ書き込みと低コストストレージにおけるこれまでの利点を組み合わせ、Apache Doris をベースとした新世代のログ取得および分析プラットフォームは、業界の一般的なログ分析ソリューションと比較して、 10 倍以上のコストパフォーマンスの向上を実現しました。
02 湖と倉庫の一体化
Apache Doris バージョン 1.2 では、複数の異種データ ソースの自動メタデータ マッピングと同期をサポートし、便利なメタデータとデータ接続を実現するマルチカタログ機能を導入しました。バージョン 2.0.0 では、データ フェデレーション分析機能がさらに強化され、より多くのデータ ソースが導入され、ユーザーの実際の運用環境向けに多くのパフォーマンスの最適化が行われ、実際のワークロード条件下でのクエリ パフォーマンスが大幅に向上しました。
データソースに関しては、Apache Doris バージョン 2.0.0 は、Hudi Copy-on-Write テーブルのスナップショット クエリと Merge-on-Read テーブルの読み取り最適化クエリをサポートしており、これまでに Hive、Hudi、Iceberg をサポートしています。 、Paimon、MaxCompute、Elasticsearch、Trino、ClickHouse などの数十のデータ ソースは、ほぼすべてのオープン レイク ウェアハウス形式とメタストアをサポートしています。同時に、Apache Range を介した Hive カタログの認証もサポートされており、ユーザーの既存の権限システムとシームレスに接続できます。同時に、任意のカタログにカスタム認証方法を実装するための拡張可能な認証プラグインもサポートします。
パフォーマンスの面では、Apache Doris 独自の効率的な分散実行フレームワーク、ベクトル化された実行エンジン、クエリ オプティマイザーを使用し、バージョン 2.0 の小さなファイルと広いテーブルの読み取りの最適化、ローカル ファイル キャッシュ、ORC/Parquet ファイルの読み取り効率を組み合わせて最適化します。 、エラスティック コンピューティング ノード、および外観の統計コレクションを備えているため、Apaceh Doris は TPC-H シナリオで Hive 外部テーブルをクエリでき、Hive 外部テーブルのクエリのパフォーマンスは Presto/Trino のパフォーマンスよりも 3 ～ 5 倍高くなります。
この一連の最適化により、Apache Doris のレイクとウェアハウスの統合機能が大幅に拡張され、その優れた分析機能が次のシナリオでより有効に活用できるようになりました。
- Lake ウェアハウス クエリ アクセラレーション: データ レイク、Elasticsearch、およびさまざまなリレーショナル データベースに優れたクエリ アクセラレーション機能を提供し、Hive、Presto、Spark などのクエリ エンジンと比較して数倍のパフォーマンス向上を達成します。
- データのインポートと統合: 拡張可能な接続フレームワークに基づいて、データ統合における Apache Doris の機能が強化され、データの消費と処理がより便利になります。ユーザーは、Apache Doris を通じてさまざまなアップストリーム データ ソースの統合増分同期および完全同期を実行し、Apache Doris のデータ処理機能を使用してデータを処理および表示したり、処理されたデータをデータ ソースに書き戻したり、ダウンストリーム システムに提供したりできます。消費用に。
- 統合データ分析ゲートウェイ: Apache Doris を使用して、複数の種類のデータ ソースに高速にアクセスするのに便利な、完全でスケーラブルなデータ ソース接続フレームワークを構築します。さまざまな異種データ ソースに基づいた高速クエリおよび書き込み機能を提供し、Apache Doris を統合データ分析ゲートウェイにします。
効率的なデータ更新
リアルタイム分析シナリオでは、データの更新は非常に一般的な要件です。ユーザーは、最新のデータをリアルタイムでクエリできることだけでなく、データをリアルタイムで柔軟に更新できることも望んでいます。電子商取引注文分析、物流運送状分析、ユーザー ポートレートなどの一般的なシナリオでは、行全体の更新、列の部分更新、条件に応じたバッチ更新または削除、テーブル全体または全体の書き換えなどのデータ更新タイプをサポートする必要があります。パーティション (挿入上書き) 。
ビッグ データ分析の分野では、効率的なデータ更新が常に課題となっています。オフライン データ ウェアハウス Hive は通常、パーティション レベルのデータ更新のみをサポートしていますが、Hudi や Iceberg などのデータ レイクはレコード レベルの更新をサポートしていますが、通常は Merge を使用します。 on-Read または Copy -on-Write メソッドは、低頻度のバッチ更新にのみ適しており、リアルタイムの高頻度の更新には適していません。
Apache Doris バージョン 1.2 では、Unique Key 主キー モデルに Merge-on-Write データ更新モードを実装しました。すべてのデータのマージはデータ書き込みフェーズ中に完了できるため、クエリのパフォーマンスが 5 ～ 10 倍向上しました。Apache Doris バージョン 2.0 では、主に次のようなデータ更新機能がさらに強化されました。
- 書き込みパフォーマンスが大幅に最適化され、高同時書き込みシナリオと混合負荷書き込みシナリオの安定性も大幅に向上しました。例えば、7GBタブレット1台の繰り返しインポートテストでは、データインポート時間が約30分から90秒に短縮され、書き込み効率が20倍向上し、1秒あたり30万エントリの書き込みスループットを実現できました。 10 時間以上連続して書き込みを行った後でも、パフォーマンスは依然として非常に安定しています。
- 部分的な列更新機能をサポートします。バージョン 2.0.0 より前では、Apache Doris は Aggregate Key 集計モデルの Replace_if_not_null による部分的な列更新のみをサポートしていましたが、バージョン 2.0.0 では、Unique Key 主キー モデルの部分的な列更新が追加され、同時に広いテーブルを拡張するときの書き込みが行われました。 , Flink はマルチストリーム結合の拡張を実行する必要がなく、ワイド テーブルに直接書き込むことができるため、コンピューティング リソースの消費が削減され、データ処理リンクの複雑さが大幅に軽減されます。同時に、ポートレートシーンのリアルタイムラベル列更新やオーダーシーンのステータス更新に直面した場合、指定された列を直接更新することが従来よりも便利です。
- 複雑な条件付き更新と条件付き削除をサポートします。バージョン 2.0.0 より前では、Unique Key 主キー モデルは単純な更新および削除操作のみをサポートしていましたが、バージョン 2.0.0 では Merge-on-Write に基づく複雑な条件でのデータ更新および削除が実装され、実行効率が向上しました。 。上記の最適化に基づいて、Apache Doris はさまざまなデータ更新要件を完全にサポートします。
より効率的かつ安定したデータ書き込み
01 インポートパフォーマンスがさらに向上
リアルタイム分析に重点を置き、過去数バージョンでリアルタイム分析機能を継続的に強化してきましたが、エンドツーエンドのリアルタイムデータ書き込み機能は最適化の重要な方向性であり、Apache Doris 2.0ではさらに強化されました。この能力。スキップリストを使用しない Memtable、並列ダウンロード、単一コピーのインポートなどの最適化により、インポートのパフォーマンスが大幅に向上しました。
- Stream Load を使用して、TPC-H 144G lineitem テーブルの元のデータのコピーを 3 つ作成し、それを 48 バケットの Duplicate テーブルにインポートすると、スループットが 100% 向上します。
- Stream Load を使用して、TPC-H 144G ラインアイテム テーブルの元のデータのコピーを 3 つ作成し、それを 48 バケットの一意のキー テーブルにインポートすると、スループットが 200% 向上します。
- insert into select を使用して、TPC-H 144G ラインアイテム テーブルを 48 バケットの重複テーブルにインポートすると、スループットが 50% 増加します。
- insert into select を使用して、TPC-H 144G ラインアイテム テーブルを 48 バケットの一意のキー テーブルにインポートすると、スループットが 150% 増加します。
02 高頻度のデータ書き込みがより安定します
高頻度のデータ書き込みプロセスでは、小さなファイルのマージと書き込み増幅の問題、およびその後のディスク I/O と CPU リソースのオーバーヘッドがシステムの安定性を制限する鍵となるため、バージョン 2.0 では垂直方向を導入しました。コンパクションとセグメントコンパクションは、書き込みプロセス中のコンパクションメモリと多すぎるセグメントファイルの問題を完全に解決するために使用され、リソース消費が90%削減され、速度が50%向上し、メモリ使用量はわずか10%になります。オリジナル。
詳細な紹介: https://mp.weixin.qq.com/s/BqiMXRJ2sh4jxKdJyEgM4A
03 データテーブル構造の自動同期
以前のバージョンではミリ秒レベルでのスキーマ変更を導入していましたが、Flink-Doris-Connector の最新バージョンでは、MySQL などのリレーショナル データベースから Apache Doris へのデータベース全体のワンクリック同期を実現しました。実際のテストでは、単一の同期タスクで数千のテーブルのリアルタイムの並列書き込みを実行できます。これにより、これまでの退屈で複雑な同期プロセスに完全に別れを告げ、上流のビジネス データベースのテーブル構造とデータ同期を実現できます。簡単なコマンドで実現できます。同時に、上流のデータ構造が変更された場合、スキーマの変更を自動的にキャプチャし、DDL を Doris に動的に同期して、ビジネスのシームレスな運用を保証します。
詳細な紹介: https://mp.weixin.qq.com/s/Ur4VpJtjByVL0qQNy_iQBw
より完全なマルチテナントリソースの分離
マルチテナントとリソース分離の主な目的は、高負荷時の相互リソースのプリエンプションを回避することです。Apache Doris は、過去のバージョンでリソース グループ (リソース グループ) のハード分離スキームを導入しました。同じクラスター内の BE にラベルを付けることで、BE に同じラベルがリソース グループを形成します。データをデータベースに格納する際には、リソース グループの構成に従ってデータのコピーが異なるリソース グループに書き込まれ、クエリの際には、リソース グループの分割に従って、対応するリソース グループ上の計算リソースが計算に使用されます。読み取りと書き込みのトラフィックは別のコピーに配置されます。読み取りと書き込みの分離を実現するため、またはオンライン サービスとオフライン サービスを異なるリソース グループに分割するには、オフライン分析タスク間のリソースのプリエンプションを回避します。
リソース グループのハード分離スキームは、複数のビジネス間のリソースのプリエンプションを効果的に回避できますが、実際のビジネス シナリオでは、一部のリソース グループが逼迫し、一部のリソース グループがアイドル状態になる可能性があるため、より柔軟な方法が必要です。リソースの空き率を減らすため。したがって、バージョン 2.0.0 では、ワークロード グループ リソースのソフト リミット ソリューションを追加し、ワークロードをグループで管理して、メモリと CPU リソースの柔軟な割り当てと制御を確保しました。
クエリをワークロード グループに関連付けることにより、BE ノード上の単一クエリの CPU およびメモリ リソースの割合を制限し、リソース グループを開くためのメモリ ソフト リミットを構成できます。クラスターのリソースが不足している場合、クラスターへの負荷を軽減するために、グループ内で最大のメモリを占有するいくつかのクエリ タスクが自動的に強制終了されます。クラスター リソースがアイドル状態の場合、ワークロード グループによって使用されるリソースが事前設定値を超えると、複数のワークロードがクラスターの利用可能なアイドル リソースを共有し、自動的にしきい値を超え、安定した実行を保証するためにシステム メモリを使用し続けます。クエリタスク。ワークロード グループは優先順位の設定もサポートしており、事前設定された優先順位によってリソース割り当てを管理し、どのタスクが通常リソースを取得できるか、どのタスクが少量しかリソースを取得できないかまったく取得できないかを決定します。
同時に、ワークロードグループにクエリキューイング機能も導入しました。ワークロードグループ作成時にクエリの最大数を設定でき、最大同時実行数を超えたクエリはキューに入れられて実行され、システム負荷を軽減します。高負荷、圧力下。
極めて高い柔軟性とストレージと計算の分離
これまで、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/compute_node
より徹底的なストレージとコンピューティングの分離要件に直面して、フライホイール テクノロジー (SelectDB)技術チームは、新しいクラウドネイティブのストレージとコンピューティングの分離アーキテクチャ (SelectDB Cloud) を設計および実装しました。このアーキテクチャは、多数の企業による大規模な使用を経験しています。機能の成熟度、システムの安定性、その他の側面は、実際の運用環境のテストに耐えています。Apache Doris 2.0.0 のリリースの機会に、Flywheel Technology は、広範な磨きをかけた後、この成熟したアーキテクチャを Apache Doris コミュニティに提供することを発表しました。この作業は 2023 年 10 月頃に完了する予定です。その時点で、すべてのストレージとコンピューティングの分離コードは、Apache Doris コミュニティのメイン ブランチに提出されます。9 月には、コミュニティ ユーザーの大多数が、ストレージとコンピューティングの分離アーキテクチャを事前に体験できるプレビュー版です。
使いやすさがさらに向上
上記の機能要件に加えて、エンタープライズ レベルの機能に関する多くのエクスペリエンス向上が Apache Doris に追加されました。
01 Kubernetes コンテナ化されたデプロイメントのサポート
以前は、Apache Doris は IP 通信に基づいていました。K8s 環境にデプロイする場合、ホスト障害による Pod IP ドリフトにより、クラスターが使用できなくなります。バージョン 2.0 では、FQDN をサポートしているため、Apache Doris は IP 通信なしで実装できます。ノードの自己修復機能により、K8s 環境の展開や柔軟な拡張や縮小にうまく対応できます。
02 クラスター間のデータレプリケーション
Apache Doris バージョン 2.0.0 では、CCR 機能を使用して、ソース クラスターのデータ変更をターゲット クラスターにデータベース/テーブル レベルで同期し、シナリオに応じて同期の範囲を細かく制御できます。ニーズに応じて完全または増分を柔軟に選択できます同期により、データ同期の柔軟性と効率が効果的に向上します。さらに、Dors CCR は DDL 同期もサポートしており、ソース クラスタによって実行される DDL ステートメントはターゲット クラスタに自動的に同期できるため、データの一貫性。Doris CCR は設定と使用が非常に簡単で、簡単な操作でクラスタ間のデータ レプリケーションを迅速に完了できます。Doris CCR の優れた機能に基づいて、読み取り/書き込み負荷の分離と複数のコンピューター ルームのバックアップをより適切に実現し、さまざまなシナリオでのクラスター間のレプリケーション要件をより適切にサポートできます。
03 その他のアップグレードに関する考慮事項
- 1.2-lts では 2.0.0 にアップグレードするためにダウンタイムが必要で、2.0-alpha では 2.0.0 にアップグレードするためにダウンタイムが必要です
- クエリ オプティマイザー スイッチはデフォルトで有効になっています。
- ベクトル化されていないコードはシステムから削除されたため、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.0 のリリース中に、私たちは新しいバージョンの磨き上げに参加するよう数百の企業を招待し、より優れたパフォーマンス、より高い安定性、より優れた使いやすさを備えたデータ分析エクスペリエンスをすべてのユーザーに提供することに努めました。今後も、ユーザーの皆様の高機能化と安定性の追求に応えるため、アジャイル版のリリースを継続し、8月下旬には2.0シリーズの第一弾バージョン2.0.1、そしてバージョン2.0がリリースされる予定です。 2は9月発売予定です。バグ修正を迅速に行うとともに、最新機能の一部が引き続き新しいバージョンに追加されます。9 月に、バージョン 2.1 のアーリーアダプター バージョンをリリースします。これには、半構造化データの分析要件をより適切に満たすためのバリアント変数データ型、スキーマ フリー、およびマルチテーブル マテリアライズドを含む一連の待望の新機能が追加されます。同時に、データのスケジューリングとリンクの処理を簡素化し、インポート パフォーマンスを継続的に最適化し、より簡潔な新しいデータ インポート メソッドを追加し、自動バッチ処理およびコンポジットのネスト機能により、よりリアルタイムのデータ書き込みを実現します。データ型など。
私たちは、コミュニティ内のより多くのユーザーにリアルタイムの統合分析エクスペリエンスを提供するために、Apache Doris 2.0 の正式リリースを楽しみにしています。また、Apache Doris 2.0 は、リアルタイム分析シナリオにおいて理想的な選択肢になると信じています。
最後に、Apache Doris コミュニティの年次サミットである Doris Summit 2023 がすでに始まっており、Doris Summit 2023 ではバージョン 2.0 のより多くのアプリケーションのベスト プラクティスがすべてのユーザーに公開されることを期待しています。