SQL

OLTP vs OLAP — 스키마 설계로 이어지는 차이

OLTP(Online Transaction Processing) 시스템은 초당 수천 건의 삽입 같은 대량·저지연 쓰기에 최적화된다(결제 처리 DB가 대표적). OLAP(Online Analytical Processing) 시스템은 5억 행을 스캔해 분기 매출을 계산하는 것 같은 복잡하고 읽기 위주의 쿼리에 최적화된다. 이 차이는 데이터 모델에 그대로 반영된다 — OLTP는 쓰기 이상현상을 최소화하기 위해 고도로 정규화된(3NF) 스키마를 쓰고, OLAP은 JOIN 오버헤드를 최소화하기 위해 역정규화된(스타/스노우플레이크) 스키마를 쓴다.

파티셔닝과 클러스터링(정렬 키)의 조합

파티셔닝은 날짜 같은 컬럼값 기준으로 큰 테이블을 물리적으로 분리된 조각으로 나눈다. 쿼리가 `WHERE order_date BETWEEN '2026-01-01' AND '2026-03-31'`처럼 필터링하면, 엔진은 해당 3개월 파티션만 스캔한다. BigQuery에서는 날짜 필터가 있는 쿼리의 경우 파티셔닝이 비용을 90% 이상 줄일 수 있는데(스캔한 바이트만큼 과금되므로), 이는 예시 수치이지 모든 상황에 보장되는 값은 아니다 — 실제 절감폭은 파티션 키가 실제 쿼리 필터 패턴과 얼마나 잘 맞는지에 달려 있다. 지나치게 많은 값(예: 수백만 개의 값을 갖는 user_id)으로 파티셔닝하면 작은 파일이 너무 많이 생겨 오히려 성능이 나빠지므로, 카디널리티가 적당한 컬럼을 골라야 한다.

클러스터링(또는 정렬 키)은 파티션 내부에서 하나 이상의 컬럼 기준으로 데이터를 물리적으로 재정렬한다. 테이블이 date로 파티셔닝되고 customer_id로 클러스터링되어 있다면, 같은 날짜의 같은 고객 관련 행들이 물리적으로 연속해서 저장된다. 이는 파티션 안에서도 필터에 맞지 않는 데이터 블록을 건너뛸 수 있게 해준다. Snowflake는 이를 '마이크로 파티션 프루닝'이라 부르고, Redshift에서는 정렬 키(sort key)에 해당한다. 실무 80/20 원칙은 '시간 컬럼으로 파티셔닝하고, 가장 흔한 필터나 JOIN 키로 클러스터링한다'는 것이다.

데이터 레이크, 웨어하우스, 레이크하우스, 그리고 스타 vs OBT 결정

데이터 레이크는 원시·비정형 데이터를 저렴하게 저장하지만(S3, ADLS) ACID 트랜잭션과 스키마 강제가 없다. 데이터 웨어하우스는 구조화되고 거버넌스가 적용된, 쿼리에 최적화된 저장소를 제공하지만 비용이 높고 경직적이다. 레이크하우스는 둘을 결합한다 — 저렴한 오브젝트 스토리지 위에 오픈 파일 포맷(Parquet/Delta)을 쓰면서 ACID 트랜잭션, 스키마 강제, 그 위의 SQL 쿼리 엔진까지 제공한다. Delta Lake, Apache Iceberg, Apache Hudi가 이 패턴을 가능하게 하는 대표적인 레이크하우스 테이블 포맷이다.

스타 스키마와 OBT 중 무엇을 쓸지는 소비자의 규모와 숙련도에 달려 있다. 단일 분석팀이 dbt를 쓰고 JOIN을 이해한다면 스타 스키마로 충분하다. 50명의 비즈니스 사용자가 Looker에서 셀프서비스로 조회하고 매번 추가 JOIN이 혼란과 잘못된 숫자를 만든다면, 서빙 계층으로 OBT를 구체화하는 것이 낫다. 이는 이분법적 선택이 아니라 — 스타 스키마가 OBT에 데이터를 공급하는 형태로 둘 다 가질 수 있다는 계층적 답이 더 강력하다.