Spark 결과 조각 캐싱 - 아마존 EMR

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

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일 분량의 결과를 모두 다시 계산해야 하는 연말에는 속도가 가장 느려집니다.

결과 조각 캐싱을 활성화하면 캐시에 있는 해당 연도의 모든 이전 날짜에 대한 결과를 사용합니다. 이 기능은 매일 하루의 결과만 다시 계산하면 됩니다. 기능이 결과 조각을 계산한 후 해당 조각을 캐싱합니다. 따라서 캐시를 사용하는 쿼리 시간이 빨라지고 후속 쿼리마다 일정한 시간이 유지됩니다.

Spark 결과 조각 캐싱 활성화

Spark 결과 조각 캐싱을 활성화하려면 다음 단계를 수행합니다.

  1. Amazon S3에 캐시 버킷을 생성하고 에 대한 읽기/쓰기 액세스를 승인합니다. EMRFS 자세한 내용은 Amazon S3의 EMRFS 데이터에 대한 액세스 권한 부여 단원을 참조하십시오.

  2. Amazon EMR Spark 구성을 설정하여 이 기능을 활성화합니다.

    spark.subResultCache.enabled = true spark.subResultCache.fs.root.path = s3://DOC-EXAMPLE-BUCKET/cache_dir/
  3. 버킷의 S3 수명 주기 관리를 활성화하여 캐시 파일을 자동으로 정리합니다.

  4. 필요에 따라 reductionRationThreshold 및 maxBufferSize 속성을 구성하여 기능을 추가로 조정할 수 있습니다.

    spark.sql.subResultCache.reductionRatioThreshold spark.sql.subResultCache.maxBufferSize

결과 조각 캐싱 사용 시 고려 사항

다시 계산하는 대신 Amazon S3에 이미 캐시된 결과를 사용할 경우 동일한 캐시된 결과를 사용할 수 있는 횟수만큼 비용 절감 효과가 커집니다. 대형 테이블을 스캔한 후 결과 크기를 8배 이상 줄이는 필터 또는 해시 집계(즉, 입력 크기 대 결과의 비율이 8:1 이상인 경우)를 사용하는 쿼리에서는 이 기능을 최대한 활용할 수 있습니다. 입력과 결과 간의 감소 비율이 클수록 비용상의 이점도 커집니다. 감소 비율은 작지만 테이블 스캔과 필터 또는 집계 사이에 비용이 많이 드는 계산 단계가 포함된 쿼리도 결과를 생성하는 데 드는 비용이 Amazon S3에서 결과를 가져오는 데 드는 비용보다 큰 경우 비용이 절감됩니다. 기본적으로 결과 조각 캐싱은 감소 비율이 8:1 이상일 것으로 감지되는 경우에만 유효합니다.

쿼리가 캐시된 결과를 반복적으로 재사용하는 경우 이 기능의 이점이 가장 큽니다. 롤링 및 증분 기간 쿼리가 좋은 예입니다. 예를 들어 이미 29일 동안 실행된 30일의 롤링 기간 쿼리는 원래 입력 소스에서 대상 데이터의 1/30만 가져오면 되고 이전 29일 동안 캐시된 결과 조각을 사용합니다. 증분 기간 쿼리는 기간의 시작 위치가 고정되어 있기 때문에 훨씬 더 유용합니다. 쿼리를 간접 호출할 때마다 입력 소스에서 읽어야 하는 처리 비율이 줄어듭니다.

결과 조각 캐싱을 사용할 때 고려해야 할 추가 사항은 다음과 같습니다.

  • 동일한 쿼리 조각을 포함하는 동일한 데이터를 대상으로 하지 않는 쿼리는 캐시 적중률이 낮으므로 이 기능을 활용할 수 없습니다.

  • 비용이 많이 드는 계산 단계를 포함하지 않고 감소 비율이 낮은 쿼리에서는 캐시된 결과에서는 처음에 처리할 때와 읽기 비용이 거의 같습니다.

  • 캐시에 쓰는 데 드는 비용 때문에 첫 번째 쿼리에서는 항상 약간의 회귀가 나타납니다.

  • 결과 조각 캐싱 기능은 Parquet 파일에서만 작동합니다. 다른 파일 형식은 지원되지 않습니다.

  • 결과 조각 캐싱 기능 버퍼는 파일 분할 크기가 128MB 이상인 스캔만 캐시하려고 시도합니다. 기본 Spark 구성에서 스캔 크기(스캔 중인 모든 파일의 총 크기)를 실행기 코어 수로 나눈 값이 128MB 미만이면 결과 조각 캐싱이 비활성화됩니다. 아래 나열된 Spark 구성 중 하나를 설정하는 경우 파일 분할 크기는 다음과 같습니다.

    min(maxPartitionBytes, max(openCostInBytes, scan size / minPartitionNum))
    • spark.sql. leafNodeDefault병렬성 (기본값은 spark.default.parallelism)

    • 스파크.sql.files. minPartitionNum (기본값은 spark.sql 입니다. leafNodeDefault병렬성)

    • .sql.file을 스파크 처리하십시오. openCostIn바이트

    • .sql.files를 스파크. maxPartitionBytes

  • 결과 프래그먼트 캐싱 기능은 파티션 단위로 캐싱합니다RDD. 앞에서 설명한 감소율 (기본값 8:1) 을 파티션별로 평가합니다. RDD RDD감소율 감소율이 8:1 미만인 워크로드는 감소율 비율이 지속적으로 8:1 미만인 RDD 워크로드보다 성능상의 이점이 적을 수 있습니다.

  • 결과 프래그먼트 캐싱 기능은 캐시되는 각 RDD 파티션에 기본적으로 16MB 쓰기 버퍼를 사용합니다. 파티션당 RDD 16MB 이상을 캐시할 경우 쓰기 불가능 여부를 판단하는 데 드는 비용으로 인해 성능이 저하될 수 있습니다.

  • 기본적으로 Result Fragment Caching은 감소율이 8:1 미만인 RDD 파티션 결과를 캐시하려고 시도하지 않고 쓰기 버퍼를 16MB로 제한하지만 다음 구성을 통해 이 두 값을 모두 조정할 수 있습니다.

    spark.sql.subResultCache.reductionRatioThreshold (default: 8.0) spark.sql.subResultCache.maxBufferSize (default: 16MB, max: 64MB)
  • 동일한 Amazon EMR 릴리스를 사용하는 여러 클러스터는 동일한 캐시 위치를 공유할 수 있습니다. 결과의 정확성을 보장하기 위해 결과 프래그먼트 캐싱은 여러 Amazon 릴리스에서 작성한 캐시 결과를 사용하지 않습니다. EMR

  • 결과 프래그먼트 캐싱은 Spark Streaming 사용 사례 또는 Apache Ranger를 사용하는 경우 자동으로 비활성화됩니다. RecordServer AWS Lake Formation

  • 결과 프래그먼트 캐시 읽기/쓰기 사용 및 EMRFS Amazon S3 버킷 CSE/SSES3/ 암호화가 지원됩니다 SSEKMS.