Amazon Redshift 아키텍처 및 모범사례::김민성::AWS Summit Seoul 2018

© 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved.
김민성
Solutions Architect / Amazon Web Services
Bigdata
Amazon Redshift
아키텍처 및 모범사례

“Hive 대비
50~100배 빠른 성능”
Amazon Redshift
빠른 성능 비용 효율적 데이터 레이크와의
통합
보안
$ Data lake
10011000010010101
11001010101110010
10110101100101
010100001
1/10 비용으로 빠르고, 손쉬운 확장을 지원하는 완전 관리형 DW
“210억 행과
100억행 조인에 2
시간”
“시간당 $0.25로
시작”
”년간 압축
데이터 기준 1TB에
$250~$333”
“모든 Activity에
대한 감사”
“저장부터 전송까지
전계층 암호화”
“S3 (데이터레이크) 대
한 쿼리”
”AWS 다양한 서비스
와의 유연한 통합”

Amazon Redshift
데이터레이크와의 통합
Amazon S3
데이터 레이크
Redshift Spectrum
쿼리 엔진
• Amazon Redshift에서 S3데이터에 대한
쿼리
• 다양한 포멧 지원
(CSV, ORC, Gro, Avro, Parquet)
• 빠른 쿼리 성능
• Compute과 Storage 에 대한 별도의
용량 관리
• On demand, 쿼리당 스켄 데이터에
기준한 비용 (TB 당 $5)

만약 빅데이터 분석을 처음 시작하신다면…

아키텍처 및 업데이트

Amazon Redshift 클러스터 아키텍처
• MPP 기반의 아키텍처
• Amazon S3로의 지속적엔 데이터 백업
• 리더 노드
• SQL 엔드포인트
• 메타데이터 저장소
• 병렬 SQL 쿼리 코디네이터
• 컴퓨팅 노드
• 로컬, 컬럼 기반의 스토리지
• 컴퓨팅 최적화 (DC), 스토리지 최적화 (DS)
• 데이터 로드, 백업 및 복원 주체
• 2, 16, 32개 슬라이스 (Virtual Core 당)
Redshift 클러스터
JDBC/ODBC 커넥션
리더 노드
컴퓻 노드
• 데이터 로딩
• 스트리밍 백업/복원
• 확장 스토리지
Amazon S3

새로운 고밀도 컴퓨팅 노드 – DC2
“Amazon Redshift DC1에서 DC2로 이전한
후 월간 레포트 작성이 9배가 빨라 졌습니다.”
- Bradley Todd,
Technical Architect, Liberty Mutual
NVMe SSD DDR4 Memory Intel E5-2686 v4 (Broadwell)
동일 가격에 DC1 대비 3배 높아진 I/O 성능과 30% 개선된 컴퓨팅 성능

분석 및 BI,
대쉬 보드 도구
Amazon Redshift
RESULTS CACHE
QUERY_ID RESULT
QUERY_ID RESULT
결과 캐싱 - 일초 미만의 쿼리 응답 속도
쿼리 실행 시간을 단축을 위한 쿼리 결과 메모리 케싱
• 기본 활성화 (관련 파라메터 enable_result_cache_for_session)
• 캐시 조건
• 쿼리에 사용되는 객체에 대한 액세스 권한 보유
• Redshift 쿼리 관련 파라메터 및 조회하는 테이블내
데이터의 미변경
• 쿼리 실행 시마다 실행해야 하는 함수 (예: GETDATE)
미사용
• 리더 노드 사이즈 및 쿼리 결과 크기를 기준으로 캐싱
• 세션에 관계 없이 캐쉬 조회
• SVL_QLOG 뷰의 “source_query”항목을 통해 확인

단기 쿼리 가속화 Short Query Acceleration (SQA)
Amazon Redshift
Machine Learning Class
ifier
머신 러닝분석 및 BI,
대쉬 보드 도구
• 머신 러닝 알고리즘을 기반으로 단기 쿼리 판단
• 장기 쿼리뒤에서 단기 쿼리가 대기하지 않도록 SQA
전용 큐에서 단기 쿼리 실행
• SQA 조건
• GUI에서는 WML의 총 슬롯 수가 15개 이하여야 함
(CLI, API를 통해 SQA를 활성화 한 경우 해당 없음)
• CTAS 및 읽기 전용 쿼리에 사용
• 기본값은 5초 (권장), 최대 20초까지 설정
• ‘STL_WLM_Query’의 ‘service_class’ 컬럼값이 14인
쿼리가 SQA를 통해 Acceleration된 쿼리 문이며,
‘final_state’를 통해 ‘Completed’ 또는 ‘Evicted’ 여부를
확인할 수 있음
장기 쿼리로 인한 체감 성능 저하 완화 및 동시성 확보

노드 선택의 기준
• DC 또는 DS
• IO Latency 요구 사항 및 필요 스토리지 용량
• 노드의 사이즈
• 쿼리의 수행 패턴 (Slice Level, Node Level)
• Slice Level vs Node Level
• Broadcast
• 결과 캐싱 사용 여부
• 리더 노드 전용 함수 및 최종 Sorting,
Aggregation (집계) 의 사용
• 최신 세대의 노드
리더 노드 전용 함수
날짜 함수
• AGE
• CURRENT_TIME
• CURRENT_TIMESTAMP
• LOCALTIME
• ISFINITE
• NOW
문자열 함수
• ASCII
• GET_BIT
• GET_BYTE
• SET_BIT
• SET_BYTE
• TO_ASCII

노드 타입 및 클러스터 사이즈 변경
1. 기존 클러스터를 Read Only 모드로 변경
2. 변경된 노드 수량 및 노드 타입에 맞춰 신규 클러스터 생성
3. 클러스터의 데이터를 신규 클러스터로 병렬 전송
4. 기존 클러스터의 SQL Endpoint 변경 (DNS 활용)
5. 기존 클러스터 제거

데이터 및 스키마 모델링

Columnar 스토리지
ID Date Amount Handling Items State Payment
1 10/1/2013 $53.50 5 1 VA Visa
2 10/1/2013 $100.25 8 3 MD MC
3 10/2/2013 $25.50 3 1 VA Debit
4 10/2/2013 $150.75 6 10 NC Visa
5 10/2/2013 $99.90 3 4 PA ACH
6 10/3/2013 $75.85 7 7 MD Visa
주문 테이블 (Order Table)
“Select ID, Amount, State from Order”
“ROW 스토리지”
“Columnar 스토리지”

Columnar 스토리지
“적절한 크기의 데이터형
선언을 통한 성능 향상”
• Redshift는 쿼리 수행 및 데이터 Ingestion시 선언된 Column의
크기를 기반으로 버퍼 준비
• 실 데이터 보다 큰 자료형은 메모리의 낭비를 가져올 수 있음
• SVV_TABLE_INFO 테이블의
‘max_varchar’을 통해 가장
큰 열을 확인

스키마 디자인
Star Snowflake

테이블 분산 스타일
분산 키 전체 (All)
Node 1
Slice 1 Slice 2
Node 2
Slice 3 Slice 4
Node 1
Slice 1 Slice 2
Node 2
Slice 3 Slice 4
모든 데이터를를
각 노드에 전부
동일 키는 동일한 위치에
Node 1
Slice 1 Slice 2
Node 2
Slice 3 Slice 4
균등
라운드 로빈

분산키에 따른 데이터 분산
Node 1
Slice 1 Slice 2
Node 2
Slice 3 Slice 4
user_profile
user_id=1234
name=janet
…
user_profile
user_id=6789
name=fred
…
cloudfront
uri = /imgs/ad1.png
user_id=2345
…
user_profile
user_id=2345
name=bill
…
cloudfront
uri=/games/g10.exe
user_id=4312
…
user_profile
user_id=4312
name=fred
…
order_line
order_line_id = 25693
…
“분산키는 레코드가 어느 슬라이스에 저장되게 될지를 결정함”
cloudfront
uri = /games/g1.exe
user_id=1234
…
cloudfront
uri = /img/ad_5.img
user_id=1234
…
테이블에서 동일 분산키를 갖
는 레코드는 동일 슬라이스
에 저장

분산키에 따른 데이터 분산
Node 1
Slice 1 Slice 2
cloudfront
uri = /games/g1.exe
user_id=1234
…
user_profile
user_id=1234
name=janet
…
cloudfront
uri = /imgs/ad1.png
user_id=2345
…
user_profile
user_id=2345
name=bill
…
order_line
order_line_id = 25693
…
cloudfront
uri = /img/ad_5.img
user_id=1234
…
다른 테이블의 레코드의
경우에도 동일한 분산키를
사용하는 경우
동일 슬라이스에 저장
Node 2
Slice 3 Slice 4
user_profile
user_id=6789
name=fred
…
cloudfront
uri=/games/g10.exe
user_id=4312
…
user_profile
user_id=4312
name=fred
…
테이블에서 동일 분산키를 갖
는 레코드는 동일 슬라이스
에 저장
“분산키를 통한 조인 연산에 대한 데이터 지역성 확보”

데이터 분산 여부의 판별
• 적절한 분산 처리
• Broadcast 발생
DS_DIST_NONE, DS_DIST_ALL_NONE
DS_BCAST_INNER, DS_DIST_BOTH

네트워크 Broadcast
DS_DIST* INFO
DS_DIST_NONE Preferred, no data transfer between nodes.
DS_DIST_ALL_NONE One table has DISTSTYLE ALL, no data transfer between nodes.
DS_DIST_ALL_INNER Inner table is being sent to the Single Node.
DS_DIST_INNER Inner table is being redistributed in an outer join.
DS_DIST_OUTER Outer table is being redistributed in an outer join.
DS_BCAST_INNER Inner table is being broadcast to all nodes.
DS_BCAST_BOTH Both tables are being broadcast to all nodes.
쿼리 수행에 있어 네트워크를 통한 데이터이동은 가장 비용이 비싼 오퍼레이션

데이터 분산과 분산 키
Node 1
Slice 1 Slice 2
Node 2
Slice 3 Slice 4
cloudfront
uri = /games/g1.exe
user_id=1234
…
cloudfront
uri = /imgs/ad1.png
user_id=2345
…
cloudfront
uri=/games/g10.exe
user_id=4312
…
cloudfront
uri = /img/ad_5.img
user_id=1234
…
2M records
5M records
1M records
4M records
적절치 못한 분산키 선택은 단일 슬라이스로의 데이터 쏠림 현상을 초래

데이터 분산과 분산 키
Node 1
Slice 1 Slice 2
Node 2
Slice 3 Slice 4
cloudfront
uri = /games/g1.exe
user_id=1234
…
cloudfront
uri = /imgs/ad1.png
user_id=2345
…
cloudfront
uri=/games/g10.exe
user_id=4312
…
cloudfront
uri = /img/ad_5.img
user_id=1234
…
2M records2M records 2M records 2M records
균등한 데이터 분산은 쿼리 성능 향상에 도움이 됨

적절한 분산키의 선택
• 목적
• 각 노드에 균등하게 데이터 분산
• 데이터의 이동 최소화 : Co-located Joins & Aggregates
• 분산키에 적절한 컬럼
• 가장 큰 테이블에서 조인에 활용되는 컬럼
• Group By 조건에서 사용되는 컬럼
• 높은 Cardinality를 보유한 컬럼
• 분산키에 적절치 않은 컬럼
• Where 조건절에서 활용되는 칼럼
• 데이터의 몰림을 유발하는 컬럼

팁! 분산키 어떻게 선택할까?
1. 가장 큰 Dimension Table의 Primary키와 Fact Table의 Foreign키
를 Dist Key로 선택
2. 나머지 조인이 되는 조건의 Dimension Table은 Distribution ALL
을 검토 한다.
“300만개 이하의 경우 데이터 분산 타입을 전체 (ALL)로 선택해도 무방＂

팁! 분산키 어떻게 선택할까?
1. 가장 자주 활용되는 쿼리를 확인합니다.
예 “awslabs/amazon-redshift-utils/AdminScripts/top-queries.sql” 활용 등
2. 조인 또는 Group By에 활용되며 고른 데이터 분포 및 높은 Cardinality 보유한 컬럼
을 선택 합니다.
3. 그게 아니라면….
“Fact Table은 Even으로 Dimension Table은 ALL로”
“참고 : MPP 형태의 스키마는 테이블 내에
모든 데이터를 보유하기 때문에 Distribution style 은 Even으로“
“3정규화 형태의 Inmon 모델은 노드 수량은 줄이고
노드 크기는 키우거나 Star Schema로 전환＂

데이터 정렬

성능 향상
1. 보다 높은 하드웨어 스펙
2. 병렬화의 달성
3. 네트워크를 통한 트레픽의 최소화
“스토리지 I/O의 최소화”

SELECT COUNT(*)
FROM LOGS
WHERE DT = ‘09-JUNE-2015’
• Zone Map : 각 Block에 대한 최대값 및 최소값에 대한 정보 저장
Zone Map과 정렬

정렬 키
• 정렬 키가 지정된 테이블의 경우 데이터 로드시 정렬 순서대로 디스크에
저장
• 정렬키의 종류
• 정렬 키: 테이블의 단일 컬럼의 값을 기준으로 데이터를 정렬하여 저장
• 복합 정렬키 (Compound Sort Key):
• 다수의 컬럼을 활용 (최대 6개) 활용하여 정렬 키로 활용
• 선언한 순서에 따라 순차적으로 정렬되어 저장됨
• 조인 및 Group By, Order By에 효과적이며, 특히 사전에 순서대로 정렬이 되어 있기 때문에 Merge 조인에
효과적
• 인터리브 정렬키 (Interleaved Sort Key)
• 다수의 컬럼을 활용 (최대 8개) 활용하여 정렬 키로 활용
• 정렬 키에서 각 열, 즉 열의 하위 집합에 똑같은 가중치를 부여
• AD-Hoc 형태의 쿼리에서 높은 성능을 제공함

복합 정렬 키 vs 인터리브 정렬 키
• 키 선언 : Product (type, color, size)
• 복합 정렬키 type, color, size
• Where type = ‘shirt’ and color=‘red’ and size = ‘xl’: 정렬을 기반한
가장 우수한 성능
• Where type = ‘shirt’ and color=‘red’: 약간 효과적
• Where type = ‘shirt’ and size = ‘xl’: 제한적으로 성능에 기여함
• 인터리브 정렬키 type, color, size
• 조회시 type, color, size 순서등에 관계 없이 일관성 있는 성능 제공

그리고…

쿼리 분석
EXPLAIN 커맨드와 실제 쿼리 수행:
EXPLAIN은 쿼리 수행과 관련된 정보
• 수행된 오퍼레이션 및 그에 대한 비용
• 쿼리에 사용된 테이블 및 컬럼 정보
• 프로세싱에 사용될 데이터의 크기
참고 : https://docs.aws.amazon.com/redshift/latest/dg/c-the-query-plan.html
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)

파일 분산 및 병렬 로딩
client.aa
client.ab
client.ac
client.ad
Node 0
Slice 0
Slice 1
Node1
Slice 0
Slice 1
{
"entries": [
{"url":"s3://mybucket-alpha/client.aa", "mandatory":true},
{"url":"s3://mybucket-alpha/client.ab", "mandatory":true},
{"url":"s3://mybucket-beta/client.ac", "mandatory":true},
{"url":"s3://mybucket-beta/client.ad", "mandatory":true}
]
}
매니페스트 파일
copy customer
from 's3://mybucket/cust.manifest'
iam_role 'arn:aws:iam::0123456789012:role/MyRedshiftRole'
manifest;
Copy 커멘트를 통한 실행

기타
• Vacuum
• 변경되거나 삭제된 블럭에 대한 정리
• 정렬키에 맞춰 데이터 정렬
• 옵션 : FULL, SORT ONLY, DELETE ONLY, REINDEX (인터리브 정렬키)
• 통계 업데이트
• 통계 업데이트 자동 실행
• CREATE (TEMP) TABLE AS SELECT
• SELECT INTO
• COPY (with COMPUPDATE ON)
• 통계 업데이트를 실행해줘야 하는 경우
• 기존 데이터의 5%이상에 대해 변경이 있는 경우
• 외례키를 추가하거나 삭제한 경우
• Vacuum 실행 후
• 제약 조건 (not null, primary, foreign, unique)은 쿼리 옵티마이저가 활용

S3 데이터레이크와 통합
Amazon Redshift Spectrum

Redshift Spectrum
S3의 수천개 이상의 노드들을 활용하여 쿼리 실행
Fast @ exabyte scale Elastic & highly available On-demand, pay-per-query
High concurrency: Multiple clusters
access same data
No ETL: Query data in-place using open
file formats
Full Amazon Redshift
SQL support
S3
SQL

데모 아키텍처

SELECT
c.c_name,
c.c_mktsegment,
t.prettyMonthYear,
SUM(uv.adRevenue)
FROM
clickstream.uservisits_csv10 as uv
RIGHT OUTER JOIN
customer as c
ON c.c_custkey = uv.custKey
INNER JOIN
(
SELECT
DISTINCT d_yearmonthnum,
(d_month||','||d_year) as prettyMonthYear
FROM
dwdate
WHERE
d_yearmonthnum >= 199810
) as t
ON uv.yearMonthKey = t.d_yearmonthnum
WHERE
c.c_custkey <= 3
GROUP BY
c.c_name,
c.c_mktsegment,
t.prettyMonthYear,
uv.yearMonthKey
ORDER BY
c.c_name,
c.c_mktsegment,
uv.yearMonthKey ASC
XN Merge (cost=1141056800867.31..1141056801917.31 rows=420000 width=78)
-> XN Network (cost=1141056800867.31..1141056801917.31 rows=420000 width=78)
-> XN Sort (cost=1141056800867.31..1141056801917.31 rows=420000 width=78)
-> XN HashAggregate (cost=141056760589.25..141056761639.25 rows=420000 width=78)
-> XN Hash Join DS_DIST_ALL_NONE (cost=37.34..141056596142.86 rows=13155711 width=78)
-> XN Seq Scan on customer c (cost=0.00..3.75 rows=300 width=38)
-> XN Subquery Scan t (cost=0.00..32.82 rows=7 width=36)
-> XN Unique (cost=0.00..32.75 rows=7 width=18)
-> XN Seq Scan on dwdate (cost=0.00..32.43 rows=64 width=18)
-> XN Seq Scan PartitionInfo of clickstream.uservisits_csv10 uv (cost=0.00..10.00 rows=1000 width=0)
-> XN S3 Query Scan uv (cost=0.00..93969358.62 rows=3758774345 width=16)
clickstream.uservisits_csv10 as uv
rows=3758774345
• 결과 : 약 4분 47초
• CSV 포멧
• 파티셔닝 없음

SELECT
c.c_name,
c.c_mktsegment,
t.prettyMonthYear,
SUM(uv.adRevenue)
FROM
clickstream.uservisits_parquet1 as uv
RIGHT OUTER JOIN
customer as c
ON c.c_custkey = uv.custKey
INNER JOIN
(
SELECT
FROM
dwdate
WHERE
) as t
ON uv.yearMonthKey = t.d_yearmonthnum
WHERE
c.c_custkey <= 3
GROUP BY
c.c_name,
c.c_mktsegment,
t.prettyMonthYear,
uv.yearMonthKey
ORDER BY
c.c_name,
c.c_mktsegment,
uv.yearMonthKey ASC
-> XN Seq Scan PartitionInfo of clickstream.uservisits_parquet1 uv (cost=0.00..10.00 rows=1000 width=0)
-> XN S3 Query Scan uv (cost=0.00..93969358.62 rows=3758774345 width=16)
clickstream.uservisits_parquet1 as uv
rows=3758774345
• 결과 : 약 26초
• Parquet 포멧 (Columnar 포멧)
• 파티셔닝 없음

SELECT
c.c_name,
c.c_mktsegment,
t.prettyMonthYear,
uv.totalRevenue
FROM
((SELECT
customer,
visitYearMonth,
SUM(adRevenue) as totalRevenue
FROM
clickstream.uservisits_parquet1
WHERE
customer <= 3
and visitYearMonth >= 199810
GROUP BY
customer,
visitYearMonth) as uv
RIGHT OUTER JOIN
customer as c
ON c.c_custkey = uv.customer
INNER JOIN
(
SELECT
FROM
dwdate
WHERE
) as t
ON uv.visitYearMonth = t.d_yearmonthnum
)
ORDER BY
c.c_name,
c.c_mktsegment,
uv.visitYearMonth ASC
-> XN Subquery Scan uv (cost=93971346.13..93971346.42 rows=23 width=16)
-> XN Seq Scan PartitionInfo of clickstream.uservisits_parquet1 (cost=0.00..17.50 rows=112 width=8)
-> XN S3 Query Scan uservisits_parquet1 (cost=46984679.32..46984689.32 rows=1000 width=8)
customer <= 3
and visitYearMonth >= 199810
rows=3000000
• 결과 : 약 3초
• Parquet 포멧 (Columnar 포멧)
• 파티셔닝 : customer, visitYearMonth

EMR을 활용한 ORC, Parquet 형태로 데이터 변경
하이브 쿼리 (CREATE TABLE AS SELECT)를 통해 변경
CREATE TABLE data_converted
STORED AS PARQUET
AS
SELECT col_1, col2, col3 FROM data_source
Spark Script 활용
사례 : ELB 1TB 로그 변환
- 1TB의 ROW기반 데이터를 Parquet 변환시 130GB까지 축소 (압축 코덱 Snappy)
- EMR 비용 : 5$
참고 : https://github.com/awslabs/aws-big-data-blog/tree/master/aws-blog-spark-parquet-conversion
AWS Glue 활용

Redshift Spectrum Best Practice
• 파티셔닝 및 Columnar 파일 포맷 (ORC, Parquet) 사용
• 파티셔닝 컬럼의 조건
• 필터 및 조인의 조건이 되는 컬럼
• 비니지스 유닛
• 비니지스 그룹
• 날짜 및 시간
• 파일의 갯수는 Redshift의 Slice의 수량 이상
• 파일의 크기는 64MB 이상을 권고
• 각 파일은 동일한 크기를 권고

마무리 하며,
• Redshift 도구 모음:
https://github.com/awslabs/amazon-redshift-utils
• Redshift 커스톰 모니터링 도구:
https://github.com/awslabs/amazon-redshift-monitoring
• Amazon Redshift Column Encoding Utility:
https://github.com/awslabs/amazon-redshift-utils/tree/master/src/ColumnEncodingUtility
• Analyze & Vacuum Schema Utility:
https://github.com/awslabs/amazon-redshift-utils/tree/master/src/AnalyzeVacuumUtility
• 마이크로 배치 로딩:
https://aws.amazon.com/blogs/big-data/best-practices-for-micro-batch-loading-on-
amazon-redshift/

오늘 마무리 못한 이야기들은…
“Go Builder Theater“
Day 2 오후 3시 20분 ~ 3시 50분
Redshift 못다한 이야기

AWS Summit 모바일 앱과 QR코드를 통
해 강연 평가 및 설문 조사에 참여해 주
시기 바랍니다.
내년 Summit을 만들 여러분의 소중한 의
견 부탁 드립니다.
#AWSSummit 해시태그로 소셜 미디어에 여러분의 행사 소
감을 올려주세요.
발표 자료 및 녹화 동영상은 AWS Korea 공식 소셜 채널로
공유될 예정입니다.
여러분의 피드백을 기다립니다!

Amazon Redshift 아키텍처 및 모범사례::김민성::AWS Summit Seoul 2018

Amazon Redshift 아키텍처 및 모범사례::김민성::AWS Summit Seoul 2018

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados(20)

Similar a Amazon Redshift 아키텍처 및 모범사례::김민성::AWS Summit Seoul 2018

Similar a Amazon Redshift 아키텍처 및 모범사례::김민성::AWS Summit Seoul 2018(20)

Mais de Amazon Web Services Korea

Mais de Amazon Web Services Korea(20)

Amazon Redshift 아키텍처 및 모범사례::김민성::AWS Summit Seoul 2018