翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Spark 結果フラグメントキャッシュ
Amazon EMR 6.6.0 以降には、結果フラグメントを自動的にキャッシュする Spark 結果フラグメントキャッシュ機能がオプションとして含まれています。これらの結果フラグメントは、選択した Amazon S3 バケットに保存されているクエリのサブツリーからの結果の一部です。保存されたクエリ結果のフラグメントは、その後のクエリ実行で再利用されるため、クエリが高速になります。
結果フラグメントキャッシュは、Spark SQL クエリを分析し、対象となる結果フラグメントを指定した S3 の場所にキャッシュすることで機能します。その後のクエリ実行時に、使用可能なクエリ結果のフラグメントが自動的に検出され、S3 から取得されます。結果フラグメントキャッシュは結果セットキャッシュとは異なります。結果セットキャッシュでは、後続のクエリが元のクエリと完全に一致しないとキャッシュから結果を返しません。データの静的サブセットを繰り返しターゲットとするクエリに使用する場合、結果フラグメントキャッシュはパフォーマンスを大幅に向上させます。
2022年までの注文をカウントする次のクエリを考えてみましょう。
select l_returnflag, l_linestatus, count(*) as count_order from lineitem where l_shipdate <= current_date and year(l_shipdate) == '2022' group by l_returnflag, l_linestatus
時間が経つにつれて、このクエリを毎日実行して、その年の総売上を報告する必要があります。結果フラグメントキャッシュがないと、その年のすべての日の結果を毎日再計算する必要があります。クエリは時間が経つにつれて遅くなり、365 日分の結果をすべて再計算する必要がある年末に最も遅くなります。
結果フラグメントキャッシュを有効にすると、キャッシュからその年の過去すべての日の結果を使用します。フィーチャが毎日再計算する必要があるのは 1 日分の結果だけです。フィーチャが結果フラグメントを計算すると、フィーチャはフラグメントをキャッシュします。その結果、キャッシュを有効にしたクエリ時間は速く、後続のクエリでも一定に保たれます。
Spark 結果フラグメントキャッシュの有効化
Spark 結果フラグメントキャッシュを有効にするには、以下の手順を実行します。
-
Amazon S3 にキャッシュバケットを作成し、EMRFS の読み取り/書き込みアクセスを許可します。詳細については、「Amazon S3 内の EMRFS データへのアクセスを許可する」を参照してください。
-
EMR Spark 設定を設定して、この機能を有効にします。
spark.subResultCache.enabled = true spark.subResultCache.fs.root.path = s3://DOC-EXAMPLE-BUCKET/cache_dir/
-
バケットの S3 ライフサイクル管理を有効にして、キャッシュファイルを自動的にクリーンアップします。
-
オプションで、 reductionRationThreshold maxBufferSizeおよびプロパティを設定して機能をさらに調整します。
spark.sql.subResultCache.reductionRatioThreshold spark.sql.subResultCache.maxBufferSize
結果フラグメントキャッシュを使用するときの考慮事項
Amazon S3 にすでにキャッシュされている結果を再計算せずに使用した場合のコスト削減額は、同じキャッシュされた結果を使用できる回数が増えるほど大きくなります。大規模なテーブルスキャンの後に結果サイズを少なくとも 8 分の 1 に縮小する (つまり、入力サイズと結果の比率が少なくとも 8:1 の) フィルターまたはハッシュ集計を行うクエリには、この機能の最大のメリットがあります。入力と結果の削減率が大きいほど、コストメリットが大きくなります。結果を生成するコストが Amazon S3 から結果を取得するコストよりも大きい限り、削減率は小さいけれども、テーブルスキャンとフィルターまたは集計の間の計算ステップが高価なクエリにもメリットがあります。デフォルトでは、結果フラグメントキャッシュは、削減率が 8:1 以上になることを検出した場合にのみ有効になります。
クエリがキャッシュされた結果を繰り返し再利用する場合、この機能の利点が最も大きくなります。ローリングウィンドウクエリやインクリメンタルウィンドウクエリが良い例です。たとえば、30 日間のローリングウィンドウクエリがすでに 29 日間実行されている場合、元の入力ソースからターゲットデータの 30 分の 1 を取得するだけでよく、過去 29 日間のキャッシュされた結果フラグメントを使用します。インクリメンタルウィンドウクエリは、ウィンドウの開始が固定されたままなので、さらにメリットがあります。クエリを呼び出すたびに、入力ソースからの読み取りを必要とする処理の割合は少なくなります。
結果フラグメントキャッシュを使用する際のその他の考慮事項は次のとおりです。
-
同じクエリフラグメントを持つ同じデータをターゲットとしないクエリは、キャッシュヒット率が低くなるため、この機能のメリットはありません。
-
削減率が低く、コストのかかる計算ステップを含まないクエリでは、キャッシュされた結果の読み取りコストは、最初の処理とほぼ同じです。
-
最初のクエリでは、キャッシュへの書き込みコストがかかるため、常に軽微なリグレッションが発生します。
-
結果フラグメントキャッシュ機能はParquetファイルでのみ機能します。他のファイル形式はサポートされていません。
-
結果フラグメントキャッシュ機能のバッファは、ファイル分割サイズが 128 MB 以上のスキャンのみをキャッシュしようとします。デフォルトのSpark構成では、スキャン・サイズ(スキャンされるすべてのファイルの合計サイズ)をエグゼキューター・コアの数で割った値が128 MB未満の場合、結果フラグメント・キャッシュは無効になります。以下の Spark 構成のいずれかを設定すると、ファイル分割サイズは次のようになります。
min(maxPartitionBytes, max(openCostInBytes, scan size / minPartitionNum))
-
spark.sql。 leafNodeDefault並列処理 (デフォルト値は spark.default.parallelism)
-
スパーク.sql ファイル。 minPartitionNum (デフォルト値は spark.sql です。 leafNodeDefault並列処理)
-
スパーク.sql ファイル。 openCostInバイト
-
スパーク.sql ファイル。 maxPartitionBytes
-
-
結果フラグメントキャッシュ機能は、RDD パーティション単位でキャッシュします。前述の削減率(デフォルトは 8:1)は、RDD パーティションごとに評価されます。RDD あたりの削減率が 8:1 よりも大きい場合と小さい場合の両方で、RDD あたりの削減率が常に 8:1 未満のワークロードよりもパフォーマンス上のメリットが小さい場合があります。
-
Result Fragment Caching 機能では、キャッシュされる RDD パーティションごとに 16MB の書き込みバッファがデフォルトで使用されます。RDD パーティションごとに 16 MB を超える書き込みバッファがキャッシュされる場合、書き込みが不可能であると判断するコストによってパフォーマンスが低下する可能性があります。
-
デフォルトでは、Result Fragment Caching は 8:1 未満の縮小率で RDD パーティションの結果をキャッシュしようとせず、書き込みバッファの上限を 16MB に設定しますが、これらの値は両方とも次の構成で調整できます。
spark.sql.subResultCache.reductionRatioThreshold (default: 8.0) spark.sql.subResultCache.maxBufferSize (default: 16MB, max: 64MB)
-
同じ EMR リリースを使用する複数のクラスターが同じキャッシュ場所を共有できます。結果の正確性を確保するため、結果フラグメントキャッシュでは Amazon EMR のさまざまなリリースで書き込まれたキャッシュ結果を使用しません。
-
結果フラグメントキャッシュは、Spark ストリーミングのユースケースや、Apache Ranger RecordServer、AWS Lake Formationまたはが使用されている場合は自動的に無効になります。
-
結果フラグメントキャッシュの読み取り/書き込みには EMRFS と Amazon S3 バケットを使用します。CSE/SSE S3/SSE KMS 暗号化がサポートされています。