Direct Lake 의미 체계 모델에 대한 스토리지 이해

아티클
10/25/2024

이 문서에서는 Direct Lake 스토리지 개념을 소개합니다. 델타 테이블 및 Parquet 파일에 대해 설명합니다. 또한 Direct Lake 의미 체계 모델에 델타 테이블을 최적화하는 방법과 이를 유지 관리하여 안정적이고 빠른 쿼리 성능을 제공하는 방법에 대해서도 설명합니다.

Delta 테이블

델타 테이블은 OneLake에 있습니다. 파일 기반 데이터를 행과 열로 구성하며 Notebook, Kusto , Lakehouse 및 Warehouse와 같은 Microsoft Fabric 컴퓨팅 엔진에서 사용할 수 있습니다. DAX(데이터 분석 식), MDX(다차원 식), T-SQL(Transact-SQL), Spark SQL 및 Python을 사용하여 델타 테이블을 쿼리할 수 있습니다.

참고 항목

Delta 또는 Delta Lake는 오픈 소스 스토리지 형식입니다. 즉, Fabric은 다른 도구 및 공급업체에서 만든 델타 테이블을 쿼리할 수도 있습니다.

델타 테이블은 데이터를 Parquet 파일에 저장하며, 일반적으로 Direct Lake 의미 체계 모델이 데이터를 로드하는 데 사용하는 레이크하우스에 저장됩니다. 그러나 Parquet 파일은 외부에 저장할 수도 있습니다. 외부 Parquet 파일은 ADLS(Azure Data Lake Storage) Gen2, Amazon S3 스토리지 계정 또는 Dataverse와 같은 특정 스토리지 위치를 가리키는 OneLake 바로 가기를 사용하여 참조할 수 있습니다. 거의 모든 경우에 컴퓨팅 엔진은 델타 테이블을 쿼리하여 Parquet 파일에 액세스합니다. 그러나 일반적으로 Direct Lake 의미 체계 모델은 코드 변환이라는 프로세스를 사용하여 OneLake의 최적화된 Parquet 파일에서 직접 열 데이터를 로드합니다.

데이터 버전 관리

델타 테이블은 하나 이상의 Parquet 파일로 구성됩니다. 이러한 파일에는 델타 테이블과 연결된 각 Parquet 파일의 순서와 특성을 추적하는 JSON 기반 링크 파일 집합이 함께 제공됩니다.

기본 Parquet 파일은 본질적으로 증분이라는 것을 이해하는 것이 중요합니다. 따라서 증분 데이터 수정에 대한 참조로 이름이 Delta입니다. 델타 테이블에 대한 쓰기 작업이 발생할 때마다(예: 데이터가 삽입, 업데이트 또는 삭제되는 경우) 데이터 수정 내용을 버전으로 나타내는 새 Parquet 파일이 만들어집니다. 따라서 Parquet 파일은 변경할 수 없으므로 수정되지 않습니다. 따라서 델타 테이블에 대한 Parquet 파일 집합에서 데이터를 여러 번 복제할 수 있습니다. Delta 프레임워크는 링크 파일을 사용하여 올바른 쿼리 결과를 생성하는 데 필요한 물리적 Parquet 파일을 결정합니다.

이 문서에서 다양한 데이터 수정 작업을 설명하는 데 사용하는 델타 테이블의 간단한 예제를 생각해 보세요. 테이블에는 두 개의 열이 있고 세 개의 행이 저장됩니다.

ProductID	StockOnHand
A	1
B	2
C	3

델타 테이블 데이터는 모든 데이터를 포함하는 단일 Parquet 파일에 저장되며 데이터가 삽입된 시점(추가됨)에 대한 메타데이터를 포함하는 단일 링크 파일이 있습니다.

Parquet 파일 1:
- ProductID: A, B, C
- StockOnHand: 1, 2, 3
링크 파일 1:
- 만들어진 타임스탬프 Parquet file 1 와 데이터가 추가된 레코드를 포함합니다.

삽입 작업

삽입 작업이 발생할 때 발생하는 작업을 고려합니다. 재고가 4 있는 제품의 C 새 행이 삽입됩니다. 이 작업을 수행하면 새 Parquet 파일 및 링크 파일이 만들어지므로 이제 Parquet 파일 2개와 링크 파일 2개가 있습니다.

Parquet 파일 1:
- ProductID: A, B, C
- StockOnHand: 1, 2, 3
Parquet 파일 2:
- ProductID: D
- StockOnHand: 4
링크 파일 1:
- 만들어진 타임스탬프 Parquet file 1 와 데이터가 추가된 레코드를 포함합니다.
링크 파일 2:
- 만들어진 타임스탬프 Parquet file 2 와 데이터가 추가된 레코드를 포함합니다.

이 시점에서 델타 테이블의 쿼리는 다음 결과를 반환합니다. 결과가 여러 Parquet 파일에서 제공되는 것은 중요하지 않습니다.

ProductID	StockOnHand
A	1
B	2
C	3
D	4

모든 후속 삽입 작업은 새 Parquet 파일 및 링크 파일을 만듭니다. 즉, 삽입 작업마다 Parquet 파일 및 링크 파일 수가 증가합니다.

작업 업데이트

이제 업데이트 작업이 발생할 때 발생하는 작업을 고려합니다. 제품의 D 행에 재고가 있는 재고가 변경되었습니다 10. 이 작업을 수행하면 새 Parquet 파일 및 링크 파일이 생성되므로 이제 Parquet 파일 3개와 링크 파일 3개가 있습니다.

Parquet 파일 1:
- ProductID: A, B, C
- StockOnHand: 1, 2, 3
Parquet 파일 2:
- ProductID: D
- StockOnHand: 4
Parquet 파일 3:
- ProductID: C
- StockOnHand: 10
링크 파일 1:
- 만들어진 타임스탬프 Parquet file 1 와 데이터가 추가된 레코드를 포함합니다.
링크 파일 2:
- 만들어진 타임스탬프 Parquet file 2 와 데이터가 추가된 레코드를 포함합니다.
링크 파일 3:
- 만들어진 타임스탬프 Parquet file 3 와 데이터가 업데이트된 레코드를 포함합니다.

이 시점에서 델타 테이블의 쿼리는 다음 결과를 반환합니다.

ProductID	StockOnHand
A	1
B	2
C	10
D	4

이제 제품에 C 대한 데이터가 여러 Parquet 파일에 있습니다. 그러나 델타 테이블에 대한 쿼리는 링크 파일을 결합하여 올바른 결과를 제공하는 데 사용해야 하는 데이터를 결정합니다.

삭제 작업

이제 삭제 작업이 발생할 때 발생하는 작업을 고려합니다. 제품의 B 행이 삭제됩니다. 이 작업을 수행하면 새 Parquet 파일 및 링크 파일이 생성되므로 이제 Parquet 파일 4개와 링크 파일 4개가 있습니다.

Parquet 파일 1:
- ProductID: A, B, C
- StockOnHand: 1, 2, 3
Parquet 파일 2:
- ProductID: D
- StockOnHand: 4
Parquet 파일 3:
- ProductID: C
- StockOnHand: 10
Parquet 파일 4:
- ProductID: A, C, D
- StockOnHand: 1, 10, 4
링크 파일 1:
- 만들어진 타임스탬프 Parquet file 1 와 데이터가 추가된 레코드를 포함합니다.
링크 파일 2:
- 만들어진 타임스탬프 Parquet file 2 와 데이터가 추가된 레코드를 포함합니다.
링크 파일 3:
- 만들어진 타임스탬프 Parquet file 3 와 데이터가 업데이트된 레코드를 포함합니다.
링크 파일 4:
- 만들어진 타임스탬프 Parquet file 4 와 데이터가 삭제된 레코드를 포함합니다.

Parquet file 4 제품에 B대한 데이터는 더 이상 포함되지 않지만 테이블의 다른 모든 행에 대한 데이터가 포함되어 있습니다.

이 시점에서 델타 테이블의 쿼리는 다음 결과를 반환합니다.

ProductID	StockOnHand
A	1
C	10
D	4

참고 항목

이 예제는 작은 테이블, 몇 가지 작업 및 사소한 수정만 포함하기 때문에 간단합니다. 많은 쓰기 작업을 경험하고 많은 데이터 행을 포함하는 큰 테이블은 버전당 둘 이상의 Parquet 파일을 생성합니다.

Important

델타 테이블을 정의하는 방법과 데이터 수정 작업의 빈도에 따라 많은 Parquet 파일이 발생할 수 있습니다. 각 패브릭 용량 라이선스에는 가드레일이 있습니다. Delta 테이블의 Parquet 파일 수가 SKU에 대한 제한을 초과하면 쿼리가 DirectQuery로 대체되어 쿼리 성능이 저하될 수 있습니다.

Parquet 파일 수를 관리하려면 이 문서의 뒷부분에 있는 델타 테이블 유지 관리를 참조하세요.

Delta 시간 이동

링크 파일을 사용하면 이전 시점을 기준으로 데이터를 쿼리할 수 있습니다. 이 기능을 델타 시간 이동이라고합니다. 이전 시점은 타임스탬프 또는 버전일 수 있습니다.

다음 쿼리 예제를 고려합니다.

SELECT * FROM Inventory TIMESTAMP AS OF '2024-04-28T09:15:00.000Z';
SELECT * FROM Inventory AS OF VERSION 2;

팁

약식 구문을 사용하여 @ 테이블 이름의 일부로 타임스탬프 또는 버전을 지정하여 테이블을 쿼리할 수도 있습니다. 타임스탬프는 yyyyMMddHHmmssSSS 형식이어야 합니다. 버전 앞에 v를 추가하여 @ 뒤에 버전을 지정할 수 있습니다.

다음은 약식 구문으로 다시 작성된 이전 쿼리 예제입니다.

SELECT * FROM Inventory@20240428091500000;
SELECT * FROM Inventory@v2;

Important

시간 이동으로 액세스할 수 있는 테이블 버전은 트랜잭션 로그 파일에 대한 보존 임계값과 VACUUM 작업에 대한 빈도 및 지정된 보존의 조합에 따라 결정됩니다(델타 테이블 유지 관리 섹션의 뒷부분에서 설명). 기본값으로 VACUUM 매일을 실행하는 경우 7일간의 데이터를 시간 이동에 사용할 수 있습니다.

프레임

프레이밍 은 의미 체계 모델 열에 데이터를 로드하는 데 사용해야 하는 델타 테이블의 버전을 설정하는 Direct Lake 작업입니다. 또한 이 버전은 데이터를 로드할 때 제외해야 하는 항목도 결정합니다.

프레이밍 작업은 각 델타 테이블의 타임스탬프/버전을 의미 체계 모델 테이블에 스탬프합니다. 이 시점에서 의미 체계 모델이 델타 테이블에서 데이터를 로드해야 하는 경우 가장 최근의 프레이밍 작업과 연결된 타임스탬프/버전을 사용하여 로드할 데이터를 결정합니다. 최신 프레이밍 작업 이후 델타 테이블에 대해 발생하는 모든 후속 데이터 수정은 무시됩니다(다음 프레이밍 작업까지).

Important

프레임 의미 체계 모델은 특정 델타 테이블 버전을 참조하므로 원본은 새 버전의 프레이밍이 완료될 때까지 델타 테이블 버전을 유지해야 합니다. 그렇지 않으면 모델에서 델타 테이블 파일에 액세스해야 하고 생산자 워크로드에 의해 진공 처리되거나 삭제된 경우 오류가 발생합니다.

프레이밍에 대한 자세한 내용은 Direct Lake 개요를 참조하세요.

테이블 분할

행의 하위 집합이 단일 Parquet 파일 집합에 함께 저장되도록 델타 테이블을 분할할 수 있습니다. 파티션은 쓰기 작업뿐만 아니라 쿼리의 속도를 높일 수 있습니다.

2년 동안 10억 행의 판매 데이터가 있는 Delta 테이블을 고려합니다. 모든 데이터를 단일 Parquet 파일 집합에 저장할 수 있지만 이 데이터 볼륨의 경우 읽기 및 쓰기 작업에 적합하지 않습니다. 대신, 10억 행의 데이터를 여러 Parquet 파일에 분산하여 성능을 향상시킬 수 있습니다.

테이블 분할을 설정할 때 파티션 키를 정의해야 합니다. 파티션 키는 계열에 저장할 행을 결정합니다. 델타 테이블의 경우 날짜 테이블의 월/연도 열과 같이 지정된 열의 고유 값에 따라 파티션 키를 정의할 수 있습니다. 이 경우 2년 데이터는 24개 파티션(2년 x 12개월)에 분산됩니다.

패브릭 컴퓨팅 엔진은 테이블 파티션을 인식하지 못합니다. 새 파티션 키 값을 삽입하면 새 파티션이 자동으로 만들어집니다. OneLake에서는 각 고유한 파티션 키 값에 대해 하나의 하위 폴더를 찾을 수 있으며 각 하위 폴더는 자체 Parquet 파일 및 링크 파일 집합을 저장합니다. 하나 이상의 Parquet 파일과 하나의 링크 파일이 있어야 하지만 각 하위 폴더의 실제 파일 수는 다를 수 있습니다. 데이터 수정 작업이 수행되면 각 파티션은 자체 Parquet 파일 집합과 링크 파일을 유지 관리하여 지정된 타임스탬프 또는 버전에 대해 반환할 항목을 추적합니다.

분할된 델타 테이블의 쿼리를 가장 최근 3개월의 판매 데이터로만 필터링하는 경우 액세스해야 하는 Parquet 파일 및 링크 파일의 하위 집합을 빠르게 식별할 수 있습니다. 그러면 여러 Parquet 파일을 모두 건너뛸 수 있으므로 읽기 성능이 향상됩니다.

그러나 파티션 키를 필터링하지 않는 쿼리가 항상 더 잘 수행되지는 않을 수 있습니다. 델타 테이블이 모든 데이터를 하나의 큰 Parquet 파일 집합에 저장하고 파일 또는 행 그룹 조각화가 있는 경우일 수 있습니다. 여러 클러스터 노드에 걸쳐 여러 Parquet 파일에서 데이터 검색을 병렬 처리할 수 있지만 많은 작은 Parquet 파일은 파일 I/O에 부정적인 영향을 주므로 쿼리 성능에 부정적인 영향을 줄 수 있습니다. 이러한 이유로 쓰기 작업이나 ETL(추출, 변환 및 로드) 프로세스가 명확하게 이점을 얻지 않는 한 대부분의 경우 델타 테이블을 분할하지 않는 것이 가장 좋습니다.

파일 작업은 수정되거나 삭제된 행의 파티션 키와 일치하는 하위 폴더에서만 수행되므로 분할은 삽입, 업데이트 및 삭제 작업에도 유용합니다. 예를 들어 데이터 일괄 처리가 분할된 델타 테이블에 삽입되는 경우 데이터는 일괄 처리에 존재하는 파티션 키 값을 확인하기 위해 평가됩니다. 그런 다음 데이터는 파티션에 대한 관련 폴더로만 전달됩니다.

델타 테이블이 파티션을 사용하는 방법을 이해하면 큰 델타 테이블을 업데이트할 때 수행해야 하는 쓰기 작업을 줄이는 최적의 ETL 시나리오를 설계하는 데 도움이 될 수 있습니다. 작성해야 하는 새 Parquet 파일의 수와 크기를 줄여 쓰기 성능이 향상됩니다. 이전 예제에 설명된 대로 월/연도별로 분할된 큰 델타 테이블의 경우 새 데이터는 최신 파티션에 새 Parquet 파일만 추가합니다. 이전 달력 월의 하위 폴더는 그대로 유지됩니다. 이전 달력 월의 데이터를 수정해야 하는 경우 관련 파티션 폴더만 새 파티션 및 링크 파일을 받습니다.

Important

델타 테이블의 주요 목적이 의미 체계 모델(및 보조 쿼리 워크로드)에 대한 데이터 원본으로 사용되는 경우 일반적으로 열의 메모리 로드를 최적화하기 위한 기본 설정에서 분할을 방지하는 것이 좋습니다.

Direct Lake 의미 체계 모델 또는 SQL 분석 엔드포인트의 경우 델타 테이블 파티션을 최적화하는 가장 좋은 방법은 Fabric이 각 버전의 Delta 테이블에 대한 Parquet 파일을 자동으로 관리하도록 하는 것입니다. 관리를 Fabric에 맡기면 병렬 처리를 통해 쿼리 성능이 높아지게 되지만 반드시 최상의 쓰기 성능을 제공하는 것은 아닙니다.

쓰기 작업을 최적화해야 하는 경우 파티션을 사용하여 파티션 키를 기반으로 델타 테이블에 대한 쓰기 작업을 최적화하는 것이 좋습니다. 그러나 델타 테이블을 분할하면 읽기 성능에 부정적인 영향을 미칠 수 있습니다. 이러한 이유로 타이밍을 비교하기 위해 서로 다른 구성으로 동일한 델타 테이블의 여러 복사본을 만들어 읽기 및 쓰기 성능을 신중하게 테스트하는 것이 좋습니다.

Warning

높은 카디널리티 열에서 분할하는 경우 Parquet 파일 수가 너무 많을 수 있습니다. 모든 패브릭 용량 라이선스에는 가드레일이 있습니다. Delta 테이블의 Parquet 파일 수가 SKU에 대한 제한을 초과하면 쿼리가 DirectQuery로 대체되어 쿼리 성능이 저하될 수 있습니다.

Parquet 파일

델타 테이블의 기본 스토리지는 하나 이상의 Parquet 파일입니다. Parquet 파일 형식은 일반적으로 한 번 쓰기, 읽기-다 애플리케이션에 사용됩니다. 새 Parquet 파일은 삽입, 업데이트 또는 삭제 작업으로 델타 테이블의 데이터가 수정될 때마다 만들어집니다.

참고 항목

OneLake 파일 탐색기 같은 도구를 사용하여 델타 테이블과 연결된 Parquet 파일에 액세스할 수 있습니다. 다른 파일을 이동하는 것만큼 쉽게 파일을 다운로드, 복사 또는 다른 대상으로 이동할 수 있습니다. 그러나 컴퓨팅 엔진이 델타 테이블로 파일에 대해 쿼리를 실행하도록 허용하는 Parquet 파일과 JSON 기반 링크 파일의 조합입니다.

Parquet 파일 형식

Parquet 파일의 내부 형식은 CSV, TSV, XMLA 및 JSON과 같은 다른 일반적인 데이터 스토리지 형식과 다릅니다. 이러한 형식은 행별로 데이터를 구성하고 Parquet은 데이터를 열별로 구성합니다. 또한 Parquet 파일 형식은 데이터 행을 하나 이상의 행 그룹으로 구성하기 때문에 이러한 형식과 다릅니다.

Power BI 의미 체계 모델의 내부 데이터 구조는 열 기반이므로 Parquet 파일은 Power BI와 많은 공통점을 공유합니다. 이러한 유사성은 Direct Lake 의미 체계 모델이 Parquet 파일의 데이터를 메모리에 직접 효율적으로 로드할 수 있음을 의미합니다. 실제로 매우 많은 양의 데이터를 몇 초 안에 로드할 수 있습니다. 이 기능을 블록 또는 원본 데이터를 검색한 다음, 처리, 인코딩, 저장한 다음 메모리에 로드해야 하는 가져오기 의미 체계 모델의 새로 고침과 대조합니다. 의미 체계 모델 새로 고침 가져오기 작업은 상당한 양의 컴퓨팅(메모리 및 CPU)을 사용하고 완료하는 데 상당한 시간이 걸릴 수도 있습니다. 그러나 델타 테이블을 사용하면 Parquet 파일이 생성될 때 의미 체계 모델로 직접 로드하는 데 적합한 데이터를 준비하기 위한 대부분의 노력이 수행됩니다.

Parquet 파일에서 데이터를 저장하는 방법

다음 예제 데이터 집합을 고려합니다.

날짜	ProductID	StockOnHand
2024-09-16	A	10
2024-09-16	B	11
2024-09-17	A	13
…

Parquet 파일 형식으로 저장되는 경우 개념적으로 이 데이터 집합은 다음 텍스트와 같이 표시될 수 있습니다.

Header:
RowGroup1:
    Date: 2024-09-16, 2024-09-16, 2024-09-17…
    ProductID: A, B, A…
    StockOnHand: 10, 11, 13…
RowGroup2:
    …
Footer:

데이터는 일반 값에 대한 사전 키를 대체하고 RLE(실행 길이 인코딩)을 적용하여 압축됩니다. RLE은 일련의 동일한 값을 더 작은 표현으로 압축하려고 합니다. 다음 예제에서는 숫자 키를 값에 매핑하는 사전을 헤더에 만들고 데이터 값 대신 더 작은 키 값을 사용합니다.

Header:
    Dictionary: [
        (1, 2024-09-16), (2, 2024-09-17),
        (3, A), (4, B),
        (5, 10), (6, 11), (7, 13)
        …
    ]
RowGroup1:
    Date: 1, 1, 2…
    ProductID: 3, 4, 3…
    StockOnHand: 5, 6, 7…
Footer:

Direct Lake 의미 체계 모델에 그룹ProductID화된 열의 StockOnHand 합계를 계산하기 위해 데이터가 필요한 경우 두 열과 연결된 사전 및 데이터만 필요합니다. 많은 열이 포함된 큰 파일에서 Parquet 파일의 상당 부분을 건너뛰어 읽기 프로세스를 가속화할 수 있습니다.

참고 항목

Parquet 파일의 내용은 사람이 읽을 수 없으므로 텍스트 편집기에서 여는 데 적합하지 않습니다. 그러나 Parquet 파일의 내용을 열고 표시할 수 있는 많은 오픈 소스 도구가 있습니다. 이러한 도구를 사용하면 파일에 포함된 행 및 행 그룹 수와 같은 메타데이터를 검사할 수도 있습니다.

V-Order

Fabric은 V-Order라는 추가 최적화를 지원합니다. V-Order는 Parquet 파일 형식에 대한 쓰기 시간 최적화입니다. V-Order가 적용되면 파일 읽기 속도가 더 작고 빨라집니다. 이 최적화는 메모리에 빠르게 로드하기 위해 데이터를 준비하므로 용량 리소스에 대한 요구가 적기 때문에 Direct Lake 의미 체계 모델과 특히 관련이 있습니다. 또한 더 적은 메모리를 스캔해야 하므로 쿼리 성능이 더 빨라집니다.

데이터 파이프라인, 데이터 흐름 및 Notebook과 같은 패브릭 항목에서 만들고 로드한 델타 테이블은 자동으로 V-Order를 적용합니다. 그러나 Fabric Lakehouse에 업로드되거나 바로 가기에서 참조되는 Parquet 파일은 이 최적화를 적용하지 않을 수 있습니다. 최적화되지 않은 Parquet 파일은 계속 읽을 수 있지만 읽기 성능은 V 주문이 적용된 동등한 Parquet 파일만큼 빠르지 않을 수 있습니다.

참고 항목

V 순서가 적용된 Parquet 파일은 여전히 오픈 소스 Parquet 파일 형식을 준수합니다. 따라서 비 패브릭 도구에서 읽을 수 있습니다.

자세한 내용은 Delta Lake 테이블 최적화 및 V 순서를 참조하세요.

델타 테이블 최적화

이 섹션에서는 의미 체계 모델에 대한 델타 테이블을 최적화하기 위한 다양한 항목에 대해 설명합니다.

데이터 볼륨

델타 테이블은 매우 많은 양의 데이터를 저장하도록 확장할 수 있지만 패브릭 용량 가드레일은 쿼리하는 의미 체계 모델에 제한을 적용합니다. 이러한 제한을 초과하면 쿼리가 DirectQuery로 대체되어 쿼리 성능이 저하될 수 있습니다.

따라서 세분성(요약된 데이터 저장)을 높이거나, 차원을 줄이거나, 기록을 더 적게 저장하여 큰 팩트 테이블 의 행 수를 제한하는 것이 좋습니다.

또한 V-Order가 더 작고 따라서 읽을 파일이 더 빨라지므로 적용되었는지 확인합니다.

열 데이터 형식

각 델타 테이블의 모든 열에서 카디널리티(고유 값 수)를 줄이려고 노력합니다. 모든 열이 해시 인코딩을 사용하여 압축되고 저장되기 때문입니다. 해시 인코딩을 사용하려면 열에 포함된 각 고유 값에 숫자 식별자를 할당하기 위해 V 순서 최적화가 필요합니다. 스토리지 및 쿼리 중에 해시 조회가 필요한 숫자 식별자입니다.

부동 소수점 및 실제와 같은 근사치 데이터 형식을 사용하는 경우 값을 반올림하고 더 낮은 정밀도를 사용하는 것이 좋습니다.

불필요한 열

데이터 테이블과 마찬가지로 델타 테이블은 필요한 열만 저장해야 합니다. 이 문서의 컨텍스트에서 이는 의미 체계 모델에 필요한 것을 의미하지만 델타 테이블을 쿼리하는 다른 분석 워크로드가 있을 수 있습니다.

델타 테이블에는 모델 관계를 지원하는 열 외에도 필터링, 그룹화, 정렬 및 요약을 위해 의미 체계 모델에 필요한 열이 포함되어야 합니다. 불필요한 열은 의미 체계 모델 쿼리 성능에 영향을 주지 않지만(메모리에 로드되지 않으므로) 스토리지 크기가 커지므로 로드 및 유지 관리하기 위해 더 많은 컴퓨팅 리소스가 필요합니다.

Direct Lake 의미 체계 모델은 계산 열을 지원하지 않으므로 델타 테이블에서 이러한 열을 구체화해야 합니다. 이 디자인 방법은 Import 및 DirectQuery 의미 체계 모델에 대한 안티 패턴입니다. 예를 들어 열이 있고 LastName 열이 필요한 FullName 경우 FirstName 델타 테이블에 행을 삽입할 때 이 열의 값을 구체화합니다.

일부 의미 체계 모델 요약은 둘 이상의 열에 따라 달라질 수 있습니다. 예를 들어 판매를 계산하기 위해 모델의 측정값은 두 열의 곱을 합산합니다. Quantity Price 이러한 열 중 어느 것도 독립적으로 사용되지 않으면 구성 요소 값을 별도의 열에 저장하는 것보다 판매 계산을 단일 열로 구체화하는 것이 더 효율적입니다.

행 그룹 크기

내부적으로 Parquet 파일은 데이터 행을 각 파일 내의 여러 행 그룹으로 구성합니다. 예를 들어 30,000개의 행이 포함된 Parquet 파일은 각각 10,000개의 행이 있는 3개의 행 그룹으로 청크할 수 있습니다.

행 그룹의 행 수는 Direct Lake에서 데이터를 읽는 빈도에 영향을 줍니다. 행 수가 적은 행 그룹이 많을수록 과도한 I/O로 인해 열 데이터를 의미 체계 모델로 로드하는 데 부정적인 영향을 줄 수 있습니다.

일반적으로 기본 행 그룹 크기를 변경하지 않는 것이 좋습니다. 그러나 큰 델타 테이블의 행 그룹 크기를 변경하는 것이 좋습니다. 타이밍을 비교하기 위해 서로 다른 구성으로 동일한 델타 테이블의 여러 복사본을 만들어 읽기 및 쓰기 성능을 신중하게 테스트해야 합니다.

Important

모든 패브릭 용량 라이선스에는 가드레일이 있습니다. 델타 테이블의 행 그룹 수가 SKU에 대한 제한을 초과하면 쿼리가 DirectQuery로 대체되어 쿼리 성능이 저하될 수 있습니다.

델타 테이블 유지 관리

시간이 지남에 따라 쓰기 작업이 수행되면 델타 테이블 버전이 누적됩니다. 결국 읽기 성능에 부정적인 영향을 미칠 수 있는 지점에 도달할 수 있습니다. 더 나쁜 것은 테이블당 Parquet 파일 수 또는 테이블당 행 그룹 또는 테이블당 행 수가 용량의 가드레일을 초과하면 쿼리가 DirectQuery로 대체되어 쿼리 성능이 저하될 수 있습니다. 따라서 델타 테이블을 정기적으로 유지하는 것이 중요합니다.

OPTIMIZE

OPTIMIZE를 사용하여 델타 테이블을 최적화하여 더 작은 파일을 더 큰 파일로 병합할 수 있습니다. 지정된 파티션 조건자와 일치하는 행의 필터링된 하위 집합만 대상으로 지정하도록 절을 설정할 WHERE 수도 있습니다. 파티션 키와 관련된 필터만 지원됩니다. 이 OPTIMIZE 명령은 V 순서를 적용하여 Parquet 파일을 압축하고 다시 쓸 수도 있습니다.

ETL 프로세스가 완료되는 날마다 정기적으로 자주 업데이트되는 대규모 델타 테이블에서 이 명령을 실행하는 것이 좋습니다. 더 나은 쿼리 성능과 테이블을 최적화하는 데 필요한 리소스 사용 비용 간의 균형을 유지합니다.

VACUUM

VACUUM을 사용하여 더 이상 참조되지 않거나 설정된 보존 임계값보다 오래된 파일을 제거할 수 있습니다. 적절한 보존 기간을 설정해야 합니다. 그렇지 않으면 의미 체계 모델 테이블에 스탬프된 프레임보다 오래된 버전으로 다시 이동하는 시간이 손실될 수 있습니다.

Important

REORG TABLE

REORG TABLE을 사용하여 ALTER TABLE DROP COLUMN을 사용하여 열을 삭제하는 경우와 같이 파일을 다시 작성하여 일시 삭제된 데이터를 제거하여 델타 테이블을 다시 구성할 수 있습니다.

테이블 유지 관리 자동화

테이블 유지 관리 작업을 자동화하기 위해 Lakehouse API를 사용할 수 있습니다. 자세한 내용은 Microsoft Fabric REST API를 사용하여 Lakehouse 관리를 참조하세요.

팁

Fabric 포털에서 Lakehouse 테이블 유지 관리 기능을 사용하여 델타 테이블 관리를 간소화할 수도 있습니다.

다음을 통해 공유

Direct Lake 의미 체계 모델에 대한 스토리지 이해

Delta 테이블

데이터 버전 관리

삽입 작업

작업 업데이트

삭제 작업

Delta 시간 이동

프레임

테이블 분할

Parquet 파일

Parquet 파일 형식

Parquet 파일에서 데이터를 저장하는 방법

V-Order

델타 테이블 최적화

데이터 볼륨

열 데이터 형식

불필요한 열

행 그룹 크기

델타 테이블 유지 관리

OPTIMIZE

VACUUM

REORG TABLE

테이블 유지 관리 자동화

피드백

추가 리소스

다음을 통해 공유

Direct Lake 의미 체계 모델에 대한 스토리지 이해

Delta 테이블

데이터 버전 관리

삽입 작업

작업 업데이트

삭제 작업

Delta 시간 이동

프레임

테이블 분할

Parquet 파일

Parquet 파일 형식

Parquet 파일에서 데이터를 저장하는 방법

V-Order

델타 테이블 최적화

데이터 볼륨

열 데이터 형식

불필요한 열

행 그룹 크기

델타 테이블 유지 관리

OPTIMIZE

VACUUM

REORG TABLE

테이블 유지 관리 자동화

관련 콘텐츠

피드백

추가 리소스