마이그레이션: Azure Synapse Analytics 전용 SQL 풀을 Fabric으로
적용 대상:✅ Microsoft Fabric 내 웨어하우스
이 문서에서는 Azure Synapse Analytics 전용 SQL 풀에서 Microsoft Fabric 웨어하우스로 데이터 웨어하우징을 마이그레이션하는 전략, 고려 사항 및 방법을 자세히 설명합니다.
마이그레이션 소개
Microsoft는 Data Factory, 데이터 엔지니어링, 데이터 웨어하우징, 데이터 과학, 실시간 인텔리전스 및 Power BI를 비롯한 포괄적인 서비스 제품군을 제공하는 엔터프라이즈를 위한 일체형 SaaS 분석 솔루션인 Microsoft Fabric을 도입했습니다.
이 문서에서는 DDL(스키마) 마이그레이션, DML(데이터베이스 코드) 마이그레이션 및 데이터 마이그레이션 옵션에 중점을 둡니다. Microsoft는 몇 가지 옵션을 제공하며 여기서는 각 옵션에 대해 자세히 설명하고 시나리오에 대해 고려해야 하는 이러한 옵션에 대한 지침을 제공합니다. 이 문서에서는 일러스트레이션 및 성능 테스트를 위해 TPC-DS 업계 벤치마크를 사용합니다. 실제 결과는 데이터 형식, 데이터 유형, 테이블 너비, 데이터 원본 대기 시간 등을 비롯한 여러 요인에 따라 달라질 수 있습니다.
마이그레이션 준비
시작하기 전에 마이그레이션 프로젝트를 신중하게 계획하고 스키마, 코드 및 데이터가 Fabric 웨어하우스와 호환되는지 확인합니다. 고려해야 할 몇 가지 제한 사항이 있습니다. 마이그레이션 제공 전에 필요한 다른 리소스뿐만 아니라 호환되지 않는 항목의 리팩터링 작업을 정량화합니다.
계획의 또 다른 주요 목표는 솔루션이 Fabric 웨어하우스가 제공하도록 설계된 높은 쿼리 성능을 최대한 활용할 수 있도록 디자인을 조정하는 것입니다. 확장을 위한 Data Warehouse의 디자인은 고유한 디자인 패턴을 도입하므로 일반적인 접근 방식이 항상 최선은 아닙니다. 마이그레이션 후에 일부 디자인을 조정할 수 있지만 프로세스의 앞부분에서 변경하면 시간과 노력이 절약되므로 Fabric 웨어하우스 성능 지침을 검토합니다. 한 기술/환경에서 다른 기술/환경으로 마이그레이션하는 것은 항상 중요한 작업입니다.
다음 다이어그램에서는 원활한 마이그레이션을 계획하고 준비하기 위해 각 핵심 요소의 관련 작업과 함께 분석 및 평가, 계획 및 디자인, 마이그레이션, 모니터링 및 관리, 최적화 및 현대화 핵심 요소로 구성된 주요 핵심 요소를 나열하는 마이그레이션 수명 주기를 보여 줍니다.
마이그레이션용 Runbook
Synapse 전용 SQL 풀에서 Fabric 웨어하우스로 마이그레이션하기 위한 계획 Runbook으로 다음 작업을 고려합니다.
- 분석 및 평가
- 목표와 동기를 식별합니다. 원하는 명확한 결과를 설정합니다.
- 기존 아키텍처를 검색, 평가 및 기준으로 합니다.
- 주요 이해 관계자 및 스폰서를 식별합니다.
- 마이그레이션할 항목의 범위를 정의합니다.
- 작고 간단하게 시작하여 여러 소규모 마이그레이션을 준비합니다.
- 프로세스의 모든 단계를 모니터링하고 문서화합니다.
- 마이그레이션을 위한 데이터 및 프로세스 인벤토리를 빌드합니다.
- 데이터 모델 변경 내용을 정의합니다(있는 경우).
- Fabric 작업 영역을 설정합니다.
- 기술 세트/기본 설정이란?
- 가능한 모든 곳에서 자동화합니다.
- Azure 기본 제공 도구 및 기능을 사용하여 마이그레이션 작업을 줄입니다.
- 새 플랫폼에서 초기에 담당자를 학습합니다.
- Microsoft Learn을 포함하여 업스킬링 요구 사항 및 학습 자산을 식별합니다.
- 계획 및 디자인
- 원하는 아키텍처를 정의합니다.
- 마이그레이션에 대한 방법/도구를 선택하여 다음 작업을 수행합니다.
- 원본에서 데이터를 추출합니다.
- 테이블 및 뷰보기에 대한 메타데이터를 포함하여 DDL(스키마) 변환
- 기록 데이터를 포함하여 데이터를 수집합니다.
- 필요한 경우 새로운 플랫폼 성능과 확장성을 통해 데이터 모델을 다시 설계합니다.
- DML(데이터베이스 코드) 마이그레이션
- 저장 프로시저 및 업무 프로세스를 마이그레이션하거나 리팩터링합니다.
- 원본에서 보안 기능 및 개체 권한을 인벤토리화하고 추출합니다.
- 증분 로드를 위해 기존 ETL/ELT 프로세스를 대체/수정하도록 설계 및 계획합니다.
- 새 환경에 대한 병렬 ETL/ELT 프로세스를 만듭니다.
- 자세한 마이그레이션 계획을 준비합니다.
- 현재 상태를 원하는 새 상태로 매핑합니다.
- 마이그레이션
- 스키마, 데이터, 코드 마이그레이션을 수행합니다.
- 원본에서 데이터를 추출합니다.
- DDL(스키마) 변환
- 데이터 수집
- DML(데이터베이스 코드) 마이그레이션
- 필요한 경우 마이그레이션 속도를 지원하기 위해 전용 SQL 풀 리소스를 일시적으로 확장합니다.
- 보안 및 권한을 적용합니다.
- 증분 로드를 위해 기존의 ETL/ELT 프로세스를 마이그레이션합니다.
- ETL/ELT 증분 로드 프로세스를 마이그레이션하거나 리팩터링합니다.
- 병렬 증분 로드 프로세스를 테스트하고 비교합니다.
- 필요에 따라 세부 마이그레이션 계획을 조정합니다.
- 스키마, 데이터, 코드 마이그레이션을 수행합니다.
- 모니터링 및 제어
- 병렬로 실행하여 원본 환경과 비교합니다.
- 애플리케이션, 비즈니스 인텔리전스 플랫폼 및 쿼리 도구를 테스트합니다.
- 쿼리 성능을 벤치마킹하고 최적화합니다.
- 비용, 보안 및 성능을 모니터링하고 관리합니다.
- 거버넌스 벤치마크 평가
- 병렬로 실행하여 원본 환경과 비교합니다.
- 최적화 및 현대화
- 비즈니스가 안정되면 애플리케이션 및 기본 보고 플랫폼을 Fabric으로 전환합니다.
- 워크로드가 Azure Synapse Analytics에서 Microsoft Fabric으로 이동함에 따라 리소스를 확장/축소합니다.
- 향후 마이그레이션을 위해 얻은 경험을 바탕으로 반복 가능한 템플릿을 구축합니다. 반복.
- 비용 최적화, 보안, 확장성 및 최적의 작동에 대한 기회 식별
- 최신 Fabric 기능을 사용하여 데이터 자산을 현대화할 기회를 식별합니다.
- 비즈니스가 안정되면 애플리케이션 및 기본 보고 플랫폼을 Fabric으로 전환합니다.
‘리프트 앤 시프트’ 또는 현대화 여부
일반적으로 계획된 마이그레이션의 목적과 범위에 관계없이 두 가지 형식의 마이그레이션 시나리오가 있습니다. 즉, 있는 그대로의 리프트 앤 시프트와 아키텍처 및 변경 내용을 통합하는 단계적 접근 방식입니다.
리프트 앤 시프트
리프트 앤 시프트 마이그레이션에서 기존 데이터 모델은 새 Fabric 웨어하우스를 약간 변경하여 마이그레이션됩니다. 이 방법은 마이그레이션의 이점을 실현하는 데 필요한 새 작업을 줄여 위험과 마이그레이션 시간을 최소화합니다.
리프트 앤 시프트 마이그레이션은 다음 시나리오에 적합합니다.
- 마이그레이션할 소수의 데이터 마트가 있는 기존 Oracle 환경이 있습니다.
- 이미 잘 설계된 별 모양 또는 눈송이 스키마에 있는 데이터가 있는 기존 환경이 있습니다.
- Fabric 웨어하우스로 이동하는 데 시간과 비용 부담이 있습니다.
요약하자면, 이 접근 방식은 현재 Synapse 전용 SQL 풀 환경으로 최적화된 워크로드에 적합하므로 Fabric에서 크게 변경할 필요가 없습니다.
아키텍처를 변경하여 단계적 접근 방식으로 현대화
레거시 Data Warehouse가 오랜 기간 동안 발전한 경우 필요한 성능 수준을 유지하기 위해 이를 다시 설계해야 할 수 있습니다.
Fabric 작업 영역에서 사용할 수 있는 새로운 엔진과 기능을 활용하도록 아키텍처를 다시 디자인할 수도 있습니다.
디자인 차이점: Synapse 전용 SQL 풀 및 Fabric 웨어하우스
전용 SQL 풀을 Fabric 웨어하우스와 비교하여 다음과 같은 Azure Synapse 및 Microsoft Fabric 데이터 웨어하우징의 차이점을 고려합니다.
테이블 고려 사항
서로 다른 환경 간에 테이블을 마이그레이션할 때 일반적으로 원시 데이터와 메타데이터만 실제로 마이그레이션됩니다. 인덱스와 같은 원본 시스템의 다른 데이터베이스 요소는 일반적으로 새 환경에서 불필요하거나 다르게 구현될 수 있으므로 마이그레이션되지 않습니다.
인덱스와 같은 원본 환경의 성능 최적화는 새 환경에서 성능 최적화를 추가할 수 있는 위치를 나타내지만 이제 Fabric에서 자동으로 처리합니다.
T-SQL 고려 사항
알아야 할 몇 가지 DML(데이터 조작 언어) 구문 차이점이 있습니다. Microsoft Fabric의 T-SQL 노출 영역을 참조하세요. DML(데이터베이스 코드)에 대한 마이그레이션 방법을 선택할 때 코드 평가도 고려합니다.
마이그레이션 시 Parity 차이에 따라 T-SQL DML 코드의 일부를 다시 작성해야 할 수 있습니다.
데이터 형식 매핑 차이점
Fabric 웨어하우스에는 몇 가지 데이터 형식 차이점이 있습니다. 자세한 내용은 Microsoft Fabric의 데이터 형식을 참조하세요.
다음 테이블에서는 Synapse 전용 SQL 풀에서 Fabric 웨어하우스로 지원되는 데이터 형식의 매핑을 제공합니다.
| Synapse 전용 SQL 풀 | Fabric 웨어하우스 |
|---|---|
| money | DECIMAL(19,4) |
| smallmoney | DECIMAL(10,4) |
| smalldatetime | datetime2 |
| datetime | datetime2 |
| nchar | char |
| nvarchar | varchar |
| tinyint | smallint |
| binary | varbinary |
| datetimeoffset* | datetime2 |
* Datetime2는 저장된 추가 표준 시간대 오프셋 정보를 저장하지 않습니다. datetimeoffset 데이터 형식은 현재 Fabric 웨어하우스에서 지원되지 않으므로 표준 시간대 오프셋 데이터를 별도의 열로 추출해야 합니다.
스키마, 코드 및 데이터 마이그레이션 방법
이러한 옵션 중 시나리오, 직원 기능 및 데이터의 특성에 맞는 옵션을 검토하고 식별합니다. 선택한 옵션은 환경, 기본 설정 및 각 도구의 이점에 따라 달라집니다. 우리의 목표는 마이그레이션 환경을 원활하게 만들기 위해 마찰과 수동 개입을 완화하는 마이그레이션 도구를 계속 개발하는 것입니다.
이 테이블에는 DDL(데이터 스키마), DML(데이터베이스 코드) 및 데이터 마이그레이션 방법에 대한 정보가 요약되어 있습니다. 옵션 열에 연결된 이 문서의 뒷부분에 있는 각 시나리오에 대해 자세히 살펴보겠습니다.
| 옵션 번호 | 옵션 | 수행하는 작업 | 기술/기본 설정 | 시나리오 |
|---|---|---|---|---|
| 1 | Data Factory | DDL(스키마) 변환 데이터 추출 데이터 수집 |
ADF/파이프라인 | 하나의 DDL(스키마) 및 데이터 마이그레이션에서 모두 간소화되었습니다. 차원 테이블에 권장됩니다. |
| 2 | 파티션이 있는 Data Factory | DDL(스키마) 변환 데이터 추출 데이터 수집 |
ADF/파이프라인 | 분할 옵션을 사용하여 팩트 테이블에 권장되는 10배 처리량과 옵션 1을 제공하는 읽기/쓰기 병렬 처리를 높입니다. |
| 3 | 가속 코드가 있는 Data Factory | DDL(스키마) 변환 | ADF/파이프라인 | 먼저 DDL(스키마)을 변환하고 마이그레이션한 다음 CETAS를 사용하여 데이터를 추출하고 COPY/Data Factory를 사용하여 최적의 전체 수집 성능을 위해 데이터를 수집합니다. |
| 4 | 저장 프로시저 가속 코드 | DDL(스키마) 변환 데이터 추출 코드 평가 |
T-SQL | 작업하려는 작업을 보다 세부적으로 제어하는 IDE를 사용하는 SQL 사용자. COPY/Data Factory를 사용하여 데이터를 수집합니다. |
| 5 | Azure Data Studio용 SQL Database 프로젝트 확장 | DDL(스키마) 변환 데이터 추출 코드 평가 |
SQL 프로젝트 | 옵션 4의 통합을 사용하여 배포할 SQL Database 프로젝트. COPY 또는 Data Factory를 사용하여 데이터를 수집합니다. |
| 6 | CETAS(CREATE EXTERNAL TABLE AS SELECT) | 데이터 추출 | T-SQL | 비용 효율적인 고성능 데이터를 ADLS(Azure Data Lake Storage) Gen2로 추출합니다. COPY/Data Factory를 사용하여 데이터를 수집합니다. |
| 7 | dbt를 사용하여 마이그레이션 | DDL(스키마) 변환 DML(데이터베이스 코드) 변환 |
dbt | 기존 dbt 사용자는 dbt Fabric 어댑터를 사용하여 DDL 및 DML을 변환할 수 있습니다. 그런 다음 이 테이블의 다른 옵션을 사용하여 데이터를 마이그레이션해야 합니다. |
초기 마이그레이션을 위한 워크로드 선택
Synapse 전용 SQL 풀에서 Fabric 웨어하우스 마이그레이션 프로젝트로 시작할 위치를 결정할 때 다음을 수행할 수 있는 워크로드 영역을 선택합니다.
- 새로운 환경의 이점을 신속하게 제공하여 Fabric 웨어하우스로의 마이그레이션 가능성을 입증합니다. 작고 간단하게 시작하여 여러 소규모 마이그레이션을 준비합니다.
- 사내 기술 담당자가 다른 영역을 마이그레이션할 때 사용할 프로세스 및 도구에 대한 관련 환경을 얻을 수 있습니다.
- 원본 Synapse 환경과 현재 도구 및 프로세스와 관련된 추가 마이그레이션을 위한 템플릿을 만듭니다.
팁
마이그레이션해야 하는 개체의 인벤토리를 만들고 마이그레이션 프로세스를 처음부터 끝까지 문서화하여 다른 전용 SQL 풀 또는 워크로드에 대해 반복할 수 있도록 합니다.
초기 마이그레이션에서 마이그레이션된 데이터의 양은 Fabric 웨어하우스 환경의 기능과 이점을 보여 주기에 충분히 커야 하지만 가치를 빠르게 보여 주기에는 너무 크지 않아야 합니다. 1-10TB 범위의 크기가 일반적입니다.
Fabric Data Factory를 사용하여 마이그레이션
이 섹션에서는 Azure Data Factory 및 Synapse Pipeline에 익숙한 로우코드/노코드 가상 사용자를 위해 Data Factory를 사용하는 옵션에 대해 설명합니다. 이 끌어서 놓기 UI 옵션은 DDL을 변환하고 데이터를 마이그레이션하는 간단한 단계를 제공합니다.
Fabric Data Factory는 다음 작업을 수행할 수 있습니다.
- DDL(스키마)을 Fabric 웨어하우스 구문으로 변환합니다.
- Fabric 웨어하우스에서 DDL(스키마)을 만듭니다.
- Fabric 웨어하우스로 데이터를 마이그레이션합니다.
옵션 1. 스키마/데이터 마이그레이션 - 복사 마법사 및 ForEach 복사 작업
이 메서드는 Data Factory Copy 도우미를 사용하여 원본 전용 SQL 풀에 연결하고, 전용 SQL 풀 DDL 구문을 Fabric으로 변환하고, 데이터를 Fabric 웨어하우스에 복사합니다. 1개 이상의 대상 테이블을 선택할 수 있습니다(TPC-DS 데이터 세트의 경우 22개의 테이블이 있음). ForEach를 생성하여 UI에서 선택한 테이블 목록을 반복하고 22개의 병렬 복사 작업 스레드를 생성합니다.
- 22개의 SELECT 쿼리(선택한 각 테이블에 대해 하나)가 생성되어 전용 SQL 풀에서 실행되었습니다.
- 생성된 쿼리를 실행할 수 있도록 적절한 DWU 및 리소스 클래스가 있는지 확인합니다. 이 경우 최대 32개의 쿼리가 제출된 22개의 쿼리를 처리할 수 있도록 최소 DWU1000의
staticrc10이 필요합니다. - 전용 SQL 풀에서 Fabric 웨어하우스로 데이터를 직접 복사하려면 Data Factory에서 스테이징이 필요합니다. 수집 프로세스는 두 단계로 구성됩니다.
- 첫 번째 단계는 전용 SQL 풀에서 ADLS로 데이터를 추출하는 작업으로 구성되며 스테이징이라고 합니다.
- 두 번째 단계는 스테이징에서 Fabric 웨어하우스로 데이터를 수집하는 작업으로 구성됩니다. 대부분의 데이터 수집 타이밍은 스테이징 단계에 있습니다. 요약하면 스테이징은 수집 성능에 큰 영향을 미칩니다.
권장 사용
복사 마법사를 사용하여 ForEach를 생성하면 DDL을 변환하고 선택한 테이블을 전용 SQL 풀에서 Fabric 웨어하우스로 한 단계로 수집하는 간단한 UI가 제공됩니다.
그러나 전체 처리량 측면에서는 최적이 아닙니다. 스테이징을 사용해야 하는 요구 사항, "소스-스테이지" 단계에 대한 읽기 및 쓰기를 병렬화해야 하는 요구 사항은 성능 대기 시간의 주요 요소입니다. 이 옵션은 차원 테이블에만 사용하는 것이 좋습니다.
옵션 2. DDL/데이터 마이그레이션 - 파티션 옵션을 사용하는 데이터 파이프라인
Fabric 데이터 파이프라인을 사용하여 더 큰 팩트 테이블을 로드하는 처리량 향상을 해결하려면 파티션 옵션이 있는 각 팩트 테이블에 복사 작업을 사용하는 것이 좋습니다. 그러면 복사 작업에 최상의 성능을 제공합니다.
사용 가능한 경우 원본 테이블 실제 분할을 사용할 수 있습니다. 테이블에 실제 분할이 없는 경우 파티션 열을 지정하고 동적 분할을 사용하려면 최소/최대값을 제공해야 합니다. 다음 스크린샷에서 데이터 파이프라인 원본 옵션은 ws_sold_date_sk 열을 기반으로 파티션의 동적 범위를 지정합니다.
파티션을 사용하면 스테이징 단계에서 처리량을 늘릴 수 있지만 적절한 조정을 위해 고려해야 할 사항이 있습니다.
- 파티션 범위에 따라 전용 SQL 풀에서 128개가 넘는 쿼리를 생성할 수 있으므로 잠재적으로 모든 동시성 슬롯을 사용할 수 있습니다.
- 모든 쿼리를 실행할 수 있도록 최소 DWU6000으로 확장해야 합니다.
- 예를 들어 TPC-DS
web_sales테이블의 경우 163개의 쿼리가 전용 SQL 풀에 제출되었습니다. DWU6000에서 35개의 쿼리가 큐에 대기하는 동안 128개의 쿼리가 실행되었습니다. - 동적 파티션은 범위 파티션을 자동으로 선택합니다. 이 경우 전용 SQL 풀에 제출된 각 SELECT 쿼리에 대한 11일 범위입니다. 예:
WHERE [ws_sold_date_sk] > '2451069' AND [ws_sold_date_sk] <= '2451080') ... WHERE [ws_sold_date_sk] > '2451333' AND [ws_sold_date_sk] <= '2451344')
권장 사용
팩트 테이블의 경우 처리량을 늘리기 위해 분할 옵션과 함께 Data Factory를 사용하는 것이 좋습니다.
그러나 병렬 처리된 읽기가 증가하려면 추출 쿼리를 실행할 수 있도록 전용 SQL 풀을 더 높은 DWU로 확장해야 합니다. 분할을 활용하여 파티션 옵션 없이 속도가 10배 향상됩니다. 컴퓨팅 리소스를 통해 추가 처리량을 얻기 위해 DWU를 늘릴 수 있지만 전용 SQL 풀에는 최대 128개의 활성 쿼리가 허용됩니다.
참고 항목
Synapse DWU에서 Fabric 매핑에 대한 자세한 내용은 블로그: Azure Synapse 전용 SQL 풀을 Fabric Data Warehouse 컴퓨팅에 매핑을 참조하세요.
옵션 3. DDL 마이그레이션 - 복사 마법사 ForEach 복사 작업
이전의 두 가지 옵션은 소규모 데이터베이스에 대한 우수한 데이터 마이그레이션 옵션입니다. 그러나 더 높은 처리량이 필요한 경우 대체 옵션을 사용하는 것이 좋습니다.
- 전용 SQL 풀에서 ADLS로 데이터를 추출하여 단계 성능 오버헤드를 완화합니다.
- Data Factory 또는 COPY 명령을 사용하여 Fabric 웨어하우스로 데이터를 수집합니다.
권장 사용
Data Factory를 계속 사용하여 DDL(스키마)을 변환할 수 있습니다. 복사 마법사를 사용하여 특정 테이블 또는 모든 테이블을 선택할 수 있습니다. 기본적으로 쿼리 문에서 잘못된 조건 TOP 0을 사용하여 행 없이 스키마를 추출해 스키마와 데이터를 한 단계로 마이그레이션합니다.
다음 코드 샘플에서는 Data Factory를 사용한 DDL(스키마) 마이그레이션에 대해 설명합니다.
코드 예제: Data Factory를 사용하여 DDL(스키마) 마이그레이션
Fabric 데이터 파이프라인을 사용하여 원본 Azure SQL 데이터베이스 또는 전용 SQL 풀의 테이블 개체에 대한 DDL(스키마)을 통해 쉽게 마이그레이션할 수 있습니다. 이 데이터 파이프라인은 원본 전용 SQL 풀 테이블의 DDL(스키마)을 통해 Fabric 웨어하우스로 마이그레이션합니다.
파이프라인 디자인: 매개 변수
이 데이터 파이프라인은 마이그레이션할 스키마를 지정할 수 있는 SchemaName 매개 변수를 허용합니다. dbo 스키마가 기본값입니다.
기본값 필드에 마이그레이션 할 스키마를 나타내는 쉼표로 구분된 테이블 스키마 목록을 입력합니다. 'dbo','tpch'에서는 dbo 및 tpch의 두 스키마를 제공합니다.
파이프라인 디자인: 조회 작업
조회 작업을 만들고 원본 데이터베이스를 가리키도록 연결을 설정합니다.
설정 탭에서 다음을 수행합니다.
데이터 저장소 유형을 외부로 설정합니다.
연결은 해당 Azure Synapse 전용 SQL 풀입니다. 연결 유형은 Azure Synapse Analytics입니다.
쿼리 사용은 쿼리로 설정됩니다.
쿼리 필드는 동적 식을 사용하여 작성해야 하므로 대상 원본 테이블 목록을 반환하는 쿼리에서 SchemaName 매개 변수를 사용할 수 있습니다. 쿼리를 선택한 다음, 동적 콘텐츠 추가를 선택합니다.
조회 작업 내의 이 식은 시스템 보기를 쿼리하여 스키마 및 테이블 목록을 검색하는 SQL 문을 생성합니다. SQL 스키마에서 필터링할 수 있도록 SchemaName 매개 변수를 참조합니다. 이 출력은 ForEach 작업에 대한 입력으로 사용될 SQL 스키마 및 테이블의 배열입니다.
다음 코드를 사용하여 스키마 이름이 있는 모든 사용자 테이블 목록을 반환합니다.
@concat(' SELECT s.name AS SchemaName, t.name AS TableName FROM sys.tables AS t INNER JOIN sys.schemas AS s ON t.type = ''U'' AND s.schema_id = t.schema_id AND s.name in (',coalesce(pipeline().parameters.SchemaName, 'dbo'),') ')
파이프라인 디자인: ForEach 루프
ForEach 루프의 경우 설정 탭에서 다음 옵션을 구성합니다.
- 여러 반복이 동시에 실행되도록 하려면 순차를 사용하지 않도록 설정합니다.
- 일괄 처리 수를
50으로 설정하여 최대 동시 반복 횟수를 제한합니다. - 항목 필드는 동적 콘텐츠를 사용하여 조회 작업의 출력을 참조해야 합니다.
@activity('Get List of Source Objects').output.value코드 조각을 사용합니다.
파이프라인 디자인: ForEach Loop 내의 복사 작업
ForEach 작업 내에 복사 작업을 추가합니다. 이 메서드는 데이터 파이프라인 내의 동적 식 언어를 사용하여 데이터가 없는 스키마만 Fabric 웨어하우스로 마이그레이션하도록 SELECT TOP 0 * FROM <TABLE>을 빌드합니다.
원본 탭에서:
- 데이터 저장소 유형을 외부로 설정합니다.
- 연결은 해당 Azure Synapse 전용 SQL 풀입니다. 연결 유형은 Azure Synapse Analytics입니다.
- 쿼리 사용을 쿼리로 설정합니다.
- 쿼리 필드에서 동적 콘텐츠 쿼리에 붙여넣고 테이블 스키마
@concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)만 0행을 반환하는 이 식을 사용합니다.
대상에서 다음을 수행합니다.
- 데이터 저장소 유형을 작업 영역으로 설정합니다.
- 작업 영역 데이터 저장소 유형은 Data Warehouse이며 Data Warehouse는 Fabric 웨어하우스로 설정됩니다.
- 대상 테이블의 스키마 및 테이블 이름은 동적 콘텐츠를 사용하여 정의됩니다.
- 스키마는 현재 반복의 필드인
@item().SchemaName코드 조각이 있는 SchemaName을 참조합니다. - 테이블이
@item().TableName코드 조각이 있는 TableName을 참조하고 있습니다.
- 스키마는 현재 반복의 필드인
파이프라인 디자인: 싱크
싱크의 경우 웨어하우스를 가리키고 원본 스키마 및 테이블 이름을 참조합니다.
이 파이프라인을 실행하면 Data Warehouse가 적절한 스키마를 사용하여 원본의 각 테이블로 채워진 것을 볼 수 있습니다.
Synapse 전용 SQL 풀에서 저장 프로시저를 사용하여 마이그레이션
이 옵션은 저장 프로시저를 사용하여 Fabric 마이그레이션을 수행합니다.
GitHub.com의 microsoft/fabric-migration에서 코드 샘플을 가져올 수 있습니다. 이 코드는 오픈 소스로 공유되므로 자유롭게 공동 작업하고 커뮤니티에 도움을 줄 수 있습니다.
마이그레이션 저장 프로시저에서 수행할 수 있는 작업은 다음과 같습니다.
- DDL(스키마)을 Fabric 웨어하우스 구문으로 변환합니다.
- Fabric 웨어하우스에서 DDL(스키마)을 만듭니다.
- Synapse 전용 SQL 풀에서 ADLS로 데이터를 추출합니다.
- T-SQL 코드(저장 프로시저, 함수, 보기)에 대해 지원되지 않는 Fabric 구문에 플래그를 지정합니다.
권장 사용
이 옵션은 다음 사용자에게 유용한 옵션입니다.
- T-SQL에 익숙합니다.
- SSMS(SQL Server Management Studio)와 같은 통합 개발 환경을 사용하려고 합니다.
- 작업하려는 작업을 보다 세부적으로 제어하려고 합니다.
DDL(스키마) 변환, 데이터 추출 또는 T-SQL 코드 평가에 대한 특정 저장 프로시저를 실행할 수 있습니다.
데이터 마이그레이션의 경우 COPY INTO 또는 Data Factory를 사용하여 Fabric 웨어하우스로 데이터를 수집해야 합니다.
SQL 데이터베이스 프로젝트를 사용하여 마이그레이션
Microsoft Fabric Data Warehouse는 Azure Data Studio 및 Visual Studio Code 내에서 사용할 수 있는 SQL Database 프로젝트 확장에서 지원됩니다.
이 확장은 Azure Data Studio 및 Visual Studio Code에서 사용할 수 있습니다. 이 기능을 사용하면 소스 제어, 데이터베이스 테스트 및 스키마 유효성 검사 기능을 사용할 수 있습니다.
Git 통합 및 배포 파이프라인을 포함하여 Microsoft Fabric 웨어하우스에 대한 소스 제어에 대한 자세한 내용은 웨어하우스를 사용한 소스 제어를 참조하세요.
권장 사용
이 옵션은 배포에 SQL Database 프로젝트를 사용하려는 사용자에게 유용한 옵션입니다. 이 옵션은 기본적으로 Fabric 마이그레이션 저장 프로시저를 SQL Database 프로젝트에 통합하여 원활한 마이그레이션 환경을 제공합니다.
SQL Database 프로젝트에서는 다음을 수행할 수 있습니다.
- DDL(스키마)을 Fabric 웨어하우스 구문으로 변환합니다.
- Fabric 웨어하우스에서 DDL(스키마)을 만듭니다.
- Synapse 전용 SQL 풀에서 ADLS로 데이터를 추출합니다.
- T-SQL 코드(저장 프로시저, 함수, 보기)에 대해 지원되지 않는 구문에 플래그를 지정합니다.
데이터 마이그레이션의 경우 COPY INTO 또는 Data Factory를 사용하여 Fabric 웨어하우스로 데이터를 수집합니다.
Microsoft Fabric CAT 팀은 Azure Data Studio 지원 가능성을 Fabric에 더하여 SQL Database 프로젝트를 통해 DDL(스키마) 및 DML(데이터베이스 코드)의 추출, 생성, 배포를 처리하는 PowerShell 스크립트 집합을 제공했습니다. 유용한 PowerShell 스크립트와 함께 SQL Database 프로젝트를 사용하는 연습은 GitHub.com의 microsoft/fabric-migration을 참조하세요.
SQL Database 프로젝트에 대한 자세한 내용은 SQL Database 프로젝트 확장 시작과 프로젝트 빌드 및 게시를 참조하세요.
CETAS를 사용하여 데이터 마이그레이션
T-SQL CREATE EXTERNAL TABLE AS SELECT(CETAS) 명령은 Synapse 전용 SQL 풀에서 ADLS(Azure Data Lake Storage) Gen2로 데이터를 추출하는 가장 비용 효율적인 최적의 방법을 제공합니다.
CETAS에서 수행할 수 있는 작업은 다음과 같습니다.
- 데이터를 ADLS로 추출합니다.
- 이 옵션을 사용하려면 사용자가 데이터를 수집하기 전에 Fabric 웨어하우스에서 DDL(스키마)을 만들어야 합니다. 이 문서의 옵션을 사용하여 DDL(스키마)을 마이그레이션합니다.
이 옵션의 장점은 다음과 같습니다.
- 원본 Synapse 전용 SQL 풀에 대해 테이블당 단일 쿼리만 제출됩니다. 이렇게 하면 모든 동시성 슬롯이 사용되지 않으므로 동시 고객 프로덕션 ETL/쿼리를 차단하지 않습니다.
- 각 테이블에 단일 동시성 슬롯만 사용되므로 고객은 더 낮은 DWU를 사용할 수 있어 DWU6000 크기 조정이 필요하지 않습니다.
- 추출은 모든 컴퓨팅 노드에서 병렬로 실행되며 이는 성능 향상의 핵심입니다.
권장 사용
CETAS를 사용하여 데이터를 Parquet 파일로 ADLS에 추출합니다. Parquet 파일은 네트워크를 통해 이동하는 데 더 적은 대역폭이 소요되는 열 형식 압축을 통해 효율적인 데이터 스토리지의 이점을 제공합니다. 또한 Fabric은 데이터를 델타 parquet 형식으로 저장했기 때문에 수집 중에 델타 형식 오버헤드로 변환되지 않으므로 데이터 수집 속도가 텍스트 파일 형식에 비해 2.5배 더 빠릅니다.
CETAS 처리량을 늘리려면 다음을 수행합니다.
- 병렬 CETAS 작업을 추가하여 동시성 슬롯의 사용을 늘리면서 더 많은 처리량을 허용합니다.
- Synapse 전용 SQL 풀에서 DWU 크기를 조정합니다.
dbt를 통한 마이그레이션
이 섹션에서는 현재 Synapse 전용 SQL 풀 환경에서 이미 dbt를 사용하고 있는 고객을 위한 dbt 옵션에 대해 설명합니다.
수행할 수 있는 작업은 다음과 같습니다.
- DDL(스키마)을 Fabric 웨어하우스 구문으로 변환합니다.
- Fabric 웨어하우스에서 DDL(스키마)을 만듭니다.
- DML(데이터베이스 코드)을 Fabric 구문으로 변환합니다.
dbt 프레임워크는 실행될 때마다 DDL 및 DML(SQL 스크립트)을 즉시 생성합니다. SELECT 문에 표현된 모델 파일을 사용하면 프로필(연결 문자열) 및 어댑터 유형을 변경하여 DDL/DML을 모든 대상 플랫폼으로 즉시 변환할 수 있습니다.
권장 사용
dbt 프레임워크는 코드 우선 방법입니다. 이 문서에 나열된 옵션(예: CETAS 또는 COPY/Data Factory)을 사용하여 데이터를 마이그레이션해야 합니다.
Microsoft Fabric Synapse Data Warehouse용 dbt 어댑터를 사용하면 Synapse 전용 SQL 풀, Snowflake, Databricks, Google 빅 쿼리 또는 Amazon Redshift와 같은 다양한 플랫폼을 대상으로 하는 기존 dbt 프로젝트를 간단한 구성 변경을 통해 Fabric 웨어하우스로 마이그레이션할 수 있습니다.
Fabric 웨어하우스를 대상으로 하는 dbt 프로젝트를 시작하려면 자습서: Fabric Data Warehouse에 대한 dbt 설정을 참조하세요. 이 문서에는 다른 웨어하우스/플랫폼 간에 이동하는 옵션도 나열되어 있습니다.
Fabric 웨어하우스로 데이터 수집
Fabric 웨어하우스로 수집하려면 기본 설정에 따라 COPY INTO 또는 Fabric Data Factory를 사용합니다. 파일이 이미 ADLS(Azure Data Lake Storage) Gen2에 추출된 필수 조건을 감안할 때 두 방법 모두 동일한 성능 처리량을 가지므로 이는 권장되는 최적의 성능 옵션입니다.
최대 성능을 위해 프로세스를 디자인할 수 있도록 주의해야 할 몇 가지 요소는 다음과 같습니다.
- Fabric을 사용하면 ADLS에서 Fabric 웨어하우스로 여러 테이블을 동시에 로드할 때 리소스 경합이 없습니다. 따라서 병렬 스레드를 로드할 때 성능이 저하되지 않습니다. 최대 수집 처리량은 Fabric 용량의 컴퓨팅 성능에 의해서만 제한됩니다.
- Fabric 워크로드 관리는 부하 및 쿼리에 할당된 리소스의 분리를 제공합니다. 쿼리 및 데이터 로드가 동시에 실행되는 동안에는 리소스 경합이 없습니다.