데이터 플랫폼 설계와 구축 | 2장 데이터 웨어하우스만이 아닌 데이터 플랫폼인 이유

2장 데이터 웨어하우스만이 아닌 데이터 플랫폼인 이유

요약

• 정형 데이터와 반정형 데이터를 모두 대응해야하는 경우, 데이터 플랫폼을 구성해야 한다
• 웨어하우스방식은 수집된 데이터를 바로 웨어하스에 저장하지만, 플랫폼 방식은 블롭 스토리지와 데이터브릭스를 사용해서 수집, 임시저장, 처리의 계층을 분리하였다
• 웨어하우스 방식과 달리 플랫폼 방식은 입력 스키마 변경에 자유로울 수 있다
• 웨어하우스 방식과 달리 플랫폼 방식은 JSON과 같은 반정형 데이터가 분석 될 때에도 모듈화, 테스트, 유지보수성을 제공할 수 있다
• 플랫폼 방식에서 수집, 임지 저장, 처리의 계층을 분리한 덕분에 스키마 변경에 대해서 더욱 자유로울 수 있고, 스파크와 같은 분산 데이터 처리 엔진을 사용할 수 있게 된다
• 데이터 플랫폼을 사용하는 사용자마다 데이터를 조회하는 방식과 목적이 다른데, 이러한 다양한 요구사항을 만족하기 위해서라도 데이터 플랫폼 방식처럼 계층을 분리하는 것이 좋다

2.0. 들어가며

• 1장 : 데이터 플랫폼의 정의. 데이터의 어떤 변화(3V)가 데이터 플랫폼의 형태를 만드는지 설명함
• 2장 : 클라우드 데이터 플랫폼이 단일 데이터 웨어하우스 아키텍처와 달리, 더 많은 기능을 제공하는 이유를 상세하게 살펴봄
  • 데이터 플랫폼 프로젝트를 착수할 때 프로젝트 배경인 “왜”에 대해서 알고 시작할 수 있음
  • 프로젝트 진행 과정에서 훨씬 적절하게 의사 결정을 할 수 있음
  • 클라우드 데이터 플랫폼 프로젝트를 착수해야하는 이유인 당위성은 비즈니스 관점에서 설명할 수 있게 됨

2.1. 클라우드 데이터 플랫폼과 클라우드 데이터 웨어하우스: 실용적 측면

• 요구사항
  • 데이터
    • 이메일 마케팅 캠페인 데이터 : 관계형 데이터베이스 (MySQL RDBMS)에 저장되어 있음
    • 클릭 스트림 데이터 : 웹 사이트의 모든 사용자의 활동을 캡처 → CSV 파일로 저장 → 내부 SFTP 서버에 저장되어 있음
  • 분석 목표
    • 캠페인 데이터와 클릭 스트림 데이터를 조합해야 함
    • 사이트에 방문한 경로가 특정 이메일 마케팅 캠페인의 링크를 통해서 들어온 사용자인지 여부
    • 사용자들이 어떤 사이트를 방문했는지 식별
  • 기타
    • 분석 작업이 반복적으로 수행되어야 함
    • 데이터 파이프라인에서 데이터를 정기적으로 클라우드 환경으로 가져와야 함
    • 업스트림 소스의 변화에 대해서도 자체 회복력이 있어야 함
    • 비용 효율적이어야 함
    • 성능 기준에도 부합해야 함
• 접근 방법
  1. 데이터 플랫폼 안에 데이터 웨어하우스가 포함되어 있는 경우 (이하 데이터 플랫폼)
  2. 전용적 데이터 웨어하우스 (데이터 웨어하우스)
• 참고
  • Azure Synapse :
    • MS SQL Server데이터베이스 엔진 기반 완전 관리형 웨어하우징 솔루션
    • 두 가지 접근 방법 중 데이터 웨어하우스 방법과 유사함

2.1.1. 데이터 소스 자세히 살펴보기

• 이메일 마케팅 캠페인 데이터
  • campaign_id : 켐페인의 고유 식별자
  • email : 캠페인이 전송된 대상 이메일 주소 목록
  • unique_code : 각 특정 사용자에 대한 회사 웹 사이트 링크에 포함된 고유 코드
  • send_date : 캠페인이 전송된 날짜
  • 클릭 스트림 데이터
    • 고정 스키마가 없음
      • 웹 애플리케이션 로그에서 파생된 반정형 데이터
      • 방문한 페이지에 대하 세부 저옵
      • 방문자의 브라우저와 운영 체제 정보
      • 세션 식별자
  • 여기서는 아래의 3개 컬럼이 포함된 CSV 형식의 수백 GB 텍스트 파일
    • timestamp : 이벤트가 발생한 시점의 unix 타임스템프
    • content_json : 페이지 URL, 고유 방문자 식별지, 브라우저 정보
    • other_details : 기타 세부 정보
    • 특이사항 : content_json 컬럼이 중첩된nested 필드를 많이 가진 json 문서
• 해야하는 작업 2가지
  1. 두 데이터 소스를 성능과 비용 효율적인 방식으로 통합한 클라우드 데이터 플랫폼 설계
  2. 마케팅 팀에서 통합 데이터 분석을 위해 사용할 수 있도록 하는 것

2.1.2. 클라우드 데이터 웨어하우스만 활용한 사례

• 전통적인 기업용 데이터 웨어하우스 솔루션과 매우 유사함
• 아키텍처의 중심이 최종 사용자에게 데이터를 저장, 처리, 제공하는 역할을 하는 관계형 데이터 웨어하우스이다
• 애저에서 제공하는 두 개의 PaaS 서비스
  • 애저 데이터 팩토리
    • 데이터 파이프라인 역할
      • 완전 관리형 PaaS ETL 서비스
      • 다양한 데이터 소스에 연결하거나 데이터를 수집
      • 파일 압축 해제 또는 파일 형식 변경
      • 처리 및 서비스를 위해 destination 서비스에 데이터를 적재
    • 기능
      • MySQL 테이블에서 이메일 캠페인 데이터를 읽음
      • SFTP 서버에서 클릭 스트림 데이터가 포함된 파일을 가져옴
      • 가져온 데이터를 애저 시냅스로 적재
  • 애저 시냅스
    • MS SQL Server기술을 기반으로 하는 완전 관리형 웨어하우스 서비스
    • 완전 관리란
      • 데이터베이스 서버를 직접 설치, 구성, 관리하지 않아도 됨
      • 컴퓨팅 크기와 스토리지 용량만 선택하면 나머지는 애저가 알아서 함

2.1.3. 클라우드 데이터 플랫폼 아키텍처 사례

• 공통점
  • 애저 데이터 팩토리와 애저 시냅스를 사용하는 것은 동일하다
• 차이점
  1. 데이터 팩토리를 사용해서 소스 시스템에 연결해 추출
  2. 애저 블록 스토리지의 랜딩 영역에 소스 데이터를 저장 (data lake)
     1. 원천 데이터 형식을 보존할 수 있음
     2. 데이터 다양성에 관한 문제점 해결 등 이점이 있음
  3. 데이터가 애저 블롭 스토리지에 도착하면 애저 데이터브릭스는 apache spark를 사용해서 데이터를 처리한다
     1. 스파클르 직접 설치, 구동하지 않아도 됨
     2. 노트북 환경도 제공
     3. 스파크 프로그램을 컴파일하고 클러스터에 전송하는 과정 없이, 레이크의 데이터로 스파크 명령을 바로 실행해 결과를 즉시 확인할 수 있음
     4. 스파크와 같은 분산 데이터 처리 프레임워크는 다양항 데이터 형식과 거의 무한한 데이터 볼륨을 처리하는데 도움을 줄 수 있음
     5. 하지만 대화형 쿼리 용도로는 적합하지 않음
        1. 대화형 : 쿼리 응답 예상 시간이 몇 분이 아닌 몇 초 이내인 경우
     6. 대화형을 위해서는 분산 데이터 처리 프레임워크보다 ‘관계형 웨어하우스’를 잘 설계해서 사용하는 것이 스파크보다 빠른 쿼리 성능을 제공함
        1. 상용 리포팅 툴이나 BI 툴토 스파크와 같은 분산 시스템보다는 RDBMS 데이터베이스와 훨씬 잘 통합 되어 있어, 일반 사용자가 사용하기 용이하다
        2. 💡 스파크 = 애저 데이터 브릭스 = 분산 데이터 처리 프레임워크 = 대화형 쿼리에는 적합하지 않고, 관계형 웨어하우스를 사용해야 함

2.2. 데이터 수집

• 데이터 팩토리
  • 다양한 데이터베이스 소스용 커넥터 세트를 기본 제공
  • 기초 수준의 데이터 변환 기능
  • 많이 사용되는 데스티네이션 시스템 데이터 저장 기능 제공

2.2.1. 애저 시냅스로 직접 데이터 수집

• 데이터 팩토리에서 바로 애저 시냅스로 직접 데이터 적재하는 경우
• 데이터 팩토리 파이프라인
  • 연결 서비스
  • 입력 및 출력 데이터 세트
  • 처리 작업
• 연결 서비스 = 특정 데이터 소스(이 경우, MySQL) 또는 데이터 싱크(이 경우, 애저 시냅스)에 대한 연결을 의미함
  • 데이터 소스의 위치
  • 소스 연결에 사용할 자격 증명 등을 포함함
• 데이터 세트 : 연결된 서비스에 위치한 특정 객체
  • MySQL 데이터베이스 테이블
  • 애저 시냅스의 데스티네이션 테이블
  • 데이터 세트의 중요한 속성은 스키마이다.
• 소스와 데스티네이션 테이블의 스키마를 미리 알고 있어야 데이터 팩토리가 MySQL에서 애저 시냅스로 데이터를 적재할 수 있다
• 파이프라인이 실행되기 전에 파이프라인에서 스키마를 사용할 수 있어야 한다
• 입력 데이터 소스에 대한 스키마는 데이터 펙토리에서 자동으로 유추할 수 있지만
• 출력 스키마 + 입출력 스키마 간 매핑 정보는 사전에 제공되어야 함
• 위 사진에서는 입출력 스키마가 유사하지만, 실제 상황에서는 입출력 스키마가 다를 수 있다

2.2.2. 애저 데이터 플랫폼으로 데이터 수집

• 수집 데이터의 기본 데스티네이션은 애저 블롭 스토리지이다.
• 이 유즈케이스에서는 무한 확장 가능한 파일 시스템으로 생각할 수 있다

• 주요 차이점
  • 애저 블롭 스토리지에서는 스키마를 미리 지정할 필요가 없다
  • MySQL에서 소스 컬럼 및 데이터 형식에 관계없이 수집한 데이터가 애저 블롭 스토리지에 텍스트 파일로 저장된다
  • 데이터 처리를 위한 추가 계층을 두어 아파치 스파크 등을 사용해서 처리한다.
  • 이 과정을 통해서 출력 스키마와 소스 스키마에 대한 매핑 정보를 수작업으로 처리할 필요성이 없어진다
    • 관계형 데이터베이스에는 수백 개의 테이블이 포함되어 있는데, 이 작업이 수작업으로 인한 오류가 발생할 수 있는 가능성을 없앤다
    • 변경이 생겼을 때도 시스템의 회복성을 가질 수 있게 된다

2.2.3. 업스트림 데이터 소스의 변경 관리

• 소스 데이터 세트는 전혀 정적이지 않다
• 마케팅 캠페인 관리 소프트웨어를 담당하는 개발자는 꾸준히 새로운 기능을 추가할 것이다
• 소스 테이블에 신규 컬럼이 추가되거나 컬럼명이 변경 또는 삭제될 수 있다
• 데이터 팩토리는 컬럼 위치에 따른 입출력 컬럼 매핑 방식이고, 출력 컬럼의 이름 변경을 지원한다.
• 입력 컬럼에 region 컬럼이 도착하면 스키마가 변경되었기 때문에 애저 시냅스로 삽입하는 작업이 실패하게 된다
• 운영자는 출력 데이터 세트 스키마를 수작업으로 변경하고 파이프라인을 다시 시작해야 한다

💡 애저 블롭 스토리지와 같은 데스티네이션은 입력 스키마 정보에 대해 상관하지 않지만, 데이터베이스와 애저 시냅스 같은 데스티네이션들은 스키마가 사전에 엄격하게 정의되어야 한다. 데스티네이션의 스키마 변경이나 신규 컬럼 추가 작업은 가능하지만, 작업 방법은 데스티네이션 유형에 따라 차이가 있다.

예를 들면, 일부 데이터베이스의 경우, 스키마 변경 시 테이블 락 메커니즘이 존재하므로 최종 사용자가 사용할 수 없는 상황이 되기도 한다. 또, 해당 테이블의 데이터 크기에 따라 스페이스 크기 조정니나, 스키마 변경 작업에 몇 시간 이상 걸리는 경우도 있다.

다수의 데이터 데스티네이션 스키마 변경을 일원화된 방식으로 처리할 수 없다보니, 데이터 팩토리나 ETL 툴에서는 플랫폼 운영자가 이 작업을 맡는다

• 업스트림 스키마 변경에 대한 회복력은 데이터 웨어하우스 접근 방법에 비해 데이터 플랫폼 아키텍처가 가진 이점 중 하나이다.
• 출력 스키마가 필요하지 않으므로, 소스 스키마가 변경되더라도 수집 파이프라인이 신규 스키마를 가진 파일을 생성하면서 계속 작업을 이어나간다
• 그런데 저장된 데이터를 사용하는 입장에서는 신규 컬럼이 추가됐다는 사실을 알아야 한다.
• 데이터 플랫폼에서 스키마 변경 처리 방법은 8장에서 다룬다

2.3. 데이터 처리

• 아래와 같은 데이터에 대해서 데이터 웨어하우스 방식과 데이터 플랫폼 방식의 차이를 알아보자

2.3.1. 웨어하우스에서 데이터 처리

• 웨어하우스 설계에서 데이터 소스의 데스티네이션으로 애저 시냅스를 사용했다
• 수집 프로세스를 통해 두 개의 관계형 테이블(클릭 스트림 데이터용, 이멩리 마케팅 캠페인 데이터용) 데이터가 적재 됐다
• 이 테이블을 기반으로 작업을 진행해야 한다
• 캠페인 데이터는 관계형 테이블에서 관계형 테이블로의 변환이므로 간단하다
• 클릭 스트림 데이터처럼 중첩된 json 문서의 처리가 어려워진다

• 위 예제에서 어려운 점은 JSON 문서에서 값을 파싱하고 추출하는 로직이다
• ETL 파이프라인에서 미리 파싱하거나, 쿼리의 가독성을 높이기 위해 사용자 정의 함수UDF를 만들 수는 있지만, 클릭 스트림 데이터의 크기는 점점 커지고 UDF를 유지보수해야하는 문제점이 있다.
• 뿐만아니라 테스트도 어렵다
• 테스트가 어려우면 사용자와 좋은 신뢰 관계를 구축할 수 없다
• 애저 시냅스의 다양한 성능 최적화 기법을 적용할 수 없는 문제도 있다
  • 일반적으로 숫자나 짧은 문자가 포함된 컬럼을 압축하고, 쿼리가 실행되는 동안 디스크를 읽는 횟수를 줄여준다
  • JSON 값을 사용하면 개별 속성별로 파싱해 액세스해야하기 때문에 데이터 크기가 증가할수록 쿼리 성능에 부정적인 영향을 미친다

2.3.2. 데이터 플랫폼에서 데이터 처리

• 여러 종류의 분산 데이터 처리 엔진을 사용해서 규모에 상관없이 처리할 수 있는 다양한 방법을 제공한다
• 아파치 스파크는 가장 많이 사용되는 분산 데이터 처리 엔진 중 하나이다
• 서비스를 사요하면 클러스터 배포와 설정에 대해 걱정할 필요가 없다
• 아파치 스파크에서는 SQL을 사용해서 데이터를 처리하거나, 파이썬이나 스칼라와 같은 프로그래밍 방식으로 처리할 수 있다
• SQL은 작성과 확인이 빠르기 때문에 간단한 리포트나 애드혹 분석에 사용한다
• 장기적으로 유지보수할 계획이고, 코드의 테스트 용이성이 높아야한다면, 파이썬 API를 사용한다

2.4. 데이터 엑세스

• 최종 사용자가 데이터 웨어하우스와 데이터 플랫폼에 데이터에 액세스하는데 사용할 수 있는 툴을 검토한다
• 마케팅 팀 : 비즈니스 사용자 계층으로, 각 캠페인 진행 과정에서 방문한 상위 10개 페이지 정보들이 무엇인지 관심있다
  • Power BI와 같은 리포팅 풀, 대시보드 툴, SQL 인터페이스
• 데이터 분석가 : 다양한 방법으로 데이터를 분할하거나 가공하고자 하는 고급 사용자
  • SQL 인터페이스
• 데이터 과학자 : 방문한 페이지 기반에 따라 사용자를 프로필별로 분류하고자 하는 고급 사용자
  • 결과 데이터 세트뿐만 아니라 원시 클릭 스트림 데이터에도 액세스해야 하는 경우가 있음
  • 스파크와 같은 툴과 애저 블롭 스토리지의 파일에 대한 액세스가 필요하다
  • 웨어하우스에 적재되는 데이터는 집계 및 정리된 형태인데, 이미 존재하는 방식보다 더 세부적인 집계 방식이 필요한 경우 애저 블롭 스토리지의 파일에서 원본 엑세스가 필요할 수 있다

2.5. 클라우드 비용 고려사항

• 단일 클라우드 공급 업체 내에서도 서로 다른 서비스의 사용료와 구축 비용을 비교하기가 쉽지 않다
• 공급 업체 간 비교는 더더군다나 어렵다
• 스토리지는 상대적으로 저렴하고, 처리 연산이 많은 서비스들은 대체로 비용이 높다. 아키텍처를 고려할 때에는 서비스에서 비용이많이 들 만한 요소를 먼저 알아야 한다
• 어떤 서비스가 가장 비용이 많이 드는지 알고 나면, 이 서비스가 진정한 탄력적 확장을 지원하는지 확인해야 한다.
• 탄력적 서비스의 개념은 필요한 만큼만 사용하고, 필요하지 않을 때 축소해 전체 비용을 최적화할 수 있다는 것이다
• 많은 클라우드 서비스가 그렇다라고 주장하지만, 플랫폼 아키텍트는 이러한 주장을 검증하고 장단점을 이해해야 한다
• 애저 시냅스
  • 처리 용량 측면에서 확장 및 축소가 가능하다.
  • 하지만 확장에는 때로는 수십 분 씩의 시간이 걸린다.
  • 이 시간동안은 전체웨어하우스를 사용할 수 없는 상태가 된다.
  • 따라서 진정한 탄력적 확장을 지원하지 않는다고 할 수 있다. 사용자가 24시간 데이터에 엑세스하지 않아도 되면, 밤 시간에만 업무가 수행되도록 할 수 있다. 그런데 확장 작업 시간동안에는 사용할 수 없다.
  • 애저 시냅스가 여러 인스턴스를 생성해 동일한 데이터 기반에서 동작학 ㅔ하려면, 인스턴스 간 데이터 복제가 가능해야하는데, 이 작업도 역시 시간이 소요된다
• 데이터 브릭스
  • 스파크가 실행되고 있는 가상의 머신의 메모리에 데이터를 복사한다.
  • 복사 과정은 신규 작업을 시작할 때 약간의 오버헤드가 있지만, 동일한 데이터로 동작하는 여러 스파크 클러스터를 만들 수 있다는 점에서 이점이 있다.
  • 탄련성 관점에서 볼 때, 애저 데이터브릭스는 애저 시냅스보다 비용 통제 옵션이 우수하다. 대량의 SparkSQL 쿼리를 실행하기 위해 전용 클러스터를 프로비저닝하고, 실행을 완료하면 대부분 클러스터를 제거한다.