티스토리 뷰

반응형

데이터 플랫폼 빌딩 블록 : 상위 레벨 아키텍처 

구분 내용
데이터 플랫폼의 빌딩 블록
  1. 데이터 플랫폼의 목적 
    1. 분석에 활용될 수 있도록 어떤 유형의 데이터든 최대한 비용 효과적인 방식으로 데이터를 수집, 저장, 처리해서 활용할 수 있도록 제공하는 것
  2. 계층간 느슨하게 결합돼 있는 형태의 아키텍처를 지향한다. 
    1. 각 계층은 각가의 특정 역할을 담당하고, 잘 정의된 API를 통해 각 계층간 상호교류한다. 
       
수집 계층 (Ingestion Layer)
  1. 데이터를 데이터 플랫폼으로 가져오는 역할 
    1. 관계형 데이터베이스, NoSQL 데이터베이스, 파일 스토리지, 사내 API, 타사 API 등..에 접속해 데이터를 추출하는 역할을 담당
    2. 유연성이 높아야 한다. >> 활용하고자 하는 데이터 소스가 다양해 지고 있음 
    3. 대부분 오픈 소스 툴이나 사용 툴을 사용해 구현하는 경우가 많다. 
      1. Fluentd, Logstash 등...
  2. 주의 사항 
    1. 이 계층에서는 어떤 경우에도 수집되는 데이터를 수정하거나 변환해서는 안된다. 
    2. 원시 데이터를 데이터 레이크에 보관함으로써 데이터 계통 추적 및 재처리 할 수 있도록 하기 위함
스토리지 계층
(Storage Layer)
  1. 데이터를 저장하는 역할 >> 데이터 레이크 스토리지 계층 
    1. 데이터의 수집 속도와 양을 언제든지 수용할 수 있도록 확장성이 뛰어나야 한다. 
    2. 비용도 저렴해야 한다. 
    3. 원시 데이터 형태의 데이터를 저장할 수 있어야 한다. >> 다양한 데이터 유형 대응이 가능해야 한다. 
      1. CSV, JSON, 아브로, 파케이, 이미지, 비디오 등... 거의 모든 파일 형식 지원이 가능해야함
처리 계층
  1. 활용 목적에 맞게 저장된 데이터를 처리하는 역할 
    1. 데이터 과학자 같은 전문 분석가들이 좀 더 사용하기 쉽게 원시 데이터를 어느 정도 미리 변환 >> 생산성 및 효율성 측면 
  2. 활용 가능한 기술 프레임 워크 : 상위 수준에서 현대 프로그래밍 언어를 사용해 데이터 변환, 유효성 검사, 정제 작업을 흐름 수준으로 쉽게 프로그래밍 할 수 있도록 지원 
    1. 아파크 스파크 
    2. 아파치 빔 
    3. 아파치 플링크 
  3. 위 프레임 워크를 통해, 클라우드 스토리지로부터 데이터 읽고, 더 작은 청크로 분할(데이터 규모에 따라 필요한 경우), 유연한 클라우드 컴퓨팅 리소스들을 사용해 데이터 청크 처리를 한다.
  4. 데이터 처리 방식 
    1. 배치 처리 
      1. 데이터 수집 후 스토리지에 저장 후 처리 
      2. 데이터의 규모가 크고 처리 시간에 민감하지 않을 경우 
    2. 스트림 처리  
      1. 데이터 수집 후 스토리지를 거치지 않고 처리 부터 진행 
      2. 처리 시간 요구 사항이 초단위인 경우 
서비스 계층
(Serving Layer)
  1. 사용자나 다른 시스템에서 데이터를 활용할 수 있도록 준비
    1. 연계되는 시스템이 다양화 되고 각 조직별로 다른 기술 배경을 가진 경우가 많음 
    2. 다양한 요구 사항을 대응하기 위해서 별도의 Layer 필요 
      1. 데이터 분석가, 인공지능 연구자 : 다양한 프로그래밍 언어로 데이터에 접근 가능하도록 지원해야함 
      2. BI Tool에서는 SQL 언어 지원이 가능해야함 

 

데이터 플랫폼 설계 : 상세

구분
내용
데이터 플랫폼 설계
  1. 수집 계층: 스트리밍 데이터, 배치 데이터 구분 
  2. 저장 계층 : 저속 스토리지, 고속 스토리지 구분
  3. 처리 계층 : 배치 처리, 스트리밍 처리 구분
  4. 메타데이터 계층 : 처리 계층 개선을 위해 필요한 계층 
  5. 서비스 계층  : 데이터 웨어 하우스 + 다른 데이터 소비자들도 포함되도록 구성 
  6. 오버레이 계층 : ETL이나 오케스트레이션 작업 위해 존재 
수집 계층 
  1. 스트리밍 모드, 배치 모드에서 다양한 데이터 소스로 보안 연결 할 수 있어야 한다. 
  2. 메타데이터 저장소에 수집 통계와 수집 상태를 등록할 수 있어야 한다. 
    1. 예 : 스트리밍 데이터 소스인 경우 특정 시간 간격 동안 데이터 수집량, 배치 방식의 경우 배치당 데이터 수집량 
  3. 데이터 수집 계층의 특성 
    1. 플러그형 아키텍처 : 새로운 유형의 데이터 소스가 항상 추가 된다는 가정.
      1. 큰 노력 없이 새 커넥터 유형을 추가 할 수 있는 구조 준비 필요 
    2. 확장성 : 대량의 데이터를 처리할 수 있어야 한다. 
      1. 복수개의 서버로 스케일 아웃 할 수 있어야 한다. 
    3. 고가용성 : 데이터 수집 계층은 개별 컴포넌트의 장애 유형들, 디스크 장애, 네트워크 장애, 가상 시스템 전체 다운등을 고려한 장애 대응 체계를 갖고 있어야 한다. 
    4. 관측 가능성 : 데이터 처리량, 지연 시간과 같은 중요한 메트릭을 외부 모니터링 툴에 노출 
메타 데이터 계층 
  1. 메타 데이터 관리 대상
    1. 데이터 소스의 스키마 정보
    2. 수집 상태 정보, 성공, 실패, 오류율 등
    3. 파이프라인의 상태 정보
    4. 행 개수와 같은 수집 데이터와 처리된 데이터에 대한 통계 정보
  2. 역할 
    1. 데이터 플랫폼 계층들의 처리 상태에 대한 정보 관리 
    2. 각 계층에서 저장소의 메타데이터를 읽고, 추가, 변경 할 수 있도록 인터페이스 제공 
    3. 자동화, 모니터링, 경보, 개발자 생산성 효율 면에서 매우 중요 
    4. 각 계층이 정보 공유 할 수 있도록 제공 >> 독립성 높임  
      1. 예 : 처리 계층이 수집 계층과 직접 통신하지 않고 현재 어떤 데이터 처리가 가능한지 메타데이터를 통해 확인 가능 
  3. 메타데이터 저장소가 가져야 할 특성 
    1. 확장성 : 플랫폼 환경에서 많은 개별 작업이 실행될 수 있음 >> 개별 작업에서 오는 요청을 빠르게 응답할 수 있어야 함. 
    2. 고가용성 : 단일 장애 지점이 될 가능성이 있음 
    3. 확장 가능 : 많은 양 또는 다양한 메타 데이터 관리를 위해 필요 
서비스  계층 
  1. 분석 결과물을 제공 
    1. 관계형 데이터 구조와 SQL 지원을 원하는 소비자에게는 데이터 웨어 하우스 
      1. BI 툴이나 타 서비스 연동에 용이함
    2. 스토리지로 부터 데이터를 바로 액세스하려는 소비자에게는 저속 스토리지 또는 고속 스토리지로 제공 
      1. ML 애플리케이션을 사용하는 데이터 과학자들은 대부분 스토리지에서 원시 파일을 읽는 경우가 많음 
반응형
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함