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

아티클
06/09/2023

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

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

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

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

사용하지 않는 테이블 구조도 마이그레이션해야 하나요?
위험과 사용자 영향을 최소화하기 위한 최상의 마이그레이션 방법은 무엇인가요?
데이터 마트를 마이그레이션할 때 실제로 유지하나요, 가상으로 전환해야 하나요?

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

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

팁

레거시 시스템에서 시간이 지남에 따라 테이블이 중복되는 것은 드문 일이 아니며 대부분의 경우 마이그레이션할 필요가 없습니다.

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

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

다음은 특정 기간 내에 특정 테이블의 사용을 찾는 예제 쿼리입니다.

SELECT FORMAT_TABLE_ACCESS (usage),
  hq.submittime
FROM "$v_hist_queries" hq
  INNER JOIN "$hist_table_access_3" hta USING
(NPSID, NPSINSTANCEID, OPID, SESSIONID)
WHERE hq.dbname = 'PROD'
AND hta.schemaname = 'ADMIN'
AND hta.tablename = 'TEST_1'
AND hq.SUBMITTIME > '01-01-2015'
AND hq.SUBMITTIME <= '08-06-2015'
AND
(
  instr(FORMAT_TABLE_ACCESS(usage),'ins') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'upd') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'del') > 0
)
AND status=0;

| FORMAT_TABLE_ACCESS | SUBMITTIME
----------------------+---------------------------
ins                   | 2015-06-16 18:32:25.728042
ins                   | 2015-06-16 17:46:14.337105
ins                   | 2015-06-16 17:47:14.430995
(3 rows)

이 쿼리는 도우미 함수 FORMAT_TABLE_ACCESS와 $v_hist_table_access_3 보기의 끝에 있는 숫자를 사용하여 설치된 쿼리 기록 버전을 매칭합니다.

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

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

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

Netezza에서 마이그레이션할 때, 기존 데이터 모델이 이미 있는 그대로 Azure Synapse로 마이그레이션하기에 적합한 경우가 많습니다.

팁

향후에 데이터 모델에 대한 변경이 계획되어 있더라도 초기에 기존 모델을 있는 그대로 마이그레이션합니다.

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

팁

데이터 마트를 가상화하면 스토리지 및 처리 리소스를 절약할 수 있습니다.

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

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

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

팁

Azure Synapse의 성능과 확장성은 성능 저하 없이 가상화를 가능하게 합니다.

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

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

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

가상 데이터 마트는 실제 테이블 및 관련 ETL 프로세스보다 변경하기 쉬우므로 민첩성이 향상됩니다.
가상화된 구현에는 더 적은 수의 데이터 저장소와 데이터 복사본이 필요하므로 총 소유 비용이 낮아집니다.
가상화된 환경에서 마이그레이션 및 단순화된 데이터 웨어하우스 아키텍처를 위한 ETL 작업을 제거합니다.
실제 데이터 마트가 역사적으로 더 성능이 좋았지만 가상화 제품은 이제 이를 완화하기 위해 지능형 캐싱 기술을 구현하므로 성능이 좋습니다.

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

데이터 이해

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

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

Netezza 데이터 형식 매핑

팁

지원되지 않는 데이터 형식이 준비 단계의 일부로 미치는 영향을 평가합니다.

대부분의 Netezza 데이터 형식은 Azure Synapse에 직접 대응되는 형식이 있습니다. 다음 표는 이러한 데이터 형식과 이러한 데이터 형식을 매핑하는 데 권장하는 방법을 보여줍니다.

Netezza 데이터 형식	Azure Synapse 데이터 형식
BIGINT	BIGINT
BINARY VARYING(n)	VARBINARY(n)
BOOLEAN	BIT
BYTEINT	TINYINT
CHARACTER VARYING(n)	VARCHAR(n)
CHARACTER(n)	CHAR(n)
DATE	DATE(날짜)
DECIMAL(p,s)	DECIMAL(p,s)
DOUBLE PRECISION	FLOAT
FLOAT(n)	FLOAT(n)
INTEGER	INT
INTERVAL	INTERVAL 데이터 형식은 현재 Azure Synapse Analytics에서 직접 지원되지 않지만 DATEDIFF와 같은 임시 함수를 사용하여 계산할 수 있습니다.
MONEY	MONEY
NATIONAL CHARACTER VARYING(n)	NVARCHAR(n)
NATIONAL CHARACTER(n)	NCHAR(n)
NUMERIC(p,s)	NUMERIC(p,s)
REAL	REAL
SMALLINT	SMALLINT
ST_GEOMETRY(n)	ST_GEOMETRY와 같은 공간 데이터 형식은 현재 Azure Synapse Analytics에서 지원되지 않지만, 그 데이터는 VARCHAR 또는 VARBINARY로 저장할 수 있습니다.
TIME	TIME
TIME WITH TIME ZONE	DATETIMEOFFSET
timestamp	DATETIME

Netezza 카탈로그 테이블의 메타데이터를 사용하여 이러한 데이터 형식을 마이그레이션해야 하는지 결정하고, 마이그레이션 계획에서 이를 허용합니다. 이 유형의 쿼리에 대한 Netezza의 중요한 메타데이터 보기는 다음과 같습니다.

_V_USER: 사용자 보기는 Netezza 시스템의 사용자에 대한 정보를 제공합니다.
_V_TABLE: 테이블 보기에는 Netezza 성능 시스템에서 만든 테이블 목록이 포함됩니다.
_V_RELATION_COLUMN: 관계 열 시스템 카탈로그 보기에는 테이블에서 사용할 수 있는 열이 포함됩니다.
_V_OBJECTS: 개체 보기에는 Netezza에서 사용할 수 있는 테이블, 보기, 함수 등의 다양한 개체가 나열됩니다.

예를 들어 다음 Netezza SQL 쿼리는 열 및 열 형식을 보여줍니다.

SELECT
tablename,
  attname AS COL_NAME,
  b.FORMAT_TYPE AS COL_TYPE,
  attnum AS COL_NUM
FROM _v_table a
  JOIN _v_relation_column b
  ON a.objid = b.objid
WHERE a.tablename = 'ATT_TEST'
AND a.schema = 'ADMIN'
ORDER BY attnum;

TABLENAME | COL_NAME    | COL_TYPE             | COL_NUM
----------+-------------+----------------------+--------
ATT_TEST  | COL_INT     | INTEGER              | 1
ATT_TEST  | COL_NUMERIC | NUMERIC(10,2)        | 2
ATT_TEST  | COL_VARCHAR | CHARACTER VARYING(5) | 3
ATT_TEST  | COL_DATE    | DATE                 | 4
(4 rows)

모든 테이블을 검색하여 지원되지 않는 데이터 형식이 발생했는지 확인하도록 이 쿼리를 수정할 수 있습니다.

Azure Data Factory는 레거시 Netezza 환경의 데이터를 이동하는 데 사용할 수 있습니다. 자세한 내용은 IBM Netezza 커넥터를 참조하세요.

타사 공급업체는 앞에서 설명한 것처럼 데이터 형식 매핑을 포함하여 마이그레이션을 자동화하는 도구와 서비스를 제공합니다. 또한 Netezza 환경에서 이미 사용 중인 Informatica 또는 Talend와 같은 타사 ETL 도구는 필요한 모든 데이터 변환을 구현할 수 있습니다. 다음 섹션에서는 기존 타사 ETL 프로세스의 마이그레이션을 살펴봅니다.

ETL 마이그레이션 고려 사항

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

팁

ETL 마이그레이션에 대한 방법을 미리 계획하고 적절한 경우 Azure 시설을 활용합니다.

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

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

Flowchart of migration options and recommendations.

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

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

팁

기존 타사 도구에 대한 투자를 활용하여 비용과 위험을 줄입니다.

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

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

기존 Netezza 관련 스크립트 재설계

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

팁

마이그레이션할 ETL 작업의 인벤토리에는 스크립트와 저장 프로시저가 포함되어야 합니다.

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

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

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

타사 ETL 도구 사용

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

Netezza에서 데이터 로드

팁

타사 도구는 마이그레이션 프로세스를 단순화하고 자동화하여 위험을 줄일 수 있습니다.

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

데이터를 파일로 추출하려고 하나요, 아니면 네트워크 연결을 통해 직접 이동하려고 하나요?
원본 시스템 또는 Azure 대상 환경 중 어디서 프로세스를 오케스트레이션할 예정인가요?
프로세스를 자동화하고 관리하는 데 사용할 도구는 무엇인가요?

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

팁

이러한 요인이 마이그레이션 방법 결정에 영향을 미치므로 마이그레이션할 데이터 볼륨과 사용 가능한 네트워크 대역폭을 이해합니다.

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

파일 추출: nzsql에서 -o 옵션을 통해 또는 CREATE EXTERNAL TABLE 문을 통해 Netezza 테이블에서 플랫 파일(일반적으로 CSV 형식)로 데이터를 추출합니다. 가급적이면 데이터 처리량 측면에서 가장 효율적인 외부 테이블을 사용합니다. 다음 SQL 예제에서는 외부 테이블을 통해 CSV 파일을 만듭니다.
```
CREATE EXTERNAL TABLE '/data/export.csv' USING (delimiter ',')
AS SELECT col1, col2, expr1, expr2, col3, col1 || col2 FROM your table;
```
로컬 Netezza 호스트에 탑재된 파일 시스템으로 데이터를 내보내는 경우 외부 테이블을 사용합니다. JDBC, ODBC 또는 OLEDB가 설치된 원격 머신으로 데이터를 내보내는 경우 “remotesource odbc” 옵션은 USING 절입니다.

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

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

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

Microsoft는 네트워크를 통해 Azure Storage로 파일을 이동하는 AzCopy, 프라이빗 네트워크 연결을 통해 데이터를 대량으로 이동하는 Azure ExpressRoute, 파일을 실제 스토리지 디바이스로 이동한 후 실제 스토리지 디바이스를 Azure 데이터 센터로 보내서 로드할 수 있는 Azure Data Box를 포함하여 대량의 데이터를 이동할 수 있는 다양한 옵션을 제공합니다. 자세한 내용은 데이터 전송을 참조하세요.
네트워크를 통한 직접 추출 및 로드: 대상 Azure 환경은 일반적으로 SQL 명령을 통해 레거시 Netezza 시스템에 데이터 추출 요청을 전송하여 데이터를 추출합니다. 결과는 네트워크를 통해 전송되고 Azure Synapse에 직접 로드되며 데이터를 중간 파일에 '랜딩'할 필요가 없습니다. 이 시나리오의 제한 요소는 일반적으로 Netezza 데이터베이스와 Azure 환경 간의 네트워크 연결 대역폭입니다. 매우 큰 데이터 볼륨의 경우 이 방법이 실용적이지 않을 수 있습니다.

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

Netezza 또는 Azure 중 어디서 오케스트레이션하나요?

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

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

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

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

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

요약

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

성공적인 마이그레이션을 위해 미리 계획합니다.
가능한 한 빨리 마이그레이션할 데이터 및 프로세스의 상세한 인벤토리를 빌드합니다.
시스템 메타데이터 및 로그 파일을 사용하여 데이터 및 프로세스 사용을 정확하게 이해합니다. 설명서가 오래되었을 수 있으므로 설명서에 의존하지 마세요.
마이그레이션할 데이터 볼륨과 온-프레미스 데이터 센터와 Azure 클라우드 환경 간의 네트워크 대역폭을 이해합니다.
표준 기본 제공 Azure 기능을 활용하여 마이그레이션 워크로드를 최소화합니다.
Netezza 및 Azure 환경 모두에서 데이터 추출 및 로드를 위한 가장 효율적인 도구를 식별하고 이해합니다. 프로세스의 각 단계에서 적절한 도구를 사용합니다.
Azure Synapse Pipelines 또는 Azure Data Factory와 같은 Azure 기능을 사용하여 Netezza 시스템에 대한 영향을 최소화하면서 마이그레이션 프로세스를 조정 및 자동화합니다.

다음 단계

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

다음을 통해 공유