Hologres の公開: 高効率分散クエリ エンジンの詳細な分析

Hologres（中国語名：Interactive Analysis）は、Alibaba Cloud が開発したワンストップのリアルタイム データ ウェアハウスです。このクラウドネイティブ システムは、リアルタイム サービスとビッグ データ分析シナリオを統合します。 PostgreSQL プロトコルと完全に互換性があり、ビッグデータ エコシステムにシームレスに接続されます。同じデータ アーキテクチャを使用して、リアルタイム書き込み、リアルタイム クエリ、リアルタイム オフライン フェデレーション分析をサポートできます。その出現により、ビジネス アーキテクチャが簡素化されると同時に、ビジネスにリアルタイムの意思決定機能が提供され、ビッグ データがより大きな商業的価値を発揮できるようになります。アリババグループの誕生からクラウドでの商用化に至るまで、ビジネスの発展とテクノロジーの進化に伴い、Hologres もコアテクノロジーの競争力を継続的に最適化してきました。皆様にHologresについてもっと知っていただくために、高性能ストレージエンジンから高効率クエリエンジン、高スループット書き込みから高QPSクエリなど、Hologresの基盤となる技術原理をシリーズで継続的に公開し、あらゆる側面からHologresを解釈していく予定です。引き続きご注目ください！

今回は、Hologers の高効率分散クエリ エンジンの技術的原理を分析します。

HSAP サービス分析の統合のベスト プラクティスとして、Hologres のクエリ エンジンは完全に自社開発された実行エンジンです。その中心的な設計目標は、あらゆる種類の分散分析およびサービス クエリをサポートし、究極のクエリ パフォーマンスを実現することです。これを実現するために、分析データベースやリアルタイム データ ウェアハウスなどのさまざまな分散クエリ システムを活用し、それぞれの利点を吸収してまったく新しい実行エンジンをゼロから構築しました。

新しいクエリ エンジンをゼロから構築することを選択する理由は何ですか?オープンソースの分散分析およびクエリ システムには、主に 2 つのカテゴリがあります。

1 つのタイプは従来の超並列処理システムです。これは一般的な SQL クエリをサポートできますが、リアルタイムのシナリオを十分にサポートしておらず、パフォーマンスも理想的ではありません。
1 つのタイプは、Apache Druid や ClickHouse などのリアルタイム データ ウェアハウスで、リアルタイムのシナリオ向けに特別に設計され、最適化されています。一般的な単一テーブルのリアルタイム クエリは比較的適切にサポートされますが、複雑なクエリのパフォーマンスは比較的低くなります。
さらに、ビッグデータ エコシステムにおける MapReduce ベースのエンジンは、バッチ処理 ETL に適していますが、一般的にオンライン サービスや多次元分析シナリオには適しておらず、パフォーマンスもかなり劣っています。
Hologres 実行エンジンは、複雑なクエリと前述の高性能リアルタイム サービス クエリをサポートできる一般的なアーキテクチャに基づいています。まず、一般的なリアルタイム データ ウェアハウス シナリオを実装し、徹底的に最適化して内部ベンチマークを使用し、専用のリアルタイム データ ウェアハウスを含む他の競合製品よりもパフォーマンスと安定性が優れていることを確認してから、他の複雑なクエリをサポートするように拡張します。拡張プロセスでは、システムが必然的にますます複雑になりますが、ベンチマークは、回帰することなく単純なリアルタイム クエリのパフォーマンスを維持するためにも使用されます。既存のクエリ エンジンに改良を加えた場合、多くのアーキテクチャと設計の選択がすでに確定しており、1 つの変更がシステム全体に影響するため、同じ効果を達成することは困難です。

Hologres 実行エンジンは、開発から実装まで多くの課題に直面しましたが、この分野におけるさまざまな新しい進歩を組み合わせて活用し、既存のシステムを上回り、さまざまなクエリ タイプを高性能に処理する機会も提供してくれました。これは主に以下の機能に基づいています。

分散実行モデル:ストレージとコンピューティングの分離アーキテクチャで動作する分散実行モデル。実行プランは、非同期演算子で構成された実行グラフ DAG (有向非巡回グラフ) で表され、さまざまな複雑なクエリを表現でき、Hologres のデータ ストレージ モデルに完全に適応できるため、クエリ オプティマイザーへの接続が容易になり、業界のさまざまなクエリ最適化テクノロジを活用できます。
完全な非同期実行:エンドツーエンドの完全な非同期処理フレームワークにより、高同時実行システムのボトルネックを回避し、リソースを最大限に活用し、ストレージとコンピューティングの分離システムによって発生するデータ読み取り遅延の影響を最小限に抑えることができます。
ベクトル化と列処理:内部でデータを処理する場合、演算子は可能な限りベクトル化された実行を使用します。演算子はストレージ エンジンと深く統合されており、柔軟な実行モデルを通じてさまざまなインデックスを最大限に活用し、ベクトルの実体化と計算を可能な限り遅延させて、不要なデータの読み取りと計算を回避します。
適応型増分処理:一般的なリアルタイム データ アプリケーションのクエリ パターンの適応型増分処理。
特定のクエリの詳細な最適化:一部のクエリ パターンに対する独自の最適化。以下、各モジュールを一つずつ紹介していきます。

分散実行モデル
Hologres は、データ量とコンピューティング能力を水平方向に弾力的かつ無限に拡張できるシステムであり、効率的な分散クエリをサポートできる必要があります。

Hologres クエリ エンジンは、オプティマイザーによって生成された分散実行プランを実行します。実行プランは演算子で構成されます。 Hologres テーブルのデータは分散キーに従って複数のシャードに分散され、各シャードには多数のセグメントを含めることができるため、実行プランもこの構造を反映し、実行のためにデータが配置されているノードに分散されます。各テーブル シャードはコンピューティング ノードにロードされ、データはこのノードのメモリとローカル ストレージにキャッシュされます。ストレージとコンピューティングが分離されたアーキテクチャであるため、ノードに障害が発生した場合、そのサービスのシャードを任意のコンピューティング ノードに再ロードすることができ、これはキャッシュをクリアすることと同等です。

たとえば、比較的単純なクエリ。

選択 キー、カウント（値）をテーブル1グループの合計として による 鍵 注文 合計説明制限は100 です。

スタンドアロン データベースの場合は、この実行プランを使用できます。データと計算が複数のノードに分散されている場合は、より複雑な実行プランが必要になります。

分散テーブルでより効率的に実行し、データ転送を最小限に抑えるために、実行プランを異なるフラグメントに分割し、対応するノードに分散して実行することができます。一部の操作は、フラグメントによるデータ出力を削減するためにプッシュダウンできます。実行計画は次のようになります。

データの特性に応じて、オプティマイザーは異なるプランを生成する場合があります。たとえば、ローカル集計によってデータ量が大幅に削減されない場合は、この演算子を省略できます。たとえば、キーが配布キーの場合、次のように最適化できます。

これらの例から、Hologres の実行プランはデータの特性に応じて異なるセグメントに分割され、分散同時実行方式で実行されることがわかります。データは Exchange 演算子を通じてフラグメント間で交換されます。複数テーブル結合クエリなどのより複雑なクエリでは、フラグメントが多くなり、データ交換パターンもより複雑になります。

例えば、次のSQL

 user_nameを選択し、 sum (value)をt1からtotalとして結合し、t1.user_id = t2.user_idでt2 を結合します。ここで、 …グループ ユーザー名順 合計制限100

Hologresでは、実行計画は次のようになります。

結合キーと配布キーが一致している場合は、実行プランを次のように最適化して、リモート データの転送を削減できます。必要なクエリに応じて配布キーを適切に設定すると、クエリのパフォーマンスが大幅に向上する可能性があります。

フィルタリング条件と統計情報に基づいて、オプティマイザーは、動的フィルタリング、ローカル集計などを含むさまざまな最適化された実行プランを生成することもできます。

このような分散実行プランは、すべての SQL クエリとその他のクエリを表現できるほど汎用的です。実行プランもほとんどの超並列処理 (MPP) システムと似ているため、業界で適用可能な最適化を簡単に学習して統合できます。少しユニークなのは、多くのクエリ プラン フラグメント インスタンスが Hologres ストレージ構造に合わせて調整され、効率的なパーティション プルーニングとファイル プルーニングが可能になることです。

同時に、Hologres は PostgreSQL の Explain および Explain Analyze シリーズのステートメントを実装しており、実行プランと対応する実行情報をテキスト形式で表示できるため、ユーザーが自分で実行プランを理解し、ターゲットを絞った SQL 最適化調整を行うことが容易になります。

完全に非同期な実行

同時実行性の高いシステム、特に大量の I/O を伴うシステムでは、頻繁な待機やタスクの切り替えが一般的なシステムボトルネックになります。非同期処理は、これらのボトルネックを回避し、高同時実行システムのパフォーマンスを極限まで高める実証済みの方法です。

実行エンジン、ストレージ エンジン、その他のコンポーネントを含む Hologres のバックエンド全体は、HOS (Hologres Operation System) コンポーネントによって提供される非同期ロックフリー プログラミング フレームワークを統一的に使用して、非同期実行の効果を最大化します。各フラグメント インスタンスは HOS の EC (論理スケジューリング ユニット) を使用するため、フラグメント内のすべての演算子とストレージ エンジンは非同期で実行され、ロックなしでほとんどのリソースに安全にアクセスできます。

演算子とフラグメントには、次のようなインターフェースがあります。

 future<> Open (const SeekParameters&parameters, ...)future<RecordBatchPtr, bool> GetNext(...)future<> Close (...)

非同期処理の一般的な利点に加えて、非同期オペレーター インターフェイスは、ストレージとコンピューティングの分離アーキテクチャにおける比較的高い読み取りデータ待機時間のクエリ パフォーマンスへの影響を効果的に回避し、分散クエリ実行モデル自体にも独自の利点をもたらします。

DAG 実行エンジンは、一般的に、データをプルするモデル (ボルケーノ モデルなど) とデータをプッシュするモデル (多くのビッグ データの段階的実行モデルなど) に分けられ、それぞれに長所と短所があります。 Hologres が採用している非同期プル モデルは、両方のモデルの利点を享受し、欠点を回避することができます (特許申請済み)。一般的なハッシュ結合を例に挙げて説明しましょう。

火山モデルは、まず b のデータを取得してハッシュ テーブルを構築し、すべてのデータをメモリに保存せずに a のデータをストリーミング方式で処理します。ただし、a または b がデータを読み取る必要がある場合、単純な実装では待機が必要になり、CPU を十分に活用できません。リソースを最大限に活用するには、同時フラグメントの数を増やすか、複雑なプリフェッチ メカニズムを導入する必要があり、これにより他のパフォーマンスの問題が発生します。

プッシュ データ モデルを使用すると、同時データ読み取り要求を実行し、完了時に下流の処理をトリガーすることが容易になりますが、上記の Join 演算子の実装はより複雑になります。たとえば、a がデータのバッチを処理して Join 演算子にプッシュしたが、b のハッシュ テーブルがまだ構築されていない場合、このデータのバッチをメモリまたはディスクに一時的に保存するか、バック プレッシャー メカニズムを導入する必要があります。フラグメントの境界でも同様の問題が発生する可能性があり、プル データ モデルでは必要のないデータ キャッシュがいくつか発生します。

Hologres のオペレーターと Fragment の非同期データ プル モデルは、volcano モデルのようにオンデマンドで上流からデータを簡単に取得できると同時に、push データ モデルのようにデータを並行して簡単に読み取ることができます。アップストリームに対して複数の非同期 GetNext を発行すれば、アップストリームの処理が完了した時点で後続の処理が自然にトリガーされます。非同期 GetNext の数とタイミングは自然なフロー制御メカニズムとみなすことができ、CPU 使用率を効果的に向上させ、不要なデータの保存を回避できます。

Hologres は、すべての PostgreSQL クエリをサポートするこの非同期モデルを使用して、完全なクエリ エンジンを実装しました。

列処理とベクトル化

列ベースの処理とベクトル化された実行はどちらも分析クエリ エンジンでよく使用される最適化メカニズムであり、データ処理の効率を大幅に向上させることができます。 Hologres も例外ではありません。可能な限りベクター処理を使用するようにしてください。

Hologres はメモリ内の列ストレージも使用します。メモリ内の列にデータを保存すると、より多くのベクトル処理が可能になります。データを列形式で整理するもう 1 つの利点は、遅延計算が容易になることです。たとえば、... a = 1 かつ b = 2 ... の場合、データのバッチ (通常は格納されている行グループに対応) では、Hologres スキャン演算子によって出力される a と b は、遅延読み取りされた a と b の情報であり、この a のバッチは、a = 1 を処理するときに読み取られます。このバッチ内のすべての行で a=1 が満たされない場合、このバッチの列 b はまったく読み取られません。

ただし、Join などの一部の行ベースの演算子では、列に格納されたデータによって CPU キャッシュ ミスが増加し、パフォーマンスの問題が大きくなる可能性があります。多くのクエリ エンジンでは、さまざまな時点で列ベースのストレージと行ベースのストレージ間の変換が導入されますが、頻繁な変換自体がかなりのオーバーヘッドをもたらし、列から行への変換によって、前述の遅延読み取り列が不必要に読み取られるなど、パフォーマンス上の問題が発生します。

適応増分処理

多くのリアルタイム データ アプリケーションでは、異なる期間を使用してクエリを繰り返し実行することがよくあります。たとえば、監視インジケーター ページを開いた後、select avg(v1) from metrics where d1 = x and d2 = y and ts >= '2020-11-11 00:00:00' and ts < '2020-11-11 03:01:05' and … group by d3 … が定期的に実行されます。このようなクエリは、次回は ts < '2020-11-11 00:03:10' に変更され、次回は ts < '2020-11-11 00:03:15' に変更されます。

ストリーム コンピューティングまたは増分コンピューティングは、このタイプのクエリを非常に効率的に処理できます。ただし、ユーザーが自由に生成できるようなインタラクティブなクエリの場合、通常、すべての組み合わせに対してストリーム コンピューティングまたは増分コンピューティング タスクを構成することは不可能です。クエリを毎回単純に実行すると、大量の繰り返し計算が発生し、リソースが浪費され、パフォーマンスが低下します。

Hologres は、ストレージ エンジンとコンピューティング エンジンの緊密な統合と、ほとんどのデータを読み取り専用ファイルに格納する列指向ストレージの特性を最大限に活用します。繰り返しの計算を可能な限り回避しながら、最新の書き込まれたデータを含むクエリ結果を提供できます。これにより、このタイプのクエリのパフォーマンスが大幅に向上し、リソース使用量が削減されます。

特定のクエリパターンに対する徹底的な最適化

Hologres には、特定のクエリ パターンに対する独自の最適化機能があります。ここでは、フィルター集計の最適化を例に挙げます。

多くのデータ アプリケーションではオープン列が必要になります。これは、テーブル スキーマを変更せずに論理列を動的に追加することと同じです。たとえば、「{c1:v1, c2:u1}」のように複数の論理列値を格納する複数値列タグ（Postgres では配列型を使用できます）があります。クエリを実行する際に通常の列を使用する場合、一般的なクエリの種類は

-- Q1: c1 を (v1, v2, v3) 内にあり、name = 'abc' である t1 から c1、sum(x) を選択し、c1 でグループ化します。  

オープン列の場合、このクエリは次のようになります

-- Q2: select unnest(tags), sum(x) from t1 where name = 'abc' and tags && ARRAY['c1:v1', 'c1:v2', c1:v3'] group by unnest(tags) having unnest(tags) in ('c1:v1', 'c1:v2', c1:v3')  

このタイプのクエリでは、Hologres はビットマップ インデックスを使用して、フィルター条件をすばやく計算し、関連する行を取得できます。ただし、複数値列から関連データを取得する後続の操作ではベクトル処理を使用できず、パフォーマンスを最適化することはできません。調査後、クエリの実行は次のように変換できます。

 Q3:選択  'c1:v1' 、 t1のtags && ARRAY[ 'c1:v1' ] UNIONからの合計(x)  全て 選択  'c1:v2' 、 t1のtags && ARRAY[ 'c1:v2' ] UNIONからの合計(x)  全て…

このように、各 UNION ALL ブランチは、名前とタグのビットマップ インデックスのみを読み取ってフィルター条件を計算し、列 x のデータとフィルター条件を使用してベクトル計算 SUM_IF を実行し、目的の結果を取得します。問題は、各ブランチが t1 を通過して x 列と name 列のビットマップ インデックスを読み取る必要があり、計算が繰り返されることです。最後に、このタイプの一般的なクエリを究極のパフォーマンスに最適化するために、フィルター集計と呼ばれる特別な演算子が導入されました。 t1 を 1 回だけ通過して、繰り返し操作を削除できます。タグ列のデータを読み取らずに、ベクトル計算のみを使用して結果を得ることができます。数十 TB のテーブルでの実際のパフォーマンス向上は 3 倍以上です。

同様の最適化については、Hologres の実行エンジンは、より多くのシナリオに適用できるより一般的な演算子に抽象化しようとします。 Filter Aggregate 演算子も、Hologres が申請した特許の 1 つです。

要約する

Hologres 実行エンジンは、関連する分散クエリ システムのほぼすべての最も効率的な最適化方法 (さまざまな種類のインデックスを含む) を 1 つのアーキテクチャに統合し、独自の改善を加えます。ストレージ エンジンとの緊密な統合により、非同期モデルの利点を最大限に活用でき、さまざまな種類のインデックスを効率的に使用してクエリを高速化できます。これらを組み合わせることで、既存システムを上回るパフォーマンスを実現し、アリババのダブル11のデータ規模での実戦テストに合格し（2020年のダブル11は、1秒あたり5億9600万のリアルタイムデータピークに耐え、数兆のデータに基づく多次元分析とサービスを提供し、99.99％のクエリが80ミリ秒以内に結果を返すことができます）、外部に高い同時実行性と高性能を備えた分散型HSAPクエリサービスを提供しています。