메뉴

문서정보

목차

AWS Enterprise data warehousing on aws 의 요약문서다. 개인 학습을 목적으로 요약했다.

문서 요약

서론

모든 대기업은 자체 트랜잭션 시스템 및 데이터베이스를 비롯한 다양한 소스로부터 데이터를 수집하고 이를 분석하기 위한 용도로 데이터웨어하우스를 구축하고 있다. 이러한 시스템을 구성하기 위해서 대기업의 아래의 것들을 준비해야 한다.
  1. 소프트웨어와 하드웨어에 수십억원의 비용이 들어간다.
  2. 계획의 수립, 조달, 구축과 배포에 수개월의 시간이 걸린다.
  3. 데이터베이스 관리자 팀을 만들어야 한다.
이렇게 해서 데이터웨어하우스를 구축하더라도, 기존의 DW는 아래의 운영상의 문제점을 가지고 있다.
  1. 확장이 어렵다.
  2. SLA를 준수하기 위해서 데이터 증가, 쿼리 추가가 자제될 수 있다. 해결하기가 쉽지 않다.
Amazon Redshift를 이용해서 기능과 성능을 희생하지 않으면서 데이터웨어하우스 시스템을 구성할 수 있다.
  1. 기존의 BI 도구를 사용해서 대량의 데이터를 합리적인 비용으로 분석 할 수 있다.
  2. 1/10의 비용으로 대량 병렬 처리(MPP)를 수행 할 수 있다.
  3. 0.25 시작 1.,000의 규모로 자유롭게 확장 할 수 있다.
NTT DOCOMO, FINRA, Johnson & Johnson, Hearst, Amgen, NASDAQ 등이 사용하고 있다.

최신 분석 및 데이터 웨어하우징 아키텍처

데이터 웨어하우스는 하나 또는 여러 데이터 소스로 부터의 정보를 보관하는 중앙저장소다.

 DW

데이터 소스는 정형(Structured), 반정형(Semi-Structured), 비정형(Unstructured)등 다양한 구조를 가질 수 있다. 이 데이터는 ETL에서 처리/변환의 과정을 거쳐서 수집된다. 데이터 사이언티스트, 비지니스 분석가들은 BI 도구, SQL 클라이언트, 스프레드쉬트를 통해 데이터를 사용 할 수 있다.

데이터웨어 하우스를 구축하는 이유

트랜잭션이 기록되는 OLTP(Online transaction processing)에서 직접 쿼리를 실행하지 않고, 비용을 들여서 데이터웨어 하우스를 구축하는 이유에 대해서 살펴보자. OLTP와 DW를 비교하면 도움이 될 것이다.
OLTP DW
읽기/쓰기 타입 지속적인 쓰기, 많은 양의 소규모 데이터 읽기 일괄 쓰기, 대량의 데이터 읽기
스키마 높은 데이터 처리량읠 위한 Star, Snowflak와 같은 비정형 스키마 높은 트랜잭션 처리를 위한 고도로 정형화된 스키마
OLTP로 부터, DW의 요구사항인 일괄쓰기, 대량의 데이터 읽기를 할 경우 실제 서비스의 성능에 영향을 주게 된다. 목적이 다르므로 다른 툴/방법을 사용해야 한다. 따라서 DW를 이용하기위해서는 OLTP나 다른 데이터 소스를 DW요구사항에 맞춰서 변환하는 데이터 파이프라인을 구축해야 한다.

분석 아키텍처

분석 파이프라인은 데이터베이스, 애플리케이션, 디바이스 등과 같이 다양한 소스로 부터 유입되는 많은 양의 데이터 흐름을 처리하도록 설계된다. 분석 파이프라인은 아래의 단계를 가진다.
  1. 데이터 수집
  2. 데이터 저장
  3. 데이터 처리
  4. 데이터 분석 및 시각화
 분석 파이프라인

데이터 수집

트랜잭션 데이터, 로그데이터, 스트리밍 데이터, IoT 데이터등과 같은 다양한 유형의 데이터를 수집한다.

트랜잭션 데이터 로그 데이터 스트리밍 데이터 IoT 데이터

데이터 처리

수집된 데이터의 처리 과정이다. 이 처리 과정을 통해서 비지니스에 도움이 될만한 정보를 얻을 수 있다. 여기에는 배치(Batch)와 실시간 두 가지 유형의 워크플로우를 사용 할 수 있다. 배치처리에 포함되는 프로세서들은 아래와 같다.

ETL(Extract Transform Load)
ETL은 여러 소스로 부터 데이터를 가져와서 데이터웨어 하우징 시스템에 로드하는 프로세스다. 하나 이상의 소스로 부터 데이터가 추출되고, 추출된 데이터는 목적에 맞게 정리/변형한 다음 데이터웨어 하우징 시스템에 로드된다. 대량의 데이터에 대한 변형을 수행해야 하는데 Apache Pig, Apache Hive와 같은 하둡 프레임워크를 일반적으로 사용한다.

ELT(Extract Load Transform)
ELT는 ETL의 변형이다. 여러 소스로 부터 데이터를 가져와서 먼저 데이터웨어 하우징 시스템에 로드한다. 변형은 데이터웨어 하우스에 로드된 데이터에 대해서 수행한다. ELT는 일반적으로 데이터 시스템이 대량의 데이터의 변형에 충분한 성능을 가지고 있을 때 사용한다. Amazon Redshift는 변형 수행에 뛰어나기 때문에 ELT 파이프라인에 종종사용한다.

OLAP
OLAP(Onlin analytical processing)는 의사 결정 지원 시스템을 지원한다. 취합된 데이터를 사용자가 여러 기준에서 다양한 방법으로 바라보면서 다차원 데이터 분석을 할 수 있도록 지원한다. OLAP는 광범위한 BI(Business intelligence)의 한부분으로 관계형 데이터베이스, 리포팅 시스템, 데이터마이닝등도 포함한다. OLAP는 fast join에 최적화되기 때문에 Amazon Redshift를 OLAP 시스템 개발에 종종 사용한다.

 AWS Redshift

실시간처리 : Amazon Kinesis를 이용한 실시간 OLAP 시스템을 구성할 수 있다. Kinesis에 퍼블리싱되는 스트리밍 데이터를 연속적으로 처리한 후, 처리한 데이터의 상관관계 분석, 취합, 필터링, 샘플링등의 다양한 방법으로 분석 할 수 있다. 데이터가 퍼블리싱되는 시점에서 처리 되기 때문에 실시간 처리라고 한다. Kinesis는 애플리케이션 로그, 웹 사이트 클릭, 디바이스 액션, 위치정보에 대한 데이터 변화에 신속하게 대응 할 수 있다. Kinesis Data firehose를 이용해서 이들 데이터를 변환한 후 S3에 저장하고 배치 작업을 통해서 Redshift 로드 할 수 있다.

데이터 스토리지

데이터는 데이터 웨어하우스나 데이터 마트에 저장 할 수 있다. 데이터 웨어하우스와 데이터 마트에 대해서는 아래 글을 참고하자. 간단히 정리하자면 아래와 같다.

데이터 웨어하우스는 하나 이상의 데이터소스로 부터 정보를 보관하는 중앙 저장소다. 데이터 웨어하우스를 이용해서 대량의 데이터에 대한 빠른 분석을 수행 할 수 있다. 비지니스 부서는 비지니스 인사이트를 얻기 위한 BI(Business Intelligence)의 목적으로 사용 할 수 있으며, 데이터 과학자는 다양한 쿼리를 이용해서 오프라인 분석을 수행 할 수 있다. 기타 다른 여러 조직에서 자신들의 목적에 맞게 SQL 쿼리, 정기적인 보고서 등을 만들어서 의사결정에 사용 할 수 있다.

데이터 마트는 데이터 웨어하우스의 하위 요소다. 데이터 웨어하우스가 전사적인 데이터를 다룬다면, 데이터 마트는 특정 목적을 효율적으로 다루기 위해서 사용한다. 예를 들어서 각 부서 단위로 데이터 마트를둬서 조직이 원하는 요구를 효과적으로 처리 하는 시스템을 만들 수 있다. 데이터 마트는 데이터 웨어하우스와 운영 스토어로부터 구축 할 수 있다. 데이터웨어 하우스에 비해서 간단하게 구축하고 운영 할 수 있다.

Amazon Redshift를 이용해서 데이터 웨어하우스와 데이터 마트를 구축 할 수 있다.

분석과 시각화

Amazon Redshift를 이용해서 구성한 데이터 웨어하우스와 데이터 마트는 ANSI SQL을 통해서 분석 할 수 있다. 또한 Spotfire와 Tableau 와 같은 전문 BI 툴을 Redshift에 연동해서 분석 할 수 있다.

Amazon QuickSight는 AWS에서 제공하는 BI 서비스다. Spotfire와 Tableau와 같은 전문적인 툴에 비해서 기능은 떨어질 수 있겠으나 간편하고 빠르고 저렴하게 사용 할 수 있다. Amazon S3를 기본 스토리지로 사용하고 있다면 Amazon EMR과 Apache Spark 노트북을 실행 할 수 있다. Apache Zeppelin과 같은 오픈소스 BI 솔류션을 사용 할 수도 있다.

AWS에서의 분석 파이프라인

AWS는 데이터 수집,처리,분석을 위한 모든 솔류션을 제공한다. 아래 그림은 각 단계에서 사용 할 수 있는 AWS 솔류션들을 보여주고 있다.

 AWS 데이터파이프라인 패턴

데이터 웨어하우스 기술 옵션

데이터 웨어하우스 3가지 구축 아키텍처인 행 기반 데이터베이스, 열 기반 데이터베이스, 대량 병렬 처리(MPP)아키텍처에 대해서 살펴본다.

행 기반 데이터베이스

데이터 행을 저장하는데 최적화 된 데이터베이스다. Oracle Database, Mysql, PostgreSQL, Microsoft SQL Server와 같은 관계형 데이터베이스들이 대표적인 행 기반 데이터베이스다. 이러한 시스템은 분석용 보다는 트랜잭선처리(OLTP)에 더 적합하다.

데이터 웨어하우스로 사용 될 경우 구체화된 뷰 생성, 사전에 집계된 롤업 테이블 생성, 다양한 조합의 인덱스 생성, 파티셔닝 등의 최적화를 통해서 인덱스 기반의 조인을 수행 하는 등 다양한 기법을 사용 한다.

행 기반 데이터베이스는 scale-out이 쉽지 않기 때문에 한 대의 머신에서 사용 가능한 리소스에 따라서 규모가 제한 받는다. 이 문제는 데이터 마트로 어느 정도 완화 할 수 있다. 어느 정도 완화라는 것에 주의하자. 데이터 마트가 커지면 결국 데이터 처리 속도가 느려진다.

행 기반 데이터 웨어하우스는 쿼리에 선택하지 않았다고 하더라도 해당 행의 모든 열을 읽어야 한다. 이는 데이터 열이 많을 경우 데이터 웨어하우스의 성능에 병목을 발생시킬 수 있다.

열 기반 데이터베이스

관계형 데이터베이스가 행을 저장하는데 최적화된 반면, 열 기반 데이터베이스(Columnar Database)는 데이터 열을 빠르게 검색하는 데 최적화된다. 보통 분석이 열 단위로 이루어지기 때문에 데이터 분석에 사용 할 경우 효율이 좋다.

아래 그림은 열 기반 데이터베이스와 행 기반 데이터베이스의 데이터 검색 방법을 묘사하고 있다.

행 기반 데이터베이스

 행 기반 데이터베이스

OLTP에서 발생하는 대부분의 트랜잭션에서는 전체 레코드에 대한 모든 값에 대한 읽기와 쓰기가 수행된다. 온라인 가입 프로세스를 위한 개인정보 입력을 개인정보 업데이트를 생각해보면 된다. 이런 작업 처리에는 행 기반 데이터베이스가 유리할 것이다.

열 기반 데이터베이스

 열 기반 데이터베이스

열 기반 데이터베이스는 데이터 블록에 각 여러 행의 단일 컬럼의 값을 연속된 데이터블록으로 저장한다. 열 기반 스토리지는 행 기반 스토리지 보다 데이터에 대한 압축률이 좋다. 따라서 동일한 수의 열을 읽을 경우 행 단위 스토리지에 비교해서 1/3 정도의 디스크 I/O 조작으로 충분하다. 일반적인 데이터베이스 블록 크기는 2KB에서 32KB 정도다. Amazon Redshift는 1MB의 블록크기를 사용해서 보다 효율적으로 쿼리를 수행 할 수 있다.

대표적인 열 기반 데이터베이스로 Amazon Redshift, Vertica, Teradata Aster, Druid 등이 있다.

MPP 아키텍처

MPP(Massively parallel processor)는 많은 수의 프로세스를 사용해서 일련의 (거대한)계산을 병렬로 수행해서 빠르게 처리하려는 컴퓨팅 기법이다.

그리드 컴퓨팅 이나 컴퓨터 클러스터가 MPP를 위한 접근 방법이다. 컴퓨터 클러스터가 근거리의 컴퓨터를 하나로 묶는 방법이라면 그리드 컴퓨터는 원거리의 이기종 컴퓨터를 묶는 방법이다. 묶는 방법에 차이가 있을 뿐 원리는 같다. MPP는 또한 수백 혹은 수천개의 CPU와 RAM 뱅크로 구성된 집적회로의 유형인 MPPA(massively parallel processor arrays) 에도 적용된다.

처리해야 하는 데이터의 양이 늘어남에 따라 Druid, Vertica, GreenPlum, Terradata Aster, Amazon Redshift 같은 데이터 웨어하우스 소프트웨어들은 MPP를 아키텍처를 기반으로 하고 있다. 하둡이나 Spark 같은 오픈 소스 프레임워크 역시 MPP를 지원한다.

Amazon Redshift

Amazon Redshift는 열 기반 데이터베이스 시스템으로 MPP 아키텍처를 기반으로 한다. 열 기반 데이터베이스의 특징인 높은 압축 효율, 효율적인 I/O, 스토리지의 효과적인 사용등 의 이점을 제공한다. ANSI SQL을 기반으로 하기 때문에 기존의 SQL 자산을 거의 수정 없이 사용 할 수 있는 것도 큰 장점이다. Amazon Redshift는 고객이 데이터 처리 환경을 구성 할 필요가 없다. 데이터 처리 환경을 구성하기 위해서는 대량의 컴퓨터 자원의 프로비저닝, 소프트웨어 설치/구성/관리, 모니터링, 백업, 보안과 같은 복잡한 업무를 수행해야 한다. 이러한 작업은 몇 주에서 몇 달이 걸릴 수 있는데, Amazon Redshift를 이용하면 몇 분만에 사용 할 수 있다.

성능

Amazon Redshift는 컬럼 방식 스토리지와 데이터 압축 및 zone map(영역 지도)를 이용해서 쿼리를 실행하는데 필요한 I/O를 줄인다. 인터리브 정렬 기능은 인덱스나 프로젝션 관리에 따른 부담 없이 성능을 향상시킨다.

인터리브(Interleaved)정렬 키는 z order curve를 응용한 데이터 정렬방식이다. z order curve는 공간(spatial) 정보를 인덱싱하기 위해서 사용한다. 공간은 하나의 구역이 여러 개의 하위 구역을 포함 할 수 있는 구조를 가진다. 이러한 요구사항을 해결하기 위해서 R-tree를 사용하는데, Z order curve를 이용하면 R-tree의 문제점들을 해결하면서 더 하위 구역(데이터)를 더 빠르게 색인하고 검색 할 수 있다. Amazon Redshift에서의 Interleave 정렬키에 대한 자세한 내용은 Interleaved Sort Keys in Amazon Redshift, Part1, Redshift - 정렬 키 선택, AMAZON Redshift. 정렬 키의 이해 문서를 읽어보자.

Amazon Redshift는 MPP 아키텍처를 사용해서 SQL 작업을 병렬로 처리 할 수 있다. Redshift의 기반 하드웨어는 CPU와 드라이브간의 처리량을 최대화 하기 위한 로컬 연결 스토리지, 높은 처리량을 위한 10GibE 메시 네트워크로 구축된다. 사용자는 데이터 웨어하우징 요구사항에 따라서 SSD 기반의 DC(Dense Compute), DS(Dense Storage)옵션을 선택 할 수도 있다.

로컬 연결 스토리지는 호스트에 직접 연결된 디스크 혹은 SAS나 SATA 등의 프로토콜을 통해 호스트에 직접 연결되는 스토리지다. 네트워크 연결 스토리지에 비해서 유연성은 떨어지지만 상대적으로 높은 성능을 달성 할 수 있다. 메시 네트워크(Mesh network)는 네트워크를 구성하는 각각의 노드가 네트워크에 대해서 데이터를 릴레이하는 네트워크토폴로지다. 네트워 내의 모든 노드가 데이터분산에 사용되기 때문에 효과적인 망 구성이 가능하다.

지속성과 가용성

AWS의 다른 관리형 서비스와 마찬가지로 장애, 복구, 프로비저닝 같은 작업을 대신해 준다. Amazon Redshift 클러스터는 한 개의 가용 영역에 전개되지만 복제와 장애조치에 대한 약간의? 관리비용을 추가하는 선에서 다중 가용 영역을 설정 할 수 있다. 또한 Amazon Console에서 간단하게 DR(Diasater recovery) 환경을 구축 할 수 있다. 하나의 리전에서 서비스 중단이 발생하면 다른 AWS 리전에서 백업 클러스터를 복구 할 수 있다. 이러한 과정은 수분안에 끝난다.

확장성과 탄력성

AWS의 가장 큰 장점은 워크로드에 맞는 유연한 환경을 구축할 수 있다는 점이다. Redshift는 160GB 노드에서 페타바이트단위의 규모로까지 확장 할 수 있다.

인터페이스

JDBC(Java Database Connectivity), ODBC(Open Database Connectivity) 드라이버를 이용해서 애플리케이션을 개발 할 수 있다. Amazon Redshift 드라이버에 대한 자세한 내용은 Amazon Redshift and PostgreSQL 문서를 읽어보자. 3줄 요약. AWS 파트너 네트워크에서 Reidshift와 통합되는 BI, ETL 공급업체를 찾을 수 있다.

아래 구성도는 Firehose와 Redshift의 통합을 묘사하고 있다.

 Firehose Redshift

사용자는 Amazon CloudWatch API를 이용해서 Redshift 데이터 웨어하우스 클러스터에 대한 컴퓨팅 사용량, 메모리 사용률, 스토리지 사용율, 읽기/쓰기 트래픽을 모니터링 할 수 있다.

적당한 사용 패턴

비적합 사용 패턴

Amazon Redshift로의 마이그레이션

기존 데이터 웨어하우스를 Amazon Redshift로 마이그레이션 고민해야 할 내용들이다.

데이터베이스 마이그레이션 도구들

AWS DMS(AWS database migration service) : AWS DMS는 데이터베이스를 AWS로 마이그레이션 할 수 있도록 도와주는 툴이다. 오라클, Mysql, Postgresql 과 같은 상용 및 오픈소스 데이터베이스를 AWS의 여러 서비스로 마이그레이션 할 수 있다. 마이그레이션 할 수 있는 데이터베이스 목록이다. 이들 데이터베이스는 아래의 AWS 서비스로 마이그레이션 할 수 있다.

데이터 웨어하우징 워크플로 설계

엔터프라이즈 데이터 웨어하우스의 일반적인(가장 단순한)워크플로다.

 엔터프라이즈 데이터 웨어하우스 워크플로

  1. 여러 소스의 데이터를 Amazon S3로 모은다. 거의 무한대의 공간을 제공하며, 매우 저렴하기 때문에 Amazon은 데이터 수집을 위한 가장 좋은 서비스 중 하나다. 2019년 11월 현재 S3 standard 스토리지의 가격은 0.025 USD/GB 다.
  2. S3에 저장된 소스 데이터는 대부분의 경우 그대로 사용 할 수 없다. 처리하기 좋은 방식으로 데이터를 변형해야 한다. AWS EMR은 S3에 있는 데이터에 직접 엑세스 할 수 있다. 사용자는 EMR을 이용해서 대량의 데이터를 처리 할 수 있는 데이터로 변형 할 수 있다. 보통 이런 데이터는 주기적으로(보통 새벽시간) 올라오기 마련이니, 스팟 인스턴스를 잘 쓴다면 저렴한 가격으로 변환 작업을 수행 할 수 있다.
  3. 이렇게 변형된 데이터는 S3에 저장된다. S3에 저장하는 이유는 AWS의 서비스들 대부분이 S3를 기본 데이터 저장소로 사용하기 때문이다. EMR은 물론이고, RDS, Redshift도 S3로 부터 데이터를 로드 할 수 있다. S3는 데이터 웨어하우징을 위한 Sourct of Truth를 제공한다. 즉 99.9999999%의 내구성, 99.99%의 가용성, (거의)무한한 스토리지, 버전관리, 데이터 복구, 유비쿼터스 액세스를 지원한다.
  4. Redshift에 데이터가 로드되고 분석 작업을 수행한다. 데이터가 늘어남에 따라 노드를 추가하고 쉽게 용량을 늘릴 수 있다.
  5. Amazon QuickSight, ODBC, JDBC를 Redshift에 연결해서 시각화 할 수 있다. 이들 시각화 툴을 이용해서 CEO와 경영진에게 필요한 정보를 담고 있는 보고서, 차트, 대시보드를 개발 할 수 있다.
Aurora에 빌리언 데이터 밀어넣기 문서를 읽어보자. Redshift 대신 RDS가 사용된 것을 제외하고는 동일한 워크플로를 가지고 있다.

용어