분할 정책
적용 대상: ✅Microsoft Fabric✅Azure Data Explorer
분할 정책은 특정 테이블 또는 구체화된 뷰에 대해 익스텐트(데이터 분할)를 분할해야 하는지 여부와 방법을 정의합니다.
정책은 데이터 수집 후 익스텐트를 만든 후에 발생하는 추가 백그라운드 프로세스를 트리거합니다. 이 프로세스에는 원본 익스텐트에서 데이터를 다시 수집하고 파티션 키로 지정된 열의 모든 값이 단일 파티션 내에 있는 균일한 익스텐트를 생성하는 작업이 포함됩니다.
분할 정책의 주요 목적은 지원되는 특정 시나리오에서 쿼리 성능을 향상시키는 것입니다.
참고 항목
기본적으로 데이터 분할 정책이 정의되지 않은 경우(즉 null
), 생성 시간(수집)에 따라 익스텐트를 분할합니다. 대부분의 경우 데이터 분할 정책을 설정할 필요가 없습니다.
지원되는 시나리오
다음은 데이터 분할 정책을 설정하는 것이 권장되는 유일한 시나리오입니다. 다른 모든 시나리오에서는 정책 설정을 권장하지 않습니다.
- 중간 또는 높은 카디널리티
string
또는guid
열에 대한 빈번한 필터: - 높은 카디널리티
string
또는 열에서 자주 집계 또는guid
조인:- 예를 들어 다양한 센서의 IoT 정보 또는 여러 다른 학생의 학업 기록입니다.
- 높은 카디널리티는 적어도 1,000,000개의 고유 값이며 열의 값 분포는 대략 짝수입니다.
- 이 경우 해시 파티션 키를 자주 그룹화되거나 조인된 열로 설정하고 속성을
ByPartition
.로 설정합니다PartitionAssignmentMode
.
- 순서가 다른 데이터 수집:
- 테이블에 수집된 데이터는 데이터 생성 시간을 나타내며 일반적으로 데이터를 필터링하는 데 사용되는 특정
datetime
열에 따라 익스텐트(분할)로 정렬되고 분할되지 않을 수 있습니다. 이는 대규모 시간 범위에 걸쳐 날짜/시간 값을 포함하는 이질적인 원본 파일의 백필 때문일 수 있습니다. - 이 경우 균일한 범위 날짜/시간 파티션 키를 열로
datetime
설정합니다. - 수집 시간에 맞추는 대신 열의 날짜/시간 값과 일치하도록 보존 및 캐싱 정책이 필요한 경우 속성을
true
.로 설정합니다OverrideCreationTime
.
- 테이블에 수집된 데이터는 데이터 생성 시간을 나타내며 일반적으로 데이터를 필터링하는 데 사용되는 특정
주의
- 분할 정책이 정의된 테이블 수에는 하드 코딩된 제한이 설정되지 않습니다. 그러나 모든 추가 테이블은 백그라운드 데이터 분할 프로세스에 오버헤드를 추가합니다. 더 많은 테이블에 정책을 설정하면 더 많은 리소스가 사용되고 기본 스토리지 트랜잭션으로 인해 비용이 높아집니다. 자세한 내용은 용량을 참조 하세요.
- 파티션당 압축된 데이터 크기가 1GB 미만인 경우에는 분할 정책을 설정하지 않는 것이 좋습니다.
- 분할 프로세스는 분할 프로세스 중 및 병합 프로세스 중에 대체된 모든 익스텐트에서 잔여 스토리지 아티팩트가 생성됩니다. 대부분의 잔여 스토리지 아티팩트가 자동 정리 프로세스 중에 삭제되어야 합니다. 속성 값을
MaxPartitionCount
늘리면 잔여 스토리지 아티팩트 수가 증가하고 정리 성능이 저하됩니다. - 구체화된 뷰에 분할 정책을 적용하기 전에 구체화된 뷰 분할 정책에 대한 권장 사항을 검토합니다.
파티션 키
다음과 같은 종류의 파티션 키가 지원됩니다.
종류 | 열 유형 | 파티션 속성 | 파티션 값 |
---|---|---|---|
해시 | string 또는 guid |
Function , MaxPartitionCount , Seed PartitionAssignmentMode |
Function (ColumnName , MaxPartitionCount , Seed ) |
균일한 범위 | datetime |
RangeSize , , Reference OverrideCreationTime |
bin_at (ColumnName , RangeSize , Reference ) |
해시 파티션 키
정책에 해시 파티션 키가 포함된 경우 동일한 파티션에 속하는 모든 동종 익스텐트는 동일한 데이터 노드에 할당됩니다.
참고 항목
데이터 분할 작업은 상당한 처리 부하를 추가합니다. 다음 조건에서만 테이블에 해시 파티션 키를 적용하는 것이 좋습니다.
- 대부분의 쿼리에서 같음 필터(
==
,in()
)를 사용하는 경우 - 대부분의 쿼리는 형식
string
의 특정 열 또는guid
큰 차원(10M 이상의 카디널리티)(예:device_ID
10M 이상)에 대해 집계/조인user_ID
합니다. - 분할된 테이블의 사용 패턴은 모니터링 또는 대시보드 애플리케이션과 같이 동시성 쿼리 부하가 높습니다.
- 해시 모듈로 함수는 데이터를 분할하는 데 사용됩니다.
- 균일한(분할된) 익스텐트 내의 데이터는 해시 파티션 키로 정렬됩니다.
- 테이블에 해시 파티션 키가 정의된 경우 행 순서 정책에 해시 파티션 키를 포함할 필요가 없습니다.
- 순서 섞기 전략을
join
summarize
shuffle key
사용하고 사용된 쿼리 또는make-series
테이블의 해시 파티션 키인 쿼리는 노드 간에 이동하는 데 필요한 데이터의 양이 줄어들기 때문에 더 나은 성능을 발휘할 것으로 예상됩니다.
파티션 속성
속성 | 설명 | 지원되는 값 | 권장 값 |
---|---|---|---|
Function |
사용할 해시 모듈로 함수의 이름입니다. | XxHash64 |
|
MaxPartitionCount |
기간당 만들 파티션의 최대 수(해시 모듈로 함수에 대한 모듈로 인수)입니다. | 범위 (1,2048] 에서 . |
값이 높을수록 데이터 분할 프로세스의 오버헤드가 증가하고 각 기간마다 익스텐트 수가 높아질 수 있습니다. 권장 값은 128 입니다. 값이 높을수록 수집 후 데이터를 분할하는 오버헤드와 메타데이터 크기가 크게 증가하므로 권장되지 않습니다. |
Seed |
해시 값을 임의로 지정하는 데 사용합니다. | 양의 정수 | 1 는 기본값이기도 하다. |
PartitionAssignmentMode |
노드에 파티션을 할당하는 데 사용되는 모드입니다. | ByPartition : 동일한 파티션에 속하는 모든 균일한(분할된) 익스텐트도 동일한 노드에 할당됩니다. Uniform : 익스텐트의 파티션 값은 무시됩니다. 익스텐트 노드에 균일하게 할당됩니다. |
쿼리가 해시 파티션 키 Uniform 에 조인하거나 집계되지 않는 경우 . 그렇지 않으면 ByPartition 를 사용합니다. |
해시 파티션 키 예제
라는 tenant_id
형식화된 열에 대한 string
해시 파티션 키입니다.
권장 값 128
및 기본값 Seed
1
으로 MaxPartitionCount
설정된 해시 함수를 사용합니다XxHash64
.
{
"ColumnName": "tenant_id",
"Kind": "Hash",
"Properties": {
"Function": "XxHash64",
"MaxPartitionCount": 128,
"Seed": 1,
"PartitionAssignmentMode": "Uniform"
}
}
균일한 범위 날짜/시간 파티션 키
참고 항목
테이블에 수집된 데이터가 이 열에 datetime
따라 정렬되지 않을 경우에만 테이블의 형식화된 열에 균일한 범위 날짜/시간 파티션 키를 적용합니다.
이러한 경우 각 익스텐트에서 제한된 시간 범위의 레코드를 포함할 수 있도록 익스텐트 간에 데이터를 다시 구성할 수 있습니다. 이 프로세스를 통해 열에 대한 필터가 datetime
쿼리 시간에 더 효과적입니다.
사용되는 파티션 함수는 bin_at() 이며 사용자 지정할 수 없습니다.
파티션 속성
속성 | 설명 | 권장 값 |
---|---|---|
RangeSize |
timespan 각 datetime 파티션의 크기를 나타내는 스칼라 상수입니다. |
값 1.00:00:00 (1일)로 시작합니다. 테이블에 병합할 수 없는 작은 범위가 많을 수 있으므로 더 짧은 값을 설정하지 마세요. |
Reference |
datetime 날짜/시간 파티션이 정렬되는 고정된 시점을 나타내는 스칼라 상수입니다. |
1970-01-01 00:00:00 를 시작합니다. datetime 파티션 키 null 에 값이 있는 레코드가 있는 경우 해당 파티션 값은 값 Reference 으로 설정됩니다. |
OverrideCreationTime |
bool 결과 익스텐트의 최소 및 최대 생성 시간을 파티션 키의 값 범위로 재정의해야 하는지 여부를 나타내는 값입니다. |
기본값은 false 입니다. true 데이터가 도착 시간 순서대로 수집되지 않는 경우로 설정합니다. 예를 들어 단일 원본 파일에는 먼 날짜/시간 값이 포함되거나 수집 시간이 아닌 날짜/시간 값에 따라 보존 또는 캐싱을 적용할 수 있습니다.설정 true 되면 OverrideCreationTime 병합 프로세스에서 익스텐트 누락이 발생할 수 있습니다. 생성 시간이 테이블의 익스텐트 병합 정책 기간보다 Lookback 오래된 경우 익스텐트 누락됩니다. 익스텐트 검색 가능하도록 하려면 속성을 HotCache .로 설정합니다Lookback . |
균일한 범위 날짜/시간 파티션 예제
코드 조각은 형식timestamp
화된 열에 대해 균일한 datetime
날짜/시간 범위 파티션 키를 표시합니다.
각 파티션의 7d
크기를 사용하여 참조 지점으로 사용 datetime(2021-01-01)
하며 익스텐트의 생성 시간을 재정의하지 않습니다.
{
"ColumnName": "timestamp",
"Kind": "UniformRange",
"Properties": {
"Reference": "2021-01-01T00:00:00",
"RangeSize": "7.00:00:00",
"OverrideCreationTime": false
}
}
정책 개체
기본적으로 테이블의 데이터 분할 정책은 null
테이블의 데이터를 수집한 후에 다시 분할되지 않습니다.
데이터 분할 정책에는 다음과 같은 기본 속성이 있습니다.
PartitionKeys:
- 테이블의 데이터를 분할하는 방법을 정의하는 파티션 키 의 컬렉션입니다.
- 테이블에는 다음 옵션 중 하나를 사용하여 최대
2
파티션 키가 있을 수 있습니다.- 해시 파티션 키 1개.
- 하나의 균일한 범위 날짜/시간 파티션 키입니다.
- 해시 파티션 키 1개와 균일한 범위 날짜/시간 파티션 키 1개
- 각 파티션 키에는 다음과 같은 속성이 있습니다.
ColumnName
:string
- 데이터를 분할할 열의 이름입니다.Kind
:string
- 적용할 데이터 분할 종류(Hash
또는UniformRange
)입니다.Properties
:property bag
- 분할이 수행되는 매개 변수를 정의합니다.
EffectiveDateTime:
- 정책이 적용되는 UTC 날짜/시간입니다.
- 이 속성은 선택 사항입니다. 지정하지 않으면 정책이 적용된 후 수집된 데이터에 대해 정책이 적용됩니다.
주의
- 과거 날짜/시간 값을 설정하고 이미 수집된 데이터를 분할할 수 있습니다. 그러나 이 방법은 분할 프로세스에 사용되는 리소스를 크게 늘릴 수 있습니다.
- 대부분의 경우 새로 수집한 데이터만 분할하고 대량의 기록 데이터를 분할하지 않도록 하는 것이 좋습니다.
- 기록 데이터를 분할하도록 선택한 경우 정책을 변경할 때마다 최대 며칠의 단계에서 EffectiveDateTime을 이전
datetime
으로 설정하여 점진적으로 분할하는 것이 좋습니다.
데이터 분할 예제
두 개의 파티션 키를 사용하는 데이터 분할 정책 개체입니다.
- 라는
tenant_id
형식화된 열에 대한string
해시 파티션 키입니다.- 권장 값
128
및 기본값Seed
1
으로MaxPartitionCount
설정된 해시 함수를 사용합니다XxHash64
.
- 권장 값
- 이름이 지정된
timestamp
형식 열에 대한 균일한datetime
날짜/시간 범위 파티션 키입니다.- 각 파티션의
7d
크기를 사용하여 참조 지점으로 사용합니다datetime(2021-01-01)
.
- 각 파티션의
{
"PartitionKeys": [
{
"ColumnName": "tenant_id",
"Kind": "Hash",
"Properties": {
"Function": "XxHash64",
"MaxPartitionCount": 128,
"Seed": 1,
"PartitionAssignmentMode": "Uniform"
}
},
{
"ColumnName": "timestamp",
"Kind": "UniformRange",
"Properties": {
"Reference": "2021-01-01T00:00:00",
"RangeSize": "7.00:00:00",
"OverrideCreationTime": false
}
}
]
}
추가 속성
다음 속성은 정책의 일부로 정의할 수 있습니다. 이러한 속성은 선택 사항이며 변경하지 않는 것이 좋습니다.
속성 | 설명 | 권장 값 | Default value |
---|---|---|---|
MinRowCountPerOperation | 단일 데이터 분할 작업의 원본 익스텐트 행 수 합계에 대한 최소 대상입니다. | 0 |
|
MaxRowCountPerOperation | 단일 데이터 분할 작업의 원본 익스텐트 행 수 합계에 대한 최대 대상입니다. | 분할 작업에서 작업당 많은 양의 메모리 또는 CPU를 사용하는 경우 5M보다 낮은 값을 설정합니다. | 0 는 기본 대상인 5,000,000개의 레코드를 사용합니다. |
MaxOriginalSizePerOperation | 단일 데이터 분할 작업의 원본 익스텐트의 원래 크기(바이트)의 합계에 대한 최대 대상입니다. | 분할 작업에서 작업당 많은 양의 메모리 또는 CPU를 사용하는 경우 5GB 미만의 값을 설정합니다. | 0 기본 대상인 5,368,709,120바이트(5GB)입니다. |
데이터 분할 프로세스
- 데이터 분할은 수집 후 백그라운드 프로세스로 실행됩니다.
- 지속적으로 수집되는 테이블에는 아직 분할되지 않은 데이터의 "비상"(비호종 익스텐트)이 항상 있어야 합니다.
- 데이터 분할은 정책의
EffectiveDateTime
속성 값에 관계없이 핫 익스텐트에서만 실행됩니다.- 콜드 익스텐트 분할이 필요한 경우 캐싱 정책을 일시적으로 조정해야 합니다.
.show 데이터베이스 익스텐트 분할 통계 명령 및 분할 메트릭을 사용하여 데이터베이스에서 정의된 정책을 사용하여 테이블의 분할 상태를 모니터링할 수 있습니다.
용량 분할
데이터 분할 프로세스는 더 많은 익스텐트 생성을 초래합니다. 익스텐트 병합 용량이 점차 증가하여 익스텐트 병합 프로세스가 계속 진행되도록 할 수 있습니다.
수집 처리량이 많거나 분할 정책이 정의된 테이블 수가 충분히 많은 경우 익스텐트 파티션 용량 이 점진적으로 증가하여 익스텐 트 분할 프로세스가 계속 진행되도록 할 수 있습니다.
::: 모니커 범위 = "azure-data-explorer"
- 리소스를 너무 많이 사용하지 않도록 하기 위해 이러한 동적 증가는 제한됩니다. 완전히 사용되는 경우 캡을 넘어 서서히 선형적으로 늘려야 할 수 있습니다.
제한 사항
- 이미 5,000,000개 이상의 익스텐트가 있는 데이터베이스에서 데이터를 분할하려는 시도가 제한됩니다.
- 이러한 경우
EffectiveDateTime
구성 및 정책을 재평가할 수 있도록 데이터베이스의 테이블 분할 정책 속성이 몇 시간씩 자동으로 지연됩니다.
- 이러한 경우
분할된 열의 이상값
- 다음 상황은 노드 간에 데이터를 분산하는 불균형을 초래하고 쿼리 성능을 저하시킬 수 있습니다.
- 해시 파티션 키에 빈 문자열 또는 제네릭 값(예: 또는
N/A
)과 같이null
다른 값보다 훨씬 더 널리 사용되는 값이 포함된 경우 - 값은 데이터 세트에서 더 널리 사용되는 엔터티(예:
tenant_id
)를 나타냅니다.
- 해시 파티션 키에 빈 문자열 또는 제네릭 값(예: 또는
- 균일한 범위 날짜/시간 파티션 키에 열의 대부분의 값과 "멀리" 있는 값의 비율이 충분히 크면 데이터 분할 프로세스의 오버헤드가 증가하고 추적할 수 있는 작은 범위가 많을 수 있습니다. 이러한 상황의 예로 먼 과거 또는 미래의 날짜/시간 값이 있습니다.
두 경우 모두 데이터를 "수정"하거나 수집 전이나 수집 시 데이터의 관련 없는 레코드를 필터링하여 데이터 분할의 오버헤드를 줄입니다. 예를 들어 업데이트 정책을 사용합니다.