데이터 플랫폼 - 스토리지 설계 및 구축 방법

데이터 플랫폼의 데이터 저장소 구성시, 명확하고 일관된 원칙을 갖는 것이 중요하다. 

이 일관된 원칙은 표준화된 파이프라인 구축이 가능하게 하고 대규모 파이프라인을 효율적으로 관리 할 수 있게 도와준다.  

아래 그림은 많은 유스케이스를 충족시킬 수 있는 스토리지 구성 패턴이다. 

(1) 수집 계층에 데이터는 랜딩(Landing) 영역에 저장된다.랜딩 영역은 원시 데이터가 처리될 때까지 저장돼 있는 곳이다. (랜딩 영역에 기록할 수 있는 계층은 오직 수집 계층이다.)

(2) 원시 데이터는 일련의 공통 변환 과정을 거치게 된다. 그리고 스테이징 영역에 저장된다. 

(3) 원시 데이터는 랜딩 영역에서 아카이브 영역으로 복제된다. 아카이브 영역에 원시 데이터의 활용 목적은 재처리가 필요한 경우, 파이프라인 디버깅을 해야 될 경우, 신규 파이프라인 코드를 테스트해야 되는 경우를 대비하여 보관하게 된다. 

(4) 데이터 변환 작업은 스테이징 영역에서 데이터를 읽고, 필요한 비즈니스 로직을 적용한 후 처리 결과를 프로덕션 영역에 저장한다. 

(5) "패스 스루(pass-through)" 작업은 옵션이다. 원시 데이터 복제본을 그대로 복제하는 경우를 의미한다. 

(6) 각 단계별로 장애 시나리오를 준비해야 한다. 장애 발생시, 이슈 디버깅을 위해 데이터를 스토리지의 실패 영역에 저장하고 데이터 엔지니어가 활용할 수 있도록 해야 한다. 

영역별 상세 설명

구분	내용
랜딩 영역	데이터 수집 단계로부터 원시 데이터가 저장되는 영역이다. 데이터가 처리되기 전까지 랜딩 영역에 저장된다. 랜딩 영역은 일시적인 영역이므로 데이터가 장기간 저장되는 곳은 아니다.
스테이징 영역	원시 데이터는 일련의 공통 변환 과정을 거치게 된다. (공통 변환 과정 : <예: 스키마 준수 여부 확인, 데이터 포맷 변환, 데이터 품질 검사 실행 등..>) 이 단계를 성공적으로 마치면 해당 데이터는 스테이징 영역에 저장하게 된다.  스테이징 영역의 데이터는 기본적으로 데이터 품질 요구 사항을 만족하는 데이터라고 볼 수 있다.  <공통 데이터 처리> 1. 파일 포맷 변환  2. 데이터 중복 제거  3. 데이터 품질 검사
아카이브 영역	랭딩 영역의 데이터에 공통 변환 과정을 처리하고 처리된 결과를 스테이징 영역에 저장한 후. 랜딩 영역의 원시 데잍를 아카이브 영역에 복제해야 한다. (배치 작업 재처리가 필요할 경우 아카이브 영역에서 랜딩 영역으로 데이터를 간단히 이동만 시켜주면, 파이프라인이 필요 작업을 다시 수행할 수 있게 할 수 있기 때문이다) 아카이브 영역의 데이터 사용 목적  - 파이프라인 이슈 디버깅  - 신규 파이프라인 코드를 테스트  * 데이터 파이프라인 전체 흐름에서 오류 발생시 해결을 위한 별도 단계가 되므로 중요한 영역이다.
프로덕션 영역	데이터 변환 작업은 스테이징 영역에서 데이터를 읽어 비즈니스 로직을 적용하고 변환된 데이터를 프로덕션 영역에 저장하게 된다.
패스 스루 작업	"패스 스루" 작업은 특별한 경우로 분류된다.  스테이징에서 비즈니스 로직 적용후 프로덕션으로 데이터를 복제한 다음, 스테이징에 데이터에 비즈니스 로직을 적용하지 않고 바로 데이터 웨어하우스로 복제하는 것을 의미한다.  이 작업은 선택 사항이다. 주로 비즈니스 로직 관련 이슈를 디버깅할 때 매우 유용하다고 한다.
클라우드 데이터 웨어 하우스와 프로덕션 영역	리포팅이나 기타 분석 목적으로 사용할 데이터 세트를 생성한다. 이러한 파생 데이터 세트는 프로덕션 영역의 전용 위치에 저장해야 하며, 데이터 웨어하우스에도 적재해야 한다.
실패 영역	데이터 파이프라인을 견고하게 구축한다는 의미는 발생 가능성이 있는 모든 경우의 오류와 장애에 대한 대비책을 가지고 있어야 함을 의미한다.  파이프라인 코드에 버그가 있을 수도 있고, 클라우드 리소스가 작동하지 않을 수도 있으며, 수신 데이터의 데이터 품질이 좋지 않을 수도 있다.  랭딩 영역에 데이터가 저장된 이후부터 흐름의 각 단계에서 장애가 발생할 때마다 관련 데이터를 스토리지의 실패 영역에 저장해야 한다.  - 데이터 엔지니어는 이슈를 훨씬 쉽게 디버깅 할 수 있으며, 문제를 야기시킨 데이터를 식별하기 쉽다.  - 이슈 해결한 후, 재 처리가 필요한 데이터는 재처리 하기도 쉽다.

 

폴더 명명 규칙

데이터를 논리적 구조로 체계화 할 때, 폴더를 활용하는 것을 추천한다. 

데이터와 데이터 파이프라인을 논리적인 방법으로 구성하는데 필요한 공통 요소부터 정의해보자. 

구분	내용
네임스페이스	- 네임스페이스는 계층 구조에서 가장 높은 레벨이며, 여러 파이프라인을 논리적으로 그룹화 하는데 사용된다.  - 부서명이나 특정 이니셔티브를 네임스페이스로 쓰기도 한다.  - 사용자 그룹별로 별도의 네임스페이스 데이터 접근 권한을 관리해야 할 경우. 네임스페이스를 나누어 관리하면 보다 권한 관리를 용이하게 할 수 있다.
파이프라인명	- 각 데이터 파이프라인은 파이프라인의 용도를 반영한 이름이 있어야 한다.  - 파이프라인 명은 파이프라인 로그에도 기록되고, 파이프라인에서 생성한 스토리지 폴더명을 표현할 때도 활용할 수 있다.
데이터 소스명	- 수집 계층은 플랫폼으로 가져와야 하는 Target 데이터 소스에 각각 이름을 할당하게 됩니다.  - 소스명은 주로 메타데이터 저장소에 저장됩니다.  - 클라우드 스토리지 폴더명에 소스명을 포함하면, 사용자와 파이프라인이 데이터의 출처를 쉽게 식별할 수 있게 됩니다.
배치 ID	- 배치 ID는 랜딩 영역에 저장되는 데이터 배치 작업에 대한 고유 식별자 입니다.  - 랜딩 영역에 데이터를 저장할 수 있는 유일한 계층은 수집 계층이므로 이 식별자를 생성하는 것은 수집 애플리케이션의 책임이 된다.  - 대부분 이와 같은 유형의 식별자는 UUID나 ULID를 사용하게 됩니다.    > ULID를 사용하면, UUID보다 짧고 정렬성이 뛰어나 데이터를 활용하고 관리하기에 보다 유용합니다.

각 단계별 폴더 구조

구분	내용
랜딩	/landing/NAMESPACE/PIPELINE/SOURCE_NAME/BATCH_ID landing은 스토리지 단계를 의미하고 나머지 경로는 폴더 구조라고 이해하면 됩니다.  1. 파이프라인 명은 짧지만 설명을 포함하도록 만드는 것이 좋습니다.  2. 스토리지 폴더를 보는 사람이 문서나 메타데이터 저장소를 참조하지 않아도 데이터의 출처를 이해할 수 있기 때문입니다.  3. 랜딩 영역에는 일반적으로 가장 최근 배치만 포함되게 됩니다.  4. 랜딩 영역에 여러 배치가 쌓이게 되면 다운스트림 처리가 작동하지 않거나 느리다는 것을 의미하게 됩니다.
스테이징	/staging/NAMESPACE/PIPELINE/SOURCE_NAME/year=xxxx/month=xx/day=xx/BATCH_ID 스테이징 폴더 구조는 랜딩과 비슷하지만 장기적으로 스테이징 영역에 데이터를 저장할 계획이므로 데이터를 시간별로 정리하면 용이합니다.  1. 위에 작성된 명명 규칙인 year=xxxx/month=xx/day=xx은 하둡에서 유래했으며, 스파크를 포함한 많은 분산 처리 엔진에서도 사용되는 규칙 입니다.
아카이브 & 실패	아카이브와 실패는 스테이징과 동일한 폴더 구조를 가집니다.
프로덕션	/production/NAMESPACE/PIPELINE/SOURCE/year=xxxx/month=xx/day=xx/BATCH_ID 신규 파이프라인이 추가될 수 있다는 점을 제외하면, 스테이징과 동일한 구조입니다.  1. 신규 파이프라인이 추가되는 예를 들면, contracts 데이터 소스와 campaigns 데이터 소스의 데이터를 결합해 마케팅 리포트를 생성하는 작업이 필요한 경우를 들 수 있습니다.  2. 신규 파이프라인의 이름을 지을 때는 이 작업이 어디에서 왔는지 반영하는 방식으로 작업명을 지정하는 것이 좋습니다.  3. 여러 소스에서 데이터를 읽고 신규 데이터 세트를 생성하는 경우에는 데이터 변환 파이프라인에 필요한 모든 소스명을 폴더명으로 표현할 수 있는 이름을 사용하면 좋습니다. (모든 데이터 소스를 나열하게 되면 가시성이 떨어지게 됩니다. >> 파생 소스를 만드는 것이 좋음)

 

위 내용은 "데이터 플랫폼 설계와 구축:클라우드 데이터 플랫폼 구축 시 고려사항"의 책 내용을 정리한 내용 입니다.