Spark Relational Cache implements interactive analysis of sub-second response

1. プロジェクトの概要

プロジェクトの背景

Alibaba Cloud EMR はオープンソースのビッグデータソリューションです。現在、EMR は多くのオープンソースコンポーネントを統合しており、その数も増加し続けています。EMR の下層では、Object Storage Service (OSS)、クラスター内に自社構築した HDFS、ストリーミングデータなど、さまざまなストレージにアクセスできます。ユーザーは EMR を使用して大量のデータを処理し、迅速な分析を行うことができます。また、機械学習やデータクレンジングもサポートしています。EMR は非常に大量のビジネスデータをサポートし、データの増加に伴うクラスターの拡張による迅速なデータ分析の実現を目指しています。

クラウド上のアドホックデータ分析の課題

クラウド上でアドホックデータ分析を行う場合、データ量が増加してもクエリ遅延が顕著に増加しないようにすることは困難です。さまざまなエンジンが登場しており、一部のエンジンは特定のシナリオでは非常に高速に動作しますが、データ量が増加するとクエリ応答速度は必然的に低下します。そのため、より統一されたプラットフォームで優れたパフォーマンスを得たいと考えています。同時に、Alibaba Cloud はクラウドネイティブソリューションの提供も目指しています。Spark は現在、業界で最も広く使用されているコンピューティングエンジンであり、広く普及していますが、アドホック処理にはまだ多くの課題があります。そこで、Alibaba Cloud は Spark に多くの最適化を施し、ユーザーがアドホッククエリのニーズを満たせるよう支援しています。そのため、キャッシュスキームが導入されています。Spark には以前からキャッシュメカニズムがありますが、クラウド上のアドホックシナリオを満たすには多くの不備があります。そこで、Alibaba Cloud は Spark に多くの最適化を施し、ユーザーのアドホッククエリ速度の最適化を支援しています。ただし、データをメモリに保存するだけでは、すべてのデータをキャッシュとして使用するには不十分な場合があります。ここに Spark Relational Cache が登場します。


Spark Relational Cache

ユーザーの SQL リクエストが Spark に到着した後、データソースの処理に長い時間がかかります。ここで、下層ストレージにはクラスター HDFS、リモート JindoFS、Alibaba Cloud OSS などがあります。Spark Relational Cache が利用可能な場合、クエリ終了後に Relational Cache に保存されたキャッシュデータを使用できるかどうかをクエリします。使用できない場合は元のパスに転送されます。使用可能な場合は、キャッシュからデータが読み取られ、結果がユーザーに返されます。Relational Cache は効率的なストレージ上に構築されており、ユーザーの DDL を通じてデータが Relational Cache に変換されます。

Spark Relational Cache の機能

Spark Relational Cache は秒レベルまたはサブセカンドレスポンスの実現を目指し、SQL を送信した後すぐに結果を確認できます。また、大量のデータをサポートし、永続ストレージ上に保存されます。同時に、いくつかのマッチング方法を通じて、マッチングシナリオを増やしています。さらに、下層ストレージではカラムナーストレージなど効率的なストレージフォーマットを使用しており、オフライン分析用であり、カラムナーストレージに対して大幅な最適化が施されています。さらに、Relational Cache はユーザー透明性の機能でもあります。ユーザーはクエリ時に複数のテーブル間の関係を認識する必要はなく、数人の管理者がメーカーのためにメンテナンスを行う必要があります。Spark Relational Cache は自動更新をサポートしています。ユーザーは、新しいデータの挿入により Cache が古くなり、誤ったデータをクエリすることを心配する必要はありません。ユーザーが更新を支援するための設定ルールが提供されています。さらに、Spark Relational Cache は研究開発において多くの探索を行っており、インテリジェントレコメンデーションなどがあります。たとえば、ユーザーの SQL 履歴に基づいて、どの関係に基づいて Relational Cache を構築するかを推奨できます。

2. 技術分析

Alibaba Cloud EMR には、データ事前計算、クエリ自動マッチング、データ事前編成など、多くのコア技術があります。

データ事前計算

データには多くの場合、モデルがあります。スノーフレークモデルは、従来のデータベースで非常に一般的なモデルです。Alibaba Cloud EMR では Primary Key / Foreign Key のサポートを追加し、ユーザーが Primary Key / Foreign Key を通じてテーブル間の関係を指定できるようにし、マッチング成功率を向上させています。データ事前計算では、EMR Spark の強化されたコンピューティング能力を十分に活用しています。さらに、Data Cube データキューブを通じて多次元データ分析がサポートされています。

実行プランの書き換え

この部分では、まずデータ事前計算を通じて事前計算結果を生成し、その結果を外部ストレージ（OSS、HDFS、その他のサードパーティストレージなど）に保存します。Spark DataSource などのデータフォーマットや、DataLake などの人気のあるストレージフォーマットをサポートしています。サポートも追加される予定です。従来のデータベースには同様の最適化スキーム（マテリアライズドビュー方式など）がありますが、Spark でこの方法を使用するのは適切ではありません。ロジックマッチングは Catalyst ロジックオプティマイザー内部に配置され、ロジック実行プランを書き換えて、クエリが Relational Cache を通じて実現できるかどうかを判断し、Relational Cache に基づくさらなる Join または組み合わせを実現します。簡略化されたロジックプランを物理プランに変換し、物理エンジン上で実行します。EMR Spark の他の最適化方向に依存することで、非常に高速な実行結果を得ることができ、スイッチを通じて実行プランの書き換えを制御します。

クエリ自動マッチング

ここでは簡単な例を挙げます。3 つのテーブルを単純に結合し、フィルター条件後に最終結果を取得します。クエリが届いたら、まず Spark Relational Cache が要件を満たせるかどうかを判断し、事前計算結果のフィルターを実現し、最終的な目的の結果を取得します。

データ事前編成

ストレージに数十テラバイトのデータが保存されている場合、この関係から最終結果を取得するには多くの時間がかかります。多くのタスクノードを起動する必要があり、これらのタスクのスケジューリングにも多くのオーバーヘッドが必要だからです。ファイルインデックス方法により、時間オーバーヘッドを秒レベルに圧縮でき、実行中に読み取るファイルの総量をフィルターできるため、タスク数が大幅に削減され、実行速度が大幅に向上します。グローバルインデックスをより効果的にする必要があるため、データをソートすることが最適です。構造化データをソートする場合、最初のキーに対してのみ非常に優れた最適化効果があることがわかります。ソートの後続のキーについてはより困難なため、ZOrder ソートが導入され、リストされた各列が同じ効果を持つようになります。同時に、データはパーティションテーブルに保存され、GroupID がパーティション列として使用されます。

3. 使用方法

DDL

シンプルなクエリでは、自動更新スイッチを指定し、後続の管理を容易にするために名前を付けることができます。データレイアウトの形式も指定でき、最後に SQL 文を通じて関係を記述し、ユーザーに WebUI と同じものを提供して、ユーザーが Relational Cache を管理しやすくします。

データ更新

Relational Cache のデータ更新には主に 2 つの戦略があります。1 つは On Commit です。たとえば、依存データが更新されたときに、追加が必要なすべてのデータを追記書き込みできます。もう一つはデフォルトの On Demand 形式で、ユーザーが Refresh コマンドを通じて手動で更新をトリガーします。作成時に指定することも、作成後に手動で調整することもできます。Relational Cache の増分更新はパーティションに基づいて実装されています。将来的には、よりインテリジェントなストレージフォーマットを統合して、行レベル更新をサポートすることを検討しています。

4. パフォーマンス分析

Cube ビルド

Alibaba Cloud EMR Spark は、1 TB のデータ構築にわずか 1 時間しかかかりません。

クエリパフォーマンス

クエリパフォーマンスでは、SSB の平均クエリ時間消費において、キャッシュがない場合、クエリ時間はスケールに比例して増加し、キャッシュキューブは常にサブセカンドレスポンスを維持します。