Share via


마이그레이션: Azure Synapse Analytics 전용 SQL 풀을 패브릭으로

적용 대상: Microsoft Fabric의 웨어하우스

이 문서에서는 Azure Synapse Analytics 전용 SQL 풀에서 Microsoft Fabric Warehouse로 데이터 웨어하우징을 마이그레이션하는 전략, 고려 사항 및 방법을 자세히 설명합니다.

마이그레이션 소개

Microsoft는 Data Factory, 데이터 엔지니어ing, 데이터 웨어하우징, 데이터 과학, 실시간 인텔리전스Power BI를 비롯한 포괄적인 서비스 제품군을 제공하는 엔터프라이즈를 위한 올인원 SaaS 분석 솔루션인 Microsoft Fabric을 도입했습니다.

이 문서에서는 DDL(스키마) 마이그레이션, DML(데이터베이스 코드) 마이그레이션 및 데이터 마이그레이션 옵션에 중점을 둡니다. Microsoft는 몇 가지 옵션을 제공하며 여기서는 각 옵션에 대해 자세히 설명하고 시나리오에 대해 고려해야 하는 이러한 옵션에 대한 지침을 제공합니다. 이 문서에서는 일러스트레이션 및 성능 테스트를 위해 TPC-DS 업계 벤치마크를 사용합니다. 실제 결과는 데이터 형식, 데이터 형식, 테이블 너비, 데이터 원본 대기 시간 등을 비롯한 여러 요인에 따라 달라질 수 있습니다.

마이그레이션 준비

시작하기 전에 마이그레이션 프로젝트를 신중하게 계획하고 스키마, 코드 및 데이터가 Fabric Warehouse와 호환되는지 확인합니다. 고려해야 할 몇 가지 제한 사항이 있습니다. 마이그레이션 배달 전에 필요한 다른 리소스뿐만 아니라 호환되지 않는 항목의 리팩터링 작업을 정량화합니다.

계획의 또 다른 주요 목표는 패브릭 웨어하우스가 제공하도록 설계된 높은 쿼리 성능을 솔루션이 최대한 활용할 수 있도록 디자인을 조정하는 것입니다. 확장을 위한 데이터 웨어하우스의 디자인은 고유한 디자인 패턴을 도입하므로 일반적인 접근 방식이 항상 최선은 아닙니다. 패브릭 웨어하우스 성능 지침을 검토합니다. 마이그레이션 후에 일부 디자인을 조정할 수 있지만 프로세스의 앞부분에서 변경하면 시간과 노력이 절약되기 때문입니다. 한 기술/환경에서 다른 환경으로 마이그레이션하는 것은 항상 중요한 작업입니다.

다음 다이어그램에서는 원활한 마이그레이션을 계획하고 준비하기 위해 각 핵심 요소의 관련 작업과 함께 평가 및 평가, 계획 및 디자인, 마이그레이션, 모니터링 및 관리, 최적화 및 현대화 핵심 요소로 구성된 주요 핵심 요소를 나열하는 마이그레이션 수명 주기를 보여 줍니다.

마이그레이션 수명 주기의 다이어그램.

마이그레이션용 Runbook

Synapse 전용 SQL 풀에서 패브릭 웨어하우스로 마이그레이션하기 위한 계획 Runbook으로 다음 활동을 고려합니다.

  1. 평가 및 평가
    1. 목표와 동기를 식별합니다. 명확한 원하는 결과를 설정합니다.
    2. 기존 아키텍처를 검색, 평가 및 기준으로 합니다.
    3. 주요 이해 관계자 및 스폰서를 식별합니다.
    4. 마이그레이션할 대상의 범위를 정의합니다.
      1. 작고 간단하게 시작하여 여러 소규모 마이그레이션을 준비합니다.
      2. 프로세스의 모든 단계를 모니터링하고 문서화하기 시작합니다.
      3. 마이그레이션을 위한 데이터 및 프로세스 인벤토리를 빌드합니다.
      4. 데이터 모델 변경 내용을 정의합니다(있는 경우).
      5. 패브릭 작업 영역을 설정합니다.
    5. 기술 세트/기본 설정이란?
      1. 가능한 모든 곳에서 자동화합니다.
      2. Azure 기본 제공 도구 및 기능을 사용하여 마이그레이션 노력을 줄입니다.
    6. 새 플랫폼에서 초기에 담당자를 학습합니다.
      1. Microsoft Learn을 포함하여 업스킬링 요구 사항 및 교육 자산을 식별합니다.
  2. 계획 및 디자인
    1. 원하는 아키텍처를 정의합니다.
    2. 마이그레이션대한 방법/도구를 선택하여 다음 작업을 수행합니다.
      1. 원본에서 데이터 추출.
      2. 테이블 및 뷰에 대한 메타데이터를 포함하여 DDL(스키마) 변환
      3. 기록 데이터를 포함한 데이터 수집
        1. 필요한 경우 새 플랫폼 성능 및 확장성을 사용하여 데이터 모델을 다시 엔지니어링합니다.
      4. DML(데이터베이스 코드) 마이그레이션
        1. 저장 프로시저 및 업무 프로세스를 마이그레이션하거나 리팩터링합니다.
    3. 원본에서 보안 기능 및 개체 권한을 인벤토리화하고 추출합니다.
    4. 증분 로드를 위해 기존 ETL/ELT 프로세스를 대체/수정하도록 설계 및 계획합니다.
      1. 새 환경에 대한 병렬 ETL/ELT 프로세스를 만듭니다.
    5. 자세한 마이그레이션 계획을 준비합니다.
      1. 현재 상태를 원하는 새 상태로 매핑합니다.
  3. 마이그레이션
    1. 스키마, 데이터, 코드 마이그레이션을 수행합니다.
      1. 원본에서 데이터 추출.
      2. 스키마(DDL) 변환
      3. 데이터 수집
      4. DML(데이터베이스 코드) 마이그레이션
    2. 필요한 경우 마이그레이션 속도를 지원하기 위해 전용 SQL 풀 리소스를 일시적으로 확장합니다.
    3. 보안 및 사용 권한을 적용합니다.
    4. 증분 로드를 위해 기존 ETL/ELT 프로세스를 마이그레이션합니다.
      1. ETL/ELT 증분 로드 프로세스를 마이그레이션하거나 리팩터링합니다.
      2. 병렬 증분 로드 프로세스를 테스트하고 비교합니다.
    5. 필요에 따라 세부 마이그레이션 계획을 조정합니다.
  4. 모니터링 및 관리
    1. 병렬로 실행하여 원본 환경과 비교합니다.
      1. 애플리케이션, 비즈니스 인텔리전스 플랫폼 및 쿼리 도구를 테스트합니다.
      2. 쿼리 성능을 벤치마킹하고 최적화합니다.
      3. 비용, 보안 및 성능을 모니터링하고 관리합니다.
    2. 거버넌스 벤치마크 및 평가.
  5. 최적화 및 현대화
    1. 비즈니스가 편안하면 애플리케이션 및 기본 보고 플랫폼을 패브릭으로 전환합니다.
      1. 워크로드가 Azure Synapse Analytics에서 Microsoft Fabric으로 이동함에 따라 리소스를 확장/축소합니다.
      2. 향후 마이그레이션을 위해 얻은 환경에서 반복 가능한 템플릿을 빌드합니다. 반복.
      3. 비용 최적화, 보안, 확장성 및 운영 우수성에 대한 기회 식별
      4. 최신 패브릭 기능을 사용하여 데이터 자산을 현대화할 기회를 식별합니다.

'리프트 앤 시프트'또는 현대화?

일반적으로 계획된 마이그레이션의 목적과 범위, 즉 리프트 앤 시프트를 있는 그대로 또는 아키텍처 및 코드 변경 내용을 통합하는 단계적 접근 방식과 관계없이 두 가지 유형의 마이그레이션 시나리오가 있습니다.

리프트 앤 시프트

리프트 앤 시프트 마이그레이션에서 기존 데이터 모델은 새 패브릭 웨어하우스를 약간 변경하여 마이그레이션됩니다. 이 방법은 마이그레이션의 이점을 실현하는 데 필요한 새 작업을 줄여 위험 및 마이그레이션 시간을 최소화합니다.

리프트 앤 시프트 마이그레이션은 다음 시나리오에 적합합니다.

  • 마이그레이션할 데이터 마트가 적은 기존 환경이 있습니다.
  • 잘 디자인된 별모양 또는 눈송이 스키마에 이미 있는 데이터가 있는 기존 환경이 있습니다.
  • 패브릭 웨어하우스로 이동하는 데 시간과 비용 부담이 있습니다.

요약하자면, 이 방법은 현재 Synapse 전용 SQL 풀 환경으로 최적화된 워크로드에 적합하므로 패브릭에서 큰 변경이 필요하지 않습니다.

아키텍처를 변경하여 단계적 접근 방식으로 현대화

레거시 데이터 웨어하우스가 오랜 기간 동안 발전한 경우 필요한 성능 수준을 유지하기 위해 이를 다시 설계해야 할 수 있습니다.

패브릭 작업 영역에서 사용할 수 있는 새로운 엔진과 기능을 활용하도록 아키텍처를 다시 디자인할 수도 있습니다.

디자인 차이점: Synapse 전용 SQL 풀 및 패브릭 웨어하우스

전용 SQL 풀을 Fabric Warehouse와 비교하여 다음과 같은 Azure Synapse 및 Microsoft Fabric 데이터 웨어하우징 차이점을 고려합니다.

테이블 고려 사항

서로 다른 환경 간에 테이블을 마이그레이션하는 경우 일반적으로 원시 데이터와 메타데이터만 물리적으로 마이그레이션됩니다. 인덱스와 같은 원본 시스템의 다른 데이터베이스 요소는 일반적으로 새 환경에서 불필요하거나 다르게 구현될 수 있으므로 마이그레이션되지 않습니다.

인덱스와 같은 원본 환경의 성능 최적화는 새 환경에서 성능 최적화를 추가할 수 있는 위치를 나타내지만 이제 Fabric에서 자동으로 처리합니다.

T-SQL 고려 사항

알아야 할 몇 가지 DML(데이터 조작 언어) 구문 차이점이 있습니다. Microsoft Fabric의 T-SQL 노출 영역을 참조하세요. DML(데이터베이스 코드)에 대한 마이그레이션 방법을 선택할 때도 코드 평가를 고려합니다.

마이그레이션 시 패리티 차이에 따라 T-SQL DML 코드의 일부를 다시 작성해야 할 수 있습니다.

데이터 형식 매핑 차이점

패브릭 웨어하우스에는 몇 가지 데이터 형식 차이점이 있습니다. 자세한 내용은 Microsoft Fabric의 데이터 형식을 참조 하세요.

다음 표에서는 Synapse 전용 SQL 풀에서 Fabric Warehouse로 지원되는 데이터 형식의 매핑을 제공합니다.

Synapse 전용 SQL 풀 패브릭 웨어하우스
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 Warehouse에서 지원되지 않으므로 표준 시간대 오프셋 데이터를 별도의 열로 추출해야 합니다.

스키마, 코드 및 데이터 마이그레이션 방법

이러한 옵션 중 시나리오, 직원 기술 집합 및 데이터의 특성에 맞는 옵션을 검토하고 식별합니다. 선택한 옵션은 환경, 기본 설정 및 각 도구의 이점에 따라 달라집니다. 우리의 목표는 마이그레이션 환경을 원활하게 만들기 위해 마찰과 수동 개입을 완화하는 마이그레이션 도구를 계속 개발하는 것입니다.

이 표에는 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 풀에서 패브릭 웨어하우스 마이그레이션 프로젝트로 시작할 위치를 결정할 때 다음을 수행할 수 있는 워크로드 영역을 선택합니다.

  • 새 환경의 이점을 신속하게 제공하여 패브릭 웨어하우스로 마이그레이션할 수 있는 가능성을 증명합니다. 작고 간단하게 시작하여 여러 소규모 마이그레이션을 준비합니다.
  • 사내 기술 직원이 다른 영역으로 마이그레이션할 때 사용하는 프로세스 및 도구에 대한 관련 경험을 얻을 수 있도록 합니다.
  • 원본 Synapse 환경과 관련된 추가 마이그레이션을 위한 템플릿과 도움이 되는 도구 및 프로세스를 만듭니다.

마이그레이션해야 하는 개체의 인벤토리를 만들고 마이그레이션 프로세스를 처음부터 끝까지 문서화하여 다른 전용 SQL 풀 또는 워크로드에 대해 반복할 수 있도록 합니다.

초기 마이그레이션에서 마이그레이션된 데이터의 볼륨은 패브릭 웨어하우스 환경의 기능과 이점을 입증할 만큼 충분히 커야 하지만, 가치를 빠르게 입증하기에는 너무 크지 않습니다. 1-10TB 범위의 크기가 일반적입니다.

Fabric Data Factory를 사용하여 마이그레이션

이 섹션에서는 Azure Data Factory 및 Synapse Pipeline에 익숙한 하위 코드/코드 없는 가상 사용자에 Data Factory를 사용하는 옵션에 대해 설명합니다. 이 끌어서 놓기 UI 옵션은 DDL을 변환하고 데이터를 마이그레이션하는 간단한 단계를 제공합니다.

Fabric Data Factory는 다음 작업을 수행할 수 있습니다.

  • 스키마(DDL)를 Fabric Warehouse 구문으로 변환합니다.
  • 패브릭 웨어하우스에서 DDL(스키마)을 만듭니다.
  • 패브릭 웨어하우스로 데이터를 마이그레이션합니다.

옵션 1. 스키마/데이터 마이그레이션 - 복사 마법사 및 ForEach 복사 작업

이 메서드는 Data Factory Copy 도우미 사용하여 원본 전용 SQL 풀에 연결하고, 전용 SQL 풀 DDL 구문을 Fabric으로 변환하고, 데이터를 Fabric Warehouse에 복사합니다. 1개 이상의 대상 테이블을 선택할 수 있습니다(TPC-DS 데이터 세트의 경우 22개의 테이블이 있습니다). ForEach를 생성하여 UI에서 선택한 테이블 목록을 반복하고 22개의 병렬 복사 작업 스레드를 생성합니다.

  • 22개의 SELECT 쿼리(선택한 각 테이블에 대해 하나)가 생성되어 전용 SQL 풀에서 실행되었습니다.
  • 생성된 쿼리를 실행할 수 있도록 적절한 DWU 및 리소스 클래스가 있는지 확인합니다. 이 경우 최대 32개의 쿼리가 제출된 22개의 쿼리를 처리할 수 있도록 최소 DWU1000 staticrc10 필요합니다.
  • 전용 SQL 풀에서 Fabric Warehouse로 데이터를 직접 복사하려면 Data Factory에서 준비해야 합니다. 수집 프로세스는 두 단계로 구성됩니다.
    • 첫 번째 단계는 전용 SQL 풀에서 ADLS로 데이터를 추출하는 것으로 구성되며 스테이징이라고 합니다.
    • 두 번째 단계는 스테이징에서 패브릭 웨어하우스로 데이터를 수집하는 것으로 구성됩니다. 대부분의 데이터 수집 타이밍은 준비 단계에 있습니다. 요약하면 스테이징은 수집 성능에 큰 영향을 미칩니다.

복사 마법사를 사용하여 ForEach를 생성하면 DDL을 변환하고 선택한 테이블을 전용 SQL 풀에서 Fabric Warehouse로 한 단계로 수집하는 간단한 UI가 제공됩니다.

그러나 전체 처리량으로는 최적이 아닙니다. 스테이징을 사용해야 하는 요구 사항, "소스-스테이지" 단계에 대한 읽기 및 쓰기를 병렬화해야 하는 요구 사항은 성능 대기 시간의 주요 요소입니다. 차원 테이블에만 이 옵션을 사용하는 것이 좋습니다.

옵션 2. DDL/데이터 마이그레이션 - 파티션 옵션을 사용하는 데이터 파이프라인

패브릭 데이터 파이프라인을 사용하여 더 큰 팩트 테이블을 로드하는 처리량 향상을 해결하려면 파티션 옵션이 있는 각 팩트 테이블에 복사 작업을 사용하는 것이 좋습니다. 이렇게 하면 복사 작업 최상의 성능을 제공합니다.

사용 가능한 경우 원본 테이블 물리적 분할을 사용할 수 있습니다. 테이블에 실제 분할이 없는 경우 파티션 열을 지정하고 동적 분할을 사용하려면 최소/최대값을 제공해야 합니다. 다음 스크린샷에서 데이터 파이프라인 원본 옵션은 열을 기반으로 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개의 활성 쿼리가 허용됩니다.

옵션 3. DDL 마이그레이션 - 복사 마법사 ForEach 복사 작업

이전의 두 가지 옵션은 소규모 데이터베이스에 대한 훌륭한 데이터 마이그레이션 옵션입니다. 그러나 더 높은 처리량이 필요한 경우 대체 옵션을 사용하는 것이 좋습니다.

  1. 전용 SQL 풀에서 ADLS로 데이터를 추출하여 단계 성능 오버헤드를 완화합니다.
  2. Data Factory 또는 COPY 명령을 사용하여 패브릭 웨어하우스로 데이터를 수집합니다.

Data Factory를 계속 사용하여 스키마(DDL)를 변환할 수 있습니다. 복사 마법사를 사용하여 특정 테이블 또는 모든 테이블을 선택할 수 있습니다. 기본적으로 쿼리 문에서 false 조건을 TOP 0 사용하여 행 없이 스키마를 추출하여 스키마와 데이터를 한 단계로 마이그레이션합니다.

다음 코드 샘플에서는 Data Factory를 사용한 DDL(스키마) 마이그레이션에 대해 설명합니다.

코드 예제: Data Factory를 사용하여 스키마(DDL) 마이그레이션

패브릭 데이터 파이프라인을 사용하여 원본 Azure SQL Database 또는 전용 SQL 풀의 테이블 개체에 대한 DDL(스키마)을 통해 쉽게 마이그레이션할 수 있습니다. 이 데이터 파이프라인은 원본 전용 SQL 풀 테이블의 스키마(DDL)를 통해 Fabric Warehouse로 마이그레이션합니다.

For Each 개체로 이어지는 조회 개체를 보여 주는 Fabric Data Factory의 스크린샷 For Each 개체 내에는 DDL을 마이그레이션하는 작업이 있습니다.

파이프라인 디자인: 매개 변수

이 데이터 파이프라인은 마이그레이션할 스키마를 지정할 수 있는 매개 변수 SchemaName를 허용합니다. 스키마가 dbo 기본값입니다.

기본값 필드에 마이그레이션 'dbo','tpch' 할 스키마를 나타내는 쉼표로 구분된 테이블 스키마 목록을 입력합니다 dbotpch. 두 스키마를 제공하고 .

데이터 파이프라인의 매개 변수 탭을 보여 주는 Data Factory의 스크린샷 이름 필드에서 'SchemaName'입니다. 기본값 필드 'dbo','tpch'에서 이러한 두 스키마를 마이그레이션해야 함을 나타냅니다.

파이프라인 디자인: 조회 작업

조회 작업을 만들고 원본 데이터베이스를 가리키도록 커넥트을 설정합니다.

설정 탭에서 다음을 수행합니다.

  • 데이터 저장소 유형을 외부설정합니다.

  • 커넥트ion은 Azure Synapse 전용 SQL 풀입니다. 커넥트ion 유형은 Azure Synapse Analytics입니다.

  • 쿼리 사용은 쿼리설정됩니다.

  • 쿼리 필드는 동적 식을 사용하여 작성해야 하므로 대상 원본 테이블 목록을 반환하는 쿼리에서 SchemaName 매개 변수를 사용할 수 있습니다. 쿼리를 선택한 다음 동적 콘텐츠 추가를 선택합니다.

    LookUp 작업 내의 이 식은 시스템 뷰를 쿼리하여 스키마 및 테이블 목록을 검색하는 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'),')
    ')
    

데이터 파이프라인의 설정 탭을 보여 주는 Data Factory의 스크린샷 '쿼리' 단추가 선택되고 코드가 '쿼리' 필드에 붙여넣습니다.

파이프라인 디자인: ForEach 루프

ForEach 루프의 경우 설정 탭에서 다음 옵션을 구성합니다.

  • 여러 반복이 동시에 실행되도록 하려면 순차를 사용하지 않도록 설정합니다.
  • 일괄 처리 수를 설정하여 50최대 동시 반복 횟수를 제한합니다.
  • 항목 필드는 동적 콘텐츠를 사용하여 조회 작업의 출력을 참조해야 합니다. 다음 코드 조각을 사용합니다. @activity('Get List of Source Objects').output.value

ForEach 루프 작업의 설정 탭을 보여 주는 스크린샷

파이프라인 디자인: ForEach 루프 내의 복사 작업

ForEach 작업 내에 복사 작업을 추가합니다. 이 메서드는 데이터 파이프라인 내의 동적 식 언어를 사용하여 데이터가 없는 스키마만 패브릭 웨어하우스로 마이그레이션하도록 빌드 SELECT TOP 0 * FROM <TABLE> 합니다.

원본 탭에서:

  • 데이터 저장소 유형을 외부설정합니다.
  • 커넥트ion은 Azure Synapse 전용 SQL 풀입니다. 커넥트ion 유형은 Azure Synapse Analytics입니다.
  • 쿼리에 사용 쿼리 설정합니다.
  • 쿼리 필드에서 동적 콘텐츠 쿼리에 붙여넣고 테이블 스키마만 0행을 반환하는 이 식을 사용합니다.@concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)

ForEach 루프 내 복사 작업의 원본 탭을 보여 주는 Data Factory의 스크린샷

대상 탭에서 다음을 수행 합니다 .

  • 데이터 저장소 유형을 작업 영역으로 설정합니다.
  • 작업 영역 데이터 저장소 유형Data Warehouse이고 데이터 웨어하우스는 패브릭 웨어하우스로 설정됩니다.
  • 대상 테이블의 스키마 및 테이블 이름은 동적 콘텐츠를 사용하여 정의됩니다.
    • 스키마는 현재 반복의 필드인 코드 조각이 있는 SchemaName을 참조합니다. @item().SchemaName
    • 테이블이 코드 조각을 사용하여 TableName을 참조하고 있습니다. @item().TableName

각 ForEach 루프 내에서 복사 작업의 대상 탭을 보여 주는 Data Factory의 스크린샷

파이프라인 디자인: 싱크

싱크의 경우 웨어하우스를 가리키고 원본 스키마 및 테이블 이름을 참조합니다.

이 파이프라인을 실행하면 데이터 웨어하우스가 적절한 스키마를 사용하여 원본의 각 테이블로 채워진 것을 볼 수 있습니다.

Synapse 전용 SQL 풀에서 저장 프로시저를 사용하여 마이그레이션

이 옵션은 저장 프로시저를 사용하여 패브릭 마이그레이션을 수행합니다.

GitHub.com microsoft/fabric-migration에서 코드 샘플을 가져올 수 있습니다. 이 코드는 오픈 소스 공유되므로 자유롭게 공동 작업하고 커뮤니티에 도움을 줄 수 있습니다.

마이그레이션 저장 프로시저에서 수행할 수 있는 작업은 다음과 같습니다.

  1. 스키마(DDL)를 Fabric Warehouse 구문으로 변환합니다.
  2. 패브릭 웨어하우스에서 DDL(스키마)을 만듭니다.
  3. Synapse 전용 SQL 풀에서 ADLS로 데이터를 추출합니다.
  4. T-SQL 코드(저장 프로시저, 함수, 뷰)에 대해 지원되지 않는 패브릭 구문에 플래그를 지정합니다.

이 옵션은 다음을 수행하는 사람들에게 유용한 옵션입니다.

  • T-SQL에 익숙합니다.
  • SSMS(SQL Server Management Studio)와 같은 통합 개발 환경을 사용하려고 합니다.
  • 작업하려는 작업을 보다 세부적으로 제어하려고 합니다.

스키마(DDL) 변환, 데이터 추출 또는 T-SQL 코드 평가에 대한 특정 저장 프로시저를 실행할 수 있습니다.

데이터 마이그레이션의 경우 COPY INTO 또는 Data Factory를 사용하여 패브릭 웨어하우스로 데이터를 수집해야 합니다.

SQL Database 프로젝트를 사용하여 마이그레이션

Microsoft Fabric Data Warehouse는 Azure Data StudioVisual Studio Code 내에서 사용할 수 있는 SQL Database 프로젝트 확장에서 지원됩니다.

이 확장은 Azure Data Studio 및 Visual Studio Code 내에서 사용할 수 있습니다. 이 기능을 사용하면 소스 제어, 데이터베이스 테스트 및 스키마 유효성 검사 기능을 사용할 수 있습니다.

이 옵션은 배포에 SQL Database 프로젝트를 사용하려는 사용자에게 유용한 옵션입니다. 이 옵션은 기본적으로 패브릭 마이그레이션 저장 프로시저를 SQL Database 프로젝트에 통합하여 원활한 마이그레이션 환경을 제공합니다.

SQL Database 프로젝트는 다음을 수행할 수 있습니다.

  1. 스키마(DDL)를 Fabric Warehouse 구문으로 변환합니다.
  2. 패브릭 웨어하우스에서 DDL(스키마)을 만듭니다.
  3. Synapse 전용 SQL 풀에서 ADLS로 데이터를 추출합니다.
  4. T-SQL 코드(저장 프로시저, 함수, 뷰)에 대해 지원되지 않는 구문에 플래그를 지정합니다.

데이터 마이그레이션의 경우 COPY INTO 또는 Data Factory를 사용하여 패브릭 웨어하우스로 데이터를 수집합니다.

Azure Data Studio 지원 가능성을 패브릭에 추가한 Microsoft Fabric CAT 팀은 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 Warehouse에서 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 옵션에 대해 설명합니다.

dbt에서 수행할 수 있는 작업은 다음과 같습니다.

  1. 스키마(DDL)를 Fabric Warehouse 구문으로 변환합니다.
  2. 패브릭 웨어하우스에서 DDL(스키마)을 만듭니다.
  3. DML(데이터베이스 코드)을 패브릭 구문으로 변환합니다.

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 프로젝트를 간단한 구성 변경으로 패브릭 웨어하우스로 마이그레이션할 수 있습니다.

패브릭 웨어하우스를 대상으로 하는 dbt 프로젝트를 시작하려면 자습서: Fabric Data Warehouse에 대한 dbt 설정을 참조하세요. 이 문서에는 다른 웨어하우스/플랫폼 간에 이동하는 옵션도 나열되어 있습니다.

패브릭 웨어하우스로 데이터 수집

패브릭 웨어하우스로 수집하려면 기본 설정에 따라 COPY INTO 또는 Fabric Data Factory를 사용합니다. 파일이 이미 ADLS(Azure Data Lake Storage) Gen2에 추출된 필수 조건을 감안할 때 두 방법 모두 동일한 성능 처리량을 가지므로 권장되고 성능이 뛰어난 옵션입니다.

최대 성능을 위해 프로세스를 디자인할 수 있도록 주의해야 할 몇 가지 요소는 다음과 같습니다.

  • Fabric을 사용하면 ADLS에서 Fabric Warehouse로 여러 테이블을 동시에 로드하는 리소스 경합이 없습니다. 따라서 병렬 스레드를 로드하는 성능 저하가 없습니다. 최대 수집 처리량은 패브릭 용량의 컴퓨팅 성능에 의해서만 제한됩니다.
  • 패브릭 워크로드 관리는 부하 및 쿼리에 할당된 리소스의 분리를 제공합니다. 쿼리 및 데이터 로드가 동시에 실행되는 동안에는 리소스 경합이 없습니다.