압축을 사용하여 테이블 유지 관리하기

Iceberg에는 테이블에 데이터를 쓴 후 테이블 유지 관리 작업을 수행할 수 있는 기능이 포함되어 있습니다. 일부 유지 관리 작업은 메타데이터 파일을 간소화하는 데 중점을 두는 반면, 쿼리 엔진이 사용자 요청에 응답하는 데 필요한 정보를 효율적으로 찾을 수 있도록 파일 내 데이터 클러스터링 방식을 개선하는 작업도 있습니다. 이 섹션에서는 압축 관련 최적화에 중점을 둡니다.

아이스버그 컴팩션

Iceberg에서는 압축을 사용하여 다음 네 가지 작업을 수행할 수 있습니다.

• 작은 파일을 일반적으로 크기가 100MB가 넘는 큰 파일로 결합합니다. 이 기법을 빈 패킹이라고 합니다.

• 삭제 파일을 데이터 파일과 병합 삭제 파일은 이 접근 방식을 사용하는 업데이트 또는 삭제를 통해 생성됩니다. merge-on-read

• 쿼리 패턴에 따라 데이터를 (재) 정렬합니다. 정렬 순서 없이 또는 쓰기 및 업데이트에 적합한 정렬 순서로 데이터를 쓸 수 있습니다.

• 공간을 채우는 곡선을 사용하여 데이터를 클러스터링하여 고유한 쿼리 패턴, 특히 z-순서 정렬에 맞게 최적화합니다.

에서는 AWS Amazon Athena를 통해 또는 Amazon EMR에서 Spark를 사용하여 Iceberg에 대한 테이블 압축 및 유지 관리 작업을 실행할 수 있습니다. AWS Glue

rewrite_data_files 프로시저를 사용하여 압축을 실행하는 경우 여러 개의 노브를 조정하여 압축 동작을 제어할 수 있습니다. 다음 다이어그램은 빈 패킹의 기본 동작을 보여줍니다. 계층 정렬과 Z-순서 정렬 구현은 빈 패킹 인터페이스의 확장이며 유사한 방식으로 작동하기 때문에 빈 패킹 압축을 이해하는 것이 중요합니다. 주된 차이점은 데이터를 정렬하거나 클러스터링하는 데 필요한 추가 단계입니다.

이 예제에서 Iceberg 테이블은 네 개의 파티션으로 구성되어 있습니다. 파티션마다 크기가 다르고 파일 수도 다릅니다. 압축을 실행하기 위해 Spark 애플리케이션을 시작하면 애플리케이션은 처리할 총 4개의 파일 그룹을 만듭니다. 파일 그룹은 단일 Spark 작업으로 처리될 파일 컬렉션을 나타내는 Iceberg 추상화입니다. 즉, 압축을 실행하는 Spark 애플리케이션은 데이터를 처리하는 Spark 작업 4개를 생성합니다.

압축 동작 조정

다음 주요 속성은 압축을 위해 데이터 파일을 선택하는 방법을 제어합니다.

• MAX_FILE_GROUP_SIZE_BYTES는 단일 파일 그룹 (스파크 작업) 에 대한 데이터 제한을 기본적으로 100GB로 설정합니다. 이 속성은 파티션이 없는 테이블이나 수백 기가바이트에 달하는 파티션이 있는 테이블에 특히 중요합니다. 이 제한을 설정하면 작업을 세분화하여 작업을 계획하고 진행하면서 클러스터의 리소스 고갈을 방지할 수 있습니다.

  참고: 각 파일 그룹은 개별적으로 정렬됩니다. 따라서 파티션 수준 정렬을 수행하려면 파티션 크기와 일치하도록 이 제한을 조정해야 합니다.

• MIN_FILE_SIZE_BYTES 또는 MIN_FILE_SIZE_DEFAULT_RATION의 기본값은 테이블 수준에서 설정된 대상 파일 크기의 75% 입니다. 예를 들어, 테이블의 대상 크기가 512MB인 경우 384MB보다 작은 파일은 압축될 파일 세트에 포함됩니다.

• MAX_FILE_SIZE_BYTES 또는 MAX_FILE_SIZE_DEFAULT_RATIO의 기본값은 대상 파일 크기의 180퍼센트입니다. 최소 파일 크기를 설정하는 두 속성과 마찬가지로 이러한 속성은 압축 작업에 사용할 후보 파일을 식별하는 데 사용됩니다.

• MIN_INPUT_FILES는 테이블 파티션 크기가 대상 파일 크기보다 작을 경우 압축할 최소 파일 수를 지정합니다. 이 속성의 값은 파일 수를 기준으로 파일을 압축할 가치가 있는지 여부를 결정하는 데 사용됩니다 (기본값은 5).

• DELETE_FILE_THRESHOLD는 압축에 포함되기 전에 파일에 대한 최소 삭제 작업 수를 지정합니다. 달리 지정하지 않는 한 압축은 삭제 파일을 데이터 파일과 결합하지 않습니다. 이 기능을 사용하려면 이 속성을 사용하여 임계값을 설정해야 합니다. 이 임계값은 개별 데이터 파일에만 적용되므로 이 임계값을 3으로 설정하면 해당 데이터 파일을 참조하는 삭제 파일이 세 개 이상 있는 경우에만 데이터 파일이 다시 작성됩니다.

이러한 속성을 통해 이전 다이어그램의 파일 그룹 구성을 파악할 수 있습니다.

예를 들어 레이블이 지정된 파티션은 최대 크기 제한인 100GB를 초과하므로 파일 그룹이 두 개 month=01 포함되어 있습니다. 반면 month=02 파티션은 크기가 100GB 미만이므로 단일 파일 그룹을 포함합니다. month=03파티션이 파일 5개라는 기본 최소 입력 파일 요구 사항을 충족하지 않습니다. 따라서 압축되지 않습니다. 마지막으로, month=04 파티션에 원하는 크기의 파일 하나를 만들 수 있는 데이터가 충분하지 않더라도 파티션에 작은 파일이 5개 이상 포함되어 있기 때문에 파일이 압축됩니다.

Amazon AWS Glue EMR에서 실행되는 Spark 또는 에 대해 이러한 파라미터를 설정할 수 있습니다. Amazon Athena의 경우 접두사로 optimize_ 시작하는 테이블 속성을 사용하여 유사한 속성을 관리할 수 있습니다.

Amazon EMR에서 Spark를 사용하여 컴팩션을 실행하거나 AWS Glue

이 섹션에서는 Iceberg의 압축 유틸리티를 실행하기 위해 Spark 클러스터의 크기를 적절하게 조정하는 방법을 설명합니다. 다음 예시에서는 Amazon EMR 서버리스를 사용하지만, Amazon EC2의 Amazon EMR 또는 Amazon EKS에서도 동일한 방법을 사용할 수 있습니다. AWS Glue

파일 그룹과 Spark 작업 간의 상관 관계를 활용하여 클러스터 리소스를 계획할 수 있습니다. 파일 그룹당 최대 크기가 100GB인 것을 고려하여 파일 그룹을 순차적으로 처리하려면 다음과 같은 Spark 속성을 설정하면 됩니다.

• spark.dynamicAllocation.enabled = FALSE

• spark.executor.memory = 20 GB

• spark.executor.instances = 5

압축 속도를 높이려면 병렬로 압축되는 파일 그룹 수를 늘려 수평으로 확장할 수 있습니다. 수동 또는 동적 조정을 사용하여 Amazon EMR을 확장할 수도 있습니다.

• 수동 조정 (예: 4배)

  • MAX_CONCURRENT_FILE_GROUP_REWRITES= 4 (우리 계수)

  • spark.executor.instances= 5 (예제에 사용된 값) x 4 (우리 계수) = 20

  • spark.dynamicAllocation.enabled = FALSE

• 동적 스케일링

  • spark.dynamicAllocation.enabled= TRUE (기본값, 조치 필요 없음)

  • MAX_CONCURRENT_FILE_GROUP_REWRITES = N (이 값을 기본값인 100에 맞춥니다. 예제의 실행자 구성에 따라 20으로 spark.dynamicAllocation.maxExecutors 설정할 수 있습니다.) N

  다음은 클러스터 크기를 조정하는 데 도움이 되는 지침입니다. 하지만 워크로드에 가장 적합한 설정을 찾으려면 Spark 작업의 성능도 모니터링해야 합니다.

Amazon Athena로 컴팩션 실행하기

Athena는 OPTIMIZE 선언문을 통해 Iceberg의 압축 유틸리티 구현을 관리형 기능으로 제공합니다. 이 명령문을 사용하면 인프라를 평가할 필요 없이 컴팩션을 실행할 수 있습니다.

이 명령문은 빈 패킹 알고리즘을 사용하여 작은 파일을 큰 파일로 그룹화하고 삭제 파일을 기존 데이터 파일에 병합합니다. 계층적 정렬 또는 z-순서 정렬을 사용하여 데이터를 클러스터링하려면 Amazon EMR의 Spark 또는 을 사용하십시오. AWS Glue

OPTIMIZE명령문에 테이블 속성을 전달하여 테이블 생성 시 또는 테이블 생성 후 CREATE TABLE 명령문을 사용하여 명령문의 기본 동작을 변경할 수 있습니다. ALTER TABLE 기본값은 Athena 설명서를 참조하십시오.

컴팩션 실행을 위한 권장 사항

사용 사례	권장 사항
일정에 따라 쓰레기통 포장 압축 실행	테이블에 몇 개의 작은 파일이 들어 있는지 모르는 경우 Athena의 OPTIMIZE 명령문을 사용하십시오. Athena의 가격 책정 모델은 스캔한 데이터를 기반으로 하므로 압축할 파일이 없는 경우 이러한 작업과 관련된 비용이 발생하지 않습니다. Athena 테이블에서 타임아웃이 발생하지 않도록 하려면 베이스를 기준으로 실행하십시오. OPTIMIZE per-table-partition 대용량의 작은 파일이 압축될 것으로 예상되는 경우 Amazon EMR을 사용하거나 동적 크기 조정과 AWS Glue 함께 사용하십시오.
이벤트를 기반으로 빈 패킹 압축 실행	대용량의 작은 파일이 압축될 것으로 예상되는 경우 Amazon EMR을 사용하거나 동적 크기 조정과 AWS Glue 함께 사용하십시오.
컴팩션을 실행하여 데이터를 정렬합니다.	정렬은 비용이 많이 들고 데이터를 AWS Glue디스크로 넘겨야 할 수도 있으므로 Amazon EMR을 사용하거나 사용하십시오.
압축을 실행하여 z-순서 정렬을 사용하여 데이터를 클러스터링합니다.	Amazon EMR을 사용하거나 AWS Glue, z-order 정렬은 비용이 많이 들고 데이터를 디스크로 넘겨야 할 수도 있으므로 Amazon EMR을 사용하십시오.
늦게 도착하는 데이터로 인해 다른 애플리케이션에서 업데이트할 수 있는 파티션에서 컴팩션을 실행합니다.	Amazon EMR을 사용하거나. AWS Glue아이스버그 PARTIAL_PROGRESS_ENABLED 속성을 활성화하십시오. 이 옵션을 사용하면 Iceberg는 압축 출력을 여러 커밋으로 분할합니다. 충돌이 발생하는 경우 (즉, 압축이 실행되는 동안 데이터 파일이 업데이트되는 경우) 이 설정은 영향을 받는 파일이 포함된 커밋으로 제한하여 재시도 비용을 줄여줍니다. 그렇지 않으면 모든 파일을 다시 압축해야 할 수도 있습니다.