파일 포맷 변환, 데이터 중복 제거, 데이터 품질 검사에 대해 알아볼거임
데이터의 포맷은 JSON, CSV, XML, 사용자 정의 바이너리 포맷 등..으로 다양함
데이터 레이크의 핵심은 데잍터를 다양한 포맷으로 저장하고 액세스할 수 있기에,
전통적인 데이터 레이크는 스토리 계층에 포맷 변경 없이 데이터를 그대로 저장함
하지만, 이런 방식은 데이터 변환 작업이나, 처리를 수행하는 파이프라인의 업무를 증가시킴
그렇기에 현대 데이터 플랫폼 설계는 더 조직적이고, 구조화된 방식을 제안하고 있음
데이터를 원본 포맷으로 유지하고, 아카이브 영역에 저장하는 것은 같지만,
수신 데이터에 수행하는 첫 번째 변환 중 하나로 데이터를 단일 통합 파일 포맷으로 변환함
여기에서는 두 가지 다른 파일 포맷을 사용함
1. 스테이징 영역에서는 apache avro
2. 프로덕션 영역에서는 apache parquet
avro와 parquet 모두 바이너리 파일 포맷임
텍스트 포맷과 달리, 인코딩/디코딩이 필요함
바이너리 포맷을 사용하는 이유
- 바이너리 포맷은 데이터 인코딩 중에 적용할 수 있는 최적화 방식이 달라, 디스크 공간을 훨씬 적게 차지함
- avro, parquet 모두 컬럼 타입(attribute단위) 정보를 포함하고 있기에, 파일 압축률이 상당히 높음
- 텍스트 파일 포맷을 압축해 바이너리 포맷으로 변경할 경우 최대 10배까지 줄일 수도 있다고 함...
- 특정 스키마의 사용을 강제함
- 즉, avro, parquet 포맷으로 데이터 저장전, 해당 데이터 세트에 대한 컬럼과 컬럼 타입을 정의해야 함
- avro 포맷의 경우, 스키마 정보가 실제로 각가의 파일에 포함되어 있기에 파일을 읽는 프로그램이나 데이터 파이프라인이 컬럼명과 해당 타입을 자동으로 인식할 수 있음
- 이런 방식은 시간이 걸리지만, 파이프라인이나 플랫폼의 데이터를 여러 소비자가 사용할 경우 빛을 발휘하게 (뒤에서 자세히 배움)
avro와 parquet이 모두 필요한 이유에 대해 알아보자
- 먼저 행지향 파일 포맷과 열지향 파일 포맷의 차이점을 알아야함
프로그램이 스토리지에서 파일을 읽을 때 실제로는 바이트 단위로 읽지 않고, 한 번에 전체 블록을 읽음
즉, 한 블록을 읽으면 여러 행의 데이터를 가져오기에, 모든 행의 전체 칼럼 값을 읽을때 유용함
한 블록을 읽으면 모든 행의 특정 칼럼 값 전체를 얻을 수 있음
ex) col3의 총합을 얻을려면 블록2만 읽으면 됨
즉, 분석 워크로드 수행 시 특정 칼럼만 필요로 하는 경우 유용함
칼럼 기반의 포맷은 행 포맷보다 압축률이 훨씬 좋다는 장점이 있음
- 칼럼 기반 포맷은 한 블록에 같은 타입의 데이터가 저장되기 때문
Avro는 행지향 파일 포맷임
nested(중첩)형을 포함해 기본 데이터 타입과 복합 데이터 타입을 지원함
avro는 스키마를 각 파일 내부에 포함하므로 avro 파일로 작업하는 프로그램이 칼럼 정의와 칼럼 타입 정보를 빨리 가져올 수 있음 (header에 정보가 있어 이를 읽고 바로 데이터를 가져올 수 있음)
스키마 진화 규칙 역시 지원함 (스키마가 변경되더라도 항상 최신 버전의 avro schema를 사용해 이전 파일을 모두 읽음)
그렇기에 avro는 스테이징 영역에서 주로 다운스트림 변환용 소스로 사용됨
parquet은 기본 데이터 타입과 복합 데이터 타입을 지원하는 컬럼 파일 포맷임
데이터 세트의 개별 컬럼에 빠르게 액세스할 수 있음
압축률이 뛰어나 저장공간을 줄이는데 도움이 됨
프로덕션 영역에서 웨어하우스로 데이터를 원활하게 적재할 수 있음
redshift, bigquery..
avro, parquet으로 변환할때는 spark를 사용해 변환 작업을 쉽게 진행할 수 있음
데이터 중복 제거
특정 데이터에 대한 고유성을 강제화하는 주제에 대해 알아보자
고유성에 관한 두 가지 주요 이슈가 있음
1. 신뢰할 수 없는 데이터 소스 또는 반복 수집
2. 분산 환경 특성상 클라우드 웨어하우스의 고유성 강제화 부족(unique index, FK 같은 제약 조건을 지원하지 않음)
스파크를 활용해 중복되는 데이터를 제거해보자
먼저 아래 그림에서 설명하는 global 중복 제거 시나리오와 batch내 중복 제거 시나리오의 차이점을 알아보자
먼저, 랜딩 영역에서 저장된 단일 수신 배치 내에 존재하는 중복 데이터 제거를 해보자
스테이징, 프로덕션 및 웨어하우스에는 중복이 없다고 가정을 할거임
스파크를 써서 내장된 함수를 써서 제거를 함 (문서나 llm써서 코딩 해보면 됨..)
global한 데이터 중복이 발생해도, spakr에서 sql의 join문을 통해 중복을 쉽게 제거 가능함
데이터 품질 검사
- 중요도 확인
- 데이터 품질 이슈에 대한 경보 알림
- 잘못된 행 제거 또는 전체 배치 실패
위에서는 공통 데이터 처리 파이프라인이었고, 수백의 다른 데이터 소스가 추가되면 어떻게 확장해나갈지 알아보자
유연한 데이터파이프라인 설계
단일 파이프라인은 모든 수신 데이터 소스를 처리하지만 소스마다 다른 파라미터로 호출됨
- 메타데이터 저장소
- 공통 데이터 처리 파이프라인은 여러 모듈로 구성됨
- 각 모듈은 오케스트레이션 계층을 사용해 여러 형태로 구현될 수 있음
- 즉, 각 단계에 가장 적합한 방식으로 형태가 달라짐
- 파이프라인 각 모듈을 구현 방법에 관계없이 설정 파일을 통해 처리할 데이터 소스, 소스가 존재하는 스토리지 위치, 소스 스키마 정보, 중복 제거에 사용할 컬럼 등의 정보를 받아들어야함
- 이때 설정을 정하는 데 권장되는 위치가 메타데이터 저장소임
- 오케스트레이션 계층
- 여러 데이터 처리 작업을 조정하고 작업 실패 및 재시도를 처리하는 역할을 수행함
- 랜딩 영역을 모니터링해, 신규 데이터 배치를 감지하고, 파이프라인명, 데이터 소스명 및 기타 필요한 파라미터를 추출
- 오케스트레이션 계층에서 필요한 모든 설정값을 받아와 데이터 처리 작업을 실행하게 됨
1. 오케스트레이션 도구는 새로운 데이터가 있는지 스토리지 랜딩 영역을 모니터링함
2. 해당 데이터 소스로부터 수신된 데이터 처리르 위한 파이프라인 설정값을 가져옴
3. 데이터 처리 작업을 시작하면서 설정값을 제공함
'데이터 > 아키텍처' 카테고리의 다른 글
| FoodDonor 데이터 인프라 설계 (0) | 2026.01.14 |
|---|---|
| 메타데이터 계층 아키텍처(2) (0) | 2025.11.07 |
| 메타데이터 계층 아키텍처(1) (0) | 2025.11.04 |
| 클라우드 스토리지 구성(1) (0) | 2025.10.30 |
| 데이터 플랫폼 아키텍쳐 (0) | 2025.10.28 |