Amazon Redshift의 이해와 활용 (김용우) - AWS DB Day

Amazon Redshift 의 이해와 활용
김용우 매니저(kevkim@amazon.com)
Partner Solution Architect
Time : 16:30 – 17:50

설계 및 튜닝
개요 및 아키텍쳐
데이터 로딩
백업 및 복구
업그레이드 및 확장
데이터 활용

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 RAM
2 virtual cores
단일노드 (160GB SSD)
클러스터 2-32 노드 (320GB – 5.12TB SSD)
dc1.8xlarge 노드
244GiB RAM
32 virtual cores
클러스터 2-128 노드 (최대 326TB SSD)

작게 시작하고 크게 확장 가능 – 고용량 DW
Dense Storage Nodes - ds2.xlarge & ds2.8xlarge
ds2.xlarge 노드
31 GiB RAM
4 virtual cores
단일노드 (2TB HDD)
클러스터 2-32 노드 (4TB – 64TB HDD)
ds2.8xlarge 노드
244GiB RAM
36 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)
Ingestion
Backup
Restore
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
Dense
Compute
Dense
Storage
Amazon Redshift 아키텍쳐 – 슬라이스

Amazon Redshift 손쉽게 클러스터 운영
 데이터 백업시 전송(In Transit)/저장(At rest) 암호화 기능 제공
 Amazon S3 로 지속적인/변경 부분/자동 백업 제공
 클러스터 용량 만큼의 백업스토리지 기본제공(무료)
 타 리전으로 스냅샷 비동기 복제 기능
 Streaming restore 를 통해 빠르게 쿼리 재개 가능
 디스크 장애, 노드의 복구는 자동으로 관리됨
Clients Amazon Redshift Amazon S3
자동백업
Streaming
Restore

Amazon Redshift 는 IO 사용을 최소화 시킴
 Columnar 스토리지
 데이터 압축
 Zone maps
 개별 노드에 직접 연결된 스토리지
(Directly Attached Storage)
Row
storage
Column
storage
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
Round
Robin
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 Cyan
DISTSTYLE KEY
Hash
Function

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
DISTSTYLE KEY
Hash
Function
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
4
DISTSTYLE 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 Volume
Amazon 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 customer
from '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 엔드 포인트 변경

콘솔을 통한 리사이징 실행

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 Japan
Customer 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.
”
“

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-cl
ass data into Amazon
Redshift to perform an
alytics
• Using redundant AWS
Direct Connect for fas
t 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

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
Requirements
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
Transfer
POS Data
Owned DC
Amazon
Redshift
(DWH)
Amazon S3
(Collection)
Amazon EC2
(Analytics)
Analyze Big Data
in few ~ tens of
seconds
Feedback
HQ(Marketing Div.)
Revenue Forecasting,
Campaign Effect
Measurement
Restaurants(3,000)
Staffing, Procurement,
Marketing Campaigns
HQ
Restaurant

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
Requirements
Flexible analytics platform for behavior / purchase analysis
Scalable big data processing platform
Ad-hoc queries + storing raw data
Amazon Redshift + Tableau

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

Amazon Redshift의 이해와 활용 (김용우) - AWS DB Day

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Amazon Redshift의 이해와 활용 (김용우) - AWS DB Day

Similar to Amazon Redshift의 이해와 활용 (김용우) - AWS DB Day (20)

More from Amazon Web Services Korea

More from Amazon Web Services Korea (20)

Amazon Redshift의 이해와 활용 (김용우) - AWS DB Day