[데브코스TIL] Redshift 02

1. Redshift의 특징

• AWS에서 지원하는 데이터 웨어하우스 서비스
  • 2 PB의 데이타까지 처리 가능
    • 최소 160GB로 시작해서 점진적으로 용량 증감 가능 : 고정비용으로 사용할 때, SSD 사용 (처리속도 빠름)
  • Still OLAP
    • 응답속도가 빠르지 않기 때문에 프로덕션 데이터베이스로 사용불가
  • 컬럼 기반 스토리지
    • 레코드 별로 저장하는 것이 아니라 컬럼별로 저장함
    • 컬럼별 압축이 가능하며 컬럼을 추가하거나 삭제하는 것이 아주 빠름
  • 벌크 업데이트 지원 (데이터 웨어하우스의 특징)
    • 레코드가 들어있는 파일을 S3로 복사 후 COPY 커맨드로 Redshift로 일괄 복사
  • 고정 용량/비용 SQL 엔진
    • 최근 가변 비용 옵션도 제공 (Redshift Serverless)
  • 데이터 공유 기능 (Datashare):
    • 다른 AWS 계정과 특정 데이터 공유 가능. Snowflake의 기능을 따라함
  • 다른 데이터 웨어하우스처럼 primary key uniqueness를 보장하지 않음 (데이터 웨어하우스의 특징)
    • 프로덕션 데이터베이스들은 보장함

2. Redshift는 SQL 기반 관계형 데이터베이스

• Postgresql 8.x와 SQL이 호환됨
  - 하지만 Postgresql 8.x의 모든 기능을 지원하지는 않음
  - 예를 들어 text 타입이 존재하지 않음
  • Postgresql 8.x를 지원하는 툴이나 라이브러리로 액세스 가능
    • JDBC/ODBC
  • 다시 한번 SQL이 메인 언어라는 점 명심
    • 그래서 데이터 모델링(테이블 디자인)이 아주 중요

3. Redshift의 스케일링 방식

• 용량이 부족해질 때마다 새로운 노드를 추가하는 방식으로 스케일링
  • 예) Scale Out 방식과 Scale Up 방식
    • dc2.large가 하나면 최대 0.16TB까지의 용량을 갖게됨
    • 공간이 부족해지면
      • dc2.large 한대를 더 추가 -> 총 0.32TB (Scale Out)
      • 아니면 사양을 더 좋은 것으로 업그레이드 -> dc2.8xlarge 한대로 교체 (Scale Up)
• 이를 Resizing이라 부르며 Auto Scaling 옵션을 설정하면 자동으로 이뤄짐
• 이는 Snowflake나 BigQuery의 방식과는 굉장히 다름
  • 여기서는 특별히 용량이 정해져있지 않고 쿼리를 처리하기 위해 사용한 리소스에 해당하는
    비용 지불
    • 즉 Snowflake와 BigQuery가 훨씬 더 스케일하는 데이터베이스 기술이라 볼 수 있음
    • 장단점 존재 -> 비용의 예측이 불가능하다는 단점 존재
• Redshift에도 가변비용 옵션 존재 -> Redshift Serverless
  • 뒤에 데모에서는 Redshift Serverless를 사용해볼 예정 (Pay as You Go)
• Redshift 최적화는 굉장히 복잡
  - Redshift가 두 대 이상의 노드로 구성되면 한 테이블의 레코드들의 저장방식은?
  - 분산 저장되어야함
  - 또 한 노드 내에서는 순서가 정해주어야함
  
  

4. Redshift의 레코드 분배와 저장 방식

• Redshift가 두 대 이상의 노드로 구성되면 그 시점부터 테이블 최적화가 중요
  • 한 테이블의 레코드들을 어떻게 다수의 노드로 분배할 것이냐!
• Distkey, Diststyle, Sortkey 세 개의 키워드를 알아야함
  • Diststyle은 레코드 분배가 어떻게 이뤄지는지를 결정
    • all, even, key (디폴트는 even)
  • Distkey는 레코드가 어떤 컬럼을 기준으로 배포되는지 나타냄 (diststyle이 key인 경우)
  • Sortkey는 레코드가 한 노드에서 어떤 컬럼을 기준으로 정렬되는지 나타냄
    • 이는 보통 타임스탬프 필드가 됨

노드 : 분산 컴퓨팅에서 노드는 네트워크에 연결된 개별 컴퓨터나 장치를 의미. 각각의 노드는 네트워크의 일부로서 데이터를 처리하고 다른 노드와 통신할 수 있다.

Amazon Redshift는 데이터 웨어하우스 서비스로, 큰 규모의 데이터 세트를 효율적으로 분석할 수 있도록 설계된 클라우드 기반 솔루션이다. Redshift에서는 테이블의 데이터를 노드 간에 분배하는 몇 가지 방식을 제공하는데, 이를 "분배 스타일(Distribution Style)"이라고 한다. 각 분배 스타일은 데이터의 배치와 쿼리 성능에 영향을 미친다. 주요 분배 스타일은 ALL, EVEN, KEY 세 가지이다.

- ALL (전체 분배)
ALL 분배 스타일은 테이블의 모든 데이터를 클러스터의 모든 노드에 복사하여 저장한다. 이 방식은 조인이 자주 일어나는 작은 참조 테이블에 적합하다. 각 노드에 데이터가 전체적으로 복사되기 때문에 네트워크를 통한 데이터 전송이 필요 없어서 조인 성능이 향상된다. 그러나 테이블 크기가 크면 많은 저장 공간을 차지하고, 데이터 로드 시간도 길어질 수 있다.

- EVEN (균등 분배)
EVEN 분배 스타일은 테이블의 행을 클러스터 내의 모든 노드에 균등하게 분배한다. 특정 행을 특정 노드에 할당하는 것이 아니라, 순차적 혹은 무작위로 데이터를 분배한다. 이 방식은 분배 키를 선택할 수 없거나 특정 키에 따른 데이터 편향이 예상될 때 유용하며, 데이터를 균등하게 분배하여 각 노드의 작업 부하를 균일하게 유지할 수 있다.

- KEY (키 분배)
KEY 분배 스타일은 특정 컬럼(분배 키)의 값을 기준으로 데이터 행을 분배한다. 분배 키로 사용된 컬럼의 값에 따라 각 행이 특정 노드에 할당된다. 이 방식은 자주 조인되는 컬럼을 분배 키로 선택할 때 유리하고, 조인 수행 시 네트워크를 통한 데이터 이동이 적어서 조인 성능이 향상되지만, 분배 키의 값 분포가 불균형하면 특정 노드에 데이터가 집중되어 성능 저하가 발생할 수 있다. 각 분배 스타일은 테이블의 크기, 조인 패턴, 쿼리 성능 요구 사항 등에 따라 적절히 선택되어야 한다.

• Diststyle이 key인 경우 컬럼 선택이 잘못되면?
  • 레코드 분포에 Skew가 발생 → 분산처리의 효율성이 사라짐
  • BigQuery나 Snowflake에서는 이런 속성을 개발자가 지정할 필요가 없음(시스템이 알아서 선택)

Load skew : 특정 노드나 서버에 작업의 대부분이 집중되어 다른 노드들보다 훨씬 많은 부하를 겪는 상황
Data skew : 데이터가 분산 시스템 내의 노드나 파티션 간에 고르지 않게 분배되어 일부 노드에 데이터가 과도하게 집중되는 현상. 이로 인해 일부 노드는 과부하 상태가 되며, 전체 시스템의 성능이 저하될 수 있다.

Redshift의 레코드 분배와 저장 방식 예

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

# my_table의 레코드들은 column1의 값을 기준으로 분배되고, 
같은 노드(슬라이스)안에서는 column3의 값을 기준으로 소팅이 됨

4. Redshiftt의 벌크 업데이트 방식 - COPY SQL

• 소스로부터 데이터 추출 → S3에 업로드 (보통 Parquet 포맷을 선호) → COPY SQL로 S3에서 Redshift 테이블로 한번에 복사

5. Redshift의 데이터 타입

기본 데이터 타입

• SMALLINT (INT2)
• INTEGER (INT, INT4)
• BIGINT (INT8)
• DECIMAL (NUMERIC)
• REAL (FLOAT4)
• DOUBLE PRECISION (FLOAT8)
• BOOLEAN (BOOL)
• CHAR (CHARACTER) * redshift의 char 단위는 bite
• VARCHAR (CHARACTER VARYING)
• TEXT (VARCHAR(256))
• DATE
• TIMESTAMP