Redshift 특징
- AWS에서 지원하는 데이터 웨어하우스 서비스
- SQL 기반 관계형 데이터베이스
- 2PB의 데이터까지 처리 가능
- 최소 160GB로 시작해서 점진적으로 용량 증감 가능
- 단, 이 때는 SSD를 사용하기 때문에 속도가 빠름
- Still OLAP
- 응답속도가 빠르지 않기 때문에 프로덕션 데이터베이스로 사용불가
- 컬럼 기반 스토리지
- 레코드 별로 저장하는 것이 아니라 컬럼별로 저장함
- 컬럼별 압축이 가능하며 컬럼을 추가하거나 삭제하는 것이 아주 빠름
- 벌크 업데이트 지원 (모든 데이터 웨어하우스의 특징)
- 레코드가 들어있는 파일을 S3로 복사 후 COPY 커맨드로 Redshift로 일괄 복사
- 고정 용량/비용 SQL 엔진
- 최근 가변 용량 옵션도 제공
- 데이터 공유 가능 (Datashare)
- 다른 AWS 계정과 특정 데이터 공유 가능, snowflake가 원조
- primary key uniqueness를 보장하지 않음 (모든 데이터 웨어하우스의 특징)
Redshift 스케일링 방식
- 용량이 부족해질 때 마다 새로운 노드를 추가하는 방식으로 스케일링
- ex) scale out 방식과 scale up 방식
- dc3.large가 하나면 최대 0.16TB까지의 용량을 갖게 됨
- 공간이 부족해지면
- dc2.large 한대 더 추가 -> 총 0.32TB : scale out
- 아니면 사양을 더 좋은 것으로 업그레이드 -> dc2.8xlarge 한대로 교체 : scale up
- 이를 resizing 이라고 부르며 Auto Scaling 옵션을 설정하면 자동으로 이뤄짐
- 이는 Snowflake나 BigQuery의 방식과는 굉장히 다름
- 특별히 용량이 정이 정해져 있지 않고 쿼리를 처리하기 위해 사용한 리소스에 해당하는 비용 지불
- 즉, snowflake와 BigQuery가 훨씬 더 스케일하는 데이터베이스 기술이라 볼 수 있음
- 비용의 예측이 불가능하다는 단점 존재
- 특별히 용량이 정이 정해져 있지 않고 쿼리를 처리하기 위해 사용한 리소스에 해당하는 비용 지불
- Redshift에도 가변 비용 옵션 존재 -> Redshift Serverless
Redshift의 레코드 분배와 저장 방식
- Redshift가 두 대 이상의 노드로 구성되면 그 시점부터 테이블 최적화가 중요 (다른 웨어하우스는 할 필요 X)
- 한 테이블의 레코드들을 어떻게 다수의 노드로 분배할 것인가
- Diststyle, Distkey, Sortkey 세 개의 키워드를 알아야 함
- Diststyle: 레코드 분배가 어떻게 이뤄지는지 결정
- all, even, key (defalut: even)
- key 선택을 잘못할 경우 레코드 분포에 skew 발생 -> 분산처리의 효율성이 사라짐
- Distkey: 레코드가 어떤 컬럼을 기준으로 배포되는지 나타냄
- Sortkey: 레코드가 한 노드 내에서 어떤 컬럼을 기준으로 정렬되는지 나타냄
- 보통 타임스탬프 필드가 됨
- Diststyle: 레코드 분배가 어떻게 이뤄지는지 결정
* skew란? 데이터가 한 쪽으로 쏠린다
데이터 웨어하우스의 벌크 업데이트 방식 - COPY SQL
- 압축률이 좋은 binary file로 만든 후 클라우드 스토리지에 로딩
- 한 번에 원하는 테이블로 벌크 업데이트
Redshift 초기 설정
Redshift Schema
다른 기타 관계형 데이터베이스와 동일한 구조
- DEV
- raw_data: ETL 결과가 들어감
- analytics: ELT 결과가 들어감
- adhoc: 테스트용 테이블이 들어감
- pii: 개인정보가 들어감
- 테이블이 어느 스키마에 있는지만 봐도 어떤 유형인지 알 수 있어야 함
그룹(Group) 생성/설정
- 한 사용자는 다수의 그룹에 속할 수 있음
- 그룹의 단점: 계승이 안 됨
- 즉, 너무 많은 그룹을 만들게 되고 관리가 어려워짐
- 예를 들어,
- admin을 위한 pii_users
- 데이터 분석가를 위한 analytics_authors
- 데이터 활용을 하는 개인을 위한 analytics_users
반응형
