다음을 통해 공유


Teradata 마이그레이션을 위한 디자인 및 성능

이 문서는 Teradata에서 Azure Synapse Analytics로 마이그레이션하는 방법에 대한 지침을 제공하는 7부작 시리즈 중 1부입니다. 이 문서는 디자인 및 성능에 대한 모범 사례에 중점을 두고 있습니다.

개요

Teradata 데이터 웨어하우스 시스템의 많은 기존 사용자는 최신 클라우드 환경이 제공하는 혁신을 활용하기를 원합니다. IaaS(Infrastructure-as-a-Service) 및 PaaS(Platform-as-a-Service) 클라우드 환경을 사용하면 인프라 유지 관리 및 플랫폼 개발과 같은 작업을 클라우드 공급자에게 위임할 수 있습니다.

단순한 데이터베이스가 아닌 Azure 환경에는 포괄적인 기능 및 도구 세트가 포함되어 있습니다.

Teradata와 Azure Synapse Analytics는 둘 다 매우 큰 데이터 볼륨에서 높은 쿼리 성능을 달성하기 위해 MPP(대규모 병렬 처리) 기술을 사용하는 SQL 데이터베이스이지만 접근 방식에서 몇 가지 기본적인 차이점이 있습니다.

  • 레거시 Teradata 시스템은 자주 온-프레미스에 설치되고 전용 하드웨어를 사용하는 반면, Azure Synapse는 클라우드 기반이며 Azure 스토리지 및 컴퓨팅 리소스를 사용합니다.

  • 스토리지와 컴퓨팅 리소스는 Azure 환경에서 분리되어 있고 탄력적인 스케일링 기능이 있으므로 이러한 리소스를 독립적으로 위 또는 아래로 스케일링 기능을 활용할 수 있습니다.

  • 리소스 사용률과 비용을 줄이기 위해 필요에 따라 Azure Synapse를 일시 중지하거나 크기를 조정할 수 있습니다.

  • Teradata 구성 업그레이드는 추가 실제 하드웨어와 잠재적으로 긴 데이터베이스 다시 구성 또는 다시 로드를 포함하는 주요 작업입니다.

Microsoft Azure는 Azure Synapse와 지원 도구 및 기능의 에코시스템을 포함하는 전 세계적으로 사용 가능하고 매우 안전하며 스케일링 가능한 클라우드 환경입니다. 다음은 Azure Synapse 에코시스템을 요약해서 보여주는 다이어그램입니다.

지원 도구 및 기능의 Azure Synapse 에코시스템을 보여 주는 차트.

Azure Synapse는 자주 사용하는 데이터에 대해 MPP 및 여러 수준의 자동화된 캐싱과 같은 기술을 사용하여 동급 최고의 관계형 데이터베이스 성능을 제공합니다. Azure Synapse를 다른 자주 사용되는 클라우드 데이터 웨어하우스 제품과 비교하는 GigaOm에서 최근에 실행한 것과 같은 독립적인 벤치마크에서 이러한 기술의 결과를 확인할 수 있습니다. Azure Synapse 환경으로 마이그레이션하는 고객은 다음과 같은 많은 이점을 누릴 수 있습니다.

  • 성능 및 가성비 향상

  • 민첩성 증가 및 가치 창출 시간 단축

  • 더 빠른 서버 배포 및 애플리케이션 개발.

  • 탄력적 확장성 - 실제로 사용한 만큼만 지불합니다.

  • 보안/규정 준수 향상

  • 스토리지 및 재해 복구 비용 절감.

  • 전체 TCO 감소, 보다 철저한 비용 관리, OPEX(운영 지출) 간소화

이러한 이점을 최대화하려면 신규 또는 기존 데이터 및 애플리케이션을 Azure Synapse 플랫폼으로 마이그레이션하세요. 많은 조직에서 마이그레이션에는 레거시 데이터 웨어하우스를 Teradata와 같은 레거시 온-프레미스 플랫폼에서 Azure Synapse로 이동하는 작업이 포함됩니다. 상위 수준에서 마이그레이션 프로세스에는 다음 단계가 포함됩니다.

    준비 🡆

  • 범위 정의 - 마이그레이션 대상.

  • 마이그레이션을 위한 데이터 및 프로세스 인벤토리를 빌드합니다.

  • 데이터 모델 변경 내용을 정의합니다(있는 경우).

  • 원본 데이터 추출 메커니즘을 정의합니다.

  • 사용할 적절한 Azure 및 타사 도구와 기능을 식별합니다.

  • 새 플랫폼에서 초기에 담당자를 학습합니다.

  • Azure 대상 플랫폼을 설정합니다.

    마이그레이션 🡆

  • 작고 간단하게 시작합니다.

  • 가능한 모든 곳에서 자동화합니다.

  • Azure 기본 제공 도구 및 기능을 활용하여 마이그레이션 활동을 줄입니다.

  • 테이블 및 보기에 대한 메타데이터를 마이그레이션합니다.

  • 유지 관리할 기록 데이터를 마이그레이션합니다.

  • 저장 프로시저 및 업무 프로세스를 마이그레이션하거나 리팩터링합니다.

  • ETL/ELT 증분 로드 프로세스를 마이그레이션하거나 리팩터링합니다.

    마이그레이션 후

  • 프로세스의 모든 단계를 모니터링하고 문서화합니다.

  • 얻은 환경을 사용하여 향후 마이그레이션을 위한 템플릿을 빌드합니다.

  • 필요한 경우 데이터 모델을 다시 설계합니다(새로운 플랫폼 성능 및 확장성 사용).

  • 애플리케이션 및 쿼리 도구를 테스트합니다.

  • 쿼리 성능을 벤치마킹하고 최적화합니다.

이 문서에서는 기존 Netezza 환경에서 Azure Synapse로 데이터 웨어하우스를 마이그레이션할 때 성능 최적화를 위한 일반 정보 및 지침을 제공합니다. 성능 최적화의 목표는 스키마 마이그레이션 후 Azure Synapse에서 동일하거나 더 나은 데이터 웨어하우스 성능을 달성하는 것입니다.

디자인 고려 사항

마이그레이션 범위

Teradata 환경에서 마이그레이션을 준비할 때 다음 마이그레이션 선택 사항을 고려합니다.

초기 마이그레이션을 위한 워크로드 선택

일반적으로 레거시 Teradata 환경은 시간이 지남에 따라 여러 주제 영역과 혼합 워크로드를 포괄하도록 발전했습니다. 마이그레이션 프로젝트를 시작할 위치를 결정할 때 다음을 수행할 수 있는 영역을 선택합니다.

  • 새로운 환경의 이점을 신속하게 제공하여 Azure Synapse로의 마이그레이션 가능성을 입증합니다.

  • 사내 기술 담당자가 다른 영역을 마이그레이션할 때 사용할 프로세스 및 도구에 대한 관련 환경을 얻을 수 있습니다.

  • 원본 Teradata 환경과 이미 있는 현재 도구 및 프로세스와 관련된 추가 마이그레이션을 위한 템플릿을 만듭니다.

Teradata 환경에서 초기 마이그레이션에 적합한 후보는 앞의 항목을 지원하며 다음과 같습니다.

  • OLTP(온라인 트랜잭션 처리) 워크로드가 아닌 BI/Analytics 워크로드를 구현합니다.

  • 최소한의 수정으로 마이그레이션할 수 있는 별모양 또는 눈송이 스키마와 같은 데이터 모델이 있습니다.

마이그레이션해야 하는 개체의 인벤토리를 만들고 마이그레이션 프로세스를 문서화합니다.

초기 마이그레이션에서 마이그레이션된 데이터의 양은 Azure Synapse 환경의 기능과 이점을 보여 주기에 충분히 커야 하지만 가치를 빠르게 보여 주기에는 너무 크지 않아야 합니다. 1-10TB 범위의 크기가 일반적입니다.

초기 마이그레이션 프로젝트의 경우 위험, 활동 및 마이그레이션 시간을 최소화하여 Azure 클라우드 환경의 이점을 빠르게 확인하고 마이그레이션 범위를 Teradata 웨어하우스의 OLAP DB 부분과 같은 데이터 마트로만 제한합니다. . 리프트 앤 시프트 및 단계적 마이그레이션 방법은 모두 초기 마이그레이션 범위를 데이터 마트로만 제한하고 ETL 마이그레이션 및 기록 데이터 마이그레이션과 같은 광범위한 마이그레이션 측면을 다루지 않습니다. 그러나 마이그레이션된 데이터 마트 계층이 데이터와 필요한 빌드 프로세스로 채워지면 프로젝트의 이후 단계에서 이러한 측면을 해결할 수 있습니다.

리프트 앤 시프트 마이그레이션 대 단계적 방법

일반적으로 계획된 마이그레이션의 목적과 범위에 관계없이 두 가지 형식의 마이그레이션이 있습니다. 즉, 있는 그대로의 리프트 앤 시프트와 변경 내용을 통합하는 단계적 방법입니다.

리프트 앤 시프트

리프트 앤 시프트 마이그레이션에서는 별모양 스키마와 같은 기존 데이터 모델이 변경되지 않고 새 Azure Synapse 플랫폼으로 마이그레이션됩니다. 이 방법은 Azure 클라우드 환경으로 이동하는 이점을 실현하는 데 필요한 작업을 줄여 위험과 마이그레이션 시간을 최소화합니다. 리프트 앤 시프트 마이그레이션은 다음 시나리오에 적합합니다.

  • 마이그레이션할 단일 데이터 마트가 있는 기존 Teradata 환경이 있거나
  • 이미 잘 설계된 별모양 또는 눈송이 스키마에 있는 데이터가 있는 기존 Teradata 환경이 있습니다.
  • 최신 클라우드 환경으로 전환해야 하는 시간과 비용의 압박을 받고 있습니다.

후속 단계에서 데이터 모델 변경을 구현하더라도 리프트 앤 시프트는 좋은 시작점입니다.

변화를 통합하는 단계적 접근

레거시 데이터 웨어하우스가 오랜 기간 동안 발전한 경우 필요한 성능 수준을 유지하기 위해 이를 다시 설계해야 할 수 있습니다. 또한 IoT(사물 인터넷) 스트림과 같은 새로운 데이터를 지원하기 위해 다시 엔지니어링해야 할 수도 있습니다. 재설계 프로세스의 일부로 Azure Synapse로 마이그레이션하면 확장성 있는 클라우드 환경의 이점을 얻게 됩니다. 마이그레이션에는 Inmon 모델에서 데이터 자격 증명 모음으로의 이동과 같은 기본 데이터 모델의 변경도 포함될 수 있습니다.

Microsoft는 기존 데이터 모델을 있는 그대로 Azure로 이동하고(선택적으로 Azure에서 VM Teradata 인스턴스 사용) Azure 환경의 성능과 유연성을 사용하여 리엔지니어링 변경 내용을 적용하는 것이 좋습니다. 이렇게 하면 Azure의 기능을 사용하여 기존 원본 시스템에 영향을 주지 않고 변경할 수 있습니다.

마이그레이션의 일부로 Azure VM Teradata 인스턴스 사용

온-프레미스 Teradata 환경에서 마이그레이션할 때 Azure의 클라우드 스토리지와 탄력적인 확장성을 활용하여 VM 내에 Teradata 인스턴스를 만들 수 있습니다. 이 방법은 Teradata 인스턴스를 대상 Azure Synapse 환경과 함께 배치합니다. Teradata Parallel Data Transporter와 같은 표준 Teradata 유틸리티를 사용하여 마이그레이션 중인 Teradata 테이블의 하위 집합을 VM 인스턴스로 효율적으로 이동할 수 있습니다. 그런 다음 Azure 환경 내에서 모든 추가 마이그레이션 작업을 수행할 수 있습니다. 이 접근 방식에는 몇 가지 이점이 있습니다.

  • 데이터의 초기 복제 후 원본 시스템은 다른 마이그레이션 작업의 영향을 받지 않습니다.

  • Azure 환경 내에서 친숙한 Teradata 인터페이스, 도구 및 유틸리티를 사용할 수 있습니다.

  • Azure 환경은 온-프레미스 원본 시스템과 클라우드 대상 시스템 간의 네트워크 대역폭 가용성과 관련된 잠재적인 문제를 회피합니다.

  • Azure Data Factory와 같은 도구는 Teradata Parallel Transporter와 같은 유틸리티를 호출하여 데이터를 효율적이고 빠르게 마이그레이션할 수 있습니다.

  • Azure 환경 내에서 마이그레이션 프로세스를 완전히 오케스트레이션하고 제어할 수 있습니다.

Azure VM을 사용하여 임시 Teradata 인스턴스를 만들어 마이그레이션 속도를 높이고 원본 시스템에 미치는 영향을 최소화하세요.

Azure Data Factory를 사용하여 메타데이터 기반 마이그레이션 구현

Azure 환경의 기능을 사용하여 마이그레이션 프로세스를 자동화하고 오케스트레이션할 수 있습니다. 이 방법은 이미 거의 용량에 가깝게 실행되고 있는 기존 Netezza 환경의 성능 저하를 최소화합니다.

Azure Data Factory는 데이터 이동 및 데이터 변환을 조정하고 자동화하는 클라우드에서 데이터 기반 워크플로 만들기를 지원하는 클라우드 기반 데이터 통합 서비스입니다. Data Factory를 사용하여 서로 다른 데이터 저장소에서 데이터를 수집하는 데이터 기반 워크플로(파이프라인)를 만들고 예약할 수 있습니다. Data Factory는 Azure HDInsight Hadoop, Spark, Azure Data Lake Analytics 및 Azure Machine Learning과 같은 컴퓨팅 서비스를 사용하여 데이터를 처리하고 변환할 수 있습니다.

Data Factory 기능을 사용하여 마이그레이션 프로세스를 관리하려는 경우 마이그레이션할 모든 데이터 테이블과 해당 위치를 나열하는 메타데이터를 만듭니다.

Teradata와 Azure Synapse의 디자인 차이점

앞서 언급했듯이 Teradata와 Azure Synapse Analytics 데이터베이스 간의 방법에는 몇 가지 기본적인 차이점이 있으며 이러한 차이점에 대해서는 다음에 설명합니다.

여러 데이터베이스와 단일 데이터베이스 및 스키마

Teradata 환경에는 여러 개의 개별 데이터베이스가 포함되어 있는 경우가 많습니다. 예를 들어, 데이터 수집 및 준비 테이블, 코어 웨어하우스 테이블, 데이터 마트(의미 체계 계층이라고도 함)를 위한 별도의 데이터베이스가 있을 수 있습니다. ETL 또는 ELT 파이프라인 프로세스는 데이터베이스 간 조인을 구현하고 별도의 데이터베이스 간에 데이터를 이동할 수 있습니다.

대조적으로 Azure Synapse 환경은 단일 데이터베이스를 포함하고 스키마를 사용하여 테이블을 논리적으로 별도의 그룹으로 분리합니다. 대상 Azure Synapse 데이터베이스 내에서 일련의 스키마를 사용하여 Teradata 환경에서 마이그레이션된 별도의 데이터베이스를 모방하는 것이 좋습니다. Teradata 환경에서 이미 스키마를 사용하는 경우 기존 Teradata 테이블과 보기를 새 환경으로 이동할 때 새 명명 규칙을 사용해야 할 수 있습니다. 예를 들어 기존 Teradata 스키마와 테이블 이름을 새 Azure Synapse 테이블 이름에 연결하고, 새 환경에서 스키마 이름을 사용하여 원래의 별도 데이터베이스 이름을 유지할 수 있습니다. 스키마 통합 이름에 점이 있는 경우 Azure Synapse Spark에 문제가 있을 수 있습니다. 기본 테이블 위에 SQL 보기를 사용하여 논리 구조를 유지할 수 있지만 해당 방법에는 잠재적인 단점이 있습니다.

  • Azure Synapse의 보기는 읽기 전용이므로 데이터에 대한 모든 업데이트가 기본 테이블에서 수행되어야 합니다.

  • 이미 하나 이상의 보기 계층이 존재할 수 있으며 중첩된 보기는 문제를 해결하기 어렵기 때문에 보기 계층을 추가하면 성능과 지원 가능성에 영향을 미칠 수 있습니다.

Azure Synapse 내에서 여러 데이터베이스를 단일 데이터베이스로 결합하고 스키마 이름을 사용하여 테이블을 논리적으로 분리합니다.

테이블 고려 사항

서로 다른 환경 간에 테이블을 마이그레이션할 때 일반적으로 원시 데이터와 이를 설명하는 메타데이터만 실제로 마이그레이션됩니다. 인덱스와 같은 원본 시스템의 다른 데이터베이스 요소는 일반적으로 새 환경에서 불필요하거나 다르게 구현될 수 있으므로 마이그레이션되지 않습니다. 인덱스와 같은 원본 환경의 성능 최적화는 새 환경에서 성능 최적화를 추가할 수 있는 위치를 나타냅니다. 예를 들어 원본 Teradata 환경 내의 테이블에 NUSI(고유하지 않은 보조 인덱스)가 있는 경우 Azure Synapse 내에서 클러스터되지 않은 인덱스를 만들어야 함을 나타냅니다. 테이블 복제와 같은 다른 네이티브 성능 최적화 기술은 유사 인덱스를 만드는 것보다 더 적합할 수 있습니다.

기존 인덱스는 마이그레이션된 웨어하우스의 인덱싱 후보를 나타냅니다.

데이터베이스의 고가용성

Teradata는 지정된 노드에 실제로 상주하는 테이블 행을 시스템 내의 다른 노드로 복제하는 FALLBACK 옵션을 통해 노드 간 데이터 복제를 지원합니다. 이 방법은 노드에서 문제가 발생하더라도 데이터가 손실되지 않도록 보장하며 장애 조치(failover) 시나리오의 기반을 제공합니다.

Azure Synapse Analytics에서 고가용성 아키텍처의 목표는 유지 관리 작업 및 중단의 영향에 대해 걱정하지 않고 데이터베이스가 99.9%의 시간 동안 실행되도록 보장하는 것입니다. SLA에 대한 자세한 내용은 Azure Synapse Analytics에 대한 SLA를 참조하세요. Azure는 패치, 백업, Windows 및 SQL 업그레이드와 같은 중요한 서비스 작업을 자동으로 처리합니다. 또한 Azure는 기본 하드웨어, 소프트웨어 또는 네트워크의 오류와 같은 계획되지 않은 이벤트를 자동으로 처리합니다.

Azure Synapse의 데이터 스토리지는 스냅샷으로 자동 백업됩니다. 이러한 스냅샷은 복원 지점을 만드는 서비스의 기본 제공 기능입니다. 이 기능은 사용하도록 설정할 필요가 없습니다. 사용자는 현재 서비스에서 복구를 위한 SLA(서비스 수준 계약)를 유지 관리하는 데 사용하는 자동 복원 지점을 삭제할 수 없습니다.

Azure Synapse Dedicated SQL 풀은 하루 종일 데이터 웨어하우스의 스냅샷을 만들어서 7일 동안 사용할 수 있는 복원 지점을 만듭니다. 이 보존 기간은 변경할 수 없습니다. Azure Synapse는 8시간 RPO(복구 지점 목표)를 지원합니다. 지난 7일 동안 만들어진 모든 스냅샷 중 하나에서 주 지역의 데이터 웨어하우스를 복원할 수 있습니다. 보다 세분화된 백업이 필요한 경우 다른 사용자 정의 옵션을 사용할 수 있습니다.

지원되지 않는 Teradata 테이블 유형

Teradata는 시계열 및 임시 데이터에 대한 특수 테이블 유형을 지원합니다. 이러한 테이블 형식에 대한 구문 및 일부 함수는 Azure Synapse에서 직접 지원되지 않습니다. 그러나 적절한 데이터 형식에 매핑하고 날짜/시간 열을 인덱싱하거나 분할하여 데이터를 Azure Synapse의 표준 테이블로 마이그레이션할 수 있습니다.

Azure Synapse의 표준 테이블은 마이그레이션된 Teradata 시계열 및 임시 데이터를 지원할 수 있습니다.

Teradata는 쿼리 재작성을 사용하여 임시 쿼리 내에 필터를 추가하여 적용 가능한 날짜 범위를 제한함으로써 임시 쿼리 기능을 구현합니다. 원본 Teradata 환경에서 이 기능을 마이그레이션할 계획이라면 관련 임시 쿼리에 추가 필터링을 추가합니다.

Azure 환경은 대규모 시계열 데이터에 대한 복잡한 분석을 위한 시계열 인사이트를 지원합니다. 이 기능은 IoT 데이터 분석 애플리케이션을 대상으로 합니다.

SQL DML 구문 차이점

Teradata SQL과 Azure Synapse T-SQL 간에 SQL DML(데이터 조작 언어) 구문 차이가 있습니다.

  • QUALIFY: Teradata는 QUALIFY 연산자를 지원합니다. 예시:

    SELECT col1
    FROM tab1
    WHERE col1='XYZ'
    QUALIFY ROW_NUMBER () OVER (PARTITION by
    col1 ORDER BY col1) = 1;
    

    상응하는 Azure Synapse 구문은 다음과 같습니다.

    SELECT * FROM (
    SELECT col1, ROW_NUMBER () OVER (PARTITION by col1 ORDER BY col1) rn
    FROM tab1 WHERE col1='XYZ'
    ) WHERE rn = 1;
    
  • 날짜 산술: Azure Synapse에는 DATEADDDATEDIFF처럼 DATE 또는 DATETIME 필드에서 사용할 수 있는 연산자가 있습니다. Teradata는 SELECT DATE1 - DATE2 FROM...처럼 날짜에서 직접 빼기를 지원합니다.

  • GROUP BY: GROUP BY 서수의 경우 T-SQL 열 이름을 명시적으로 제공합니다.

  • LIKE ANY: Teradata는 다음과 같은 LIKE ANY 구문을 지원합니다.

    SELECT * FROM CUSTOMER
    WHERE POSTCODE LIKE ANY
    ('CV1%', 'CV2%', 'CV3%');
    

    Azure Synapse 구문의 해당 구문은 다음과 같습니다.

    SELECT * FROM CUSTOMER
    WHERE
    (POSTCODE LIKE 'CV1%') OR (POSTCODE LIKE 'CV2%') OR (POSTCODE LIKE 'CV3%');
    
  • 시스템 설정에 따라 Teradata의 문자 비교는 기본적으로 대/소문자를 구분하지 않을 수 있습니다. Azure Synapse에서 문자 비교는 항상 대/소문자를 구분합니다.

함수, 저장 프로시저, 트리거 및 시퀀스

Teradata와 같은 성숙한 환경에서 데이터 웨어하우스를 마이그레이션할 때 간단한 테이블 및 뷰 이외의 요소를 마이그레이션해야 할 수도 있습니다. 함수, 저장 프로시저, 트리거 및 시퀀스를 예로 들 수 있습니다. 일반적으로 기본 제공 Azure 도구를 사용하는 것이 Azure Synapse용으로 해당 요소를 다시 코딩하는 것보다 더 효율적이므로 Azure 환경 내의 도구가 기능, 저장 프로시저 및 시퀀스의 기능을 바꿀 수 있는지 확인합니다.

준비 단계의 일부로 마이그레이션해야 하는 개체의 인벤토리를 만들고, 개체를 처리하는 방법을 정의하고, 마이그레이션 계획에 적절한 리소스를 할당합니다.

데이터 통합 파트너는 함수, 저장 프로시저 및 시퀀스의 마이그레이션을 자동화할 수 있는 도구와 서비스를 제공합니다.

다음 섹션에서는 함수, 저장 프로시저 및 시퀀스의 마이그레이션에 대해 자세히 설명합니다.

함수

대부분의 데이터베이스 제품과 마찬가지로 Teradata는 SQL 구현 내에서 시스템 및 사용자 정의 함수를 지원합니다. 레거시 데이터베이스 플랫폼을 Azure Synapse로 마이그레이션할 때 일반적인 시스템 함수는 일반적으로 변경 없이 마이그레이션될 수 있습니다. 일부 시스템 함수는 구문이 약간 다를 수 있지만 필요한 변경 내용은 자동화할 수 있습니다.

Azure Synapse에 동등한 함수가 없는 Teradata 시스템 함수 또는 임의의 사용자 정의 함수의 경우 대상 환경 언어를 사용하여 해당 함수를 다시 코딩합니다. Azure Synapse는 Transact-SQL 언어를 사용하여 사용자 정의 함수를 구현합니다.

저장 프로시저

대부분의 최신 데이터베이스 제품은 데이터베이스 내 저장 프로시저를 지원합니다. Teradata는 이 용도로 SPL 언어를 제공합니다. 저장 프로시저는 일반적으로 SQL 문과 프로시저 논리를 모두 포함하며 데이터 또는 상태를 반환합니다.

Azure Synapse는 T-SQL을 사용하는 저장 프로시저를 지원하므로 마이그레이션된 저장 프로시저를 해당 언어로 다시 코딩해야 합니다.

트리거

Azure Synapse는 트리거 만들기를 지원하지 않지만, Azure Data Factory를 사용하여 트리거 만들기를 구현할 수 있습니다.

시퀀스

Azure Synapse는 Teradata와 유사한 방식으로 시퀀스를 처리하며, 시리즈에서 다음 시퀀스 번호를 생성하는 SQL 코드 또는 IDENTITY 열을 사용하여 시퀀스를 구현할 수 있습니다. 시퀀스는 기본 키의 서로게이트 키 값으로 사용할 수 있는 고유한 숫자 값을 제공합니다.

Teradata 환경에서 메타데이터 및 데이터 추출

DDL(데이터 정의 언어) 생성

ANSI SQL 표준은 DDL(데이터 정의 언어) 명령의 기본 구문을 정의합니다. CREATE TABLECREATE VIEW와 같은 일부 DDL 명령은 Teradata와 Azure Synapse 모두에 공통적이지만 인덱싱, 테이블 배포 및 분할 옵션과 같은 구현별 기능도 제공합니다.

기존 Teradata CREATE TABLECREATE VIEW 스크립트를 편집하여 Azure Synapse에서 동등한 정의를 얻을 수 있습니다. 이렇게 하려면 수정된 데이터 형식을 사용하고 FALLBACK과 같은 Teradata 관련 절을 제거하거나 수정해야 할 수 있습니다.

그러나 기존 Teradata 환경 내에서 테이블 및 보기의 현재 정의를 지정하는 모든 정보는 시스템 카탈로그 테이블 내에서 유지 관리됩니다. 이러한 테이블은 최신 상태이고 완전하다는 보장이 있으므로 이 정보의 가장 좋은 소스입니다. 사용자 유지 설명서가 현재 테이블 정의와 동기화되지 않을 수 있습니다.

Teradata 환경 내에서 시스템 카탈로그 테이블은 현재 테이블과 뷰 정의를 지정합니다. 사용자가 관리하는 설명서와 달리 시스템 카탈로그 정보는 항상 완전하며 현재 테이블 정의와 동기화됩니다. DBC.ColumnsV와 같은 카탈로그 보기를 사용하면 시스템 카탈로그 정보에 액세스하여 Azure Synapse에서 동등한 테이블을 만드는 CREATE TABLE DDL 문을 만들 수 있습니다.

기존 Teradata 메타데이터를 사용하여 Azure Synapse의 CREATE TABLECREATE VIEW DDL 생성을 자동화합니다.

유사한 결과를 가져오기 위해 시스템 카탈로그 정보를 처리하는 타사 마이그레이션 및 ETL 도구를 사용할 수도 있습니다.

Teradata에서 데이터 추출

BTEQ(Basic Teradata Query), Teradata FastExport 또는 TPT(Teradata Parallel Transporter)와 같은 표준 Teradata 유틸리티를 사용하여 Teradata 테이블에서 CSV 파일과 같이 단순하게 구분된 파일로 원시 테이블 데이터를 추출할 수 있습니다. TPT를 사용하여 가능한 한 효율적으로 테이블 데이터를 추출합니다. TPT는 여러 병렬 FastExport 스트림을 사용하여 최고의 처리량을 달성합니다.

가장 효율적인 데이터 추출을 위해 Teradata Parallel Transporter를 사용합니다.

Azure Data Factory에서 직접 TPT를 호출합니다. 이는 Azure 환경에서 Teradata 온-프레미스 인스턴스 및 VM 내에서 실행되는 Teradata 인스턴스의 데이터 마이그레이션에 권장되는 방법입니다.

추출된 데이터 파일에는 CSV, ORC(Optimized Row Columnar) 또는 Parquet 형식으로 구분된 텍스트가 포함되어야 합니다.

Teradata 환경에서 데이터 및 ETL을 마이그레이션하는 방법에 대한 자세한 내용은 Teradata 마이그레이션을 위한 데이터 마이그레이션, ETL 및 로드를 참조하세요.

Teradata 마이그레이션의 성능 권장 사항

성능 최적화의 목표는 Azure Synapse로 마이그레이션한 후 동일하거나 더 나은 데이터 웨어하우스 성능입니다.

마이그레이션 시작 시 Azure Synapse의 튜닝 옵션에 대해 우선적으로 숙지합니다.

성능 튜닝 방법의 차이점

이 섹션에서는 Teradata와 Azure Synapse 간의 낮은 수준의 성능 튜닝 구현 차이점을 강조합니다.

데이터 배포 옵션

성능을 위해 Azure Synapse는 다중 노드 아키텍처로 설계되었으며 병렬 처리를 사용합니다. Azure Synapse에서 개별 테이블 성능을 최적화하기 위해 DISTRIBUTION 문을 사용하여 CREATE TABLE 문에서 데이터 배포 옵션을 정의할 수 있습니다. 예를 들어, 결정적 해시 함수를 사용하여 컴퓨팅 노드에 테이블 행을 분산하는 해시 분산 테이블을 지정할 수 있습니다. 목표는 쿼리를 실행할 때 처리 노드 간에 이동되는 데이터의 양을 줄이는 것입니다.

대형 테이블 간 조인의 경우 해시는 한 테이블을 또는 두 테이블을 모두(이상적) 조인 열 중 하나에 분산하며, 조인 열은 데이터를 균등하게 분포할 수 있도록 값의 범위가 넓습니다. 조인할 데이터 행이 동일한 처리 노드에 배치되므로 조인 처리를 로컬로 수행합니다.

Azure Synapse는 작은 테이블 복제를 통해 작은 테이블과 큰 테이블 간의 로컬 조인도 지원합니다. 예를 들어, 별모양 스키마 모델 내의 작은 차원 테이블과 큰 사실 테이블을 고려합니다. Azure Synapse는 모든 노드에서 더 작은 차원 테이블을 복제하여 큰 테이블의 모든 조인 키 값에 일치하는 로컬에서 사용 가능한 차원 행이 있는지 확인할 수 있습니다. 차원 테이블 복제의 오버헤드는 작은 차원 테이블에 대해 상대적으로 낮습니다. 큰 차원 테이블의 경우 해시 분포 방법이 더 적합합니다. 데이터 배포 옵션에 대한 자세한 내용은 복제 테이블 사용을 위한 디자인 지침분산 테이블 디자인 지침을 참조하세요.

데이터 인덱싱

Azure Synapse는 Teradata에서 구현된 인덱싱 옵션과 다른 여러 사용자 정의 가능한 인덱싱 옵션을 지원합니다. Azure Synapse의 다양한 인덱싱 옵션에 대한 자세한 내용은 전용 SQL 풀 테이블의 인덱스를 참조하세요.

원본 Teradata 환경 내의 기존 인덱스는 Azure Synapse 환경에서 인덱싱을 위한 후보 열 및 데이터 사용량에 대한 유용한 표시를 제공합니다.

데이터 분할

엔터프라이즈 데이터 웨어하우스에서 팩트 테이블에는 수십억 개의 행이 포함될 수 있습니다. 분할은 이러한 테이블을 별도의 부분으로 분할하여 처리된 데이터의 양을 줄여 유지 관리 및 쿼리 성능을 최적화합니다. Azure Synapse에서 CREATE TABLE 문은 테이블에 대한 분할 사양을 정의합니다. 매우 큰 테이블만 파티션하고 각 파티션에 최소 6천만 개의 행이 포함되어 있는지 확인합니다.

분할에는 테이블당 하나의 필드만 사용할 수 있습니다. 많은 쿼리가 날짜 또는 날짜 범위로 필터링되기 때문에 해당 필드는 날짜 필드인 경우가 많습니다. CTAS(CREATE TABLE AS) 문을 사용하여 새 배포로 테이블을 다시 만들어 초기 로드 후 테이블의 분할을 변경할 수 있습니다. Azure Synapse의 분할에 대한 자세한 내용은 전용 SQL 풀에서 테이블 분할을 참조하세요.

데이터 테이블 통계

ETL/ELT 작업에 대한 통계 단계를 작성하여 데이터 테이블에 대한 통계를 최신 상태로 유지해야 합니다.

데이터 로드를 위한 PolyBase 또는 COPY INTO

PolyBase는 병렬 로드 스트림을 사용하여 데이터 웨어하우스에 대용량 데이터를 효율적으로 로드할 수 있도록 지원합니다. 자세한 내용은 PolyBase 데이터 로드 전략을 참조하세요.

COPY INTO는 또한 처리량이 많은 데이터 수집을 지원하며 다음을 수행합니다.

  • 폴더 및 하위 폴더 내의 모든 파일에서 데이터 검색.

  • 동일한 스토리지 계정의 여러 위치에서 데이터 검색. 쉼표로 구분된 경로를 사용하여 여러 위치를 지정할 수 있습니다.

  • Azure Data Lake Storage(ADLS) 및 Azure Blob Storage.

  • CSV, PARQUET 및 ORC 파일 형식.

워크로드 관리

혼합된 워크로드를 실행하면 사용량이 많은 시스템에서 리소스 문제가 발생할 수 있습니다. 성공적인 워크로드 관리 체계는 리소스를 효과적으로 관리하고, 매우 효율적인 리소스 사용률을 보장하며, ROI(투자 수익률)를 극대화합니다. 워크로드 분류, 워크로드 중요도워크로드 격리를 통해 워크로드가 시스템 리소스를 활용하는 방법을 더 잘 제어할 수 있습니다.

워크로드 관리 가이드에서는 워크로드를 분석하고 워크로드 중요도를 관리 및 모니터링하는 기술 및 리소스 클래스를 작업 그룹으로 변환하는 단계를 설명합니다. Azure PortalDMV의 T-SQL 쿼리를 사용하여 해당 리소스가 효율적으로 활용되도록 워크로드를 모니터링합니다.

다음 단계

Teradata 마이그레이션에 대한 ETL 및 로드에 대한 자세한 내용은 이 시리즈의 다음 문서인 Teradata 마이그레이션을 위한 데이터 마이그레이션, ETL, 로드를 참조하세요.