231128 화 - ETL ELT Redshift SQL BI (2)

1. 특징

최소 기준 용량인 160기가 이상은 무조건 써야함

 

레드시프트를 포함한 DW들이 갖는 특징인데, 일반 RDBMS에서 했던 것처럼 레코드 단위로 insert into 해서 삽입하는 게 아니라 파일 write한걸 copy로 삽입 = 이게 bulk update.

 

primary key uniqueness를 보장하지 않음: 다른 데이터 웨어하우스들도 이렇고, 내가 어떤 컬럼을 PK로 설정한다 한들 그게 유니크하단 걸 보장해주지 않는단 뜻

 

3가지의 고정 비용 옵션. 첫째는 스토리지(즉 컴퓨터 크기)쪽에 포커싱한 옵션, 두번째는 컴퓨팅 파워(즉 처리 속도)

라지->8xlarge 로 가는 이런게 스케일업.

스케일 아웃은 용량 부족해졌을 때 새로운 노드를 추가하는 것. 오토 스케일링 온 옵션 통해 첨부터 이를 가능하게 만들 수 있.

 

 

2. 최적화

고정 비용 옵션일 때, 예를 들어 노드가 3개 레코드가 5개면 이걸 어떻게 저장할지 개발자가 지정해줘야함 (라운드 로빈 등등 지정 옵션 뭐 많지 않나..?) 아하 역시나. diststyle 방식 중 even 옵션이 라운드로빈이었군

빅쿼리, 스노우플레이크 등의 장점은 내가 그 최적화 옵션이니 방식이니 어떻게 분배하고 순서 뭐하고 알고리즘 뭐하고 코어 스레드 등등 생각 하나도 안해도 알아서 해준다는 거임. 물론 항상 잘한다는 건 아니고.

diststyle 방식 쓸떄가 젤 핵심인데, 어떤 컬럼 선택할 때 skew 생기는지를 꼭 체크.

 

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

컬럼1 기준으로 분배되고, 컬럼3 기준으로 한 노드 내 데이터 정렬 방식 지정. 정렬키는 타임스탬프 쓰는게 일반적

스큐된 키면 even 옵션 쓰는게 더 좋을 수 ㅇ. 단 그룹바이나 조인이 되면 같은 키 갖는 애들이 같은 노드로 이동해야 하기 때문에 셔플링 발생하게 되고, 시간이 더 걸리다 보니...

 

 

3. 벌크 업뎃 방식

이건 다른 애들도 다 비슷. 애초에 걍 이게 DW의 보편적인 레코드 적재 방식

 

 

4-1. 기본 데이터 타입

가장 다른 건 캐릭터 타입. 포스트그레스의 캐릭터는 기본 UTF8 기준 캐릭터기 때문에 영문이든 한문이든 한 글자는 한 캐릭터. 근데 레드시프트는 char varchar text 다 바이트 단위라 한국, 중국어, 일본어 같은 경우는 UTF8 기준 3바이트.

영어는 한 바이트가 한 캐릭터지만 CJK는 3바이트가 1캐릭터

글고 포스트그레스의 text는 거의 2기가? 까지 허용할 정도로 매우 긴 캐릭터 타입인데, 레드시프트는 걍 256바이트. 맥스 지정 값은 65535 바이트

 

 

4-2. 고급 데이터 타입

여기 나오는 super는 씨플플에서 쓰는 유니온 타입이랑 비슷, 동일한 것

글고 포스트그라스에는 제이슨 타입 있잖아? 그래서 nested된 structure를 처리하기가 쉽

rest는 네이티브한 타입으로 지원 안해준다. 그래서 json으로 된 포스트그라스 필드를 레드시프트에서 처리하고 싶다? 기본적으로 캐릭터 타입으로 받아온 다음 제이쓴 함수로 파싱하는 형태