4

Presto には複数のコネクタがあります。コネクタは読み取りおよび書き込み操作を実装していますが、私が読んだすべてのチュートリアルから、コネクタは通常、読み取り専用のデータ ソースとして使用されているようです。たとえば、netflixでは Amazon S3 に「10 ペタバイト」のデータがあり、Presto ワーカー ノードではディスク (および HDFS) が使用されていないと明示的に述べています。記載されているユース ケースは、「アドホック インタラクティブ」クエリです。

また、Amazon Athena は本質的に S3+Presto であり、同様のユース ケースが付属しています。

これが実際にどのように機能するのか、私は困惑しています。当然のことながら、すべてのクエリで 10 PB のデータを読み取る必要はありません。したがって、データベースのインデックスなど、以前にフェッチしたデータをメモリに保持したいと考えています。ただし、データとクエリに制約がないため、これがどのように効率的であるかを理解できません。

ユース ケース 1: ダッシュボードにメトリックを表示するなど、同じクエリを頻繁に実行します。Presto は、既に「既知」のデータ ポイントの再スキャンを回避しますか?

ユース ケース 2: 大規模なデータ セットを分析しています。各クエリはわずかに異なりますが、共通のサブクエリがあるか、データの共通のサブセットにフィルターをかけます。Presto は以前のクエリから学習し、中間結果を引き継いでいますか?

または、そうでない場合は、中間結果をどこかに保存することをお勧めしますか (たとえば、CREATE TABLE AS ...)?

4

3 に答える 3

1

Presto クエリのレイテンシを改善するための一般的な最適化は、ワーキング セットをキャッシュして、リモート データ ソースや低速ネットワークからの不要な I/O を回避することです。このセクションでは、Alluxio を Presto のキャッシング レイヤーとして活用するための次のオプションについて説明します。

Alluxio File System は、HDFS または AWS S3、GCP、Azure ブロブ ストアなどのオブジェクト ストア上の独立した分散キャッシュ ファイル システムとして Presto Hive Connector を提供します。ユーザーは、キャッシュの使用状況を把握し、ファイル システム インターフェイスを介して明示的にキャッシュを制御できます。たとえば、Alluxio ディレクトリ内のすべてのファイルをプリロードして Presto クエリのキャッシュをウォームアップし、キャッシュされたデータの TTL (time-to-live) を設定してキャッシュ容量を再利用できます。

Alluixo 構造化データ サービスは、オプション 1 に基づいて、カタログとキャッシュ ファイル システムの両方を使用して Presto とやり取りします。このオプションは、オプション 1 に加えて、Hive メタストア上のテーブルの場所を変更せずに既存の Hive テーブルにシームレスにアクセスし、多数の小さなファイルを統合するか、入力ファイルの形式を変換することにより、パフォーマンスをさらに最適化するという点で、追加の利点を提供します。

出典: Presto Alluxio キャッシュ サービス

于 2020-10-19T09:22:13.290 に答える