[2. ETL 구축] 2-1. ETL의 서브시스템

34개의 ETL 서브시스템

ETL 시스템 아키텍쳐는 34개의 핵심적인 서브시스템으로 이루어진다.

 

서브시스템들은 4개의 주요 프로세스로 구분된다.

I. 추출

원천으로부터 데이터의 변화 없이 ETL 환경의 디스크에 쓰는 프로세스

 

1. 데이터 프로파일링

DW에 적재하기에 적절한 데이터 소스인지, 데이터 소스에 어떠한 데이터가 있는지 등을 파악하는 단계이다.

 

데이터 프로파일링은 데이터의 내용, 일관성, 구조를 설명하는 기술적 분석 과정이다. SELECT DISTINCT와 같은 쿼리 또한 프로파일링의 일종으로 볼 수 있다.

 

이 과정을 통해 좀 더 나은 데이터 수집 방법, 개발 일정 등 요구 수준에 맞게 계획을 세울 수 있다.

 

데이터 프로파일링은 신뢰도 있는 ETL 시스템 구축의 첫번째 단추이다.

2. CDC 시스템

CDC는 각 상황에 맞는 효과적인 방식이 몇가지 있다.

• 감사 칼럼
• 시간 기준 추출
• 전체 변경 사항 비교
• 데이터베이스 로그 시스템
• 메시지 큐 모니터링

3. 데이터 추출 시스템

오래되거나 복잡한 환경에서 추출할 땐 플랫파일, 데이터베이스에서 추출할 땐 스트림 형식 등으로 파일을 추출하는 과정을 포함하는 시스템이다.

 

플랫파일을 분산 병렬 처리하기 위해 MapR 과정을 추가하거나 추출과 동시에 변환을 정의하는 스트림을 구성할 수 있다.

 

II. 정제와 표준화

차원을 위한 표준 디멘션, 팩트를 위한 또는 표준 메트릭을 생성하기 위해 데이터의 병합, 가공 등의 처리 과정을 거치는 프로세스

 

4. 데이터 정제 시스템

데이터 품질을 검사하고 불량 데이터를 탐지했을 경우에 이를 분류해내는 시스템이다. 데이터 품질 필터의 역할을 하는 시스템의 구성 요소를 품질 스크린이라고 부른다.

 

품질 스크린은 단일 칼럼의 데이터를 테스트 하는 칼럼 스크린, 칼럼 데이터들 간의 관계를 테스트 하는 구조 스크린, 복잡한 비즈니스 규칙이나 임계치를 테스트 하는 비즈니스 규칙 스크린의 세가지 범주로 분류된다.

 

품질 스크린에서 발생한 이슈에 대응하는 방법 또한 세가지가 있다. ETL 프로세스를 멈추거나, 오류 데이터를 파일에 기록해두고 사후 처리를 진행하거나, 오류 데이터에 간단한 태그를 달아 프로세스를 이어가는 방식이다.

5. 오류 스키마

오류 처리 스키마는 ETL 흐름 여러 곳에 위치한 품질 스크린에 의해 걸러지는 모든 오류를 기록하기 위한 중앙 집중화된 다차원 스키마이다.

 

일반적으로 오류 기록 팩트 테이블, 오류 발생 일자 차원, 오류가 발생한 배치 프로그램 차원, 오류가 발생한 스크린 차원으로 이루어진다.

6. 감사 디멘션

감사 디멘션(Audit dimention)은 ETL 개발자나 IT 관리자, 데이터 품질에 관심이 있는 특정 비즈니스 사용자가 사용할 수 있는 차원이다.

 

팩트 테이블의 행을 처리할 시기에 이상 데이터, 산정 로직 버전 정보 등 ETL 프로세스의 사이니지를 가진다.

7. 중복 제거 시스템

여러 원천 데이터베이스를 가진 시스템에서, 종종 다수의 데이터를 하나로 병합하거나 중복 데이터를 제거해야 할 때 사용하는 시스템이다.

 

한 곳의 시스템에서 작업을 한번에 수행하기엔 어렵기 때문에, 부분적 중복제거 및 병합 작업을 ETL 과정에 걸쳐 수행할 수 있다.

8. 표준화 시스템

유사한 컬럼을 가지는 레코드들의 내용을 통일하여 서로 다른 원천에서 온 데이터를 표준화 하는 시스템이다.

 

III. 전달

최종 차원 모델에 데이터를 적재하고 물리적으로 구성하는 프로세스

 

9. 차원 데이터 이력 관리 시스템

ETL 시스템은 DW에 이미 저장된 값이 지속적으로 변경될 때 이를 처리할 방안을 마련해야 한다.

slowly changing dimension stages

 

slowly changing dimension in Amazon Redshift

10. 대체 키 생성기

차원 테이블에 존재하는 대체키를 DBMS의 트리거를 통해 생성할 경우, 성능상이 병목이 생길 확률이 높다. DBMS를 사용한다면 시퀀스 생성기를 호출하는 편이 좋고, 효율성을 극대화 시키려면 ETL 툴에서 대체 키를 생성하고 관리하는 것이 좋다.

11. 디멘션 계층 관리 시스템

 

12. 특수 디멘션 관리 시스템

일자, 정크, 미니 차원과 같은 특수한 목적의 차원 테이블을 관리하는 시스템이다. 다음과 같은 차원들이 이곳에서 관리된다.

• 일자/날짜 디멘션
• 정크 디멘션
• 미니 디멘션
• 축소 디멘션
• 소규모 정적 디멘션
• 사용자 관리 디멘션
• …

13. 팩트 테이블 적재 시스템

트랜잭션, 주기적 스냅샷, 점진적 스냅샷 총 세 가지 주요 유형의 팩트 테이블에 적재하는데 효과적인 ETL 아키텍처적 요구 사항에 집중하는 시스템이다.

14. 대체 키 파이프라인

팩트 테이블에서 참조하는 차원 테이블의 데이터가 없거나 잘못된 참조를 할 상황을 방지하기 위해, ETL 프로세스는 적절한 절차를 거치며 수행되어야 하는 파이프라인 형식을 가져야 한다.

 

파이프라인을 구성할 때 일반적으로 다음과 같은 고려사항과 절차를 가진다.

1. 디멘션 테이블을 우선적으로 갱신 처리 한다.
2. 원천 팩트 데이터의 원본 키를 대체 키인 디멘션 테이블의 기본키로 대체한다.
   • 원본 키와 일치하는 대체 키를 찾기 위해 디멘션 테이블의 모든 행을 검색한다. 필요하다면 데이터 유효성을 체크한다.
   • 검색 성능을 위해 가능하다면 디멘션 테이블의 모든 데이터는 메모리 상에서 처리되는것이 좋다.
   • 팩트 데이터는 모든 처리 단계가 끝나지 전까진 디스크에 쓰지 않는다.
3. 키 충돌이 인식되었을 때의 파이프라인 처리 중단 여부를 결정하고, 중단점에서부터 작업을 재개할 지에 대한 비즈니스 규칙을 적용하며 오류 스키마에 해당 로우를 기록한다.

15. 차원 브리지 생성 시스템

 

16. 지연 도착 데이터 제어 시스템

실시간 환경에서 데이터의 도착이 지연되어 무결성에 문제가 발생했을 때 이를 제어하기 위한 시스템이다.

 

문제가 발생하는 두가지의 상황에 대해 제어가 필요하다.

• SCD Type 2 방식의 차원 테이블에 갱신 지연이 있을 때
• 차원 테이블에 최신 데이터가 지연된 상황
• 차원 테이블에 추가 지연이 있을 때
• 차원 테이블에 해당 원천 데이터의 이력이 없는 상황

17. 디멘션 관리자

디멘션 관리자는 DW에서 표준 디멘션을 생성하고 공급하는 중앙 관리자이다.

 

조직 내에 다수가 있을 수 있는 차원 관리자는 아래와 같은 책임을 가지고 있다.

• 디멘션 설계 시 데이터 담당자와 사용자 등 이해관계자들이 동의한 공통된 설계를 정의한다.
• 새로운 원천 데이터가 발생했을 때 표준 디멘션에 레코드를 추가하고 새로운 대체키를 생성한다.
• 원천 데이터가 갱신되었을 때 SCD Type 2 방식의 표준 디멘션에 레코드를 추가하고 새로운 대체키를 생성한다.
• 원천 데이터가 갱신되었을 때 SCD Type 1, 3 방식의 표준 디멘션에서 대체키를 제외한 레코드를 수정한다. 이후 디멘션에 대한 버전을 갱신한다.
• 모든 팩트 테이블 공급자에게 새로운 버전의 디멘션을 복제하여 동시 배포한다.

18. 팩트 공급자

팩트 공급자는 디멘션 관리자로부터 표준 디맨션을 전달 받으며, 하나 또는 그 이상의 팩트 테이블에 대한 관리와 그들의 생성, 유지 보수, 사용의 책임을 가진다.

• 디멘션 관리자로부터 복제된 디멘션을 수신 또는 다운로드 한다.
• 원천 키를 적절한 대체 키로 교체한 후 팩트 테이블에 신규 로우를 추가한다.
• 누적 스냅샷, 오류, 처리 지연 데이터들에 대해 모든 팩트 테이블 내의 로우를 수정한다.
• 쓸모 없어진 집계를 제거한다.
• 디멘션의 새로운 배포나 버전에 영향을 받는 집계를 재처리 한다.
• 기반이 되는 모든 팩트 테이블과 집계 팩트 테이블에 대해 품질을 보증한다.
• 갱신된 팩트 테이블과 디멘션 테이블을 연결한다.
• 데이터베이스가 갱신되었음을 사용자에게 알린다.

19. 집계 생성자

집계는 성능 향상을 위한 특별한 데이터 구조라는 점에서 인덱스와 같은 것이다.

 

ETL 시스템과 집계 생성자는 많은 자원과 처리 시간을 소비하거나 혼란스럽게 만들지 않으면서 효과적으로 집계를 생성하고 사용해야 한다.

20. OLAP 큐브 생성자

 

21. 데이터 전달 관리자

 

IV. 관리

ETL 시스템과 프로세스를 일관성 있게 관리하는 프로세스

 

22. 잡 스케줄러

전체 ETL 프로세스는 단일한 메타데이터 기준의 잡(Job) 통제 환경을 기반으로 관리되어야 하고, 확장이 가능해야 한다.

 

스케줄링은 잡들을 실행하는 것 이상의 것이다. 스케줄러는 ETL 잡들 사이의 관계와 종속성을 인지하고 제어할 필요가 있다. 파일 또는 테이블이 처리할 준비가 되었을 때를 인식해야 한다.

 

스케줄러는 잡 정의, 잡 스케줄링, 메타데이터 수집, 로깅, 알림의 기능을 포함해야 한다.

23. 백업 시스템

DW를 위한 백업은 보통 물리적인 백업이며, 특정 시간에 생성된 데이터베이스 이미지로 인덱스와 물리적인 구성 정보를 포함한다.

 

백업 시스템은 아래와 같은 기능을 제공해야 한다.

• 고성능 - 백업은 할당된 시간을 맞춰야 한다.
• 단순한 관리 - 관리 인터페이스는 백업, 스케줄 생성, 백업 확인이 용이한 툴을 제공해야 하며, 이를 위해 복구를 로깅해야 한다.
• 자동화 - 저장소 관리, 자동화된 스케줄링, 장치의 제어, 리포팅, 알림 기능을 제공해야 한다.

24. 복구 및 재시작 시스템

네트워크, DB, 메모리 등 각종 오류로 인해 ETL 처리 작업이 도중에 중단되었을 때 문제 지점을 인식하고 이를 복구하거나 재시작 할 수 있어야 한다.

 

팩트 테이블의 유일키가 되는 대리키는 이 시점에서 활용된다. 팩트 테이블에 데이터가 추가될 때마다 순차적으로 할당되는 단순한 정수형의 대리키는 적재 도중 중단된 시점을 쉽게 확인할 수 있게 해준다.

25. 버전 관리 시스템

ETL 파이프라인 상의 작업과 메타데이터, 코드의 버전을 관리해야 한다. Git과 같은 버전 관리 도구를 사용할 수 있다.

26. 버전 이관(CI/CD) 시스템

개발 및 테스트 환경에서 완성된 버전을 운영 환경으로 이관하는 시스템이다.

 

Git과 더불어 Git Action과 같은 도구를 사용할 수 있다.

27. 워크플로우 모니터링

일관성, 신뢰성, 가용성 있는 DW를 구축하기 위해 ETL 시스템은 ETL 작업이 정상적으로 작동함을 보장하도록 지속적인 모니터링을 제공해야 한다.

 

워크플로우 모니터링 시스템에선 모든 작업의 정지, 실행, 완료, 지연 상태를 실시간으로 확인하고 작업의 로그를 확인할 수 있어야 하며, 하드웨어 모니터링 시스템에선 CPU 사용률, 메모리 할당, 디스크 사용, 버퍼, DB 성능 등 인프라 성능을 측정하고 확인할 수 있어야 한다.

28. 정렬 처리 시스템

일반적인 ETL 시스템에선 특정 순서로 정렬된 데이터를 필요로 하기 때문에, DBMS의 정렬 기능이나 효율적인 파일 데이터 정렬 도구를 사용할 수 있어야 한다.

29. 선행/후행 흐름 분석 시스템

선행흐름 분석이란, BI 대시보드나 레포트의 계산된 데이터부터 시작해 처리 과정 도중 거친 중간 테이블, 원천 DB까지 수행되어왔던 변환 작업을 확인하는 것이다.

 

후행흐름 분석이란. 원천 DB 또는 중간 테이블 부터 파생되거나 변환되어 결과로 나타내어지는 BI 대시보드와 레포트를 확인하는 것이다.

 

ETL 시스템은 이러한 선행, 후행흐름 분석이 가능하여야 한다.

30. 오류 통지 시스템

 

31. 병렬 처리/파이프라인 시스템

ETL 시스템은 주어진 짧은 시간 내에 DW의 적재를 끝내기 위해 일반적으로 병렬 처리 기술을 사용해야 한다.

32. 보안 시스템

 

33. 규제 관리 시스템

DW는 정부와 법률의 규제요건을 충족하여야 한다.

34. 메타데이터 저장소 관리자