적용 대상: ✅ Microsoft Fabric의 웨어하우스
Microsoft Fabric 파이프라인은 Dev → Test → Production과 같은 작업 공간 전반에 걸쳐 창고 스키마를 효율적으로 변경할 수 있는 방법을 제공합니다. 파이프라인은 내장된 의존성 처리, 스키마 검증, 선언적 배포 인텔리전스를 갖추고 있습니다.
Important
이 기능은 프리뷰 상태입니다.
이 글에서는 파이프라인을 이용한 창고 배치 과정을 설명합니다.
배포 파이프라인은 스토리지 변경 사항을 작업 공간 간에 안전하게 이동시키는 데 필요한 수명주기 구조를 제공합니다. 이들은 스키마 프로모션의 중앙 오케스트레이션 계층 역할을 하여, 팀이 애드혹 배포에 의존하지 않고 변화가 분석 플랫폼을 통해 어떻게 흐르는지 표준화할 수 있게 합니다. 파이프라인이 생성되면 창고 비교, 변경 사항 검토, 배포 실행을 위한 주요 인터페이스가 됩니다.
파이프라인 만들기
새로운 파이프라인을 생성하려면 배포 파이프라인을 생성하고 관리하는 '배포 파이프라인 시작 하기'를 참조하세요.
Compare
배포 전에 항상 T-SQL 변경 사항을 확인하고 비교하세요. 배포 파이프라인은 Fabric 포털에서 영향을 받는 웨어하우스 객체를 검토할 수 있는 간편한 비교 화면을 제공합니다.
변경 사항을 검토하면 팀이 하위 환경에 업데이트를 촉진하기 전에 준비 상태를 검증할 수 있습니다. 이 과정은 여러 팀이 창고 개발에 참여하는 기업 시나리오에서 특히 유용합니다.
Fabric은 이 비교를 위해 DacFx(데이터 계층 애플리케이션 프레임워크)를 사용합니다. DacFx는 두 환경의 선언적 스키마 모델을 구축하며, 새로운 테이블, 수정된 열, 제약 조건, 의존성 변경 등 차이점을 식별합니다. 이 비교는 모델 기반이기 때문에 배포 과정에서 실제로 일어나는 일을 정확히 반영합니다.
Important
스키마 비교가 작동하려면 웨어하우스가 소스와 대상 작업 공간 모두에 존재해야 합니다. 대상 작업 공간에 아직 웨어하우스가 포함되어 있지 않다면, 먼저 초기 기준 버전을 생성하거나 배포하세요.
메모
만약 어떤 열의 절이 COLLATE 창고의 기본 콜레이션과 동일한 콜레이션을 명시적으로 지정한다면, 비교 시 차이로 표시되지 않습니다. 왜냐하면 이는 콜레이션을 아예 지정하지 않는 것과 같기 때문입니다. 창고의 기본 정렬과 다른 열만 정렬이 변경될 때 비교에 나타납니다. 자세한 정보와 예시는 Fabric Data Warehouse 개발을 위한 Git 통합 문제 해결을 참조하세요.
변경 사항을 배포하기 전에 배포 파이프라인의 비교 기능을 사용하여 소스와 대상 창고 작업 공간 간의 차이를 검토하세요.
비교를 선택하고 창고에서 새 뷰를 생성하는 변경 사항을 확인하세요:
Deploy
비교가 끝나고 변경 사항을 검증한 후, 파이프라인 인터페이스에서 홍보할 창고 항목을 선택하여 직접 배포할 수 있습니다.
배포 과정에서 배포 파이프라인은 DacFx를 사용하여 스키마 차이를 기반으로 지능형 배포 계획을 생성합니다. Fabric은 대상 작업 공간이 소스와 동기화되도록 필요한 변경만 적용합니다.
배포 구성
Fabric 배포 파이프라인은 Fabric Data Warehouse에 맞게 맞춤 설정된 DacFx 배포 기술을 사용합니다. 이러한 구성은 Fabric 플랫폼의 역량과 운영 관행에 부합하면서 배포가 신뢰성 있게 성공하도록 보장합니다.
데이터 손실 차단(
BlockOnPossibleDataLoss = true) - Fabric Data Warehouse 사용자 데이터를 잘라내거나 드랍하거나 손실할 수 있는 배포를 방지합니다. 이 설정은 고위험 스키마 변경이 CI/CD를 통과하지 못하게 하며, 데이터 손실 위험이 조용한 기본값이 아닌 의도적인 결정이 되도록 만듭니다.데이터베이스 수준의 옵션 스크립팅 건너뛰기 (
ScriptDatabaseOptions = false) - Fabric은 플랫폼 수준에서 많은 데이터베이스 수준의 설정을 관리합니다. 배포 중과 같은ALTER DATABASE ... SET스크립팅 문은 실패나 의도치 않은 구성 드리프트를 초래할 수 있습니다. 따라서 배포 파이프라인은 이러한 설정을 전파하지 않고, 스키마 배포가 지원되는 웨어하우스 객체에만 집중하도록 보장합니다.복제된 객체에 대한 엔진 강제 허용 (
DoNotAlterReplicatedObjects = false) - 웨어하우스는 링크나 동기화 시나리오 등 내부 복제 메커니즘을 자주 사용합니다. 스키마 변경을 조기에 차단하는 대신, 배포 파이프라인은 Fabric 엔진이 변경 허용 여부를 판단할 수 있게 합니다. 이 접근법은 불필요한 배포 실패를 방지하면서도 플랫폼 안전장치를 유지할 수 있습니다.트랜잭션 DDL 스크립팅 비활성화 (
IncludeTransactionalScripts = false) - 현재 웨어하우스는 트랜잭션 내에서 DDL 스크립트를 래핑하는 것을 지원하지 않습니다. 따라서 배포 파이프라인은 배포가 성공적으로 완료되도록 비트랜잭션 스크립트를 생성합니다.스키마 진화를 위한 지능형 기본값 사용 (
GenerateSmartDefaults = true) - 스키마 변경이 더 엄격한 제약 조건을 도입할 때, 예를 들어 nullable 열을 비nullable으로 변환하거나 기본 제약 조건을 가진 새로운 열을 추가하는 경우, 배포 파이프라인은 자동으로 기준선 값을 채울 수 있습니다. 이 접근법은 배포가 수작업 데이터 준비 없이 성공할 수 있도록 돕고, 스키마 진화 과정에서 운영 마찰을 줄여줍니다.배포에서 보안 주체를 제외하기(
ExcludeObjectTypes = Logins, Users, Permissions) - 보안 객체는 웨어하우스 배포에서 의도적으로 제외됩니다. 로그인, 사용자 또는 권한을 환경 간에 홍보하는 것은 보안 위험이나 환경별 충돌을 초래할 수 있습니다. 대신 환경 거버넌스 또는 신원 관리 프로세스를 통해 접근 제어를 별도로 관리하세요.소스에 없는 객체를 드롭하지 않음 (
DropObjectsNotInSource = false) - 타겟에 존재하지만 소스에 없는 객체는 자동으로 드롭되지 않습니다. 생산 과정을 소스 관리와 완벽하게 동기화하는 창고는 이 점이 제한적일 수 있습니다.
제한점
- 기본적으로 시스템은 테이블 드롭을 차단합니다. 배포 과정이 대상에는 존재하지만 소스에는 없는 객체를 자동으로 삭제하지 않습니다. 이 설계는 우발적인 데이터 손실을 줄이고 생산 중 예상치 못한 삭제를 방지합니다.
- 성공적인 배포가 항상 모든 요청된 변경 사항이 적용되었다는 뜻은 아닙니다. 배포는 요청된 드롭 테이블 작업을 건너뛰더라도 성공을 보고할 수 있는데, 이는 기본적으로 테이블 드롭이 차단되기 때문입니다. 이 경우 배포 작업은 완료되지만, 누락된 변경 사항을 명시적으로 해결할 때까지 대상이 소스 컨트롤에서 벗어날 수 있습니다.
- Fabric 배포 파이프라인은 SQL 분석 엔드포인트 항목을 지원하지 않습니다. 현재 배포 과정은 대상 내에 존재하는 객체를 버리지 않음으로써 엄격한 소스 패리티보다 안전을 우선시합니다.
- SQL 분석 엔드포인트와 웨어하우스 간의 항목 간 종속성, 항목 시퀀싱 및 동기화 간격은 패브릭 배포 파이프라인 워크플로에 영향을 줍니다.
- Fabric Deployment 파이프라인을 사용하면 한 번에 한 개의 창고만 배포할 수 있습니다. 배포 관련 항목 선택은 지원되지 않습니다.
Git 통합 문제 해결
Git 통합에 관한 제한 사항은 Git 통합 문서의 'Git 통합 제한' 을 참조하세요.
Fabric Data Warehouse 개발에서 흔히 발생하는 Git 통합 문제 해결, 해결책, 해결책은 'Fabric Data Warehouse 개발을 위한 Git 통합 문제 해결'을 참조하세요.