クラウド データ ウェアハウスの将来動向: コンピューティングとストレージの分離

[[403506]]

背景

クラウド時代の到来とともに、データベースもクラウド データベース時代を迎え始めました。オープンソースの MySQL、PostgreSQL、MongoDB、従来のデータベースベンダーの SQL Server、Oracle、クラウドベンダーが自社開発した Aurora、Redshift、PolarDB、AnalyticDB、AzureSQL など、さまざまなデータベースシステム (OLTP、OLAP、NoSQL など) が、さまざまな社内外のクラウドプラットフォーム (AWS、Azure、Alibaba Cloud) 上で繁栄しています。一部のデータベースはまだクラウドホスティングの段階にあり、元のアーキテクチャをクラウドホストに移行してクラウドリソースを活用するだけです。一部のデータベースはクラウド ネイティブ ステージに入り、クラウド プラットフォームの IAAS レイヤーのインフラストラクチャに基づいて、弾力性、サーバーレス、データ共有などの機能を構築しています。

本稿では主に、Alibaba Cloud のクラウドネイティブ データ ウェアハウス AnalyticDB for MySQL (以下、AnalyticDB) のここ数年間の弾力性の方向への探求と成果を紹介します。

コンピューティングとストレージを分離する必要があるのはなぜですか?

MPP (Massive Parallel Processing) アーキテクチャは、OLAP データベースで最も一般的に使用される技術アーキテクチャです。 MPP アーキテクチャでは、コンピューティングとストレージがノードを共有し、各ノードには独自の独立した CPU、メモリ、およびディスク リソースがあり、それらは互いに共有されません。データは、特定のパーティション ルール (ハッシュ、ランダム、範囲) に従って異なるノードに分散されます。クエリを処理する際、各ノードはリソースを競合することなく独自のデータを並列処理し、比較的優れた並列実行機能を備えています。

ストレージ リソースとコンピューティング リソースを緊密に結合したこのアーキテクチャでは、クラウド時代のさまざまなシナリオにおけるさまざまなワークロード要件を満たすのは簡単ではありません。たとえば、データのインポート タスクでは、比較的大きな IO とネットワーク帯域幅の消費が必要になることが多いですが、CPU リソースの消費はそれほど多くありません。複雑なクエリ タスクは、多くの場合、大量の CPU リソースを消費します。したがって、これら 2 つの異なるワークロードのリソース仕様を選択するときは、異なるワークロードに基づいて異なる選択を行う必要があります。また、1 つのリソース仕様を使用して両方のタイプを同時に満たすことも困難です。ビジネスは常に発展し、作業量も常に変化するため、事前に計画を立てることは困難です。

ビジネス開発では CPU リソースに対する要求が高まるため、クラスターと CPU リソースを拡張すると、データの再シャッフルがトリガーされ、比較的大きなネットワーク帯域幅と CPU リソースが消費されます。クラウド プラットフォーム上に構築されたデータ ウェアハウスの場合でも、オフピークのクエリ期間中に一部のコンピューティング リソースを解放することで使用コストを削減することはできません。これは、これによってもデータの再シャッフルがトリガーされるためです。この結合アーキテクチャにより、データ ウェアハウスの弾力性が制限されます。

ストレージリソースとコンピューティングリソースを分離することで、ストレージとコンピューティングのリソース仕様と容量を独立して計画できるようになります。この方法では、コンピューティング リソースの拡張、削減、解放を比較的迅速に完了でき、データ移行に追加コストは発生しません。ストレージとコンピューティングは、それぞれの特性をより適切に組み合わせて、より適したリソース仕様と設計を選択することもできます。

3つの業界トレンド

1 赤方偏移

AWS で最も人気のあるデータ ウェアハウス製品である Redshift は、MPP アーキテクチャを採用し、弾力性に向けて進化してきました。 2018 年 11 月に Redshift がリリースした Elastic サイズ変更機能により、従来のサイズ変更に比べてスケーリング時間が大幅に短縮されます。 2019 年 11 月には、伸縮自在なサイズ変更スケジューリングがさらに導入され、ユーザーは拡張および縮小プランを構成して自動伸縮性を実現できるようになりました。さらに、Redshift は 2019 年 12 月に RA3 フォームを正式にリリースしました。これは、コンピューティングとストレージを分離するアーキテクチャを採用しています。データは S3 に保存され、コンピューティング ノードは高性能 SSD をローカル キャッシュとして使用してデータへのアクセスを高速化します。このアーキテクチャでは、コンピューティングとストレージは独立して弾力性があり、優れた弾力性を備えています。

2 スノーフレーク

Snowflake は創業以来、コンピューティングとストレージを分離するアーキテクチャを採用してきました。クラウド プラットフォーム全体にわたるクラウド データ ウェアハウスとして、ストレージ層はオブジェクト ストレージ (AWS S3、Azure Blob など) で構成され、コンピューティング層は仮想ウェアハウス (略して VW) で構成されます。各ユーザーは 1 つ以上の対応する VW を作成でき、各 VW は複数の EC2 (AWS 上の仮想ホスト) で構成されるクラスターです。このように、さまざまなワークロードに応じて、さまざまなユーザー向けにさまざまな仕様の VW を柔軟に作成でき、ユーザー同士を非常にうまく分離できます。 VW の柔軟性に基づいて、Snowflake は VW の自動一時停止、再開、自動スケール機能をサポートし、コンピューティングとストレージの分離によってもたらされる弾力性を通じて、ユーザーに「従量課金制」エクスペリエンスを提供します。

4つのAnalyticDBエラスティックモード

Redshift と同様に、AnalyticDB はもともと従来の MPP アーキテクチャに基づいて構築されました。 2020 年 5 月、AnalyticDB はコンピューティングとストレージのアーキテクチャが分離されたエラスティック モードを開始しました。 AnalyticDB エラスティック モードは、アクセス レイヤー、コンピューティング レイヤー、ストレージ レイヤーに分かれています。アクセス層は MySQL プロトコルと互換性があり、リアルタイムのデータ書き込みとクエリを担当する権限制御、オプティマイザー、メタデータ、クエリ スケジューリングなどのモジュールが含まれています。

1 ストレージ層

エラスティック アーキテクチャでは、ストレージ レイヤーはリアルタイムのデータ書き込み、インデックス構築、データ スキャン、プッシュダウン述語計算 (フィルタリング、列プルーニング、パーティション プルーニングなど) を担当し、クエリ計算タスクは担当しなくなります。データはストレージ層で引き続き MPP モードで整理されます。データはハッシュまたはランダムな方法でパーティション (シャード) 間に均等に分散されます。パーティショニング (シャード) 方式では、リアルタイムのデータ書き込みで強力な一貫性を簡単に実現でき、データ スキャン中にシャード レベルの同時読み取りを実現して同時実行性を確保できます。同時に、ストレージ層は統合されたホットおよびコールド階層型ストレージ機能を提供します。データは、ローカル SSD にホット テーブルとして保存することも、基盤となる DFS にコールド テーブルとして保存することも、ホットとコールドの混合テーブルの形式で保存して、ホット データとコールド データの自動移行を実現することもできます。これについては、「データ ウェアハウス階層化ストレージ テクノロジーの公開」の記事で詳しく説明されています。

2 計算層

エラスティック モードでは、コンピューティング層は複数のコンピューティング ノードで構成されます。コンピューティング ノードは、アクセス層から送信された物理実行プランを受信し、物理実行プランに従って対応する演算子に変換する役割を担います。コンピューティング層はベクトル化された実行モデルを採用しています。オペレータ間のデータはパイプライン方式でやり取りされます。複数行 (通常は数千行) のデータがバッチを形成し、バッチ内のデータは列ストレージの形式で編成されます。さらに、コンピューティング レイヤーの JIT モジュールは、クエリ プランに基づいてコードを動的に生成し、式の計算、並べ替え、型の比較などの計算を高速化します。また、JIT モジュールは、計画されたパターンをキーとして使用して動的に生成されたコードをキャッシュし、インタラクティブ クエリでの動的に生成されたコードのコストを削減します。

3 実行計画

コンピューティングとストレージを分離するアーキテクチャでは、ストレージ層からデータをロードする役割を担う新しい Resharding オペレーターがコンピューティング層に追加されます。データは、バッチおよび列ストレージでストレージ層とコンピューティング層の間で転送されます。 1 回のリクエストで複数のバッチのデータが送信されますが、そのサイズは通常 32 MB 以下です。ストレージ レイヤーでは MPP データの事前パーティション分割方法が保持されるため、オプティマイザーは実行プランを生成するときに、この分散機能に基づいて結合操作および集計操作中の不要なデータの再パーティション分割を削減します。さらに、オプティマイザーは、クエリ内のフィルターがストレージ レイヤー インデックスを使用できるかどうかも判断し、ストレージ レイヤーで認識できるフィルターをストレージ レイヤーにプッシュしてインデックスを使用し、フィルタリングを高速化し、コンピューティング レイヤー間のデータ転送を削減しようとします。プッシュダウンできないフィルターは、フィルタリングのために計算レイヤーに保持されます。

4 パーティションの動的再配分

Resharding オペレータと Scan オペレータの間では、パーティション (シャード) は次の原則に従って再配布されます。

同じストレージ ノードから複数のパーティションを異なるコンピューティング ノードに分散してみます。
同じクエリでは、異なるテーブルの同じパーティションが同じコンピューティング ノードにマップされます。
同じパーティションが、異なるクエリ間で異なるコンピューティング ノードにランダムに割り当てられます。
Snowflake や Redshift とは異なり、コンピューティング ノードとパーティションの間には固定されたマッピング関係はありません。コンピューティング ノードにはローカル キャッシュがないため、データ アクセスの高速化はストレージ層の SDD とメモリ キャッシュに完全に依存します。この動的な再配分方法により、パーティションの不均一性やパーティション内のデータの偏りなどの問題が大幅に軽減され、固定コンピューティング ノードにホットスポットが発生することはありません。

5 データ読み込みの最適化

元のアーキテクチャと比較すると、コンピューティングとストレージの分離によりリモート データ アクセスが追加され、クエリのレイテンシとスループットに大きな影響を与えます。以下の最適化を行いました。

ネットワーク接続をマージします。図 3 に示すように、接続をマージすることで、少量データ クエリのネットワーク インタラクションの数が減り、クエリのレイテンシが短縮されます。
データ圧縮。バッチ内の列ストレージ形式に基づいて圧縮が実行され、ネットワーク帯域幅の消費が削減され、Resharding オペレーターの読み込みスループットが効果的に向上します。
非同期読み取り。ネットワーク モジュールは非同期的にロードされ、データはバッファーに格納されます。 Resharding オペレーターはバッファーからデータを取得し、CPU とネットワーク IO を完全に並列化できるようにします。

6 パフォーマンステスト

このセクションでは、大規模なデータ ボリューム分析シナリオにおけるコンピューティングとストレージの分離アーキテクチャが AnalyticDB のクエリ スループットに与える影響について説明します。

テスト環境

例 1: 非分離モード、4 つのストレージ ノード グループ、ストレージ ノードはデータのスキャン、クエリの計算を担当します。
例 2: エラスティック モード、4 つのストレージ ノード グループ + 6 つのコンピューティング ノード。ストレージ ノードはデータのスキャンを担当し、コンピューティング ノードはクエリの計算を担当します。 2 つのインスタンスはそれぞれ tpch 1TB データをテスト データ セットとしてインポートします。

テストシナリオ

テスト SQL として TPCH Q1 を選択しました。 Q1 は、収束度が非常に高い単一テーブルの集計クエリです。ストレージ層とコンピューティング層の間で送信されるデータの量は約 260 GB です。 TPCH Q1 を単一同時順次実行モードで実行し、クエリの平均実行時間を測定します。

 l_returnflag、l_linestatus、sum(l_quantity) を sum_qty として、sum(l_extendedprice) を sum_base_price として、sum(l_extendedprice * ( 1 - l_discount)) を sum_disc_price として、sum(l_extendedprice * ( 1 - l_discount) * ( 1 + l_tax)) を sum_charge として、avg(l_quantity) を avg_qty として、avg(l_extendedprice) を avg_price として、avg(l_discount) を avg_disc として、count(*) を count_order として lineitem から選択します。ここで、l_shipdate <= date '1998-12-01' - interval '120' day、group by l_returnflag、l_linestatusorder by l_returnflag、l_linestatus;

テストデータ

テストの結論

上記のテスト データから、弾性モードでの TPCH Q1 の実行時間がわずかに優れていることがわかります。結果は一見するとかなり驚くべきものです。コンピューティングとストレージを分離すると、パフォーマンスが向上します。弾性モードと非分離モードのストレージ ノードの数が同じであることを注意深く分析すると、分離モードのストレージ ノードがボトルネックにならないことが保証されます。実行時のリソース消費量で見ると、分離モードの総リソース消費量（19.5% + 97%）は、非分離モード（98%）の1.19倍になります。追加の CPU 消費は、ネットワーク転送、シリアル化、デシリアル化などによって発生します。コンピューティング層の場合、ストレージ層が十分なデータ スループットを提供でき、コンピューティング層の CPU が十分に活用されている限り、コンピューティングとストレージを分離してもクエリ処理のスループットは低下しません。もちろん、非分離モードと比較すると、より多くのリソースを消費します。

5. 結論

当社は、AnalyticDB のエラスティック モードを基盤として、コンピューティング リソースのプーリング、オンデマンドのエラスティック性、共有ストレージに基づくストレージ層の急速な拡張と縮小の機能など、今後さらにエラスティック機能を開発していきます。これらの柔軟な機能により、クラウド データ ウェアハウスに対する顧客の要求をより適切に満たし、使用コストをさらに削減することができます。

参考文献
[1] https://levelup.gitconnected.com/snowflake-vs-redshift-ra3-the-need-for-more-than-just-speed-52e954242715
[2] https://www.snowflake.com/
[3] https://databricks.com/session/aking-advantage-of-a-disaggregated-storage-and-compute-architecture
[4] Dageville B、Cruanes T、Zukowski M、他。 Snowflake エラスティック データ ウェアハウス。[C]// ACM。 ACM、2016年。
[5] Gupta A、Agarwal D、Tan D、他。 Amazon Redshift とよりシンプルなデータ ウェアハウスの事例[C]// Acm Sigmod 国際会議。 ACM、2015年。
[6] Vuppalapati M、Miron J、Agarwal R、他。分散ストレージ上の柔軟なクエリ エンジンの構築[C]//第 17 回 {USENIX} ネットワーク システムの設計と実装に関するシンポジウム ({NSDI} 20)。 2020年:449-462.