# 퍼블릭 클라우드 활용
퍼블릭 클라우드는 온디맨드, 온디맨드+프로비저닝, 사용량 기반의 요금 지불 모델을 모두 지원한다. 이 퍼블릭 클라우드로 하둡의 한계를 뛰어넘는 데이터 레이크 설계가 가능하게 됐다. 이를 통해 데이터 레이크의 유연성과 확장성을 높일 수 있는 설계가 가능하고, 필요한 자원도 크게 줄일 수 있어서 비용 효과적이다.
# 퍼블릭 클라우드의 장점
1. 언제나 리소스를 추가/축소 가능하다
2. 데이터 웨어하우스와 다르게 스토리지와 컴퓨팅을 각각 증설할 수 있게 되었다.
3. 사용량에 따라 비용 지불할 수 있다
4. 자본 투자/예산/상각 방식에서 운영 비용 방식으로의 전환
5. 시스템의 운영, 지원 및 업데이트를 클라우드 서비스에서 제공한다
6. 즉시 사용 가능
최근들어 수행 성능을 높여야 하는 분석 과업들이 데이터 레이크 형태로 구성되는 경우를 보는데, 이는 비용 측면에서 데이터 레이크가 데이터 웨어하우스보다 우수하고, 기존 데이터 웨어하우스 방식이 배치 처리 방식이었다면, 데이터 레이크를 활용할 경우 스트리밍과 같은 새로운 방식의 데이터 처리가 가능하기 때문이다.
데이터 레이크와 데이터 웨어하우스의 경계 구분이 지속적으로 흐려져가고는 있지만, 차세대 분석 플랫폼 설계 시 각기 다른 역할을 하는 것으로 정의된다. 모든 데이터에 즉시 액세스하려는 사용자들의 요구사항을 충족시키고자 할 경우에는 데이터 레이크를 활용하고, 적절하게 관리되며 정제된 데이터를 필요로 하는 요구사항에서는 데이터 웨어하우스를 활용하는 방식으로 둘 간의 역할 관점의 균형을 유지할 수 있다.
# 클라우드 데이터 플랫폼의 빌딩 블록
- 데이터 플랫폼의 목적 : 분석에 활용될 수 있는 어떤 유형의 데이터든 최대한 비용 효과적인 방식으로 데이터를 수집, 저장, 처리해서 활용할 수 있도록 제공하는 것
위 목적을 위해 플랫폼은 계층간 느슨하게 결합돼 있는 형태의 아키텍처를 지향하며, 각 계층은 각각의 특정 역할을 담당하고, 잘 정의된 API를 통해 각 계층 간 상호교류한다.
- 데이터 플랫폼 아키텍처의 구성 : 수집 + 스토리지 + 처리 + 서비스 -> 클라우드 데이터 웨어하우스 / APIs / 데이터 내보내기
## 수집
이 계층은 유연성이 높아야 한다. 따라서 수집 계층을 구성할 때는 특정 데이터 유형을 처리할 수 있는 오픈소 소스 툴이나 상용 툴을 사용해 구현하는 경우가 많다. 이 계층에서는 어떤 경우에도 수집되는 데이터를 수정하거나 변환해서는 안된다. 데이터 레이크에 처리되지 않은 원시 데이터를 보관해서 추적 및 재처리를 할 수 있도록 하기 위함이다.
## 스토리지
데이터 센터 환경에서 스토리지를 확장하려면 주로 대용량 디스크 어케리나 네트워크 연결 스토리지NAS를 사용해야 했다. 하지만 대개 비용이 비싸고, 또 정해진 용량 단위로 거래가 되었다.
그래서 클라우드 공급 업체의 최초 서비스 중 하나가 스토리지 서비스였다는 것은 그리 놀랍지 않다. NAS 또는 하둡DFS는 클라우드 스토리지와 아래와 같은 차이점이 있다.
1. 관련 관리형 서비스 : 유지보수, 소프트웨어/하으뒈어 업그레이드 등에 대해 고민할 필요가 없다
2. 탄력성이 높다. 언제든지 스토리지 볼륨을 늘리거나 줄일 수 있다
3. 사용량에 따라 지불한다
4. 스토리지와 직접적으로 연결된 커뮤팅 리소스가 없다. 그래서 데이터 저장 공간을 확보하기 위해 불필요한 컴퓨팅 자원을 구매하지 않아도 된다.
## 처리 계층
원시 데이터를 직접 분석하는 방식으로 데이터 레이크를 설계할 수도 있겠지만, 생산성이나 효율성 측면에서 볼 때 최상의 선택은 아니다. 데이터 레이크 구축 시, 데이터 과학자 같은 전문 분석가들이 좀 더 사용하기 쉽게 원시 데이터를 어느 정도 미리 변환해두는 것이 일반적이다.
데이터 웨어하우스를 구축할 때 대체적으로 데이터 베이스 공급 업체에서 제공하는 SQL 엔진에 국한된다. 클라우드 데이터 레이크에서는 처리 계층 구현을 위해 선택할 수 있는 몇 가지 기술과 프레임워크가 있다.
1. 아파치 스파크
2. 아파치 빔
3. 아파치 플링크
위 솔루션들은 현대 프로그래밍 언어를 사용해서 데이터 변환, 유효성 검사, 정체 작업을 흐름 수준으로 쉽게 프로그래밍 할 수 있도록 지원한다. 이 프레임워크를 통해 클라우드 스토리지로부터 데이터를 읽고, 더 작은 청크로 분할한 후, 마지막을 ㅗ유연한 클라우드 컴퓨팅 리소스들을 사용해서 이 데이털 청크를 처리한다.
1. 수집
- 배치 모드에서는 데이터라 먼저 스토리지에 저장된 다음 처리된다.
- 스트리밍 모드에서는 데이터 수집 후 스토리지 계층을 거치지 않고 처리 계층으로 바로 전송된다.
2. 스토리지 : 데이터 과학자의 활용 및 분석
3. 처리 :
4. 서비스
5. 클라우드 데이터 웨어하우스 / APIs / 데이터 export
클라우드 스토리지는 저렴하며 확장성이 뛰어나지만, 처리 속도 측면에서는 그렇게 빠르지 않다. 규모가 어느 정도 되는 데이터라면 읽고 쓰는 데에만 몇 분이 걸릴 수 있다. 근래에 들어서 처리 시간 요구사항이 초 단위 이하가 되는 사례가 점점 더 많아졌다. 이 경우 주로 스트림 기반 데이터 처리로 해결한다.
# 서비스 계층
서비스 계층의 목표는 사용자나 다른 시스템에서 데이터를 활용할 수 있도록 준비하는 것이다.
- 비즈니스 부서의 사용자들은 셀프 서비스 방식으로 그들이 원하는 다양한 보고서와 대시보드를 활용하기를 원한다.
- 파워 유저와 데이터 분석가는 SQL 쿼리를 바로 만들어 직접 실행해서 몇 초 안에 즉각 응답받기를 원한다.
- 데이터 과학자와 개발자는 익숙한 프로그래밍 언어를 사요해서 새로운 데이터 변환이나 머신러닝 구축 또는 다른 팀과의 공유를 원한다.
즉, 다양한 작업 유형에 맞는 전문화된 기술을 제공해야 한다. 클라우드 환경에서는 다양한 요구사항을 아키텍쳐 내에서 구성할 수 있다. 예를 들면, SQL 엑세스를 높이기 위해 데이터 레이크의 데이터를 클라우드 데이터 웨어하우스에 적재할 수 있다.
애플리케이션에서 데이터 레이크의 데이터를 액세스하게 하려면, 먼저 데이터 레이크의 데이터를 키/밸류 저장소나 문서 저장소에 적재하고, 애플리케이션이 그 쪽을 바라보게 한다.
# 클라우드 데이터 플렛폼이 세 가지 V를 다루는 방법
## 다양성
- 수집 계층 : 다양한 소스를 플러그 앤 플레이 방식으로 지원
- 스토리지 계층 : 클라우드 스토리지에는 어떤 형태의 데이터도 저장할 수 있음
## 규모
- 클라우드 스토리지는 자주 사용할 용도, 장기 보관 용도 등 사용 빈도와 제공 용량별로 다양한 스토리지 옵션을 제공하고 있다. 사용자가 필요한 용량과 용도에 맞게 스토리지 옵션을 선택하고 해당 스토리지의 사용 비용만 지불 할 수 있다.
## 속도
클라우드 환경에서는 실시간 워크로드와 배치 워크로드를 굳이 공유할 필요가 없다. 컴퓨팅 리소스를 탄력적으로 운용하기 위함이다. 유스 케이스에 따라 전용 처리 클러스터를 구성할 수도 있고, 필요한 경우 개별 작업별로 클러스터 구성도 가능하다.
처리 계층에서는 처리를 완료한 데이터를 데이터의 목적과 용도에 맞게 다르게 보관할 수 있다. 애플리케이션에서 사용하기 위한 목적이라면 키/밸류 저장소로, 아카이브가 목적이면 클라우드 스토리지로, 리포팅이나 애드혹 분석 목적이라면 클라우드 웨어하우스로 보낼 수 있다.
'DEV > Data Platform' 카테고리의 다른 글
데이터 플랫폼 설계와 구축 | 1장 데이터 플랫폼 소개 (0) | 2024.03.30 |
---|---|
데이터 플랫폼 설계와 구축 | 03. 빅3의 활용과 확대 | 수집, 저장, 처리, 메타데이터 계층 설계시 고려사항 (1) | 2023.11.06 |
데이터 플랫폼 설계와 구축 | 02. 데이터 웨어하우스만이 아닌 데이터 플랫폼인 이유 | 데이터 플랫폼에서의 데이터 수집,처리,엑세스 방식 (1) | 2023.11.04 |
데이터 플랫폼 설계와 구축 | 02. 데이터 웨어하우스만이 아닌 데이터 플랫폼인 이유 | 데이터 웨어하우스와 데이터 플랫폼의 차이 (1) | 2023.11.01 |
데이터 플랫폼 설계와 구축 | 01. 데이터 플랫폼 소개 | 데이터 웨어하우스부터 하둡 전성기까지의 흐름 (0) | 2023.10.30 |