20130716 aws meister re:generate - amazon redshift (korean)

Amazon Redshift

[AWS Meister – re:Generate] 웨비나 시리즈 발표자료 작성: 八木橋徹平 솔루션스 아키텍트

번역: 정윤진 솔루션스 아키텍트

이 자료의 내용은 웨비나가 진행된 2013년 07월 16일에 맞춰져 있어 현재의 내용과는 다를 수 있습니다. 내용에 대한 문의사항이 있으신 경우 [email protected]으로 연락 주시기 바랍니다.

mailto:[email protected]



© 2012 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified or distributed in whole or in part without the express consent of Amazon.com, Inc.

2

Agenda

Amazon Redshift 란?

Amazon Redshift 의 관리

테이블 설계 및 데이터 로드

튜닝 포인트

정리


3

Agenda




튜닝 포인트

정리


4

AWS 의 다양한 서비스들 응용 프로그램

인증 AWS IAM

모니터링 Amazon

CloudWatch

Web Management

Console

배포 및 자동화 AWS Elastic Beanstalk AWS Cloud Formation

AWS OpsWorks

IDE 플러그인 Eclipse

Visual Studio

라이브러리 & SDKs Java, PHP, .NET, Python, Ruby,

node.js

Development &

Administration

AWS 글로벌 인프라 Geographical Regions, Availability Zones, Points of Presence AZ Region

네트워크 및 라우팅 Amazon VPC / Amazon Elastic Load Balancer / Amazon Route 53 /AWS Direct Connect

Infrastructure

Service

컴퓨팅 Amazon EC2

Auto Scale

스토리지 Amazon S3 Amazon EBS

Amazon Glacier AWS Storage Gateway

데이터베이스 Amazon RDS

Amazon DynamoDB Amazon ElastiCache

Amazon Redshift

컨텐츠 전송 Amazon CloudFront

메시징 Amazon SNS Amazon SQS Amazon SES

분산 처리 Elastic MapReduce

검색 엔진 Amazon Cloud Search

트랜스 코딩 Amazon Elastic Transcoder

워크 플로우 관리 Amazon SWF

Application

Service


5

AWS의 글로벌 인프라 스트럭쳐

US West (Northern

California)

US East (Northern

Virginia)

EU (Ireland)

Asia

Pacific (Singapore)

Asia

Pacific (Tokyo)

GovCloud (US ITAR

Region)

US West (Oregon)

South

America (Sao Paulo)

AWS Regions

AWS Edge Locations

• US East、US West、EU 에 이어 4번째로

Tokyo 에서 Amazon Redshift 사용이 가능 • hs1.xlarge (dw1.xlarge)、hs1.8xlarge

(dw1.8xlarge), dw2.large, dw2.8xlarge 를

사용한 클러스터 구축이 가능

Asia

Pacific (Sydney)


6

AWS 의 각종 데이터 서비스

Amazon RDS

OLTP 에 사용되는 AWS 가 관리하여 서비스로 제공되는 데이터베이스 서비스

Amazon DynamoDB

확장성이 뛰어난 고속의 NoSQL 서비스

Amazon Redshift

병렬 처리가 가능한 데이터 웨어하우징 서비스

Amazon EMR

높은 확장성을 가진 Hadoop 서비스


7

관리형 데이터베이스가 필요한 이유?

backup & recovery, data load & unload

performance tuning 25% 40%

5% 5%

scripting & coding security planning

install, upgrade, patch and migrate

documentation, licensing & training

관리가 아닌 서비스에

더 많은 노력을 집중


8

Amazon Redshift 의 개요

Data Warehouse as a Service – 분석을 위한 대량의 데이터를 저장, 쿼리가 가능한 데이터 베이스 서비스

확장성：수TB ～수PB

성능：컬럼 기반 저장, 대규모 병렬 처리(MPP)

비용：인스턴스를 사용한 만큼만 과금（초기 투자 비용, 라이센스 비용 필요없음）


9

Row 기반 vs. Column 기반

DWH 에는 컬럼 기반의 데이터베이스가 주로 사용된다

orderid name qty

1 Book 100

2 Pen 50

…

n Eraser 70

orderid name qty

1 Book 100

2 Pen 50

…

n Eraser 70

Row 기반 – 트랜젝션 처리에 유리 Column 기반 – 분석 처리 방향


10

내부 아키텍처

마스터 노드를 통해 쿼리를 수용, 각 노드에 수행할 쿼리를 전달

각 컴퓨팅 노드에서 쿼리를 병렬 실행

각 컴퓨팅 노드의 로컬 스토리지에 데이터를 유지

4개의 타입의 컴퓨팅 노드를 선택 가능

BI 도구

마스터 노드

컴퓨팅 노드

컴퓨팅 노드

컴퓨팅 노드

JDBC/ODBC

10GigE Mesh

SQL Endpoint: • 쿼리를 병렬처리 • 결과를 취합

실제 쿼리 수행 노드 • “N” 스케일 아웃 • 로컬 디스크의 사용

S3, DynamoDB, EMRとの統合


11

노드 유형 (Dense Storage)

Extra Large (XL) DW Node:

• CPU: 2 virtual cores

• ECU: 4.4

• Memory: 15 GiB

• Storage: 2TB HDD (0.30GB/s)

• API: dw1.xlarge

Eight Extra Large (8XL) DW Node:

• CPU: 16 virtual cores

• ECU: 35

• Memory: 120 GiB

• Storage: 16TB HDD (2.4GB/s)

• Disk I/O: Very High

• API: dw1.8xlarge


12

노드 유형 (Dense Compute)

Large (L) DW Node: • CPU: 2 virtual cores

• ECU: 7

• Memory: 15 GiB

• Storage: 0.16TB SSD (0.20 GB/s)

• API: dw2.large

Eight Extra Large (8XL) DW Node: • CPU: 32 virtual cores

• ECU: 104

• Memory: 244 GiB

• Storage: 2.56TB SSD (3.70 GB/s)

• Network: 10 Gigabit Ethernet with support for cluster placement groups

• Disk I/O: Very High

• API: dw.hs1.8xlarge


13

클러스터의 확장성 (dw1)

단일 노드 (2TB)

클러스터 2 ~ 32 노드 （4TB – 64TB)

클러스터 2 ~ 100 노드 （32TB – 1.6PB)

Extra Large Node (XL)

8 Extra Large Node (8XL)


14

클러스터의 확장성 (dw2)

단일 노드 (160GB)

클러스터 2 ~ 32 노드 （320GB – 5.12TB)

클러스터 2 ~ 100 노드 （5.12TB – 256TB)

Large Node (XL)

8 Extra Large Node (8XL)


15

Agenda




튜닝 포인트

정리


16


자동화 or 최소한의 관리 작업

• Amazon Redshift 는 관리가 거의 필요하지 않다

• 예：

• 클러스터의 생성, 크기 조절 및 복원 – Management Console에서

가능

• 재해 복구 – 노드의 자동 프로비저닝, 데이터 복구

데이터 내구성

• 모든 데이터는 로컬 디스크에 저장되고 다른 노드에 미러링

• 각 노드는 여러개의 디스크로 구성됨

• Amazon S3 에 자동 or 수동 스냅샷 저장


17

클러스터 작성의 사전 준비

Classic-EC2 또는 VPC 내에 클러스터 생성이 가능

VPC 에 생성하는 경우,「Cluster Subnet Group」을 사전에 생성해 줄 필요가 있음

클러스터가 생성될 Availability Zone 을 사전에 지정하여 Cluster Subnet Group 생성


18

클러스터 생성（１）

Amazon Redshift 관리 메뉴에서 「Launch Cluster」클릭 후 정보를 입력

클러스터 이름

데이터베이스 이름

데이터베이스 포트

관리 사용자 이름


19

클러스터 생성（２）

노드 유형 및 클러스터의 크기를 선택

Dw 인스턴스 유형을 선택

클러스터의 형태 (단일/클러스터)

필요한 노드의 수량


20

클러스터의 생성（３）

보안을 위한 네트워크 환경 설정

데이터 베이스의 암호화 여부

VPC 를 선택 Cluster Subnet Group 을 선택

Security Group の指定 • 최종으로「Launch Cluster」를 클릭하면

Redshift 클러스터 생성을 시작!!!


21

클러스터의 크기 조정

클러스터의 크기 변경이 필요한 경우 매우 쉽게 적용이 가능


22

Agenda




튜닝 포인트

정리


23

테이블 디자인

최적의 SORTKEY 선택 • SORTKEY 에 따라 데이터를 디스크에 순차적으로 저장

• 쿼리 옵티마이저는 SORTKEY 에 따라 실행계획을 구축

최적의 DISTKEY 선택 • DISTKEY 는 컴퓨팅 노드간의 데이터 배치를 결정하는데 사용

최적의 압축 유형 선택 • 다수의 압축 알고리즘에서 선택 가능

제약 조건의 정의 • 기본키 제약 조건과 외래키 제약 조건은 실행계획을 만들때 팁으로 사용됨


24

SORTKEY 선택

SORTKEY

• SORTKEY 에 따라 디스크에 데이터를 순차적으로 저장

• 쿼리 옵티마이저는 정렬 순서를 고려하여 최적의 쿼리 실행

계획을 구축

Tips

• 특정 컬럼에 대해 잦은 범위 검색 또는 등식 검색이 필요한 경우

SORTKEY 로 지정

-> 검색되지 않는 블록에 대한 접근을 생략하여 높은 성능을 유지

• 자주 조인하는 경우 해당 컬럼을 SORTKEY 및 DISTKEY 로 지정

-> 해시 조인 대신 정렬 병합 조인이 선택됨


25

SORKEY 예제

Orderdate 컬럼을 SORTKEY 로 지정한 경우：

2013/07/17

2013/07/18

2013/07/18

2003/07/19

…

I0001

I0002

I0003

I0004

・・・

2013/08/20

2013/08/21

2013/08/22

2013/08/22

…

I0020

I0021

I0022

I0023

orderdate … orderid

SELECT * FROM orders WHERE

orderdate BETWEEN ‘2013-08-01’ AND

‘2013-08-31’;

쿼리와 관련이 없는 데이터 블록은

건너뛰고 해당 블록만 참조


26

DISTKEY 선택

DISTKEY

• DISTKEY 는 테이블의 데이터가 어떻게 분산되어 저장될지를

결정

• 지향해야 할 목표

• 노드와 슬라이스간에 최대한 데이터를 고르게 분산 해야 함

-> 편향된 데이터의 저장은 특정 노드의 부하를 증가시켜 전체

처리성능을 지연시킬 가능성이 있음

• 조인이 필요한 경우 데이터의 전송을 최소화 하기 위한 데이터

배열을 염두

분산 방식: CREATE TABLE ~ DISTSTYLE EVEN | KEY • Even distribution：라운드 로빈의 형태로 데이터를 분산

• Key distribution：DISTKEY 에 따라 데이터를 분산

http://docs.aws.amazon.com/redshift/latest/dg/t_Distributing_data.html


28

압축 유형 선택（２）

데이터 압축 알고리즘

• RAW：압축하지 않음

• BYTEDICT：CHAR 와 같이 고정된 크기 제한을 가지는 컬럼에 적합

• DELTA/DELTA32K：연속되는 값을 최적화（datetimes、sequence 등）

• LZO : JSON string 을 가지는 VARCHAR, CHAR 와 같이 많은 데이터를 가지는 컬럼에 유용. 높은 압축률을 자랑

• MOSTLY8、MOSTLY16、MOSTLY32：대부분의 값이 낮은 범위의 비트 숫자에 집중되는 경우 최적화

• RUNLENGTH：동일한 값이 자주 연속되는 경우 최적화

• TEXT255/TEXT32K：텍스트 내의 단어 사전을 이용

http://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html


29

데이터 압축의 예

Orderdate 컬럼에 DELTA 인코딩을 적용：

2013/08/20

2013/08/21

2013/08/22

2013/08/22

…

I0020

I0021

I0022

I0023

orderdate … orderid

2013/08/20

1

1

0

…

I0020

I0021

I0022

I0023

레코드가 저장될때 4바이트 DATE 형태로 저장되는 것이 아니라 이전 레코드와 차이를 나타내는 숫자로 저장된다.

주의: 이 내용은 개념을 설명하기 위한 것이며, 실제 사용시에는 테이블 생성 이후 인코딩의 변경은 불가능


30

제약 조건의 정의

기본키와 외래키 제약 조건은 어디까지나 정보로만

간주됨

쿼리 플래너가 실행 계획을 만들때 힌트로 사용

주의 사항

• 플래너는 제약이 정의 되어있는 경우 항상 데이터가 타당하다고

인식 (예: 고유 및 외래키로 참조 가능)

• 일관성이 없는 데이터는 잘못된 쿼리 결과를 반환 할 수도 있다

• 데이터의 유효성이 확실한 경우에만 제약 조건을 정의


데이터의 로딩

31

AWS 의 다양한 서비스에서 데이터의 로딩이 가능 • Amazon S3 에서 각 노드에 병렬로 데이터를 로드

• Amazon DynamoDB 테이블의 데이터를 로드

• Amazon EMR (예정)

• 데이터 로드시 발생한 오류를 추적 가능

스타 스키마, 인덱스는 필요하지 않음

RDBMS와 비교하여 x 2 – 4 배의 압축 • 다양한 압축 알고리즘을 채용

• 자동 압축 가능


데이터의 로딩

Amazon S3 에 저장된 데이터를 COPY 를 사용하여 로딩

32

% psql --host=mydb.wetyuioop.us-east-1.redshift-

dev.amazonaws.com --port=5439 –username=admin --

dbname=mydb

mydb=# copy customer from 's3://data/customer.tbl.1'

credentials

'aws_access_key_id=XXXXYYYYZZZZ;aws_secret_acc

ess_key=abcdefghijklmn' delimiter '|';


33

Agenda




튜닝 포인트

정리


성능 조정시 고려사항

성능을 확인하는 방법

• EXPLAIN 명령의 사용, SVL_QUERY_SUMMARY, SVL_QUERY_REPORT 테이블 참조

• 쿼리 실행 계획의 분석, 필요에 따라 쿼리를 수정

얼마나 많은 자원을 소비하는지 확인하는 방법

• 쿼리 수행시 결과를 출력하기 위해 사용되는 I/O 모니터링

• 메모리 소비량을 분석

• 스키마의 재설계, SORTKEY 와 DISTKEY

쿼리가 다른 쿼리의 완료를 대기하고 있는지의 여부

• 각 쿼리의 실행 시간을 파악하고 우선 순위를 결정

• 다수의 대기열을 정의하고 여기에 쿼리를 입력

34


쿼리의 분석（１）

EXPLAIN 커맨드

EXPLAIN 을 통해 확인 할 수 있는 내용：

• 쿼리의 실행 단계

• 각 단계에서 어떠한 작업이 수행되는지

• 각 단계에서 어떤 테이블, 컬럼이 사용되는지

• 각 단계에서 얼마나 많은 데이터를 처리할 필요가 있는지

35

explain select avg(datediff(day, listtime, saletime)) as avgwait from sales, listing

where sales.listid = listing.listid;

QUERY PLAN

XN Aggregate (cost=6350.30..6350.31 rows=1 width=16)

-> XN Hash Join DS_DIST_NONE (cost=47.08..6340.89 rows=3766 width=16)

Hash Cond: ("outer".listid = "inner".listid)

-> XN Seq Scan on listing (cost=0.00..1924.97 rows=192497 width=12)

-> XN Hash (cost=37.66..37.66 rows=3766 width=12)

-> XN Seq Scan on sales (cost=0.00..37.66 rows=3766 width=12)

http://docs.aws.amazon.com/redshift/latest/dg/c-optimizing-query-performance.html


쿼리의 분석 (2)

대량의 데이터를 업데이트 한 경우에는 ANALYZE 를

사용하여 통계를 갱신. 쿼리의 실행 계획이 변경될 수도

있음

STL_EXPLAIN 테이블 참조 （이전에 실행된 쿼리 분석）

SVL_QUERY_SUMMARY 와 SVL_QUERY_REPORT 에

더 자세한 정보가 포함되어 있으므로 참조 36

analyze lineitem;

select query,nodeid,parentid,substring(plannode from 1 for 30),

substring(info from 1 for 20) from stl_explain

where query=10 order by 1,2;

query | nodeid | parentid | substring | substring

------+--------+----------+---------------------+---------------------

10 | 1 | 0 | XN Aggregate (cost=6350.30... |

10 | 2 | 1 | -> XN Merge Join DS_DIST_NO | Merge Cond: ("outer"

10 | 3 | 2 | -> XN Seq Scan on lis |

10 | 4 | 2 | -> XN Seq Scan on sal |


쿼리의 분석（３）

Management Console 에서 확인

• 각 쿼리의 내용 및 부하정도를 확인 가능

37


Workload management（１）

장기간 실행되는 쿼리는 단기 실행 쿼리를 대기열에

기다리게 할 수 있다.

예기치 않은 성능 열화에 따른 사용자 경험이 저하될

가능성이 있다

기본적으로 Redshift 클러스터는 단일 큐를 가진다.

38

Running

Default queue


Workload management（２）

용어 및 개요

39

User Group A

Short-running queue

Short

Query Group

Long-running queue

Long

Query Group


다수의 큐를 생성（１）

쿼리가 다른 쿼리를 기다리고 있는지의 여부를 확인

• 단기, 장기 실행 쿼리를 식별하고 우선순위를 설정

Management Console 에서 새로운 큐를 생성

40


다수의 큐를 생성（２）

쿼리의 워크로드는 전체 컴퓨팅 노드에 분산된다.

• 쿼리 처리의 병렬화는 race condition 으로 인해 항상 (반드시)

성능이 향상되는 것은 아니다.

• 다른 많은 쿼리들을 대기 상태로 두고 오랜시간 실행중인 쿼리를

먼저 종료 시키는 것이 전체 성능 향상에 도움이 될 수 있다.

41


쿼리 할당의 예

사용자 그룹에 할당

쿼리 그룹에 할당

42

create group usergroupA;

create user userA in group usergroupA password 'Password1';

set query_group to ‘ShortQueryGroup’;

select count(*) from lineitem;

reset query_group;


43

Agenda




튜닝 포인트

정리


44

Amazon Redshift 의 장점

DW를 위한 초기 비용이 필요하지 않음 • DWH에 필요한 Disk 를 할당하고 사용한 만큼만 과금

확장성 • 필요할때 노드를 추가함으로서 데이터 저장공간의 확장이 매우 쉽다

운영과 관리가 매우 편리 • Management Console 에서 클러스터의 생성, 크기 조정, 복원 및 백업이 모두 가능


45

감사합니다. http://aws.amazon.com/ko/redshift

20130716 aws meister re:generate - amazon redshift (korean)

Documents