SlideShare una empresa de Scribd logo
1 de 46
Descargar para leer sin conexión
Cloud DW 트렌드 및 성능 비교
( Snowflake vs AWS Redshift vs AWS EMR )
Performance & Cost Test
2021.07
freepsw
2
왜 기업들은 Cloud DW에 주목하는가?
Cloud DW 솔루션의 성능은?
기존 Data Lake(EMR) 대비 성능은?
유사 Cloud DW(snowflake vs redshift) 대비 성능은?
시장에는 어떤 제품들이 있는가?
우리 Biz 환경에서는 어떤 제품을 도입해야 하는가?
3
Cloud DW ?
왜 많은 기업들에게 주목 받고 있을까?
4
왜 기업들은 Cloud DW에 주목할까?
정부 정책 변화
데이터 3법 (2020.01 시행)
빅데이터 센터 (16개소)
AI/Data 산업 활성화
데이터 개방은 가속화되며, 기업은 더 많은 데이터를 분석하고자 함
더 많은 데이터를
기업의 데이터 이슈
Data Silo 현상
기존 DW의 한계
운영/투자 비용 증가
통합 관리할 수 있는
Data 아키텍처 진화
ETL à ELT 로 진화
Cloud DW 등장
Data Mesh 아키텍처
데이터 기술 필요
5
기업의 데이터 이슈 – Data Silo
Data Lake 도입에도 Data Silo 발생 è 데이터 적시 활용 어려움
Data Silos
발생
DW Silo Hadoop Silo
과도한 ETL
작업 실행
(ETL 제품 종속)
동적인 컴퓨팅 자원
할당 어려움
(수많은 배치 스케줄)
분석가가 원하는
데이터를 적시에
확보하기 어려움
또 다른
Data Silo 발생
또 다른
Data Silo 발생
ETL을 통해 생성된
Data Silo 발생
https://databricks.com/glossary/data-lakehouse
6
Data 아키텍처의 변화 – ELT
분석가가 필요한 데이터를 원하는 방식으로 변환 및 조회 가능한 ELT 도입 증가
https://blog.naver.com/freepsw/222276087707
7
Cloud DW & Lakehouse 제품 등장
모든 데이터를 저장하고, 목적에 따라 DW를 구성하여, 최소화된 운영비로 원하는 성능 제공
Data Warehouse
(On-prem)
Data Lake
Cloud DW
Lake House
• 정형 데이터 중심
• 저장 공간 및 컴퓨팅 성능 한계
Cloud 스토리지로 저장용량 한계 극복
필요시 DW 즉시 생성 (처리 성능 개선)
Manage Service로 운영 부담 제거
• 정형 + 반정형 중심
• Snowflake, Redshift, BigQuery 등
• 신규 제품 지속 출시 및 시장 점유율 증가
• 정형 + 반정형 + 비정형 지원
• 정형 데이터에 최적화된 조회 성능 한계
(ETL을 통해 DW로 데이터 적재 후 조회)
• 복잡한 Data Engineering 필요
Cloud 스토리지로 저장용량 한계 극복
필요시 DW 즉시 생성 (처리 성능 개선)
Manage Service로 운영 부담 제거
정형 데이터 중심의
Data Lake 고객의 전환 수요 증가
(EMR à Snowflake/Redshift)
• 정형 + 반정형 + 비정형 지원
• 복잡한 ETL 없이 빠르게 데이터 조회
(Data Silo 제거)
• Delta Lake (Data Bricks)
8
https://interworks.com/blog/sparker/2018/03/08/introducing-snowflake-cloud-based-data-warehousing/
Cloud DW 란?
Cloud의 동적 자원(컴퓨팅 & 스토리지)를 활용하여 사용자에게 동적인 DW환경을 제공
(성능 개선, 운영 부담 감소, 비용 절감 효과)
Snowflake의 서비스 개념
(많은 제품이 유사한 기능 제공)
9
Cloud DW는 구체적으로 어떤 기능을 제공하는가?
Cloud의 장점을 기반으로 DW의 성능/안정성/비용 최적화
Data integration Data storage Performance
Management
Security
&
compliance
- 배치/실시간 등 대용량 데이터 유입 -
- 정형/반정형 데이터 지원 -
- 클라우드 스토리지 장점 활용 -
- 칼럼 기반 스토리지 지원 -
- 스토리지와 컴퓨팅 노드 분리 -
- 동적 scale out 지원 -
- 캐싱/분산(MPP) 처리 지원 -
- 인증/암호화/접근제어 -
- 다양한 법적 규제 지원 -
- 빠른 DW 환경 구성-
- 데이터 백업 및 복구 용이 -
- 운영 비용 감소 -
10
시장에는 어떤 Cloud DW 제품들이 있을까 ?
On-Prem DW
Managed
Cloud DW
Cloud DW
Cloud
Data Lake
Cloud based
Self-DW
Public Cloud
DW
인프라 및 운영 비용 해결 빠른 성능과 운영 복잡성 감소
Cloud 사업자 제공 서비스
• Oracle Exadata
• Teradata
• IBM Netezza,
• Oracle Exadata
• EMC Greenplum Data C
omputing Appliance
• SAP Sybase IQ
• HP Vertica
• AWS EMR
• GCP Dataproc
• Azure HDInsight
• Cloudera CDP
• AWS Redshift
• GCP BigQuery
• Azure Synaps
DW 전문 기업의 Cloud기반 서비스
• Snowflake
• GCP BigQuery omni
• Teradata Vantage
Data Mart
Cloud Infra에 직접 DW 구축
• Vertica
• Greenplum
• IBM DB2
기존 DW/DataMart 영역과 Data Lake영역을 포함하여 시장을 확장 중
Cloud 사업자 종속 Multi-Cloud 지원
Multi-Cloud +
Hybrid Cloud
제품 종속 제거
운영 편의성
DeltaLake
(Databricks)
Snowflake
Firebolt
11
시장에는 어떤 Cloud DW 제품들이 있을까 ?
On-Prem DW
Managed
Cloud DW
Cloud DW
Cloud
Data Lake
Cloud based
Self-DW
Public Cloud
DW
인프라 및 운영 비용 해결 빠른 성능과 운영 복잡성 감소
Cloud 사업자 제공 서비스
• Oracle Exadata
• Teradata
• IBM Netezza,
• Oracle Exadata
• EMC Greenplum Data C
omputing Appliance
• SAP Sybase IQ
• HP Vertica
• AWS EMR
• GCP Dataproc
• Azure HDInsight
• Cloudera CDP
• AWS Redshift
• GCP BigQuery
• Azure Synaps
DW 전문 기업의 Cloud기반 서비스
• Snowflake
• GCP BigQuery omni
• Teradata Vantage
Data Mart
Cloud Infra에 직접 DW 구축
• Vertica
• Greenplum
• IBM DB2
기존 DW/DataMart 영역과 Data Lake영역을 포함하여 시장을 확장 중
Cloud 사업자 종속 Multi-Cloud 지원
Multi-Cloud +
Hybrid Cloud
제품 종속 제거
운영 편의성
Databricks
Snowflake
Firebolt
기업의 상황에 맞는 최적 제품을 찾아야 함.
12
기업 상황에 맞는 Cloud DW는 어떻게 선정해야 할까?
운영 편의성 & 보안 최적의 비용과 성능 보장 다양한 제품과 연동/통합
도입을 원하는 기업의 고민은…..
실제 적용 시 원하는 성능이 나올까?
사전에 검증이 필요하다!
13
Cloud DW의 성능을 어떻게 검증할 것인가?
다양한 기업 환경에 맞는 성능(Benchmark) 결과를 찾기는 어렵다.
14
Cloud DW의 성능을 비교해 보자 !
15
테스트 제약 조건
동일한 조건에서 성능을 비교할 수 있도록 테스트 자원 설정
표준 데이터 사용 성능/비용 측정
동일한 자원 할당
가장 범용적으로 활용하는 TPC-DS 데이터 생성
50G, 200G, 1000G(1TB) 활용
각 제품에 맞게 데이터 적재
Snowflakes는 자원 스펙을 공개하지 않음
따라서,
Snowflake 기준으로 동일한 비용의 자원 할당
(AWS는 Instance 유형 및 노드 개수 조정)
(+- 0.24 $ / Hour 오차 있음)
DW 생성 시간 (얼마나 빨리 DW를 생성하는가?)
처리 성능 (데이터 로딩 시간 + 쿼리 시간)
소요 비용 (DW 생성 후 쿼리 완료까지 소요된 비용)
“ 시간당 동일한 비용의 자원 할당” “ 빅데이터 용 TPC-DS 데이터 활용 ” ” 처리 성능 및 소요 비용 비교 ”
16
상세 테스트 환경 설정
AWS Tokyo Region에서 테스트 수행
구분 설명 고려 사항
테스트 대상
Snowflake
AWS Redshift
AWS EMR - 6.2.0 (Hive)
Redshift ra3 type에 Aqua 적용하지 않음
테스트 데이터 TPC-DS Benchmark 데이터 50G, 200G, 1,000G (1TB) 데이터 사용
데이터 포맷
Snowflake와 Redshift는 자체 최적화 포맷 (csv import)
EMR은 parquet 포맷 사용
Snowflake/Redshift : gzip으로 압축된 csv 파일 로딩
EMR : parquet 포맷으로 변화하여 S3에 저장 (동일 region)
비용 기준
(DW 서버 스펙)
Snowflake (Standard Type, Tokyo region) 비용을 기준 (2021.7월 기준)
(Snowflake는 서버 스펙 공개하지 않음)
X-Small : 2.8$
Medium : 11.4$ (x-small 대비 4 배)
Large : 22.8$ (x-small 대비 8 배)
Query 성능 측정
TPC-DS에서 제공하는 99개 Query 실행
(순차적으로 실행하여 전체 쿼리 실행시간 비교)
소요 비용 측정 Cloud DW 서비스(자원)을 사용한 총 비용
DW 생성 à 데이터 로딩 à 성능 측정 à 종료까지 사용된
총 비용
17
테스트 조건 >> 동일한 자원 할당 ( Snowflake 기준)
Snowflake 기준으로 동일한 시간당 비용의 자원 할당 (AWS Tokyo Region)
- 본 테스트에서는 ”X-Small, Medium, Large” 기준으로 각 제품별 Type 선택 -
Snowflake와 동일한 비용의
AWS Type 으로 선별
18
[백업] Snowflake 자원 할당 기준
Snowflake 기준으로 시간당 비용 기준 설정 (Tokyo Region/Standard 요금제 기준)
- Snowflake의 경우는 인프라 스펙은 공개하지 않으며, 클러스터 사이즈/비용만 공개 -
시간당 2.8$ ~ 최대 364$까지 존재
데이터 량 및 원하는 조회 성능(속도)에 따라
Virtual Warehouse(WH) 선택하여 실행
Snowflake에서 제공하는
Virtual Warehouse유형
수초 이내로 생성됨
19
[백업] AWS Redshift 자원 할당 기준 (Tokyo Region)
2가지 Type(DC2, RA3)으로 진행하며, Snowflake 기준으로 동일한 가격의 자원 할당
- 가장 최신 type은 RA3이며, Aurora 옵션은 미 적용(리소스에 따라 enable이 불가능한 경우가 많음) -
Type이 세분화되어 있지 않아서,
비용 증가 폭이 크다. (약 5배 증가)
(즉, 애매한 용량의 경우 비용 과다 지출 가능)
처리 성능 중심의 Test이므로,
저장공간 중심의 Type인 DS2는 제외
20
[백업] AWS EMR 자원 할당 기준 (Tokyo Region)
EMR은 ec2 Instance를 선택하는 방식이라, 약 150개 유형에서 임의로 선택
21
테스트 조건 >> 테스트 데이터 (TPC-DS)
기존 TPC-H 대비 Data Warehouse 용으로 많이 사용되는 TPC-DS 선택
- 분석가들이 많이 사용하는 복잡한 Ad-hoc/olap query, reporting 등의 다양한 query(99개) 지원 -
TPC-DS Schema [ 데이터 size 별 Table record 건수]
• 정규화된 테이블 구조를 가지며,
• DW에서 많이 사용하는 star schema로 구성되어,
• 기업의 환경과 유사한 테스트가 가능하다.
• 1TB의 경우 최대 2백 80만 건의 record가 생성됨 (store_sales table)
22
테스트 환경 및 구성도
AWS 인프라를 이용하여 Test client와 대상 서비스(snowflake, redshift, emr)를 검증한다.
- EMR을 제외하고, 나머지 DW 제품들은 데이터를 import하면서 자체 최적화된 포맷으로 저장 (성능 향상) -
AWS Tokyo Region (동일 region에서 진행)
Data Generator
(TPC-DS)
1) 데이터 생성 후 S3 Upload
Data Loader
2) S3 Data 적재 (DB 생성 후 Import)
2) Table 생성
Execute Query
3) TPC-DS에서 제공하는 99개 Query 실행 후 성능 기록
( Parquet format )
( 자체 최적 format )
( 자체 최적 format )
( TPC-DS Query : https://github.com/Agirish/tpcds )
23
테스트 케이스 (다양한 관점 별 성능 측정)
Data Size > DW Size > DW Type 별로 구분하여 총 30개의 Test Case 실행
50G는 제품의 다양한 Spec을
추가하여 성능 확인
24
Cloud DW의 성능 테스트 결과는?
25
50G TPC-DS Data 기준
테스트 결과 (50G) – Query 실행 속도 (Snowflake)
모든 가격대(XS, Medium, Large)에서 Snowflake가 가장 빠른 성능을 제공한다.
- Medium 사이즈는 X-Small 대비 약 30% 성능 개선 -
Large Size가
성능 개선 효과가 매우 높음
(X-Small 대비 2배 빠른 성능)
Time
(Minute)
테스트 결과 (50G) – Query 실행 속도 (AWS Redshift)
50G에서는 Instance node 수의 증가가 성능 향상에 영향이 낮음
- 데이터가 많지 않을 경우, 고가의 장비(또는 노드 증가)는 성능에 영향이 낮음 -
Ra3.4xlarge type의
3개 node에서 가장 높은 성능
(X-Small 대비 2배)
Node를 6개로 증가했으나,
쿼리 소요시간은 더 오래 걸림
Time
(Minute)
작은 데이터는 dc2 type이
성능 측면에서 효율적
테스트 결과 (50G) – Query 실행 속도 (AWS EMR)
EMR은 EC2 Instance 스펙 향상이 성능에 영향이 없음 (사용자가 충분히 검증해야 함)
- C5.2xlarge (8core, 16G Mem) à c5n.4xlarge(16core, 42G Mem) à m5.8xlarge(32core, 128G Mem) à m5a.24xlarge( 96core, 384G Mem) -
EC2를 c5 à m5 변경
(node는 5대로 증가)
EC2를 m5.8xlarge à m5a.24xlarge 변경
(node는 4대로 감소)
쿼리 소요시간은 더 오래 걸림
EC2 c5.2xlage à c5n.4xlarge 변경
(node는 2대로 감소)
성능은 유사함
Time
(Minute)
테스트 결과 (50G) – 비용 대비 성능 비교
작은 데이터(50G)에서는 모든 사이즈(X-small, Medium, Large)에서 Snowflake가 가장 효율적
- 또한 비용을 증가(DW 사이즈 향상)했을 때, 성능 개선효과도 가장 높음 -
Snowflake가
비용 대비 가장 효율적
60% 낮은 비용으로,
2배 빠른 성능
Time
(Minute)
Cost
(달러, $)
Snowflake가 Redshift 대비
3배 낮은 비용으로,
3배 빠른 성능
Snowflake가 Redshift 대비
35% 낮은 비용으로,
30% 빠른 성능
30
200G TPC-DS Data 기준
테스트 결과 (200G) – Query 실행 속도 (Snowflake)
Medium과 Large에서 빠른 성능을 제공 (200G 이상은 X-small 사용시 성능 한계)
- Medium 에서 성능 개선 효과가 가장 높음 (3배 빠른 성능 제공) -
Time
(Minute)
Medium 대비 성능 개선 효과가 높지 않음
(약 1.5배 빠른 성능)
성능 개선효과가 가장 높음
(X-Small 대비 3배)
200G에서는 Snowflake X-Small이 Redshift와
유사하거나, 성능이 떨어짐
테스트 결과 (200G) – Query 실행 속도 (AWS Redshift)
X-Small size에서는 Redshift(dc2 type)이 가장 빠른 성능 제공
- 200G는 dc2 type에 노드를 확장하는 것이 효과적으로 보임 -
Time
(Minute)
Ra3.4xlarge로 업그레이드 시
2배 이상 성능 개선
DC2 type 성능이 가장 높음
(Node가 8대라 분산 효과?)
테스트 결과 (200G) – Query 실행 속도 (AWS EMR)
Time
(Minute)
32core, 128G 서버를 5 node로 구성 시
성능개선
EMR은 EC2 Instance 스펙 향상이 성능에 영향이 없음 (사용자가 충분히 검증해야 함)
- C5.2xlarge (8core, 16G Mem) à m5.8xlarge(32core, 128G Mem) à m5a.24xlarge( 96core, 384G Mem) -
고 성능 장비는 오히려 성능 저하
(이 부분은 좀 더 확인 필요)
테스트 결과 (200G) – 비용 대비 성능 비교
200G에서는 X-Small은 Redshift dc2 type이 효율적 (Snowflake X-Small 사이즈 성능부하 발생 )
- Medium 이상의 size에서는 snowflake의 비용 및 성능이 약 30% 뛰어남 -
X-Small 사이즈에서는
Redshift dc2 type이
30% 낮은 비용(2.6$)으로,
13% 빠른 성능
Time
(Minute)
Cost
(달러, $)
Redshift(large) 대비
30% 낮은 비용(6$)으로,
50% 빠른 성능
Redshift 대비
20% 낮은 비용(4.1$)으로,
20% 빠른 성능
35
1TB TPC-DS Data 기준
테스트 결과 (1 TB) – Query 실행 속도 (Snowflake)
1TB 이상은 Large Size 이상의 Virtual Warehouse를 선택해야 빠른 성능 제공 가능
- Snowflake는 데이터 사이즈에 따라서 적합한 Virtual Warehouse 선택 필요 (사용자가 잘 선택할 수 있을까?) -
Time
(Minute)
Medium Size도
1TB에서는
Redshift와 성능 유사
Snowflake X-Small은
1 TB 데이터 처리에
가장 낮은 성능
Large Size 부터
Redshift 대비
빠른 성능 제공
테스트 결과 (1 TB) – Query 실행 속도 (Redshift)
1TB에서는 ra3 type에서 노드를 확장하면 Query 속도가 빠르게 향상됨
- 1TB 에서는 고사양의 장비와 노드를 확장하는 것이 성능 측면에서 효율적 -
Time
(Minute)
성능 개선효과 가장 높음
(약 3배 빠른 성능)
1TB는 X-Small로
처리시 성능 낮음
약 2배 빠른 성능
테스트 결과 (1 TB) – Query 실행 속도 (EMR)
EMR은 데이터가 1TB로 증가하면서 작은 데이터(50G, 200G) 대비 향상된 성능을 제공
- 아주 고사양의 장비 보다는, CPU/Memory 증설과 노드 수를 증가하는 것이 성능에 효과적 -
Time
(Minute)
데이터가 커질수록
성능 차이가
아주 크지 않음
데이터가 커져도
높은 스펙의 인스턴스의 장점이 거의 없음
Medium 사이즈에서
2배 빠른 성능 제공
데이터가 1TB로 증가하면서 Redshift vs Snowflake 성능 & 비용이 거의 유사하게 측정됨
- Snowflake는 데이터 사이즈와 맞지 않는 Virtual Warehouse Size(X-Small)을 선택 시, 비용 증가 & 성능 저하 -
- EMR은 가장 낮은 비용으로 Snowflake보다 빠르게 쿼리 실행 가능 -
X-Small 사이즈에서는 Redshift ra3
type이
Snowflake 대비
15% 낮은 비용(15.1$)으로,
25% 빠른 성능
Time
(Minute)
Cost
(달러, $)
Snowflake와 Redshift의
성능/비용이 거의 유사
Redshift가 Snowflake 대비
5% 낮은 비용(19.4$)으로,
9% 빠른 성능
테스트 결과 (1 TB) – 비용 대비 성능 비교
가장 낮은 비용으로 1TB
처리 가능
40
Cloud DW 성능 테스트 결과를
정리해 보면?
41
전반적으로 Snowflake가 성능 & 비용 측면에서 효율적
Data Size와 Cluster Type에 따라 성능/비용 차이 발생
DW Type
Data Size
사용시 고려사항
50 G 200 G 1000 G (1 TB)
Snowflake
가장 빠른 성능
(X-Small, Medium, Large)
가장 낮은 가격
(X-Small, Medium, Large)
가장 빠른 성능
(Medium, Large)
가장 낮은 가격
(Medium, Large)
가장 빠른 성능
(Large)
가장 낮은 가격
(Large)
• 쿼리할 데이터 사이즈에 따라, 최적의 Cluster Size 존재
• 기업이 보유한 데이터 & 자주 사용하는 SQL을 이용하여, 사전에
용도별 Cluster Size 확인 필요 (비용&성능 최적화)
• 대량의 데이터(1 TB)에 작은 Cluster Size (X-Small)를 할당하면,
최악의 성능과 비용이 나옴
Redshift
가장 빠른 성능
(X-Small, dc2.large_8 node)
가장 낮은 가격
(X-Small, dc2.large_8 node)
가장 빠른 성능
(Medium, ra3.4xplus_3_node)
가장 낮은 가격
(Medium, ra3.4xplus_3_node)
• 200G 이상의 데이터에서 비용 대비 성능이 높아짐.
• Snowflake 대비 선택 가능한 Type이 작음.
• Ra3 type 권장 (ra3.xplus, ra3.4xlarge, ra3.16xlarge)
• 비용이 5배 단위로 증가하여, 세분화된 요금 관리 어려움
EMR (Hive)
가장 느린 성능
가장 비싼 가격
가장 느린 성능
가장 비싼 가격
가장 느린 성능
가장 낮은 가격
(X-Small, c5_2xlarge_5_node)
• 1 TB 이상의 대량 데이터를 느리더라도 안정적으로 실행하는 환
경에 적합
• 기업의 목적(비용, 성능)에 따라 최적의 Instance Type을 직접 찾
아야 함. (시간과 노력 필요)
42
END
43
Backup
(Cloud DW 제품별 성능)
44
제품별 성능 & 비용 비교 (Snowflake)
데이터 사이즈가 클 때,
작은 Cluster 선택하면,
성능 & 비용 모두 최악
데이터 Size 별
성능/비용 비교
DW Size 별
성능/비용 비교
50 G 200 G 1000 G (1 TB)
X-Small Medium Large
50G : X-Small 이 최적
200G : Medium이 최적
1TB : Large가 최적
(데이터 사이즈에 따라,
최적의 Cluster Size 존재)
(비용 증가에 따른 성능
개선 효과 높음)
45
제품별 성능 & 비용 비교 (Redshift)
DW Type 업그레이드에 따라,
일부 성능 개선 효과
데이터 Size 별
성능/비용 비교
DW Size 별
성능/비용 비교
50 G 200 G 1000 G (1 TB)
X-Small Medium Large
데이터가 클 수록 (1TB),
비용을 증가하면,
성능개선 효과가 높음
(데이터가 클수록,
성능 개선효과 높음)
Redshift는 1TB에서
비용 50% 증가로,
6배 빠른 성능 제공
(1 TB에서 비용에 따른
성능 개선효과 높음)
46
제품별 성능 & 비용 비교 (EMR)
200G 이하는
DW Type 변경(비용증가)에 따른
성능 개선효과가 없음
데이터 Size 별
성능/비용 비교
DW Size 별
성능/비용 비교
50 G 200 G 1000 G (1 TB)
X-Small Medium Large
50G/200G 데이터는
비용을 추가(인스턴스 변경)해도,
성능 개선효과 거의 없음
(200G 까지는
성능 개선 효과 낮음)
1TB는
성능은 개선(50%)되었으나,
비용이 7배 증가
(비용 증가에 따른 성능
개선 효과 낮음)
1TB 데이터는
적합한 인스턴스 선택 시,
성능 개선효과 높음

Más contenido relacionado

La actualidad más candente

실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018
실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018
실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018
Amazon Web Services Korea
 

La actualidad más candente (20)

효율적인 빅데이터 분석 및 처리를 위한 Glue, EMR 활용 - 김태현 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019
효율적인 빅데이터 분석 및 처리를 위한 Glue, EMR 활용 - 김태현 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019효율적인 빅데이터 분석 및 처리를 위한 Glue, EMR 활용 - 김태현 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019
효율적인 빅데이터 분석 및 처리를 위한 Glue, EMR 활용 - 김태현 솔루션즈 아키텍트, AWS :: AWS Summit Seoul 2019
 
AWS Aurora 100% 활용하기
AWS Aurora 100% 활용하기AWS Aurora 100% 활용하기
AWS Aurora 100% 활용하기
 
2017 AWS DB Day | Amazon Aurora 자세히 살펴보기
2017 AWS DB Day | Amazon Aurora 자세히 살펴보기2017 AWS DB Day | Amazon Aurora 자세히 살펴보기
2017 AWS DB Day | Amazon Aurora 자세히 살펴보기
 
AWS 활용한 Data Lake 구성하기
AWS 활용한 Data Lake 구성하기AWS 활용한 Data Lake 구성하기
AWS 활용한 Data Lake 구성하기
 
Building a Data Lake on AWS
Building a Data Lake on AWSBuilding a Data Lake on AWS
Building a Data Lake on AWS
 
Amazon Redshift의 이해와 활용 (김용우) - AWS DB Day
Amazon Redshift의 이해와 활용 (김용우) - AWS DB DayAmazon Redshift의 이해와 활용 (김용우) - AWS DB Day
Amazon Redshift의 이해와 활용 (김용우) - AWS DB Day
 
AWS CloudWatch
AWS CloudWatchAWS CloudWatch
AWS CloudWatch
 
Amazon Redshift로 데이터웨어하우스(DW) 구축하기
Amazon Redshift로 데이터웨어하우스(DW) 구축하기Amazon Redshift로 데이터웨어하우스(DW) 구축하기
Amazon Redshift로 데이터웨어하우스(DW) 구축하기
 
Migrating Data and Databases to Azure
Migrating Data and Databases to AzureMigrating Data and Databases to Azure
Migrating Data and Databases to Azure
 
누가 내 엔터프라이즈 고객을 클라우드로 옮겼을까?-양승호, Head of Cloud Modernization,AWS::AWS 마이그레이션 ...
누가 내 엔터프라이즈 고객을 클라우드로 옮겼을까?-양승호, Head of Cloud Modernization,AWS::AWS 마이그레이션 ...누가 내 엔터프라이즈 고객을 클라우드로 옮겼을까?-양승호, Head of Cloud Modernization,AWS::AWS 마이그레이션 ...
누가 내 엔터프라이즈 고객을 클라우드로 옮겼을까?-양승호, Head of Cloud Modernization,AWS::AWS 마이그레이션 ...
 
IDC 서버 몽땅 AWS로 이전하기 위한 5가지 방법 - 윤석찬 (AWS 테크에반젤리스트)
IDC 서버 몽땅 AWS로 이전하기 위한 5가지 방법 - 윤석찬 (AWS 테크에반젤리스트) IDC 서버 몽땅 AWS로 이전하기 위한 5가지 방법 - 윤석찬 (AWS 테크에반젤리스트)
IDC 서버 몽땅 AWS로 이전하기 위한 5가지 방법 - 윤석찬 (AWS 테크에반젤리스트)
 
AWS 클라우드 비용 최적화를 위한 TIP - 임성은 AWS 매니저
AWS 클라우드 비용 최적화를 위한 TIP - 임성은 AWS 매니저AWS 클라우드 비용 최적화를 위한 TIP - 임성은 AWS 매니저
AWS 클라우드 비용 최적화를 위한 TIP - 임성은 AWS 매니저
 
사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...
사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...
사례로 알아보는 Database Migration Service : 데이터베이스 및 데이터 이관, 통합, 분리, 분석의 도구 - 발표자: ...
 
실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018
실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018
실전! AWS 기반 데이터베이스 마이그레이션::최홍식::AWS Summit Seoul 2018
 
대용량 데이터레이크 마이그레이션 사례 공유 [카카오게임즈 - 레벨 200] - 조은희, 팀장, 카카오게임즈 ::: Games on AWS ...
대용량 데이터레이크 마이그레이션 사례 공유 [카카오게임즈 - 레벨 200] - 조은희, 팀장, 카카오게임즈 ::: Games on AWS ...대용량 데이터레이크 마이그레이션 사례 공유 [카카오게임즈 - 레벨 200] - 조은희, 팀장, 카카오게임즈 ::: Games on AWS ...
대용량 데이터레이크 마이그레이션 사례 공유 [카카오게임즈 - 레벨 200] - 조은희, 팀장, 카카오게임즈 ::: Games on AWS ...
 
AWS Backup을 이용한 데이터베이스의 백업 자동화와 편리한 복구방법
AWS Backup을 이용한 데이터베이스의 백업 자동화와 편리한 복구방법AWS Backup을 이용한 데이터베이스의 백업 자동화와 편리한 복구방법
AWS Backup을 이용한 데이터베이스의 백업 자동화와 편리한 복구방법
 
The Zen of DataOps – AWS Lake Formation and the Data Supply Chain Pipeline
The Zen of DataOps – AWS Lake Formation and the Data Supply Chain PipelineThe Zen of DataOps – AWS Lake Formation and the Data Supply Chain Pipeline
The Zen of DataOps – AWS Lake Formation and the Data Supply Chain Pipeline
 
민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS
민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS
민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS
 
Introduction to Serverless
Introduction to ServerlessIntroduction to Serverless
Introduction to Serverless
 
Migration From Oracle to PostgreSQL
Migration From Oracle to PostgreSQLMigration From Oracle to PostgreSQL
Migration From Oracle to PostgreSQL
 

Similar a Cloud dw benchmark using tpd-ds( Snowflake vs Redshift vs EMR Hive )

기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...
Amazon Web Services Korea
 
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...
Amazon Web Services Korea
 
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호 상무, 조영준 상무, BSG::AWS Summit Se...
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호 상무, 조영준 상무, BSG::AWS Summit Se...기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호 상무, 조영준 상무, BSG::AWS Summit Se...
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호 상무, 조영준 상무, BSG::AWS Summit Se...
Amazon Web Services Korea
 
AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)
AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)
AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)
Amazon Web Services Korea
 
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
Amazon Web Services Korea
 

Similar a Cloud dw benchmark using tpd-ds( Snowflake vs Redshift vs EMR Hive ) (20)

게임 고객 사례를 통해 살펴보는 AWS 활용 전략 :: 이경안 :: AWS Summit Seoul 2016
게임 고객 사례를 통해 살펴보는 AWS 활용 전략 :: 이경안 :: AWS Summit Seoul 2016게임 고객 사례를 통해 살펴보는 AWS 활용 전략 :: 이경안 :: AWS Summit Seoul 2016
게임 고객 사례를 통해 살펴보는 AWS 활용 전략 :: 이경안 :: AWS Summit Seoul 2016
 
[AWS Media Symposium 2019] 고객사례 | SBS Web Service Cloud Migration Process - 김...
[AWS Media Symposium 2019] 고객사례 | SBS Web Service Cloud Migration Process - 김...[AWS Media Symposium 2019] 고객사례 | SBS Web Service Cloud Migration Process - 김...
[AWS Media Symposium 2019] 고객사례 | SBS Web Service Cloud Migration Process - 김...
 
디지털 미디어 산업을 위한 AWS 서비스 :: 홍두현 :: AWS Summit Seoul 2016
디지털 미디어 산업을 위한 AWS 서비스 :: 홍두현 :: AWS Summit Seoul 2016디지털 미디어 산업을 위한 AWS 서비스 :: 홍두현 :: AWS Summit Seoul 2016
디지털 미디어 산업을 위한 AWS 서비스 :: 홍두현 :: AWS Summit Seoul 2016
 
기술 지원 사례로 알아보는 마이그레이션 이슈 및 해결 방안 모음-김용기, AWS Storage Specialist SA / 한소영, AWS...
기술 지원 사례로 알아보는 마이그레이션 이슈 및 해결 방안 모음-김용기, AWS Storage Specialist SA / 한소영, AWS...기술 지원 사례로 알아보는 마이그레이션 이슈 및 해결 방안 모음-김용기, AWS Storage Specialist SA / 한소영, AWS...
기술 지원 사례로 알아보는 마이그레이션 이슈 및 해결 방안 모음-김용기, AWS Storage Specialist SA / 한소영, AWS...
 
[E-commerce & Retail Day] Data Freedom을 위한 Database 최적화 전략
[E-commerce & Retail Day] Data Freedom을 위한 Database 최적화 전략[E-commerce & Retail Day] Data Freedom을 위한 Database 최적화 전략
[E-commerce & Retail Day] Data Freedom을 위한 Database 최적화 전략
 
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...
 
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호, 조영준 BSG Partners::AWS Summit ...
 
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호 상무, 조영준 상무, BSG::AWS Summit Se...
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호 상무, 조영준 상무, BSG::AWS Summit Se...기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호 상무, 조영준 상무, BSG::AWS Summit Se...
기업 IT 담당자라면 꼭 알아야 할 Enterprise AWS 사례와 특징::김종호 상무, 조영준 상무, BSG::AWS Summit Se...
 
AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)
AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)
AWS CLOUD 2017 - Amazon Redshift 기반 DW 와 비지니스 인텔리전스 구현 방법 (김일호 솔루션즈 아키텍트)
 
[찾아가는세미나] 클라우드 데이터 가상화솔루션
[찾아가는세미나] 클라우드 데이터 가상화솔루션[찾아가는세미나] 클라우드 데이터 가상화솔루션
[찾아가는세미나] 클라우드 데이터 가상화솔루션
 
변화와 혁신을 위한 클라우드 마이그레이션 – 김진우 AWS 어카운트 매니저, 이아영 네오위즈 가버너스팀 팀장, 박주희 우아한형제들 시스템신...
변화와 혁신을 위한 클라우드 마이그레이션 – 김진우 AWS 어카운트 매니저, 이아영 네오위즈 가버너스팀 팀장, 박주희 우아한형제들 시스템신...변화와 혁신을 위한 클라우드 마이그레이션 – 김진우 AWS 어카운트 매니저, 이아영 네오위즈 가버너스팀 팀장, 박주희 우아한형제들 시스템신...
변화와 혁신을 위한 클라우드 마이그레이션 – 김진우 AWS 어카운트 매니저, 이아영 네오위즈 가버너스팀 팀장, 박주희 우아한형제들 시스템신...
 
SQream DB, GPU-accelerated data warehouse
SQream DB, GPU-accelerated data warehouseSQream DB, GPU-accelerated data warehouse
SQream DB, GPU-accelerated data warehouse
 
데이터 분석가를 위한 신규 분석 서비스 - 김기영, AWS 분석 솔루션즈 아키텍트 / 변규현, 당근마켓 소프트웨어 엔지니어 :: AWS r...
데이터 분석가를 위한 신규 분석 서비스 - 김기영, AWS 분석 솔루션즈 아키텍트 / 변규현, 당근마켓 소프트웨어 엔지니어 :: AWS r...데이터 분석가를 위한 신규 분석 서비스 - 김기영, AWS 분석 솔루션즈 아키텍트 / 변규현, 당근마켓 소프트웨어 엔지니어 :: AWS r...
데이터 분석가를 위한 신규 분석 서비스 - 김기영, AWS 분석 솔루션즈 아키텍트 / 변규현, 당근마켓 소프트웨어 엔지니어 :: AWS r...
 
Azure databases for PostgreSQL, MySQL and MariaDB
Azure databases for PostgreSQL, MySQL and MariaDB Azure databases for PostgreSQL, MySQL and MariaDB
Azure databases for PostgreSQL, MySQL and MariaDB
 
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
레코벨의 추천 서비스 고군 분투기 - AWS Summit Seoul 2017
 
Azure Databases for PostgreSQL MYSQL and MariaDB
Azure Databases for PostgreSQL MYSQL and MariaDBAzure Databases for PostgreSQL MYSQL and MariaDB
Azure Databases for PostgreSQL MYSQL and MariaDB
 
데이터베이스 운영, 서버리스로 걱정 끝! - 윤석찬, AWS 테크에반젤리스트 - AWS Builders Online Series
데이터베이스 운영, 서버리스로 걱정 끝! - 윤석찬, AWS 테크에반젤리스트 - AWS Builders Online Series데이터베이스 운영, 서버리스로 걱정 끝! - 윤석찬, AWS 테크에반젤리스트 - AWS Builders Online Series
데이터베이스 운영, 서버리스로 걱정 끝! - 윤석찬, AWS 테크에반젤리스트 - AWS Builders Online Series
 
MariaDB 마이그레이션 - 네오클로바
MariaDB 마이그레이션 - 네오클로바MariaDB 마이그레이션 - 네오클로바
MariaDB 마이그레이션 - 네오클로바
 
경력 공유와 AWS-GCP 비교.pptx
경력 공유와 AWS-GCP 비교.pptx경력 공유와 AWS-GCP 비교.pptx
경력 공유와 AWS-GCP 비교.pptx
 
SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...
SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...
SK Telecom - 망관리 프로젝트 TANGO의 오픈소스 데이터베이스 전환 여정 - 발표자 : 박승전, Project Manager, ...
 

Más de SANG WON PARK

The Data tech for AI based innovation(기업의 AI기반 혁신을 지원하는 데이터 기술)
The Data tech for AI based innovation(기업의 AI기반 혁신을 지원하는 데이터 기술)The Data tech for AI based innovation(기업의 AI기반 혁신을 지원하는 데이터 기술)
The Data tech for AI based innovation(기업의 AI기반 혁신을 지원하는 데이터 기술)
SANG WON PARK
 
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
SANG WON PARK
 

Más de SANG WON PARK (17)

Trends_of_MLOps_tech_in_business
Trends_of_MLOps_tech_in_businessTrends_of_MLOps_tech_in_business
Trends_of_MLOps_tech_in_business
 
The Data tech for AI based innovation(기업의 AI기반 혁신을 지원하는 데이터 기술)
The Data tech for AI based innovation(기업의 AI기반 혁신을 지원하는 데이터 기술)The Data tech for AI based innovation(기업의 AI기반 혁신을 지원하는 데이터 기술)
The Data tech for AI based innovation(기업의 AI기반 혁신을 지원하는 데이터 기술)
 
Understanding of Apache kafka metrics for monitoring
Understanding of Apache kafka metrics for monitoring Understanding of Apache kafka metrics for monitoring
Understanding of Apache kafka metrics for monitoring
 
Apache kafka performance(latency)_benchmark_v0.3
Apache kafka performance(latency)_benchmark_v0.3Apache kafka performance(latency)_benchmark_v0.3
Apache kafka performance(latency)_benchmark_v0.3
 
Optane DC Persistent Memory(DCPMM) 성능 테스트
Optane DC Persistent Memory(DCPMM) 성능 테스트Optane DC Persistent Memory(DCPMM) 성능 테스트
Optane DC Persistent Memory(DCPMM) 성능 테스트
 
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
Apache kafka 모니터링을 위한 Metrics 이해 및 최적화 방안
 
boosting 기법 이해 (bagging vs boosting)
boosting 기법 이해 (bagging vs boosting)boosting 기법 이해 (bagging vs boosting)
boosting 기법 이해 (bagging vs boosting)
 
Machine Learning Foundations (a case study approach) 강의 정리
Machine Learning Foundations (a case study approach) 강의 정리Machine Learning Foundations (a case study approach) 강의 정리
Machine Learning Foundations (a case study approach) 강의 정리
 
Apache kafka performance(throughput) - without data loss and guaranteeing dat...
Apache kafka performance(throughput) - without data loss and guaranteeing dat...Apache kafka performance(throughput) - without data loss and guaranteeing dat...
Apache kafka performance(throughput) - without data loss and guaranteeing dat...
 
Coursera Machine Learning (by Andrew Ng)_강의정리
Coursera Machine Learning (by Andrew Ng)_강의정리Coursera Machine Learning (by Andrew Ng)_강의정리
Coursera Machine Learning (by Andrew Ng)_강의정리
 
내가 이해하는 SVM(왜, 어떻게를 중심으로)
내가 이해하는 SVM(왜, 어떻게를 중심으로)내가 이해하는 SVM(왜, 어떻게를 중심으로)
내가 이해하는 SVM(왜, 어떻게를 중심으로)
 
코드로 이해하는 Back_propagation(cs231n)
코드로 이해하는 Back_propagation(cs231n)코드로 이해하는 Back_propagation(cs231n)
코드로 이해하는 Back_propagation(cs231n)
 
Rancher Simple User Guide
Rancher Simple User GuideRancher Simple User Guide
Rancher Simple User Guide
 
OLAP for Big Data (Druid vs Apache Kylin vs Apache Lens)
OLAP for Big Data (Druid vs Apache Kylin vs Apache Lens)OLAP for Big Data (Druid vs Apache Kylin vs Apache Lens)
OLAP for Big Data (Druid vs Apache Kylin vs Apache Lens)
 
Reinforcement learning v0.5
Reinforcement learning v0.5Reinforcement learning v0.5
Reinforcement learning v0.5
 
Code로 이해하는 RNN
Code로 이해하는 RNNCode로 이해하는 RNN
Code로 이해하는 RNN
 
Hadoop eco story 이해
Hadoop eco story 이해Hadoop eco story 이해
Hadoop eco story 이해
 

Cloud dw benchmark using tpd-ds( Snowflake vs Redshift vs EMR Hive )

  • 1. Cloud DW 트렌드 및 성능 비교 ( Snowflake vs AWS Redshift vs AWS EMR ) Performance & Cost Test 2021.07 freepsw
  • 2. 2 왜 기업들은 Cloud DW에 주목하는가? Cloud DW 솔루션의 성능은? 기존 Data Lake(EMR) 대비 성능은? 유사 Cloud DW(snowflake vs redshift) 대비 성능은? 시장에는 어떤 제품들이 있는가? 우리 Biz 환경에서는 어떤 제품을 도입해야 하는가?
  • 3. 3 Cloud DW ? 왜 많은 기업들에게 주목 받고 있을까?
  • 4. 4 왜 기업들은 Cloud DW에 주목할까? 정부 정책 변화 데이터 3법 (2020.01 시행) 빅데이터 센터 (16개소) AI/Data 산업 활성화 데이터 개방은 가속화되며, 기업은 더 많은 데이터를 분석하고자 함 더 많은 데이터를 기업의 데이터 이슈 Data Silo 현상 기존 DW의 한계 운영/투자 비용 증가 통합 관리할 수 있는 Data 아키텍처 진화 ETL à ELT 로 진화 Cloud DW 등장 Data Mesh 아키텍처 데이터 기술 필요
  • 5. 5 기업의 데이터 이슈 – Data Silo Data Lake 도입에도 Data Silo 발생 è 데이터 적시 활용 어려움 Data Silos 발생 DW Silo Hadoop Silo 과도한 ETL 작업 실행 (ETL 제품 종속) 동적인 컴퓨팅 자원 할당 어려움 (수많은 배치 스케줄) 분석가가 원하는 데이터를 적시에 확보하기 어려움 또 다른 Data Silo 발생 또 다른 Data Silo 발생 ETL을 통해 생성된 Data Silo 발생 https://databricks.com/glossary/data-lakehouse
  • 6. 6 Data 아키텍처의 변화 – ELT 분석가가 필요한 데이터를 원하는 방식으로 변환 및 조회 가능한 ELT 도입 증가 https://blog.naver.com/freepsw/222276087707
  • 7. 7 Cloud DW & Lakehouse 제품 등장 모든 데이터를 저장하고, 목적에 따라 DW를 구성하여, 최소화된 운영비로 원하는 성능 제공 Data Warehouse (On-prem) Data Lake Cloud DW Lake House • 정형 데이터 중심 • 저장 공간 및 컴퓨팅 성능 한계 Cloud 스토리지로 저장용량 한계 극복 필요시 DW 즉시 생성 (처리 성능 개선) Manage Service로 운영 부담 제거 • 정형 + 반정형 중심 • Snowflake, Redshift, BigQuery 등 • 신규 제품 지속 출시 및 시장 점유율 증가 • 정형 + 반정형 + 비정형 지원 • 정형 데이터에 최적화된 조회 성능 한계 (ETL을 통해 DW로 데이터 적재 후 조회) • 복잡한 Data Engineering 필요 Cloud 스토리지로 저장용량 한계 극복 필요시 DW 즉시 생성 (처리 성능 개선) Manage Service로 운영 부담 제거 정형 데이터 중심의 Data Lake 고객의 전환 수요 증가 (EMR à Snowflake/Redshift) • 정형 + 반정형 + 비정형 지원 • 복잡한 ETL 없이 빠르게 데이터 조회 (Data Silo 제거) • Delta Lake (Data Bricks)
  • 8. 8 https://interworks.com/blog/sparker/2018/03/08/introducing-snowflake-cloud-based-data-warehousing/ Cloud DW 란? Cloud의 동적 자원(컴퓨팅 & 스토리지)를 활용하여 사용자에게 동적인 DW환경을 제공 (성능 개선, 운영 부담 감소, 비용 절감 효과) Snowflake의 서비스 개념 (많은 제품이 유사한 기능 제공)
  • 9. 9 Cloud DW는 구체적으로 어떤 기능을 제공하는가? Cloud의 장점을 기반으로 DW의 성능/안정성/비용 최적화 Data integration Data storage Performance Management Security & compliance - 배치/실시간 등 대용량 데이터 유입 - - 정형/반정형 데이터 지원 - - 클라우드 스토리지 장점 활용 - - 칼럼 기반 스토리지 지원 - - 스토리지와 컴퓨팅 노드 분리 - - 동적 scale out 지원 - - 캐싱/분산(MPP) 처리 지원 - - 인증/암호화/접근제어 - - 다양한 법적 규제 지원 - - 빠른 DW 환경 구성- - 데이터 백업 및 복구 용이 - - 운영 비용 감소 -
  • 10. 10 시장에는 어떤 Cloud DW 제품들이 있을까 ? On-Prem DW Managed Cloud DW Cloud DW Cloud Data Lake Cloud based Self-DW Public Cloud DW 인프라 및 운영 비용 해결 빠른 성능과 운영 복잡성 감소 Cloud 사업자 제공 서비스 • Oracle Exadata • Teradata • IBM Netezza, • Oracle Exadata • EMC Greenplum Data C omputing Appliance • SAP Sybase IQ • HP Vertica • AWS EMR • GCP Dataproc • Azure HDInsight • Cloudera CDP • AWS Redshift • GCP BigQuery • Azure Synaps DW 전문 기업의 Cloud기반 서비스 • Snowflake • GCP BigQuery omni • Teradata Vantage Data Mart Cloud Infra에 직접 DW 구축 • Vertica • Greenplum • IBM DB2 기존 DW/DataMart 영역과 Data Lake영역을 포함하여 시장을 확장 중 Cloud 사업자 종속 Multi-Cloud 지원 Multi-Cloud + Hybrid Cloud 제품 종속 제거 운영 편의성 DeltaLake (Databricks) Snowflake Firebolt
  • 11. 11 시장에는 어떤 Cloud DW 제품들이 있을까 ? On-Prem DW Managed Cloud DW Cloud DW Cloud Data Lake Cloud based Self-DW Public Cloud DW 인프라 및 운영 비용 해결 빠른 성능과 운영 복잡성 감소 Cloud 사업자 제공 서비스 • Oracle Exadata • Teradata • IBM Netezza, • Oracle Exadata • EMC Greenplum Data C omputing Appliance • SAP Sybase IQ • HP Vertica • AWS EMR • GCP Dataproc • Azure HDInsight • Cloudera CDP • AWS Redshift • GCP BigQuery • Azure Synaps DW 전문 기업의 Cloud기반 서비스 • Snowflake • GCP BigQuery omni • Teradata Vantage Data Mart Cloud Infra에 직접 DW 구축 • Vertica • Greenplum • IBM DB2 기존 DW/DataMart 영역과 Data Lake영역을 포함하여 시장을 확장 중 Cloud 사업자 종속 Multi-Cloud 지원 Multi-Cloud + Hybrid Cloud 제품 종속 제거 운영 편의성 Databricks Snowflake Firebolt 기업의 상황에 맞는 최적 제품을 찾아야 함.
  • 12. 12 기업 상황에 맞는 Cloud DW는 어떻게 선정해야 할까? 운영 편의성 & 보안 최적의 비용과 성능 보장 다양한 제품과 연동/통합 도입을 원하는 기업의 고민은….. 실제 적용 시 원하는 성능이 나올까? 사전에 검증이 필요하다!
  • 13. 13 Cloud DW의 성능을 어떻게 검증할 것인가? 다양한 기업 환경에 맞는 성능(Benchmark) 결과를 찾기는 어렵다.
  • 14. 14 Cloud DW의 성능을 비교해 보자 !
  • 15. 15 테스트 제약 조건 동일한 조건에서 성능을 비교할 수 있도록 테스트 자원 설정 표준 데이터 사용 성능/비용 측정 동일한 자원 할당 가장 범용적으로 활용하는 TPC-DS 데이터 생성 50G, 200G, 1000G(1TB) 활용 각 제품에 맞게 데이터 적재 Snowflakes는 자원 스펙을 공개하지 않음 따라서, Snowflake 기준으로 동일한 비용의 자원 할당 (AWS는 Instance 유형 및 노드 개수 조정) (+- 0.24 $ / Hour 오차 있음) DW 생성 시간 (얼마나 빨리 DW를 생성하는가?) 처리 성능 (데이터 로딩 시간 + 쿼리 시간) 소요 비용 (DW 생성 후 쿼리 완료까지 소요된 비용) “ 시간당 동일한 비용의 자원 할당” “ 빅데이터 용 TPC-DS 데이터 활용 ” ” 처리 성능 및 소요 비용 비교 ”
  • 16. 16 상세 테스트 환경 설정 AWS Tokyo Region에서 테스트 수행 구분 설명 고려 사항 테스트 대상 Snowflake AWS Redshift AWS EMR - 6.2.0 (Hive) Redshift ra3 type에 Aqua 적용하지 않음 테스트 데이터 TPC-DS Benchmark 데이터 50G, 200G, 1,000G (1TB) 데이터 사용 데이터 포맷 Snowflake와 Redshift는 자체 최적화 포맷 (csv import) EMR은 parquet 포맷 사용 Snowflake/Redshift : gzip으로 압축된 csv 파일 로딩 EMR : parquet 포맷으로 변화하여 S3에 저장 (동일 region) 비용 기준 (DW 서버 스펙) Snowflake (Standard Type, Tokyo region) 비용을 기준 (2021.7월 기준) (Snowflake는 서버 스펙 공개하지 않음) X-Small : 2.8$ Medium : 11.4$ (x-small 대비 4 배) Large : 22.8$ (x-small 대비 8 배) Query 성능 측정 TPC-DS에서 제공하는 99개 Query 실행 (순차적으로 실행하여 전체 쿼리 실행시간 비교) 소요 비용 측정 Cloud DW 서비스(자원)을 사용한 총 비용 DW 생성 à 데이터 로딩 à 성능 측정 à 종료까지 사용된 총 비용
  • 17. 17 테스트 조건 >> 동일한 자원 할당 ( Snowflake 기준) Snowflake 기준으로 동일한 시간당 비용의 자원 할당 (AWS Tokyo Region) - 본 테스트에서는 ”X-Small, Medium, Large” 기준으로 각 제품별 Type 선택 - Snowflake와 동일한 비용의 AWS Type 으로 선별
  • 18. 18 [백업] Snowflake 자원 할당 기준 Snowflake 기준으로 시간당 비용 기준 설정 (Tokyo Region/Standard 요금제 기준) - Snowflake의 경우는 인프라 스펙은 공개하지 않으며, 클러스터 사이즈/비용만 공개 - 시간당 2.8$ ~ 최대 364$까지 존재 데이터 량 및 원하는 조회 성능(속도)에 따라 Virtual Warehouse(WH) 선택하여 실행 Snowflake에서 제공하는 Virtual Warehouse유형 수초 이내로 생성됨
  • 19. 19 [백업] AWS Redshift 자원 할당 기준 (Tokyo Region) 2가지 Type(DC2, RA3)으로 진행하며, Snowflake 기준으로 동일한 가격의 자원 할당 - 가장 최신 type은 RA3이며, Aurora 옵션은 미 적용(리소스에 따라 enable이 불가능한 경우가 많음) - Type이 세분화되어 있지 않아서, 비용 증가 폭이 크다. (약 5배 증가) (즉, 애매한 용량의 경우 비용 과다 지출 가능) 처리 성능 중심의 Test이므로, 저장공간 중심의 Type인 DS2는 제외
  • 20. 20 [백업] AWS EMR 자원 할당 기준 (Tokyo Region) EMR은 ec2 Instance를 선택하는 방식이라, 약 150개 유형에서 임의로 선택
  • 21. 21 테스트 조건 >> 테스트 데이터 (TPC-DS) 기존 TPC-H 대비 Data Warehouse 용으로 많이 사용되는 TPC-DS 선택 - 분석가들이 많이 사용하는 복잡한 Ad-hoc/olap query, reporting 등의 다양한 query(99개) 지원 - TPC-DS Schema [ 데이터 size 별 Table record 건수] • 정규화된 테이블 구조를 가지며, • DW에서 많이 사용하는 star schema로 구성되어, • 기업의 환경과 유사한 테스트가 가능하다. • 1TB의 경우 최대 2백 80만 건의 record가 생성됨 (store_sales table)
  • 22. 22 테스트 환경 및 구성도 AWS 인프라를 이용하여 Test client와 대상 서비스(snowflake, redshift, emr)를 검증한다. - EMR을 제외하고, 나머지 DW 제품들은 데이터를 import하면서 자체 최적화된 포맷으로 저장 (성능 향상) - AWS Tokyo Region (동일 region에서 진행) Data Generator (TPC-DS) 1) 데이터 생성 후 S3 Upload Data Loader 2) S3 Data 적재 (DB 생성 후 Import) 2) Table 생성 Execute Query 3) TPC-DS에서 제공하는 99개 Query 실행 후 성능 기록 ( Parquet format ) ( 자체 최적 format ) ( 자체 최적 format ) ( TPC-DS Query : https://github.com/Agirish/tpcds )
  • 23. 23 테스트 케이스 (다양한 관점 별 성능 측정) Data Size > DW Size > DW Type 별로 구분하여 총 30개의 Test Case 실행 50G는 제품의 다양한 Spec을 추가하여 성능 확인
  • 24. 24 Cloud DW의 성능 테스트 결과는?
  • 26. 테스트 결과 (50G) – Query 실행 속도 (Snowflake) 모든 가격대(XS, Medium, Large)에서 Snowflake가 가장 빠른 성능을 제공한다. - Medium 사이즈는 X-Small 대비 약 30% 성능 개선 - Large Size가 성능 개선 효과가 매우 높음 (X-Small 대비 2배 빠른 성능) Time (Minute)
  • 27. 테스트 결과 (50G) – Query 실행 속도 (AWS Redshift) 50G에서는 Instance node 수의 증가가 성능 향상에 영향이 낮음 - 데이터가 많지 않을 경우, 고가의 장비(또는 노드 증가)는 성능에 영향이 낮음 - Ra3.4xlarge type의 3개 node에서 가장 높은 성능 (X-Small 대비 2배) Node를 6개로 증가했으나, 쿼리 소요시간은 더 오래 걸림 Time (Minute) 작은 데이터는 dc2 type이 성능 측면에서 효율적
  • 28. 테스트 결과 (50G) – Query 실행 속도 (AWS EMR) EMR은 EC2 Instance 스펙 향상이 성능에 영향이 없음 (사용자가 충분히 검증해야 함) - C5.2xlarge (8core, 16G Mem) à c5n.4xlarge(16core, 42G Mem) à m5.8xlarge(32core, 128G Mem) à m5a.24xlarge( 96core, 384G Mem) - EC2를 c5 à m5 변경 (node는 5대로 증가) EC2를 m5.8xlarge à m5a.24xlarge 변경 (node는 4대로 감소) 쿼리 소요시간은 더 오래 걸림 EC2 c5.2xlage à c5n.4xlarge 변경 (node는 2대로 감소) 성능은 유사함 Time (Minute)
  • 29. 테스트 결과 (50G) – 비용 대비 성능 비교 작은 데이터(50G)에서는 모든 사이즈(X-small, Medium, Large)에서 Snowflake가 가장 효율적 - 또한 비용을 증가(DW 사이즈 향상)했을 때, 성능 개선효과도 가장 높음 - Snowflake가 비용 대비 가장 효율적 60% 낮은 비용으로, 2배 빠른 성능 Time (Minute) Cost (달러, $) Snowflake가 Redshift 대비 3배 낮은 비용으로, 3배 빠른 성능 Snowflake가 Redshift 대비 35% 낮은 비용으로, 30% 빠른 성능
  • 31. 테스트 결과 (200G) – Query 실행 속도 (Snowflake) Medium과 Large에서 빠른 성능을 제공 (200G 이상은 X-small 사용시 성능 한계) - Medium 에서 성능 개선 효과가 가장 높음 (3배 빠른 성능 제공) - Time (Minute) Medium 대비 성능 개선 효과가 높지 않음 (약 1.5배 빠른 성능) 성능 개선효과가 가장 높음 (X-Small 대비 3배) 200G에서는 Snowflake X-Small이 Redshift와 유사하거나, 성능이 떨어짐
  • 32. 테스트 결과 (200G) – Query 실행 속도 (AWS Redshift) X-Small size에서는 Redshift(dc2 type)이 가장 빠른 성능 제공 - 200G는 dc2 type에 노드를 확장하는 것이 효과적으로 보임 - Time (Minute) Ra3.4xlarge로 업그레이드 시 2배 이상 성능 개선 DC2 type 성능이 가장 높음 (Node가 8대라 분산 효과?)
  • 33. 테스트 결과 (200G) – Query 실행 속도 (AWS EMR) Time (Minute) 32core, 128G 서버를 5 node로 구성 시 성능개선 EMR은 EC2 Instance 스펙 향상이 성능에 영향이 없음 (사용자가 충분히 검증해야 함) - C5.2xlarge (8core, 16G Mem) à m5.8xlarge(32core, 128G Mem) à m5a.24xlarge( 96core, 384G Mem) - 고 성능 장비는 오히려 성능 저하 (이 부분은 좀 더 확인 필요)
  • 34. 테스트 결과 (200G) – 비용 대비 성능 비교 200G에서는 X-Small은 Redshift dc2 type이 효율적 (Snowflake X-Small 사이즈 성능부하 발생 ) - Medium 이상의 size에서는 snowflake의 비용 및 성능이 약 30% 뛰어남 - X-Small 사이즈에서는 Redshift dc2 type이 30% 낮은 비용(2.6$)으로, 13% 빠른 성능 Time (Minute) Cost (달러, $) Redshift(large) 대비 30% 낮은 비용(6$)으로, 50% 빠른 성능 Redshift 대비 20% 낮은 비용(4.1$)으로, 20% 빠른 성능
  • 36. 테스트 결과 (1 TB) – Query 실행 속도 (Snowflake) 1TB 이상은 Large Size 이상의 Virtual Warehouse를 선택해야 빠른 성능 제공 가능 - Snowflake는 데이터 사이즈에 따라서 적합한 Virtual Warehouse 선택 필요 (사용자가 잘 선택할 수 있을까?) - Time (Minute) Medium Size도 1TB에서는 Redshift와 성능 유사 Snowflake X-Small은 1 TB 데이터 처리에 가장 낮은 성능 Large Size 부터 Redshift 대비 빠른 성능 제공
  • 37. 테스트 결과 (1 TB) – Query 실행 속도 (Redshift) 1TB에서는 ra3 type에서 노드를 확장하면 Query 속도가 빠르게 향상됨 - 1TB 에서는 고사양의 장비와 노드를 확장하는 것이 성능 측면에서 효율적 - Time (Minute) 성능 개선효과 가장 높음 (약 3배 빠른 성능) 1TB는 X-Small로 처리시 성능 낮음 약 2배 빠른 성능
  • 38. 테스트 결과 (1 TB) – Query 실행 속도 (EMR) EMR은 데이터가 1TB로 증가하면서 작은 데이터(50G, 200G) 대비 향상된 성능을 제공 - 아주 고사양의 장비 보다는, CPU/Memory 증설과 노드 수를 증가하는 것이 성능에 효과적 - Time (Minute) 데이터가 커질수록 성능 차이가 아주 크지 않음 데이터가 커져도 높은 스펙의 인스턴스의 장점이 거의 없음 Medium 사이즈에서 2배 빠른 성능 제공
  • 39. 데이터가 1TB로 증가하면서 Redshift vs Snowflake 성능 & 비용이 거의 유사하게 측정됨 - Snowflake는 데이터 사이즈와 맞지 않는 Virtual Warehouse Size(X-Small)을 선택 시, 비용 증가 & 성능 저하 - - EMR은 가장 낮은 비용으로 Snowflake보다 빠르게 쿼리 실행 가능 - X-Small 사이즈에서는 Redshift ra3 type이 Snowflake 대비 15% 낮은 비용(15.1$)으로, 25% 빠른 성능 Time (Minute) Cost (달러, $) Snowflake와 Redshift의 성능/비용이 거의 유사 Redshift가 Snowflake 대비 5% 낮은 비용(19.4$)으로, 9% 빠른 성능 테스트 결과 (1 TB) – 비용 대비 성능 비교 가장 낮은 비용으로 1TB 처리 가능
  • 40. 40 Cloud DW 성능 테스트 결과를 정리해 보면?
  • 41. 41 전반적으로 Snowflake가 성능 & 비용 측면에서 효율적 Data Size와 Cluster Type에 따라 성능/비용 차이 발생 DW Type Data Size 사용시 고려사항 50 G 200 G 1000 G (1 TB) Snowflake 가장 빠른 성능 (X-Small, Medium, Large) 가장 낮은 가격 (X-Small, Medium, Large) 가장 빠른 성능 (Medium, Large) 가장 낮은 가격 (Medium, Large) 가장 빠른 성능 (Large) 가장 낮은 가격 (Large) • 쿼리할 데이터 사이즈에 따라, 최적의 Cluster Size 존재 • 기업이 보유한 데이터 & 자주 사용하는 SQL을 이용하여, 사전에 용도별 Cluster Size 확인 필요 (비용&성능 최적화) • 대량의 데이터(1 TB)에 작은 Cluster Size (X-Small)를 할당하면, 최악의 성능과 비용이 나옴 Redshift 가장 빠른 성능 (X-Small, dc2.large_8 node) 가장 낮은 가격 (X-Small, dc2.large_8 node) 가장 빠른 성능 (Medium, ra3.4xplus_3_node) 가장 낮은 가격 (Medium, ra3.4xplus_3_node) • 200G 이상의 데이터에서 비용 대비 성능이 높아짐. • Snowflake 대비 선택 가능한 Type이 작음. • Ra3 type 권장 (ra3.xplus, ra3.4xlarge, ra3.16xlarge) • 비용이 5배 단위로 증가하여, 세분화된 요금 관리 어려움 EMR (Hive) 가장 느린 성능 가장 비싼 가격 가장 느린 성능 가장 비싼 가격 가장 느린 성능 가장 낮은 가격 (X-Small, c5_2xlarge_5_node) • 1 TB 이상의 대량 데이터를 느리더라도 안정적으로 실행하는 환 경에 적합 • 기업의 목적(비용, 성능)에 따라 최적의 Instance Type을 직접 찾 아야 함. (시간과 노력 필요)
  • 44. 44 제품별 성능 & 비용 비교 (Snowflake) 데이터 사이즈가 클 때, 작은 Cluster 선택하면, 성능 & 비용 모두 최악 데이터 Size 별 성능/비용 비교 DW Size 별 성능/비용 비교 50 G 200 G 1000 G (1 TB) X-Small Medium Large 50G : X-Small 이 최적 200G : Medium이 최적 1TB : Large가 최적 (데이터 사이즈에 따라, 최적의 Cluster Size 존재) (비용 증가에 따른 성능 개선 효과 높음)
  • 45. 45 제품별 성능 & 비용 비교 (Redshift) DW Type 업그레이드에 따라, 일부 성능 개선 효과 데이터 Size 별 성능/비용 비교 DW Size 별 성능/비용 비교 50 G 200 G 1000 G (1 TB) X-Small Medium Large 데이터가 클 수록 (1TB), 비용을 증가하면, 성능개선 효과가 높음 (데이터가 클수록, 성능 개선효과 높음) Redshift는 1TB에서 비용 50% 증가로, 6배 빠른 성능 제공 (1 TB에서 비용에 따른 성능 개선효과 높음)
  • 46. 46 제품별 성능 & 비용 비교 (EMR) 200G 이하는 DW Type 변경(비용증가)에 따른 성능 개선효과가 없음 데이터 Size 별 성능/비용 비교 DW Size 별 성능/비용 비교 50 G 200 G 1000 G (1 TB) X-Small Medium Large 50G/200G 데이터는 비용을 추가(인스턴스 변경)해도, 성능 개선효과 거의 없음 (200G 까지는 성능 개선 효과 낮음) 1TB는 성능은 개선(50%)되었으나, 비용이 7배 증가 (비용 증가에 따른 성능 개선 효과 낮음) 1TB 데이터는 적합한 인스턴스 선택 시, 성능 개선효과 높음