All
4장에서는 다양한 데이터 유형을 수집하는 방법에 대해 살펴본다
4.1 수집 데이터 유형 - Database, File, API, Stream
데이터 소스 유형에는 각 고유한 특성이 있으며, 수집 방식 및 처리 전략 또한 달라진다
4.1.1 관계형 데이터베이스(RDB)
•
구조화된 테이블 형태로 구성됨
•
각 컬럼은 명확한 데이터 타입을 가짐
•
고도로 정규화된 구조를 가지며, 여러 테이블이 공통 키로 연결됨
주요 고려 사항
데이터 타입 매핑
•
소스 DB의 컬럼 데이터 타입을 목적지 시스템에 맞게 매핑해야함
•
벤더별 차이, 또는 동일 타입 간에도 세부 동작이 달라질 수 있음
◦
ex. 타임스탬프 정밀도 차이(나노초 vs 마이크로초), DATE 포맷 차이 등
자동화
•
RDB는 수백개의 서로 다른 테이블로 구성되기 때문에 수집 프로세스는 반드시 자동화
변동성
•
RDB는 변동성이 높기 때문에 끊임없이 변하는 데이터를 처리할 수 있어야함
4.1.2 File
•
텍스트나 바이너리 파일로 제공됨
◦
텍스트 포맷- CSV, JSON, XML
◦
바이너리 포맷 - Avro, Protobuf
•
FTP를 통해 목표 시스템에 전달되거나 AWS S3같은 클라우드 스토리지에 저장
•
컬럼 타입 정보가 없어 데이터 구조가 일정하지 않음
주요 고려사항
다양한 파일 포맷 파싱
•
CSV, JSON, XML, Avro 등 다양한 파일 포맷 파싱 로직
스키마 변경
•
RDB와 달리 CSV나 JSON에 새 속성 추가가 쉽기 때문에 이에 대비한 유연한 설계
스냅샷 데이터, 복수 개의 파일
•
RDB는 변동성이 높지만 파일은 보통 특정 시점의 스냅샷 형태
◦
전체 스냅샷(ex. 전체 주문 데이터)
◦
데이터의 증분(ex. 어제 이후로 생성된 주문 데이터)
•
단일 파일 또는 여러 파일로 분할 수 있으므로 배치 단위 고려
4.1.3 SaaS API
•
대부분 SaaS 공급업체에서 데이터 추출을 위해 REST API 제공
•
일반적으로 HTTP 프로토콜 기반에 JSON 포맷
고려사항
•
업체마다 데이터 노출방식이 제각각임
◦
단일 엔드포인트 or 각 객체별 엔드포인트 제공
◦
기간 지정 or 모든 기간만 or 최근 며칠만 제공
•
명확한 데이터 타입 정보가 없을 수 있기 때문에 수집 파이프라인에서 데이터 타입 검증, 스키마 검증 수행
•
API 표준이 없기 때문에 각 SaaS 솔루션별 파이프라인 따로 구현 및 관리 필요
4.1.4 Stream
•
특정 시점에 발생하는 이벤트
◦
ex. 클릭 스트림 데이터
◦
이벤트 내용과 발생 시점 정보가 연속적인 흐름 형태
◦
언제 전자 상거래 사이트의 쇼핑 카트에 아이템을 넣고 빼는지, 언제 은행 계좌로 입금하고 인출하는지 등 분석가능
고려사항
•
메시지는 바이트 배열로 저장되며 JSON, Avro 같은 형식으로 인코딩하기 때문에 수집 파이프라인에서 데이터 이용 목적에 맞는 포맷으로 디코딩 필요
•
이벤트 중복이 있을 수 있어 동일 메시지 여러번 처리하는 상황 고려
•
데이터 프로듀서가 한번 생성한 메시지는 변경 불가
•
대용량 데이터이기에 확장성 있고 처리 지연을 고려한 설계
4.2 관계형 데이터베이스에서 데이터 수집
4.2.1 SQL 인터페이스 기반 수집
•
가장 기본적인 수집 방식으로, SQL 쿼리를 통해 데이터를 조회하고 플랫 파일 형태로 저장
•
주로 CSV, JSON 등의 포맷으로 저장하며, 다양한 필터와 파라미터를 활용 가능
기능 요구사항
•
다양한 종류의 RDB로 SQL 쿼리 실행 가능
•
결과 데이터를 다양한 포맷으로 저장
•
WHERE, LIMIT, 날짜 필터 등 파라미터 조건 적용
4.2.2 테이블 전체 데이터 수집
•
서비스용 데이터베이스는 현재 상태가 중요하지만, 분석용 데이터베이스는 특정 아이템이 시간에 따라 어떻게 변했는지가 중요함
•
정기적으로 전체 테이블을 저장해 데이터의 상태 변화를 기록
데이터 변화 예시
user_id | statue | join_date |
1 | 프리미엄 | 2025-03-27 |
2 | 평가판 | 2025-05-01 |
프리미엄 가입자와 평가판 가입자 두 행 존재
user_id | statue | join_date |
1 | 프리미엄 | 2025-03-27 |
2 | 평가판 | 2025-05-01 |
3 | 평가판 | 2025-05-04 |
신규 사용자 3 추가
user_id | statue | join_date |
1 | 프리미엄 | 2025-03-27 |
2 | 프리미엄 | 2025-05-01 |
3 | 평가판 | 2025-05-04 |
사용자 2가 프리미엄으로 전환
user_id | statue | join_date |
1 | 프리미엄 | 2025-03-27 |
2 | 프리미엄 | 2025-05-01 |
사용자 3이 탈퇴하면서 행 제거
•
이벤트 시작 시점에 테이블에 행이 2개 있었고, 이벤트 끝난 후에도 행 2개인 상태
•
데이터 행값은 변경된 상태이며 그 사이에 중요한 일이 일어났지만 RDB만 분석할 경우 이를 알 수 없음
•
분석에 필요한 데이터를 얻으려면 시간의 흐름에 따른 데이터 변화 내용이 필요
→ 이를 해결하는 한가지 방법으로 파이프라인 실행할때마다 전체 테이블 스냅샷 저장
전체 테이블 저장
•
일주일동안 매일 한번 전체 테이블 저장했다면 총 7개 스냅샷이 존재
•
단일 테이블에 버전 누적 저장 or 버전별로 테이블 분리 저장
•
파생 데이터 세트 생성:
◦
가장 최신 상태만 보여주는 뷰
◦
이전 버전과 비교해 삭제된 행 추출
◦
변경 없는 행은 중복 제거하여 저장
▪
user_id 가 스냅샷 A 이후 변경되지 않았으면 이 테이블에 user_id 1인 데이터 행 하나만 저장
단점: 구현이 쉽지만 대규모 테이블의 경우, 데이터 추출·저장이 비효율적 → 증분 수집으로 보완
4.2.3 증분 데이터 수집
•
마지막 수집 이후 변경되거나 새로 추가된 행만 가져오는 방식
•
일반적으로 updated_at 컬럼을 기준으로 필터링
◦
ex: WHERE updated_at > '2025-07-12 00:00:00'
•
삭제된 행은 읽을 수 없고, 데이터가 빠른시간 내에 자주 변경된다면 그 사이의 값을 읽는데 한계가 있음 → CDC로 보완
4.2.4 CDC 변경데이터 캡쳐
•
DB의 변경 로그(예: 트랜잭션 로그, 바이너리 로그 등)를 활용해 변경 사항을 추출
•
데이터 삽입, 수정, 삭제 모든 이벤트 추적 가능
•
실시간 수집 가능하며 소스 DB에 부담이 적음
단점
•
CDC 애플리케이션 비용이 추가
•
실시간 성격의 인프라 구현이 복잡
•
CDC 메시지를 웨어하우스에 필요한 속성만 필터링하는 후처리 로직 필요
DB별 CDC 구현 방식
DBMS | CDC 방식 | 도구/기술 |
Oracle | Redo 로그 기반 | Oracle GoldenGate (상용) |
MySQL | Binary 로그 기반 | Debezium (오픈소스) |
PostgreSQL | WAL(Log) + Output Plugin | Debezium, AWS DMS 등 |
4.2.5 데이터 타입 변환
데이터 수집 과정에서는 두 번의 변환이 발생:
1.
RDB → 수집 애플리케이션
2.
수집 애플리케이션 → 데이터 웨어하우스
데이터 타입 지원 확인 절차
1.
소스 RDB가 지원하는 데이터 타입 목록 준비
2.
클라우드 데이터 웨어하우스가 지원하는 데이터 타입 목록 준비해 두 데이터타입 비교 분석
3.
직접 대응되지 않고 데이터 손실이 발생하지 않는 타입이 있는지 식별
•
ex. 목적지에서 가장 큰 INT 값도 수용할 수 있는지 체크
•
MySQL에서는 tinyint, smallint, medialint, int, bigint 다섯가지 정수 타입이있지만 구글 빅쿼리에서는 INT64 하나뿐임
4.
직접 대응되지 않고 데이터 손실이 발생할 수 있는 타입 확인해 우회방안 찾기
•
ex. 지리공간, Json 타입 등
•
사용자 정의 데이터 처리 프로그램으로 변환해 텍스트로 저장
5.
데이터 웨어하우스 공급업체 변경도 선택지
•
ex. 지리공간 데이터 → AWS 레드시프트는 적합하지 않고 Snowflake 사용
6.
수집 애플리케이션 직접 개발하는 경우 데이터베이스 드라이버가 지원하는 데이터 타입 확인
4.2.6 NoSQL 데이터베이스에서 데이터 수집
이름처럼 NoSQL은 SQL을 지원하지 않으며 대신 공급업체에서 데이터 액세스용 API 제공
수집 방법
•
상용 제품이나 SaaS 제품 사용
•
공급 업체 별로 별도 수집 애플리케이션 구현
•
CDC 플러그인이 가능하다면 활용
•
NoSQL에서 제공하는 Export 툴 사용
공급 업체 별 수집
•
몽고 DB
◦
문서 지향 DB
◦
Mongo Export로 JSON 추출 가능
◦
최종 수정 시간 필드로 증분 추출 가능
◦
Debezium CDC 지원
•
카산드라
◦
키-밸류 + 컬럼 기반 하이브리드 모델
◦
CQL(Cassandra Query Language) 사용
◦
COPY 명령으로 전체 테이블 CSV 추출
◦
내장 CDC 기능은 존재하나 생태계는 제한적
4.2.7 메타데이터 캡쳐
중요 통계지표를 캡쳐해 데이터 품질 검사와 모니터링 정보 체계 구축
메타데이터 저장소에 이런 관리 지표를 저장하고 관리
캡쳐 항목
기본 정보
•
데이터베이스 서버명, DB명/스키마명, 테이블명
•
+ 스키마 변경 여부
전체/증분 데이터 수집시
•
테이블당 수집되는 행 수
◦
수집된 데이터가 모두 데스티네이션으로 흘러갔는지 확인하는 검사
◦
수집 행수가 갑자기 증가하거나 감소할 경우 파이프라인 문제가 생겼는지 인지 가능
•
수집시 소요되는 시간(시작시간, 끝난 시간, 걸린 시간)
◦
파이프라인이 지정된 시간보다 오래 걸리거나 평균 시간보다 오래 걸리는 시점을 알 수 있음
스트리밍/CDC 수집시
•
시간 단위별 수집 행 수 (짧게 설정할 수록 문제 생겼을시 빠른 대응 가능)
•
Insert/Delete/Update 이벤트 개수
4.3 파일에서 데이터 수집
클라우드 데이터 플랫폼으로 파일 전송하는 두가지 방법
•
FTP/SFTP 프로토콜
◦
파일 저장할 전용 서버, 클라이언트에서 username&password로 인증
◦
FTP 서버와 클라우드 데이터 플랫폼 간 보안 네트워크 설정 필요
◦
FTP 스토리지 사이즈 고려
•
클라우드 스토리지
◦
탄력적인 스토리지, 네트워크 구성 단순화
◦
임시 액세스키, IAM 역할 등 보안 옵션 활용 가능
4.3.1 수집된 파일 추적
파일은 변경 불가능(immutable) 데이터이므로 전체/증분 구분보다 신규 파일 탐지 방식이 중요
수신/처리됨 폴더 방식
•
소스 시스템에 수신/처리됨 폴더 두개 구성
•
소스 시스템에서 신규 파일을 수신폴더에 저장
•
수집 앱은 수신 폴더를 읽어 클라우드 데이터 플랫폼 랜딩영역에 저장
•
저장이 완료되면 수집 앱은 해당 파일을 소스 시스템의 수신 → 처리됨 폴더로 옮김
타임스탬프 기반 추적
•
파일의 최종 변경 타임스탬프 메타데이터를 이용해 이후 추가된 신규 파일 식별
•
소스 스토리지의 파일과 최종 타임스탬프 값을 목록화
•
메타데이터 저장소에서 현재 최고 타임스탬프 값을 가져와서 이보다 큰 파일로 필터링
•
해당 파일중 최대 타임스탬프 찾은 후 이를 메타데이터 저장소에 새 최고 타임스탬프로 업데이트
•
파일명에 타임스탬프를 포함시키면 성능 향상 가능
•
단점
◦
파일 개수가 늘어날수록 매우 느려질 수 있음
◦
특정 파일만 재처리는 어려움
4.3.2 파일 수집 메타데이터 캡쳐
•
소스 시스템 이름
•
파일 형식 (CSV, JSON, Avro 등)
•
수집 시작/종료 시각 및 소요 시간
•
파일 이름 (생성 시각, 시스템명 포함 권장)
•
전체 경로 (full path)
•
파일 크기
4.4 스트림 방식의 데이터 수집
•
스트리밍 데이터는 이벤트 기반이며, 빠른 속도로 생성되는 메시지를 실시간 또는 준실시간으로 처리 (일반적으로 kafka 같은 고속 메시징 시스템 사용)
특징
•
직접 컨슈머 구현하기도 하지만 대용량 데이터 처리, 적절한 로깅, 확장성 등 고려할게 많아 전문 솔루션 권장
•
저장을 위해 별도 아카이빙 구성 필요
◦
ex. Google Dataflow → BigQuery, Kinesis Firehose → Redshift 등
•
클라우드 스토리지는 많은 양의 작은 사이즈를 처리하는데 비효율적 → 메시지 일괄처리해 대용량 파일로 스토리지에 쓰는 것이 일반적
4.4.1 배치와 스트리밍 수집의 차이점
항목 | 배치 수집 | 스트리밍 수집 |
수집 방식 | 일정 주기마다 수집 | 이벤트 발생 시 실시간 수집 |
데이터 추적 | 수집된 여부 기준 | 오프셋(Offset)을 통한 메시지 사용 여부 추적 |
메시지 처리 상태 | 명확한 완료 여부 | 오프셋 커밋 지연으로 중복 처리 가능성 존재 |
데이터 보관 | 장기 보관 중심 | 메시지 양 많아 TTL(보관 기간) 설정 필요 |
장애 복구 | Backfill | 커밋 이전 메시지는 재처리 가능성 있음 → 중복 허용 설계 필요 |
재처리 가능성 추가 설명
카프카에서는 메시지 처리 후 여기까지 처리했다고 오프셋 커밋을 수행. 오프셋 커밋을 쓰기 작업으로, 너무 자주 수행할 경우 실시간 성능에 영향을 미칠 수 있어 보통 주기적으로 커밋을 함. 장애가 날 경우 애플리케이션에서는 실제로 처리됐던 메시지가 오프셋 커밋은 되지 않은 상태로, 마지막 커밋 이후 메시지가 재처리가 될 수 있음.
4.4.2 스트리밍 메타데이터 캡쳐
스트리밍 수집 상태를 실시간으로 모니터링하기 위해 다음 정보를 수집
•
소스 시스템 이름
•
수집 시작 시각, 종료 시각, 소요 시간
•
수집된 메시지 개수
•
(배치 저장이 포함된 경우) 저장 경로 정보
기준치 이하 메시지 도착 시 알림 → 장애 조기 감지