Teradata 마이그레이션을 위한 데이터 마이그레이션, ETL 및 로드

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

데이터 마이그레이션 고려 사항

Teradata에서 데이터 마이그레이션을 위한 초기 결정

Teradata 데이터 웨어하우스를 마이그레이션할 때는 몇 가지 기본적인 데이터 관련 질문을 해야 합니다. 예시:

• 사용하지 않는 테이블 구조도 마이그레이션해야 하나요?

• 위험과 사용자 영향을 최소화하기 위한 최상의 마이그레이션 방법은 무엇인가요?

• 데이터 마트를 마이그레이션할 때 실제로 유지하나요, 가상으로 전환해야 하나요?

다음 섹션에서는 Teradata에서 마이그레이션하는 컨텍스트 내에서 이러한 사항에 대해 설명합니다.

사용하지 않는 테이블도 마이그레이션해야 하나요?

기존 시스템에서 사용 중인 테이블만 마이그레이션하는 것이 좋습니다. 활성 상태가 아닌 테이블은 마이그레이션하는 대신 보관할 수 있으므로 향후 필요할 때 데이터를 사용할 수 있습니다. 설명서가 최신 상태가 아닐 수 있으므로 사용 중인 테이블을 확인하기 위해 설명서보다 시스템 메타데이터 및 로그 파일을 사용하는 것이 가장 좋습니다.

사용하도록 설정된 경우 Teradata 시스템 카탈로그 테이블 및 로그에는 지정된 테이블에 마지막으로 액세스한 시간을 결정할 수 있는 정보가 포함되며, 이는 테이블이 마이그레이션 후보인지 여부를 결정하는 데 사용할 수 있습니다.

다음은 마지막 액세스 및 마지막 수정 날짜를 제공하는 DBC.Tables에 대한 쿼리의 예입니다.

SELECT TableName, CreatorName, CreateTimeStamp, LastAlterName,
LastAlterTimeStamp, AccessCount, LastAccessTimeStamp 
FROM DBC.Tables t
WHERE DataBaseName = 'databasename'

로깅이 사용하도록 설정되고 로그 기록에 액세스할 수 있는 경우 SQL 쿼리 텍스트와 같은 기타 정보는 DBQLogTbl 테이블 및 관련 로깅 테이블에서 사용할 수 있습니다. 자세한 내용은 Teradata 로그 기록을 참조하세요.

사용자에 대한 위험과 영향을 최소화하기 위한 최상의 마이그레이션 방법은 무엇인가요?

이 질문은 회사가 민첩성을 개선하기 위해 데이터 웨어하우스 데이터 모델에 대한 변경의 영향을 낮추기를 원할 수 있으므로 자주 제기됩니다. 회사에는 ETL 마이그레이션 중에 데이터를 더욱 현대화하거나 변환할 기회가 많이 있습니다. 이 방법은 여러 요소를 동시에 변경하여 기존 시스템과 새 시스템의 결과를 비교하기 어렵게 만들기 때문에 더 높은 위험을 수반합니다. 여기에서 데이터 모델을 변경하면 다른 시스템에 대한 업스트림 또는 다운스트림 ETL 작업에도 영향을 줄 수 있습니다. 이러한 위험 때문에 데이터 웨어하우스 마이그레이션 후에 이 규모로 재설계하는 것이 좋습니다.

데이터 모델이 전체 마이그레이션의 일부로 의도적으로 변경되더라도 새 플랫폼에서 리엔지니어링을 수행하는 것보다 기존 모델을 있는 그대로 Azure Synapse에 마이그레이션하는 것이 좋습니다. 이 방법은 기존 프로덕션 시스템에 대한 영향을 최소화하는 동시에 일회성 리엔지니어링 작업을 위해 Azure 플랫폼의 성능과 탄력적인 확장성을 활용합니다.

Teradata에서 마이그레이션할 때 마이그레이션 프로세스의 디딤돌로 Azure 내의 VM에 Teradata 환경을 만드는 것이 좋습니다.

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

온-프레미스 Teradata 환경에서 마이그레이션하기 위한 한 가지 선택적 방법은 Azure 환경을 활용하여 대상 Azure Synapse 환경과 같은 위치에 있는 Azure 내의 VM에 Teradata 인스턴스를 만드는 것입니다. 이는 Azure가 저렴한 클라우드 스토리지와 탄력적인 확장성을 제공하기 때문에 가능합니다.

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

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

• Azure 환경에는 친숙한 Teradata 인터페이스, 도구 및 유틸리티가 있습니다.

• Azure 환경은 온-프레미스 원본 시스템과 클라우드 대상 시스템 간에 네트워크 대역폭 가용성을 제공합니다.

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

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

데이터 마트를 마이그레이션할 때 실제로 유지하나요, 가상으로 전환해야 하나요?

레거시 Teradata 데이터 웨어하우스 환경에서는 조직 내의 특정 부서 또는 비즈니스 함수에 대한 임시 셀프 서비스 쿼리 및 보고서에 대해 우수한 성능을 제공하도록 구성된 여러 데이터 마트를 만드는 것이 일반적입니다. 따라서 데이터 마트는 일반적으로 데이터 웨어하우스의 하위 집합으로 구성되며 사용자가 Microsoft Power BI, Tableau 또는 MicroStrategy와 같은 사용자 친화적인 쿼리 도구를 통해 빠른 응답 시간으로 해당 데이터를 쉽게 쿼리할 수 있는 형식의 집계된 데이터 버전을 포함합니다. 이 양식은 일반적으로 차원 데이터 모델입니다. 데이터 마트의 한 가지 용도는 기본 웨어하우스 데이터 모델이 다른 모델(예: 데이터 자격 증명 모음)인 경우에도 사용 가능한 형식으로 데이터를 노출하는 것입니다.

사용자가 자신과 관련된 특정 데이터 마트에만 액세스하도록 허용하고 중요한 데이터를 제거, 난독화 또는 익명화함으로써 조직 내의 개별 사업부에 대해 별도의 데이터 마트를 사용하여 강력한 데이터 보안 체제를 구현할 수 있습니다.

이러한 데이터 마트가 실제 테이블로 구현되는 경우 이를 수용하기 위한 추가 스토리지 리소스와 정기적으로 빌드 및 새로 고침하기 위한 추가 처리가 필요합니다. 또한 마트의 데이터는 마지막 새로 고침 작업만큼만 최신 상태이므로 변동성이 큰 데이터 대시보드에는 적합하지 않을 수 있습니다.

Azure Synapse와 같은 비교적 저렴한 확장 가능한 MPP 아키텍처의 출현과 이러한 아키텍처의 고유한 성능 특성으로 인해 마트를 일련의 실제 테이블로 인스턴스화하지 않고도 데이터 마트 기능을 제공할 수 있습니다. 이는 주 데이터 웨어하우스에 대한 SQL 보기를 통해 또는 Azure 보기 또는 Microsoft 파트너의 시각화 제품과 같은 기능을 사용하는 가상화 계층을 통해 데이터 마트를 효과적으로 가상화함으로써 달성됩니다. 이 방법은 추가 스토리지 및 집계 처리의 필요성을 단순화하거나 제거하고 마이그레이션할 데이터베이스 개체의 전체 수를 줄입니다.

이 접근 방식에는 또 다른 잠재적인 이점이 있습니다. 가상화 계층 내에서 집계 및 조인 논리를 구현하고 가상화된 보기를 통해 외부 보고 도구를 제공함으로써 이러한 보기를 만드는 데 필요한 처리가 일반적으로 가장 좋은 데이터 웨어하우스로 “푸시”됩니다. 이는 대용량 데이터 볼륨에서 조인, 집계, 기타 관련 작업을 실행하는 장소입니다.

실제 데이터 마트보다 가상 데이터 마트 구현을 선택하기 위한 주요 동인은 다음과 같습니다.

• 가상 데이터 마트는 실제 테이블 및 관련 ETL 프로세스보다 변경하기 쉬우므로 민첩성이 향상됩니다.

• 가상화된 구현에는 더 적은 수의 데이터 저장소와 데이터 복사본이 필요하므로 총 소유 비용이 낮아집니다.

• 가상화된 환경에서 마이그레이션 및 단순화된 데이터 웨어하우스 아키텍처를 위한 ETL 작업을 제거합니다.

• 실제 데이터 마트가 역사적으로 더 성능이 좋았지만 가상화 제품은 이제 이를 완화하기 위해 지능형 캐싱 기술을 구현하므로 성능이 좋습니다.

Teradata에서 데이터 마이그레이션

데이터 이해

데이터의 양을 자세히 이해하는 것은 마이그레이션 방법에 대한 결정에 영향을 미칠 수 있으므로 마이그레이션 계획의 일부가 됩니다. 시스템 메타데이터를 사용하여 마이그레이션할 테이블 내의 “원시 데이터”가 차지하는 실제 공간을 결정합니다. 이 컨텍스트에서 “원시 데이터”는 인덱스 및 압축과 같은 오버헤드를 제외하고 테이블 내의 데이터 행이 사용하는 공간의 양을 의미합니다. 이는 일반적으로 데이터의 95% 이상을 구성하기 때문에 가장 큰 팩트 테이블의 경우 특히 그렇습니다.

압축되지 않은 구분된 플랫 ASCII 데이터 파일로 데이터의 대표적인 샘플(예: 백만 행)을 추출하여 지정된 테이블에 대해 완화할 데이터 볼륨에 대한 정확한 수치를 구할 수 있습니다. 그런 다음, 해당 파일의 크기를 사용하여 해당 테이블의 행당 평균 원시 데이터 크기를 구합니다. 마지막으로 해당 평균 크기에 전체 테이블의 총 행 수를 곱하여 테이블의 원시 데이터 크기를 제공합니다. 계획에 원시 데이터 크기를 사용합니다.

ETL 마이그레이션 고려 사항

Teradata ETL 마이그레이션에 관한 초기 결정

ETL/ELT 처리의 경우 레거시 Teradata 데이터 웨어하우스는 BTEQ 및 TPT(Teradata Parallel Transporter)와 같은 Teradata 유틸리티 또는 Informatica 또는 Ab Initio와 같은 타사 ETL 도구를 사용하여 사용자 지정 스크립트를 사용할 수 있습니다. 경우에 따라 Teradata 데이터 웨어하우스는 시간이 지남에 따라 발전된 ETL 및 ELT 방법의 조합을 사용합니다. Azure Synapse로의 마이그레이션을 계획할 때는 관련된 비용과 위험을 최소화하면서 새 환경에서 필요한 ETL/ELT 처리를 구현하는 가장 좋은 방법을 결정해야 합니다. ETL 및 ELT 처리에 대한 자세한 내용은 ELT 및 ETL 디자인 방법을 참조하세요.

다음 섹션에서는 마이그레이션 옵션에 대해 설명하고 다양한 사용 사례에 대한 권장 사항을 제시합니다. 이 순서도는 한 가지 방법을 요약합니다.

첫 번째 단계는 항상 마이그레이션해야 하는 ETL/ELT 프로세스의 인벤토리를 빌드하는 것입니다. 다른 단계와 마찬가지로 표준 “기본 제공” Azure 기능으로 인해 일부 기존 프로세스를 마이그레이션할 필요가 없을 수 있습니다. 계획을 위해서는 수행할 마이그레이션의 규모를 이해하는 것이 중요합니다.

앞의 순서도에서 결정 1은 완전한 Azure 네이티브 환경으로 마이그레이션할지 여부에 대한 상위 수준 결정과 관련이 있습니다. 완전히 Azure 기반 환경으로 이동하는 경우 Azure Data Factory의 파이프라인 및 작업 또는 Azure Synapse 파이프라인을 사용하여 ETL 처리를 다시 설계하는 것이 좋습니다. 완전히 Azure 네이티브 환경으로 이동하지 않는 경우 결정 2는 기존 타사 ETL 도구가 이미 사용 중인지 여부를 나타냅니다.

Teradata 환경에서 일부 또는 전체 ETL 처리는 BTEQ 및 TPT와 같은 Teradata 고유 유틸리티를 사용하는 사용자 지정 스크립트에 의해 수행될 수 있습니다. 이 경우 방법은 Data Factory를 사용하여 재설계하는 것입니다.

타사 ETL 도구가 이미 사용 중이고 특히 기술에 대한 대규모 투자가 있거나 해당 도구를 사용하는 여러 기존 워크플로 및 일정이 있는 경우 결정 3은 도구가 대상 환경으로 Azure Synapse를 효율적으로 지원할 수 있는지 여부를 나타냅니다. 이상적으로 도구에는 가장 효율적인 데이터 로드를 위해 PolyBase 또는 COPY INTO와 같은 Azure 기능을 활용할 수 있는 “네이티브” 커넥터가 포함됩니다. PolyBase 또는 COPY INTO와 같은 외부 프로세스를 호출하고 적절한 매개 변수를 전달하는 방법이 있습니다. 이 경우 Azure Synapse를 새 대상 환경으로 사용하여 기존 기술과 워크플로를 활용합니다.

기존 타사 ETL 도구를 유지하기로 결정한 경우 Azure 환경(기존 온-프레미스 ETL 서버가 아닌) 내에서 해당 도구를 실행하고 Azure Data Factory가 기존 워크플로의 전체 오케스트레이션을 처리하도록 하면 이점이 있을 수 있습니다. 한 가지 특별한 이점은 Azure에서 다운로드하고 처리한 다음, Azure로 다시 업로드해야 하는 데이터가 적다는 것입니다. 따라서 결정 4는 비용, 성능 및 확장성 이점을 가져오기 위해 기존 도구를 그대로 실행할지 아니면 Azure 환경으로 이동할지 여부를 나타냅니다.

기존 Teradata 전용 스크립트 재설계

기존 Teradata 웨어하우스 ETL/ELT 처리의 일부 또는 전체가 BTEQ, MLOAD 또는 TPT와 같은 Teradata 관련 유틸리티를 활용하는 사용자 지정 스크립트로 처리되는 경우 이러한 스크립트는 새로운 Azure Synapse 환경에 대해 다시 코딩해야 합니다. 마찬가지로 ETL 프로세스가 Teradata의 저장 프로시저를 사용하여 구현된 경우 이 프로세스도 다시 코딩해야 합니다.

ETL 프로세스의 일부 요소는 마이그레이션하기 쉽습니다(예: 외부 파일에서 준비 테이블로 간단한 대량 데이터 로드). 예를 들어 빠른 로드 또는 MLOAD 대신 PolyBase를 사용하여 프로세스의 이러한 부분을 자동화하는 것이 가능할 수도 있습니다. 내보낸 파일이 Parquet인 경우 PolyBase보다 빠른 옵션인 네이티브 Parquet 읽기 권한자를 사용할 수 있습니다. 임의의 복잡한 SQL 및/또는 저장 프로시저를 포함하는 프로세스의 다른 부분은 재설계하는 데 더 많은 시간이 걸립니다.

Azure Synapse와의 호환성을 위해 Teradata SQL을 테스트하는 한 가지 방법은 Teradata 로그에서 몇 가지 대표적인 SQL 문을 캡처한 다음 해당 쿼리에 EXPLAIN 접두사를 붙인 다음 Azure Synapse에서 마이그레이션된 데이터 모델과 유사하다고 가정하여 Azure Synapse의 EXPLAIN 문을 실행하는 것입니다. 호환되지 않는 SQL은 오류를 생성하고, 오류 정보는 레코딩 작업의 규모를 결정할 수 있습니다.

Microsoft 파트너는 Teradata SQL 및 저장 프로시저를 Azure Synapse로 마이그레이션하는 도구와 서비스를 제공합니다.

타사 ETL 도구 사용

이전 섹션에서 설명한 것처럼 많은 경우 기존 레거시 데이터 웨어하우스 시스템은 이미 타사 ETL 제품에 의해 채워지고 유지 관리됩니다. Azure Synapse용 Microsoft 데이터 통합 파트너 목록은 데이터 통합 파트너를 참조하세요.

Teradata에서 데이터 로드

Teradata에서 데이터를 로드할 때 선택 가능

Teradata 데이터 웨어하우스에서 데이터를 마이그레이션할 때 해결해야 하는 데이터 로드와 관련된 몇 가지 기본 질문이 있습니다. 기존 온-프레미스 Teradata 환경에서 클라우드의 Azure Synapse로 데이터를 실제로 전송하는 방법과 전송 및 로드를 수행하는 데 사용할 도구를 결정해야 합니다. 다음 섹션에서 논의될 다음 질문을 고려해 보세요.

• 데이터를 파일로 추출하려고 하나요, 아니면 네트워크 연결을 통해 직접 이동하려고 하나요?

• 원본 시스템 또는 Azure 대상 환경 중 어디서 프로세스를 오케스트레이션할 예정인가요?

• 프로세스를 자동화하고 관리하는 데 사용할 도구는 무엇인가요?

파일 또는 네트워크 연결을 통해 데이터를 전송하나요?

마이그레이션할 데이터베이스 테이블이 Azure Synapse에서 만들어지면 데이터를 이동하여 레거시 Teradata 시스템에서 해당 테이블을 채우고 새 환경으로 로드할 수 있습니다. 다음과 같은 두 가지 기본 방법이 있습니다.

• 파일 추출: BTEQ, Fast Export 또는 TPT(Teradata Parallel Transporter)를 통해 일반적으로 CSV 형식의 Teradata 테이블에서 플랫 파일로 데이터를 추출합니다. TPT는 데이터 처리량 측면에서 가장 효율적이므로 가능한 한 항상 TPT를 사용합니다.

  이 방법을 사용하려면 추출된 데이터 파일을 저장할 공간이 필요합니다. 공간은 Teradata 원본 데이터베이스에 로컬이거나(사용 가능한 스토리지가 충분한 경우) Azure Blob Storage에서 원격일 수 있습니다. 파일이 로컬로 기록되면 네트워크 오버헤드가 방지되기 때문에 때 최상의 성능을 얻을 수 있습니다.

  스토리지 및 네트워크 전송 요구 사항을 최소화하려면 gzip과 같은 유틸리티를 사용하여 추출된 데이터 파일을 압축하는 것이 좋습니다.

  압축을 풀면 플랫 파일을 Azure Blob Storage(대상 Azure Synapse 인스턴스와 함께 배치)로 이동하거나 PolyBase 또는 COPY INTO를 사용하여 Azure Synapse에 직접 로드할 수 있습니다. 로컬 온-프레미스 스토리지에서 Azure 클라우드 환경으로 데이터를 실제로 이동하는 방법은 데이터 양과 사용 가능한 네트워크 대역폭에 따라 다릅니다.

  Microsoft는 네트워크를 통해 Azure Storage로 파일을 이동하기 위한 AZCopy, 개인 네트워크 연결을 통해 대량 데이터를 이동하기 위한 Azure ExpressRoute, 파일을 실제 스토리지 디바이스로 이동하는 Azure Data Box를 포함하여 대용량 데이터를 이동하기 위한 다양한 옵션을 제공합니다. 그런 다음 로드를 위해 Azure 데이터 센터로 배송됩니다. 자세한 내용은 데이터 전송을 참조하세요.

• 네트워크를 통한 직접 추출 및 로드: 대상 Azure 환경은 일반적으로 SQL 명령을 통해 레거시 Teradata 시스템에 데이터 추출 요청을 전송하여 데이터를 추출합니다. 결과는 네트워크를 통해 전송되고 Azure Synapse에 직접 로드되며 데이터를 중간 파일에 '랜딩'할 필요가 없습니다. 이 시나리오의 제한 요소는 일반적으로 Teradata 데이터베이스와 Azure 환경 간의 네트워크 연결 대역폭입니다. 매우 큰 데이터 볼륨의 경우 이 방법이 실용적이지 않을 수 있습니다.

두 가지 방법을 모두 사용하는 하이브리드 방법도 있습니다. 예를 들어 더 작은 차원 테이블과 더 큰 팩트 테이블의 샘플에 대한 직접 네트워크 추출 방법을 사용하여 Azure Synapse에서 테스트 환경을 빠르게 제공할 수 있습니다. 대용량 기록 팩트 테이블의 경우 Azure Data Box를 사용하여 파일 추출 및 전송 방식을 사용할 수 있습니다.

Teradata 또는 Azure에서 오케스트레이션하려고 하나요?

Azure Synapse로 이동할 때 권장되는 방법은 Azure Synapse Pipelines 또는 Azure Data Factory와 관련 유틸리티(예:가장 효율적인 데이터 로드를 위해 PolyBase 또는 COPY INTO)를 사용하여 Azure 환경에서 데이터 추출 및 로드를 조정하는 것입니다. 이 방법은 Azure 기능을 활용하고 재사용 가능한 데이터 로드 파이프라인을 빌드하는 쉬운 방법을 제공합니다.

이 방법의 다른 이점으로는 관리 및 로드 프로세스가 Azure에서 실행되기 때문에 데이터 로드 프로세스 동안 Teradata 시스템에 미치는 영향이 줄어들고 메타데이터 기반 데이터 로드 파이프라인을 사용하여 프로세스를 자동화하는 기능이 있습니다.

어떤 도구를 사용할 수 있나요?

데이터 변환 및 이동 작업은 모든 ETL 제품의 기본 함수입니다. 이러한 제품 중 하나가 기존 Teradata 환경에서 이미 사용 중인 경우 기존 ETL 도구를 사용하면 Teradata에서 Azure Synapse로의 데이터 마이그레이션을 단순화할 수 있습니다. 이 방법은 ETL 도구가 Azure Synapse를 대상 환경으로 지원한다고 가정합니다. Azure Synapse를 지원하는 도구에 대한 자세한 내용은 데이터 통합 파트너를 참조하세요.

ETL 도구를 사용하는 경우 Azure 환경 내에서 해당 도구를 실행하여 Azure 클라우드 성능, 확장성 및 비용을 활용하고 Teradata 데이터 센터의 리소스를 확보하는 것을 고려합니다. 또 다른 이점은 클라우드와 온-프레미스 환경 간의 데이터 이동 감소입니다.

요약

요약하면 Teradata에서 Azure Synapse로 데이터 및 관련 ETL 프로세스를 마이그레이션하기 위한 권장 사항은 다음과 같습니다.

• 성공적인 마이그레이션을 위해 미리 계획합니다.

• 가능한 한 빨리 마이그레이션할 데이터 및 프로세스의 상세한 인벤토리를 빌드합니다.

• 시스템 메타데이터 및 로그 파일을 사용하여 데이터 및 프로세스 사용을 정확하게 이해합니다. 설명서가 오래되었을 수 있으므로 설명서에 의존하지 마세요.

• 마이그레이션할 데이터 볼륨과 온-프레미스 데이터 센터와 Azure 클라우드 환경 간의 네트워크 대역폭을 이해합니다.

• Azure VM의 Teradata 인스턴스를 레거시 Teradata 환경에서 마이그레이션을 오프로드하기 위한 디딤돌로 사용하는 것이 좋습니다.

• 표준 기본 제공 Azure 기능을 활용하여 마이그레이션 워크로드를 최소화합니다.

• Teradata 및 Azure 환경 모두에서 데이터 추출 및 로드를 위한 가장 효율적인 도구를 식별하고 이해합니다. 프로세스의 각 단계에서 적절한 도구를 사용합니다.

• Azure Synapse Pipelines 또는 Azure Data Factory와 같은 Azure 기능을 사용하여 Teradata 시스템에 대한 영향을 최소화하면서 마이그레이션 프로세스를 조정 및 자동화합니다.

다음 단계

보안 액세스 작업에 대해 자세히 알아보려면 이 시리즈의 다음 문서인 Teradata 마이그레이션을 위한 보안, 액세스 및 작업을 참조하세요.