[Deep Dive] Redshift부터 StarRocks까지, OLAP 엔진 뼛속까지 털어본 Q&A

“똑같은 SQL인데 왜 성능은 수백 배 차이가 날까?”
빗썸에서 Redshift와 Vertica를 굴리며, 그리고 토스의 StarRocks를 분석하며 깨달은 하드코어 OLAP의 정수를 Q&A 형태로 정리했습니다.

---

1. 기초편: OLAP은 왜 이렇게 미친 듯이 빠름? 🏎️💨

Q: 일반 RDB(MySQL 등)랑 비교했을 때 수백 배 차이가 나는 근본적 이유가 뭐임?
A: 차원이 다름!! 💀
1. I/O의 기적: 필요한 컬럼만 읽으니까 읽는 데이터 양 자체가 1/100로 줄어듦.
2. CPU의 폭주 (SIMD): 한 번의 망치질로 숫자 16개를 한꺼번에 더해버림 (벡터 연산).
3. 캐시 히트: 데이터가 메모리에 일렬로 쫙 서 있어서 CPU가 쉴 틈 없이 일함.

결론: 삽질(RDB) 하다가 포크레인(OLAP) 끌고 온 격임!! 🚜✨

---

2. 심화편: 쿼리 엔진의 두 파벌 (Compilation vs Vectorization) 🏗️🚀

Q: Redshift는 ‘코드 생성(JIT)’ 방식이고 Clickhouse는 ‘벡터화’ 방식이라는데 뭐가 다름?
A: ‘맞춤 정장’과 ‘고급 기성복’의 차이임!! 👔👕
1. Compilation (Redshift/Spark): 쿼리 들어오면 딱 그 쿼리 전용 C++ 기계어를 구워버림. 첫 실행은 컴파일 때문에 느린데, 한 번 돌기 시작하면 최적화 끝판왕임.
2. Vectorization (Clickhouse/StarRocks): 미리 초고속 함수들을 잔뜩 만들어두고 데이터를 뭉치(Vector) 단위로 쏴줌. 컴파일 대기 시간 없이 즉각 반응함!!

Q: LLVM JIT가 뭐길래 쿼리를 굽는다고 함?
A: 쿼리라는 ‘설계도’를 받자마자 LLVM이라는 ‘초고속 타자’가 메모리상에서 즉석으로 최적화된 기계어를 써 내려가는 거임!! CPU가 직진만 할 수 있게 ‘분기(IF)’를 싹 제거한 하드코딩된 코드를 실시간으로 만드는 마법임!! 🧙‍♂️🔥

---

3. 하드코어편: 엔지니어링 냄새 진동하는 내부 구조 🧬💥

Q: Redshift 접속하면 Postgres 8.0.2라고 뜨는데, 얘 진짜 OLTP DB 아님?
A: 겉만 번지르르한 ‘프랑켄슈타인’임!! 💀 쿼리 파싱이랑 메타데이터 관리만 Postgres 껍데기를 빌려온 거고, 실제 쿼리 실행은 계획(Plan)이 나오자마자 C++ 기계어로 컴파일해서 돌려버림. OLTP 엔진이랑은 유전자 자체가 다른 ‘변종’임!!

Q: 쿼리 엔진에서 ‘분기(IF)’가 왜 그렇게 성능에 치명적임?
A: CPU는 성격이 급해서 다음에 올 길을 미리 때려 맞히는 ‘분기 예측’을 함. 하지만 데이터가 뒤죽박죽이라 예측이 틀리면? 미리 달렸던 작업을 싹 다 쓰레기통에 버리고 다시 돌아와야 함(Penalty)!! 💀💥

JIT나 벡터화는 이 ‘IF’ 문 자체를 없애서 CPU가 눈 감고도 직진만 할 수 있게 ‘고속도로’를 깔아주는 작업임!! 🏎️💨

---

4. 실전편: 왜 요즘 대세는 StarRocks임? 🌟💰

Q: Redshift 쓰다가 StarRocks 보면 눈 돌아가는 이유가 뭐임?
A: 레드시프트가 못 하는 ‘실시간성’을 다 뚫어버렸기 때문임!! 💀🔨
1. PK 엔진: 수정/삭제(Update/Delete)가 거의 공짜임!! 메모리에 ‘삭제 비트맵’ 스탬프만 찍는 방식이라 성능 저하가 거의 없음.
2. 동시성 깡패: 쿼리를 잘게 쪼개는 파이프라인 엔진 덕분에 수백 명이 동시에 날려도 버팀.
3. 똑똑한 CBO: 데이터를 읽기도 전에 “야, 저 노드에 7번 데이터 없으면 꺼내지도 마!” 하고 무전 치는(Runtime Filter) 능력이 탁월함.

Q: 레드가 느려도 낫지, 스타락스는 왜 자꾸 뻗음(OOM)?
A: 철학의 차이임!!
– Redshift: 메모리 부족하면 디스크에 임시로 쓰고 버팀(Spill-to-disk). 느려지지만 쿼리는 완주함. (거북이 🐢)
– StarRocks: 모든 걸 메모리 성능에 올인함!! 램이 부족하면 “나 죽네!” 하고 뻗어버림.

결론: 스타락스 엔지니어는 메모리(RAM)와 데이터 스큐(Skew) 관리에 영혼을 팔아야 함!! 🔨👻

---

5. 알고리즘편: 왜 DISTINCT 숫자가 가끔 틀림? 🔮🚫

Q: 10억 건 집계할 때 COUNT DISTINCT 숫자가 예상과 다르게 나오는 이유는?
A: HLL(HyperLogLog)이라는 확률적 알고리즘 때문임!!
모든 데이터를 전수 조사하면 네트워크 터지니까, ‘앞자리에 0이 몇 개 있나’ 하는 힌트만 보고 전체 규모를 때려 맞히는 거임. 1.5KB 메모리로 10억 건을 99% 정확도로 맞히는 ‘가성비’를 택한 결과임!! 👻✨

Q: 그럼 정확한 숫자가 필요하면 어떡함?
A: 스타락스라면 ‘Bitmap’ 기능을 쓰셈!! 유니크 값을 비트로 바꿔서 관리하면 정확도 100%를 유지하면서도 HLL 급의 속도를 낼 수 있음!!

---

6. 운영편: 프로젝션(Projection)과 꼼수의 미학 🏛️🪄

Q: Vertica에서 말하는 프로젝션, 결국 MV(Materialized View) 아님?
A: 논리는 같은데 ‘물성’이 다름!!
– MV: 원본 테이블이 있고 ‘추가’로 만드는 것.
– Projection: 데이터 그 자체임!! 원본이라는 실체가 따로 없고, 데이터가 어떤 순서로 정렬되어 저장될지를 정의함.

“데이터를 어떻게 보관할까(보관법)”가 프로젝션이라면, “결과를 미리 계산할까(요약본)”가 MV임!!

Q: 쿼리 효율을 극단적으로 높이는 ‘Late Materialization’이 뭐임?
A: 데이터를 통째로 읽지 말고, WHERE 조건에 맞는 놈들의 ‘주소(ID)’만 먼저 광속으로 추려내는 거임!! 진짜 필요한 전체 컬럼은 맨 마지막에 “살아남은 놈들”만 콕 집어서 가져오는 방식으로 I/O를 수십 분의 일로 줄임. 🚀✨

---

7. 결론: 데이터 엔지니어는 어떻게 해야 함? 👨‍💻🚀

Q: 이 모든 기술을 다 알아야 함?
A: ㅇㅇ!! 💀 “어떤 엔진이 좋냐”가 아니라 “내 비즈니스 목적에 뭐가 맞냐”를 골라내는 게 실력임.
– 안정적인 전사 DW: Redshift (장갑차) 🛡️
– 실시간 서비스 연동: StarRocks (F1 레이싱카) 🏎️
– 결론: 형님은 두 마리 토끼 다 잡는 아키텍트가 되면 됨!! 💰🔥

---

Written by. Junku Lee (with. Kkaeb 👻)