Microsoft Fabric의 델타 테이블은 OneLake에 저장된 데이터를 기반으로 Spark, SQL 분석 엔드포인트, Power BI Direct Lake, Warehouse 및 기타 Fabric 경험을 제공할 수 있습니다. 최적의 교차 작업 성능은 두 가지 요인에 따라 달라집니다:
- 테이블을 만들고 유지하는 작업량입니다.
- 테이블을 집어삼키는 엔진들.
레이크하우스 테이블은 일반적으로 Spark, Fabric pipeline 복사 작업, 또는 Dataflow Gen2에서 관리됩니다. Spark는 가장 일반적인 작성자이며 가장 광범위한 레이아웃 및 유지보수 제어를 제공합니다. 창고 및 데이터베이스 미러링은 물리적 레이아웃을 자동으로 관리합니다. 미러형 카탈로그는 소스 시스템에서 관리하는 레이아웃을 유지합니다. 소비자 요구사항은 대체로 호환되지만, Power BI Direct Lake는 최적의 성능을 위해 추가 저장 공간 요구사항이 있습니다.
요구 사항이 일치할 때는 하나의 공유 테이블을 사용하세요. 다른 테이블을 정당화하는 예외에 대해서는 ' 언제 또 다른 테이블을 만들 것인가'를 참조하세요.
레이아웃 소유권 이해하기
먼저 물리적 테이블 레이아웃을 소유하는 작업 부하를 식별하는 것부터 시작하세요. 다음 표의 컨트롤은 각 엔진의 기능을 포괄적으로 나열한 것이 아니라, 크로스 워크로드 테이블 레이아웃과 유지보수에 관련된 핵심 컨트롤입니다.
| 데이터 저장소 | 작성자 또는 섭취 방법 | 레이아웃 및 유지 관리 담당 | 주요 제어 |
|---|---|---|---|
| Lakehouse | Spark | 사용자 관리형 |
파일 크기 조정: 적응형 대상 파일 크기 및 파일 수준 압축 대상. 쓰기 및 유지보수: 삭제 벡터, 자동 압축, 쓰기 최적화 OPTIMIZEVACUUM, 그리고 . 데이터 조직: 액체 클러스터링, 분할,Z-순서, V-순서. |
| Lakehouse | Fabric 파이프라인 복사 작업 또는 Dataflow Gen2 | 서비스는 데이터를 기록합니다; 호숫가 집 주인이 테이블을 관리합니다 | 목적지별 쓰기 설정. Spark, Lakehouse 유지보수 또는 파이프라인 유지보수 활동을 사용하여 호환되는 유지보수를 별도로 수행하세요. |
| 창고 | Fabric Data Warehouse, Fabric 파이프라인의 복사 작업 또는 Dataflow Gen2 | 창고 관리 | 데이터 클러스터링 과 창고 수준의 V-Order 설정. |
| 미러링된 항목 | 미러링 서비스 | 미러링 유형에 따라 다릅니다 | 데이터베이스 미러링은 직접적인 레이아웃 제어가 없는 시스템 관리 V-순서 델타 레이아웃을 사용합니다. 미러드 카탈로그는 소스 파일 레이아웃을 유지하며, 지원 시 소스 시스템에서 최적화할 수 있습니다. |
교차 작업 부하 지침
다음 표는 생산자와 소비자가 권장하는 접근법을 요약한 것입니다.
| Producer | Consumer | 권장되는 접근 방식 |
|---|---|---|
| 레이크하우스: 스파크 작가 | Spark | Fabric Spark 런타임 2.0 이상 기본 설정을 사용하고 자동 압축을 활성화하세요. 액체 클러스터링은 측정된 조건자가 향상된 파일 건너뛰기의 이점을 얻는 경우 고려하세요. |
| 레이크하우스: 스파크 작가 | SQL 분석 엔드포인트 | Spark에 권장되는 레이아웃을 사용하세요. SQL 분석 엔드포인트 성능 때문에만 정적인 목표 파일 크기, 임의의 행 제한, V-Order 를 설정하지 마세요. |
| 레이크하우스: 스파크 작가 | Power BI 다이렉트 레이크 | Spark에 권장되는 동일한 레이아웃을 사용하고 추가로 V-Order를 활성화하거나 리소스 프로필을readHeavyForPBI 사용하세요. |
| Lakehouse: Fabric 파이프라인 또는 Dataflow Gen2 라이터 | Spark, SQL 분석 엔드포인트, 또는 Power BI Direct Lake | 결과 파일 레이아웃을 모니터링하고 호환되는 호숫가 유지 관리를 별도로 일정 조정하세요. Dataflow Gen2 점진적 갱정과 같은 일부 목적지 모드는 유지보수 제한을 부과합니다. |
| 창고 | Fabric Data Warehouse 또는 스파크 | 시스템 관리 레이아웃을 사용하세요. Fabric Data Warehouse 압축 및 기타 유지 관리를 자동으로 수행합니다. 데이터 클러스터링 을 사용해 반복 선택적 술어가 있는 워크로드의 파일 건너뛰기를 개선하세요. |
| 창고 | Power BI 다이렉트 레이크 | 기본 창고 V-Order 설정을 유지하세요. 공유 쿼리 패턴에 유리할 때 데이터 클러스터링 을 사용하세요. |
| Mirroring | Spark, SQL 분석 엔드포인트, 또는 Power BI Direct Lake | 데이터베이스 미러링의 경우, 시스템 관리 V-Ordered Delta 레이아웃을 사용하세요. 미러드 카탈로그의 경우, 지원 시 소스 시스템 내 기본 파일을 최적화하세요. 'Fabric에서 미러링이란 무엇인가?'를 참고하세요. |
레이크하우스 테이블 최적화
Lakehouse Delta 테이블은 Spark, Pipeline 복사 작업 또는 Dataflow Gen2에서 기록하든 관계없이 명시적인 유지 관리 전략이 필요합니다. Spark는 이 섹션에서 가장 넓은 레이아웃 및 유지보수 통제를 제공하기 때문에 Fabric 주요 예입니다.
중요합니다
테이블 유지보수는 엔진 간 최적의 쓰기 및 읽기 성능을 위해 매우 중요합니다. 초기 유지보수 없이도 잘 작동하는 보조 전용 워크로드도 과도한 작은 파일이 쌓일 수 있으며, 이는 Spark, SQL 분석 엔드포인트, Direct Lake, 외부 데이터 리더에 영향을 미칩니다. 자동 및 수동 압축 방법에 대해서는 Compacting Delta 표 를 참조하세요.
Spark 런타임 기본값을 사용하세요
Spark가 테이블을 작성할 때는 Fabric Spark 런타임 2.0 이상 기본값을 사용하세요:
- 적응형 목표 파일 크기를 계속 활성화하세요. 각 테이블마다 128MB에서 1GB 사이의 타겟을 자동으로 선택합니다.
- 이전 적응형 목표를 충족하는 파일을 재작성하지 않도록 파일 수준의 압축 목표를 계속 활성화하세요.
- 삭제 벡터를 계속 활성화하세요.
- 파일당 임의의 최대 행 수를 강요하지 마세요. 행 너비는 다양하기 때문에 행 제한이 좁은 테이블에 과도한 작은 파일을 만들 수 있습니다.
Fabric Spark 1.3 런타임에서는 적응형 타겟 파일 크기, 파일 수준 압축 타겟, 삭제 벡터가 옵트인 설정으로 제공됩니다.
Pipeline 복사 작업 또는 Dataflow Gen2가 테이블을 작성할 때, 결과 파일 레이아웃을 점검하고 별도로 유지보수 일정을 잡으세요. 이 작성자들이 Spark 런타임 기본값을 적용한다고 가정하지 마세요.
- Fabric 파이프라인은 쓰기 작업 후 Lakehouse 유지 관리 작업을 오케스트레이션할 수 있습니다.
중요합니다
점진적 새로 고침을 사용하는 Dataflow Gen2 레이크하우스 대상은 REORG TABLE 또는 OPTIMIZE을(를) 지원하지 않습니다.
Dataflow Gen2의 점진적 새로고침 제한을 준수하세요.
작은 파일을 방지하고 압축하세요
Spark에서 작성한 테이블의 경우, 자동 압축(auto compaction)을 사용하세요. 이 기능은 쓰기 후 테이블 분할을 평가하며, 필요할 때만 컴팩트를 실행합니다. 유지보수 실행 전에 별도의 테이블 상태 검사가 필요 없게 됩니다.
예외 및 보완 기능에 대해 다음 지침을 참고하세요:
| Scenario | 권장되는 접근 방식 |
|---|---|
| Spark로 작성된 테이블 | 자동 압축을 기본 유지보수 전략으로 활성화하세요. |
| 스트리밍 또는 마이크로배치 쓰기 작업 | 자동 압축을 활성화하고 쓰기를 최적화하여 작은 파일 누적을 줄이세요. |
| 엄격한 쓰기 지연 요구사항이 있는 워크로드 | 동기식 자동 압축 대신 별도로 일정을 잡으세요OPTIMIZE. |
| 누적된 작은 파일이 포함된 기존 테이블 | 한 번 OPTIMIZE을 실행한 다음, 지속적인 유지 관리를 위해 자동 압축을 활성화하세요. |
| 자주 업데이트, 삭제 또는 병합이 이루어지는 테이블 | 삭제 벡터와 자동 압축을 계속 활성화하세요. |
OPTIMIZE 파일을 압축하고, 삭제 벡터가 참조한 기록이 5% 이상일 경우 파일의 삭제 벡터를 자동으로 삭제합니다. 해당 기준치 이하로 기록을 물리적으로 삭제하거나 특정 준수 요건을 충족할 때만 사용 REORG TABLE ... APPLY (PURGE) 하세요.
메모
자동 압축은 분할도 작은 파일 트리거 조건을 충족하는 경우에만 삭제 벡터를 제거합니다. 워크로드가 작은 파일을 생성하지 않고 업데이트나 삭제를 수행한다면, 주기적으로 자격을 갖춘 삭제 벡터를 정화하기 위해 실행 OPTIMIZE 하세요. 물리적으로 정화를 강제로 해야 할 때 사용 REORG TABLE ... APPLY (PURGE) 하세요.
보존 기간 이후에는 참조되지 않은 파일을 삭제하기 위해 별도의 일정으로 실행 VACUUM 하세요.
VACUUM 저장 공간을 되찾지만 활성 파일 레이아웃은 개선되지 않습니다.
Warning
타임 트래블 요구사항과 동시 읽기 또는 쓰기 작업을 평가하지 않고 VACUUM 유지 기간을 단축하지 마세요. 파일을 너무 일찍 삭제하면 필요한 테이블 버전을 사용할 수 없게 될 수 있습니다.
파일 건너뛰기 데이터를 정리하기
반복 필터나 처리 패턴이 파일 건너뛰기 개선으로 이점을 얻을 때는 액체 클러스터링을 사용하세요. 액체 클러스터 테이블은 새로 작성된 데이터를 정리하기 위해 자동 압축이 필요합니다OPTIMIZE.
기본적으로 파티션을 피하세요. 특정 요구사항이 운영상의 상충을 정당화할 때, 예를 들어 데이터를 업데이트, 삭제, 병합하는 동시 작성자를 분리하는 등 서로 다른 파티션 간에 데이터를 분리할 때 사용하세요. 자세한 내용은 'When to use partitioning'을 참고하세요.
기존의 파티셔닝된 테이블의 경우, 선택적 조건자가 파티션 내에서 동일한 열을 기준으로 자주 필터링한다면 Z-Order를 고려하세요.
웨어하우스 관리형 테이블 최적화
Fabric Data Warehouse 인제스 방식과 관계없이 물리적 델타 테이블 레이아웃을 관리합니다.
Warehouse가 제공하는 전략적 통제 기능을 활용해 데이터 레이아웃을 조정하세요:
- 동일한 열에 대해 선택도가 높은 조건자가 쿼리에서 반복적으로 사용되는 경우, 대규모 테이블에는 데이터 클러스터링을 적용하세요.
- 읽기 지향 및 혼합 작업 부하를 위해 V-Order 를 계속 활성화하세요. V-Order는 기본적으로 활성화되어 있습니다.
- 쓰기 집약적인 웨어하우스 작업에서는 V-Order를 비활성화 하는 것을 고려해 보세요.
Warning
V-오더 비활성화는 창고 수준에서 일어나는 되돌릴 수 없는 작업입니다. 전체 읽기 및 쓰기 작업을 비활성화하기 전에 테스트하세요.
전체 창고 지침은 Fabric Data Warehouse의 성과 지침을 참조하십시오.
미러드 데이터 최적화
물리적 레이아웃을 개선할 수 있는 능력은 Fabric이 데이터를 복제하는지, 아니면 소스 파일을 참조하는지에 달려 있습니다:
- 데이터베이스 미러링: Fabric은 원본 데이터를 OneLake의 Delta 테이블로 복제하고, V-Ordered 파일 레이아웃과 유지보수를 관리합니다. 미러된 목적지에서 목표 파일 크기, 삭제 벡터 정리, 액체 클러스터링, 파티션, V-Order를 직접 설정할 수 없습니다.
- 미러 카탈로그: Fabric은 메타데이터를 동기화하고 OneLake 단축키를 사용해 소스 데이터를 현장에서 참조합니다. Fabric은 이 파일들을 다시 작성하거나 유지하지 않습니다. 지원 기능이 허용할 때 소스 시스템의 물리적 레이아웃과 정리를 개선하세요. 이러한 변경 사항은 Fabric에서 별도의 복사본을 만들지 않고도 단축키를 통해 확인할 수 있습니다.
데이터베이스 미러 데이터의 경우:
- 선택도가 높은 조건식을 사용하고 Spark 및 SQL 쿼리에서 불필요한 열은 조회하지 마세요.
- 효율적인 Direct Lake 소비를 위한 Power BI 시맨틱 모델과 DAX 측정 도구를 설계합니다.
미러 카탈로그의 경우:
- 소스 플랫폼의 지원되는 테이블 유지 및 레이아웃 기능을 활용하세요.
- 단축키를 쿼리하는 Fabric 소비자의 소스 파일과 행 그룹 분포를 평가하세요.
- Direct Lake의 경우, 소스 레이아웃이 성능 요구를 충족하지 못할 때 추가로 차원 모델링된 V-Ordered 서빙 레이어를 생성하는 것을 고려하세요.
미러링 개념, 타입, 지원되는 소스에 대해서는 'Fabric에서의 미러링이란 무엇인가?'와 메타데이터 미러링이 어떻게 작동하는지를 참고하세요.
소비자별 최적화 적용
Spark와 SQL 분석 엔드포인트는 동일한 적응형 레이크하우스 레이아웃에서 잘 작동합니다. 적응형 대상 파일 크기를 사용해 지나치게 작은 파일이 과도하게 생성되는 것을 방지하고, 측정된 조건자가 개선된 파일 건너뛰기의 이점을 얻는 경우 리퀴드 클러스터링을 적용합니다. Spark나 SQL 분석 엔드포인트 성능 때문만으로 V-Order 를 활성화하지 마세요. 엔진별 세부 사항은 SQL 분석 엔드포인트 성능 고려사항을 참조하세요.
Power BI 다이렉트 레이크
Direct Lake는 동일한 기본 Delta 테이블을 사용하지만, 트랜스코딩과 증분 프레이밍과 관련된 권고사항을 추가합니다:
- 파일 및 행 그룹 배치: 작은 행 그룹 과 불균일한 행 그룹 분포를 피하세요. 이 레이아웃은 VertiPaq 컬럼 세그먼트를 더 많이 생성하고 트랜스코딩 오버헤드를 증가시킵니다.
-
V-명령: 크로스-워크로드 가이드의 생산자 특화 권고사항을 따릅니다. 주로 Direct Lake를 통해 소비되는 Spark에서 작성된 테이블의 경우, V-Order를 활성화하거나 리소스 프로필을
readHeavyForPBI사용하세요. - 업데이트 패턴: 가능한 한 첨부 친화적인 업데이트 패턴 을 선호하여 기존 Parquet 파일을 보존하고 점진적 프레이밍을 지원하세요.
메모
Direct Lake는 일반적으로 100만 행에서 1,600만 줄 사이의 줄 그룹에서 가장 좋은 성능을 보입니다. 지원되는 생산자 설정을 변경하기 전에 행 그룹 분포와 Direct Lake 성능을 평가하세요.
Spark에서 작성된 테이블의 경우, spark.sql.parquet.native.writer.maxRowGroupRowCount네이티브 실행 엔진 이 Parquet 파일을 쓸 때 행 그룹당 최대 행 수를 설정합니다. 기본값은 0이며, 이는 최대값을 부과하지 않습니다. 분석 결과 행 그룹 크기가 Direct Lake 성능에 영향을 미친다면, 테이블을 작성하거나 다시 작성하기 전에 테스트 한계를 설정하세요. 다음은 그 예입니다.
spark.conf.set("spark.sql.parquet.native.writer.maxRowGroupRowCount", 8_000_000)
특정 행 수를 맞추기 위해서만 제한을 설정하지 마세요. 행 너비, 압축, 파일 분포, 용량 병렬성도 성능에 영향을 미칩니다. Delta Analyzer를 사용하여 결과 레이아웃을 평가하세요.
프레이밍, 트랜스코딩, 행 그룹, 업데이트 패턴, 델타 분석기에 대한 자세한 지침은 'Understand Direct Lake 쿼리 성능'을 참조하세요.
메달리온 레이어에 가이드를 적용하세요
청동, 은, 금은 데이터 목적과 정제를 나타냅니다. 레이아웃이 사용자 관리인지 시스템 관리인지 결정하지 않으며, 각 소비자마다 별도의 복사본을 요구하지도 않습니다.
| 레이어 | 기본 목표 | 교차 작업 부하 지침 |
|---|---|---|
| 청동 (착지) | 소스 충실도와 인제스트 처리량 유지 | 자동 압축 기능을 적용해 Spark가 작성한 테이블을 유지하면서 쓰기 처리량을 우선시하세요. Power BI Direct Lake 시맨틱 모델을 원시 브론즈 테이블에 사용하지 마세요. 의도적으로 모델과 데이터 형태를 설계하지 않는 한요. |
| 실버 (큐레이팅) | 재사용을 위해 검증되고 일치한 데이터를 제공하세요 | 호환되는 Fabric 소비자들 간에 테이블을 재사용하세요. Spark가 작성한 호숫가 테이블의 경우, Direct Lake가 주요 소비자일 때만 V-Order 를 활성화하세요. |
| 골드(제공) | 비즈니스에 바로 활용할 수 있는 차원, 팩트, 집계 및 분석 모델을 제공합니다 | Direct Lake 의미론 모델에는 이 레이어를 선호합니다. 호환 가능한 소비자 간에 테이블을 재사용하고, 이 글에서 설명한 생산자별 통제를 적용하세요. |
레이아웃 및 유지보수 문제 해결
생산자 인식 기반 복원을 활용하세요. 목적지 모드가 해당 작업을 지원할 때 호수하우스 테이블에 Spark 유지 관리 명령을 적용하세요. 신호를 보편적 임계값이 아닌 지표로 간주하고, 테이블의 쓰기 패턴과 소비자 성능에 대해 검증하세요.
| 상태 | 신호 | 호숫가 테이블 | 창고 테이블 |
|---|---|---|---|
| 과도한 소형 파일 | 파일 수는 활성 테이블 크기보다 빠르게 증가하며, 파일은 적응 대상 이하로 유지됩니다. | Spark에서는 기존 백로그에 대해 일회성 OPTIMIZE 실행 후 자동 압축을 활성화하세요. 파이프라인 Copy 활동 또는 Dataflow Gen2 쓰기의 경우, 지원되는 레이크하우스 유지 관리를 별도로 예약하세요. |
아무 행동도 필요 없습니다. 창고 압축은 자동으로 이루어집니다. |
| 레거시 오버사이즈 파일 | 파일은 현재 적응 목표보다 훨씬 높게 유지되며, 너무 적은 파일이 스캔 병렬성을 제한합니다. | 덮어쓰기를 사용하거나 CREATE OR REPLACE TABLE AS SELECT적응형 타겟 파일 크기를 활성화하여 테이블을 다시 작성합니다. |
아무 행동도 필요 없습니다. Warehouse는 파일 크기를 자동으로 관리합니다. |
| 삭제 벡터 축적 |
DESCRIBE HISTORY 지표 는 삭제 벡터가 압축 제거보다 더 빠르게 추가되거나 업데이트되어 읽기 오버헤드가 증가할 수 있음을 보여줍니다. |
자동 압축 기능을 계속 활성화하세요. 삭제 벡터가 누적되는데도 소형 파일 컴팩션이 발생하지 않으면 OPTIMIZE 예약하세요. 명시적인 정화 요구사항에만 사용 REORG TABLE ... APPLY (PURGE) 하세요. |
아무 행동도 필요 없습니다. 정리는 시스템이 관리하는 작업입니다. |
| 파일 건너뛰기 불량 | 선택도가 높은 조건자는 테이블의 상당 부분을 스캔하거나, 클러스터링 품질 평가에서 구성이 좋지 않음을 보여줍니다. | Spark에서는 액체 클러스터링 을 구성하거나 기존 분할 테이블에 대해 Z-Order 를 사용할 수 있습니다. | Warehouse 데이터 클러스터링을 구성하세요. |
| Direct Lake 트랜스코딩 오버헤드 | Delta Analyzer는 업데이트 후 과도한 파일, 작은 행 그룹, 또는 광범위한 재전송을 보여줍니다. | 작은 파일을 압축하고, 행 그룹을 검토하며, Spark가 작성한 테이블에 V-Order 를 적용하세요. 선택적으로 Parquet 파일 내에서 압축 품질을 향상시키기 위해 액체 클러스터링 을 구성할 수 있습니다. | V-Order를 활성화하고 데이터 클러스터링을 평가하세요. |
| 참조되지 않은 파일 저장 공간 확장 | OneLake 저장소는 데이터 변경 작업 후 활성 테이블 크기보다 빠르게 성장합니다. | 유지 요건에 맞춰 운영하세요 VACUUM . |
아무 행동도 필요 없습니다. 정리는 시스템이 관리하는 작업입니다. |
미러 데이터의 경우, Optimize mirrored data 내 생산자별 복원 절차를 따르세요. 데이터베이스 미러링은 시스템 관리이며; 미러드 카탈로그의 경우, 소스 플랫폼에서 지원 유지보수를 적용하세요.
레이크하우스 테이블의 경우, Spark에서 지원하는 검사 옵션은 다음과 같습니다:
- 파일 수, 총 크기, 평가된
delta.targetFileSize.adaptive속성을 검사하기 위해 실행하세요DESCRIBE DETAIL. - 쓰기 패턴과 유지 관리 기록을 검토하려면
DESCRIBE HISTORY을 실행하세요. - 상세한 Direct Lake 행 그룹과 업데이트 패턴 분석이 필요할 때는 Delta Analyzer 를 사용하세요.
평균 파일 크기 검사
테이블 레이아웃의 초기 지표로 평균 파일 크기를 계산하는 데 사용 DESCRIBE DETAIL 하세요:
details = spark.sql("DESCRIBE DETAIL schema_name.table_name").first()
table_size_gb = details["sizeInBytes"] / (1024**3)
num_files = details["numFiles"]
avg_file_size_mb = (
details["sizeInBytes"] / num_files / (1024**2)
if num_files
else 0
)
print(f"Table size: {table_size_gb:.2f} GB")
print(f"Number of files: {num_files}")
print(f"Average file size: {avg_file_size_mb:.2f} MB")
평균은 파티션이나 최근과 이전에 압축된 파일 간의 스큐를 숨길 수 있습니다. 평균이 레이아웃 문제를 시사한다면, 개별 파켓 파일을 확인하거나 Delta Analyzer 를 사용해 분포를 평가한 후 유지보수 설정을 변경하세요.
언제 다른 테이블을 만드려야 할까요
여러 Fabric 엔진이 데이터를 소비한다고 해서 또 다른 물리적 테이블을 만들지 마세요.
독립적인 목적이 있을 때 다음과 같은 다른 테이블을 만드세요:
- 데이터의 흐름이나 비즈니스 의미를 바꾸는 변환이나 집계.
- 보안, 보존, 데이터 품질 요구 사항이 다릅니다.
- 공유 테이블이 충족할 수 없는 지연 시간 또는 새로 고침 요구 사항입니다.
- 소비자 전용 레이아웃으로, 그 측정된 이점이 저장, 처리, 혈통, 거버넌스 비용을 상회합니다.