주의
Databricks는 모든 관리되는 테이블에 액체 클러스터링을 권장합니다. Apache Iceberg를 사용하는 관리 테이블의 경우 Unity 카탈로그는 액체 클러스터링만 지원하고 열을 클러스터링 키로 해석합니다 PARTITION BY .
분할된 테이블을 액체 클러스터링으로 변환을 참조하세요.
데이터가 100TB 미만인 Azure Databricks 대부분의 테이블은 분할이 필요하지 않습니다. Azure Databricks 기본적으로 모든 테이블에 Delta Lake를 사용하고 수집 시간을 통해 분할되지 않은 테이블의 데이터를 자동으로 클러스터링하므로 수동 튜닝 없이 분할과 유사한 성능을 얻을 수 있습니다. 이러한 기본값을 능가하는 경우에만 사용자 지정 분할 전략을 고려합니다. 수집 시간 클러스터링 사용을 참조하세요.
사용자 지정 분할 전략
Apache Spark 및 Delta Lake의 고급 사용자는 기본 수집 시간 클러스터링을 능가하는 분할 전략을 식별할 수 있습니다.
Warning
비효율적인 분할 전략은 쿼리 성능에 부정적인 영향을 줄 수 있으며 수정하려면 데이터를 완전히 다시 작성해야 합니다. 전체 다시 쓰기는 큰 테이블에 대해 매우 비싸고 느릴 수 있습니다.
사용자 지정 분할 전략을 사용하기 전에 Databricks는 모든 테이블에 대한 액체 클러스터링과 Unity 카탈로그 관리 테이블에 대한 예측 최적화를 권장합니다. 테이블에 액체 클러스터링 사용 및 Unity Catalog 관리 테이블에 대한 예측 최적화를 참조하세요.
기존의 분할된 Delta Lake 테이블을 리퀴드 클러스터링으로 변환하려면 ALTER TABLE ... REPLACE PARTITIONED BY WITH CLUSTER BY을(를) 사용하세요. Liquid 클러스터링은 카디널리티가 낮은 열과 높은 카디널리티 열 모두에서 작동하며 고정 파티션 경계 및 정적 분할과 관련된 작은 파일 문제를 방지합니다.
분할된 테이블을 액체 클러스터링으로 변환을 참조하세요.
파티션 열에 지원되는 데이터 형식
분할은 파티션 열에 대해 다음과 같은 데이터 형식을 지원합니다.
- 날짜
- 시간표시
- TimestampNTZ
- 간격
- String
- Binary
- Boolean
- 정수, 장정수, 단정수, 바이트
- Float (부동소수점), Double (배정밀도 부동소수점), Decimal (십진수)
파티션 열은 최상위 열이어야 합니다. 다음 중 어느 것으로도 분할할 수 없습니다.
- 복합 형식(예:
StructType, , 또는)MapTypeArrayTypeVariantType - 구조체 필드(예:
struct_col.field). Delta Lake는PARTITIONED BY에서 구조체 필드를 열 참조가 아니라 식으로 처리합니다.
구조체 필드를 기준으로 테이블을 구성하려면 구조체 필드를 클러스터링 키로 인식하는 액체 클러스터링을 대신 사용합니다. Liquid 클러스터링은 구조체 필드를 먼저 최상위 열로 추출하지 않고 해당 필드에서 데이터 스킵을 수행할 수 있는 유일한 방법입니다. 테이블에 대한 액체 클러스터링 사용을 참조하세요.
최소 크기 권장 사항
이러한 최소 크기 이하로 분할하면 쿼리 성능이 개선되지 않고 부정적인 영향을 줄 수 있습니다. 테이블을 분할할지 여부를 결정할 때 다음을 고려합니다.
- 테이블의 경우:
- 1TB 미만의 데이터를 사용하여 분할하지 마세요.
- 1TB에서 100TB 이상의 데이터를 사용하여 분할 대신 액체 클러스터링을 사용합니다. 분할은 성능에 도움이 되는 것보다 성능에 부정적인 영향을 줄 수 있습니다.
- 100TB 이상의 데이터를 사용하면 분할이 성능을 향상시킬 수 있지만 Databricks는 먼저 액체 클러스터링을 사용하고 성능 향상을 확인하는 것이 좋습니다.
- 파티션의 경우 각 파티션에 1GB 이상의 데이터가 포함되어 있는지 확인합니다. 파티션 수가 적고 파티션이 큰 테이블은 더 작은 파티션이 많은 테이블을 능가하는 경향이 있습니다.
수집 시간 클러스터링을 사용
Delta Lake를 사용하면 분할되지 않은 테이블은 수집 시간 클러스터링을 자동으로 사용합니다. 수집 시간에는 데이터를 수동으로 최적화하거나 조정할 필요 없이 날짜/시간 필드를 사용하여 분할 전략과 유사한 쿼리 성능이 향상되었습니다.
주의
테이블에서 UPDATE 또는 MERGE 문을 사용하여 많은 수의 수정을 수행할 때 수집 시간 클러스터링을 유지하려면, Databricks는 이벤트 타임스탬프 또는 생성 날짜와 같이 수집 순서와 일치하는 열에서 '리퀴드 클러스터링'을 사용하는 것을 권장합니다.
테이블에 대한 액체 클러스터링 사용을 참조하세요.
Delta Lake 및 Parquet 파티셔닝 호환성
Delta Lake는 데이터를 저장하기 위해 Parquet을 사용하고, 분할된 일부 Delta Lake 테이블에는 Apache Spark와 함께 저장된 Parquet 테이블과 유사한 데이터 레이아웃이 있습니다. Apache Spark는 데이터를 Parquet 형식으로 저장할 때 Hive 스타일 분할을 사용합니다. Hive 스타일 분할은 Delta Lake 프로토콜의 일부가 아니며 워크로드는 Delta Lake 테이블과 상호 작용하기 위해 이 분할 전략에 의존해서는 안 됩니다.
Databricks는 공식적으로 지원되는 클라이언트 및 API를 사용하여 Delta Lake에 저장된 데이터와 상호 작용하는 것이 좋습니다. 많은 Delta Lake 기능은 Parquet, Hive 또는 이전 Delta Lake 프로토콜 버전에서 사용되었을 수 있는 데이터 레이아웃에 대한 가정을 끊습니다.
주의
Delta Lake 테이블에 열 매핑을 사용하도록 설정하면 임의 접두사는 Hive 스타일 분할을 위해 파티션 디렉터리에 있는 열 이름을 대체합니다. Delta Lake 열 매핑를 사용하여 열 이름 바꾸기 및 삭제 방법에 대한 내용을
다른 데이터 레이크와 비교한 Delta Lake 파티셔닝
다른 오픈 소스 기술(예: Apache Spark, Parquet, Hive 및 Hadoop)에 유용한 분할 기술은 항상 Azure Databricks 적합한 것은 아닙니다. 테이블을 분할하도록 선택하는 경우 다음을 고려합니다.
- 트랜잭션은 파티션 경계에 의해 정의되지 않습니다. Delta Lake는 트랜잭션 로그를 통해 ACID 를 보장하므로 원자성을 보장하기 위해 데이터 일괄 처리를 파티션으로 구분할 필요가 없습니다.
- Azure Databricks 컴퓨팅 클러스터에는 실제 미디어에 연결된 데이터 지역성이 없습니다. Lakehouse로 수집된 데이터는 클라우드 오브젝트 스토리지에 저장됩니다. 데이터를 처리하는 동안 데이터가 로컬 디스크 스토리지에 캐시되는 동안 Azure Databricks는 파일 기반 통계를 사용하여 병렬 로드를 위한 최소 데이터 양을 식별합니다.
Z 순서 및 파티션
주의
Databricks는 모든 새 테이블에 Z 순서를 통해 액체 클러스터링을 권장합니다. 테이블에 대한 액체 클러스터링 사용을 참조하세요.
파티션과 함께 Z 순서 인덱스를 사용하여 대규모 데이터 세트에서 쿼리 속도를 높일 수 있습니다. 대부분의 테이블에서는 수집 시간 클러스터링을 사용하여 Z 순서 및 파티션을 튜닝할 필요가 없습니다.
파티션 경계 및 Z 순서에 따라 쿼리 최적화 전략을 계획할 때 다음 규칙을 염두에 두세요.
- Z 순서에는 명령이
OPTIMIZE필요합니다. 파티션 경계를 넘어 파일을 결합할 수 없으므로 Z 순서 클러스터링이 파티션 내에서만 발생할 수 있습니다. 분할되지 않은 테이블의 경우 파일 전체를 결합할 수 있습니다. - 분할은 카디널리티가 낮거나 알려진 필드(예: 날짜 필드 또는 실제 위치)에 대해서만 잘 작동하지만 타임스탬프와 같이 카디널리티가 높은 필드에는 적합하지 않습니다. Z 순서는 높은 카디널리티 필드와 무한히 증가할 수 있는 필드(예: 트랜잭션 또는 주문 테이블의 타임스탬프 또는 고객 ID)를 비롯한 모든 필드에 대해 작동합니다.
- 분할에 사용되는 필드는 Z 순서로 정렬할 수 없습니다.
Azure Databricks 기존 파티션을 최적화하는 방법
많은 고객이 Parquet 기반 데이터 레이크에서 Delta Lake로 마이그레이션하며, 예를 들어 기존 데이터를 다시 쓰지 않고 기존 Parquet 기반 테이블을 Delta Lake 테이블로 변환하는 CONVERT TO DELTA 문을 사용합니다. 변환은 기존 데이터를 다시 작성하지 않으므로 큰 테이블은 이전 분할 전략을 상속할 수 있습니다.
일부 Databricks 최적화는 가능한 경우 이러한 파티션을 사용하여 Delta Lake에 최적화되지 않은 분할 전략에 부정적인 성능 효과를 완화합니다.
Delta Lake 및 Apache Spark는 오픈 소스 기술입니다. Databricks에는 분할에 대한 의존도를 줄이는 기능이 있지만 오픈 소스 커뮤니티는 복잡성을 더하는 새로운 기능을 빌드할 수 있습니다.