SlideShare ist ein Scribd-Unternehmen logo
1 von 46
Downloaden Sie, um offline zu lesen
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 데이터는
적합한 인스턴스 선택 시,
성능 개선효과 높음

Weitere ähnliche Inhalte

Was ist angesagt?

백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스
백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스
백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스
NAVER D2
 
클라우드 기반 AWS 데이터베이스 선택 옵션 - AWS Summit Seoul 2017
클라우드 기반 AWS 데이터베이스 선택 옵션 - AWS Summit Seoul 2017 클라우드 기반 AWS 데이터베이스 선택 옵션 - AWS Summit Seoul 2017
클라우드 기반 AWS 데이터베이스 선택 옵션 - AWS Summit Seoul 2017
Amazon Web Services Korea
 

Was ist angesagt? (20)

Amazon Redshift로 데이터웨어하우스(DW) 구축하기
Amazon Redshift로 데이터웨어하우스(DW) 구축하기Amazon Redshift로 데이터웨어하우스(DW) 구축하기
Amazon Redshift로 데이터웨어하우스(DW) 구축하기
 
민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS
민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS
민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS
 
AWS Glue - let's get stuck in!
AWS Glue - let's get stuck in!AWS Glue - let's get stuck in!
AWS Glue - let's get stuck in!
 
Object storage의 이해와 활용
Object storage의 이해와 활용Object storage의 이해와 활용
Object storage의 이해와 활용
 
EMR 플랫폼 기반의 Spark 워크로드 실행 최적화 방안 - 정세웅, AWS 솔루션즈 아키텍트:: AWS Summit Online Ko...
EMR 플랫폼 기반의 Spark 워크로드 실행 최적화 방안 - 정세웅, AWS 솔루션즈 아키텍트::  AWS Summit Online Ko...EMR 플랫폼 기반의 Spark 워크로드 실행 최적화 방안 - 정세웅, AWS 솔루션즈 아키텍트::  AWS Summit Online Ko...
EMR 플랫폼 기반의 Spark 워크로드 실행 최적화 방안 - 정세웅, AWS 솔루션즈 아키텍트:: AWS Summit Online Ko...
 
A Thorough Comparison of Delta Lake, Iceberg and Hudi
A Thorough Comparison of Delta Lake, Iceberg and HudiA Thorough Comparison of Delta Lake, Iceberg and Hudi
A Thorough Comparison of Delta Lake, Iceberg and Hudi
 
글로벌 기업들의 효과적인 데이터 분석을 위한 Data Lake 구축 및 분석 사례 - 김준형 (AWS 솔루션즈 아키텍트)
글로벌 기업들의 효과적인 데이터 분석을 위한 Data Lake 구축 및 분석 사례 - 김준형 (AWS 솔루션즈 아키텍트)글로벌 기업들의 효과적인 데이터 분석을 위한 Data Lake 구축 및 분석 사례 - 김준형 (AWS 솔루션즈 아키텍트)
글로벌 기업들의 효과적인 데이터 분석을 위한 Data Lake 구축 및 분석 사례 - 김준형 (AWS 솔루션즈 아키텍트)
 
Amazon Redshift
Amazon Redshift Amazon Redshift
Amazon Redshift
 
Snowflake Datawarehouse Architecturing
Snowflake Datawarehouse ArchitecturingSnowflake Datawarehouse Architecturing
Snowflake Datawarehouse Architecturing
 
[AWS Builders] Effective AWS Glue
[AWS Builders] Effective AWS Glue[AWS Builders] Effective AWS Glue
[AWS Builders] Effective AWS Glue
 
AWS Batch를 통한 손쉬운 일괄 처리 작업 관리하기 - 윤석찬 (AWS 테크에반젤리스트)
AWS Batch를 통한 손쉬운 일괄 처리 작업 관리하기 - 윤석찬 (AWS 테크에반젤리스트)AWS Batch를 통한 손쉬운 일괄 처리 작업 관리하기 - 윤석찬 (AWS 테크에반젤리스트)
AWS Batch를 통한 손쉬운 일괄 처리 작업 관리하기 - 윤석찬 (AWS 테크에반젤리스트)
 
Snowflake Architecture.pptx
Snowflake Architecture.pptxSnowflake Architecture.pptx
Snowflake Architecture.pptx
 
Aws glue를 통한 손쉬운 데이터 전처리 작업하기
Aws glue를 통한 손쉬운 데이터 전처리 작업하기Aws glue를 통한 손쉬운 데이터 전처리 작업하기
Aws glue를 통한 손쉬운 데이터 전처리 작업하기
 
빅데이터를 위한 AWS 모범사례와 아키텍처 구축 패턴 :: 양승도 :: AWS Summit Seoul 2016
빅데이터를 위한 AWS 모범사례와 아키텍처 구축 패턴 :: 양승도 :: AWS Summit Seoul 2016빅데이터를 위한 AWS 모범사례와 아키텍처 구축 패턴 :: 양승도 :: AWS Summit Seoul 2016
빅데이터를 위한 AWS 모범사례와 아키텍처 구축 패턴 :: 양승도 :: AWS Summit Seoul 2016
 
Building Your Data Warehouse with Amazon Redshift
Building Your Data Warehouse with Amazon RedshiftBuilding Your Data Warehouse with Amazon Redshift
Building Your Data Warehouse with Amazon Redshift
 
Data Warehousing with Amazon Redshift
Data Warehousing with Amazon RedshiftData Warehousing with Amazon Redshift
Data Warehousing with Amazon Redshift
 
백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스
백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스
백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스
 
Amazon EMR과 SageMaker를 이용하여 데이터를 준비하고 머신러닝 모델 개발 하기
Amazon EMR과 SageMaker를 이용하여 데이터를 준비하고 머신러닝 모델 개발 하기Amazon EMR과 SageMaker를 이용하여 데이터를 준비하고 머신러닝 모델 개발 하기
Amazon EMR과 SageMaker를 이용하여 데이터를 준비하고 머신러닝 모델 개발 하기
 
Deep Dive on Amazon Redshift
Deep Dive on Amazon RedshiftDeep Dive on Amazon Redshift
Deep Dive on Amazon Redshift
 
클라우드 기반 AWS 데이터베이스 선택 옵션 - AWS Summit Seoul 2017
클라우드 기반 AWS 데이터베이스 선택 옵션 - AWS Summit Seoul 2017 클라우드 기반 AWS 데이터베이스 선택 옵션 - AWS Summit Seoul 2017
클라우드 기반 AWS 데이터베이스 선택 옵션 - AWS Summit Seoul 2017
 

Ähnlich wie 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
 

Ähnlich wie 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 ...
 
AWS 활용한 Data Lake 구성하기
AWS 활용한 Data Lake 구성하기AWS 활용한 Data Lake 구성하기
AWS 활용한 Data Lake 구성하기
 
기업 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
 

Mehr von 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
 

Mehr von 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 데이터는 적합한 인스턴스 선택 시, 성능 개선효과 높음