데이터 플랫폼 아키텍쳐

 

• 기본 데이터 플랫폼 4계층 아키텍처
• 위에 플랫폼 계층 아키텍처를 확장해볼거임

• 수집 계층에서는 batch와 streaming 수집 두가지가 있음
• 저장 계층에서는 저속 스토리지, 고속 스토리지 개념을 도입함
• 처리 계층에서는 고속 스토리지, 저속 스토리지의 활용과 배치 방식 처리, 스트리밍 데이터 처리 방식을 논의함
• 이 처리 계층 개선을 위해 메타데이터 계층을 추가했음
• 오버레이 게층은 ETL이나 오케스트레이션 작업을 위해 추가함

---

수집 계층

• 데이터 변환을 크게 거치지 않고도 소스 시스템에서 데이터 플랫폼으로 데이터를 전송할 수 있어야 함
• 데이터 레이크에서 raw 데이터를 보존할 수 있어야 함
• 나중에 데이터를 재처리할 경우, 소스 시스템에 다시 연결하지 않아도, 재처리가 가능할 수 있도록 구축해야 함
• 메타데이터 저장소에 수집 통계와 수집 수집 상태를 등록할 수 있어야 함

한번에 하나의 이벤트를 액세스할 때에는 스트리밍 데이터 파이프라인을, CSV, JSON 등 파일의 수집을 위한 FTP 서버 등..은 배치 파이프라인을 사용하면 됨, 두개를 동시에 사용할 수도 있음 (서드파티(제삼의 외부 주체)에 따라 적절한 아키텍처 구성이 필욬)

 

cf)

lambda 아키텍처

• low-latency 분석 결과와 정확한 분석 결과를 함께 제공하기 위해서는 데이터 플랫폼이 배치 데이터 처리 경로와 스트리밍 데이터 처리 경로를 모두 지원해야함을 제안하고 있음
• 람다에서는 동일한 데이터가 서로 다른 두 개의 파이프라인에서 처리된다는 점이 데이터 플랫폼 아키텍처와는 차이점

데이터 수집 계층 특징

• 플러그형 아키텍처(Pluggable architecture)
  • 데이터 수집 계층은 큰 노력 없이 새 커넥터 유형을 추가할 수 있는 구조여야 함
  • 즉, 새로운 유형의 데이터 소스가 항상 추가되기 때문
• 확장성(Scalability)
  • 대량의 데이터 처리를 위해 scale out이 가능해야 함
• 고가용성(High-availability)
  • 개별 컴포넌트의 장애 등.. 장애 대응 체게를 갖고 있어야 함
• 관측 가능성 (Observability)
  • 데이터 수집 계층은 데이터 처리량, 지연 시간 등.. metric을 외부 모니터링 툴에 노출 시켜야 함
  • 이런 메트릭들은 중앙 메타 데이터 저장소에 저장되야 함

---

고속 스토리지, 저속 스토리지

• 데이터 수집 계층을 지나고 나서는 안정적으로 저장할 곳이 필요 함
• 즉, 스토리지 게층이 이 역할을 수행함
• 스토리지 계층 특성
  • Reliable (안정성) (장애 발생시에도 데이터를 지속적으로 유지할 수 있어야 함)
  • Scalable: 최소한의 노력으로 스토리지 용량을 추가할 수 있어야 함
  • Performant(성능): 저속 스토리지는 대용량 데이터에 대한 읽기 성능, 고속 스토리지는 단일 메시지를 읽고 쓸때, low-latencty가 보장되야 함
  • Cost efficient: 스토리지 비용도 고려해야 함

고속 스토리지는 스트림 방식 데이터를 각각의 메시지 단위로 처리하기 위한 메시지 버스임 (데이터 만료 정책이 있음, 일반적으로 KB..) 

저속 스토리지는 배치 데이터를 위한 저장 영역, 영구 데이터를 보존할때 주로 사용 (수십 MB 이상..)

 

장기적인 목적으로 클라우드에서 제공되는 객체 저장소를 사용하는 것이 더 효율적임

스토리지와 직접 연결된 컴퓨팅 서버가 없기 때문

또한, 객체 스토리지 용량을 늘릴때 가상 시스템을 프로비저닝할 필요없이, 클라우드 공급 업체가 대응을 해주기 때문

단점으로 low-latency액세스를 지원하지 않음

 

고속 스토리지를 활용하면 스트리밍 데이터 수집시 low-latency가 가능함

하지만, 용량을 늘릴때 RAM, CPU, 디스크가 포함된 서버를 함께 추가해야 함

고속 스토리지에는 보관 주기 정책을 갖고 있음 (주기가 끝나면 영구 보관 저장소로 이동되거나 삭제됨)

---

처리 계층 (processing)

• 데이터 검증, 데이터 변환, 비즈니스 로직이 수행되고 처리되는 계층
• 실시간 처리/분석과 배치 처리/분석은 분리 구성되야 함
• 데이터 분석가들이 데이터를 액세스하기 위해 데이터를 스토리지에 다시 저장할 수 있어야 함
• 스트리밍 데이터 결과물을 다른 시스템으로 제공할 수 있어야 함
• 즉, 고속 스토리지, 저속 스토리지 모두를 활용할 수 있어야 함
  • 이 두 스토리지를 모두 지원하는 오픈소스  apache beam project, cloud dataflow가 있음
• 처리 계층 특성
  • scale out
  • 배치, 스트리밍 모델 모두 지원해야 함
  • 다양한 프로그래밍 언어가 지원되야 함

---

기술 메타데이터 계층

• 데이터 소스의 스키마 정보, 수집 상태 정보, 성공/실패 여부..등 변환 파이프라인 상태 정보
• 행 개수 등.. 수집 데이터와 처리된 데이터 관한 통계 정보
• 데이터 변환 파이프에 대한 계보 정보 등..

즉, 데이터 플랫폼 계층들의 처리 상태에 대한 정보를 저장하며, 각 계층에서 저장소의 메타데이터를 읽고, 추가, 변경할 수 있도록 인터페이스를 제공함

각 계층 간 직접 통신하지 않는 경우도 있기에, 메타 데이터 계층을 통해 현재 어떤 데이터를 처리 가능한지 알 수 있게 됨 (계층 간의 독립성을 높임)

메타 데이터 특징

• Scalable
• Hight Available: 메타 데이터 계층은 SPOF가 될 수 있기에, 이에 대응 가능해야 함
• Extendable: 다양한 역할을 위해 사용할 수 있음

---

서비스 계층과 데이터 소비자

• 소비자(사람, 시스템 등...)에게 결과물을 제공
• 관계형 데이터 구조를 원하면, 데이터 웨어하우스(필터링 작업이 일어나는 곳)를 통해 데이터 제공
• 스토리지에 바로 액세스하는 소비자에게는 데이터 웨어하우스를 거치지 않고 데이터 제공
• 서비스 계층 특징
  • 확장성과 신뢰성
  • NoOps: 튜닝 작업과 운영 유지보수 작업이 최대한 적어야 함
  • 탄력적 비용 모델

---

오케스트레이션 오버레이와 ETL 오버레이 계층

• 오케스트레이션 오버레이
  • 상호 의존성 그래프를 기반으로 여러 데이터 처리 작업을 조정할 수 있어야 함
  • 즉, 데이터 처리 선후 관계 여부..
  • 작업 실패, 재시도 관리

메타데이터 계층을 통해 서로 통신하는 방식은 느슨한 결합 형태이며, 누락된 부분이 여러 계층에 걸쳐 진행될때 조율하는 컴포넌트의 역할을 수행하는게 오케스트레이션 계층

• 오케스트레이션 계층은 task간의 독립성을 유지하는 상태에서 task들을 cordination 함
• 상품 데이터와 POS 데이터가 수신되면 taks1 을 트리거 하고 task1이 완료되면, 하루치 클릭 스트림 데이터가 누적되면 task2를 트리거함

ETL 오버레이

• 데이터 파이프라인을 더욱 쉽게 구현하고 유지 관리하도록 하는 제품 모음을 말함
• 이런 툴들은 각 계층에 맞는 메커니즘을 제공함