Redshift 특징 소개

• AWS에서 지원하는 데이터 웨어하우스 서비스

• 2 PB의 데이터까지 처리 가능하다

  • 최소 160GB로 시작해서 점진적으로 용량 증감 가능

• Still OLAP

  • 응답속도가 빠르지 않기 때문에 프로덕션 데이터베이스로 사용불가
  • 큰 데이터를 처리하는데 집중을 함

• 컬럼 기반 스토리지

  • 레코드 별로 저장하는 것이 아니라 컬럼별로 저장함
  • 컬럼별 압축이 가능하며 컬럼을 추가하거나 삭제하는 것이 아주 빠름

• 벌크 업데이트 지원

  • 레코드가 들어있는 파일을 S3로 복사 후 COPY 커맨드로 Redshift로 일괄 복사

• 고정 용량/비용 SQL 엔진

  • 가장 큰 특징 중에 하나
  • 최근 가변 비용 옵션도 제공 (Redshift Serverless)

• 데이터 공유 기능 (Datashare):

  • 다른 AWS 계정과 특정 데이터 공유 가능. Snowflake의 기능을 따라함

• 다른 데이터 웨어하우스처럼 primary key uniqueness를 보장하지 않음

  • 프로덕션 데이터베이스들은 보장함
  • redshift의 데이터 베이스 엔진이 이를 보장해주지 않는다.
  • 암묵적으로 엔지니어가 보장을 해주어야 함. (비지니스 룰과 같은 것)

• Redshift는 SQL 기반의 관계형 데이터베이스

  • Postgresql 8.x와 SQL이 호환이 된다.
  • 예를 들면 text 타입이 존재하지 않는다.

• Postgresql 8.x를 지원하는 툴이나 라이브러리로 엑세스가 가능하다

  • JDBC/ODBC와 같은 데이터 베이스 엑세스 라이브러리

• 어쨋거나 SQL이 메인언어라는 점을 명심하자

  • 데이터 모델링이 아주 중요하다.

• 가격 옵션

  Redshift 옵션과 가격 정책(us-east 기준)

  

• redshift의 스케일링 방식

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

    • Redshift가 2대 이상의 노드로 구성되면 한 테이블의 레코드들의 저장 방식은?

      • 분산 저장되어야한다.
      • 한 노드 내에서는 분배가 어떻게 되어야 하는지 개발자가 순서가 정해주어야 한다

      

      만약 3개의 노드를 가진 redshift 클러스터가 존재한다

      • 5개의 레코드를 적재했다

        

      • 위의 레코드들이 3개의 노드에 어떻게 분산 저장될지, 개발자가 직접 지정을 해주어야한다

      • data skew문제가 발생할 수 있다.

        • 하나의 노드에 쏠림 저장 현상이 있을 때, 하나의 노드에서 처리 병목현상이 발생할 것. ⇒ 데이터 프로세싱에 있어서 전체적인 처리 시간이 늘어난다.

      하지만 snowflake나 bigquery는 개발자가 위의 내용을 알필요가 없다.

      • 테이블의 크기, 특성에 따라서 해당 데이터 웨어하우스가 알아서 관리를 해주기 때문.

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

• Redshift가 두 대 이상의 노드로 구성되면 그 시점부터 테이블 최적화가 중요
  • 한 테이블의 레코드들을 어떻게 다수의 노드로 분배할 것이냐를 고려해야 한다.
• Distkey, Diststyle, Sortkey 세 개의 키워드를 알아야한다
  • Diststyle은 한 테이블에 속성으로 지정이 된다.

    • 레코드 분배가 다수의 노드로 어떻게 이뤄지는지를 결정

    • all, even, key (디폴트는 “even”)

      

      • all : 모든 레코드들이 모든 노드에 복제가 되는 것, 레코드 수가 작을 때 권장이 되는 옵션
      • even : round-robin 형식으로 레코드를 돌아가면서 넣는 것
      • key : 특정 칼럼의 값을 기준으로 노드들이 다수의 노드로 분배가 되는 것
        • 분산키(Distkey)를 활용하여 테이블의 단일의 칼럼 값을 기준으로 데이터를 분산하는 방식이다. 분산키로 설정된 칼럼의 해시 값을 통해 데이터가 저장될 각 컴퓨팅 노드의 슬라이스가 선택된다. 즉 분산키의 같은 값을 가지는 데이터(row)는 같은 슬라이스에 저장되게 된다.
  • Distkey는 레코드가 어떤 컬럼을 기준으로 배포되는지 나타냄
    • diststyle이 key인 경우에 사용하는 옵션
    • 분배 기준이 되는 컬럼을 지정할 수 있게 됨
  • Sortkey는 레코드가 한 노드 내에서 어떤 컬럼을 기준으로 정렬되는지 나타냄
    • 이는 보통 타임스탬프 필드가 됨
• 예시1. Diststyle이 key인 경우 컬럼 선택이 잘못되면?
  • 레코드 분포에 Skew가 발생하게 된다 → 이 경우, 분산처리의 효율성이 사라짐
  • 특정 키의 값이 같은 레코드들은 같은 노드로 들어가게 되지만, 이 경우 같은 키의 값을 가진 데이터끼리 group by나 join을 하게 되면 데이터의 이동이 별로 없기 때문에 좋은데, 그 키의 분포가 skew하여 특정 키를 같는 레코드가 너무 많을 경우, 노드 간 데이터 불균형이 발생한다. 이는 퍼포먼스 문제를 일으키게 된다
  • BigQuery나 Snowflake에서는 이런 속성을 개발자가 지정할 필요가 없다. 왜냐하면 시스템이 알아서 선택해주기 때문.