일년 전쯤 데이터 메시를 읽고, 더 나은 데이터 파이프라인에 대해 고민하다가 샀던 책이다. 이 책은 데이터 웨어하우스를 넘어서 데이터 플랫폼이 필요한 이유와 클라우드를 이용해 데이터 플랫폼을 구축하는 방법에 대해 세세하게 알려준다. 지금와서 다시보니 새롭게 보이거나 더 공감가는 내용이 많아서 꺼내든 김에 한번 정리하려고 한다.
들어가며
모든 비즈니스에는 데이터 분석이 필요하다.
비즈니스를 하는 곳에서는 항상 비즈니스 지표를 측정하며 이 지표를 기반으로 의사결정을 한다.
최근에 기술발달로 새로운 데이터 관리 구조인 클라우드 기반의 데이터 플랫폼이 나왔다.
클라우드 데이터 플랫폼은 "모든 유형의 데이터를, 거의 무제한의 장소에서 비용 효과적인 클라우드 네이티브 방식으로 수집, 통합, 변환, 분석, 관리되는 데이터 플랫폼" 이다.
1.1 데이터 웨어하우스에서 데이터 플랫폼으로의 이동
- 데이터 웨어하우스는 오랜 기간동안 여러 영역에서 사용되어 왔지만 최근에는 부족한 점들이 드러나고 있다
- Saas의 활용이 폭발적으로 증가하면서 수집 데이터의 다양성과 종류가 크게 증가(비정형, 반정형 데이터 등)
- 애플리케이션 아키텍처가 모놀리식에서 마이크로서비스 형태로 변경됨에 따라 각 마이크로서비스로부터 메시지를 수집해야함
- 사업부서 구성원과 데이터 사이언티스트들이 원시 데이터를 직접 액세스하는 경향이 늘고 있음
1.2 데이터의 속도, 규모, 다양성이 증가하는 상황에서 데이터 웨어하우스의 한계
1.2.1 데이터의 다양성(Variety)
- 기존 데이터 웨어하우스는 정형 데이터만 처리하도록 설계되어 있음
- Saas, 소셜 미디어, 사물 인터넷의 증가로 분석해야 할 데이터 유형이 훨씬 다양해짐
- Saas 공급 업체들은 JSON 파일 형식을 사용한 API 제공하지만 예고 없이 스키마의 변경이 동반되며 이를 유연하게 대응하기 힘듦
- 이를 웨어하우스에서 처리하려할 경우 웨어하우스에서 제공하는 SQL 엔진과 프로시저 언어만 사용해야 하는 제약이 있음
1.2.2 데이터의 규모(Volume)
- 오늘날의 인터넷 세상에서는 소규모 기업에서도 테라 바이트 단위를 데이터를 처리하는 경우도 많음
- 기존 데이터 웨어하우스에서는 스토리지와 처리 영역이 결합되어 있어 확장성과 유연성에 제약이 있음
- 스토리지와 서버가 결합되어 스토리지를 증설하기 위해서는 필요하지 않은 컴퓨팅 자원을 구입하거나, 서버를 증설하기 위해 스토리지도 함께 구매해야함
1.2.3 데이터의 속도(Velocity)
- 스트리밍 데이터가 늘어나고 그에 맞춰 (준)실시간 분석 요구들이 늘어나고 있음
- 기존 데이터 웨어하우스는 배치 중심 처리 방식으로 배치 처리가 끝나기 전에는 분석이 불가능함
1.3 데이터 레이크가 대안이 될 수 있을까?
데이터 레이크: 나중에 사용하기 위해 가공하지 않은 방대한 양의 데이터를 한곳에 모아둔 스토리지 저장소 - WhatIs.com
- 데이터 웨어하우스가 처리할 수 없는 데이터 형식의 증가로 데이터 레이크가 출현함
- 정형, 비정형, 반정형, 바이너리 등 모든 유형의 데이터를 가져와 보관하고 확장성있게 데이터를 저장, 처리할 수 있었음
- 하둡이 소개된 이후 데이터 레이크는 "하둡"과 동의어처럼 사용됐으며 실질적인 표준이었음
- 데이터의 다양성 - 데이터 웨어하우스는 schema-on-write 방식, 하둡은 schema-on-read 방식으로 어떤 형식도 즉시 저장하고 나중에 처리 할 수 있음
- 데이터의 규모 - 하둡은 저렴한 범용 하드웨어를 활용한 분산 서버, 분산 스토리지로 쉽고 빠르게 대용량 데이터 처리 가능
- 데이터의 속도 - 스트리밍 데이터 수집, 저장, 처리에 용이하며 비용도 저렴 (Hive, MapReduce, Spark)
- 하지만 다음과 같은 단점이 있음
- 데이터 센터에 여러가지 컴포넌트들이 통합된 매우 복잡한 시스템으로 유지보수가 쉽지 않음
- 데이터를 활용하는 사용자들에게는 쉬운 시스템이 아님
- 스토리지와 컴퓨팅이 분리되어 있지 않음
- 시스템을 확장하기 위해 하드웨어를 추가 및 변경하려면 몇 개월씩 걸리기도함
하둡의 장점은 살리고, 단점을 보완한 솔루션이 클라우드와 함께 등장
1.4 퍼블릭 클라우드 활용
- 스토리지든 컴퓨팅이든 필요한 만큼 리소스 할당받을 수 있고, 리소스의 추가 및 축소가 자유로움
- 스토리지와 컴퓨팅이 분리되어 제공
- 클라우드 환경은 사용한 양만큼만 비용 지불
- 서버 설치 없이 즉시 사용가능
- 클라우드엥서만 사용할 수 있는 데이터 처리 프레임워크 사용가능
1.5 클라우드 데이터 플랫폼의 등장
- 다양성이 높아진 데이터를 처리하기 위해 데이터 웨어하우스와 데이터 레이크를 조합하는 방식으로 구성하는 것이 효과적
- 모든 데이터에 즉시 액세스하려는 요구 - 데이터 레이크
- 적절히 정제된 데이터를 요구 -> 데이터 웨어하우스
- 이 둘의 조합과 클라우드 서비스를 활용해 데이터 플랫폼을 설계
1.6 클라우드 데이터 플랫폼의 빌딩 블록
- 데이터 플랫폼은 여러 계층이 느슨하게 결합된 형태의 아키텍처를 지향
- 각 계층은 각각 특정 역할 담당하고, 잘 정의된 API를 통해 계층간 상호교류
1.6.1 수집 계층
- 수집 계층은 데이터를 데이터 플랫폼으로 가져오는 역할
- 다양한 데이터 소스 - 관계형 데이터베이스, NoSQL, 파일 스토리지, API등 데이터 추출
- 데이터 소스 유형이 다양하기 때문에 이 계층은 유연성이 높아야함
- 어떤경우에도 수집되는 데이터를 수정하거나 변환해서는 안됨 -> 원시 데이터를 보관하여 데이터 리니지 추적 및 재처리 할 수 있도록
1.6.2 스토리지 계층
- 수집한 데이터를 저장하는 역할
- 데이터 레이크 스토리지 계층으로 수집 속도와 양을 수용할 수 있도록 확장성이 뛰어나고 비용도 저렴해야함
- 클라우드 스토리지
- 완전 관리형 서비스
- 사용량에 따라 비용 지불하며 언제든 볼륨을 늘리거나 줄일 수 있음
- CSV, JSON, Avro, Parquet, 이미지, 비디오 같은 바이너리 파일도 자유롭게 저장 가능
1.6.3 처리 계층
- 수집한 원시 데이터를 클라우드 스토리지에 저장한 후 활용 목적에 맞게 처리하는 역할
- 기존 SQL 엔진 만으로는 단위 테스트나 데이터 클렌징같은 작업이 어렵고, RDBMS 데이터베이스 엔진 내부에서만 이루어질 수 있어 데이터 처리 작업에 한계점이 많음
- 데이터 처리 프레임워크를 활용해 데이터 변환, 유효성 검사, 클렌징 작업을 쉽게 프로그래밍 할 수 있음 (ex. 아파치 스파크, 빔, 플링크)
- 데이터 처리 방식은 크게 두가지
- 배치 모드: 데이터를 스토리지에 먼저 저장한 다음 처리
- 스트리밍 모드: 데이터 수집 후 스토리지를 거치지 않고 바로 처리 계층으로 전송
1.6.4 서비스 계층
- 사용자나 다른 시스템에서 데이터를 활용할 수 있도록 준비하는 역할
- 사용자들은 다른 기술 배경을 갖고 있기에 데이터를 액세스하고 분석하는데 사용하는 툴의 선호도가 다양함
- 비즈니스 부서 > 셀프 서비스 방식으로 다양한 보고와 대시보드
- 데이터 분석가 > SQL 쿼리로 즉각 응답 받기 원함
- 데이터 사이언티스트나 개발자 > 익숙한 프로그래밍 언어로 머신러닝 모델 구축이나 새로운 데이터 변환
- 데이터 레이크 데이터를 키/밸류 저장소나 문서 저장소에 저장 후 애플리케이션에서 바라보게 하는 식으로 제공
- 스파크, 빔, 플링크 같은 프레임워크로 클라우드 스토리지에 있는 데이터에 직접 접속해 작업
- 일부 업체는 주피터 노트북 같은 관리형 노트북 환경 제공
- 클라우드 장점은 위와 같은 기술들을 Paas로 제공
요약
기존 데이터 웨어하우스는 데이터의 다양성, 규모, 속도 측면에서 한계를 드러냈고, 이를 보완하기 위해 데이터 레이크와 클라우드 기반 데이터 플랫폼이 등장했다. 클라우드 데이터 플랫폼은 수집, 저장, 처리, 서비스 계층으로 구성되어 다양한 형태의 데이터를 유연하게 다루며, 확장성과 비용 효율성을 동시에 제공한다. 결과적으로 데이터 웨어하우스와 데이터 레이크의 장점을 결합한 클라우드 데이터 플랫폼이 현대 데이터 아키텍처의 핵심이 되고 있다.
'책 & 스터디' 카테고리의 다른 글
[자바/스프링 개발자를 위한 실용주의 프로그래밍] - 1부 객체 지향(2) SOLID (0) | 2024.11.04 |
---|---|
[자바/스프링 개발자를 위한 실용주의 프로그래밍] - 1부 객체 지향(1) (1) | 2024.10.29 |
도메인 주도 설계 첫걸음 Part 2. 전술적 설계 5장, 6장 (2) | 2024.09.03 |
도메인 주도 설계 첫걸음 Part 1. 전략적 설계 (0) | 2024.08.26 |
object 스터디를 마치며.. (1) | 2024.05.31 |