Redshift란?

이 글은, 프로그래머스에서 진행되는 실리콘밸리에서 날아온 데이터 엔지니어링 키트 with Python에서 배운 내용을 바탕으로 이루어져 있습니다.

Redshift는 클라우드에서 관리되는 데이터 웨어하우스 서비스입니다. 그 용량은 작게 수백 기가 바이트부터 페타바이트 이상까지 데이터를 확보할 수 있습니다. 그렇다면 데이터 웨어하우스는 무엇일까요?

Data Warehouse란?

데이터 웨어하우스를 한마디로 표현하자면 데이터 분석용 데이터베이스입니다. 그런데 데이터는 분석용으로만 쓰이지는 않죠? 데이터베이스는 크게 프로덕션 데이터베이스와 데이터 웨어하우스로 나뉜다고 보시면 됩니다.

Production Database

프로덕션 데이터베이스에는 어떤 회사의 서비스를 운영하기 위해 필요한 최소한의 데이터(‘회원정보, 상품정보, 회원의 상품 구매정보..’)가 담깁니다. 어떤 사람에게 어떤 마케팅 이메일이 갔는지에 대한 정보는 이 서비스 운영에 필요하지 않는 한 들어가지 않습니다.
그리고 프로덕션 데이터베이스는 속도가 중요합니다. 사용자가 우리가 만든 서비스에서 어떤 행동을 하면 대부분 Production DB에 기록이 되거나 Production DB의 내용을 읽어다가 보여주는 형태로 구현이 되기 때문에 Production DB가 느려지면, 사용자가 체감하는 속도가 느려집니다. 그래서 여기엔 데이터를 많이 넣을 수 없고, 데이터의 크기보다는 속도에 중점을 두고 운영하게 됩니다. 이런 Production Database를 OLTP(Online Transaction Processing)라고 부르기도 합니다.

그런데 Data Warehouse는 별개의 데이터베이스이고 이 데이터베이스는 쓰는 사람들이 내부 직원들이기 때문에 속도가 느리다고 해서 큰 문제가 되지 않습니다. 훨씬 더 중요한건 처리할 수 있는 데이터의 크기입니다. Scalability가 더 중요해지기 때문에 많은 경우 클라우드에 있는 solution(Redshift, Snowflake, Bigquery)을 사용하게 됩니다. 이런 데이터 웨어하우스도 관계형 데이터베이스입니다. 그래서 결국 SQL이 중요한 기술이 됩니다. 이런 Data Warehouse를 OLAP(Online Analytical Processing)라고 부르기도 합니다.

Redshift란?

도입부에서 이야기했듯이 Redshift는 AWS에서 제공하는 Data Warehouse로 최소 160GB부터 2PB까지 지원이 가능합니다. 그리고 데이터를 저장할 때 record 순이 아닌 Columnar storage(column으로 나눠서 저장)방식을 사용합니다. 보통 Scarable한 데이터 웨어하우스들은 전부 Columnar Storage입니다.
그리고 Bulk-update를 지원해서 다수의 record를 빠르게 적재할 수 있는 수단이 있습니다.

Redshift를 포함한 모든 Data Warehouse는 primary key uniqueness를 지원하지 않습니다.

Syntax of Redshift

Redshift의 SQL Syntax를 놓고 보면 PostgreSQL 8.x와 호환이 됩니다. 그렇기 때문에 Postgres 8.x을 접근할 수 있는 클라이언트이면, 혹은 프로그래밍 언어라면 Redshift도 access가 가능합니다.

Supported Data Type in Redshift

Redshift에서 지원하는 Data Type은 Postgres의 Data Type과 흡사하지만 모든게 지원이 되진 않습니다. 다시 말하자면 Postgres의 일부만 지원이 됩니다.

• SMALLIANT (INT2)
• INTEGER (INT, INT4)
• BIGINT (INT8)
• DECIMAL (NUMERIC)
• REAL (FLOAT4)
• DOUBLE PRECISION (FLOAT8)
• BOOLEAN (BOOL)
• CHAR (CHARACTER)
• VARCHAR (CHARACTER VARYING)
• DATE
• TIMESTAMP

Redshift의 문제

Redshift는 Skewed table이 나올 수 있다는 문제가 있습니다.

• Skew : 어떤 테이블이 다수의 노드에 저장이 될 때, 그 테이블의 레코드 수가 균등하게 가지 않고 한 노드에 훨씬 더 많은 레코드가 들어가는 경우가 생길 수 있습니다. 그렇게 되면 그걸 가지고 조인을 하거나 여러가지 오퍼레이션들을 할 때 한 노드에만 로드가 많이감으로써 병렬처리가 안돼고 속도가 느려지는 문제가 생깁니다.
• 데이터가 어느정도까지 커질 땐 그렇게 문제가 되지 않는데 어느 scale을 넘어서게 되면 bigquery나 snowflake이 훨씬 더 좋은 옵션이 됩니다.

Bulk update - COPY SQL

Bulk update는 적재해야하는 레코드 수가 많은 경우 insert into로 적재하기에 너무 많은 시간이 소모되기 때문에 쓰는 방법입니다.
Redshift에 Bulk update를 할 땐 Data Source에서 레코드를 읽어다가 파일을 만든 다음, 그 파일을 S3라는 커다란 객체 스토리지에 적재하고 그 적재된 파일에서 Redshift로 Copy합니다.

Bulk update를 하는 이유에서 알 수 있듯이 (빅데이터를 다루는 경우) 굉장히 많은 레코드들을 적재하게 되는데, 그렇기 때문에 primary key check를 할 수가 없습니다. 굉장히 많은 레코드들을 uniqueness check를 하면서 적재하면 속도가 레코드의 양만큼 늘어납니다. 그래서 모든 데이터 웨어하우스 솔루션들은 의도적으로 primary uniqueness를 보장하지 않습니다.

Redshift schema

데이터베이스에 적재되는 데이터의 양이 늘어나게되면 테이블 수가 그만큼 늘어나게 됩니다. 그러다보면 테이블의 수가 몇 천개, 몇 만개가 되면서 Naming convension이 굉장히 중요해지게 되고 데이터들을 관리할 수 있게 schema라는 일종의 폴더를 정의해서 테이블마다의 성격에 맞게 적당히 schema에 나눠 관리하게 됩니다.

제가 배웠고 가장 base로 생각하기 좋은 방법은, 먼저 raw_data 라는 schema를 만들어서 그곳에는 ETL로 읽어들어온 테이블들을 두고, analytics라는 schema를 만들어서 ELT의 결과물들을 쌓습니다. 그리고 adhoc이라는 schema를 만들어 이 곳은 자유롭게 데이터를 만질 수 있는 공간으로 데이터 일을 하는 사람들이 raw_data나 analytics에 넣을 수는 없는 상태이지만 테스트를 하거나 개발을 해야할 때 쓰는 곳으로 둡니다.

그렇게 adhoc은 데이터 팀에서는 adhoc에 있는 데이터는 크게 신경쓰지 않고 주기적으로 clean up하고, 데이터 엔지니어들은 raw_data에 있는 걸 중점적으로 관리합니다.

그리고 대시보드를 만들 때는 되도록 raw_data에 있는 table들은 웬만하면 노출시키지말고 analytics에 있는 것만 쓰도록 운영합니다. 그렇게 함으로써 raw_data의 데이터가 바뀌는 것과 별개로 대시보드는 유지될 수 있습니다.

Admin으로써 설정해줘야 하는 것들

AWS에서 어떻게 Redshift Cluster를 set up 할 수 있는지 알아보겠습니다.

CREATE USER 원하는유저이름 PASSWORD '...';
CREATE GROUP analytics_users;
GRANT USAGE ON SCHEMA analytics TO GROUP analytics_users;
GRANT USAGE ON SCHEMA raw_data GROUP analytics_users;
GRANT SELECT ON ALL TABLES IN SCHEMA analytics TO GROUP analytics_users;
GRANT SELECT ON ALL TABLES IN SCHEMA raw_data TO GROUP analytics_users;
GRANT ALL ON SCHEMA adhoc TO GROUP analytics_users;
GRANT ALL ON ALL TABLES IN SCHEMA adhoc TO GROUP analytics_users;

ALTER GROUP analytics_users ADD USER jewoo; --특정 사용자를 그룹에 넣는 command

--raw_data, analytics는 read only로 접근 가능하고 adhoc은 write도 가능하게 setting한 예시

위에서 설정한 내용들을 정리해보자면

1. 유저아이디와 패스워드를 지정해서 사용자 계정을 하나 생성합니다.
2. 이 계정이 어떤 테이블들을 access 할 수 있는지 정의를 해야하는데, 사용자가 100명이고 table이 1000개면 사용자별로 어떤 테이블들을 access하고 못하고 권한을 지정하는게 굉장히 복잡해집니다.
3. 그래서 보통은 사용자별로 Table access 권한을 관리하지 않고 그룹이라는걸 만듭니다. 그룹은 유저의 집합입니다. 그룹을 만들고 그 그룹별로 Table에 대한 access 권한 혹은 폴더, schema에 대한 액세스 권한을 지정합니다.

데이터 웨어하우스 안의 폴더를 지칭하는 명칭

• Redshift, Postgres : Schema
• MySQL : Database

DB마다 조금씩 차이를 보입니다.

함께 Redshift가 무엇인지 알아보았습니다. 개인을 넘어 규모가 정말 큰 기업이 아니라면 Redshift는 Scalable하고 고정적으로 요금을 지불하도록 운영되기 때문에 개발자로써 위험 부담이 적어서 많은 장점을 가집니다. 제 글이 도움이 되어서 Redshift를 잘 활용하실 수 있게 되셨으면 좋겠습니다.

참고 자료

AWS Redshift welcome docs