Teradata 마이그레이션에 대한 SQL 문제 최소화

이 문서는 Teradata에서 Azure Synapse Analytics로 마이그레이션하는 방법에 대한 지침을 제공하는 7부작 시리즈 중 5부입니다. 이 문서는 SQL 문제를 최소화하기 위한 모범 사례에 중점을 두고 있습니다.

개요

Teradata 환경의 특징

1984년에 Teradata는 처음으로 데이터베이스 제품을 출시했습니다. MPP(대규모 병렬 처리) 기술을 도입하여 당시 사용 가능했던 기존 메인프레임 기술보다 더 효율적으로 대규모 데이터를 처리할 수 있도록 했습니다. 그 후로 제품은 진화했으며 대규모 금융 기관, 통신 회사 및 소매 회사에 많이 설치되었습니다. 원래 구현은 독점 하드웨어를 사용했으며 메인프레임(일반적으로 IBM 또는 IBM 호환 프로세서)에 연결된 채널이었습니다.

최신 공지 사항에는 네트워크 연결 및 클라우드에서 Teradata 기술 스택(Azure 포함)의 사용 가능성이 포함되어 있지만, 대부분의 기존 설치는 온-프레미스에 있으므로 많은 사용자가 최신 클라우드 환경으로 이동하여 이점을 얻기 위해 Teradata 데이터의 일부 또는 전부를 Azure Synapse Analytics로 마이그레이션하는 것을 고려하고 있습니다.

Teradata 기술은 데이터 웨어하우스를 구현하는 데 자주 사용되며, SQL을 사용하여 대규모 데이터 볼륨에 대한 복잡한 분석 쿼리를 지원합니다. 별모양 또는 눈송이 스키마와 같은 차원 데이터 모델이 일반적이며, 개별 부서에 대한 데이터 마트의 구현도 일반적입니다.

이러한 SQL 및 차원 데이터 모델의 조합은 기본 개념과 SQL 기술을 전송할 수 있으므로 Azure Synapse로의 마이그레이션을 간소화합니다. 권장되는 방법은 기존 데이터 모델을 있는 그대로 마이그레이션하여 위험 및 소요 시간을 줄이는 것입니다. 데이터 모델 변경(예: 데이터 자격 증명 모음 모델로 이동)이 궁극적인 목적인 경우에도 초기에 있는 그대로 마이그레이션을 수행한 다음, Azure 클라우드 환경 내에서 변경 작업을 수행하여 성능, 탄력적 확장성 및 비용 이점을 활용합니다.

SQL 언어는 표준화되었지만 독점 확장을 구현한 개별 공급업체도 있습니다. 이 문서에서는 레거시 Teradata 환경에서 마이그레이션하는 동안 발생할 수 있는 잠재적인 SQL 차이점을 중점적으로 설명하고 해결 방법을 제시합니다.

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

온-프레미스 Teradata 환경에서 마이그레이션을 실행할 때 Azure 환경을 활용합니다. Azure는 Azure의 VM 내에 Teradata 인스턴스를 만들고 대상 Azure Synapse 환경과 함께 배치할 수 있는 경제적인 클라우드 스토리지와 탄력적 확장성을 제공합니다.

이 방법을 통해 Teradata Parallel Data Transporter와 같은 표준 Teradata 유틸리티 또는 Attunity Replicate와 같은 타사 데이터 복제 도구를 사용하여 VM 인스턴스로 마이그레이션해야 하는 Teradata 테이블의 하위 집합을 효율적으로 이동시킬 수 있으며, 모든 마이그레이션 작업이 Azure 환경 내에서 수행될 수 있습니다. 이 접근 방식에는 몇 가지 이점이 있습니다.

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

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

• Azure 환경에서는 온-프레미스 원본 시스템과 클라우드 대상 시스템 간의 네트워크 대역폭 가용성에 대한 잠재적인 문제가 없습니다.

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

• 마이그레이션 프로세스는 Azure 환경 내에서 완전히 조정되고 제어됩니다.

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

Azure 환경의 기능을 사용하여 마이그레이션 프로세스를 자동화하고 오케스트레이션합니다. 또한 이 방법은 이미 전체 용량에 가깝게 실행되고 있을 수 있는 기존 Teradata 환경에 마이그레이션이 미치는 영향을 최소화합니다.

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

마이그레이션할 데이터 테이블과 해당 위치를 나열하는 메타데이터를 만들면 Data Factory 기능을 사용하여 마이그레이션 프로세스의 일부를 관리하고 자동화할 수 있습니다. Azure Synapse Pipelines를 사용할 수도 있습니다.

Teradata와 Azure Synapse의 SQL DDL 차이점

SQL DDL(데이터 정의 언어)

ANSI SQL 표준은 CREATE TABLE 및 CREATE VIEW 같은 DDL 명령에 대한 기본 구문을 정의합니다. 이러한 명령은 Teradata 및 Azure Synapse 둘 다에서 사용될 뿐만 아니라 인덱싱, 테이블 배포, 분할 옵션과 같은 구현 관련 기능의 정의를 허용하도록 확장되었습니다.

다음 섹션에서는 Azure Synapse로 마이그레이션하는 동안 고려해야 할 Teradata 관련 옵션에 대해 설명합니다.

테이블 고려 사항

서로 다른 기술 간에 테이블을 마이그레이션하는 경우 두 환경 간에 원시 데이터와 설명 메타데이터만 실제로 이동합니다. 원본 시스템의 다른 데이터베이스 요소(예: 인덱스 및 로그 파일)는 필요하지 않거나 새 대상 환경 내에서 다르게 구현될 수 있으므로 직접 마이그레이션되지 않습니다. 예를 들어 Teradata의 CREATE TABLE 구문에는 MULTISET 옵션에 해당하는 옵션이 없습니다.

원본 환경에서 성능 최적화(예: 인덱스)가 사용된 위치를 이해하는 것이 중요합니다. 이는 새 대상 환경에서 성능 최적화를 추가할 수 있는 위치를 나타냅니다. 예를 들어 원본 Teradata 환경에서 NUSI(고유하지 않은 보조 인덱스)를 만든 경우 마이그레이션된 Azure Synapse 데이터베이스에서 비클러스터형 인덱스를 만들어야 한다는 의미일 수 있습니다. 직선적인 “동가” 인덱스 생성보다 테이블 복제와 같은 다른 네이티브 성능 최적화 기술이 더 적합할 수 있습니다.

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

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

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

Azure 환경에는 시계열 인사이트라는 대규모 시계열 데이터에 대한 복잡한 분석을 위한 특정 기능도 포함되어 있습니다. 이는 IoT 데이터 분석 애플리케이션을 대상으로 하며 이 사용 사례에 더 적합할 수 있습니다.

지원되지 않는 Teradata 데이터 형식

대부분의 Teradata 데이터 형식은 Azure Synapse에 직접 대응되는 형식이 있습니다. 다음 표에는 권장 매핑과 함께 Azure Synapse에서 지원되지 않는 Teradata 데이터 형식이 나와 있습니다. 테이블에서 Teradata 열 형식은 시스템 카탈로그(예: DBC.ColumnsV)에 저장된 형식입니다.

Teradata 카탈로그 테이블의 메타데이터를 사용하여 이러한 데이터 형식을 마이그레이션해야 하는지 결정하고, 마이그레이션 계획에서 이를 허용합니다. 예를 들어, 이와 같은 SQL 쿼리를 사용하여 해결해야 하는 주의가 필요한 지원되지 않는 데이터 형식의 발생을 찾을 수 있습니다.

SELECT
ColumnType, CASE
WHEN ColumnType = '++' THEN 'TD_ANYTYPE' 
WHEN ColumnType = 'A1' THEN 'ARRAY' WHEN 
ColumnType = 'AN' THEN 'ARRAY' WHEN 
ColumnType = 'BO' THEN 'BLOB'
WHEN ColumnType = 'CO' THEN 'CLOB'
WHEN ColumnType = 'DH' THEN 'INTERVAL DAY TO HOUR' WHEN 
ColumnType = 'DM' THEN 'INTERVAL DAY TO MINUTE' WHEN 
ColumnType = 'DS' THEN 'INTERVAL DAY TO SECOND' WHEN
ColumnType = 'DT' THEN 'DATASET'
WHEN ColumnType = 'DY' THEN 'INTERVAL DAY'
WHEN ColumnType = 'HM' THEN 'INTERVAL HOUR TO MINUTE' WHEN
ColumnType = 'HR' THEN 'INTERVAL HOUR'
WHEN ColumnType = 'HS' THEN 'INTERVAL HOUR TO SECOND' WHEN
ColumnType = 'JN' THEN 'JSON'
WHEN ColumnType = 'MI' THEN 'INTERVAL MINUTE' WHEN 
ColumnType = 'MO' THEN 'INTERVAL MONTH'
WHEN ColumnType = 'MS' THEN 'INTERVAL MINUTE TO SECOND' WHEN
ColumnType = 'PD' THEN 'PERIOD(DATE)'
WHEN ColumnType = 'PM' THEN 'PERIOD (TIMESTAMP WITH TIME ZONE)'
WHEN ColumnType = 'PS' THEN 'PERIOD(TIMESTAMP)' WHEN 
ColumnType = 'PT' THEN 'PERIOD(TIME)'
WHEN ColumnType = 'PZ' THEN 'PERIOD (TIME WITH TIME ZONE)' WHEN
ColumnType = 'SC' THEN 'INTERVAL SECOND'
WHEN ColumnType = 'SZ' THEN 'TIMESTAMP WITH TIME ZONE' WHEN
ColumnType = 'XM' THEN 'XML'
WHEN ColumnType = 'YM' THEN 'INTERVAL YEAR TO MONTH' WHEN
ColumnType = 'YR' THEN 'INTERVAL YEAR'
END AS Data_Type,
COUNT (*) AS Data_Type_Count FROM
DBC.ColumnsV
WHERE DatabaseName IN ('UserDB1', 'UserDB2', 'UserDB3') -- select databases to be migrated
GROUP BY 1,2
ORDER BY 1;

데이터 형식 매핑을 포함하여 마이그레이션을 자동화하는 도구와 서비스를 제공하는 타사 공급업체가 있습니다. 또한 Informatica 또는 Talend와 같은 타사 ETL 도구를 Teradata 환경에서 이미 사용 중인 경우 필요한 모든 데이터 변환을 구현할 수 있습니다.

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

필요한 경우 앞에서 설명한 대로 수정된 데이터 형식으로 기존 Teradata CREATE TABLE 및 CREATE VIEW 스크립트를 편집하여 해당 정의를 만듭니다. 일반적으로 이 과정에서 FALLBACK 또는 MULTISET 같은 추가 Teradata 관련 절을 제거하는 작업이 수반됩니다.

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

카탈로그에 대한 뷰(예: DBC.ColumnsV_)를 통해 이 정보에 액세스하고 Azure Synapse에서 해당 테이블에 대한 해당 CREATE TABLE DDL 문을 생성합니다.

데이터 형식 매핑을 포함하여 마이그레이션을 자동화하는 도구와 서비스를 제공하는 Microsoft 파트너가 있습니다. 또한 Informatica 또는 Talend와 같은 타사 ETL 도구를 Teradata 환경에서 이미 사용 중인 경우 필요한 모든 데이터 변환을 구현할 수 있습니다.

Teradata와 Azure Synapse의 SQL DML 차이점

SQL DML(데이터 조작 언어)

ANSI SQL 표준은 SELECT, INSERT, UPDATE 및 DELETE 같은 DML 명령에 대한 기본 구문을 정의합니다. Teradata와 Azure Synapse 모두 이러한 명령을 사용하지만 구현에 차이가 있는 경우도 있습니다.

다음 섹션에서는 Azure Synapse로 마이그레이션하는 동안 고려해야 하는 Teradata 관련 DML 명령에 대해 설명합니다.

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에는 DATEADD 및 DATEDIFF처럼 DATE 또는 DATETIME 필드에서 사용할 수 있는 연산자가 있습니다. Teradata는 SELECT DATE1 - DATE2 FROM...처럼 날짜에서 직접 빼기를 지원합니다.

• 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에서 문자 비교는 항상 대/소문자를 구분합니다.

EXPLAIN을 사용하여 레거시 SQL 유효성 검사

레거시 Teradata SQL의 Azure Synapse와의 호환성을 테스트하는 한 가지 방법은 레거시 시스템 쿼리 로그에서 일부 대표적인 SQL 문을 캡처하고, EXPLAIN을 해당 쿼리의 접두사로 지정하고(동일한 테이블 및 열에 Azure Synapse의 “동가” 마이그레이션 데이터 모델 가정), Azure Synapse에서 해당 EXPLAIN 문을 실행하는 것입니다. 호환되지 않는 SQL은 오류를 throw합니다. 이 정보를 사용하여 재코딩 작업의 규모를 확인합니다. 이 방법을 사용하면 관련 테이블과 뷰만 생성되므로 데이터를 Azure 환경에 로드할 필요가 없습니다.

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

Teradata와 같은 성숙한 레거시 데이터 웨어하우스 환경에서 마이그레이션할 때 간단한 테이블 및 뷰 이외의 요소를 새 대상 환경으로 마이그레이션해야 하는 경우가 많습니다. 이에 대한 예로는 함수, 저장 프로시저, 트리거 및 시퀀스가 있습니다.

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

Teradata 환경의 함수 또는 저장 프로시저로 구현된 기능을 대체하는 기능이 Azure 환경에 있을 수 있습니다. 이 경우 Teradata 함수를 다시 코딩하는 대신 기본 제공 Azure 기능을 사용하는 것이 더 효율적인 경우가 많습니다.

Microsoft 파트너는 마이그레이션을 자동화할 수 있는 도구와 서비스를 제공합니다.

이러한 각 요소에 대한 자세한 내용은 다음 섹션을 참조하세요.

함수

대부분의 데이터베이스 제품과 마찬가지로 Teradata는 SQL 구현 내에서 시스템 함수 및 사용자 정의 함수를 지원합니다. Azure Synapse 같은 다른 데이터베이스 플랫폼으로 마이그레이션하는 경우 일반적인 시스템 함수를 사용할 수 있으며 변경 없이 마이그레이션할 수 있습니다. 일부 시스템 함수는 구문이 약간 다를 수 있지만 필요한 변경을 자동화할 수 있습니다. 임의의 사용자 정의 함수와 같이 상응하는 항목이 없는 시스템 함수는 대상 환경에서 사용할 수 있는 언어를 사용하여 다시 코딩해야 할 수 있습니다. Azure Synapse는 널리 사용되는 Transact-SQL 언어를 사용하여 사용자 정의 함수를 구현합니다.

저장 프로시저

대부분의 최신 데이터베이스 제품은 프로시저를 데이터베이스 내에 저장하도록 허용합니다. Teradata는 이 용도로 SPL 언어를 제공합니다. 저장 프로시저는 일반적으로 SQL 문과 일부 절차 논리를 포함하며 데이터 또는 상태를 반환할 수 있습니다.

Azure Synapse Analytics의 전용 SQL 풀은 T-SQL을 사용하는 저장 프로시저도 지원하므로 저장 프로시저를 마이그레이션해야 하는 경우 적절히 다시 코딩합니다.

트리거

Azure Synapse는 트리거 생성을 지원하지 않지만 Azure Data Factory 내에서 구현할 수 있습니다.

시퀀스

Azure Synapse 시퀀스는 Teradata와 마찬가지로 서로게이트 키를 만드는 IDENTITY 또는 관리 ID를 사용하여 처리됩니다.

Teradata와 T-SQL 매핑

이 표에서는 Azure Synapse SQL 데이터 형식을 준수하는 T-SQL과 Teradata의 매핑을 보여줍니다.

요약

일반적인 기존 레거시 Teradata 설치는 Azure Synapse로 쉽게 마이그레이션할 수 있는 방식으로 구현됩니다. 이는 대용량 데이터 볼륨에 대한 분석 쿼리에 SQL을 사용하며 차원 데이터 모델 형식입니다. 이러한 요인으로 인해 Azure Synapse로 마이그레이션하는 데 적합한 후보입니다.

실제 SQL 코드를 마이그레이션하는 작업을 최소화하려면 다음 권장 사항을 따르세요.

• 최종 환경에서 데이터 자격 증명 모음과 같은 다른 데이터 모델을 통합하더라도 데이터 웨어하우스의 초기 마이그레이션은 위험과 소요 시간을 최소화하기 위해 있는 그대로 수행되어야 합니다.

• 마이그레이션 프로세스의 일부로 Azure VM의 Teradata 인스턴스를 디딤돌로 사용하는 것이 좋습니다.

• Teradata SQL 구현과 Azure Synapse 간의 차이점을 이해합니다.

• 기존 Teradata 구현의 메타데이터 및 쿼리 로그를 사용하여 차이점의 영향을 평가하고 완화할 방법을 계획합니다.

• 가능한 경우 마이그레이션의 오류, 위험 및 시간을 최소화하기 위해 프로세스를 자동화합니다.

• 전문 Microsoft 파트너 및 서비스를 사용하여 마이그레이션을 간소화하는 것이 좋습니다.

다음 단계

Microsoft 및 타사 도구에 대한 자세한 내용은 이 시리즈의 다음 문서인 Teradata 데이터 웨어하우스를 Azure Synapse Analytics로 마이그레이션하기 위한 도구를 참조하세요.