[데브코스] TIL 32일차

---

1. Redshift

AWS에서 지원하는 데이터 웨어하우스 서비스. SQL 기반 관계형 데이터베이스이기 때문에 데이터 모델링이 아주 중요

 

• 특징
  
  • 최소 160GB부터 최대 2PB 까지 처리 가능
  • Still OLAP(OnLine Analytical Processing) - 응답 속도가 빠르지 않아 프로덕션 데이터베이스로는 사용 불가
  • 컬럼 기반 스토리지 - 컬럼 압축, 추가, 삭제가 빠름
  • 벌크 업데이트 지원
  • 고정 용량/비용으로 시작했지만 가변 비용 옵션도 제공함
  • 데이터 공유 기능 - 다른 AWS 계정과 특정 데이터 공유 가능
  • 다른 데이터 웨어하우스와 마찬가지로 primary key uniqueness를 보장하지 않음

 

• 기본 데이터 타입
  • SMALLINT (INT2)
  • INTEGER (INT, INT4)
  • BIGINT (INT8)
  • DECIMAL (NUMERIC)
  • REAL (FLOAT4)
  • DOUBLE PRECISION (FLOAT8)
  • BOOLEAN (BOOL)
  • CHAR (CHARACTER)
  • VARCHAR (CHARACTER VARYING)
  • TEXT (VARCHAR(256))
  • DATE
  • TIMESTAMP
• 고급 데이터 타입
  • GEOMETRY
  • GEOGRAPHY
  • HLLSKETCH
  • SUPER

 

• 스키마
  • 다른 기타 관계형 데이터베이스와 동일한 구조

 

 

 

• 스케일링 방식
  • Scale out, Scale up - 용량이 부족해질 때마다 새로운 노드를 추가하거나 사양을 높이는 방식으로 스케일링. Auto scaling 옵션을 설정하면 자동으로 이뤄짐
  • Redshift Serverless로 가변 비용 옵션도 존재

 

• 최적화
  • Redshift가 두 대 이상의 노드일 때, 한 테이블의 레코드 저장방식은 어떻게 해야할까?
    
    • 테이블 최적화가 중요해지기 때문에, 분산 저장되어야함
    • 한 노드 내에서는 순서를 정해주어야함
  • 만약, 분배가 잘 이뤄지지 않는다면?
    • 레코드 분포에 skew(데이터 불균형) 발생으로 분산 처리의 효율성이 사라짐
    • BigQuery나 Snowflake에서는 이런 속성을 개발자가 지정할 필요 없이 시스템이 알아서 선택

 

 

[출처] https://community.microstrategy.com/s/article/Amazon-Redshift-Best-Practices-for-Performance?language=en_US

• 레코드 분배와 저장 방식
  • Distkey(Distribution Key)
    • 테이블을 분산하는 방법을 결정함
    • DistKey를 지정해 데이터를 최적으로 분산할 수 있음
  • Diststyle(Distribution Style)
    • 특정 컬럼 값을 기준으로 다수의 노드로 분배
      • all - 모든 노드에 모든 레코드를 저장
      • even - 모든 노드에 균등하게 레코드를 저장
      • key - 'DistKey'와 함께 사용되며, 해당 키(특정 컬럼) 값을 기준으로 분배
  • Sortkey(Sort Key)
    •  한 노드 내에서 어떤 컬럼을 기준으로 정렬할지 나타냄
    • 보통 타임스탬프 필드
  • 예시
    • my_table의 레코드들은 column1 기준으로 분배되고, 같은 노드 안에서는 column3을 기준으로 sorting

CREATE TABLE my_table (
    column1 INT,
    column2 VARCHAR(50),
    column3 TIMESTAMP.
    column4 DECIMAL(18,2)
) DISTSTYLE KEY DISTKEY(column1) SORTKEY(column3);

 

 

 

2. Redshift 초기 설정

• 클러스터 생성
  • 처음 VPC를 AZ 2개로 선택해 생성했더니 더 많은 free IP address가 필요하다며 만들어지지않음
  • AZ 3개를 선택했더니 잘됨!
• Jupyter에서 Redshift 연결 테스트
  • 퍼블릭 액세스를 켜야함
  • 보안 그룹의 인바운드 규칙을 포트 5439에 대해 모두 접근할 수 있게 해야함
  • Endpoint 주소, 로그인할 아이디와 비밀번호
    • 로그인 방법
      • admin
      • IAM
• 초기 설정 1) 스키마 설정 - admin 권한이 있어야함

-- 모든 스키마를 리스트하기
SELECT * FROM pg_namespace;

-- 스키마 설정
CREATE SCHEMA raw_data;
CREATE SCHEMA analytics;
CREATE SCHEMA adhoc;
CREATE SCHEMA pii;

 

• 초기 설정 2) 사용자 생성

-- 모든 사용자 리스트하기
SELECT * FROM pg_user;

-- 사용자 생성
CREATE USER yejin PASSWORD '...';

 

• 초기 설정 3) 그룹 생성/설정
  • 개개인을 관리하기 힘드니 그룹을 만들고 그룹 - 스키마 간의 허용 범위를 정해줌
    • 한 사용자는 다수의 그룹에 속할 수 있음
    • 그룹은 계승이 되지 않음! 너무 많은 그룹을 만들면 관리가 힘들어짐
  • 예시
    • pii_users - 어드민을 위한
    • analytics_authors - 데이터 분석가를 위한
    • analytics_users - 데이터 활용을 하는 개인을 위한

-- 그룹 생성
CREATE GROUP analytics_users;
CREATE GROUP analytics_authors;
CREATE GROUP pii_users;

-- 그룹에 사용자 추가
ALTER GROUP analytics_authors ADD USER yejin;
ALTER GROUP anlytics_users ADD USER yejin;
ALTER GROUP pii_users ADD USER yejin;

 

• 초기 설정 4) 역할 생성/설정
  • 역할은 그룹과 달리 계승 구조를 만들 수 있음
  • 사용자 or 다른 역할에 부여될 수 있음
  • 한 사용자는 다수의 역할에 소속 가능

-- 역할 생성
CREATE ROLE staff;
CREATE ROLE manager;
CREATE ROLE external;

GRANT ROLE staff TO yejin;
GRANT ROLE staff TO ROLE yejin;

 

 

 

 

3. Redshift 실습 - COPY

• COPY로 raw_data schema 아래 3개의 테이블에 레코드를 적재할 예정
  • 각 테이블의 입력이 되는 CSV 파일을 먼저 S3로 복사 → S3 버킷을 미리 생성
  • Redshift가 S3 접근 권한을 가지게 IAM 역할을 만들고, Redshift 클러스터에 지정
  • 각 테이블을 CREATE TABLE로 raw_data schema 아래 생성