Azure Databricks에서 partitiontables을 사용할 때

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

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

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

작은 tables가 분할되어야 합니까?

Databricks는 데이터가 테라바이트 미만인 경우 partitiontables을 하지 않는 것을 권장합니다.

table내 각 partition의 최소 크기는 무엇인가요?

Databricks는 모든 파티션에 최소 1GB의 데이터를 포함할 것이 좋습니다. 파티션 수가 적고 크기가 큰 Tables는 파티션 수가 많고 크기가 작은 tables을 능가하는 경향이 있습니다.

수집 시간 클러스터링 사용

Delta Lake 및 Databricks Runtime 11.3 LTS 이상을 사용하여 분할되지 않은 tables수집 시간 클러스터링자동으로 혜택을 만듭니다. 수집 시간은 데이터를 optimize 튜닝할 필요 없이 날짜/시간 필드를 기반으로 하는 분할 전략과 비슷한 쿼리 이점을 제공합니다.

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

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

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

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

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

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

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

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

다음 규칙은 partition 경계 및 Z 순서에 따라 쿼리 최적화 전략을 계획하는 동안 유의해야 합니다.

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

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

파티션은 특히 매우 큰 tables에 유용할 수 있습니다. 매우 큰 tables(수백 테라바이트 이상)의 데이터를 분할할 때의 많은 성능 향상이 있었습니다.

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

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

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

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