All
5장에서는 처리계층의 역할에 대해 설명한다.
5.1 데이터 플랫폼에서 처리계층
기존 데이터 웨어하우스에서는 SQL로 데이터 처리가 이루어졌지만, 데이터 플랫폼에서는 데이터 처리계층을 만들어 컴퓨팅과 스토리지를 분리해 유연성, 확장성, 비용 절감, 유지보수성을 제공.
데이터 레이크에서 데이터 처리(Spark) | 데이터 웨어하수으에서 데이터 처리(SQL) | |
유연성 | 처리 결과물이 웨어하우스 뿐 아니라 다른 곳에서 사용 가능 | 처리 결과물은 데이터 웨어하우스에서 사용 |
개발자 생산성 | 스파크로 성능과 유연성 | SQL로 가치창출 시간 단축 |
데이터 거버넌스 | 데이터 싱크 영역에서 데이터 사용방식 일관성 있게 관리가능 | 데이터 처리작업이 다른 곳에서 수행되면 정의가 상충 |
플랫폼 간 이식성 | 독립적인 코드로 이식성이 높음 | ANSI-SQL은 이식가능, 특정 기능은 불가 |
성능 | 처리량이 아무리 늘어나도 데이터 웨어하우스에 영향 없음 | 처리 부하 증가할 때 문제 발생 가능 |
처리속도 | 항상 실시간 분석 | 여러 단계나 제품을 거쳐 실시간 분석 |
비용 | 데이터 레이크에서 처리 작업이 더 저렴 | 처리 비용이 비쌈 |
재사용성 | 스파크에서 재사용할 수 있는 기능과 모듈 구현 | 저장 프로시저나 함수 사용이 가능하다면 재사용 가능 |
5.2 데이터 처리 스테이지
•
공통 데이터 처리 단계
◦
데이터 소스에서 들어오는 데이터 전체에 적용
◦
단일 통합 표준 포맷으로 변환
◦
스키마 차이점 해결
◦
중복 제거
◦
유효값 검사 등 품질 검사
•
비즈니스 로직 처리 단계
◦
각 분석 유스케이스 구현에 필요한 자체 데이터 변환 로직
flowchart TB
RAW[원시 수신데이터]
subgraph CP["공통 데이터 처리"]
direction TB
STD[파일 포맷 표준화 및<br>스키마 차이 해결]
DEDUPE[중복제거]
QC[품질검사]
TRANSFORM[데이터 변환]
end
STG[Staging 영역]
subgraph BL["비즈니스 로직에 특화된 처리"]
direction TB
XFORM1[변환작업 1]
XFORM2[변환작업 2]
end
subgraph Production 영역
OUT1[데이터 결과물 1]
OUT2[데이터 결과물 2]
end
RAW --> STD
STD --> DEDUPE
STD --> QC
STD --> TRANSFORM
DEDUPE --> STG
QC --> STG
TRANSFORM --> STG
STG --> XFORM1 --> OUT1
STG --> XFORM2 --> OUT2
Mermaid
복사
5.3 클라우드 스토리지 구성
1.
랜딩 영역
•
수집계층에서 수집된 원시 데이터 저장
•
랜딩 영역에는 수집 계층만 기록
2.
스테이징 영역
•
원시 데이터를 공통 변환 과정을 거쳐 저장
•
기본 품질 요구사항 충족하는 상태
3.
아카이브 영역
•
데이터를 처리하고 스테이징 영역에 저장하면 랜딩 영역의 원시 데이터를 아카이브 영역으로 복제
•
배치 재처리 해야할경우 아카이브에서 랜딩으로 복제해서 재수행
•
이슈 디버깅 & 신규 파이프라인 테스트 용도
4.
프로덕션 영역
•
스테이징 영역에서 데이터를 읽어 비즈니스 로직을 적용하고 저장
•
Parquet로 포맷으로 변환 (뒷부분에 설명)
5.
패스 스루 (pass through) 작업
•
선택사항으로 스테이징 영역의 데이터를 변환없이 프로덕션 영역으로 복제
•
이슈 디버깅시 용이함
6.
클라우드 데이터 웨어하우스와 프로덕션 영역
•
각 단계작업에서 스테이징 영역으로부터 데이터 읽어 목적에 따른 데이터 세트 생성
•
프로덕션 영역과 데이터 웨어하우스에 동시에 저장
7.
실패 영역
•
랜딩 영역에 데이터 저장된 이후부터 각 단계에서 장애 발생시 스토리지의 실패 영역에 관련 데이터 저장
•
이슈 파악과 디버깅 용도
5.3.1 클라우드 스토리지 컨테이너와 폴더
컨테이너 액세스 보안 및 스토리지 티어 구성
컨테이너 | 허용된 권한 | 스토리지 티어 |
랜딩 | 수집 계층 애플리케이션만 쓰기 권한
데이터 파이프라인 읽기 권한
데이터 소비자 액세스 불가 | 핫, 읽기 쓰기 자주 발생 |
스테이징 | 데이터 파이프라인 읽기 권한
특정 데이터 소비자 읽기 권한 | 핫, 읽기 쓰기 자주 발생 |
프로덕션 | 데이터 파이프라인 읽기 권한
데이터 소비자 읽기 권한 | 핫, 읽기 쓰기 자주 발생 |
아카이브 | 데이터 파이프라인 읽기 권한
전용 데이터 재처리 파이프라인 읽기 및 쓰기 권한
극소수 특정 데이터 소비자 읽기 권한 | 콜드 또는 아카이브 |
실패 | 데이터 파이프라인 읽기 권한
전용 데이터 재처리 파이프라인 읽기 권한
데이터 소비자 액세스 불가 | 핫, 읽기 쓰기 자주 발생 |
폴더 명명 규칙
•
네임스페이스
◦
계층 구조에서 가장 높은 레벨로 여러 파이프라인 논리적으로 그룹화
◦
네임스페이스 별로 별도의 스토리지 컨테이너 생성해 별도 권한으로 관리 가능
•
파이프라인명
◦
파이프라인의 기능과 용도를 쉽게 식별할 수 있는 파이프라인명 지정
•
데이터 소스명
◦
사용자와 파이프라인이 데이터의 출처를 쉽게 식별할 수 있도록 스토지리 폴더명에 소스명을 포함
•
배치 ID
◦
랜딩영역에 저장되는 데이터 배치 작업에 대한 고유 식별자
◦
UUID or ULID 사용
◦
ULID는 UUID보다 짧고 정렬성이 좋기 때문에 어떤 배치가 더 오래된 것인지 구별가능
랜딩 컨테이너
폴더 구조
•
landing/NAMESPACE/PIPELINE/SOURCE_NAME/BATCH_ID/
예시- 랜딩 컨테이너의 폴더 정보들
•
폴더명만 보고도 데이터의 출처나 어떤 수집 파이프라인이 존재하는지 알 수 있음
◦
mysql 판매 데이터베이스로부터 수집한 데이터를 두개의 테이블로 보내는 파이프라인
◦
FTP 서버에서 마케팅 데이터를 가져오는 파이프라인
landing/ETL/sales_mysql_ingest/customer/01K0GTVGHDVPTN2P6YJPS0CE06/
landing/ETL/sales_mysql_ingest/contracts/01K0GTVT3CS3ARW1E7C4QTTSXC
landing/ETL/sales_ftp_ingest/campaings/01K0GTWXC03KA7BF36G7K6R79P
Plain Text
복사
스테이징 컨테이너
•
데이터를 시간별로 정리하기위해 시간 기반 파티셔닝 사용
•
각 배치가 수집된 시간을 인코딩해 폴더에 넣음
•
하루에 배치 여러번 수집시 동일 폴더에 저장되므로 폴더 안에서 ULID로 정렬가능
•
아카이브 및 실패 컨테이너도 동일한 폴더 구조
landing/ETL/sales_mysql_ingest/customer/year=2025/month=07/day=03/01K0GTVGHDVPTN2P6YJPS0CE06
landing/ETL/sales_mysql_ingest/contracts/year=2025/month=07/day=03/01K0GTVT3CS3ARW1E7C4QTTSXC
landing/ETL/sales_ftp_ingest/campaings/year=2025/month=07/day=01/01K0GTWXC03KA7BF36G7K6R79P
Plain Text
복사
스트리밍 데이터 구성
•
아카이빙 목적으로 스트리밍 데이터를 일반 스토리지에 저장하는 경우에 사용
•
클릭 스트림 데이터를 고속 스토리지에서 저속 스토리지로 flush해 아카이빙
•
각 플러시에 고유한 배치 ID 할당
landing/ETL/clickstram_ingest/clicks/01K0GTVGHDVPTN2P6YJPS0CE06
landing/ETL/clickstram_ingest/clicks/01K0GTVT3CS3ARW1E7C4QTTSXC
landing/ETL/clickstram_ingest/clicks/01K0GTWXC03KA7BF36G7K6R79P
Plain Text
복사
→ 고속 스토리지에서 일반 스토리지로 플러시된 세개의 데이터 배치가 있음을 알 수 있음
5.4 공통 데이터 처리 단계
5.4.1 파일 포맷 변환
•
데이터 플랫폼으로 수집되는 다양한 데이터 타입을 단일 통합 포맷으로 변환
•
통합 파일 포맷을 사용하지 않을경우 추후 각 파이프라인에서 각자 파싱 로직을 구현해야해서 확장성에 문제가 발생함
•
원본 파일 포맷을 변경하지 않으면 데이터 탐색이 복잡해짐
•
이 책에서는 스테이징 영역에 Avro(아브로), 프로덕션 영역에는 Parquet(파케이) 포맷을 사용
Avro 및 Parquet 파일 포맷
공통 특징
•
바이너리 포맷
◦
텍스트 기반 포맷 대비 디스크 공간을 훨씬 적게 차지 (최대 10배)
◦
별도 인코딩/디코딩 과정 필요
•
스키마 포함/강제
◦
파일 자체에 컬럼명·타입 정보를 포함
◦
파이프라인이나 애플리케이션에서 별도 정의 없이 자동 인식 가능
행 지향(Row‑Oriented) vs 컬럼 지향(Column‑Oriented)
특성 | 행 지향 (Row‑Oriented) | 컬럼 지향 (Column‑Oriented) |
데이터 저장 방식 | 레코드 단위로 순차적 저장 | 컬럼 단위로 값만 연속 저장 |
읽기 패턴 최적화 | 전체 레코드를 자주 읽을 때 | 특정 컬럼만 선택적 조회할 때 |
쓰기/업데이트 속도 | 빠름 | 비교적 느림 |
스토리지 효율 | 중간 수준 | 매우 효율적 (압축률 우수) |
Avro
•
행 지향 포맷
◦
레코드 단위로 저장되어, 원본 메시지나 로그를 순차 처리하기에 적합
•
스키마 포함
◦
각 파일 헤더에 스키마가 내장되어 있어 초기 로딩 시 컬럼 정보를 즉시 획득
•
스키마 진화 지원
◦
기본 규칙에 따라 필드 추가·삭제·타입 변경 시에도 하위 호환성 유지
◦
언제나 최신 스키마로 과거 데이터까지 모두 읽을 수 있음
•
주 사용처
◦
스테이징 영역에서 다운스트림 변환용 소스로 활용
◦
빠른 쓰기와 유연한 스키마 변경이 중요한 단계에 적합
Parquet
•
컬럼 지향 포맷
◦
컬럼별로 데이터 블록을 연속 저장하여 특정 컬럼만 빠르게 조회
•
고성능 쿼리
◦
전체 데이터셋을 읽지 않고 필요한 컬럼만 스캔
◦
복합 타입(nested 구조) 및 다양한 기본 타입 지원
•
높은 압축 효율
◦
컬럼 단위로 특화된 압축 알고리즘 적용 가능
•
주 사용처
◦
프로덕션 영역에서 분석·조회 응답 시간이 중요한 곳에 적합
◦
OLAP 워크로드나 대규모 배치 처리 단계에 최적화
활용전략
•
스테이징(Stage) 단계
◦
Avro를 사용해 원시 데이터를 빠르게 적재·보관
◦
스키마 진화가 자주 발생해도 안정적으로 관리
•
프로덕션(Production) 단계
◦
Parquet로 변환하여 분석 쿼리 성능 극대화
◦
컬럼 단위 스캔과 높은 압축 효율로 비용 절감
5.4.2 데이터 중복 제거
데이터 파이프라인에서 중복 제거는 신뢰성 확보와 저장·처리 비용 절감을 위해 필수적인 단계
데이터 플랫폼의 중복 이슈
•
RDB에서 고유성 보장을 제공하더라도, 클라우드 데이터 플랫폼에서는 중복이 발생할 여지가 많음
•
신뢰할 수 없는 데이터 소스 또는 반복 수집
•
분산 환경 특성 때문에 고유 인덱스나 외래 키 같은 제약 조건 지원하지 않음
배치 범위 중복 제거
•
랜딩 영역에 저장된 단일 배치 내에 존재하는 중복 데이터 제거
•
별도 데이터셋 결합 없이 구현 가능해 처리 속도·복잡도 낮음
•
프로덕션 데이터에 추가하면서 중복 생길 가능성 존재
전역(Global) 중복 제거
•
랜딩 영역과 스테이징 영역의 데이터 join하여 새로운 레코드만 필터링
•
데이터 볼륨이 증가할수록 조인 비용이 급증
•
연/월/일 파티셔닝이 되어있다면 해당 범위로 제한해 중복제거 가능하지만 이 외의 범위에서 중복 위험 증가
→ 100% 중복제거를 원한다면 배치 범위 제거, 전역제거 두 방법 모두 수행해야함
5.4.3 데이터 품질 검사
데이터 품질 검사는 downstream 오류를 예방하고 의사결정 신뢰도를 높이는 핵심 활동
공통 품질 검사 항목
•
Null/Not‑Null 검증: 필수 컬럼에 결측치가 없는지
•
값 길이 검사: 문자열·배열·바이너리 데이터의 최소·최대 길이
•
값 범위 검사: 숫자·날짜·시간 컬럼의 허용 범위
•
패턴 검증: 이메일, 전화번호, UUID 등 정규 표현식 매칭
데이터 품질 검사시 고려사항
•
중요도 확인
◦
모든 데이터의 품질이 중요한 것은 아니므로 우선순위를 정해서 처리
•
데이터 품질 이슈 경보 알림
◦
검사 실패 비율이 기준치 초과 시 슬랙/이메일 알림 전송
◦
검사 통과율, 실패 건수 등을 대시보드화하여 실시간 모니터링
•
오류 처리 방식 선택
◦
행 단위 제거: 문제 있는 레코드만 삭제 후 나머지 처리 지속
◦
배치 전체 실패: 심각 오류 발생 시 전체 배치 롤백 → 재처리 유도