그동안 실전에서 갈고 닦은 지식과 경험을 글로 정리해 보았습니다.
사실 CDC든 ETL이든 원천(source) 데이타 정보를 추출하여 목표(target) 시스템에 적재하는 개념은 동일하나 그 방법과 사용목적, 적재수준에서 차이가 발생하게 됩니다.
따라서 이번에는 CDC(Change Data Capture)와 ETL(Extract-Transform-Load)과의 차이점을 살펴보도록 하겠습니다.
1.CDC (Chage Data Capture)
1) 주목적 : 실시간(real time) 또는 준실시간(near real time)으로 원천 시스템(기간계,업무계) 데이타를 읽어 들여 정보계 시스템 또는 후선업무 시스템 등에 정보를 넘겨 어떤 처리를 하고자 할 때 사용하는 방식입니다.
실시간 또는 준실시간에 대한 요건은 해당 사이트마다 서로 다르기 때문에 다 열거할 수는 없겠지만 한가지 예를 들면 , 조기경보시스템을 운영하는 사이트에서 고객이 5천만 이상을 인출할 시 조기경보 시스템에서 실시간으로 경보(Alert)을 발생시키게끔 모니터링를 해 볼수 있겠죠.
2) 사용 기술 : 모든 거래 발생 이벤트를 추적해야 하므로, DBMS의 종류에 관계없이 변경 이력을 관리하는 DB Archive Log를 주로 사용합니다. CDC 솔루션의 데몬(Demon)이 떠서 일정 시간별로 archive log를 읽어 들여 타겟 시스템에 쌓는 방식으로 대부분 작동하게 됩니다.
대대수의 경우 주로 실시간 기간계 복제용으로 사용하고 있으며 후선업무를 위해 특정 데이타 도착을 알리는 이벤트를 포함하는 개발된 경우가 많습니다.
일부 사이트에서는 실시간으로 데이타를 추출할 원천 테이블에 트리거(trigger)를 걸어 처리하는 방식도 있기는 하지만, 트리거를 사용했을 때의 위험성(dead lock, 또는 오작동, 에러시 추적 어려움)이 너무 커서 권장할 만한 방법은 아닌 것 같습니다.
3) 적재 수준 : 위에서 설명한 대로 원천 테이블이 아닌 시스템 테이블인 archive log를 읽어 처리하므로 적재주기(시간,일,월)에 관계없이 모든 원천 데이타의 변경사항(inset,update,delete)이 적재 대상이 되게 됩니다.
2. ETL (Extract - Transform - Load)
1) 주목적 : 업무계(기간계) 시스템의 하루일과를 다 끝내고 저녁에 기간계 배치(batch)프로그램까지 다 실행되어 기간계에서 필요한 집계처리까지 마무리 한 상태어서 이들 데이타(원장,거래,집계)을 정보계 시스템에 넘겨 어떤 처리를 하고자 할 때 사용하는 방식입니다.
2) 사용 기술 : CDC와 달리 시스템 테이블에 접근하는 것이 아니라 기간계의 원장테이블, 거래테이블, 집계테이블을 대상으로 그날 변경분을 찾아 변경분만을 정보계 시스템에 전달하는 방식을 주로 사용합니다. 만약 변경분을 인식할 수 있는 컬럼이 존재하지 않는 다면 매일매일 해당 테이블의 모든 데이타를 ALL-COPY 방식으로 적재해야 합니다.
따라서 DW설계시에 ETL 대상의 원천테이블 목록이 정리되었다면 반드시 변경분만을 추출할 수 있는 환경이 되어 있는지 모든 테이블별로 확인해 합니다.
가령 변경분만을 적재하는 방식으로 ETL을 구성하려고 한다면, 아래의 3가지 조건을 만족하는지 체크해야합니다.
[ ETL 변경분 적재 방식 적용시 전제 사항 ]
(1) 변경분을 인식할 수 있는 컬럼이 존재하는가? (수정일시, 조작일시 등)
(2) 변경분을 인식할 수 있는 컬럼이 존재한다면, 어떤 상황에서도 이 컬럼이 핸들링 되는가?
(3) 삭제시 해당 레코드가 물리적으로 삭제되지 않는가? (논리적 삭제는 OK, 삭제여부='Y' 등)
위의 조건을 만족하지 못하는 테이블에 대해서는 ALL-COPY 방식의 적재를 할수 밖에 없습니다.
고객 테이블이라든가, 거래내역 테이블이라 든가 엄청 큰 테이블을 전체 적재 방식으로 하게 되면 부하가 상당하며 ETL 작업시간도 많이 소요되게 됩니다. 따라서 사전에 면밀한 검토가 필요합니다.
차후에 애기 되겠지만 ALL-COPY 방식의 적재는 이력 테이블을 구축할 때 상당히 부담히 될 수 있습니다
변경분을 알 수 없으므로, 전일 데이타와 오늘 가져온 데이타를 한건 한건 일일이 변경이 있었는지 비교하여 변경분을 찾아 낸 다음 이력을 쌓아야 하는 부담이 생기는 것입니다.
3) 적재 수준 : ETL은 기간계의 원장테이블, 거래테이블, 집계테이블을 원천 데이타로 하기 때문에 적재주기(시간,일,월)에 따라 적재 수준이 정해지게 됩니다.
즉, 적재 주기가 2시간 간격으로 정해져 있다면, 적재 수준은 2시간 마다의 최종 데이타로 한정되게 됩니다.
예를 들면, 9시~11시 데이타를 적재할 때 9시 5분에 update, 9시 50분에 delete, 10시 25분의 update의 모든 이벤트를 알 수 없고 오직 11시, 그시점의 데이타를 인식한다는 뜻입니다.
어찌보면 이처럼 적재 수준의 차이가 CDC와 ETL의 가장 큰 차이라고 할 수 있습니다.
만약 적재 주기가 일별이라면 업무중에 발생된 모든 이벤트 중의 최종 이벤트만이 테이블에 남아 있으므로 적재 수준은 일(DAY)단위로 정해지겠습니다. 물론 모든 변경 이벤트가 필요하면 기간계의 이력 테이블을 정보계로 읽어 오면 변경 내역을 추적할 수 는 있겠죠.
'시스템 관리 > 인프라구조' 카테고리의 다른 글
| [스크랩] javacore / heapdump 분석 발생 (0) | 2014.11.24 |
|---|---|
| [스크랩] WEB서버와 WAS (0) | 2014.06.12 |