클라우드 스토리지 구성(1)

클라우드 스토리지의 데이터를 구성할때는 명확하고 일관된 원칙을 갖고 진행해야함

즉, 데이터를 읽을 위치, 데이터를 저장할 위치 등 동일한 설계 원칙에 따라 구축함 (표준화가 필요하다는 말..)

생산 = production

1. 수집 계층에서 나온 데이터는 Landing 영역에 저장됨

• Landing 영역은 raw데이터가 처리될 때까지 저장되어 있는 곳
• 수집 계층만이 Landing영역에 기록을 할 수 있음

2. raw data는 일련의 공통 변환 과정을 거쳐 Staging 영역에 저장됨

3. raw data는 landing 영역에서 archive 영역으로도 복제됨

• archive 목적은 재처리가 필요할 경우, 파이프라인 디버깅을 해야 될 경우, 신규 파이프라인 코드를 테스트를 위해 대비함

4. 데이터 변환 작업은 staging 영역에서 데이터를 일고, 필요한 비즈니스 로직을 적용한 후에 처리 결과를 produciton 영역에 저장함

5. pass-through 작업은 선택사항임

• raw data 복제본은 그대로 staging -> production으로 복제한 후, 다시 클라우드 웨어하우스로 복제함
• 복제는 단순히  디버깅 등.. 이런 문제를 대비함

6. 각 단계 작업에서 staging 영역으로부터 데이터를 읽어, 리포팅 등 분석 목적으로 사용할 데이터 세트를 생성함

• 이렇게 파생된 데이터 세트는 production 영역의 파생 데이터 전용 위치에 저장되며, 클라우드 웨어하우스에도 적재됨

7. 장애 시나리오도 필요함

• 디버깅을 위해 데이터를 스토리지 의 실패 영역에 저장하고, 이를 활용할 수 있도록 해야함
• 이슈가 해결되면 데이터를 랜딩 영역으로 복제함으로써 재처리하는데 활용할 수 있음

---

랜딩 영역

• raw data를 저장함
• 데이터가 장기간 저장되지 않고, 일시적인 저장임

스테이징 영역

• raw data에 대해 변환 과정을 거치고 이를 저장함
• ex) 기존 스키마를 준수하는지 확인하고, Avro 바이너리 포맷 변환, 품질 검사 진행..
• 위 과정을 거친 후 스테이징 영역에 저장됨
• 즉, 최종 사용자나 처리 작업에서 사용할 수 있는 상태

아카이브 영역

• 스테이징 영역에서 저장 과정이 끝나면, 랜딩 영역의 raw data를 아카이브 영역으로 복제해야 함
  • 배치 작업에 대해 재처리 해야 할 경우, 아카이브에서 역으로 해당 데이터를 랜딩 영역으로 간단히 복제만 해주면 됨
• 아카이브 영역의 데이터는 파이프라인의 이슈 탐지 및 테스트에 사용됨

프로덕션 영역

• 데이터 변환 작업 절차는 스테이징 영역에서 데이터를 읽은 후 비즈니스 로직을 적용해서, 변환된 데이터를  프로덕션 영역에 저장하는 순으로 진행됨
• Avro format(행 기반) 데이터가 Parquet format(열 기반)으로 변환됨

pass-through 작업

• 작업 과정 중 특별 케이스로 분류됨 (선택 사항 과정이라..)
• 스테이징에서 프로덕션(parquet format)으로 데이터를 복제하고, 비즈니스 로직 적용 없이 그대로 클라우드 데이터 웨어하우스로도 복제하는 것을 말함

클라우드 데이터 웨어하우스와 프로덕션 영역

• 파생 데이터는 프로덕션 영역의 전용 위치에 저장되어야 하며, 클라우드 웨어하우스에도 적재되야 함

실패 영역

• 랜딩 영역에 데이터가 저장된 이후부터 흐름의 각 단계에서 장애가 발생할 때마다 관련 데이터를 스토리지의 실패 영역에 저장해야 함

---

클라우드 스토리지 컨테이너와 폴더

• AWS와 GCP에서는 컨테이너를 버킷이라고 함
• 각 컨테이너는 여러 폴더를 호스팅할 수 있음
• 컨테이너에는 설정해야 할 속성을 갖고 있음
  • 액세스 및 보안
  • 컨테이너 스토리지 티어
    • 클라우드 공급자는 다양한 스토리지 계층을 제공함
    • 스토리지 계층을 핫,콜드 및 아카이브라고 함
    • 핫 스토리지 티어는 가장 빠른 읽기/쓰기 작업을 제공하지만, 장기간 저장에는 비용도 높음
    • 콜드 및 아카이브 계층은 저속이지만 저렴한 비용으로 장기간 대용량 데이터 저장 가능함
• 위에서 본 각 스테이지는 별도의 컨테이너로 구현됨

컨테이너	허용된 권한	스토리지 티어
랜딩	수집 계층 애플리케이션만 쓸 수 있음 데이터 엔지니어는 읽기/쓰기 권한을 갖지만, 데이터 소비자는 액세스 할 수 없음	핫, 읽기 및 쓰기가 자주 발생함
스테이징	데이터 엔지니어는 읽기/쓰기 권한을 갖고, 특정 데이터 소비자는 읽기 전용 액세스 권한이 있음	핫, 읽기 및 쓰기가 자주 발생
프로덕션	데이터 엔지니어는 읽기/쓰기 권한을 갖고, parquet format 데이터의 소비자는 읽기 전용 권한을 가짐	핫, 읽기 및 쓰기가 자주 발생
아카이브	데이터 엔지니어는 읽기/쓰기 권한을 갖고, 전용 데이터 재처리 파이프라인에는 읽기 전용 권한이 있으며, 극소수의 특정 데이터 소비자는 읽기 전용 권한이 있음	콜드 또는 아카이브, 데이터 볼륨에 따라 최신 데이터는 콜드 아카이브 컨테이너에 저장되고, 오래된 데이터는 아카이브 컨테이너에 저장할 수 있음
실패	데이터 엔지니어는 읽기/쓰기 권한을 갖고, 전용 데이터 재처리 파이프라인에는 읽기 전용 권한이 있음, 데이터 소비자는 액세스 못함	핫, 읽기 및 쓰기가 자주 발생

 

---

폴더 명명 규칙

컨테이너 내부의 데이터를 논리적 구조로 구축할때 폴더를 활용함

먼저 플랫폼에서 데이터와 데이터 파이프라인을 논리적인 방식으로 구성하는 데 필요한 공통 요소가 무엇인지 살펴보자

 

네임스페이스

• 계층 구조에서 가장 높은 레벨이며, 여러 파이프라인을 논리적으로 그룹화하는데 사용됨
• ex) 수백 개의 파이프라인을 처리하는 대규모 조직에선느 부서명이나 특정 별칭을 네임스페이스로 사용할 수 있음
• 사용자 그룹별로 별도의 네임스페이스 데이터 접근 권한을 관리해야 할 경우, 네임스페이스별로 별도의 스토리지 컨테이너를 생성하면 컨테이너별로도 권한을 부여할 수 있음

파이프라인명

• 파이프라인의 용도를 반영한 이름을 붙여야 함
• 파이프라인명은 로그에도 기록되고, 파이프라인에서 생성한 스토리지 폴더명을 표현할 때도 사용됨

데이터 소스명

• 수집 계층은 플랫폼으로 가져온 각 데이터 소스에 이름을 할당함
• 소스명은 메타데이터 저장소에 저장되지만, 사용자와 파이프라인이 데이터의 출처를 쉽게 식별할 수 있도록 클라우드 스토리지 폴더명에도 소스명을 포함해야 함

배치ID

• 랜딩 영역에 저장되는 데이터 배치 작업에 대한 고유 식별자
• 랜딩 영역에 데이터를 저장하는 유일 계층은 수집 게층이므로, 이 식별자를 생성하는 것이 수집 애플리케이션의 책임임
• 이런 유형의 식별자는 공통적으로 UUID(Universally Unique Identifier)를 사용함
• 기존 ETL 툴들은 UUID를 생성할 수 있음
• 배치 ID로 사용할 수 있는 다른 좋은 방법으로는 ULID(L: Lexicographically)를 사용하는거임
  • UUID보다 짧고 정렬성이 뛰어남
  • ULID를 배치 ID로 사용하는 경우 최신 배치가 항상 목록의 맨 위에 있으며 두 ULID를 비교할 수 있음

---

위에서 데이터 파이프라인의 공통 요소를 식별했으므로, 클라우드 스토리지 컨테이너에서 폴더를 구조화하는 방법을 알아보자

 

랜딩 컨테이너

• 랜딩 컨테이너의 폴더 구조: landing/NAMESPACE/PIPELINE/SOURCE_NAME/BATCH_ID/
  • landing만 컨테이너명이고, 나머지는 폴더 구조 경로임
  • BATCH_ID에 ULID를 배치 식별자로 사용할 수 있음
  • ex)
  • /staging/ETL/sales_oracle_ingest/customers/01DFT
  • 이런 폴더 구조를 보고 스토리지의 폴더를 보는 사람이 문서나 메타데이터 저장소를 참조하지 않아도, 데이터의 출처를 이해할 수 있도록 함

스테이징 컨테이너

• 장기적으로 스테이징 영역에 데이터를 저장할 계획이므로 데이터를 시간별로 정리해야 함
  • 수집 시간 기반 파티셔닝으로 시간별 구성을 할 수 있음
  • 즉, 각 배치가 수집된 시간을 인코딩해 폴더에 넣음
  • ex)
    • /staging/ETL/sales_oracle_ingest/customers/year=2019/month=07/day=03/01DFT
    • 기존 파이프라인과 소스 폴더에 대해 연, 월, 일의 세가지 폴더를 추가해서 표현함
  • 하루에 데이터 배치 파일이 여러 번 수집되면 동일한 폴더에 저장되며, ULID를 사용해서 폴더를 정렬할 수 있으며, 최신 배치는 항상 클라우드 포털 위에 배치하도록 UI 설계가 필요함

 

아카이브 및 실패 컨테이너는 스테이징과 동일한 폴더 구조를 가짐

프로덕션 컨테이너 역시, 신규 파이프라인이 추가될 수 있다는 점을 제외하고, 스테이징과 동일한 구조를 가짐

• 이때, 신규 파이프라인이 작업 어디에서 왔는지를 반영하는 방식으로 작업명을 지정해주는 것이 좋음