[TALEND] 데이터 정합성 검증하는 방법

이번 포스팅에서는 ETL 과정 자체만큼 중요하다고 볼 수 있는 검증 작업에 대한 얘기를 해보려한다. 데이터의 퀄리티와 ETL 작업 정상 완료 결과를 뒷받침하는 검증 작업은 크게 SQL 쿼리 또는 Talend 툴을 사용하여 진행했다. 내가 진행한 프로젝트에서 사용된 모든 검증 쿼리와 팁들을 공유할 수는 없겠지만 ETL 후 검증 작업에는 어떠한 것들이 포함되는지 그 대략적인 흐름을 공유해 볼 것이다. 

 

1. SQL 쿼리 사용 

SQL 쿼리를 사용한 검증은 크게 두 가지로 구분된다. 첫번째는 이관 전후 소스와 타겟 테이블의 데이터 건수를 비교하는 것이다. 전체 데이터 건수를 비교하고 기준 칼럼 별 건수를 비교하는 방식으로 1차 검증이 진행된다. 

데이터 건수로 검증

두번째는 테이블 성격에 따라 cleansing rule을 적용한 경우 해당 rule이 적절히 반영되었는지 쿼리로 확인하는 작업이다. 예를 들어 이메일 데이터가 특정 도메인 주소를 따르고 있는지, 시간 데이터가 5분 단위로 설정되어 있는지, 계층 구조 데이터가 부모-자식 형태로 잘 매핑되어 있는지를 확인하는 경우를 들 수 있다. 전자의 두 경우는 정규표현식으로, 후자의 경우는 with 구문을 사용한 계층 구조 쿼리로 검증하였다. 

 

2. Talend 사용 

Talend를 사용한 검증은 크게 세 케이스로 구분할 수 있다. 첫번째는 PK를 기준으로 모든 소스 데이터가 문제없이 타겟 테이블로 이관되었는지 확인하는 Job을 통해 데이터 정상 이관 여부를 확인할 수 있다. 

PK 기준 검증

위 예시에서 소스 테이블은 MariaDB와 Oracle로 구분되어 있고 이 두 개로 나뉜 소스의 데이터를 전부 bird_big_families 테이블에 이관하는 작업을 마치고 모든 소스 데이터가 타겟에 이관되었는지 위 Job을 통해 확인할 수 있다.

tMap 설정

소스와 타겟을 PK를 기준으로 Join하기 위해 row1에 연결된 소스 테이블의 PK family_id를 row2에 연결된 타겟 테이블의 family_id 섹션에 드래그한다. 그리고 Join Model을 Inner Join으로 변경해준다. Default 값은 Left Outer Join이다. 그리고 out1 에서 Catch Lookup Inner Join 값을 true 로 설정해주면 소스와 타겟의 데이터를 PK (family_id)를 기준으로 비교한 후 Inner Join되지 않은 여집합을 가져온다. 아래 Oracle 소스 테이블도 동일한 설정을 해준다. 

 

이대로 Job을 실행한 후 결과 값이 0이면 PK를 기준으로 모든 소스 데이터가 타겟 테이블에 이관되었음을 확인할 수 있다. 

 

두번째 방식은 전체 칼럼을 기준으로 소스와 타겟을 비교하는 것이다. PK만을 기준으로 할 경우 소스와 타겟의 데이터가 전부 100% 동일한지 장담할 수 없다. 데이터를 만지다보면 뜻밖의 상황을 마주하는 경우가 많다. 동일한 PK를 가졌지만 알고보면 다른 데이터인 경우가 있을 수 있고 N차로 데이터 이관이 이루어지는 상황에서 타겟에 미리 이관된 데이터가 신규 시스템을 통해 수정될 가능성도 있기 때문이다. 이러한 내용을 파악할 때 모든 칼럼을 기준으로 데이터를 비교하는 로직이 아주 유용하게 쓰일 수 있다. 

 

tMap 설정

tMap을 열어 약간의 설정을 추가해보자. 소스와 타겟의 PK만 매핑한 이전과 달리 이번 예시에서는 모든 칼럼을 매핑하였다. 이때, Join Model과 Catch lookup inner join reject 설정은 Inner Join, true로 이전과 동일한 설정을 유지한다. 이제 Job을 실행해보자. 

 

아까와는 다르게 결과값이 1이 나오는 것을 확인할 수 있다. 이는 모든 칼럼으로 비교 시 소스와 타겟의 데이터 중 하나가 다르다는 것을 의미한다. tLogRow를 통해 출력된 결과를 살펴보자. 

tLogRow 결과

family_id가 115인 데이터가 출력되었다. 실제 데이터를 보고 확인해보자. 

데이터 비교 

소스와 타겟의 family_id가 115인 데이터를 비교해보자. 둘은 같은 데이터일까? PK는 동일하지만 엄연히 다른 데이터이다. 사용자가 데이터를 수정했을 수도 있고 이관 작업 도중 발생한 오류일 수도 있다. 위와 같은 방식으로 소스와 타겟의 오류를 선별하였으니 남은 일은 원인을 파악하고 필요시 보정하는 작업이다. 이렇게 Talend를 활용하면 까다로운 작업을 간단하게 수행할 수 있다. 

 

마지막 Talend를 이용한 검증 방식은 하나 이상의 소스를 타겟에 이관하고 소스의 형식이 달라 첫번째의 방식으로 검증이 불가능한 경우이다. 쿼리로 합계나 기준 칼럼으로 집계가 불가능하기 때문이다. 이때는 tAggregateRow 컴포넌트를 이용하면 된다. 이 케이스의 경우 이미 이전 포스팅에서 다룬 내용이 있으니 이를 참고하면 된다. 

2021.04.07 - [TALEND] - [TALEND] 서로 다른 소스 데이터 집계하기

[TALEND] 서로 다른 소스 데이터 집계하기

 

이렇게 실무에서 경험한 내용을 바탕으로 ETL 수행 후 쿼리 또는 Talend 를 사용하여 검증하는 몇가지 방식을 소개했다.