クラウド上の OLAP エンジンのクエリパフォーマンス評価フレームワーク: 設計と実装

背景

パブリッククラウドは、ユーザーに経済的で便利なコンピューティングリソースを提供するプラットフォームです。クラウドコンピューティングテクノロジーの急速な発展とビッグデータクエリの需要の増加に伴い、多くのパブリッククラウドのクラウドコンピューティングアプリケーション市場には、ますます多くのクラウド OLAP エンジンサービスが登場しています。ビジネスニーズに応じて適切な OLAP エンジンを選択し、適切な構成を通じてエンジンを最適に動作させるには、ユーザーは現在使用しているクエリエンジンのパフォーマンスを評価する必要があります。

現在の OLAP エンジンパフォーマンス評価フレームワークは、クラウドに展開する場合、次の 3 つの大きな課題に直面します。

クラウド環境への適応性が低い。従来のパフォーマンス評価フレームワークが最初に作成されたとき、クラウド固有の PaaS、IaaS、SaaS 機能はまだなく、ストレージとコンピューティングの分離に対する適応サポートもありませんでした。クラウド上で OLAP を使用する場合は、クラウドコンピューティング機能を最大限に活用して OLAP エンジンのパフォーマンスを分析する必要があります。
複雑なワークロードを再現する能力が不足しています。ワークロードは、データセット、クエリセット、およびクエリシーケンスで構成されます。従来のパフォーマンス評価フレームワークでは通常、固定されたデータセットとクエリレベルが使用され、クエリシーケンスは主に線形シーケンスになります。最新の OLAP クエリシナリオの複雑さにより、特定のシナリオにおけるデータセットとクエリセットの機能特性、および高同時実行性と複雑なシナリオのサポートに対する要件が高まっています。
クエリのパフォーマンスとクラウド移行コストを総合的に評価することは困難です。従来の評価システム (TPC-H や TPC-DS など) ではコスト要因が反映されません。クラウドリソースがほぼ無制限である環境では、コストを考慮せずに評価すると大きな偏りが生じ、間違った結論につながることもあります。クラウドコンピューティングは、レンタルサーバーの規模をカスタマイズできるという特徴があるため、クラウド上のコストは可変かつ構成可能であり、その単価は時間の経過とともに変動します。ユーザーは、OLAP クエリを最速で実行し、コストをできるだけ節約したいと考えています。したがって、クエリパフォーマンスとクラウドコストを総合的に評価し、ユーザーのニーズに基づいてクラウドサーバーと OLAP エンジンの最もコスト効率の高い組み合わせを提供するためのパフォーマンス評価フレームワークが必要です。

上記の問題に対処するため、南京大学の Gu Rong 教授、Wu Tongyu 博士らは、Apache Kylin コミュニティチームと協力し、Raven と呼ばれるクラウドベースの OLAP エンジンクエリパフォーマンス評価フレームワークを設計および開発しました。

Raven は、OLAP エンジンをクラウドに移行する際に、ユーザーがいくつかの実用的かつ重要な質問に答えられるように設計されています。

実際の運用データに対する実際のワークロード (データロード + クエリ) の場合、クラウド上で実行すると IT コストが低くなる OLAP エンジンはどれですか。
クエリ速度の目標が与えられた場合、どの OLAP エンジンが速度の目標を達成しながらクラウド上で IT コストを削減できるでしょうか?
データがロードされる速度も考慮するとどうなるでしょうか?

この記事では、Raven の設計と実装時に私たちのチームが遭遇した問題、対応する解決策、および現在の予備調査結果を紹介します。

クラウドアーキテクチャに適合したパフォーマンス評価フレームワークの設計

OLAP エンジンクエリパフォーマンス評価フレームワークをクラウドアーキテクチャに適応させると、実際にはクラウド上の PaaS、IaaS、および SaaS 機能に適応することになります。具体的には、クラウドサーバーの多くの機能がサービスの形でユーザーに提供されます。ユーザーは、クラウドサーバーの作成、ファイル操作、パフォーマンス指標の取得、アプリケーションの実行など、さまざまな目的を達成するために、対応するサービスインターフェイスを呼び出すだけで済みます。ファイル操作では、クラウドサーバーはコンピューティングとストレージを分離したアーキテクチャを使用しているため、一部のデータはサービスを通じてリモートクラウドストレージサービスから取得する必要がある場合があります。

図1: パブリッククラウドプラットフォームに基づくRavenパフォーマンス評価フレームワーク

上記の要件を組み合わせた Raven のフレームワークを図 1 に示します。実行手順は次のとおりです。

ユーザーは、パフォーマンステスト構成情報を入力してパフォーマンステスト起動モジュールをトリガーします。このモジュールは、ユーザー構成に従ってクラウド上で OLAP パフォーマンステストを開始するために必要なクラウドサーバーとコンピューティング環境を作成します。
パフォーマンステスト起動モジュールは、ワークロード、データセット、パフォーマンスインジケーター、エンジンパラメーターなどの情報を構成制御および配布モジュールに渡します。構成制御および配布モジュールは、上記の情報を対応するサービスインターフェイスまたはモジュールに配布する役割を担います。
構成制御および配布モジュールはワークロード実行モジュールをトリガーし、ワークロード実行モジュールは構成された OLAP エンジンを起動し、ワークロード設定に従って時間の経過とともに OLAP エンジンにクエリ要求を送信します。
OLAP エンジンは、ローカルストレージまたはクラウドストレージからデータセットを取得し、クエリを実行します。クエリ実行中、ワークロード実行モジュールはクエリの開始タイムスタンプと終了タイムスタンプを記録し、リソース管理サービスを開始して、クエリ中の OLAP エンジンのパフォーマンスインジケーターを監視します。クエリの最後に、ワークロード実行モジュールはタイムスタンプとパフォーマンスメトリック情報をクラウドストレージに出力します。
パフォーマンス分析およびスコアリングモジュールを起動し、リモートクラウドストレージからタイムスタンプとパフォーマンスインジケーターの情報を取得し、ユーザー定義のスコアリングモデルをインポートして、最終的なパフォーマンス評価結果を取得します。

上記の設計の利点は次のとおりです。

カスタマイズ可能なクラウドサーバーの数と構成を活用して、ユーザーが作成するクラスター環境をカスタマイズできるようにします。
クラウド環境のストレージとコンピューティングの分離アーキテクチャに適応し、リモートクラウドストレージサービスへのデータの読み取りと書き込みをサポートします。
クラウドサービスプロバイダーのリソース管理サービスを利用すると、システムリソースの使用状況に関する多くの情報を取得できます。
プラグ可能なエンジンインターフェイスをサポートしており、ユーザーはテストに必要な OLAP エンジンとその構成を指定できます。

実際の使用では、ユーザー入力は .yaml ファイルで提示され、次のようにフォーマットされます。

エンジン: キリン
ワークロード: tpc-h
test_plan: ワンパス
メトリクス: すべて

ユーザーが必要とするクラウドサーバーの数、各マシンの構成、さまざまなエンジンなどはすべて、JSON ファイルを通じて構成できます。

イベントとタイムスタンプに基づくワークロード設計

従来の OLAP クエリエンジンは通常、固定データセットとクエリセットを使用し、一連のクエリを実行して OLAP エンジンのクエリパフォーマンスを確認します。しかし、多くの業界では作業負荷が複雑化しています。

自社のデータとビジネスには明確な特性があることを認識し、与えられたデータ特性に基づいて最適な OLAP クエリソリューションを取得したいと考える企業が増えています。
従来の OLAP クエリに加えて、ETL、インデックス、Kylin's Cube などの事前計算テクノロジを OLAP エンジンのパフォーマンス評価に含める必要があります。
データ量の急速な増加により、同時実行性の高いクエリや可変 QPS クエリのシナリオが増加しています。従来の線形クエリ方法では、これらの新しいシナリオを正確に評価することは困難です。

Raven はタイムラインベースのイベントメカニズムを使用して、複雑な OLAP 作業シナリオを記述します。このメカニズムでは、ワークロードは複数のステージで構成され、ステージは複数のイベントで構成されます。タイムラインでは、ワークロードは複数のステージの順次実行として記述されます。各ステージはオンラインとオフラインの 2 つのステージに分かれています。オンラインステージでは実際のクエリ要求が実行され、オフラインステージでは事前計算やその他の操作が実行されます。イベントは、ワークロード内の各アトミック実行ユニットを抽象化したものであり、クエリ要求、シェルコマンド、または Python などのプログラミング言語で記述されたスクリプトなどです。

図2: Ravenワークロードの実行プロセス

Raven のワークロードを図 2 に示します。実行手順は次のとおりです。

最初のフェーズを開始し、ワークロード構成、エンジン構成などを読み込みます。
イベントのタイマーがトリガーされると、コントローラによってタイムイベントが生成され、イベントに対応するクエリ文またはスクリプトの内容が読み取られ、イベントに対応するクエリ文またはスクリプトの内容がイベント実行キューに入力されて実行を待機します。
イベント実行キューを抜けた後、イベント実行コントローラに入り、スレッド実行フック関数を起動し、OLAP エンジンまたはコマンドラインで対話型操作を実行し、応答を待ちます。応答を受信すると、イベントはリソース収集キューに挿入されます。
リソース収集キューを離れた後、イベントリソース収集コントローラに入り、操作のタイムスタンプ情報をクラウドストレージサービスに出力します。
ステージ内のすべての時間が完了すると、次のステージが開始され、ワークロード全体が完了するまで各ステージが順番に実行されます。

上記の設計の利点は次のとおりです。

カスタムデータセットとクエリセットをサポートし、ユーザーはビジネス特性を最大限に活用してパフォーマンス評価を行うことができます。
事前計算をサポートし、ユーザーは事前計算と実際のクエリの全体的なパフォーマンスを評価できます。
タイムスタンプを使用した実行方法とスレッド管理戦略により、高同時クエリがサポートされ、時間の経過と共に QPS が変動するワークロードのシミュレーションが可能になります。

たとえば、次の .yaml 構成ファイルを使用して、AWS 上で 1 つのマスターと 4 つのスレーブを持つ EC2 クラスターを起動し、データセットを SSB (SF=100) に指定し、ワークロードをポアソン分布 (λ=3.0) を満たすように指定し、ワークロードの継続時間を 600 秒に指定して Presto エンジンをデプロイできます。

雲：

名前: AWS
説明: Amazon Web サービス。

プロパティ:

地域: ap-southeast-1
Ec2キー名: key_raven
マスターインスタンス数: 1
マスターインスタンスタイプ: m5.xlarge
コアインスタンス数: 4
コアインスタンスタイプ: m5.4xlarge

エンジン：

名前: プレスト
説明: プレスト。
プロパティ:
ホスト: ローカルホスト
ポート: 8080
ユーザー: hive
カタログ: ハイブ
同時実行数: 1

テスト計画:

名前: タイムラインテンプレート。

プロパティ:

タイプ: タイムライン
パス: config/testplan/template/timeline_template.yaml

作業負荷:

名前: SSB
タイプ: QPS

パラメータ:

データベース: ssb_100
分布: ポアソン
所要時間: 600
ラム: 3.0

Raven は、均一分散、バースト高同時実行分散など、ユーザーが使用できるいくつかの一般的なワークロードを事前に設定しています。

カスタム多変量関数に基づくパフォーマンス評価モデル

パフォーマンス評価の観点では、クラウドマシンはサイズや構成をカスタマイズできるのが特徴だ。したがって、クエリのパフォーマンスだけを考えれば、高性能なデバイスを大量にレンタルすることで理論的にはパフォーマンスを向上させることができます。しかし、これによりクラウドコンピューティングのコストも急騰することになります。したがって、パフォーマンスとコストのバランスと包括的な考慮を実現するための一連のメカニズムが必要です。

Raven のパフォーマンス評価方法は高度にカスタマイズされており、ユーザーは関数式を使用して利用可能なパラメータインジケーターを組み合わせて評価スコアを取得できます。

Raven で使用できるパラメータインジケーターは、主に次のカテゴリに分類されます。

クエリ品質指標: 合計クエリ時間、平均クエリ時間、クエリ時間の 95% 分位値、およびすべてのクエリの最大クエリ時間など。
リソース使用効率: 平均メモリおよび CPU 使用率、負荷分散、リソース使用率が合計時間の 90% を超える時間の割合。
クラウド上の金銭的コスト: クラウドサービスプロバイダーが提供するアプリケーションサービスを通じて直接取得でき、主にストレージ、コンピューティング、サービス呼び出し、ネットワーク伝送の 4 つの部分の費用が含まれます。

Raven による評価は相対的なものであり、同じモデルの評価間でのみ比較できます。パフォーマンス評価スコアは、クラウドコストとクラウドオーバーヘッドの積です。スコアが低いほど、OLAP エンジンのパフォーマンスは向上します。クラウドのオーバーヘッドは、線形モデルを使用して上記のパラメータに重みを割り当てることで計算できます。または、非線形モデルを使用して上記のパラメータを関数式に代入します。

Raven は、ユーザーに一連のテンプレート関数も提供します。

包括的モデル: PTO=10×ln(PoC×(ravg+qavg))PTO=10×ln⁡(PoC×(ravg+qavg))。
速度優先モデル：PTO=10×ln(ravg+qavg)PTO=10×ln⁡(ravg+qavg)
予算優先モデル: PTO=11+e8(b−PoC)×(ravg+qavg)PTO=11+e8(b−PoC)×(ravg+qavg)
クエリ効率モデル: PTO=PoC×qmax+5q95%+94qavg100PTO=PoC×qmax+5q95%+94qavg100
クエリブロッキングモデル: PTO=PoC×ln(rmax )PTO=PoC×ln⁡(rmax )

このうち、PTO はパフォーマンススコア、PoC はクラウドコスト、ravgravg と qavgqavg はそれぞれ平均応答時間と平均実行時間、rmaxrmax と qmaxqmax はそれぞれ最大応答時間と最大実行時間、b は予算額、q95%q95% はクエリ時間の 95% 分位数を表します。ここでは、前回の記事でユーザーが注意する必要がある実際的な問題について確認します。予算優先順位モデルが主に「クラウドで実行する場合、どの OLAP エンジンの IT コストが低くなるか」を評価して回答するために使用されていることは容易に理解できます。速度優先モデル、クエリ効率モデル、クエリブロッキングモデルは主に、さまざまなクエリ応答制約を満たしながらクラウド上で実行コストが低い OLAP エンジンを評価して回答するために使用されます。総合モデルは、コスト予算とクエリ応答効率を総合的に考慮してさまざまな重みを設定し、OLAP エンジンを評価するクラウドパフォーマンスモデルです。

実施と効果検証

上記の Raven の設計を Amazon AWS に実装し、パフォーマンス評価フレームワークを使用して OLAP エンジンを実行し、さまざまなエンジンのクエリ効果を確認しました。

図3: 異なるスコアリングモデルで平均クエリを10分間実行したさまざまなエンジンのパフォーマンススコア

図4: PrestoとKylinで実行されているバースト性の高い同時実行性ディストリビューションのパフォーマンススコア

図 3 からわかるように、均一なクエリを実行する場合、Athena と Kylin の方が優れたソリューションです。ただし、異なるモデルを使用すると、評価の結論も異なります。クエリ速度とクラウドコストを考慮すると、Athena はサービスを呼び出して直接クエリを実行するため、クラウドコストが低く、スコアも低くなります。ただし、速度を優先する場合、Kylin は事前計算テクノロジを使用して高速クエリを実現するため、速度優先モデルを使用するとスコアが低くなります。

図 4 からわかるように、バースト高同時実行分散を実行する場合、クエリブロッキングモデルを使用すると、同時に入力されるクエリの数が増えるにつれて、Presto のパフォーマンススコアはクエリの数に比例して増加します。ただし、Kylin はクエリ数の増加による影響を受けず、パフォーマンススコアは安定しています。これは、Kylin の事前計算テクノロジによって計算効率が向上するためです。大量のクエリが流入した場合、Kylin はこれらのクエリをより高い効率で処理し、キュー内のクエリの混雑を軽減し、パフォーマンススコアを向上させることができます。もちろん、ユーザーセット内のクエリの数が多くない場合は、事前計算関連のオーバーヘッドがないため、Presto のパフォーマンススコアの方が有利になります。