다음을 통해 공유

Azure Databricks에서 테이블을 분할하는 경우

  • 아티클

참고 항목

Databricks는 모든 새 델타 테이블에 액체 클러스터링을 사용하는 것이 좋습니다. Delta 테이블에 Liquid 클러스터링 사용을 참조하세요.

Liquid 클러스터를 "액체 파티션"이라고도 합니다. 이 문서는 액체 클러스터링이 아닌 레거시 델타 분할만을 참조합니다.

이 문서에서는 Azure Databricks에서 테이블을 분할하는 방법에 대한 개요와 Delta Lake에서 지원하는 테이블에 대해 분할을 사용해야 하는 시기에 대한 특정 권장 사항을 제공합니다. 기본 제공 기능 및 최적화로 인해 데이터가 1TB 미만인 대부분의 테이블에는 파티션이 필요하지 않습니다.

Azure Databricks는 기본적으로 모든 테이블에 대해 Delta Lake를 사용합니다. 다음 권장 사항은 모든 테이블에 대해 Delta Lake로 작업하고 있다고 가정합니다.

Databricks Runtime 11.3 LTS 이상에서 Azure Databricks는 수집 시간을 통해 분할되지 않은 테이블의 데이터를 자동으로 클러스터링합니다. 수집 시간 클러스터링 사용을 참조하세요.

작은 테이블을 분할해야 하나요?

Databricks는 1테라바이트 미만의 데이터가 포함된 테이블을 분할하지 않는 것이 좋습니다.

테이블의 각 파티션에 대한 최소 크기는 얼마인가요?

Databricks는 모든 파티션에 최소 1GB의 데이터를 포함할 것이 좋습니다. 더 적은 수의 더 큰 파티션이 있는 테이블은 더 작은 파티션이 많은 테이블보다 성능이 뛰어난 경향이 있습니다.

수집 시간 클러스터링 사용

Delta Lake 및 Databricks Runtime 11.3 LTS 이상을 사용하여 분할되지 않은 테이블을 사용하면 수집 시간 클러스터링에서 자동으로 이점을 얻을 수 있습니다. 수집 시간은 데이터를 최적화하거나 조정할 필요 없이 날짜/시간 필드를 기반으로 분할 전략에 유사한 쿼리 이점을 제공합니다.

참고 항목

테이블에서 UPDATE 또는 MERGE 문을 사용하여 많은 수의 수정을 수행할 때 수집 시간 클러스터링을 유지하기 위해 Databricks는 수집 순서와 일치하는 열을 사용하여 ZORDER BY로 OPTIMIZE를 실행할 것이 좋습니다. 예를 들어, 이벤트 타임스탬프 또는 생성 날짜를 포함하는 열일 수 있습니다.

Delta Lake와 Parquet은 분할 전략을 공유합니까?

Delta Lake는 데이터를 저장하기 위한 기본 형식으로 Parquet을 사용하고, 파티션이 지정된 일부 델타 테이블은 Apache Spark와 함께 저장된 Parquet 테이블과 유사한 조직을 보여 줍니다. Apache Spark는 데이터를 Parquet 형식으로 저장할 때 Hive 스타일 분할을 사용합니다. Hive 스타일 분할은 Delta Lake 프로토콜의 일부가 아니며 워크로드는 델타 테이블과 상호 작용하기 위해 이 분할 전략에 의존해서는 안 됩니다.

많은 Delta Lake 기능은 Parquet, Hive 또는 이전 Delta Lake 프로토콜 버전에서 전송되었을 수 있는 데이터 레이아웃에 대한 가정을 중단합니다. 공식적으로 지원되는 클라이언트 및 API를 사용하여 항상 Delta Lake에 저장된 데이터와 상호 작용해야 합니다.

Delta Lake 파티션은 다른 데이터 레이크의 파티션과 어떻게 다른가요?

Azure Databricks 및 Delta Lake는 Apache Spark, Parquet, Hive 및 Hadoop과 같은 오픈 소스 기술을 기반으로 빌드되지만 이러한 기술에 유용한 분할 동기 및 전략은 일반적으로 Azure Databricks에 적용되지 않습니다. 테이블을 분할하기로 선택한 경우 전략을 선택하기 전에 다음 사실을 고려합니다.

  • 트랜잭션은 파티션 경계에 의해 정의되지 않습니다. Delta Lake는 트랜잭션 로그를 통해 ACID를 보장하므로 원자성 검색을 보장하기 위해 파티션별로 데이터 일괄 처리를 분리할 필요가 없습니다.
  • Azure Databricks 컴퓨팅 클러스터에는 실제 미디어에 연결된 데이터 지역성이 없습니다. Lakehouse로 수집된 데이터는 클라우드 개체 스토리지에 저장됩니다. 데이터를 처리하는 동안 데이터가 로컬 디스크 스토리지에 캐시되는 동안 Azure Databricks는 파일 기반 통계를 사용하여 병렬 로드를 위한 최소 데이터 양을 식별합니다.

Z 순서와 파티션은 어떻게 함께 작동하나요?

파티션과 함께 Z 순서 인덱스를 사용하여 대규모 데이터 세트에서 쿼리 속도를 높일 수 있습니다.

참고 항목

대부분의 테이블은 수집 시간 클러스터링을 활용하여 Z 순서 및 파티션 튜닝에 대해 걱정할 필요가 없습니다.

파티션 경계 및 Z 순서를 기반으로 쿼리 최적화 전략을 계획할 때 다음 규칙을 염두에 두어야 합니다.

  • Z 순서는 OPTIMIZE 명령과 함께 작동합니다. 파티션 경계를 넘어 파일을 결합할 수 없으므로 Z 순서 클러스터링은 파티션 내에서만 발생할 수 있습니다. 분할되지 않은 테이블의 경우 전체 테이블에서 파일을 결합할 수 있습니다.
  • 분할은 카디널리티가 낮거나 알려진 필드(예: 날짜 필드 또는 실제 위치)에 대해서만 잘 작동하지만 타임스탬프와 같이 카디널리티가 높은 필드에는 적합하지 않습니다. Z 순서는 카디널리티가 높은 필드와 무한히 커질 수 있는 필드(예: 트랜잭션 또는 주문 테이블의 타임스탬프 또는 고객 ID)를 비롯한 모든 필드에서 작동합니다.
  • 분할에 사용되는 필드는 Z 순서로 정렬할 수 없습니다.

파티션이 너무 나쁜 경우 일부 Azure Databricks 기능에서 파티션을 사용하는 이유는 무엇인가요?

파티션은 특히 매우 큰 테이블에 유용할 수 있습니다. 분할과 관련된 많은 성능 향상은 매우 큰 테이블(수백 테라바이트 이상)에 중점을 둡니다.

많은 고객이 Parquet 기반 데이터 레이크에서 Delta Lake로 마이그레이션합니다. CONVERT TO DELTA 문을 사용하면 기존 데이터를 다시 쓰지 않고도 기존 Parquet 기반 테이블을 Delta 테이블로 변환할 수 있습니다. 따라서 많은 고객이 이전 분할 전략을 계승하는 대형 테이블을 보유하고 있습니다. Databricks에서 개발한 일부 최적화는 가능한 경우 이러한 파티션을 활용하여 Delta Lake에 최적화되지 않은 분할 전략의 잠재적인 단점을 완화합니다.

Delta Lake 및 Apache Spark는 오픈 소스 기술입니다. Databricks가 분할에 대한 종속성을 줄이는 기능을 계속 도입하는 동안 오픈 소스 커뮤니티는 복잡성을 추가하는 새로운 기능을 계속 빌드할 수 있습니다.

사용자 지정 분할을 사용하여 Azure Databricks 기본 제공 최적화를 능가할 수 있나요?

일부 Apache Spark 및 Delta Lake 사용자는 수집 시간 클러스터링보다 더 나은 성능을 제공하는 패턴을 설계하고 구현할 수 있습니다. 잘못된 분할 상태를 구현하면 다운스트림 성능에 매우 부정적인 영향을 미칠 수 있으며 수정하려면 데이터를 완전히 다시 작성해야 할 수 있습니다. Databricks는 비용이 많이 드는 비효율성을 피하기 위해 대부분의 사용자가 기본 설정을 사용할 것이 좋습니다.