해당 내용은 [Amazon Redshift 아키텍처 및 모범사례::김민성::AWS Summit Seoul 2018] 에서 발표한 동영상을 보며 정리한 내용입니다.
자세한 내용은 아래 링크 가셔서 동영상과 ppt 를 보시면 더 쉬울듯 하며,
저는 공부의 목적으로 보며 정리한 내용입니다.
발표내용
- 리더 노드는 각 slice 로 실행계획에 맞춰 데이터 수집을 하라고 보내고 마지막 slice 가 끝날때까지 기다렸다가 끝난 데이터를 수집하여 제공
- slice 는 redshift 내 각 클러스터의 cpu 즉 작업을 실질적으로 하는 모듈로 이해하면 될듯
Distkey 형태
- 분산키 : key 를 가지고 각 slice 로 저장(slice 는 cpu당 개수와 동일한 개수를 가지고 있음) - group by 할 때 / key를 가지고 join 하는 경우 좋음- 각 노드에 균등하게 데이터 분산이 필요- 가장 큰 테이블에서 조인에 활용되는 컬럼- group by 조건에서 사용되는 컬럼- 높은 Cardinality를 보유한 컬럼★ 아래와 같은 현상이 발생하면 slice1번이 끝날때까지 기다려야 하기에 데이터 분산이 불균형이 생기면 이에 대한 기다림이 길어지기에 문제가 발생할 수 있음을 인지하고 있어야 한다- Equality filter에서 활용되는 컬럼 (Equal 를 사용하면 하나의 slice로 고정이 되어 버리기 때문에 좋지 않음)- 데이터의 몰림을 유발하는 경우★ 분산키는 어떻게 사용 해야 되는가!- 가장 큰 Dimension table의 pk와 fact table의 foreign키를 disk key 로 선택- 나머지 조인이 되는 조건의 Dimension table(작은 테이블)은 distribution all 를 검토 -> 모든 node들에 해당 테이블에 대한 데이터가 존재하는 형태(경우에 따라 다르지만 보통 300만건 이하의 경우 데이터 분산 타입을 all 로 선택해도 무방)이렇게 하면 성능적으로 가장 좋은 형태로 제공Ⅰ 가장 자주 활용되는 쿼리 확인(https://github.com/awslabs/amazon-redshift-utils/tree/master/src/AdminScripts/top-queries.sql 활용)Ⅱ 조인 또는 group by 에 활용되며 고른 데이터 분포 및 높은 Cardinality 보유한 컬럼을 선택Ⅲ 그게 아니면-위와 같이 최고의 방법을 찾기 힘들다면.. (Fact table은 Even으로 Dimension Table-기준 테이블 은 All로)
- 전체 : 상품 테이블과 같이 개수는 적으나 모든 join이나 그런것에 필요한 경우 각 slice 에 모두 저장 (데이터 storge 가 증가)
- 균등 : round robin (Even)
- explain 하였을 경우 redshift 에서 네트워크를 통한 데이터 이동 관련 내용 (데이터 이동은 가장 비용이 비싼 operation)
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 nodex. |
- 리더 노드가 각 slice 로
성능 향상
1. 보다 높은 하드웨어 스펙
2. 병렬화의 달성
3. 네트워크를 통한 트레픽의 최소화
하지만 결국은 최고의 성능을 내기 위해서는 "스토리지 I/O의 최소화"
- 모든 블록을 1Mb형태로 나눠서 저장하는데..
- Zone Map : 각 Block 에 대한 최대값 및 최소값에 대한 정보 저장 > 그렇기 때문에 정렬 키를 이용하면 필요한 Block 만 읽기 때문에 정렬 키가 중요
정렬 키 (sortkey)
- 정렬 키가 지정된 테이블의 경우 데이터 로드 시 정렬 순서대로 디스크에 저장
- 정렬 키의 종류
- 정렬 키 : 테이블의 단일 컬럼의 값 기준으로 데이터 정렬하여 저장
- 복합 정렬키(Compound Sort Key) :
- 최대 6개의 컬럼까지 활용하여 정렬 키를 지정
- 선언한 순서에 따라 순차적으로 정렬되어 저장 -> 가장 먼저 선언한 키에 대한 높은 가중치
- 조인 및 Group by, order by 효과적이며, Merge 조인에 효과
- 인터리브 정렬키 (Interleaved Sort Key)
- 최대 8개의 컬럼까지 활용하여 정렬키를 지정
- 정렬 키에서 각 열의 하위 집합에 똑같은 가중치 부여 -> 복합 정렬키는 앞의 데이터가 가중치가 높다면, 인터리브 정렬키는 뒤의 키에 대해서도 동일하게 가중치를 부여(데이터의 양이 증가??)
- AD-Hoc 형태의 쿼리에서 높은 성능을 제공
ex) Product 테이블에 sort key로 type, color, size를 지정
복합정렬키 | 인터리브정렬키 | |
where type = 's' and color = 'B' and size = 'xl' | 정렬을 기반한 가장 우수한 성능 | 순서 등에 관계 없이 일관성 있는 성능 제공 |
where type = 's' and color = 'B' | 약간 효과적 | |
where type = 's' and size = 'xl' | 제한적으로 성능에 기여 |
쿼리 분석
- Explain 커맨드를 사용하여 쿼리 분석
- 수행된 오퍼레이션 및 그에 대한 비용
- 쿼리에 사용된 테이블 및 컬럼 정보
- 프로세싱에 사용될 데이터의 크기
파일 분산 및 병렬 로딩
- Slice 단위로 작업을 처리를 하지만, Slice는 파일 하나당 하나의 slice가 할당되기에 반드시 파일을 여러개로 나눈 후 메타데이터를 지정하여 작업 진행을 권장
아래 표 참조 (노드당 100Mbyte sec)
매니페스트 파일 | Copy 커맨드를 통한 실행 |
{ "entries":[ {"url":"s3://mybucket-alpha/client.aa", "mandatory":true}, {"url":"s3://mybucket-alpha/client.ab", "mandatory":true}, {"url":"s3://mybucket-alpha/client.ac", "mandatory":true}, {"url":"s3://mybucket-alpha/client.ad", "mandatory":true} ] } | copy customer from 's3://mybucket/cust.manifest' iam_role 'arn:aws:iam::111111111:role/MyRedshiftRole' manifest; |
압축
- 압축을 기반으로 디스크 사용량 및 I/O 더욱 줄일 수 있음
- Copy 커멘트 사용 시 10만 행을 우선 적제 후 압축 옵션 평가 (COMPUDATE on)
- "Analyze Compression" 커멘트를 통해 현재 압축(인코딩)에 대한 평가 후 "alter table" 로 변경
- 2~4배의 효과
기타
- Vacuum
- 변경되거나 삭제된 블럭에 대한 정리(플래그만 남겨놓고 디스크에는 남아져 있음) - vocuum을 이용하여 정리를 해줌
- 정렬키에 맞춰 데이터 정렬(재정렬을 해주기 위해 vocuum을 사용) , rename을 해도 됨
- 옵션 : full, sort only, delete only, reindex (인터리브 정렬키)
- 통계 업데이트
- 통계 업데이트 자동 실행 조건
- create table as select
- select into
- copy (with compupdate on)
- 통계 업데이트를 실행해줘야 하는 경우
- 5% 이상 데이터 변경된 경우
- 외례키를 추가하거나 삭제한 경우
- Vacuum 실행 후
- 제약 조건 (not null, primary, foreign, unique)은 쿼리 옵티마이저가 활용 (plan 만들 때 참고하기 때문)
- Redshift 도구 모음 :
- Redshift 커스텀 모니터링 도구 :
- Amazon Redshift Column Encoding Utility :
- Analyze & Vacuum Schema utility :
- 마이크로 배치 로딩 :
중요
- 노드 크기의 선택 조건
- 적절한 분산키의 선택 방안
- 적절한 정렬키의 선택 방안
- 데이터 적제 방안
- 레드쉬프트 스펙트럼에서의 파티셔닝 및 파일 포멧
Redshift Spectrum (redshift와 별개!!!)
- 아래는 참고로 하고 제대로 공부는 후에 하는 형태로 하자. redshift와 별개로 필요시 알고 있으면 활용방안이 있을 듯
- s3의 수천개 이상의 노드들을 활용하여 쿼리 실행
수천개의 s3 내의 csv 파일을 읽어 들여 조인 진행
- 파티셔닝 및 Columnar 파일 포맷 (ORC, Parquet) 사용
- 파티셔닝 컬럼의 조건
- 필터 및 조인의 조건이 되는 컬럼
- 비지니스 유닛
- 비지니스 그룹
- 날짜 및 시간
- 파일의 갯수는 Redsfhit 의 Slice의 수량 이상
- 파일의 크기는 64 mb 이상을 권고
- 각 파일은 크기를 권고
반응형