Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey.
효율적인 데이터 스토리지 및 쿼리를 위해 Iceberg 테이블을 관리하고 최적화하려면 어떻게 해야 합니까?
효율적인 데이터 스토리지 및 쿼리를 위해 Apache Iceberg 테이블을 최적화하고 싶습니다.
해결 방법
사용 사례에 맞는 Iceberg 테이블 유형을 선택합니다.
해결 방법 선택은 설정한 Iceberg 테이블의 유형에 따라 달라집니다.
읽기에 CoW(Copy-On-Write) 테이블 사용
이 유형의 Iceberg 테이블에서는 레코드에 대한 모든 업데이트 또는 삭제 작업을 수행하면 백엔드에서 해당하는 데이터 파일에 다시 씁니다. 다시 쓰기는 성능을 낮추며 특히 여러 번의 업데이트와 삭제에서 성능이 저하됩니다. 사용 사례에 쓰기 대신 읽기가 더 많은 경우는 CoW 테이블을 사용하십시오.
기존 Iceberg 테이블을 CoW 테이블로 변환하려면 다음 Apache Spark SQL 명령을 실행합니다.
spark.sql("ALTER TABLE <table-name> SET TBLPROPERTIES ('write.delete.mode'='copy-on-write','write.update.mode'='copy-on-write')")
새 CoW 테이블을 생성하려면 테이블 속성 **'write.delete.mode'='copy-on-write','write.update.mode'='copy-on-write'**를 사용합니다.
dataFrame.createOrReplaceTempView("tmp_<your_table_name>") query = f""" CREATE TABLE glue_catalog.<your_database_name>.<your_table_name> USING iceberg TBLPROPERTIES ('format-version'='2','write.delete.mode'='copy-on-write','write.update.mode'='copy-on-write') AS SELECT * FROM tmp_<your_table_name> """ spark.sql(query)
쓰기에 MoR(Merge-On-Read) 테이블 사용
MoR 테이블의 레코드를 업데이트하거나 삭제하면 그 작업으로 새 데이터 파일이 추가됩니다. 새로 추가된 삭제 데이터 파일은 읽기 중에 병합됩니다. 하지만 쓰기 작업은 기존 파일에 새 파일을 추가하기만 하면 됩니다. 테이블에서 읽기보다 테이블에 쓰기가 더 빈번하다면, MOR 테이블을 선택하십시오.
MoR Iceberg 테이블을 사용하려면 다음 Spark SQL 명령을 실행합니다.
spark.sql("ALTER TABLE <table-name> SET TBLPROPERTIES ('write.delete.mode'='merge-on-read','write.update.mode'='merge-on-read')")
참고: 속성에 대한 제어를 더 잘 유지하려면 Spark 엔진에서 Iceberg 테이블을 생성하는 것이 가장 좋습니다. AWS Glue, EMR Spark 또는 Amazon Athena를 사용하여 테이블을 생성할 수도 있습니다. 그러나 Athena는 테이블 속성에 대한 지원이 제한되어 있으며 MoR 유형의 테이블만 사용합니다.
Iceberg 테이블 최적화
Iceberg 테이블은 메타데이터 파일과 삭제 파일 등의 숫자 증가 이유로 쿼리 성능이 하락될 수 있습니다. 다음은 쿼리 효율성과 데이터 스토리지를 최적화하는 데 사용할 수 있는 몇 가지 방법입니다.
스냅샷 만료
테이블의 이전 상태에서 데이터를 가져올 수 있도록 Iceberg 테이블은 스냅샷을 유지합니다. 이러한 스냅샷은 테이블에 대해 수행한 모든 쓰기 작업에 대해 작성하며 관련 스냅샷 ID를 새 메타데이터 파일에 추가합니다. 시간이 지나면서 스냅샷의 수는 메타데이터 파일의 크기를 커지게 만듭니다. 이러한 추가 스냅샷은 쿼리 성능을 지연시킵니다.
스냅샷을 만료하려면 다음 옵션을 사용하십시오.
-
대규모 테이블에 대해 지정된 타임스탬프보다 오래된 스냅샷을 병렬로 만료하려면 Spark에서 expireSnapshots 작업을 사용합니다.
SparkActions.get() .expireSnapshots(table) .expireOlderThan(tsToExpire) .execute() -
또는 expire_snapshots라는 절차를 사용합니다. 자세한 내용은 Iceberg 웹사이트의 expire_snapshots를 참조하십시오.
spark.sql("CALL glue_catalog.system.expire_snapshots('databasename.tablename',<timestamp value>)")AWS Glue 작업 내에서 일정한 간격으로 이전의 코드를 실행합니다. 스냅샷 만료를 자동화하면, 데이터 파일 수를 제한하고 메타데이터 파일을 작게 유지하고 효율적인 쿼리 성능을 유지할 수 있습니다.
이전 메타데이터 파일 제거
write.metadata.delete-after-commit.enabled 테이블 속성을 True로 설정하여 각 테이블 커밋 후 이전 메타데이터 파일을 자동으로 삭제합니다. 또한 write.metadata.previous-versions-max를 설정하여 유지할 이전 메타데이터 파일 수를 관리할 수도 있습니다.
매니페스트 파일 다시 쓰기
Iceberg 테이블은 매니페스트와 매니페스트 파일을 사용하여 모든 데이터 파일을 추적합니다. 시간 경과에 따라 각 스냅샷은 많은 매니페스트 파일을 참조합니다. 이러한 작업을 수행하면 쿼리 속도가 느려집니다. 자세한 내용은 Iceberg 웹사이트의 manifest lists(매니페스트 목록) 및 manifest(매니페스트) 파일을 참조하십시오.
매니페스트 다시 쓰기 절차를 사용하여 매니페스트 파일을 효율적으로 관리하십시오. 자세한 내용은 Iceberg 웹사이트의 rewrite_manifests를 참조하십시오.
다음 Spark SQL 쿼리를 실행합니다.
spark.sql("CALL glue_catalog.system.rewrite_manifests('databasename.tablename')")
데이터 파일 다시 쓰기
Iceberg는 테이블의 모든 데이터 파일을 메타데이터 파일로 유지 관리하고 추적합니다. 시간이 지나면서 누적된 데이터 파일이 많아지면 메타데이터 파일의 크기가 커집니다. 메타데이터 파일에 불필요하거나 열려 있는 파일이 있으면 읽기 효율이 떨어집니다. Spark의 rewrite_data_files 절차는 데이터를 병렬로 압축하고 읽기 효율을 높이는 데 도움이 됩니다. 자세한 내용은 Iceberg 웹사이트의 rewrite_data_files를 참조하십시오.
다음 Spark SQL 명령을 실행합니다.
spark.sql("CALL glue_catalog.system.rewrite_data_files(table=>'databasename.tablename')")
BINPACK 또는 SORT 전략을 사용하여 사용 사례에 맞게 데이터 파일을 다시 씁니다. 자세한 내용은 Iceberg 웹사이트의 BINPACK 및 SORT를 참고하십시오.
BINPACK: 가장 저렴하고 빠른 접근 방식입니다. 작은 파일을 큰 파일로 결합하고 출력 파일의 총 개수를 줄입니다. 레코드의 순서가 흐트러지지 않으며 데이터가 뒤섞이지 않습니다. 이것이 기본 옵션입니다.
CALL catalog.system.rewrite_data_files( table => 'test_table', strategy => 'binpack', options => map( 'rewrite-job-order','bytes-asc', 'target-file-size-bytes','<set-afile-size>', 'max-file-group-size-bytes','<max-group-size>' -- 10GB ) )
SORT: SORT 전략은 파일을 압축하는 동안 데이터를 정렬합니다. 이 전략은 인접한 레코드를 비교하는 여러 집계 함수(예: 최소 또는 최대 함수)를 실행할 때 유용합니다.
CALL catalog\_name.system.rewrite\_data\_files( table => 'databasename.tablename', strategy => 'sort', sort\_order => 'id', --can be any column options => map('rewrite-all','true') )
분리된 파일 제거
분리된 파일은 어떤 메타데이터 파일에서도 참조하지 않습니다. 자세한 내용은 Iceberg 웹사이트에서 remove_orphan_files를 참조하십시오.
분리된 파일을 제거하려면 아래와 같이 remove_orphan_files 명령을 실행하십시오.
spark.sql("CALL glue_catalog.system.remove_orphan_files(table=>'databasename.tablename')")
**참고:**예약된 작업을 실행하여 유지 관리 활동을 관리하는 것이 모범 사례입니다. 단일 AWS Glue 작업을 사용하여 위의 모든 Spark SQL 쿼리를 실행합니다.
관련 정보
관련 콘텐츠
- 질문됨 3년 전
AWS 공식업데이트됨 일 년 전