ㅁ 데이터 통합

ㅇ 정의:
서로 다른 출처의 데이터를 하나의 일관된 형식과 구조로 결합하여 분석 및 활용이 가능하도록 만드는 과정.

ㅇ 특징:
– 데이터 포맷, 스키마, 단위 등이 서로 다른 경우 변환 과정 필요
– 중복 제거, 키 매핑, 참조 무결성 확보가 필수
– 배치 또는 실시간 방식으로 수행 가능

ㅇ 적합한 경우:
– 여러 시스템에서 생성된 데이터를 통합 분석해야 하는 경우
– 데이터 웨어하우스, 데이터 레이크 구축 시

ㅇ 시험 함정:
– 데이터 통합과 데이터 수집, 데이터 변환 개념 혼동
– 통합 과정에서 데이터 품질 저하 가능성 간과

ㅇ 시험 대비 “패턴 보기” 예시:
O: “서로 다른 시스템의 데이터를 일관된 형식으로 결합하는 과정”
X: “데이터를 단순히 한 곳에 모으는 과정”

================================

1. ETL

ㅇ 정의:
Extract(추출) → Transform(변환) → Load(적재) 순서로 데이터 웨어하우스에 데이터를 적재하는 전통적 통합 방식.

ㅇ 특징:
– 변환을 적재 전에 수행하여 데이터 웨어하우스에 깨끗한 데이터 저장
– 배치 처리에 적합
– 변환 과정이 중앙 집중화되어 관리 용이

ㅇ 적합한 경우:
– 데이터 변환 로직이 복잡하고 사전에 품질 보장이 필요한 경우
– 전통적인 관계형 데이터 웨어하우스를 사용하는 경우

ㅇ 시험 함정:
– ETL과 ELT 순서 혼동
– 실시간 처리에는 상대적으로 부적합함을 간과

ㅇ 시험 대비 “패턴 보기” 예시:
O: “데이터 변환을 저장 전에 수행하는 방식”
X: “데이터를 적재한 후 변환하는 방식”

================================

2. ELT

ㅇ 정의:
Extract(추출) → Load(적재) → Transform(변환) 순서로, 원시 데이터를 먼저 저장 후 변환하는 방식.

ㅇ 특징:
– 데이터 레이크, 클라우드 기반 DW에서 많이 사용
– 저장소의 확장성과 처리 성능을 활용해 변환 수행
– 원본 데이터 보존 가능

ㅇ 적합한 경우:
– 다양한 분석 요구에 따라 변환 로직이 자주 변경되는 경우
– 대규모 데이터 처리와 확장성이 중요한 경우

ㅇ 시험 함정:
– ETL과 순서 혼동
– 변환 시 저장소 자원 사용량 증가 가능성 간과

ㅇ 시험 대비 “패턴 보기” 예시:
O: “데이터를 먼저 적재한 후 변환하는 방식”
X: “변환 후 적재하는 전통적 방식”

================================

3. 데이터 파이프라인

ㅇ 정의:
데이터의 수집, 처리, 저장, 분석까지의 흐름을 자동화하는 일련의 처리 단계.

ㅇ 특징:
– 배치, 스트리밍 모두 가능
– 다양한 데이터 소스와 싱크를 연결
– 모듈화, 재사용성, 확장성이 중요

ㅇ 적합한 경우:
– 지속적인 데이터 흐름이 필요한 서비스(예: 로그 수집, 실시간 분석)
– 데이터 처리 자동화 필요 시

ㅇ 시험 함정:
– 단순 스크립트 작업과 혼동
– 파이프라인 구성 요소(소스, 변환, 싱크) 누락

ㅇ 시험 대비 “패턴 보기” 예시:
O: “데이터 흐름을 자동화하는 처리 단계 집합”
X: “데이터를 수동으로 옮기는 작업”

================================

4. CDC(Change Data Capture)

ㅇ 정의:
데이터베이스에서 변경된 데이터(삽입, 수정, 삭제)를 실시간 또는 준실시간으로 감지하고 전송하는 기술.

ㅇ 특징:
– 변경된 데이터만 전송하여 효율성 높음
– 로그 기반, 트리거 기반, 타임스탬프 기반 등 구현 방식 다양
– 실시간 데이터 동기화에 유리

ㅇ 적합한 경우:
– 운영 DB와 분석 DB 간 실시간 동기화 필요 시
– 마이크로서비스 간 데이터 일관성 유지

ㅇ 시험 함정:
– 전체 데이터 덤프 방식과 혼동
– CDC가 항상 즉시 전송하는 것으로 오해

ㅇ 시험 대비 “패턴 보기” 예시:
O: “변경된 데이터만 추출하여 전송하는 기술”
X: “전체 데이터를 매번 전송하는 방식”

ㅁ 추가 학습 내용

[정리]
ETL과 ELT의 차이
– 순서:
ETL(Extract → Transform → Load) : 변환을 로드 전에 수행
ELT(Extract → Load → Transform) : 변환을 로드 후 대상 시스템에서 수행
– 변환 위치:
ETL: 별도의 ETL 서버/도구에서 변환
ELT: 데이터 웨어하우스나 DB 내부에서 변환
– I/O 부하:
ETL: 변환 시 중간 저장소 I/O 발생, 네트워크 전송 부하가 상대적으로 큼
ELT: 로드 후 변환하므로 대량 적재 시 I/O 효율적일 수 있으나, 대상 시스템 부하 증가 가능
– 처리 시점 장단점:
ETL: 변환 품질 제어 용이, 로드 전 데이터 정제 가능
ELT: 로드 속도 빠름, 대상 시스템 성능에 의존

데이터 파이프라인 오케스트레이션 도구
– Airflow: DAG 기반 워크플로우, 스케줄링 및 모니터링 강점
– Luigi: 파이썬 기반, 의존성 관리 중심
– Apache Beam: 배치/스트리밍 통합 처리, 다양한 런타임 지원

CDC(Change Data Capture) 방식 비교
– 로그 기반: DB 트랜잭션 로그 활용, 부하 최소화, 실시간성 우수, 구현 복잡
– 트리거 기반: 구현 간단, DB에 부하 큼, 대량 변경 시 성능 저하

데이터 통합 시 고려사항
– 스키마 매핑: 서로 다른 스키마 구조를 일치시키는 작업
– 키 충돌 해결: 중복 키 처리, 키 재생성 또는 매핑
– 데이터 품질 관리(DQ) 기법:
표준화(Standardization): 형식, 단위, 코드 일관성 유지
정규화(Normalization): 중복 제거, 데이터 구조 최적화

[시험 대비 체크리스트]
1. ETL과 ELT의 단계 순서를 정확히 구분할 수 있는가?
2. 변환 위치와 그에 따른 I/O 부하 차이를 설명할 수 있는가?
3. ETL과 ELT 각각의 장단점을 처리 시점 기준으로 비교할 수 있는가?
4. Airflow, Luigi, Apache Beam의 특징과 차이를 알고 있는가?
5. CDC의 로그 기반 방식과 트리거 기반 방식의 장단점을 비교할 수 있는가?
6. 데이터 통합 시 스키마 매핑 절차를 설명할 수 있는가?
7. 키 충돌 해결 방법을 제시할 수 있는가?
8. 데이터 품질 관리 기법(표준화, 정규화)의 정의와 목적을 알고 있는가?