ETL 테스트-퀵 가이드

데이터웨어 하우스 시스템의 데이터는 ETL (추출, 변환,로드) 도구를 사용하여로드됩니다. 이름에서 알 수 있듯이 다음 세 가지 작업을 수행합니다.

Oracle, Microsoft 또는 기타 관계형 데이터베이스가 될 수있는 트랜잭션 시스템에서 데이터를 추출합니다.
데이터 정리 작업을 수행하여 데이터를 변환 한 다음
데이터를 OLAP 데이터웨어 하우스에로드합니다.

ETL 도구를 사용하여 스프레드 시트 및 CSV 파일과 같은 플랫 파일에서 데이터를 추출하고 데이터 분석 및보고를 위해 OLAP 데이터웨어 하우스에로드 할 수도 있습니다. 더 잘 이해하기 위해 예를 들어 보겠습니다.

예

영업, HR, 자재 관리, EWM 등과 같은 여러 부서가있는 제조 회사가 있다고 가정 해 보겠습니다. 이러한 모든 부서에는 업무에 대한 정보를 유지하는 데 사용하는 별도의 데이터베이스가 있으며 각 데이터베이스에는 서로 다른 기술, 환경, 테이블이 있습니다. 이름, 열 등. 이제 회사가 과거 데이터를 분석하고 보고서를 생성하려면 이러한 데이터 소스의 모든 데이터를 추출하여 데이터웨어 하우스에로드하여 분석 작업을 위해 저장해야합니다.

ETL 도구는 이러한 모든 이기종 데이터 소스에서 데이터를 추출하고 데이터를 변환 (예 : 계산 적용, 필드 결합, 잘못된 데이터 필드 제거 등) 한 다음 데이터웨어 하우스에로드합니다. 나중에 다양한 비즈니스 인텔리전스 (BI) 도구를 사용하여이 데이터를 사용하여 의미있는 보고서, 대시 보드 및 시각화를 생성 할 수 있습니다.

ETL과 BI 도구의 차이점

ETL 도구는 다른 데이터 소스에서 데이터를 추출하고 데이터를 변환 한 다음 DW 시스템에로드하는 데 사용됩니다. 그러나 BI 도구는 최종 사용자를위한 대화 형 임시 보고서, 고위 경영진을위한 대시 보드, 월간, 분기 별 및 연간 이사회를위한 데이터 시각화를 생성하는 데 사용됩니다.

가장 일반적인 ETL 도구에는 SAP BO 데이터 서비스 (BODS), Informatica – Power Center, Microsoft – SSIS, Oracle Data Integrator ODI, Talend Open Studio, Clover ETL 오픈 소스 등이 포함됩니다.

인기있는 BI 도구로는 SAP Business Objects, SAP Lumira, IBM Cognos, JasperSoft, Microsoft BI Platform, Tableau, Oracle Business Intelligence Enterprise Edition 등이 있습니다.

ETL 프로세스

이제 ETL 절차와 관련된 주요 단계에 대해 좀 더 자세히 논의하겠습니다.

데이터 추출

다른 이기종 데이터 소스에서 데이터를 추출하는 작업이 포함됩니다. 트랜잭션 시스템에서 데이터를 추출하는 것은 요구 사항과 사용중인 ETL 도구에 따라 다릅니다. 일반적으로 야간 또는 주말에 작업을 실행하는 것과 같이 업무 외 시간에 예약 된 작업을 실행하여 수행됩니다.

데이터 변환

데이터를 DW 시스템에 쉽게로드 할 수있는 적절한 형식으로 변환하는 작업이 포함됩니다. 데이터 변환에는 계산 적용, 조인, 데이터에 대한 기본 및 외래 키 정의가 포함됩니다. 예를 들어 데이터베이스에없는 총 수익의 %를 원하는 경우 변환에 % 공식을 적용하고 데이터를로드합니다. 마찬가지로 다른 열에 사용자의 이름과 성이있는 경우 데이터를로드하기 전에 연결 작업을 적용 할 수 있습니다. 일부 데이터에는 변환이 필요하지 않습니다. 이러한 데이터는direct move 또는 pass through data.

데이터 변환에는 데이터 수정 및 데이터 정리, 잘못된 데이터 제거, 불완전한 데이터 형성 및 데이터 오류 수정도 포함됩니다. 또한 DW 시스템에로드하기 전에 데이터 무결성 및 호환되지 않는 데이터 형식화를 포함합니다.

DW 시스템에 데이터로드

분석보고 및 정보를 위해 데이터를 DW 시스템에로드하는 작업이 포함됩니다. 대상 시스템은 단순 구분 플랫 파일 또는 데이터웨어 하우스 일 수 있습니다.

ETL 도구 기능

일반적인 ETL 도구 기반 데이터웨어 하우스는 스테이징 영역, 데이터 통합 및 액세스 계층을 사용하여 기능을 수행합니다. 일반적으로 3 계층 아키텍처입니다.

Staging Layer − 스테이징 레이어 또는 스테이징 데이터베이스는 다른 소스 데이터 시스템에서 추출 된 데이터를 저장하는 데 사용됩니다.
Data Integration Layer − 통합 계층은 스테이징 계층의 데이터를 변환하고 데이터를 데이터베이스로 이동합니다. 여기서 데이터는 종종 계층 적 그룹으로 정렬됩니다. dimensions, 그리고 facts 과 aggregate facts. DW 시스템에서 팩트와 차원 테이블의 조합을schema.
Access Layer − 액세스 계층은 최종 사용자가 분석보고 및 정보를 위해 데이터를 검색하는 데 사용됩니다.

다음 그림은 세 레이어가 서로 상호 작용하는 방식을 보여줍니다.

ETL 테스트는 데이터가 프로덕션 데이터웨어 하우스 시스템으로 이동되기 전에 수행됩니다. 때로는 다음과 같이 불립니다.table balancing 또는 production reconciliation. 범위와이를 완료하기 위해 취해야 할 단계 측면에서 데이터베이스 테스트와 다릅니다.

ETL 테스트의 주요 목적은 분석보고를 위해 데이터를 처리하기 전에 발생하는 데이터 결함 및 일반 오류를 식별하고 완화하는 것입니다.

ETL 테스트 – 수행 할 작업

다음은 ETL 테스트와 관련된 일반적인 작업 목록입니다.

보고에 사용할 데이터 이해
데이터 모델 검토
소스 대 대상 매핑
소스 데이터에 대한 데이터 확인
패키지 및 스키마 유효성 검사
대상 시스템에서 데이터 검증
데이터 변환 계산 및 집계 규칙 확인
소스 및 대상 시스템 간의 샘플 데이터 비교
대상 시스템의 데이터 무결성 및 품질 검사
데이터 성능 테스트

ETL 테스트와 데이터베이스 테스트는 모두 데이터 유효성 검사를 포함하지만 동일하지는 않습니다. ETL 테스트는 일반적으로 데이터웨어 하우스 시스템의 데이터에 대해 수행되는 반면 데이터베이스 테스트는 일반적으로 데이터가 서로 다른 응용 프로그램에서 트랜잭션 데이터베이스로 들어오는 트랜잭션 시스템에서 수행됩니다.

여기에서는 ETL 테스트와 데이터베이스 테스트의 주요 차이점을 강조했습니다.

ETL 테스트

ETL 테스트에는 다음 작업이 포함됩니다.

소스에서 타겟 시스템으로의 데이터 이동 검증.
소스 및 대상 시스템의 데이터 수 확인.
요구 사항 및 기대에 따라 데이터 추출, 변환을 확인합니다.
테이블 관계 (조인 및 키)가 변환 중에 유지되는지 확인합니다.

일반적인 ETL 테스트 도구에는 다음이 포함됩니다. QuerySurge, Informatica등

데이터베이스 테스트

데이터베이스 테스트는 데이터 정확성, 데이터의 정확성 및 유효한 값에 더 중점을 둡니다. 그것은 다음과 같은 작업을 포함합니다-

기본 및 외래 키가 유지되는지 확인합니다.
테이블의 열에 유효한 데이터 값이 있는지 확인합니다.
열의 데이터 정확성을 확인합니다. Example − 개월 수 열은 12보다 큰 값을 가질 수 없습니다.
열에서 누락 된 데이터를 확인합니다. 실제로 유효한 값을 가져야하는 널 열이 있는지 확인하십시오.

일반적인 데이터베이스 테스트 도구에는 다음이 포함됩니다. Selenium, QTP등

다음 표는 데이터베이스 및 ETL 테스트의 주요 기능과 비교를 보여줍니다.

함수	데이터베이스 테스트	ETL 테스트
주요 목표	데이터 검증 및 통합	BI보고를위한 데이터 추출, 변환 및로드
적용 가능한 시스템	비즈니스 흐름이 발생하는 트랜잭션 시스템	비즈니스 흐름 환경이 아닌 기록 데이터를 포함하는 시스템
일반적인 도구	QTP, 셀레늄 등	QuerySurge, Informatica 등
비즈니스 요구	여러 애플리케이션의 데이터를 통합하는 데 사용되며 심각한 영향을 미칩니다.	분석보고, 정보 및 예측에 사용됩니다.
모델링	ER 방법	다차원
데이터베이스 유형	일반적으로 OLTP 시스템에서 사용됩니다.	OLAP 시스템에 적용
데이터 형식	더 많은 조인이있는 정규화 된 데이터	더 적은 조인, 더 많은 인덱스 및 집계로 비정규 화 된 데이터.

ETL 테스트 분류는 테스트 및보고 목적에 따라 수행됩니다. 테스트 범주는 조직 표준에 따라 다르며 클라이언트 요구 사항에 따라 다릅니다. 일반적으로 ETL 테스트는 다음 사항에 따라 분류됩니다.

Source to Target Count Testing − 소스 및 대상 시스템의 레코드 개수 일치가 포함됩니다.
Source to Target Data Testing− 소스와 타겟 시스템 간의 데이터 검증이 포함됩니다. 또한 대상 시스템에서 데이터 통합 및 임계 값 확인 및 중복 데이터 확인이 포함됩니다.
Data Mapping or Transformation Testing− 소스 및 대상 시스템의 개체 매핑을 확인합니다. 또한 대상 시스템에서 데이터의 기능을 확인하는 것도 포함됩니다.
End-User Testing− 최종 사용자가 보고서의 데이터가 예상대로인지 확인하기 위해 보고서를 생성하는 작업이 포함됩니다. 여기에는 보고서에서 편차를 찾고 보고서 유효성 검사를 위해 대상 시스템의 데이터를 교차 확인하는 것이 포함됩니다.
Retesting − 대상 시스템에있는 데이터의 버그 및 결함을 수정하고 데이터 유효성 검사를 위해 보고서를 다시 실행하는 작업이 포함됩니다.
System Integration Testing− 모든 개별 시스템을 테스트하고 나중에 결과를 결합하여 편차가 있는지 확인합니다. 이를 수행하는 데 사용할 수있는 세 가지 접근 방식은 하향식, 상향식 및 하이브리드입니다.

데이터웨어 하우스 시스템의 구조에 따라 ETL 테스트 (사용되는 도구에 관계없이)는 다음 범주로 나눌 수 있습니다.

새로운 DW 시스템 테스트

이러한 유형의 테스트에는 새로운 DW 시스템이 구축 및 검증되었습니다. 데이터 입력은 고객 / 최종 사용자 및 다른 데이터 소스에서 가져 오며 새로운 데이터웨어 하우스가 생성됩니다. 나중에 ETL 도구를 사용하여 새 시스템에서 데이터를 확인합니다.

마이그레이션 테스트

마이그레이션 테스트에서 고객은 기존 데이터웨어 하우스와 ETL을 가지고 있지만 효율성을 향상시킬 새로운 ETL 도구를 찾습니다. 새로운 ETL 도구를 사용하여 기존 시스템에서 데이터를 마이그레이션하는 작업이 포함됩니다.

변경 테스트

변경 테스트에서는 다른 데이터 소스의 새 데이터가 기존 시스템에 추가됩니다. 고객은 ETL에 대한 기존 규칙을 변경하거나 새 규칙을 추가 할 수도 있습니다.

보고서 테스트

보고서 테스트에는 데이터 유효성 검사를위한 보고서 작성이 포함됩니다. 보고서는 모든 DW 시스템의 최종 출력입니다. 보고서는 레이아웃, 보고서의 데이터 및 계산 된 값을 기반으로 테스트됩니다.

ETL 테스트는 데이터베이스 테스트 또는 기타 기존 테스트와 다릅니다. ETL 테스트를 수행하는 동안 여러 유형의 문제에 직면해야 할 수 있습니다. 여기에 몇 가지 일반적인 과제를 나열했습니다.

ETL 프로세스 중 데이터 손실.
부정확하거나 불완전하거나 중복 된 데이터.
DW 시스템에는 기록 데이터가 포함되어 있으므로 데이터 볼륨이 너무 커서 대상 시스템에서 ETL 테스트를 수행하기에는 매우 복잡합니다.
ETL 테스터는 일반적으로 ETL 도구에서 작업 일정을 볼 수있는 액세스 권한이 제공되지 않습니다. 보고서 내에서 보고서 및 데이터의 최종 레이아웃을보기 위해 BI보고 도구에 거의 액세스 할 수 없습니다.
데이터 볼륨이 너무 많고 복잡하기 때문에 테스트 케이스를 생성하고 구축하기가 어렵습니다.
ETL 테스터는 일반적으로 최종 사용자 보고서 요구 사항 및 정보의 비즈니스 흐름에 대한 아이디어가 없습니다.
ETL 테스트에는 대상 시스템의 데이터 유효성 검사를위한 다양한 복잡한 SQL 개념이 포함됩니다.
때로는 테스터에게 소스-타겟 매핑 정보가 제공되지 않습니다.
불안정한 테스트 환경은 프로세스의 개발과 테스트를 지연시킵니다.

ETL 테스터는 주로 데이터 소스 유효성 검사, 데이터 추출, 변환 논리 적용 및 대상 테이블에 데이터로드를 담당합니다.

ETL 테스터의 주요 책임은 다음과 같습니다.

소스 시스템의 테이블 확인

그것은 다음과 같은 작업을 포함합니다-

카운트 확인
소스 데이터로 레코드 조정
데이터 유형 확인
스팸 데이터가로드되지 않았는지 확인
중복 데이터 제거
모든 키가 제자리에 있는지 확인하십시오.

변환 논리 적용

데이터를로드하기 전에 변환 논리가 적용됩니다. 그것은 다음과 같은 작업을 포함합니다-

예를 들어 데이터 임계 값 유효성 검사는 연령 값이 100을 넘지 않아야합니다.
변환 논리 적용 전후의 레코드 수 확인.
준비 영역에서 중간 테이블까지의 데이터 흐름 유효성 검사.
대리 키 확인.

데이터 로딩

데이터는 스테이징 영역에서 대상 시스템으로로드됩니다. 그것은 다음과 같은 작업을 포함합니다-

중간 테이블에서 대상 시스템으로의 레코드 개수 확인.
키 필드 데이터가 누락되거나 널이 아닌지 확인하십시오.
집계 값과 계산 된 측정 값이 팩트 테이블에로드되었는지 확인합니다.
대상 테이블을 기반으로 모델링 뷰를 확인하십시오.
CDC가 증분로드 테이블에 적용되었는지 확인합니다.
차원 테이블 및 이력 테이블 확인에서 데이터 확인.
로드 된 팩트 및 차원 테이블을 기반으로 예상 결과에 따라 BI 보고서를 확인하십시오.

ETL 도구 테스트

ETL 테스터는 도구와 테스트 케이스도 테스트해야합니다. 그것은 다음과 같은 작업을 포함합니다-

ETL 도구 및 해당 기능 테스트
ETL 데이터웨어 하우스 시스템 테스트
테스트 계획 및 테스트 케이스를 생성, 설계 및 실행합니다.
플랫 파일 데이터 전송을 테스트하십시오.

테스트 프로세스를 시작하기 전에 올바른 ETL 테스트 기술을 정의하는 것이 중요합니다. 모든 이해 관계자의 동의를 얻어 ETL 테스트를 수행하기 위해 올바른 기술이 선택되었는지 확인해야합니다. 이 기술은 테스트 팀에 잘 알려져 있어야하며 테스트 프로세스와 관련된 단계를 알고 있어야합니다.

사용할 수있는 다양한 유형의 테스트 기술이 있습니다. 이 장에서는 테스트 기술에 대해 간략하게 설명합니다.

생산 검증 테스트

분석보고 및 분석을 수행하려면 프로덕션의 데이터가 정확해야합니다. 이 테스트는 프로덕션 시스템으로 이동 된 데이터에 대해 수행됩니다. 여기에는 프로덕션 시스템의 데이터 유효성 검사와 소스 데이터와의 비교가 포함됩니다.

소스-타겟 카운트 테스트

이 유형의 테스트는 테스터가 테스트 작업을 수행 할 시간이 적을 때 수행됩니다. 여기에는 소스 및 대상 시스템의 데이터 수 확인이 포함됩니다. 대상 시스템의 데이터 값을 확인하는 작업은 포함되지 않습니다. 또한 데이터 매핑 후 데이터가 오름차순 또는 내림차순인지 여부도 포함되지 않습니다.

소스-타겟 데이터 테스트

이 유형의 테스트에서 테스터는 소스에서 대상 시스템까지 데이터 값의 유효성을 검사합니다. 변환 후 소스 시스템의 데이터 값과 대상 시스템의 해당 값을 확인합니다. 이러한 유형의 테스트는 시간이 많이 걸리며 일반적으로 금융 및 은행 프로젝트에서 수행됩니다.

데이터 통합 / 임계 값 검증 테스트

이 유형의 테스트에서 테스터는 데이터 범위를 검증합니다. 대상 시스템의 모든 임계 값이 예상 결과에 맞는지 확인합니다. 또한 변환 및로드 후 여러 소스 시스템에서 대상 시스템의 데이터 통합이 포함됩니다.

Example − 연령 속성은 100보다 큰 값을 가질 수 없습니다. 날짜 열 DD / MM / YY에서 월 필드는 12보다 큰 값을 가질 수 없습니다.

애플리케이션 마이그레이션 테스트

응용 프로그램 마이그레이션 테스트는 일반적으로 이전 응용 프로그램에서 새 응용 프로그램 시스템으로 이동할 때 자동으로 수행됩니다. 이 테스트는 많은 시간을 절약합니다. 기존 애플리케이션에서 추출한 데이터가 새 애플리케이션 시스템의 데이터와 동일한 지 확인합니다.

데이터 확인 및 제약 테스트

여기에는 데이터 유형 검사, 데이터 길이 검사 및 인덱스 검사와 같은 다양한 검사 수행이 포함됩니다. 여기서 테스트 엔지니어는 기본 키, 외래 키, NOT NULL, NULL 및 UNIQUE 시나리오를 수행합니다.

중복 데이터 검사 테스트

이 테스트에는 대상 시스템의 중복 데이터 확인이 포함됩니다. 대상 시스템에 엄청난 양의 데이터가있는 경우 생산 시스템에 중복 데이터가있어 분석 보고서에서 잘못된 데이터가 발생할 수 있습니다.

중복 값은 다음과 같은 SQL 문으로 확인할 수 있습니다.

Select Cust_Id, Cust_NAME, Quantity, COUNT (*) 
FROM Customer
GROUP BY Cust_Id, Cust_NAME, Quantity HAVING COUNT (*) >1;

다음과 같은 이유로 대상 시스템에 중복 데이터가 나타납니다.

기본 키가 정의되지 않은 경우 중복 값이 올 수 있습니다.
잘못된 매핑 또는 환경 문제로 인해.
소스에서 대상 시스템으로 데이터를 전송하는 동안 수동 오류가 발생했습니다.

데이터 변환 테스트

단일 SQL 문을 실행하여 데이터 변환 테스트를 수행하지 않습니다. 시간이 많이 걸리며 각 행에 대해 여러 SQL 쿼리를 실행하여 변환 규칙을 확인합니다. 테스터는 각 행에 대해 SQL 쿼리를 실행 한 다음 출력을 대상 데이터와 비교해야합니다.

데이터 품질 테스트

데이터 품질 테스트에는 번호 확인, 날짜 확인, null 확인, 정밀도 확인 등이 포함됩니다. 테스터가 수행합니다. Syntax Test 잘못된 문자, 잘못된 대 / 소문자 순서 등을보고합니다. Reference Tests 데이터가 데이터 모델에 맞는지 확인합니다.

증분 테스트

예상 결과에 따라 Insert 및 Update 문이 실행되는지 확인하기 위해 증분 테스트가 수행됩니다. 이 테스트는 이전 데이터와 새 데이터를 사용하여 단계별로 수행됩니다.

회귀 테스트

테스터가 새로운 오류를 찾는 데 도움이되는 새로운 기능을 추가하기 위해 데이터 변환 및 집계 규칙을 변경하는 것을 회귀 테스트라고합니다. 회귀 테스트에서 발생하는 데이터의 버그를 회귀라고합니다.

재시험

코드를 수정 한 후 테스트를 실행하는 것을 재 테스트라고합니다.

시스템 통합 테스트

시스템 통합 테스트에는 시스템 구성 요소를 개별적으로 테스트하고 나중에 모듈을 통합하는 작업이 포함됩니다. 시스템 통합은 하향식, 상향식, 하이브리드의 세 가지 방법이 있습니다.

탐색 테스트

탐색 테스트는 시스템의 프런트 엔드 테스트라고도합니다. 다양한 필드의 데이터, 계산 및 집계 등을 포함하는 프런트 엔드 보고서의 모든 측면을 확인하여 최종 사용자 관점 테스트를 포함합니다.

ETL 테스트는 ETL 라이프 사이클과 관련된 모든 단계를 다룹니다. 요약 보고서가 생성 될 때까지 비즈니스 요구 사항을 이해하는 것으로 시작됩니다.

ETL 테스트 수명주기의 일반적인 단계는 다음과 같습니다.

비즈니스 요구 사항 이해.
비즈니스 요구 사항 검증.
테스트 예상은 테스트 케이스를 실행하고 요약 보고서를 완료하는 데 예상되는 시간을 제공하는 데 사용됩니다.
테스트 계획에는 비즈니스 요구 사항에 따라 입력을 기반으로 테스트 기술을 찾는 것이 포함됩니다.
테스트 시나리오 및 테스트 케이스 작성.
테스트 케이스가 준비되고 승인되면 다음 단계는 사전 실행 검사를 수행하는 것입니다.
모든 테스트 케이스를 실행하십시오.
마지막 단계는 완전한 요약 보고서를 생성하고 폐쇄 프로세스를 제출하는 것입니다.

ETL 테스트 시나리오는 ETL 테스트 프로세스를 검증하는 데 사용됩니다. 다음 표는 ETL 테스터가 사용하는 가장 일반적인 시나리오 및 테스트 케이스를 설명합니다.

테스트 시나리오	테스트 케이스
구조 검증	여기에는 매핑 문서에 따라 소스 및 대상 테이블 구조의 유효성을 검사하는 작업이 포함됩니다. 데이터 유형은 소스 및 대상 시스템에서 유효성을 검사해야합니다. 소스 및 대상 시스템의 데이터 유형 길이는 동일해야합니다. 데이터 필드 유형 및 형식은 소스 및 대상 시스템에서 동일해야합니다. 대상 시스템에서 열 이름을 검증합니다.
매핑 문서 검증	모든 정보가 제공되었는지 확인하기 위해 매핑 문서의 유효성을 검사하는 작업이 포함됩니다. 매핑 문서에는 변경 로그, 유지 데이터 유형, 길이, 변환 규칙 등이 있어야합니다.
제약 조건 검증	여기에는 제약 조건의 유효성을 검사하고 예상 테이블에 적용되는지 확인하는 작업이 포함됩니다.
데이터 일관성 검사	외래 키와 같은 무결성 제약 조건의 오용을 확인하는 작업이 포함됩니다. 속성의 길이와 데이터 유형은 의미 계층에서 정의가 동일하지만 테이블마다 다를 수 있습니다.
데이터 완전성 검증	모든 데이터가 소스 시스템에서 타겟 시스템으로로드되었는지 확인하는 작업이 포함됩니다. 소스 및 대상 시스템의 레코드 수 계산. 경계 값 분석. 기본 키의 고유 한 값을 확인합니다.
데이터 정확성 검증	대상 시스템에서 데이터 값의 유효성을 검사하는 작업이 포함됩니다. 표에 철자가 틀리거나 부정확 한 데이터가 있습니다. 가져올 때 무결성 제약 조건을 비활성화하면 Null, Not Unique 데이터가 저장됩니다.
데이터 변환 유효성 검사	여기에는 입력 값과 예상 결과에 대한 시나리오 스프레드 시트를 만든 다음 최종 사용자와 함께 유효성을 검사하는 작업이 포함됩니다. 시나리오를 생성하여 데이터에서 부모-자식 관계를 검증합니다. 데이터 프로파일 링을 사용하여 각 필드의 값 범위를 비교합니다. 웨어 하우스의 데이터 유형이 데이터 모델에 언급 된 것과 동일한 지 확인합니다.
데이터 품질 검증	번호 확인, 날짜 확인, 정밀도 확인, 데이터 확인, Null 확인 등을 수행합니다. Example − 날짜 형식은 모든 값에 대해 동일해야합니다.
Null 유효성 검사	해당 필드에 대해 Not Null이 언급 된 Null 값을 확인하는 작업이 포함됩니다.
중복 검증	소스 시스템의 여러 열에서 데이터를 가져올 때 대상 시스템에서 중복 값의 유효성을 검사하는 작업이 포함됩니다. 비즈니스 요구 사항에 따라 중복 값이있는 경우 기본 키 및 기타 열의 유효성을 검사합니다.
날짜 유효성 검사	ETL 프로세스에서 수행되는 다양한 작업에 대한 날짜 필드를 확인합니다. 날짜 유효성 검사를 수행하는 일반적인 테스트 사례- From_Date는 To_Date보다 클 수 없습니다. 날짜 값의 형식은 적절해야합니다. 날짜 값에는 정크 값이나 null 값이 없어야합니다.
쿼리를 제외한 전체 데이터 유효성 검사	마이너스 쿼리를 사용하여 소스 및 대상 테이블의 전체 데이터 세트의 유효성을 검사하는 작업이 포함됩니다. 둘 다 수행해야합니다. source minus target 과 target minus source. 마이너스 쿼리가 값을 반환하면 일치하지 않는 행으로 간주해야합니다. 다음을 사용하여 소스 및 대상의 행을 일치시켜야합니다. Intersect 성명서. Intersect에서 반환 된 개수는 소스 및 대상 테이블의 개별 개수와 일치해야합니다. 마이너스 쿼리가 행을 반환하지 않고 교차 개수가 소스 개수 또는 대상 테이블 개수보다 적 으면 테이블은 중복 행을 보유합니다.
기타 테스트 시나리오	다른 테스트 시나리오는 추출 프로세스가 소스 시스템에서 중복 데이터를 추출하지 않았는지 확인하는 것입니다. 테스트 팀은 소스 시스템에서 중복 데이터가 추출되지 않았는지 확인하기 위해 실행되는 SQL 문 목록을 유지 관리합니다.
데이터 정리	데이터를 준비 영역에로드하기 전에 원하지 않는 데이터를 제거해야합니다.

ETL 성능 조정은 ETL 시스템이 여러 사용자 및 트랜잭션의 예상로드를 처리 할 수 있는지 확인하는 데 사용됩니다. 성능 조정에는 일반적으로 ETL 시스템의 서버 측 워크로드가 포함됩니다. 다중 사용자 환경에서 서버 응답을 테스트하고 병목 현상을 찾는 데 사용됩니다. 이들은 소스 및 대상 시스템, 시스템 매핑, 세션 관리 속성과 같은 구성 등에서 찾을 수 있습니다.

ETL 테스트 성능 조정을 수행하는 방법은 무엇입니까?

ETL 테스트 성능 튜닝을 수행하려면 아래 단계를 따르십시오.

Step 1 − 생산 과정에서 변형되는 부하를 찾습니다.
Step 2 − 동일한 부하의 새 데이터를 생성하거나 프로덕션 데이터에서 로컬 성능 서버로 이동합니다.
Step 3 − 필요한 부하를 생성 할 때까지 ETL을 비활성화합니다.
Step 4 − 데이터베이스의 테이블에서 필요한 데이터의 개수를 가져옵니다.
Step 5− ETL의 마지막 실행을 기록하고 ETL을 활성화하여 생성 된 전체로드를 변환하는 데 충분한 스트레스를받을 수 있도록합니다. 실행
Step 6 − ETL이 실행을 완료 한 후 생성 된 데이터의 개수를 확인합니다.

핵심 성과 지표

부하를 변환하는 데 걸린 총 시간을 알아보십시오.
성능 시간이 개선되었는지 또는 감소했는지 알아보십시오.
예상되는 전체 부하가 추출되어 전송되었는지 확인합니다.

ETL 테스트의 목표는 신뢰할 수있는 데이터를 얻는 것입니다. 테스트주기를보다 효과적으로 만들어 데이터 신뢰성을 얻을 수 있습니다.

포괄적 인 테스트 전략은 효과적인 테스트주기를 설정하는 것입니다. 테스트 전략은 데이터가 이동할 때마다 ETL 프로세스의 각 단계에 대한 테스트 계획을 다루고 비즈니스 분석가, 인프라 팀, QA 팀, DBA, 개발자 및 비즈니스 사용자와 같은 각 이해 관계자의 책임을 명시해야합니다.

모든 측면에서 테스트 준비를 보장하기 위해 테스트 전략이 중점을 두어야하는 핵심 영역은 다음과 같습니다.

테스트 범위-사용할 테스트 기술과 유형을 설명합니다.
테스트 환경 설정.
테스트 데이터 가용성-모든 / 중요한 비즈니스 요구 사항을 다루는 데이터와 같은 생산을하는 것이 좋습니다.
데이터 품질 및 성능 허용 기준.

ETL 테스트에서는 데이터가 예상대로 대상 시스템에 정확하게로드되었는지 확인하기 위해 데이터 정확도가 사용됩니다. 데이터 정확도를 수행하는 주요 단계는 다음과 같습니다.

가치 비교

값 비교에는 소스 및 대상 시스템의 데이터를 최소 또는 변환없이 비교하는 것이 포함됩니다. 다양한 ETL 테스트 도구 (예 : Informatica의 소스 한정자 변환)를 사용하여 수행 할 수 있습니다.

일부 식 변환은 데이터 정확도 테스트에서도 수행 할 수 있습니다. 다양한 집합 연산자를 SQL 문에서 사용하여 소스 및 대상 시스템의 데이터 정확성을 확인할 수 있습니다. 일반적인 연산자는 빼기 및 교차 연산자입니다. 이러한 연산자의 결과는 대상 및 소스 시스템에서 값의 편차로 간주 할 수 있습니다.

중요한 데이터 열 확인

중요한 데이터 열은 소스 및 대상 시스템의 고유 한 값을 비교하여 확인할 수 있습니다. 다음은 중요한 데이터 열을 확인하는 데 사용할 수있는 샘플 쿼리입니다.

SELECT cust_name, Order_Id, city, count(*) FROM customer 
GROUP BY cust_name, Order_Id, city;

메타 데이터 확인에는 매핑 문서에서 소스 및 대상 테이블 구조의 유효성을 검사하는 작업이 포함됩니다. 매핑 문서에는 소스 및 대상 열, 데이터 변환 규칙 및 데이터 유형, 소스 및 대상 시스템의 테이블 구조를 정의하는 모든 필드에 대한 세부 정보가 있습니다.

데이터 길이 확인

대상 컬럼 데이터 유형의 길이는 소스 컬럼 데이터 유형보다 크거나 같아야합니다. 예를 들어 보겠습니다. 소스 테이블에 이름과 성이 있고 각 데이터 길이가 50 자로 정의되어 있다고 가정합니다. 그런 다음 대상 시스템의 전체 이름 열에 대한 대상 데이터 길이는 최소 100 개 이상이어야합니다.

데이터 유형 확인

데이터 유형 검사에는 소스 및 대상 데이터 유형을 확인하고 동일한 지 확인하는 작업이 포함됩니다. 변환 후 대상 데이터 유형이 원본 데이터와 다를 수 있습니다. 따라서 변환 규칙도 확인해야합니다.

제약 / 인덱스 검사

제약 검사에는 설계 사양 문서에 따라 인덱스 값 및 제약 조건을 확인하는 작업이 포함됩니다. Null 값을 가질 수없는 모든 열에는 Not Null 제약 조건이 있어야합니다. 기본 키 열은 디자인 문서에 따라 인덱싱됩니다.

데이터 변환을 수행하는 것은 단일 SQL 쿼리를 작성한 다음 출력을 대상과 비교하여 달성 할 수 없기 때문에 약간 복잡합니다. ETL 테스트 데이터 변환의 경우 변환 규칙을 확인하기 위해 각 행에 대해 여러 SQL 쿼리를 작성해야 할 수 있습니다.

시작하려면 소스 데이터가 모든 변환 규칙을 테스트하기에 충분한 지 확인하십시오. 데이터 변환에 대한 ETL 테스트를 성공적으로 수행하기위한 핵심은 소스 시스템에서 정확하고 충분한 샘플 데이터를 선택하여 변환 규칙을 적용하는 것입니다.

ETL 테스트 데이터 변환의 주요 단계는 다음과 같습니다.

첫 번째 단계는 입력 데이터 및 예상 결과의 시나리오 목록을 만들고이를 비즈니스 고객과 함께 검증하는 것입니다. 이는 설계 중 요구 사항 수집에 대한 좋은 접근 방식이며 테스트의 일부로도 사용할 수 있습니다.
다음 단계는 모든 시나리오를 포함하는 테스트 데이터를 만드는 것입니다. ETL 개발자를 활용하여 시나리오 스프레드 시트로 데이터 세트를 채우는 전체 프로세스를 자동화하여 시나리오가 변경 될 가능성이있는 다용 성과 이동성을 허용합니다.
다음으로 데이터 프로파일 링 결과를 활용하여 대상 데이터와 소스 데이터 사이의 각 필드에서 값의 범위와 제출을 비교합니다.
ETL 생성 필드 (예 : 대리 키)의 정확한 처리를 검증합니다.
웨어 하우스 내의 데이터 유형을 검증하는 것은 데이터 모델 또는 디자인에 지정된 것과 동일합니다.
참조 무결성을 테스트하는 테이블간에 데이터 시나리오를 만듭니다.
데이터에서 상위-하위 관계를 확인합니다.
마지막 단계는 lookup transformation. 조회 쿼리는 집계없이 직선이어야하며 소스 테이블 당 하나의 값만 반환해야합니다. 이전 테스트에서와 같이 소스 한정자에서 조회 테이블을 직접 조인 할 수 있습니다. 그렇지 않은 경우 룩업 테이블을 소스의 기본 테이블과 결합하는 쿼리를 작성하고 대상의 해당 열에있는 데이터를 비교합니다.

ETL 테스트 중 데이터 품질 검사에는 대상 시스템에로드 된 데이터에 대한 품질 검사 수행이 포함됩니다. 다음 테스트가 포함됩니다.

번호 확인

숫자 형식은 대상 시스템에서 동일해야합니다. 예를 들어 소스 시스템에서 열 번호 지정 형식은 다음과 같습니다.x.30, 그러나 대상이 30, 그런 다음 접두사없이로드해야합니다. x. 대상 열 번호에서.

날짜 확인

날짜 형식은 소스 및 대상 시스템 모두에서 일관되어야합니다. 예를 들어 모든 레코드에서 동일해야합니다. 표준 형식은 yyyy-mm-dd입니다.

정밀 검사

정밀도 값은 대상 테이블에 예상대로 표시되어야합니다. 예를 들어 소스 테이블에서 값은 15.2323422이지만 대상 테이블에서는 15.23 또는 15의 반올림으로 표시되어야합니다.

데이터 확인

비즈니스 요구 사항에 따라 데이터를 확인하는 작업이 포함됩니다. 특정 기준을 충족하지 않는 레코드는 필터링해야합니다.

Example − date_id> = 2015 및 Account_Id! = '001'인 레코드 만 대상 테이블에로드되어야합니다.

Null 검사

일부 열은 해당 필드의 요구 사항 및 가능한 값에 따라 Null을 가져야합니다.

Example − Termination Date 열은 활성 상태 열이 "T"또는 "Deceased"가 아닌 한 Null을 표시해야합니다.

기타 수표

From_Date와 같은 일반적인 검사는 To_Date보다 크지 않아야합니다.

데이터 완전성 검사는 대상 시스템의 데이터가로드 후 예상대로인지 확인하기 위해 수행됩니다.

이를 위해 수행 할 수있는 일반적인 테스트는 다음과 같습니다.

집계 함수 확인 (sum, max, min, count),
변환이 없거나 단순 변환이있는 열에 대한 소스와 대상 사이의 실제 데이터와 개수를 확인하고 유효성을 검사합니다.

카운트 유효성 검사

소스 및 대상 테이블의 레코드 수를 비교하십시오. 다음 쿼리를 작성하여 수행 할 수 있습니다.

SELECT count (1) FROM employee; 
SELECT count (1) FROM emp_dim;

데이터 프로필 유효성 검사

여기에는 소스 및 대상 테이블 (팩트 또는 차원)에서 개수, 합계 및 최대 값과 같은 집계 함수 확인이 포함됩니다.

열 데이터 프로필 유효성 검사

고유 값과 각 고유 값에 대한 행 수를 비교하는 작업이 포함됩니다.

SELECT city, count(*) FROM employee GROUP BY city; 
SELECT city_id, count(*) FROM emp_dim GROUP BY city_id;

중복 데이터 검증

여기에는 비즈니스 요구 사항에 따라 고유해야하는 열 또는 열 조합에서 기본 키와 고유 키의 유효성을 검사하는 작업이 포함됩니다. 다음 쿼리를 사용하여 중복 데이터 유효성 검사를 수행 할 수 있습니다.

SELECT first_name, last_name, date_of_joining, count (1) FROM employee
GROUP BY first_name, last_name HAVING count(1)>1;

시스템에 대한 백업 복구는 장애로부터 가능한 한 빨리 시스템을 복원하고 중요한 데이터를 잃지 않고 가능한 한 빨리 작업을 재개하도록 계획되어 있습니다.

ETL 백업 복구 테스트는 데이터웨어 하우스 시스템이 하드웨어, 소프트웨어 또는 데이터 손실과 함께 네트워크 장애로부터 성공적으로 복구되는지 확인하는 데 사용됩니다.

시스템 가용성을 극대화하려면 적절한 백업 계획을 준비해야합니다. 백업 시스템은 쉽게 복원 할 수 있어야하며 데이터 손실없이 장애가 발생한 시스템을 대신해야합니다.

ETL 테스트 백업 복구에는 응용 프로그램 또는 DW 시스템을 하드웨어 구성 요소, 소프트웨어 충돌 등에 대한 극단적 인 조건에 노출하는 것이 포함됩니다. 다음 단계는 복구 프로세스가 시작되고 시스템 확인이 수행되고 데이터 복구가 수행되는지 확인하는 것입니다.

ETL 테스트는 대부분 SQL 스크립트를 사용하고 스프레드 시트에서 데이터를 수집하여 수행됩니다. ETL 테스트를 수행하는이 접근 방식은 매우 느리고 시간이 많이 걸리며 오류가 발생하기 쉬우 며 샘플 데이터에서 수행됩니다.

수동 ETL 테스트의 기술적 과제

ETL 테스트 팀은웨어 하우스 시스템에서 데이터를 테스트하기 위해 SQL 쿼리를 작성하고 SQL 편집기를 사용하여 수동으로 실행 한 다음 데이터를 Excel 스프레드 시트에 넣고 수동으로 비교해야합니다. 이 프로세스는 시간과 리소스를 많이 사용하며 비효율적입니다.

이 프로세스를 자동화 할 수있는 다양한 도구가 시장에 나와 있습니다. 가장 일반적인 ETL 테스트 도구는 QuerySurge 및 Informatica 데이터 유효성 검사입니다.

QuerySurge

QuerySurge는 빅 데이터, 데이터웨어 하우스 및 ETL 프로세스를 테스트하기 위해 설계된 데이터 테스트 솔루션입니다. 전체 프로세스를 자동화하고 DevOps 전략에 잘 맞출 수 있습니다.

QuerySurge의 주요 기능은 다음과 같습니다-

사용자가 SQL을 작성할 필요없이 빠르고 쉽게 테스트 QueryPair를 생성 할 수있는 Query Wizards가 있습니다.
재사용 가능한 쿼리 스 니펫이있는 디자인 라이브러리가 있습니다. 사용자 지정 QueryPair도 만들 수 있습니다.
소스 파일 및 데이터 저장소의 데이터를 대상 데이터웨어 하우스 또는 빅 데이터 저장소와 비교할 수 있습니다.
수백만 개의 데이터 행과 열을 몇 분 안에 비교할 수 있습니다.
사용자는 (1) 즉시, (2) 임의의 날짜 / 시간 또는 (3) 이벤트가 종료 된 후 자동으로 실행되도록 테스트를 예약 할 수 있습니다.
유익한 보고서를 생성하고, 업데이트를보고, 결과를 팀에 자동 이메일로 보낼 수 있습니다.

전체 프로세스를 자동화하려면 ETL 소프트웨어가로드 프로세스를 완료 한 후 ETL 도구가 명령 줄 API를 통해 QuerySurge를 시작해야합니다.

QuerySurge는 자동으로 무인 실행되어 모든 테스트를 실행 한 다음 결과와 함께 팀의 모든 사람에게 이메일을 보냅니다.

QuerySurge와 마찬가지로 Informatica Data Validation은 개발 및 프로덕션 환경에서 ETL 테스트 프로세스를 가속화하고 자동화하는 데 도움이되는 ETL 테스트 도구를 제공합니다. 이를 통해 더 짧은 시간에 완전하고 반복 가능하며 감사 가능한 테스트 범위를 제공 할 수 있습니다. 프로그래밍 기술이 필요하지 않습니다!

데이터웨어 하우스 시스템 또는 BI 애플리케이션을 테스트하려면 데이터 중심 접근 방식이 필요합니다. ETL 테스트 모범 사례는 테스트를 수행하는 데 드는 비용과 시간을 최소화하는 데 도움이됩니다. 최종 사용자를위한 고품질 대시 보드 및 보고서를 생성하는 대상 시스템에로드 할 데이터의 품질을 향상시킵니다.

여기에 ETL 테스트를 위해 따를 수있는 몇 가지 모범 사례를 나열했습니다.

데이터 분석

올바른 데이터 모델을 설정하려면 데이터를 분석하여 요구 사항을 이해하는 것이 매우 중요합니다. 요구 사항을 이해하고 대상 시스템에 대한 올바른 데이터 모델을 갖는 데 시간을 투자하면 ETL 문제를 줄일 수 있습니다. 또한 소스 시스템, 데이터 품질을 연구하고 ETL 모듈에 대한 올바른 데이터 유효성 검사 규칙을 구축하는 것도 중요합니다. ETL 전략은 소스 및 대상 시스템의 데이터 구조를 기반으로 작성되어야합니다.

소스 시스템에서 잘못된 데이터 수정

최종 사용자는 일반적으로 데이터 문제를 알고 있지만 해결 방법을 모릅니다. 이러한 오류를 찾아 ETL 시스템에 도달하기 전에 수정하는 것이 중요합니다. 이 문제를 해결하는 일반적인 방법은 ETL 실행 시간에 있지만 가장 좋은 방법은 소스 시스템에서 오류를 찾고 소스 시스템 수준에서 오류를 수정하는 조치를 취하는 것입니다.

호환되는 ETL 도구 찾기

일반적인 ETL 모범 사례 중 하나는 소스 및 대상 시스템과 가장 호환되는 도구를 선택하는 것입니다. 소스 및 대상 시스템에 대한 SQL 스크립트를 생성하는 ETL 도구의 기능은 처리 시간과 리소스를 줄일 수 있습니다. 이를 통해 가장 적합한 환경 내 어디에서나 변환을 처리 할 수 있습니다.

ETL 작업 모니터링

ETL 구현 중 또 다른 모범 사례는 ETL 작업의 스케줄링, 감사 및 모니터링으로로드가 예상대로 수행되는지 확인하는 것입니다.

증분 데이터 통합

때로는 데이터웨어 하우스 테이블의 크기가 더 커서 모든 ETL주기 동안 새로 고칠 수 없습니다. 증분로드는 마지막 업데이트 이후 변경된 레코드 만 ETL 프로세스로 가져 오도록하고 확장 성과 시스템 새로 고침에 걸리는 시간에 큰 영향을줍니다.

일반적으로 소스 시스템에는 변경 사항을 쉽게 식별 할 수있는 타임 스탬프 나 기본 키가 없습니다. 이러한 문제는 프로젝트의 후반 단계에서 확인 될 경우 비용이 많이들 수 있습니다. ETL 모범 사례 중 하나는 초기 소스 시스템 연구에서 이러한 측면을 다루는 것입니다. 이 지식은 ETL 팀이 변경된 데이터 캡처 문제를 식별하고 가장 적절한 전략을 결정하는 데 도움이됩니다.