Embed Size (px)
Citation preview
설계 및 튜닝
개요 및 아키텍쳐
데이터 로딩
백업 및 복구
업그레이드 및 확장
데이터 활용
개요 및 아키텍쳐
Data Warehouse ?
8x large 고객 t2 고객VS
Enterprise Startup
AWS – 누구에게나 차별없는 서비스
데이터 웨어하우스(DW) 솔루션도 AWS방식으로..
사용한 만큼만 지불 (노드 사전구매도 가능)
낮은 가격에 매우 빠른 성능 제공
오픈으로 다양한 벤더의 BI툴과 연동
손쉬운 생성 및 큰 규모로 확장
S
완전 관리형 DW 서비스
관계형 데이터 웨어하우스
대용량 병렬 처리 – 페타 바이트급 (최대 2PB)
관리형(Managed) 서비스
HDD 및 SSD 플랫폼 제공
1TB기준 년간 $1,000, 시간당 $0.25 부터 시작
예약 노드(Reserved Node) 옵션 제공
더 빠르고더 간단하고더 싸게
Amazon Redshift
*버지니아 기준
Amazon Redshift – 모든 것을 병렬로 분산
10GigE Mesh
JDBC/ODBC
상용 BI /오픈소스 솔루션
Query
Load
Backup
Restore
Resize
리더노드
컴퓨팅 노드
작게 시작하고 크게 확장 가능 – 고성능 DW
Dense Compute Nodes - dc1.large & dc1.8xlarge
dc1.large 노드
15GiB RAM2 virtual cores
단일노드 (160GB SSD)
클러스터 2-32 노드 (320GB – 5.12TB SSD)
dc1.8xlarge 노드
244GiB RAM32 virtual cores
클러스터 2-128 노드 (최대 326TB SSD)
작게 시작하고 크게 확장 가능 – 고용량 DW
Dense Storage Nodes - ds2.xlarge & ds2.8xlarge
ds2.xlarge 노드
31 GiB RAM4 virtual cores
단일노드 (2TB HDD)
클러스터 2-32 노드 (4TB – 64TB HDD)
ds2.8xlarge 노드
244GiB RAM36 virtual cores
클러스터 2-128 노드 (최대 2PB HDD)
시간당 요금ds2.xlarge 단일 노드
TB당 실제 요금 TB당 연간 요금
온 디맨드 1.150/시간 0.575/시간 $5037
1년 계약 선 결제 0.670/시간 (42%) 0.335/시간 $2934.6
3년 계약 선 결제 0.280/시간 (76%) 0.140/시간 $1226.4
• ds2.xlarge 는 2TB까지 저장 가능하므로, TB당 실제 요금은 /2 로 계산
• 선수금 없는 1년 계약 시에도 온 디맨드 대비 21% 저렴
Redshift 합리적인 사용비용
*서울리전(ap-northeast-2) 기준
리더 노드 (Leader Node)
SQL 연결 엔드포인트
메타 데이타 저장
클러스터의 모든 쿼리 수행을 관리
컴퓨팅 노드 (Compute Nodes)
로컬, 컬럼방식 스토리지
병렬로 쿼리 수행
S3 기반으로 로딩, 백업, 복구 수행
DynamoDB, EC2 호스트로부터 병렬 로딩
데이터 처리를 위한 HW 최적화
데이터 처리에 최적화(Host, N/W)
DS2: HDD; scale from 2TB to 2PB
DC1: SSD; scale from 160GB to 356TB
10 GigE(HPC)
IngestionBackupRestore
JDBC/ODBC
Amazon Redshift 아키텍쳐
개별 노드는 복수의 슬라이스로 구성
개별 슬라이스는 별도의 메모리, CPU 및 Disk공간 할당
각 슬라이스별로 독립적인 워크로드를 병렬로 실행
Node Size vCPU ECU RAM (GiB) Slices Per Node Storage Per Node
Node Range
Total Capacity
ds2.xlarge 4 13 31 2 2 TB HDD 1–32 64 TB
ds2.8xlarge 36 119 244 16 16 TB HDD 2–128 2 PB
Node Size vCPU ECU RAM (GiB) Slices Per Node Storage Per Node
Node Range
Total Capacity
dc1.large 2 7 15 2 160 GB SSD 1–32 5.12 TB
dc1.8xlarge 32 104 244 32 2.56 TB SSD 2–128 326 TB
DenseCompute
DenseStorage
Amazon Redshift 아키텍쳐 – 슬라이스
Amazon Redshift 손쉽게 클러스터 운영
데이터 백업시 전송(In Transit)/저장(At rest) 암호화 기능 제공
Amazon S3 로 지속적인/변경 부분/자동 백업 제공
클러스터 용량 만큼의 백업스토리지 기본제공(무료)
타 리전으로 스냅샷 비동기 복제 기능
Streaming restore 를 통해 빠르게 쿼리 재개 가능
디스크 장애, 노드의 복구는 자동으로 관리됨
Clients Amazon Redshift Amazon S3
자동백업
StreamingRestore
Amazon Redshift 는 IO 사용을 최소화 시킴
Columnar 스토리지
데이터 압축
Zone maps
개별 노드에 직접 연결된 스토리지(Directly Attached Storage)
Row storage
Columnstorage
ID Age State
123 20 CA
345 25 WA
678 40 FL
설계 및 튜닝
최적의 테이블 디자인 선택
1. 컬럼압축 (Compression Encodings)
2. 최적의 데이터 타입 선택
3. 데이터 분산(Distribution) 및 정렬(Sort)
컬럼 압축 ( Column Compression )
http://docs.aws.amazon.com/redshift/latest/dg/t_Compressing_data_on_disk.html
Compression은 DW 시스템이 스토리지에서 데이터를 읽는 크기를 줄여
IO를 최소화 시키고, 쿼리 성능을 향상 시키는 주요 도구
COPY 명령을 사용해서 Amazon Redshift로 데이터를 로딩 하면 데이터 분석
(Analyze)을 통해 최적의 압축 수행
압축 기능의 자동 적용을 위해 COPY 명령어 사용을 권장
자동 Compression 적용 - Copy
1. 테이블이 비어있는 것을 확인 – Empty 테이블에만 자동 Compression 적용가능
2. Copy 명령어를 사용하여, 데이터 업 로딩 – COMPUPDATE ON 사용
3. 생성된 BIGLIST 테이블의 새로운 스키마 확인
copy biglist from 's3://mybucket/biglist.txt' credentials 'aws_access_key_id=<access-key-id>;
aws_secret_access_key= <secret-access-key>' delimiter '|' COMPUPDATE ON;
Raw encoding (RAW)
Byte-dictionary (BYTEDICT)
Delta encoding (DELTA / DELTA32K)
Mostly encoding (MOSTLY8 / MOSTLY16 / MOSTLY32)
Runlength encoding (RUNLENGTH)
Text encoding (TEXT255 / TEXT32K)
LZO encoding * 2 ~ 4배차이
임시 테이블 이나, 스테이징 테이블에 데이터 로딩시..
자동 압축 사용 해제
Analyze 명령을 사용해서 올바른 encoding 선정
(ANALYZE COMPRESSION – 데이터 로딩 없이 분석만 실행)
분석을 통해 알아낸 최적의 Encoding 타입을 테이블에 수동 적용
COPY <tablename> FROM 's3://<bucket-name>/<object-prefix>' CREDENTIALS
<AWS_ACCESS_KEY>;<AWS_SECRET_ACCESS_KEY> DELIMITER ',' COMPUPDATE OFF MANIFEST;
Compression 유의사항
• Example Query (TPC-H dataset)
Compressed Uncompressed
14 seconds 37 seconds
압축된 테이블에 대한 쿼리 성능이 그렇지
않은 테이블에 비해 164% 더 높은 것으로
테스트 됨
Compression – 성능비교
• Example Query (TPC-H dataset)
Redshift 는 분산형(MPP) 시스템:
클러스터는 리더 노드와 컴퓨팅 노드로 구성
컴퓨팅 노드는 하나 이상의 슬라이스로 구성
각 슬라이스는 데이터를 포함
슬라이스가 선택되는 세가지 방법
1) Even distribution - Round Robin (자동)
2) 분배 키(Distribution Key)기준 선택
3) All Distribution
쿼리는 모든 슬라이스 들에 걸쳐 병렬수행:
최적의 쿼리 성능은 모든 슬라이스들에 걸쳐 데이터를 고르게 분산
데이터 분산 (Data Distribution)
테이블 디자인：분산 방식 비교
EVEN
• 각 레코드가 슬라이스에 라운드 로빈 방식으로 분산, 균등하게 데이터 저장
DISTKEY
• 명시적으로 지정한 컬럼을 기준으로 각 레코드의 슬라이스 배치가 결정됨
• 컬럼 카디널리티에 따라 슬라이스간 상당한 편차가 발생 가능
ALL
• 모든 레코드가 각 컴퓨팅 노드에 동일하게 복제
테이블 디자인：각 적용사례
EVEN
• 조인을 자주하지 않고 비정규화 된 테이블은 EVEN으로 분산
DISTKEY
• 여러 테이블에서 조인의 대상이 되는 경우 DISTKEY 로 분산
ALL
• 작은 테이블은 ALL （마스터 테이블）
ID Gender Name
101 M John Smith
292 F Jane Jones
139 M Peter Black
446 M Pat Partridge
658 F Sarah Cyan
164 M Brian Snail
209 M James White
306 F Lisa Green
2
3
4
ID Gender Name
101 M John Smith
306 F Lisa Green
ID Gender Name
292 F Jane Jones
209 M James White
ID Gender Name
139 M Peter Black
164 M Brian Snail
ID Gender Name
446 M Pat Partridge
658 F Sarah Cyan
RoundRobin
DISTSTYLE EVEN
ID Gender Name
101 M John Smith
292 F Jane Jones
139 M Peter Black
446 M Pat Partridge
658 F Sarah Cyan
164 M Brian Snail
209 M James White
306 F Lisa Green
2
3
4
ID Gender Name
101 M John Smith
306 F Lisa Green
ID Gender Name
292 F Jane Jones
209 M James White
ID Gender Name
139 M Peter Black
164 M Brian Snail
ID Gender Name
446 M Pat Partridge
658 F Sarah CyanDISTSTYLE KEY
HashFunction
ID Gender Name
101 M John Smith
292 F Jane Jones
139 M Peter Black
446 M Pat Partridge
658 F Sarah Cyan
164 M Brian Snail
209 M James White
306 F Lisa Green
2
3
4DISTSTYLE KEY
HashFunction
ID Gender Name
101 M John Smith
139 M Peter Black
446 M Pat Partridge
164 M Brian Snail
209 M James White
ID Gender Name
292 F Jane Jones
658 F Sarah Cyan
306 F Lisa Green
ID Gender Name
101 M John Smith
292 F Jane Jones
139 M Peter Black
446 M Pat Partridge
658 F Sarah Cyan
164 M Brian Snail
209 M James White
306 F Lisa Green
2
3
4DISTSTYLE ALL
ID Gender Name
101 M John Smith
292 F Jane Jones
139 M Peter Black
446 M Pat Partridge
658 F Sarah Cyan
164 M Brian Snail
209 M James White
306 F Lisa Green
ID Gender Name
101 M John Smith
292 F Jane Jones
139 M Peter Black
446 M Pat Partridge
658 F Sarah Cyan
164 M Brian Snail
209 M James White
306 F Lisa Green
ID Gender Name
101 M John Smith
292 F Jane Jones
139 M Peter Black
446 M Pat Partridge
658 F Sarah Cyan
164 M Brian Snail
209 M James White
306 F Lisa Green
ID Gender Name
101 M John Smith
292 F Jane Jones
139 M Peter Black
446 M Pat Partridge
658 F Sarah Cyan
164 M Brian Snail
209 M James White
306 F Lisa Green
ALL
슬라이스 내에서 (on disk), 데이터는 Sort Key를 기반으로 정렬
쿼리에서 가장 빈번하게 사용되는 것을 Sort Key로 사용
Sort key 적용 시 Redshift 가 전체 블록을 읽는 것을 피할 수 있음
데이터 정렬 (Sorting Data)
SELECT COUNT(*) FROM LOGS WHERE DATE = ‘09-JUNE-2013’
MIN: 01-JUNE-2013
MAX: 20-JUNE-2013
MIN: 08-JUNE-2013
MAX: 30-JUNE-2013
MIN: 12-JUNE-2013
MAX: 20-JUNE-2013
MIN: 02-JUNE-2013
MAX: 25-JUNE-2013
정렬되지 않은 테이블
MIN: 01-JUNE-2013
MAX: 06-JUNE-2013
MIN: 07-JUNE-2013
MAX: 12-JUNE-2013
MIN: 13-JUNE-2013
MAX: 18-JUNE-2013
MIN: 19-JUNE-2013
MAX: 24-JUNE-2013
정렬된 테이블
Sort Key 와 Zone Map
쿼리, 데이터 로딩시 시스템은 컬럼의
너비를 기반으로 버퍼 할당
필요치 보다 넓은 칼럼을 사용하면
그만큼 메모리가 낭비
더 적은 양의 Row가 메모리에 적재
쿼리 수행시 다른 디스크까지
스캔범위 확장
할당된 공간
실제 필요공간
테이블의 컬럼 크기는 가능한 적게(딱 맞게)
다량의 삭제, 데이터 로드, 업데이트 등을 수행한 후 전체 또는 일부 테이블 들에
대한 클렌징 작업 – Sorting 과 Reclaim
http://docs.aws.amazon.com/redshift/latest/dg/t_Reclaiming_storage_space202.html
Vacuuming Tables
VACUUM 은 I/O 부담이 큰 작업으로 시간이 오래 걸릴수 있음
VACUUM 의 영향을 최소화하는 방법:
VACUUM 을 주기적으로 수행
테스팅용 테이블 들을 TRUNCATE 또는 DROP
VACUUM 대신 Deep Copy 사용
데이터를 정렬된 순서로 로딩하여 VACUUM 최소화
Vacuum
Deep Copy
VACUUM 의 대체수단으로 더욱 효율적임
Deleted row 들을 정리하고, 테이블 재 정렬(re-sort) 수행
실행중에는 테이블을 업데이트 할 수 없음(VACUUM은 가능)
Workload Management (WLM)
워크 로드의 특성에 따라 다른 큐를 생성하여 해당 사용자(그룹)에 할당
User Group A
Short-running queueLong-running queue
Short Query Group
Long Query Group
Trouble Shooting/System Maintenance
Super User Q Default queue
큐 단위로 쿼리의 병렬 수행을 보장
메모리의 할당 지정 가능
특정 사용자 또는 그룹에 의한 클러스터 점유 방지
최대 쿼리 실행 시간 지정 가능
쿼리의 병렬처리 수의 증가가 항상 성능 향상으로 이어지지는 않음
Workload Management (WLM) 사용효과
Using the Console for Query TuningConsole을 이용하여 쿼리 튜닝- Query Plan
Open Source Tools
• https://github.com/awslabs/amazon-redshift-utils
• Admin Scripts
• Collection of utilities for running diagnostics on your cluster.
• Admin Views
• Collection of utilities for managing your cluster, generating schema DDL, etc.
• Column Encoding Utility
• Gives you the ability to apply optimal column encoding to an established schema with data already loaded.
• Analyze and Vacuum Utility
• Gives you the ability to automate VACUUM and ANALYZE operations.
• Unload and Copy Utility
• Helps you to migrate data between Amazon Redshift clusters or databases.
데이터 로딩
AWS CloudCorporate Data center
DynamoDBAmazon S3
Data VolumeAmazon Elastic
MapReduceAmazon RDS
Amazon Redshift
Amazon
Glacier
logs / files
Source DBs
VPN
Connection
AWS Direct Connect
S3 Multipart Upload
AWS Import/ Export
Amazon Redshift 데이터 로딩 방법들
1. S3 – 병렬적인 데이터 로딩 지원
2. Dynamo DB – Copy명령어를 통해 DDB Table로딩
3. EMR - Copy명령어를 통해 병렬 로딩 지원
4. Remote호스트에서 데이터 로딩 - EC2등의 호스트에 ssh접속
복수의 호스트에 개별적인 연결 후, 병렬 로딩 지원
데이터 업로드를 지원하는 AWS 서비스들
1. Redshift에 적재할 데이터를 S3로 업로드
1) multi-part upload
2) import/export service (현재 서울리전 미지원)
3) direct connect
2. Redshift 로 한번에 하나에 테이블씩 COPY수행
3. 파트너 ETL 도구
S3 데이터 로딩 – 신규 데이터
1. 소스 시스템의 변경 사항 확인
2. Amazon S3로 데이터 이동
3. 변경사항 로딩
1) ‘Upsert process’
2) 파트너 ETL 도구
S3 데이터 로딩 - 변경사항 로딩
Upsert Process
새로 추가된 Row들을 삽입하고, 변경된 Row들을 업데이트
임시 Staging 테이블로 데이터 로딩
Staging을 Production 과 조인한 후 중복 Row들을 삭제
새로운 데이터들을 Production에 로딩
Data loading options
AWS Cloud고객 데이터센터
ETL
Source DBs
Amazon Redshift
Amazon Redshift
Redshift 파트너 ETL 도구 사용
COPY 명령어
새로운 테이블에 데이터 로딩시 COMPUPDATE ON 사용
각각의 슬라이스는 한번에 하나의 파일을 로딩
소스 파일을 쪼개서 각각의 슬라이스가 병렬로 처리 가능하도록 준비
Manifest 파일 사용
처리량을 높이기 위해서는 소스를 여러개로 분할
COPY 명령어 사용
각각의 슬라이스는 한번에 하나의 파일만 로딩
하나의 입력 파일만 있다면 하나의 슬라이스만
데이터 Ingesting작업 수행
100MB/s 대신 오직 6.25MB/s만 사용
DW1.8XL Compute Node
단일 입력파일
COPY 명령 사용
입력 파일의 개수를 최소 슬라이스의 총 개수
만큼 분할
예시) 16 입력 파일이 있다면 모든 슬라이스가
작업을 수행하며 처리량이 극대화 됨
노드당 100MB/s 처리량
노드 추가시 선형적으로 처리량 증가
16 입력파일
DW1.8XL Compute Node
처리량을 높이기 위해서는 소스를 여러개로 분할
파일 분할 예시
https://aws.amazon.com/ko/blogs/korea/fast-data-loading-for-amazon-redshift/
* Split 명령을 통한 소스파일 분할
Slice 0
Slice 1
Slice 0
Slice 1
Node 0
Node 1
2 dc1.large nodes
mydata
Client.txt.1
Client.txt.2
Client.txt.3
Client.txt.4
분할된 입력 파일
copy customer from ‘s3://mydata/client.txt’credentials ‘aws_access_key_id=<your-access-key>; aws_secret_access_key=<your_secret_key>’
delimiter ‘|’
• MANIFEST 를 특정 데이터 파일의 copy 에 지정
{
"entries": [
{"url":"s3://mybucket-alpha/2013-10-04-custdata", "mandatory":true},
{"url":"s3://mybucket-alpha/2013-10-05-custdata", "mandatory":true},
{"url":"s3://mybucket-beta/2013-10-04-custdata", "mandatory":true},
{"url":"s3://mybucket-beta/2013-10-05-custdata", "mandatory":true}
]
}
Manifest 파일을 통해 입력 파일 지정
* Json 파일형식
copy customerfrom 's3://mybucket/cust.manifest' credentials '<aws-auth-args>' manifest;
Copy 명령을 통해 빈 테이블에 데이터 로딩시 (COMPUPDATE ON상태)
100,000 정도의 Row를 로딩하고 최적의 인코딩 확인
해당 샘플링 데이터 삭제 후, 인코딩 타입 적용 후 전체 테이블 재 업로드
정기적으로 ETL 을 수행하거나, temp 또는 staging 테이블 사용시 자동 압축 Off
수동으로 인코딩 타입 선정시 Analyze compression 수행
COPY nations FROM 's3://.......'
COMPUPDATE OFF;
자동 압축 (Automatic Compression)
쿼리 옵티마이저는 최신 Statistics 정보 활용
데이터 로딩시 stats 를 업데이트를 통해 쿼리 성능 최적화
데이터 로딩시 같은 구조의 데이터가 계속 로딩될 때에는
사용하지 않는 것을 권장
COPY nations FROM 's3://.......
COMPUPDATE OFF
STATUPDATE OFF;
데이터 로딩 후 sort/dist key 칼럼 분석(Analysis)
기존 테이블에 대한 잦은 추가, 삭제, 변경 작업 후엔Analyze 명령 실행
데이터 로딩 자동화 옵션
EC2인스턴스에서 스크립트를 사용하여 Redshift로 데이터 로딩
Amazon Data Pipeline 사용 – 사전 정의된 템플릿 사용 및 수동 구성
(서울리전은 추후 지원예정)
AWS Lambda 기반의 Amazon Redshift 로더 사용
파트너 ETL 솔루션 사용
데이터 로딩 자동화
데이터 파이프라인 서비스를 통한 자동화
작업 생성작업 설정
완료작업 확인각 단계별 결과확인
Lambda 기반 Redshift 로더 사용
S3 -> (Lambda+DDB) -> Redshift
로딩되는 파일을 DDB에 기록하여 중복
로딩 방지
Github에 Lambda Loader제공
https://github.com/awslabs/aws-lambda-redshift-loader
S3입력1 S3입력2 S3입력n
AWS Lambda DynamoDB
Redshift Redshift
Table 1 Table 2 Table N
입력 파일 분할
column encoding을 수동으로 생성
Statistics 계산(분석)을 줄임
sort key를 기반으로 데이터 로딩
SSD 인스턴스 사용
빈번한 데이터 로딩시 유의사항
Data Loading Best Practices
COPY 명령어 사용하여 데이터 로딩
단일 COPY명령 사용
입력 데이터를 여러 개의 파일로 나눠 슬라이스 활용 극대화
데이터 파일을 GZIP으로 압축
Sort Key기반으로 로딩하여 Vacuum 최소화
데이터에 유의미한 변경 작업후에는 ANALYZE 명령어를 사용
하여 테이블에 대한 최신 Statistics 유지
백업 및 복구
Amazon S3로 자동으로 증분 백업 데이터 저장
시스템 스냅샷에 대한 유지기간 설정(1~35일)
필요에 따라 사용자가 수동으로 Snapshot 생성
Streaming restore 기능 지원으로 클러스터가
만들어지면 즉시 쿼리 수행 가능
(데이터는 백 그라운드에서 복제 진행)
백업 및 복구
자동수행증분 백업
스냅샷
스냅샷 복원(클러스터 All 또는특정 Table만 복원)
업그레이드 및 확장
온라인 중에 Resizing 실행 (But, Read Only 모드로 전환)
백그라운드 에서 새로운 클러스터 프로비전닝
데이터는 노드 간 병렬로 복제 수행
소스 클러스터에 대한 비용만 발생
DNS변경으로 원본 클러스터에서
신규 클러스터로 SQL 엔드 포인트 변경
콘솔을 통한 리사이징 실행
REDSHIFT 데이터 활용
Data Integration
RedshiftOLTP ERP Reporting & BIRDBMS
JDBC/ODBC
Business Intelligence & Visualisation 솔루션
https://aws.amazon.com/redshift/partners/
https://aws.amazon.com/marketplace/redshift
AWS Marketplace
감사합니다
Redshift로데이터웨어하우스구축경험담
Hoseok Danny Ryu
MangoPlate/CTO
Time : 17:20 – 17:30
망고플레이트 소개
사람들이맛있는곳을쉽고빠르게찾을수있도록도
와주는서비스[ ]
망고플레이트의 성장
누적다운로드: 250만+
MAU : 180만+
월간 페이지뷰: 2000만+
현재
망고플레이트에서는 어떤 분석을 하고 있을까?추천 및 분석
• Recommendation Engine • Restaurant to Restaurant Similarity 계산• User to User Similarity 계산• User to Restaurant Similarity 계산
• Fraud Detection • Fake review/user Identification • User/Review/Picture Scoring • Restaurant Rating
• User Behavior 분석• Web/App user mapping • Retention queries • User segmentation/testing
서비스성장에따른 Pain Point들
• 서비스 성장에 따라 기존 시스템으로 계산 시간이 점점 오래 걸림
• 추천 및 Rating 알고리즘 고도화로 분석 Query 가 복잡해짐
• 분석하고 싶은 데이터가 모두 흩어져 있음
• 이 모든걸 해결하고 싶지만
• Back-end 개발자 2명
• Data Scientist 1명
Redshift로 데이터웨어하우스를 구축왜 Redshift를 선택 했을까
• SQL에 능숙한 Data Scientist 와 Growth Hacking 팀
• 문서가 정리 잘 되어 있음http://docs.aws.amazon.com/redshift/latest/dg/c_loading-data-best-practices.html
[ ]Redshift: 클라우드에서 실행되는 신속하고 강력한 페타바이트 규모의 SQL기반 데
이터 웨어하우스 서비스
Redshift로데이터웨어하우스를구축장점
• 쉽게 Petabyte 규모까지 Scale 가능
• 빠른 계산 속도
• 저렴한 가격• dc1.large의 경우 월 20만원으로 시작 가능
• 표준 SQL 지원 및 다양한 Analytics Function 지원
현재의 Architecture모든 데이터를 한곳에
무엇이좋아졌을까요?Happy 한 Growth Hacking 팀
Before… After…
• 이 데이터는 어디서 뽑나요?
• 이거는 어떻게 합쳐요?
• 쿼리 안끝나는데요,,
오늘의 데이터 분석을 마치고!!
무엇이좋아졌을까요?분석 속도 개선
• Algorithm queries• Restaurant Similarity: 600 초 > 80 초 (7.5배)• Restaurant/User Recommendation: 720 초 > 80 초 (9배)
• Retention queries• Base Table: 1200 초 > 60 초 (20배)• Main: 2400 초 > 200 초 (12배)
무엇이좋아졌을까요?분석 Query들의 단순화
• Analytic function(window function) 들 적용• median, dense_rank, • ntile, stddev_samp/stddev_pop
• JSON function들을 이용하여 쉽게 로그테이블 사용• Json_extract_path_text• json_extract_array_element_text
망고플레이트추천분석시스템의 Next Step더 다양한 데이터를 실시간으로 수집!!
http://www.mangoplate.com/career
감사합니다
Managed Service by
Amazon Redshift Adoption in JapanCustomer Case Studies
Jun Okubo
Principal Business Development Manager, Database Services
Amazon Web Services Japan
Time : 17:30 – 17:50
”
“
NTT DOCOMO Speeds Data Analysis Using AWS
NTT DOCOMO is Japan’s largest mobile service
provider, serving more than 68 million customers.
Analytical queries are ten
times faster in Amazon
Redshift than they were with
our previous data warehouse.
• Needed to improve the performance of its data
analysis system.
• Moved its web service systems and corporate
applications to AWS and its data analysis platform to
Amazon Redshift.
• Delivers analytical data to data science team ten
times faster.
• Reduces time to add new data sources from several
months to less than one month.
• Meets security requirements and scales on demand.
Yuki Moritani
Manager, Innovation Management Department,
NTT DOCOMO, Inc.
”
“
Amazon Redshift Adoption in Japan
Customer Case Studies
Case #1: NTT DOCOMO – System Diagram
Data Source Extract
/Transform
Direct
Connect
Client
Forwarder
LoaderState Mgmt
SandboxRedshift
S3
• Data is generated by
systems on premise, a
nd ingest petabyte-class data into Amazon
Redshift to perform an
alytics
• Using redundant AWS Direct Connect for fast connection
• Comply with strict sec
urity requirements by l
everaging Amazon V
PC, VPN, data encryp
tion in flight and at res
t, Amazon CloudTrail, and database audit
Amazon Redshift Adoption in Japan
Customer Case Studies
Case #2: Skylark Has Improved Marketing Activities
• Challenges
• It took several hours to run analytics jobs in detailed (itemized) level.
• Difficult to have precise analysis results because they could run hypothesis testing cycle few times in a week.
• How Did They Improve?
• Built a new data analytics platform in just 1 month
• Adopt AWS for mobile applications for security and availability; built the 1st app in just 2 months
Req
uirem
en
ts
Performance
Ease of Use (Easy to build analytics environment)
Cost (Compute Resources, Administration)
Amazon Redshift + Tableau
Case #2: Skylark Has Improved Marketing Activities
• Effects & Achievements
• Improved ROI of marketing campaigns
• Campaign A：Achieved 4x net income
• Campaign B：Increased few hundreds thousand $ revenue
• Included customers’ favors to analytics, they are able to run marketing activities (such as personalized ad, coupons); this leads to 4x productivity
TransferPOS Data
Owned DC
AmazonRedshift(DWH)
Amazon S3(Collection)
Amazon EC2(Analytics)
Analyze Big Datain few ~ tens of
seconds
Feedback
HQ(Marketing Div.)Revenue Forecasting,
Campaign EffectMeasurement
Restaurants(3,000)Staffing, Procurement, Marketing Campaigns
HQRestaurant
Amazon Redshift Adoption in JapanCustomer Case Studies
Amazon Redshift Adoption in Japan
Customer Case Studies
Case #3: MUJI Uses Redshift for Omni-channel
• Challenges
• Want to increase retail store visitors
• Want to run digital marketing activities efficiently
• How Did They Improve?
• Released a mobile application called “MUJI Passport”• Communicate with MUJI fans (=customers) both in real (retail store) and virtual (mobile application)
• Continuous and sustainable increase of retail store visitors => increase revenue
• Visualize the effect of marketing campaigns
• Implemented a scalable data analytics environment
Req
uirem
en
ts
Flexible analytics platform for behavior / purchase analysis
Scalable big data processing platform
Ad-hoc queries + storing raw data
Amazon Redshift + Tableau
Amazon Redshift Adoption in Japan
Customer Case Studies
Case #3: MUJI Uses Redshift for Omni-channel
• Effects & Achievements
• Marketing people are able to run ad-hoc queries for hypothesis verifications (try & error)
• Analyze data across POS data, EC site logs, web site logs, etc.
• Coupon (for the mobile application) usage rate was largely increased
• Identify highly / repeatedly purchased items so that MUJI could distribute discount coupons effectively
• Increased retail store visitors
• Increased revenue through MUJI Passport Points
감사합니다
