불곰

OLAP 분석 데이터베이스 완전 비교 가이드

불곰1 — Wed, 29 Apr 2026 22:43:55 +0900

1. OLAP DB 분류 개요

1.1 데이터 저장 방식에 따른 분류

분류 설명 대표 제품

자체 저장형 OLAP	데이터를 직접 저장·관리, 전용 스토리지 엔진 보유	Druid, Pinot, ClickHouse, StarRocks, Doris
MPP 쿼리 엔진형	데이터 비저장, 외부 스토리지(HDFS, S3 등)에 쿼리만 실행	Trino, Presto, Spark SQL, Impala
임베디드/경량형	프로세스 내 실행, 서버리스	DuckDB, chDB
스트리밍 DB형	실시간 스트림 처리 + OLAP 쿼리 통합	RisingWave

1.2 Apache Impala의 분류

Apache Impala는 MPP 쿼리 엔진 계열에 속합니다.

데이터를 직접 저장하지 않음 → HDFS, HBase, S3 등 외부 스토리지에 직접 쿼리
Hadoop 에코시스템과 완전 통합 (Hive 메타스토어, YARN 등 공유)
구조: Shared-Nothing MPP 아키텍처이나, Hadoop 위에서 동작하는 SQL 레이어
Trino/Presto와 유사한 포지셔닝, 단 Hadoop 전용으로 설계됨
2025년 기준 Iceberg, Parquet, ORC 등 오픈 포맷 지원 강화 (4.5 버전)
한계: Hadoop 의존성이 강해 클라우드 네이티브 환경에서 입지 약화 중

✅ 결론: Impala는 "MPP 쿼리 엔진" 문서에 정리된 Trino/Presto와 같은 범주. 자체 저장형 OLAP이 아님.

2. Apache Druid

2.1 개요

출시: 2011년 (Metamarkets), 2015년 Apache 편입
포지션: 실시간 스트리밍 + 이벤트 기반 OLAP 데이터베이스
핵심 철학: 수십억~수조 개 이벤트 행의 밀리초급 슬라이스-앤-다이스 쿼리
주요 사용처: Netflix, Airbnb, Twitter, Lyft, Nielsen

2.2 아키텍처

마이크로서비스 구조: Master(Coordinator, Overlord), Query(Broker, Router), Data(Historical, MiddleManager, Indexer), Deep Storage
컬럼형 저장 + 시간 파티셔닝 (Time-based Partitioning이 1차 기준)
Roaring Bitmap 인덱스: 멀티 컬럼 필터링 고속화
Deep Storage: S3/HDFS 등 외부 스토리지에 세그먼트 영구 보존 → 장애 복구 가능
Streaming 수집: Apache Kafka, Amazon Kinesis 네이티브 연동
Scatter/Gather 쿼리 실행 모델 (데이터를 메모리/로컬 스토리지에 사전 로드)

2.3 장점

초고속 실시간 스트리밍 수집 + 동시 쿼리 (수집 즉시 쿼리 가능)
시계열/이벤트 데이터에 최적화된 압축 및 인덱싱
자동 데이터 롤업(Pre-aggregation)으로 스토리지/쿼리 비용 절감
수평 확장성 우수, 컴포넌트별 독립 스케일링 가능
딥 스토리지 기반 내결함성

2.4 단점 및 한계

Upsert 미지원: 실시간 업데이트/삭제 불가, append-only 설계
운영 복잡도 高: 다수의 마이크로서비스(6~8개 프로세스) 관리 필요
복잡 JOIN 약함: 다중 테이블 조인 성능이 ClickHouse/StarRocks 대비 미흡
SQL 표준 준수 부분적: 일부 SQL 기능 미지원
학습 곡선 가파름: 아키텍처 이해 및 튜닝에 상당한 노력 필요
근래 Apache Pinot, StarRocks 대비 커뮤니티 성장세 둔화

2.5 적합한 사용 사례

클릭스트림, 광고 분석, IoT 이벤트 스트림 실시간 대시보드
수십억 행 이벤트 테이블의 고동시성 slice-and-dice 분석
업데이트 없는 append-only 로그/이벤트 데이터
시간 범위 기반 분석이 주된 워크로드

2.6 확장성

컴포넌트별 독립 스케일링 (Historical 서버 추가로 쿼리 용량 확장)
페타바이트 규모 운영 사례 존재 (Netflix 등)
클라우드: Imply Cloud (상용), AWS/GCP 자체 운영 가능

3. Apache Pinot

3.1 개요

출시: 2013년 (LinkedIn), 2015년 Apache 편입
포지션: 사용자 직면(User-Facing) 실시간 분석 전문 OLAP DB
핵심 철학: 초저지연 + 초고동시성 — 수십만 QPS에서 일관된 밀리초 응답
주요 사용처: LinkedIn, Uber, Stripe, Walmart, WeChat

3.2 아키텍처

컴포넌트: Controller, Broker, Server, Minion (각 독립 서비스)
세그먼트 기반 분산 저장: Immutable segments + Consuming segments(실시간)
다양한 인덱스 지원: Inverted, Sorted, Range, Text(Lucene), JSON, Star-Tree(사전집계), N-gram, HNSW(벡터)
Multi-Stage Query Engine: 복잡한 JOIN/서브쿼리 지원 강화 (v1.0+)
Upsert 지원: Primary Key 기반 실시간 업데이트 가능
Kafka, Pulsar, Kinesis, 배치(S3/Hadoop) 수집 모두 지원

3.3 장점

최고 수준의 동시성: 100,000+ QPS에서 일관된 성능
ClickHouse 대비 쿼리 속도 4배, Druid 대비 5~7배 빠름 (일부 벤치마크)
Star-Tree 인덱스로 집계 쿼리 초고속 처리
Upsert 지원으로 가변 데이터 실시간 반영
벡터 검색(HNSW) 내장으로 AI/RAG 파이프라인 통합
2026년 기준 활발한 개발 (v1.5.0 — Kafka 4.x, Time Series Engine, Federation 등)

3.4 단점 및 한계

운영 복잡도 높음: Druid와 유사하게 다수 컴포넌트 관리
복잡 쿼리 약점: 복잡한 다중 JOIN은 StarRocks/ClickHouse 대비 불리
학습 비용: Star-Tree 등 독자 인덱스 이해 필요
생태계: Druid/ClickHouse보다 커뮤니티 규모 작음

3.5 적합한 사용 사례

사용자 직면 분석 API: 앱/서비스 내 실시간 대시보드 (수만 동시 사용자)
LinkedIn "Who viewed my profile", Uber 실시간 지표, Stripe 결제 분석
높은 QPS + 낮은 지연이 동시에 요구되는 환경
이상 탐지, 실시간 메트릭 모니터링

3.6 확장성

StarTree Cloud (상용 관리형), Apache 오픈소스
수백 노드 클러스터 운영 사례 (LinkedIn 1조+ 행)
컴포넌트별 독립 확장 가능

4. ClickHouse

4.1 개요

출시: 2016년 (Yandex 오픈소스 공개)
포지션: 범용 고성능 컬럼형 분석 OLAP DB
핵심 철학: 단순성 + 극한 쿼리 속도 + 낮은 운영 비용
주요 사용처: Cloudflare, Uber, ByteDance, eBay, Spotify, Discord

4.2 아키텍처

컬럼형 저장 (MergeTree 패밀리): MergeTree, ReplacingMergeTree, AggregatingMergeTree 등 특수 테이블 엔진
벡터화 실행 엔진 (SIMD 최적화)
공유 없는(Shared-Nothing) 아키텍처 → 클라우드 네이티브 SharedCatalog(2025) 도입
강력한 압축: LZ4, ZSTD, 전용 코덱
분산 쿼리: Distributed 테이블 엔진으로 클러스터 투명 쿼리
2025년: SharedCatalog(중앙집중 메타데이터), 벡터 검색(HNSW) 프로덕션 지원

4.3 장점

단일 테이블 스캔 최강: 수십억 행 풀스캔도 초 단위 응답
뛰어난 압축률: 타 DB 대비 5~10배 공간 절약
쉬운 도입: 단일 바이너리, 설정 단순, 최소 컴포넌트
광범위한 SQL 지원: 복잡한 집계·분석함수·Window function
활발한 생태계: GitHub Star 1위급, ClickHouse Cloud(관리형), 풍부한 커넥터
ClickHouse Cloud: 서버리스, 자동 스케일링

4.4 단점 및 한계

JOIN 성능 한계: 복잡한 다중 JOIN 시 메모리 압박, StarRocks 대비 불리
Upsert/Update 비효율: MUTATION 연산이 무거움, 빈번한 업데이트 비적합
진정한 실시간 수집 아님: 배치 인서트 → 데이터 가시화에 약간의 지연
스키마 변경 비용: 구조 변경 시 전체 재로드 필요한 경우 있음
OLTP 부적합: 트랜잭션 처리 미지원
높은 동시성 환경(100+ 동시 쿼리)에서 성능 저하 가능

4.5 적합한 사용 사례

로그/이벤트 분석: 웹 로그, 애플리케이션 로그 대용량 분석
시계열 메트릭: 시스템 모니터링, APM, 광고 분석
단일 넓은 테이블: 수십~수백 컬럼 풀스캔 집계
애드혹 분석: 개발자/분석가 자유 쿼리
비용 효율 우선: 스토리지·컴퓨팅 비용 최소화

4.6 확장성

ClickHouse Cloud (서버리스, 자동 스케일링, 페타바이트급)
오픈소스 자체 운영: 수평 샤딩+리플리케이션
2025년 SharedCatalog로 클라우드 네이티브 아키텍처 강화

5. StarRocks

5.1 개요

출시: 2020년 (Apache Doris 포크), 2022년 오픈소스 전환
포지션: 고성능 MPP + 실시간 분석 통합 DB (Lakehouse 지원)
핵심 철학: JOIN 최강 + 고동시성 + 레이크하우스 통합
주요 사용처: Airbnb, Shopee, JD.com, Xiaomi

5.2 아키텍처

MPP 아키텍처 (분산 조인 전문)
벡터화 실행 엔진 + Cost-Based Optimizer(CBO)
Primary Key 테이블: 실시간 Upsert 지원
Shared-Data 모드: S3 호환 오브젝트 스토리지 분리 (레이크하우스)
MySQL 프로토콜 호환: 기존 MySQL 드라이버/툴 그대로 사용
External Catalog: Hive, Iceberg, Delta Lake, JDBC 직접 쿼리 가능

5.3 장점

복잡 JOIN 최강: MPP 설계 + CBO로 다중 테이블 조인 압도적 성능
Upsert 효율: Primary Key 테이블로 실시간 데이터 변경 처리
고동시성: ClickHouse 대비 100배 더 많은 동시 세션에서 P95 sub-second 유지
레이크하우스 통합: Iceberg/Delta 직접 쿼리 + 자체 스토리지 혼용
MySQL 호환: 전환 비용 최소화
올인원: 스트리밍 수집, 배치, 애드혹, 대시보드 모두 커버

5.4 단점 및 한계

단일 테이블 스캔: 넓은 평탄 테이블 풀스캔은 ClickHouse가 우세
압축률: ClickHouse 대비 스토리지 효율 낮음
커뮤니티: ClickHouse 대비 작은 생태계 (성장 중)
관리형 서비스: CelerData Cloud (상용), 자체 운영 난이도 중간

5.5 적합한 사용 사례

복잡한 스타 스키마 분석: 다중 테이블 JOIN이 빈번한 데이터 웨어하우스
실시간 가변 데이터: CDC 기반 실시간 Upsert 필요 환경
레이크하우스 구축: S3 + 자체 스토리지 혼용 아키텍처
높은 동시성 분석: 수백~수천 동시 쿼리 환경
MySQL 마이그레이션: 기존 MySQL 스택 분석 레이어 교체

5.6 확장성

Shared-Data 모드로 컴퓨팅·스토리지 독립 확장
CelerData Cloud (관리형), 오픈소스 자체 운영
수십 TB ~ 수 PB 운영 사례

6. Apache Doris

6.1 개요

출시: 2017년 (Baidu 오픈소스), Apache TLP 2022년
관계: StarRocks의 원조 (StarRocks는 Doris PMC 멤버들의 포크)
포지션: 범용 MPP 분석 DB, Doris vs StarRocks 치열한 경쟁 중
주요 사용처: Baidu, Meituan, Xiaomi (중국 테크 기업 주도)

6.2 특징 및 아키텍처

StarRocks와 유사한 MPP 아키텍처
MySQL 완벽 호환 (프로토콜, SQL 방언)
실시간 Upsert (Unique Key 모델)
Apache Iceberg, Hudi, Delta Lake External Catalog 지원
스트리밍 수집 (Kafka Routine Load, Stream Load)

6.3 Doris vs StarRocks 비교

항목 Apache Doris StarRocks

기원	원조	Doris 포크
성능	양호	벤치마크 우세
커뮤니티	Apache 재단	독자 오픈소스
관리형 서비스	SelectDB Cloud	CelerData Cloud
중국 내 인지도	높음	높음
글로벌 인지도	성장 중	성장 중
Lakehouse	지원	더 성숙

6.4 장단점

장점: Apache 재단의 중립적 거버넌스, MySQL 완벽 호환, 배치+스트리밍 통합, 활발한 중국 커뮤니티

단점: StarRocks 대비 일부 벤치마크 열세, 글로벌 생태계 아직 작음, 문서 일부 중국어 위주

6.5 적합한 사용 사례

StarRocks와 거의 동일. Apache 재단 거버넌스 선호, 중국 클라우드(알리바바 등) 사용 환경, SelectDB Cloud 선택 시.

7. DuckDB

7.1 개요

출시: 2018년 (CWI 암스테르담 연구소), 2019년 오픈소스
라이선스: MIT (완전 오픈소스)
포지션: 임베디드 in-process 분석 DB — "분석 분야의 SQLite"
핵심 철학: 서버 없이 애플리케이션/노트북 내에서 즉시 고성능 OLAP 쿼리
주요 사용처: 데이터 과학자, 소규모 팀 분석 파이프라인, 임베디드 분석 앱

7.2 아키텍처

In-process 실행: Python/R/Node.js/Go/Java 라이브러리로 프로세스 내 임베딩. 별도 서버 불필요
벡터화 실행 엔진: SIMD 최적화 컬럼형 처리 (ClickHouse와 유사한 방식)
파일 직접 쿼리: Parquet, CSV, Arrow, JSON, Iceberg, Delta Lake 파일을 네이티브 쿼리 (복사 없음)
MotherDuck: DuckDB의 서버리스 클라우드 관리형 — 로컬↔클라우드 동일 SQL 사용
pg_duckdb: PostgreSQL 내 DuckDB 엔진 임베딩 (DuckDB 분석 엔진을 PG 확장으로 사용)
chDB: ClickHouse 엔진의 임베디드 버전 (DuckDB와 경쟁하는 대안)

7.3 장점

제로 설치: pip/npm/CRAN 패키지 설치만으로 즉시 사용 가능
로컬 분석 최강: 수억 행 Parquet/CSV 파일 단일 노드에서 초 단위 집계
데이터 이동 없음: S3, 로컬 파일, Arrow 메모리, Iceberg를 제자리에서 쿼리
Iceberg 네이티브: Iceberg 테이블 읽기/쓰기 지원 → 레이크하우스 파이프라인 통합
SQL 표준 준수: PostgreSQL 방언 호환 수준의 광범위한 SQL 지원
커뮤니티 성장: GitHub 23K+ Star, ADBC/Arrow 생태계 완전 통합

7.4 단점 및 한계

단일 노드 한계: 페타바이트급 분산 처리 불가. 메모리/디스크 용량이 병목
고동시성 부적합: 수십 명 이상 동시 쿼리 시 성능 저하 (서버 기반 OLAP DB와 경쟁 불가)
Kafka 수집 불가: 실시간 스트리밍 수집 미지원 — 파일/배치 기반 워크로드 전용
공유 워크로드 비적합: 여러 팀이 공유하는 OLAP 서버 역할 부적합
MotherDuck 의존: 클라우드 확장은 MotherDuck 단일 공급자에 의존

7.5 적합한 사용 사례

데이터 과학자 로컬 탐색 분석 (Jupyter 노트북 내 Parquet 쿼리)
소규모 팀 분석 파이프라인 (데이터 변환, ELT 로컬 처리)
임베디드 분석 앱 (애플리케이션 내 경량 OLAP 엔진)
MotherDuck을 통한 클라우드 서버리스 분석 (TB급 이하 팀)
S3/로컬 Iceberg·Parquet 파일 즉석 쿼리 (인프라 없이)

7.6 확장성

단일 노드: RAM + NVMe 디스크 크기가 한계 (수 TB까지 실용적)
MotherDuck: 서버리스 클라우드로 스케일 아웃, 로컬↔클라우드 투명 전환
MotherDuck 가격: 서버리스 쿼리 기반 과금 — 소규모 팀에 최적
한계점: 100TB 이상 또는 수백 동시 쿼리 → ClickHouse/StarRocks로 전환 필요

8. RisingWave

8.1 개요

출시: 2021년 오픈소스 공개
라이선스: Apache 2.0 (완전 오픈소스)
포지션: 스트리밍 데이터베이스 — 스트림 처리(Flink 역할) + OLAP 쿼리(DB 역할) 통합
핵심 철학: Kafka/Kinesis 이벤트를 소비하면서 실시간 Materialized View 유지 + SQL로 즉시 쿼리
주요 사용처: 실시간 대시보드, 이상 탐지, 피처 스토어, Flink + OLAP DB 교체

8.2 아키텍처

PostgreSQL 와이어 프로토콜 호환: 모든 PostgreSQL 드라이버/클라이언트 그대로 사용
Materialized View 엔진: Kafka/Kinesis 스트림에서 직접 소비 → MV 증분 업데이트 → 항상 쿼리 가능
ACID 일관성 보장: 스트리밍 처리 중에도 트랜잭션 일관성 유지
컴퓨팅-스토리지 분리: S3 호환 오브젝트 스토리지 기반 → 탄력적 확장
Kafka/Kinesis/Pulsar 네이티브 커넥터: 소스 직접 연결, 별도 Kafka Connect 불필요
Sink 지원: ClickHouse, StarRocks, Iceberg, S3, RDBMS 등 다양한 싱크 출력

8.3 장점

스트림+쿼리 통합: Flink(스트림 처리) + OLAP DB(쿼리 서빙)를 단일 시스템으로 대체
실시간 집계 즉시 쿼리: MV가 항상 최신 상태 유지 → 별도 집계 작업 불필요
PostgreSQL 호환: 기존 PG 생태계(도구·드라이버·ORM) 그대로 활용
운영 단순화: Flink + OLAP DB + 중간 Kafka 토픽 제거 → 파이프라인 복잡도 대폭 감소
ACID 보장: 스트리밍 환경에서도 데이터 일관성 확보 (Flink 대비 강점)

8.4 단점 및 한계

대규모 배치 분석: 수 PB 히스토리컬 배치 분석은 ClickHouse/StarRocks 대비 미흡
신생 제품: 2021년 출시 — 엔터프라이즈 성숙도·레퍼런스 상대적으로 부족
스트리밍 특화: 배치 ETL·대용량 애드혹 분석보다 스트리밍 집계에 최적화
커뮤니티 규모: ClickHouse/StarRocks 대비 작은 생태계

8.5 적합한 사용 사례

실시간 집계 대시보드 (주문 현황, 재고, KPI 실시간 반영)
이상 탐지·사기 탐지 (실시간 이벤트 → 즉시 룰 평가)
피처 스토어 구축 (ML 모델용 실시간 피처 집계·서빙)
Flink + OLAP DB 아키텍처의 단순화 대안
실시간 리포트 API (PostgreSQL 호환으로 BI 도구 직접 연결)

8.6 확장성

수평 확장: 컴퓨팅 노드 독립 확장 가능
스토리지 분리: S3 기반 → 스토리지 무제한 확장
RisingWave Cloud: AWS/GCP/Azure 완전 관리형, BYOC 지원
요금: RWU(1 vCPU 또는 4GB RAM) 단위 과금 + 스토리지 GB/월
규모: 수 TB~PB 운영 가능, 단 배치 분석보다 스트리밍 집계에서 최고 효율

9. Firebolt

9.1 개요

출시: 2020년 (이스라엘 스타트업)
라이선스: 완전 상용 (오픈소스 없음)
포지션: 클라우드 네이티브 고성능 서버리스 OLAP
핵심 철학: 극한 쿼리 속도 + 완전 서버리스 + 인프라 관리 제로
주요 사용처: 클라우드 네이티브 고성능 분석, 운영 부담 최소화 우선 팀

9.2 아키텍처

Sparse Index: 세그먼트별 최소/최대값 기반 블록 단위 데이터 스킵으로 I/O 최소화
Aggregating Index: 사전 집계 인덱스 — 집계 쿼리 즉시 응답
S3 기반 컴퓨팅-스토리지 완전 분리: 컴퓨팅과 스토리지 독립 스케일링
서버리스 자동 스케일링: 워크로드에 따라 엔진 자동 확장/축소/일시정지
AWS/GCP 기반: 두 클라우드에서 동작, 멀티 리전 지원

9.3 장점

쿼리 속도 최상위권: Sparse Index + Aggregating Index 조합으로 ClickHouse 수준 이상 성능
완전 서버리스: 엔진 미사용 시 자동 일시정지 → 비용 최소화
인프라 관리 불필요: 클러스터 구성·업그레이드·장애 복구 모두 자동
보안 완비: SOC2 Type II, RBAC, MFA(Okta/Auth0 통합), TLS+AES-256
멀티 엔진: 개발/테스트/프로덕션 용도별 엔진 분리 운영 가능

9.4 단점 및 한계

오픈소스 없음: 완전 상용 제품 — 벤더 락인 위험, 공개 가격 없음 (영업 문의 필요)
생태계 제한적: ClickHouse/StarRocks 대비 커넥터·통합 도구 적음
신생 제품: 2020년 출시 — 대형 레퍼런스 상대적으로 부족
가격 불투명: 공개 가격표 없음, 사용량에 따라 비용 예측 어려움

9.5 적합한 사용 사례

클라우드 네이티브 환경에서 운영 부담 없이 고성능 OLAP 필요 시
버스티한 워크로드 (피크 시 자동 확장, 유휴 시 비용 0)
엔터프라이즈 보안·컴플라이언스 요구 팀 (SOC2, RBAC, MFA)
빠른 프로토타이핑 → 프로덕션 전환 (인프라 설정 없이 즉시 시작)

9.6 확장성

서버리스 자동 스케일링: 요청량에 따라 엔진 자동 확장/축소
스토리지: S3 기반 무제한 확장
멀티 엔진: 복수 엔진(개발/프로덕션/임시분석) 병렬 운영
규모: PB급 데이터 처리 가능, 완전 관리형

10. Tinybird

10.1 개요

출시: 2019년 (스페인 스타트업)
라이선스: 완전 상용 (오픈소스 없음)
포지션: ClickHouse 기반 실시간 분석 API 플랫폼
핵심 철학: SQL을 REST API로 자동 변환 — ClickHouse 인프라 없이 고객 직면 분석 API 즉시 구축
주요 사용처: 고객 직면 분석 API, 실시간 대시보드 API, 스트리밍 데이터 API화

10.2 아키텍처

ClickHouse 엔진 기반: 내부적으로 ClickHouse를 사용하여 고성능 컬럼형 쿼리
SQL → REST API 자동 변환: .pipe 파일에 SQL을 작성하면 엔드포인트 자동 생성
실시간 스트리밍 수집: Kafka, Kinesis, HTTP Events API를 통한 실시간 데이터 수집
버전 관리: API·데이터 파이프라인 Git 기반 버전 관리 (CI/CD 통합)
완전 관리형 SaaS: 인프라 없이 클라우드 웹 콘솔에서 전체 구성

10.3 장점

초고속 API 빌딩: SQL만으로 밀리초급 분석 API 수 분 내 구축
ClickHouse 성능: 내부 엔진이 ClickHouse이므로 단일 테이블 집계 쿼리 최고 수준
인프라 관리 제로: ClickHouse 클러스터 운영·튜닝·업그레이드 불필요
개발자 친화적: Git 워크플로우, SQL 기반, REST API 표준 출력
실시간 수집: Kafka/HTTP 이벤트 직접 수신 → 즉시 쿼리 가능

10.4 단점 및 한계

오픈소스 없음: 완전 SaaS, 벤더 종속
복잡 쿼리 한계: ClickHouse 기반이므로 복잡한 다중 JOIN은 여전히 취약
가격 급증 위험: 트래픽·데이터 볼륨 증가 시 비용 급증 가능
커스터마이징 제한: ClickHouse 직접 운영 대비 설정 자유도 낮음

10.5 적합한 사용 사례

고객 직면 분석 API 빠른 구축 (앱 내 실시간 통계·리포트 API)
ClickHouse 인프라 직접 운영 없이 ClickHouse 성능 활용 원하는 팀
스타트업·소규모 팀의 MVP 분석 API (인프라 설정 없이 즉시 시작)
이벤트 스트리밍 → REST API 파이프라인 (Kafka → Tinybird → 앱)

10.6 확장성

완전 관리형 SaaS: Tinybird가 스케일링 자동 처리
ClickHouse 기반: 내부적으로 ClickHouse 수준의 확장성
요금: 데이터 볼륨·API 요청 수 기반 과금 (공개 가격표 존재)
규모: PB급까지 지원 가능 (Tinybird 인프라에 의존)

11. 제품별 종합 비교표

항목 Druid Pinot ClickHouse StarRocks Doris DuckDB RisingWave Firebolt

저장 방식	자체	자체	자체	자체/S3	자체/S3	외부 파일	자체(S3)	자체/S3
실시간 수집	✅ 최강	✅ 최강	△ 배치 지연	✅	✅	❌	✅ (밀리초~초)	△ (배치 중심)
Upsert	❌	✅	△ 무거움	✅	✅	❌	✅ (MV 기반)	△
단일 테이블 쿼리	✅	✅	✅ 최강	✅	✅	✅	△	✅ 최강급
복잡 JOIN	△	△	△ 한계	✅ 최강	✅	✅ (소규모)	△	✅
동시성	높음	최고	중간	높음	높음	낮음	중간	높음
운영 복잡도	높음	높음	낮음	중간	중간	없음	낮음	없음 (완전SaaS)
SQL 표준	부분	부분	높음	높음	높음	높음	높음 (PG호환)	높음
Lakehouse	△	△	△	✅	✅	✅ 최강	✅	✅
오픈소스	✅	✅	✅	✅	✅	✅	✅	❌
관리형 서비스	Imply	StarTree	CH Cloud	CelerData	SelectDB	MotherDuck	RisingWave Cloud	Firebolt Cloud
규모	PB급	PB급	PB급	PB급	TB~PB	TB급	TB~PB	PB급

12. 상황별 제품 선택 가이드

9.1 실시간 이벤트/스트리밍 분석 (append-only, 업데이트 없음)

추천: Apache Druid 또는 Apache Pinot

동시 사용자 수만 명 이상의 사용자 직면 API → Pinot 우선
내부 대시보드, 시계열 이벤트 분석 → Druid 또는 ClickHouse

9.2 로그/메트릭 분석, 애드혹 쿼리

9.3 복잡한 데이터 웨어하우스 쿼리 (다중 JOIN, Star Schema)

추천: StarRocks 또는 Apache Doris

기존 MySQL 스택 → MySQL 호환 덕에 마이그레이션 수월
Lakehouse 통합 필요 시 StarRocks Shared-Data 모드

9.4 실시간 가변 데이터 (CDC, Upsert 필수)

추천: StarRocks (Primary Key) 또는 Apache Pinot (Upsert)

CDC(Change Data Capture) 파이프라인 → StarRocks 우세

9.5 소규모 팀, 빠른 PoC, 로컬 분석

9.6 스트림 처리 + 분석 통합 (Flink 대체)

9.7 완전 서버리스, 운영 부담 제로

추천: ClickHouse Cloud 또는 Firebolt

13. 확장성 비교

제품 확장 방식 컴퓨팅/스토리지 분리 최대 규모

Druid	컴포넌트별 수평 확장	부분 (Deep Storage)	수 PB
Pinot	컴포넌트별 수평 확장	부분	수 PB (LinkedIn 1조+ 행)
ClickHouse	샤딩+리플리케이션	신규 SharedCatalog(2025)	수 PB
StarRocks	Shared-Data 모드	✅ 완전 분리 가능	수 PB
Doris	수평 확장	✅ 지원	수 PB
DuckDB	단일 노드 (MotherDuck은 클라우드)	N/A	수 TB
RisingWave	수평 확장	✅	수 TB~PB

14. 최신 트렌드 (2025~2026)

11.1 Lakehouse 아키텍처 표준화

Apache Iceberg가 사실상 표준 오픈 테이블 포맷으로 자리잡음
모든 주요 OLAP DB(StarRocks, Doris, Druid, Pinot, ClickHouse)가 Iceberg External Catalog 지원
벤더 락인 탈피, 동일 데이터를 여러 엔진에서 쿼리

11.2 벡터 검색 통합 (AI/RAG 지원)

ClickHouse: HNSW 벡터 인덱스 프로덕션 지원 (v25.8)
Apache Pinot: HNSW 벡터 검색 내장
StarRocks, Doris: 벡터 검색 기능 추가 중
의미: OLAP DB가 별도 벡터 DB(Milvus, Weaviate) 없이 AI 파이프라인 직접 통합

11.3 임베디드 OLAP 카테고리 부상

DuckDB 생태계 확산: chDB(ClickHouse), GlareDB, SlateDB
pg_duckdb: PostgreSQL 내 DuckDB 엔진 임베딩
서버 없이 애플리케이션 내 분석 처리 가능

11.4 컴퓨팅-스토리지 분리 (Cloud Native)

StarRocks Shared-Data, ClickHouse SharedCatalog(2025)
스토리지 비용 절감 + 컴퓨팅 탄력적 스케일링
S3 기반 레이크하우스 + OLAP 엔진 패턴 일반화

11.5 AI 통합 분석

자연어 쿼리(Text-to-SQL) 기능 OLAP DB에 직접 탑재 추세
예측 분석, 이상 탐지 ML 모델 인라인 실행

11.6 스트리밍 DB 성장

RisingWave, Materialize 등 스트리밍 DB: Flink + OLAP DB를 단일 시스템으로 대체
실시간 Materialized View + ACID + PostgreSQL 호환 제공

15. 상세 벤치마크 비교

12.1 벤치마크 유형별 특성

벤치마크 측정 내용 특징

ClickBench	단일 대형 테이블(웹 분석 로그) 집계 쿼리 43개	ClickHouse 주도, 단순 풀스캔 강세 측정
TPC-H	복잡한 다중 JOIN 포함 22개 쿼리	데이터 웨어하우스 표준, JOIN 능력 측정
SSB (Star Schema Benchmark)	스타 스키마 기반 집계 쿼리	실무 DW 패턴에 가까운 측정

12.2 ClickBench 결과 (단일 테이블)

ClickHouse 압도적 1위 — 단순 집계 풀스캔 최강, 타 DB 대비 10~100배 빠른 쿼리 존재
Druid는 ClickBench 기준 ClickHouse 대비 3~8배 느림
Pinot은 ClickBench 직접 비교 데이터 제한적 (설계 목적 자체가 다름)

12.3 TPC-H / SSB 결과 (다중 JOIN)

ClickHouse, Apache Druid는 TPC-H 전체 쿼리 셋 완료 불가 (JOIN 한계)
StarRocks가 SSB flat table 기준 ClickHouse 대비 1.87배 빠름 (CBO 기반 JOIN 최적화)
StarRocks vs Druid: SSB 기준 StarRocks가 8.9배 빠름
복잡한 스타 스키마 쿼리에서 StarRocks > ClickHouse > Druid 순

12.4 워크로드 유형별 최강자 요약

워크로드 1위 이유

단일 테이블 풀스캔 집계	ClickHouse	벡터화 실행 + 극한 압축
복잡 다중 JOIN	StarRocks	MPP + CBO 조인 최적화
초저지연 실시간 수집 쿼리	Pinot / Druid	밀리초급 수집-즉시-쿼리
소규모 로컬 분석	DuckDB	단일 노드 벡터화 엔진

16. 실제 도입 사례 (Case Study)

13.1 LinkedIn — Apache Pinot 창시

배경: 수억 명 사용자의 "Who viewed my profile" 등 실시간 분석 기능 제공 필요
선택 이유: 초고동시성(수십만 QPS) + 밀리초 응답 + 실시간 스트리밍 수집
규모: 1조 행 이상, 수백 노드 클러스터
결과: Pinot을 직접 개발 → Apache 오픈소스 기여

13.2 Uber — Pinot + Druid 복합 운영

배경: 실시간 운전자/승객 지표, 재무 대시보드, 이상 탐지 등 다양한 분석 수요
구조: Druid(시계열 이벤트) + Pinot(사용자 직면 API) 병행 운영
최근 변화: Presto 기반 프록시 → Pinot Multi-Stage Engine Lite Mode로 마이그레이션하여 JOIN 성능 개선
Upsert 활용: 재무 대시보드·리스크 모니터링에 실시간 Upsert 사용

13.3 Cloudflare — ClickHouse

배경: 초당 수백만 DNS/HTTP 요청 로그 실시간 분석
선택 이유: 단일 테이블 집계 쿼리 속도, 높은 압축률, 운영 단순성
마이그레이션: 자체 관리 ClickHouse 클러스터 → ClickHouse Enterprise(Alibaba Cloud 관리형) 전환
결과: 연간 컴퓨팅·스토리지 비용 40% 이상 절감

13.4 PostHog — ClickHouse

배경: 오픈소스 제품 분석 플랫폼, 수억 이벤트 저장 필요
선택 이유: 오픈소스, 뛰어난 압축, 이벤트 분석 특화
구조: ClickHouse를 "이벤트 맨션"으로 표현 — 모든 이벤트 데이터의 단일 저장소

13.5 Rokt — ClickHouse (Pinot, Druid, StarRocks 검토 후 선택)

평가 과정: Apache Pinot, Druid, Citus Data, StarRocks, Snowflake 모두 검토
최종 선택: ClickHouse — 단순성, 쿼리 속도, 비용 효율 종합 평가 우위

13.6 Demandbase — CelerData(StarRocks)

전환 결과: StarRocks 기반 CelerData Cloud로 전환 후 스토리지 비용 90% 절감, 하드웨어 사용량 60% 감소
이유: 복잡한 B2B 분석 JOIN 쿼리 + CDC 기반 데이터 변경 처리 필요

13.7 DuckDB / MotherDuck — 소규모 팀 · 임베디드 분석

Dexibit (박물관 분석): MotherDuck으로 전통 데이터 웨어하우스 대체. 고객용 대화형 대시보드 구축, 동일 SQL로 로컬↔클라우드 원활하게 전환
Definite: DuckDB 기반 아키텍처 전환 후 인프라 비용 70% 절감
Gardyn (IoT 분석): MotherDuck 기반 스택이 기존 대안 대비 10배 저렴
Finqore (핀테크): 8시간 걸리던 데이터 파이프라인을 8분으로 단축 — AI 에이전트 실시간 처리 지원
미공개 팀: Snowflake BI 비용 79% 절감 (DuckDB 스마트 캐싱 레이어 활용)

13.8 RisingWave — 스트리밍 DB 도입 사례

SHOPLINE (커머스 플랫폼): 실시간 주문 분석 고객 직면 기능 구현. RisingWave를 스트리밍+히스토리컬 SQL 통합 레이어로 채택
글로벌 금융기관 (수십 조 달러 규모): 미션크리티컬 내부 워크로드에 RisingWave 도입, 전사 확산 중
금융 브로커 리더: 사기 탐지 피처 스토어 구축에 RisingWave 핵심 컴포넌트로 활용 — 데이터 파이프라인 단순화 및 신뢰성 향상
전체 규모: 1,000개 이상 기업·스타트업 도입 (2025 기준)

17. 운영 비용 비교 (TCO)

14.1 비용 구성 요소

비용 유형 설명

인프라 비용	컴퓨팅(EC2/VM) + 스토리지(EBS/S3)
관리형 서비스 요금	클라우드 서비스 마크업
People TCO	엔지니어링 유지보수·온콜 인건비
데이터 전송(Egress)	리전 간·인터넷 데이터 전송 비용

14.2 관리형 서비스 요금 비교

서비스 기반 제품 가격 모델 비고

ClickHouse Cloud	ClickHouse	컴퓨팅 초당 과금 + 스토리지 $35~50/TB	개발: $1~193/월, 프로덕션: $500~$100,000/월
Altinity.Cloud	ClickHouse (100% 오픈소스)	BYOC (AWS/GCP/Azure)	프로프라이어터리 수정 없음, 엔터프라이즈 SLA
CelerData Cloud	StarRocks	컴퓨팅+스토리지 분리 과금	Demandbase 사례: 스토리지 90% 절감
StarTree Cloud	Apache Pinot	컴퓨팅+스토리지 분리 과금	LinkedIn 팀 주도
Imply Cloud	Apache Druid	컴퓨팅+스토리지 분리 과금	Druid 원조 팀
SelectDB Cloud	Apache Doris	컴퓨팅+스토리지 분리 과금	중국 클라우드 친화
MotherDuck	DuckDB	서버리스, 쿼리 기반 과금	소규모 팀 최적
RisingWave Cloud	RisingWave	RWU(1 vCPU 또는 4GB RAM) 단위 과금 + 스토리지 GB/월	완전 관리형 또는 BYOC, Pay-as-you-go/연간 계약 선택
Firebolt	Firebolt (완전 상용)	AWS/GCP 기반 SaaS, 영업 문의 (공개 가격 없음)	오픈소스 없음, SOC2 Type II, 엔터프라이즈 전용

14.3 자체 운영 vs 관리형 TCO 판단 기준

People TCO: 엔지니어링 유지보수·온콜 인건비 월 $1,600~$4,800 추가 발생 — 소규모 팀에서는 관리형이 유리
ClickHouse Cloud vs Snowflake: ClickHouse Cloud 기준 Snowflake 대비 약 4배 낮은 TCO (극한 압축률 덕분)
자체 운영 권장 조건: 전담 DBA/인프라 팀 존재, 페타바이트급 대규모, 커스텀 하드웨어 최적화 필요 시
관리형 권장 조건: 소규모 팀, 빠른 시작, 버스티한 워크로드, 인프라 운영 부담 최소화 필요 시

18. 데이터 수집(Ingestion) 파이프라인 패턴

15.1 Kafka 직접 수집 패턴

DB 수집 방식 지연 특징

Apache Pinot	Consuming Segments	밀리초	행 단위 수집, 즉시 쿼리 가능
Apache Druid	Kafka Indexing Service	밀리초~초	세그먼트 단위, 수집 즉시 쿼리
ClickHouse	Kafka Table Engine + MV	초~분	마이크로배치, 일정 지연 존재
StarRocks	Kafka Routine Load	초	안정적 초 단위 수집
Apache Doris	Kafka Routine Load	초	StarRocks와 유사
RisingWave	Kafka/Kinesis Native Connector + Materialized View	밀리초~초	스트림 처리 + 집계 동시 수행, MV 즉시 쿼리 가능
DuckDB	해당 없음 (Kafka 직접 수집 불가)	N/A	파일/S3/Iceberg 직접 읽기 전용 — 스트리밍 수집 미지원
Firebolt	Kafka Connect, S3 External Tables	초~분	배치 중심, 완전 서버리스 자동 처리

15.2 CDC (Change Data Capture) 파이프라인

표준 아키텍처: Source DB → Debezium → Kafka → OLAP DB

ClickHouse CDC: Debezium → Kafka → ClickHouse Kafka Connect → Materialized View로 실시간 반영. 2024년 "Lightweight Updates" 도입으로 CDC 실용성 획기적 개선 (100초 → 60ms, 1,600배 향상)
StarRocks CDC: Primary Key 테이블의 Upsert 기능으로 CDC 스트림 네이티브 처리. 실시간 변경 반영에 최적화
Pinot CDC: Upsert 테이블로 CDC 지원. Primary Key 기반 실시간 업데이트
Druid CDC: 미지원 — append-only 설계, CDC 필요 시 다른 제품 고려 필요

15.3 배치 수집 패턴

S3/HDFS → OLAP: StarRocks, Doris, ClickHouse 모두 S3 직접 로드 지원
Spark → OLAP: StarRocks Spark Connector, ClickHouse Spark Connector 제공
Flink → OLAP: 실시간 집계 후 OLAP으로 적재 (StarRocks Flink Connector 공식 지원)

15.4 하이브리드 Lambda/Kappa 아키텍처

Lambda: 배치(Hadoop/Spark) + 실시간(Kafka→OLAP) 병행 → 복잡도 높음
Kappa: Kafka 단일 스트림으로 배치+실시간 통합 → RisingWave, StarRocks가 이 패턴 지원
트렌드: Kappa 아키텍처 + 오픈 테이블 포맷(Iceberg)으로 통합 단순화 추세

19. 보안 및 거버넌스

16.1 컴플라이언스 인증 현황

제품 SOC2 ISO 27001 HIPAA GDPR 비고

ClickHouse Cloud	✅ Type II	✅	✅	✅	U.S. DPF 포함
StarTree (Pinot)	✅	-	-	✅	관리형 기준
CelerData (StarRocks)	✅	-	-	✅	관리형 기준
Imply (Druid)	✅	-	-	✅	관리형 기준
MotherDuck (DuckDB)	✅ Type II	-	-	✅	서비스 계정 토큰 기반 접근 제어, Business Plan
RisingWave Cloud	✅	-	✅	✅	완전 관리형 또는 BYOC
Firebolt	✅ Type II	-	-	✅	RBAC, MFA(Okta/Auth0), TLS+AES-256
오픈소스 자체 운영	❌ (직접 구현 필요)	-	-	기능 제공	GDPR 삭제권 등 직접 구현

16.2 접근 제어 (RBAC)

ClickHouse: 세분화된 RBAC — 데이터베이스·테이블·시스템 리소스 수준 SELECT/INSERT/CREATE 권한 개별 부여/회수
StarRocks: RBAC 지원, 행/열 수준 보안(Row-level Security, Column Masking) 엔터프라이즈 기능
Apache Pinot: 테이블 수준 접근 제어, 멀티 테넌시 지원
Apache Druid: 기본 인증·인가 + Ranger 플러그인으로 세분화 제어 가능
Firebolt: 계층적 RBAC, MFA(Okta/Auth0 통합), TLS 전송 암호화 + AES-256 저장 암호화
MotherDuck(DuckDB): 서비스 계정 토큰 기반 읽기/쓰기 분리 접근 제어, 리드 스케일링 레플리카
RisingWave Cloud: PostgreSQL 호환 권한 모델 (GRANT/REVOKE), 멀티 테넌시 지원

16.3 GDPR 대응 — 삭제권(Right to Erasure)

StarRocks / Doris: Primary Key 테이블의 DELETE 연산으로 특정 사용자 데이터 효율적 삭제 가능
ClickHouse: ALTER TABLE DELETE (Mutation) — 무거우나 가능. 2024년 Lightweight Delete로 개선
Apache Druid: 세그먼트 단위 삭제만 가능, 행 단위 삭제 어려움 → GDPR 대응 비적합
Apache Pinot: Upsert/Delete 지원으로 행 단위 삭제 가능

16.4 데이터 마스킹 및 감사

ClickHouse: 컬럼 마스킹 정책, 쿼리 로그 기반 감사
StarRocks: Dynamic Column Masking (엔터프라이즈), Audit Log Plugin
공통: TLS/SSL 암호화 전송, 저장 데이터 암호화(AES-256) 클라우드 관리형에서 기본 제공

20. Hadoop 생태계 변화와 이전 전략

17.1 Hadoop 쇠퇴 배경

2019년: Cloudera + Hortonworks 합병 → Hadoop 상용 에코시스템 통합
근본 한계: 온디맨드 쿼리 부재, 동적 스키마 미지원, 클라우드 네이티브 기술과 호환성 부족
Impala/Hive의 현재: Hadoop 의존성으로 클라우드 네이티브 전환 시 입지 약화. Impala는 Hadoop 없이 독립 운영 사실상 불가
시장 규모: Hadoop 시장은 2025년 약 $8B 규모로 유지되나, 신규 도입은 크게 감소

17.2 클라우드 네이티브 전환 시 대안 선택지

기존 역할 클라우드 네이티브 대안

Hive (배치 SQL)	Trino / Spark SQL + Iceberg
Impala (대화형 SQL)	Trino, Presto, StarRocks(External Catalog)
HBase (실시간 KV)	Apache Cassandra, DynamoDB
HDFS (분산 스토리지)	S3, GCS, Azure Blob + Iceberg
MapReduce (배치 처리)	Apache Spark, Flink
Druid on Hadoop	Druid on Kubernetes + S3 Deep Storage

17.3 Hadoop → 클라우드 네이티브 전환 효과

쿼리 레이턴시 및 동시성 30~70% 개선 (실측 사례)
인프라 운영 비용 절감 (온프레미스 서버 → 클라우드 탄력적 과금)
Apache Iceberg + Trino/StarRocks 조합이 현재 가장 일반적인 마이그레이션 패턴
Snowflake/AWS/GCP 네이티브 서비스로의 완전 이관도 활발 (특히 Hive → Snowflake)

21. HTAP (Hybrid Transactional/Analytical Processing) 동향

18.1 HTAP 개념

OLTP(트랜잭션 처리)와 OLAP(분석 처리)를 단일 시스템에서 제공하는 아키텍처. 실시간 의사결정(사기 탐지, 가격 최적화, 개인화)에 필요한 최신 데이터 즉시 분석 가능.

18.2 주요 HTAP 제품

TiDB (PingCAP)

아키텍처: TiKV (Row 스토어, OLTP) + TiFlash (Column 스토어, OLAP) 듀얼 엔진
TiKV는 CNCF 졸업 프로젝트, 완전 오픈소스
같은 데이터를 Row 형태(OLTP용)와 Column 형태(OLAP용)로 동시 유지
실시간 분석 + 트랜잭션을 단일 SQL로 처리

SingleStore (구 MemSQL)

아키텍처: 각 노드에 인메모리 Row 스토어 + Column 스토어 + 디스크 파일 혼용
MySQL 호환, 분산 아키텍처
실시간 수집 + 분석 쿼리 동시 처리 최적화

StarRocks / Apache Doris의 HTAP 접근

순수 HTAP는 아니나 Primary Key + 실시간 수집 + 물화 뷰로 유사 사용 사례 커버
10,000+ QPS + 신선한 데이터 + 고동시성 BI 쿼리 지원

18.3 시장 현황 (2025)

HTAP는 이론적으로 매력적이나 실제 도입은 제한적
클라우드 DW(Snowflake, BigQuery)가 분석 시장의 주도권을 가져가면서 순수 HTAP 포지셔닝이 약화
현실적 트렌드: OLTP(PostgreSQL/MySQL) + CDC + OLAP DB 조합이 HTAP 단일 시스템보다 더 널리 사용됨
사기 탐지, 실시간 추천 등 극한 레이턴시 요구 시에만 TiDB/SingleStore 선택 유효

22. 오픈소스 vs 상용 관리형 서비스 비교

19.1 기능 차이 (ClickHouse 기준 대표 사례)

기능 오픈소스 자체 운영 ClickHouse Cloud (관리형)

코어 쿼리 엔진	✅ 동일	✅ 동일
자동 스케일링	❌ 수동	✅
자동 리플리케이션/페일오버	❌ 수동 설정	✅
자동 백업	❌ 수동	✅
SharedMergeTree (컴퓨팅-스토리지 분리)	❌	✅ Cloud 전용
Lightweight UPDATE	❌	✅ Cloud 전용
S3 Role-based Access	❌	✅
모니터링/대시보드	❌ 외부 도구 필요	✅ 내장
보안 인증 (SOC2 등)	❌ 직접 구현	✅

19.2 제품별 오픈소스 vs 관리형 포지셔닝

제품 오픈소스 관리형 서비스 오픈코어 여부

ClickHouse	Apache 2.0	ClickHouse Cloud, Altinity.Cloud	일부 Cloud 전용 기능 존재
Apache Pinot	Apache 2.0	StarTree Cloud	완전 오픈소스 기반
Apache Druid	Apache 2.0	Imply Cloud	완전 오픈소스 기반
StarRocks	Apache 2.0	CelerData Cloud	오픈소스 완전 포함
Apache Doris	Apache 2.0	SelectDB Cloud	완전 오픈소스 기반
DuckDB	MIT	MotherDuck	완전 오픈소스 기반
RisingWave	Apache 2.0	RisingWave Cloud (AWS/GCP/Azure BYOC 포함)	완전 오픈소스 기반
Firebolt	❌ 없음 (완전 상용)	Firebolt Cloud (AWS/GCP)	오픈소스 버전 없음 — 관리형 전용
Tinybird	❌ 없음 (완전 상용)	Tinybird Cloud (ClickHouse 기반)	오픈소스 버전 없음 — API 플랫폼 전용

19.3 자체 운영 권장 vs 관리형 권장 기준

자체 운영이 유리한 경우

전담 DBA·인프라 팀 보유
페타바이트급 대규모 (관리형 비용이 자체보다 높아지는 시점)
특수 하드웨어(고성능 NVMe, 대용량 RAM) 최적화 필요
데이터 주권 규정으로 외부 클라우드 저장 불가

관리형이 유리한 경우

소규모 팀(5인 이하 엔지니어링)
빠른 프로덕션 출시 필요 (수 시간 내 클러스터 구성)
버스티한 워크로드 (자동 스케일 업/다운)
People TCO($1,600~$4,800/월) 대비 관리형 요금이 저렴한 경우

19.4 Altinity — 100% 오픈소스 엔터프라이즈 대안

ClickHouse 오픈소스를 그대로 사용 (프로프라이어터리 수정 없음)
BYOC (AWS/GCP/Azure 고객 계정 내 배포)
24/7 SLA, 핵심 ClickHouse 기여자 팀 운영
오픈소스 통제권 + 관리형 편의성을 동시에 원하는 팀에 적합

레퍼런스

공식 문서 및 홈페이지

벤치마크

제품 비교 분석

아키텍처 및 기술 심층 분석

도입 사례 (Case Studies)

운영 비용 및 관리형 서비스

데이터 수집 및 CDC

보안 및 거버넌스

Hadoop 생태계 및 마이그레이션

HTAP

SQL 안티패턴 감지

불곰1 — Tue, 28 Apr 2026 01:48:38 +0900

목표

사용자의 SQL 쿼리를 실행 전/후로 분석하여 안티패턴을 감지하고 튜닝 포인트를 제공합니다.

Dry-run — 실제 실행 없이 쿼리 구조를 정적 분석
필수 규칙 강제 — Critical 안티패턴은 차단 또는 강한 경고
실행 전 튜닝 포인트 — 정적 분석 / EXPLAIN 기반 개선 제안
실행 후 튜닝 포인트 — 실행 통계 기반 병목 진단

참고 도구 분석

도구 안티패턴 수 플랫폼 접근 방식

BigQuery Anti-Pattern Recognition	11개	BigQuery 전용	AST 정적 분석 (ZetaSQL 파서)
sqlcheck	29개	범용 RDBMS	CLI 정적 분석 (C++)
AltimateAI / altimate-code	19개	10개 웨어하우스 (Snowflake·BQ·Databricks 등)	AI 기반 + 정적 분석
sqlglot	—	31개 방언 (Trino·Databricks·Snowflake 등)	Python 파서·트랜스파일러 (자체 구현 기반)

BigQuery Anti-Pattern Recognition

구글이 공식 오픈소스로 제공한 도구입니다. ZetaSQL 파서로 AST를 분석하고, 실제 쿼리 실행 없이 안티패턴을 탐지합니다.

감지 안티패턴 11개

# 이름 설명

1	SimpleSelectStar	SELECT * — 불필요한 전체 컬럼 조회
2	SemiJoinWithoutAggregation	IN 필터 서브쿼리에서 DISTINCT 누락
3	MultipleCTEReferences	동일 CTE를 2회 이상 참조 (재연산 발생)
4	OrderByWithoutLimit	LIMIT 없는 ORDER BY
5	RegexpContainsUsage	REGEXP_CONTAINS 대신 LIKE 사용 권고
6	LatestRecordWithAnalyticFun	ROW_NUMBER()로 최신 레코드 필터링
7	DynamicPredicate	서브쿼리 필터 → 정적 술어로 변환 권고
8	WhereOrder	WHERE 절 필터 순서 — 선택도 높은 조건 우선
9	JoinOrder	테이블 크기 기반 JOIN 순서 최적화
10	MissingDropStatement	TEMP 테이블 생성 후 DROP 누락
11	DroppedPersistentTable	스크립트 끝에서 영구 테이블 삭제 감지

설치

# 사전 조건: JDK 11+, Maven, Docker, gcloud CLI
gcloud auth application-default login
git clone <https://github.com/GoogleCloudPlatform/bigquery-antipattern-recognition.git>
cd bigquery-antipattern-recognition

# Docker 이미지 빌드
mvn clean package jib:dockerBuild -DskipTests

# 또는 JAR 직접 다운로드
wget <https://github.com/GoogleCloudPlatform/bigquery-antipattern-recognition/releases/download/v1.0.0/bigquery-antipattern-recognition.jar>

입력 옵션 (Input Flags)

플래그 설명

--query "SELECT ..."	CLI에서 SQL 문자열 직접 입력
--read_from_info_schema	INFORMATION_SCHEMA.JOBS에서 쿼리 읽기
--read_from_info_schema_days N	읽을 기간 (기본값: 1일)
--info_schema_project <project>	분석 대상 프로젝트
--info_schema_region us	리전 지정
--read_from_info_schema_start_time "timestamp"	시작 시간 지정
--read_from_info_schema_end_time "timestamp"	종료 시간 지정
--info_schema_top_n_percentage_of_jobs N	상위 슬롯 소비 비율 (0~1, 예: 0.1 = 상위 10%)
--input_bq_table project.dataset.table	BigQuery 테이블에서 읽기 (컬럼: id, query)
--input_file_path /path/to/file.sql	로컬 또는 GCS 파일에서 읽기
--input_folder_path /path/to/folder	폴더 내 전체 .sql 파일 파싱
--input_csv_file_path /path/to/file.csv	CSV 파일에서 읽기 (컬럼: id, query)

출력 옵션 (Output Flags)

플래그 설명

--output_file_path /path/to/output.csv	CSV 파일로 출력
--output_table "project.dataset.table"	BigQuery 테이블에 결과 저장 (사전 생성 필요)
--rewrite_sql	Vertex AI로 최적화된 SQL 자동 재작성 (실험 기능)
--processing_project_id <project>	INFORMATION_SCHEMA 조회 및 결과 저장 프로젝트

실행 예시

인라인 쿼리 분석 (Docker)

docker run -i bigquery-antipattern-recognition \\
  --query "SELECT * FROM \\`project.dataset.orders\\` WHERE YEAR(created_at) = 2024"

# 출력 예시
SimpleSelectStar: SELECT * at line 1. All columns on table are being selected.
Non-sargable predicate: YEAR(created_at) at line 1 disables partition pruning.

인라인 쿼리 분석 (JAR)

java -jar bigquery-antipattern-recognition.jar \\
  --query "SELECT * FROM \\`project.dataset.table1\\`"

INFORMATION_SCHEMA → BigQuery 테이블 저장

docker run -v ~/.config:/root/.config -i bigquery-antipattern-recognition \\
  --read_from_info_schema \\
  --info_schema_project my-project \\
  --info_schema_region us \\
  --read_from_info_schema_days 7 \\
  --info_schema_top_n_percentage_of_jobs 0.1 \\
  --processing_project_id my-project \\
  --output_table "my-project.dataset.antipattern_output"

AI 기반 SQL 자동 재작성

docker run -v ~/.config:/root/.config -i bigquery-antipattern-recognition \\
  --query "SELECT col1 FROM table1 WHERE col2 LIKE '%abc%' AND col3 = 1" \\
  --rewrite_sql \\
  --processing_project_id my-project

로컬 파일 → CSV 출력

docker run -v /local/path:/data -i bigquery-antipattern-recognition \\
  --input_file_path /data/query.sql \\
  --output_file_path /data/output.csv

폴더 내 전체 SQL 파일 분석

docker run -v /local/path:/data -i bigquery-antipattern-recognition \\
  --input_folder_path /data/sql_files \\
  --output_file_path /data/output.csv

출력 테이블 DDL

CREATE OR REPLACE TABLE `project.dataset.antipattern_output_table` (
  job_id            STRING,
  user_email        STRING,
  query             STRING,
  recommendation    ARRAY<STRUCT<name STRING, description STRING>>,
  slot_hours        FLOAT64,
  optimized_sql     STRING,
  process_timestamp TIMESTAMP
);

결과 조회 쿼리

SELECT job_id, user_email, query, recommendation, slot_hours
FROM `project.dataset.antipattern_output_table`
ORDER BY slot_hours DESC
LIMIT 100;

sqlcheck

범용 SQL 안티패턴 탐지 CLI 도구 (C++)입니다. 29개 패턴을 4개 카테고리로 분류하여 분석합니다.

쿼리 안티패턴 16개 (실무 관련도 높음)

코드 이름 설명

3001	SELECT *	전체 컬럼 조회
3002	NULL Usage	NULL 오용
3004	String Concatenation	문자열 연결 성능
3005	GROUP BY Usage	GROUP BY 오용
3006	ORDER BY RAND	RAND() 정렬 — 전체 스캔
3007	Pattern Matching	앞자리 와일드카드 LIKE '%...'
3008	Spaghetti Query	지나치게 복잡한 단일 쿼리
3009	Reduce JOINs	과도한 JOIN
3010	Unnecessary DISTINCT	불필요한 DISTINCT
3012	HAVING Clause	HAVING 절 오용 (WHERE로 대체 가능)
3013	Nested Subqueries	중첩 서브쿼리
3014	OR Usage	OR 연산자 — 인덱스 미활용
3015	UNION Usage	UNION (UNION ALL 권고)
3016	DISTINCT & JOIN	DISTINCT + JOIN 조합

설치

# macOS (DMG)
wget <https://github.com/jarulraj/sqlcheck/releases/download/v1.3/sqlcheck-x86_64.dmg>
cp /Volumes/sqlcheck-x86_64/bin/sqlcheck /usr/local/bin/

# Ubuntu/Debian (.deb)
wget <https://github.com/jarulraj/sqlcheck/releases/download/v1.3/sqlcheck-x86_64.deb>
dpkg -i sqlcheck-x86_64.deb

# CentOS/Fedora (.rpm)
wget <https://github.com/jarulraj/sqlcheck/releases/download/v1.3/sqlcheck-x86_64.rpm>
yum --nogpgcheck localinstall sqlcheck-x86_64.rpm

# 소스 빌드 (g++ 4.9+, CMake 필요)
git clone --recursive <https://github.com/jarulraj/sqlcheck.git>
./bootstrap
cd build && cmake -DCMAKE_BUILD_TYPE=RELEASE .. && make && make install

CLI 플래그

플래그 설명

-f, --file_name	분석할 SQL 파일 경로
-r, --risk_level	탐지 위험도 필터 (1: 전체, 2: MEDIUM 이상, 3: HIGH만)
-c, --color_mode	컬러 출력 활성화
-v, --verbose_mode	상세 정보 출력
--stdin	표준 입력에서 SQL 읽기

실행 예시

SQL 파일 분석

sqlcheck -f my_query.sql

-------------------------------------------------
SQL ANTI-PATTERN REPORT :: my_query.sql
-------------------------------------------------

[my_query.sql]: (HIGH RISK) (QUERY ANTI-PATTERN) SELECT *
Never use * in a SELECT. Always list out the columns needed.
Pattern: SELECT *

[my_query.sql]: (LOW RISK) (QUERY ANTI-PATTERN) SPAGHETTI QUERY ALERT
This query is too complex. Consider splitting into simpler queries.

======================
Total Anti-Patterns: 2
High Risk: 1  Medium Risk: 0  Low Risk: 1

상세 출력 + 색상 모드

sqlcheck -f my_query.sql -v -c

HIGH 위험도만 탐지

sqlcheck -f my_query.sql -r 3

파이프 입력 (stdin)

echo "SELECT * FROM orders JOIN customers ON 1=1" | sqlcheck --stdin

여러 파일 일괄 분석

for f in ./queries/*.sql; do
  echo "=== $f ==="
  sqlcheck -f "$f" -r 2
done

CI/CD 파이프라인 연동

# 안티패턴 발견 시 비정상 종료 → CI 실패 처리 가능
sqlcheck -f migration.sql -r 3 || exit 1

위험도 레벨

레벨 범위 언제 사용

1	LOW 이상 전체	코드 리뷰 시
2	MEDIUM 이상	일반 개발 환경
3	HIGH만	CI/CD 게이트, 배포 전 필수 체크

AltimateAI / altimate-code

AI 기반 데이터 엔지니어링 도구입니다. 10개 웨어하우스를 지원하며, Claude Code 통합이 가능합니다.

탐지 안티패턴 (19개 규칙, 신뢰도 점수 포함)

SELECT *
카르테시안 조인 (조건 없는 JOIN)
Non-sargable 조건절 (함수가 필터 컬럼에 적용)
상관 서브쿼리 (Correlated Subquery)
- 15개 추가 규칙

지원 플랫폼

Snowflake, BigQuery, Databricks, PostgreSQL, Redshift, ClickHouse, DuckDB, MySQL, SQL Server, Oracle, SQLite, MongoDB

주요 기능

FinOps 분석: 비용 소비 쿼리 탐지, 웨어하우스 크기 최적화
열 수준 계보: 조인/CTE/서브쿼리를 통해 컬럼 추적
dbt 통합: 매니페스트 파싱, 테스트 생성, 영향 분석
교차 방언 변환: Snowflake ↔ BigQuery ↔ Databricks SQL 자동 변환
PII 감지: 30+ 패턴으로 민감 정보 스캔

설치

npm install -g altimate-code

# LLM API 키 설정 (하나 이상 필요)
export ANTHROPIC_API_KEY=your_key
export OPENAI_API_KEY=your_key

초기 설정

altimate
/connect        # LLM 공급자 선택 및 API 키 입력
/discover       # dbt 프로젝트, 웨어하우스 연결 자동 감지
/configure-claude  # Claude Code와 연동

데이터베이스 연결 방식

# ~/.dbt/profiles.yml 자동 감지 또는 직접 설정
my_snowflake:
  type: snowflake
  account: myorg.us-east-1
  user: myuser
  password: "{{ env_var('SNOWFLAKE_PASSWORD') }}"
  database: MY_DB
  schema: PUBLIC
  warehouse: MY_WH

에이전트 모드

모드 역할 권한 권장 환경

Analyst	데이터 탐색, SELECT 쿼리	읽기 전용	프로덕션 (안전)
Builder	dbt 모델/SQL 파이프라인 생성	읽기/쓰기 (DROP 금지)	개발 환경
Plan	접근 방식 수립만	파일 읽기만	설계 단계

주요 CLI 명령어 사용 예시

안티패턴 탐지

> Analyze this query for issues:
  SELECT * FROM orders o
  JOIN customers c ON o.id = c.order_id
  WHERE YEAR(o.created_at) = 2024
  ORDER BY o.total_amount

[HIGH] SELECT * detected — specify required columns (confidence: 98%)
[HIGH] Non-sargable predicate: YEAR(created_at)
  → Fix: created_at >= '2024-01-01' AND created_at < '2025-01-01'
[MAJOR] ORDER BY without LIMIT — full sort on potentially large dataset
  → Fix: add LIMIT clause or use window function

SQL 방언 변환

> /sql-translate this Snowflake query to Databricks:
  SELECT DATEADD(day, 7, CURRENT_DATE()), ZEROIFNULL(revenue) FROM sales

dbt 테스트 자동 생성

> /generate-tests for models/staging/stg_orders.sql

비용 리포트 조회

> /cost-report

컬럼 계보 추적

> Trace column lineage for customer_id in fact_orders

PII 탐지

> Scan schema my_schema for PII columns

지원 LLM

Anthropic Claude · OpenAI · Google Gemini · Amazon Bedrock · Azure OpenAI · Mistral · Groq · Ollama

sqlglot (자체 구현 시 파서 기반)

Python SQL 파서 및 트랜스파일러입니다. Trino·Databricks·Snowflake 등 31개 방언을 공식 지원하며, 자체 안티패턴 엔진 구현 시 기반으로 활용합니다.

설치

pip install sqlglot

# C 확장 버전 (성능 향상)
pip install "sqlglot[c]"

지원 방언 (주요)

방언 지정 키워드

Trino	"trino"
Databricks	"databricks"
Snowflake	"snowflake"
BigQuery	"bigquery"
Spark SQL	"spark"
Presto	"presto"
DuckDB	"duckdb"
PostgreSQL	"postgres"

기본 파싱

import sqlglot
from sqlglot import exp, parse_one

# 방언을 명시해야 정확한 파싱이 가능합니다
ast = parse_one(
    "SELECT * FROM orders WHERE YEAR(created_at) = 2024 ORDER BY id",
    dialect="trino"
)

AST 순회 방법

# find: 첫 번째 매칭 노드 반환
order = ast.find(exp.Order)

# find_all: 모든 매칭 노드 반환
for col in ast.find_all(exp.Column):
    print(col.alias_or_name)

# walk: 전체 노드 순회
for node in ast.walk():
    if isinstance(node, exp.Star):
        print("SELECT * 발견")

안티패턴 탐지 예시 코드

from sqlglot import exp, parse_one
from dataclasses import dataclass
from typing import List

@dataclass
class Issue:
    severity: str   # CRITICAL / MAJOR / MINOR
    message: str
    suggestion: str

def detect_antipatterns(query: str, dialect: str = "trino") -> List[Issue]:
    ast = parse_one(query, dialect=dialect)
    issues = []

    # [CRITICAL] SELECT *
    for node in ast.find_all(exp.Star):
        issues.append(Issue(
            severity="CRITICAL",
            message="SELECT * 사용 — 불필요한 전체 컬럼 조회",
            suggestion="필요한 컬럼만 명시하세요"
        ))

    # [CRITICAL] Cartesian JOIN (조건 없는 JOIN)
    for join in ast.find_all(exp.Join):
        if not join.args.get("on") and not join.args.get("using"):
            if str(join.args.get("kind", "")).upper() not in ("CROSS",):
                issues.append(Issue(
                    severity="CRITICAL",
                    message="조건 없는 JOIN 감지 — Cartesian product 발생 가능",
                    suggestion="ON 또는 USING 조건을 추가하세요"
                ))

    # [CRITICAL] Non-sargable predicate (WHERE 절 함수 적용)
    where = ast.find(exp.Where)
    if where:
        for func in where.find_all(exp.Func):
            if any(isinstance(c, exp.Column) for c in func.find_all(exp.Column)):
                issues.append(Issue(
                    severity="CRITICAL",
                    message=f"WHERE 절 함수 적용: {func.sql()} — 파티션 프루닝 불가",
                    suggestion="함수를 우변으로 이동하거나 범위 조건으로 변환하세요"
                ))

    # [MAJOR] ORDER BY without LIMIT
    if ast.find(exp.Order) and not ast.find(exp.Limit):
        issues.append(Issue(
            severity="MAJOR",
            message="ORDER BY에 LIMIT 없음 — 전체 데이터 정렬 발생",
            suggestion="LIMIT 절을 추가하세요"
        ))

    # [MAJOR] UNION (UNION ALL 권고)
    for union in ast.find_all(exp.Union):
        if not isinstance(union, exp.UnionAll):
            issues.append(Issue(
                severity="MAJOR",
                message="UNION 사용 — 중복 제거 정렬 비용 발생",
                suggestion="중복 허용 시 UNION ALL로 변경하세요"
            ))

    return issues

# 실행 예시
query = """
    SELECT *
    FROM orders o
    JOIN customers c ON 1=1
    WHERE YEAR(o.created_at) = 2024
    ORDER BY o.id
"""

for issue in detect_antipatterns(query, dialect="trino"):
    print(f"[{issue.severity}] {issue.message}")
    print(f"  → {issue.suggestion}")
    print()

[CRITICAL] SELECT * 사용 — 불필요한 전체 컬럼 조회
  → 필요한 컬럼만 명시하세요

[CRITICAL] 조건 없는 JOIN 감지 — Cartesian product 발생 가능
  → ON 또는 USING 조건을 추가하세요

[CRITICAL] WHERE 절 함수 적용: YEAR(o.created_at) — 파티션 프루닝 불가
  → 함수를 우변으로 이동하거나 범위 조건으로 변환하세요

[MAJOR] ORDER BY에 LIMIT 없음 — 전체 데이터 정렬 발생
  → LIMIT 절을 추가하세요

방언 간 SQL 변환

import sqlglot

# Snowflake → Trino 변환
result = sqlglot.transpile(
    "SELECT DATEADD(day, 7, CURRENT_DATE()), ZEROIFNULL(revenue) FROM sales",
    read="snowflake",
    write="trino"
)[0]
print(result)
# → SELECT DATE_ADD('day', 7, CURRENT_DATE), COALESCE(revenue, 0) FROM sales

# Databricks → Snowflake 변환
result = sqlglot.transpile(
    "SELECT DATE_FORMAT(order_date, 'yyyy-MM-dd') FROM orders",
    read="databricks",
    write="snowflake"
)[0]
print(result)

구문 오류 탐지

import sqlglot

try:
    sqlglot.transpile("SELECT foo FROM (SELECT baz FROM t")
except sqlglot.errors.ParseError as e:
    for err in e.errors:
        print(f"Line {err['line']}, Col {err['col']}: {err['description']}")
        print(f"Context: ...{err['start_context']}{err['highlight']}...")

Line 1, Col 34: Expecting )
Context: ...SELECT foo FROM (SELECT baz FROM t...

Scope API (서브쿼리·CTE 정확한 분석)

from sqlglot import parse_one, exp
from sqlglot.optimizer.scope import build_scope

query = """
WITH cte AS (SELECT id FROM orders)
SELECT * FROM cte JOIN cte AS cte2 ON cte.id = cte2.id
"""

ast = parse_one(query, dialect="trino")
root = build_scope(ast)

# CTE 중복 참조 탐지
for scope in root.traverse():
    cte_refs = {}
    for name, (node, source) in scope.selected_sources.items():
        if isinstance(source, exp.Subquery):
            cte_name = source.alias
            cte_refs[cte_name] = cte_refs.get(cte_name, 0) + 1

    for cte_name, count in cte_refs.items():
        if count >= 2:
            print(f"[MAJOR] CTE '{cte_name}' 중복 참조 ({count}회) — 반복 연산 발생")

통합 안티패턴 카탈로그

Critical — 반드시 수정 (실행 차단 권고)

안티패턴 설명 영향

SELECT *	전체 컬럼 조회	스캔 비용 폭증, 컬럼 추가 시 부작용
Cartesian JOIN	조건 없는 JOIN (CROSS JOIN)	행 수 곱 증가 → OOM·무한 실행
Non-sargable predicate	필터 컬럼에 함수 적용: WHERE YEAR(date) = 2024	파티션 프루닝·인덱스 무력화
Correlated subquery in WHERE	행마다 서브쿼리 재실행	O(N²) 복잡도

Major — 강하게 권고

안티패턴 설명 영향

ORDER BY without LIMIT	전체 정렬 후 페이지네이션 없음	전체 데이터 메모리 적재
CTE 중복 참조	동일 CTE를 여러 번 참조	반복 연산 (DB에 따라 materialized 미보장)
IN 서브쿼리 without DISTINCT	IN (SELECT id FROM ...)	중복 비교로 성능 저하
DISTINCT + JOIN 조합	JOIN 후 DISTINCT로 중복 제거	불필요한 해시 빌드
중첩 서브쿼리	SELECT·FROM 절 내 서브쿼리 중첩	최적화 불가 구간 생성
LIKE '%keyword'	앞자리 와일드카드	전체 스캔 강제
UNION (UNION ALL 대신)	중복 제거 정렬 포함	추가 정렬 비용

Minor — 권고

안티패턴 설명

HAVING (WHERE로 대체 가능)	집계 전 필터는 WHERE로 이동
ORDER BY RAND()	전체 스캔 후 랜덤 정렬
불필요한 DISTINCT	중복이 없는 상황에서 DISTINCT 사용
지나치게 복잡한 단일 쿼리	CTE로 분리 권고
OR 연산자 남용	UNION ALL 또는 IN으로 대체 가능
REGEXP_CONTAINS (BigQuery)	단순 패턴은 LIKE로 충분

플랫폼별 특화 안티패턴

Trino

안티패턴 설명 탐지 시점

소파일 과다 (Too many splits)	파티션당 소파일 → 과도한 split 생성	EXPLAIN 분석
Dynamic filtering 미활용	브로드캐스트 조인 없이 대형 테이블 풀스캔	EXPLAIN
Predicate pushdown 비활성	커넥터에 필터가 내려가지 않음	EXPLAIN
JOIN 순서 비최적	큰 테이블이 build side가 됨	EXPLAIN
컬럼형 포맷 미사용	ORC/Parquet 대신 CSV/JSON	정적 분석

Databricks / Spark

안티패턴 설명 탐지 시점

UDF 남용	Python UDF → Spark native 함수로 대체	정적 분석
collect() 호출	드라이버에 전체 데이터 수집 → OOM	정적 분석
explode() 후 집계 없는 JOIN	행 폭발 후 바로 조인	정적 분석
Shuffle partition 미조정	기본 200 파티션 그대로 사용	EXPLAIN EXTENDED
autoMerge 스키마 진화	예상 못한 스키마 변경	정적 분석
Liquid Clustering 미사용	Z-order 대신 Liquid Clustering 미전환	메타데이터 분석
Small file 누적	OPTIMIZE/VACUUM 미실행	메타데이터 분석

Snowflake

안티패턴 설명 탐지 시점

필터 컬럼에 함수 적용	WHERE DATE_TRUNC(...) → 파티션 프루닝 불가	정적 분석
Clustering key 미사용	대형 테이블 파티션 pruning 없음	EXPLAIN / 메타데이터
VARIANT/JSON 전체 스캔	반구조 데이터 전체 파싱	정적 분석
Small file INSERT	COPY INTO 대신 단건 INSERT 반복	정적 분석
Warehouse 과대 설정	쿼리 복잡도 대비 X-Large 사용	실행 후 통계
RESULT_SCAN 미활용	동일 쿼리 반복 실행 (캐시 미활용)	히스토리 분석

구현 방향

전체 흐름

쿼리 입력
   ↓
[1] 정적 분석 (AST)         → Critical/Major 즉시 차단·경고
   ↓
[2] EXPLAIN 분석            → 실행 계획 기반 추가 경고
   ↓
[3] 실행 (선택)
   ↓
[4] 실행 후 프로파일 분석    → 실제 비용 기반 튜닝 포인트

Pre-execution: 정적 분석 (Dry-run)

실제 실행 없이 SQL 텍스트 → AST 파싱 → 패턴 매칭 방식으로 동작합니다.

추천 도구: sqlglot (Python) — Trino·Databricks·Snowflake 방언 모두 지원, AST 변환 가능
탐지 가능: SELECT *, Cartesian JOIN, Non-sargable predicate, UNION vs UNION ALL, 중첩 서브쿼리, ORDER BY without LIMIT 등

Pre-execution: EXPLAIN 분석

DB에 EXPLAIN을 실행하여 (데이터 스캔 없음) 실행 계획을 파싱합니다.

플랫폼 명령어 얻을 수 있는 정보

Trino	EXPLAIN query	논리/분산 실행 계획, 예상 행 수
Databricks	EXPLAIN EXTENDED query	논리/물리 플랜, AQE 정보
Snowflake	EXPLAIN USING TABULAR query	파티션 프루닝 여부, 예상 스캔 크기
BigQuery	dry_run=True (API)	예상 바이트 스캔 비용

EXPLAIN으로 탐지 가능한 항목: Full scan (파티션 프루닝 없음), 비효율적 JOIN 순서, 브로드캐스트 JOIN 미활용, 동적 필터 미적용입니다.

Post-execution: 프로파일 분석

실행 완료 후 통계 데이터를 수집하여 실제 병목을 진단합니다.

플랫폼 데이터 소스 분석 포인트

Trino	system.runtime.queries	실제 스캔 바이트, CPU 시간, 스필 여부
Databricks	Spark UI / DESCRIBE HISTORY	스테이지별 실행 시간, 셔플 크기
Snowflake	Query Profile / QUERY_HISTORY	파티션 스캔율, Spill to disk, 원격 스필
BigQuery	INFORMATION_SCHEMA.JOBS	실제 바이트 처리, Slot ms

우선순위 체계

심각도 액션 예시

Critical	실행 차단 또는 명시적 확인 요구	Cartesian JOIN, Non-sargable
Major	경고 + 수정 제안 코드 제공	ORDER BY without LIMIT, CTE 중복 참조
Minor	선택적 최적화 제안	UNION → UNION ALL, OR → IN

도구 선택 가이드

상황 추천 도구

BigQuery 환경에서 전체 쿼리 자동 감사	BigQuery Anti-Pattern Recognition
DB 무관한 SQL 파일 빠른 CLI 검사	sqlcheck
Snowflake·Databricks 멀티 웨어하우스 + AI 제안	AltimateAI/altimate-code
자체 안티패턴 엔진 개발, 다방언 지원 필요	sqlglot
CI/CD 게이트에서 HIGH 패턴만 차단	sqlcheck (-r 3)
방언 간 SQL 마이그레이션	sqlglot (transpile)

참고 링크

레이크 하우스란

불곰1 — Mon, 27 Apr 2026 21:38:05 +0900

레이크하우스 오픈 테이블 포맷 완전 비교

Delta Lake · Apache Iceberg · Apache Hudi · Apache Paimon · DuckLake(2026) 포맷의 메타데이터 구조, 카탈로그 아키텍처, 심화 기술 특징을 비교합니다. Apache XTable(상호운용 레이어)도 별도 정리합니다.

레이크하우스란?

레이크하우스(Lakehouse) = 데이터 레이크의 유연성·비용 효율성 + 데이터 웨어하우스의 ACID 트랜잭션·스키마 관리·거버넌스를 오픈 파일 포맷 위에서 직접 제공하는 통합 아키텍처

전통 2계층 아키텍처의 문제

구분 데이터 레이크 데이터 웨어하우스

장점	정형·비정형 대량 저장, 비용 효율적	ACID 트랜잭션, 스키마 강제, 우수한 쿼리 성능
단점	품질·일관성·거버넌스 관리 어려움	ETL 필수, 높은 비용, 비정형 데이터 미지원

두 계층 혼용 시 데이터 중복 · ETL 복잡성 · 시스템 간 불일치 · 높은 TCO 문제가 발생합니다.

오픈 테이블 포맷이 해결하는 문제

오픈 테이블 포맷(Delta Lake, Iceberg, Hudi, Paimon 등)은 객체 스토리지(S3/OSS) 위에서 데이터 웨어하우스 수준의 기능을 직접 제공합니다.

ACID 트랜잭션: 병렬 읽기/쓰기 충돌 방지
스키마 관리: 강제(enforcement) + 진화(evolution)
데이터 버전 관리: Time Travel로 과거 스냅샷 조회
멀티 워크로드 지원: BI/SQL · ML/AI · 실시간 스트리밍을 단일 플랫폼에서

포맷 분류 체계

분류 포맷 핵심 패러다임

전통 파일 기반	Delta Lake	Flat JSON 로그 + Parquet 체크포인트, 카탈로그 독립
전통 파일 기반	Apache Iceberg	계층적 스냅샷 트리, 외부 카탈로그 필수
전통 파일 기반	Apache Hudi	Timeline 기반 CDC/Upsert 특화, COW/MOR 이중 구조
전통 파일 기반	Apache Paimon	LSM Tree + 스트리밍 네이티브, Flink 통합
SQL DB 기반	DuckLake	SQL DB가 카탈로그 + 메타데이터 역할 (2025~2026 신흥)
상호운용 레이어	Apache XTable	포맷 간 메타데이터 변환 (독립 포맷 아님)
실시간 스트리밍 스토리지 (Lakehouse 포맷 아님)	Apache Fluss	분산 스트리밍 스토리지 시스템. Kafka 후계자. Paimon/Iceberg의 hot tier 보완재 (ASF Incubating, 2025~2026)

핵심 비교 요약

항목 Delta Lake Apache Iceberg Apache Hudi Apache Paimon DuckLake

기원	Databricks	Netflix	Uber	Alibaba/Flink 커뮤니티	DuckDB Labs
출시	2019	2018	2019	2023	2025 (v1.0: 2026.04)
메타데이터 저장	_delta_log/ (JSON + Parquet)	metadata.json → Manifest 계층	.hoodie/ Timeline	Snapshot → Manifest 계층	SQL DB (SQLite / DuckDB / PostgreSQL)
외부 카탈로그 필수	아니오 (경로 기반 독립)	예 (필수)	아니오 (HMS 권장)	아니오 (FilesystemCatalog 기본)	아니오 (SQL DB 자체가 카탈로그)
저장 구조	Flat 로그 + Checkpoint	계층적 스냅샷 트리	Timeline + COW/MOR	LSM Tree • 스냅샷	Parquet + SQL 메타데이터
핵심 강점	Spark 생태계, 배치 처리	멀티 엔진 호환성	CDC/Upsert 특화	스트리밍 네이티브	경량·단순·DuckDB 최적화
동시성 제어	OCC + Coordinated Commits	OCC (CAS)	OCC + NBCC (1.0)	OCC (스냅샷 격리)	SQL DB 트랜잭션
Time Travel	버전/타임스탬프	스냅샷 ID/타임스탬프	타임스탬프/커밋	스냅샷 ID/타임스탬프	SQL DB 쿼리 기반
파티션 진화	X (Liquid Clustering 대체)	O (재작성 불필요)	제한적	O	X (단순 설계)
스트리밍 지원	보통	보통	우수	최우수 (Flink 네이티브)	미지원 (배치 중심)
Small File 자동화	Databricks 전용	수동 트리거	비동기 서비스 분리	Flink 내장 자동화	Data Inlining으로 회피
벤더 중립성	중간 (Databricks 주도)	높음 (30개+ 기업)	높음 (ASF)	중간 (Alibaba 주도)	중간 (DuckDB Labs)

전통 파일 기반 포맷

1. Delta Lake

메타데이터 구조: _delta_log/

Delta Lake는 카탈로그 없이 독립 동작이 가능한 설계입니다. 모든 트랜잭션 정보가 _delta_log/ 디렉토리에 완전히 내재화되어 있습니다.

<table-root>/
├── _delta_log/
│   ├── 00000000000000000000.json   # 최초 커밋
│   ├── 00000000000000000001.json
│   ├── 00000000000000000010.parquet  # 체크포인트 (10번째마다 자동)
│   ├── _last_checkpoint              # 최신 체크포인트 포인터
│   └── _sidecars/                    # V2 체크포인트 사이드카 (3.0+)
└── part-00000-xxxx.snappy.parquet

JSON 커밋 파일 액션 타입: protocol · metaData · add (파일 추가 + min/max 통계) · remove (논리 삭제) · commitInfo

파일 번호 자체가 순서를 보장하므로 외부 포인터가 불필요합니다.

카탈로그 아키텍처

방식 설명

경로 기반 (카탈로그 없음)	spark.read.format("delta").load("s3://...") — 외부 서비스 불필요
Hive Metastore	가장 범용적. Spark, Trino, Presto 호환
Unity Catalog	Delta 네이티브. 멀티클라우드 거버넌스, Row-level Security/Column Masking 지원
AWS Glue	서버리스. Athena/EMR 연동
Apache Polaris	Iceberg REST 스펙 준수 오픈소스

ACID 트랜잭션

기본 OCC (Optimistic Concurrency Control). Delta 4.0부터 Coordinated Commits 도입 — DynamoDB 등 외부 Commit Coordinator가 커밋을 중재하여 멀티엔진 동시 쓰기를 안전하게 보장합니다.

Deletion Vector (DV)

Delta 3.1에서 Compressed Bitmap 방식 GA. 파일 재작성 없이 _delta_log/*.bin 사이드카 파일에 삭제 위치를 비트맵으로 저장합니다.

주요 기능

Time Travel: VERSION AS OF 42 / TIMESTAMP AS OF '2025-01-01'
스키마 진화: mergeSchema (컬럼 추가), Column Mapping (컬럼명 변경/삭제, 파일 재작성 없음)
Liquid Clustering (3.0+): 내부적으로 Hilbert Curve 사용. Z-ORDER 대비 고차원 데이터 locality 우수. 증분 클러스터링으로 전체 재작성 불필요
Delta Sharing: 크로스 플랫폼 데이터 공유 프로토콜 (데이터 복제 없이 서명된 URL 공유)
UniForm (3.0+): 동일 Delta 파일 위에 Iceberg/Hudi 메타데이터 자동 생성 → Snowflake, Athena 직접 읽기 가능

단점 & 주의사항

Databricks 전용 기능: Auto Optimize, Auto Loader, Bloom Filter Index, Primary Key 제약 — OSS Delta에는 없음
파티션 진화 미지원: 파티션 변경 시 전체 데이터 재작성 필요
Small File 자동화: Databricks 환경 전용. OSS에서는 OPTIMIZE 수동 실행 필요

2. Apache Iceberg

카탈로그가 필수인 이유

오브젝트 스토리지(S3)는 원자적 파일 교체를 보장하지 않음
  → v1.metadata.json vs v2.metadata.json — 어느 것이 현재 유효한 버전인지 파일 목록만으로 알 수 없음
  → 외부 서비스가 원자적 CAS(Compare-and-Swap)로 단일 포인터를 관리해야 함

카탈로그가 저장하는 것은 단 하나:
  prod_db.orders → s3://.../metadata/v4.metadata.json

메타데이터 4계층 구조

Catalog
  └── Namespace (Database)
        └── Table
              └── metadata.json  ← 카탈로그가 가리키는 유일한 포인터
                    └── Snapshot
                          └── Manifest List (Avro, 파티션 범위 통계 포함)
                                └── Manifest File (Avro, 컬럼 min/max 통계 포함)
                                      └── Data Files (Parquet/ORC/Avro)

여러 버전 메타데이터 파일 관리

metadata/
  v1.metadata.json   ← 최초 생성
  v2.metadata.json   ← INSERT 후 (v1은 삭제되지 않음)
  v3.metadata.json   ← UPDATE 후
  v4.metadata.json   ← 현재 버전 (카탈로그가 이 경로만 가리킴)

카탈로그는 여러 버전 중 가장 최신 버전 파일 경로 하나만 포인터로 유지합니다. 이전 버전들은 Time Travel을 위해 보존됩니다.

3단계 프루닝 메커니즘

1단계: Manifest List → 파티션 범위로 불필요한 Manifest File 스킵
2단계: Manifest File → 컬럼 min/max 통계로 불필요한 Data File 스킵
3단계: Data File 내부 → Parquet Row Group 통계로 Row Group 스킵

ACID 트랜잭션: Snapshot Isolation + OCC

모든 파일은 불변(immutable). Writer는 새 파일을 생성하고 카탈로그 포인터를 CAS로 원자 교체합니다. 충돌 시 rollback + retry.

Deletion Vector (Iceberg v3, 2025 GA)

v2의 Position/Equality Delete File 방식을 개선하여 v3에서 Puffin 파일 기반 DV 도입.

Puffin 파일 (compact binary sidecar) 에 압축 비트맵으로 삭제 위치 저장
데이터 파일 1개당 DV 1개만 허용, 신규 삭제 시 기존 DV와 merge
AWS 벤치마크: v2 대비 delete 속도 55% 향상, 저장 크기 73.6% 감소

주요 기능

Hidden Partitioning: month(order_date), bucket(16, user_id) 등 변환 함수로 물리 파티션 자동 관리
파티션 진화: ALTER TABLE ... SET PARTITION SPEC (day(order_date)) — 기존 데이터 재작성 없이 파티션 전략 변경
Time Travel: Snapshot ID 또는 타임스탬프 기반
REST Catalog 표준: OpenAPI 스펙 기반 Vendor-neutral 카탈로그 인터페이스

지원 카탈로그 구현체:

구현체 특징

Apache Polaris	Snowflake 오픈소스 기증. RBAC + Credential Vending
Project Nessie	Git 스타일 브랜치/태그. 다중 테이블 트랜잭션 지원
Lakekeeper	Rust 기반 경량 구현
AWS Glue	관리형. AWS 생태계 최적화
Hive Metastore	레거시 호환성

단점

카탈로그 없이 동작 불가 — 운영 복잡도 증가
Delete 파일(v2) 누적 시 읽기 성능 저하 → 주기적 Compaction 필요
Small File 자동화 도구 없음 (수동 rewrite_data_files 실행 의존)
Clustering 알고리즘: Z-order만 지원, Hilbert Curve 미지원 (2026 기준)

3. Apache Hudi

Delta Lake와 유사한 설계 철학을 가지나, CDC/Upsert에 특화된 포맷입니다. Uber가 설계한 목적 자체가 record-level upsert입니다.

메타데이터 구조: .hoodie/ Timeline

<table_base_path>/
├── .hoodie/
│   ├── hoodie.properties          # 테이블 핵심 설정
│   ├── <instant>.commit           # 완료된 커밋
│   ├── <instant>.inflight         # 진행 중
│   ├── <instant>.requested        # 요청됨
│   ├── archived/                  # 아카이브된 타임라인
│   └── metadata/                  # Hudi Metadata Table (파일 목록, Bloom Filter, RLI)
└── partition_col=value/
    └── *.parquet / *.log

Timeline 파일명 자체가 순서를 표현하며, completed 상태 인스턴트만 Reader에 가시적입니다.

카탈로그 아키텍처

자체 카탈로그 서버 없음. HMS에 스키마/파티션 자동 싱크(HiveSyncTool). 경로 기반 직접 접근도 가능합니다.

테이블 타입: COW vs MOR

특성 Copy-on-Write (COW) Merge-on-Read (MOR)

업데이트 방식	파일 전체 재작성	.log 파일에 변경 기록
읽기 성능	우수 (base file만)	보통 (base + log 병합)
쓰기 성능	낮음	높음 (log append)
적합 케이스	배치 중심, 변경 빈도 낮음	CDC/스트리밍, 고빈도 upsert

ACID 트랜잭션: NBCC (Hudi 1.0의 핵심)

기본 OCC: 파일 그룹 단위 충돌 감지
NBCC (Non-Blocking Concurrency Control): 여러 스트리밍 Writer가 동일 File Slice에 Log File을 자유롭게 병렬 기록, 충돌 해소를 Compaction 단계로 위임. 명시적 락 불필요

Walmart 사례: 대규모 뮤터블 워크로드에서 Delta/Iceberg OCC가 반복 실패한 반면, Hudi NBCC만 안정적으로 동작했습니다.

Upsert 특화: Record-Level Index

인덱스 특징

Bloom Filter	기본. 파일 footer에 저장, 2단계 프루닝
HBase Index	O(1) 조회, 외부 HBase 서버 필요
Bucket Index	Hash 기반 결정론적 라우팅, 인덱스 조회 불필요
Record-Level Index (RLI, 0.14+)	외부 서버 없이 HBase 수준 성능. 현재 권장

Clustering 알고리즘

Hudi는 Linear Sort, Z-order, Hilbert Curve 모두 지원합니다. 인라인(write 시 동시) 또는 비동기(별도 서비스) 두 모드 선택 가능하며 파티션 내 fine-grained clustering이 가능합니다.

주요 기능

Incremental Query: 특정 시점 이후 변경된 레코드만 조회 (설계 초기부터, Delta CDF보다 앞서 구현)
CDC Query (0.13+): before/after 이미지 + 작업 유형(insert/update/delete) 포함
이벤트 타임 정렬: RecordPayload / RecordMerger API로 늦게 도착한 데이터도 정확하게 병합
Hudi Metadata Table: 파일 목록, Bloom Filter, 컬럼 통계, 레코드 인덱스 캐싱 → S3 LIST 비용 절감
LSM Timeline (1.0): 수백만 히스토리 인스턴트를 LSM Tree 방식으로 효율 관리

단점

HMS 강한 의존성, Unity Catalog 같은 통합 거버넌스 부재
MOR 테이블은 주기적 Compaction 없이 읽기 성능 저하
Snowflake, BigQuery 등 클라우드 DW에서 네이티브 지원 미흡

4. Apache Paimon

Iceberg와 유사한 스냅샷 기반 구조를 가지나, 스트리밍 네이티브 설계와 LSM Tree 저장 구조가 핵심 차별점입니다.

Flink Table Store로 출발(2022) → Apache Paimon으로 개명 후 ASF 독립 프로젝트(2023).

메타데이터 구조: 이중 Manifest List

Snapshot
  ├── Base Manifest List   ← S-1까지 누적 뷰 (배치 리더용)
  └── Delta Manifest List  ← 직전 스냅샷 대비 변경분만 (스트리밍 리더용)
        └── Manifest File (Avro)
              └── Data File / Changelog File / Index File

스트리밍 리더는 Delta Manifest만 읽어 최신 변경분만 소비, 배치 쿼리는 Base + Delta 결합으로 전체 뷰를 얻습니다.

카탈로그 아키텍처

카탈로그 특징

FilesystemCatalog (기본)	외부 서비스 불필요. 파일 어휘 정렬로 최신 스냅샷 파악
HiveCatalog	Hive에서 직접 접근 가능
JdbcCatalog	MySQL/PostgreSQL 활용
REST Metastore	표준 REST 인터페이스

LSM Tree 기반 저장

Write → Memory Buffer (Primary Key 기준 정렬)
     → Flush (Level 0 Sorted Runs)
     → Background Compaction → Level 1, 2, ...N

Primary Key Table: CRUD 완전 지원. Merge Engine: Deduplicate / Partial Update / Aggregation / First Row
Append-Only Table: INSERT 전용. 메시지 큐 대체용

Flink 통합 및 스트리밍 차별점

항목 Iceberg Paimon

스트리밍 레이턴시	높음 (마이크로배치)	100ms 미만
Changelog 생성	없음 (별도 CDC 툴 필요)	내장 Changelog Producer
Flink 통합	커넥터 수준	네이티브 (Materialized Tables, 2-Phase Commit)
워터마크	미지원	내장 지원

Changelog Producer 모드: input (CDC 소스 그대로) · lookup (before/after 이미지 생성) · full-compaction (안정성 우선)

Exactly-once 처리 보장: Paimon은 Flink의 체크포인트 메커니즘과 완벽하게 연동됩니다. Flink 작업 장애 복구 시 중복 쓰기나 데이터 유실 없이 exactly-once semantics를 보장합니다.

Flink 외부 상태 저장소로 활용: Paimon Primary Key Table을 Flink 스트리밍 작업의 외부 상태 저장소로 사용할 수 있습니다. Kafka 소비 오프셋 관리와 연동하여 체크포인트 기반 일관된 복구가 가능합니다. (Fluss PK Table이 이 역할을 더 최적화하는 방향으로 진화 중)

Iceberg 호환성

'metadata.iceberg.storage' = 'hadoop-catalog'

Iceberg v3 Deletion Vector 지원 시 Paimon Primary Key Table을 Iceberg 리더로 완전히 읽기 가능합니다.

Small File 자동화

Flink 스트리밍 파이프라인 안에서 LSM compaction이 상시 자동 실행됩니다. 별도 compaction 스케줄러가 필요 없습니다.

단점

상대적으로 신생 프로젝트 (커뮤니티 성숙도 낮음)
Flink 중심 생태계 (Spark/Trino에서 일부 기능 제한)
배치 처리 성능은 Iceberg/Delta 대비 낮을 수 있음

SQL DB 기반 포맷

5. DuckLake

2025~2026년 가장 주목받는 신흥 포맷. "파일 기반 메타데이터" 패러다임과 완전히 다른 축입니다.

배경

2025년 5월: DuckDB Labs가 DuckLake v0.1 발표
2026년 4월 13일: v1.0 production-ready 출시 (DuckDB v1.5.2 내장)
DuckDB 핵심 확장 중 다운로드 Top-10 진입, 수십 개 기업 프로덕션 사용 중

핵심 아이디어: SQL DB가 카탈로그 + 메타데이터

기존 포맷의 "Iceberg + Polaris 카탈로그" 조합 전체를 SQL DB 하나로 대체합니다.

기존 패러다임:
  오브젝트 스토리지 파일들 + 외부 카탈로그 서비스 (HMS/Polaris)

DuckLake 패러다임:
  SQL DB (SQLite/PostgreSQL/DuckDB) ← 카탈로그 + 메타데이터 모두 여기
  오브젝트 스토리지 ← 실제 Parquet 데이터 파일만

항목 Delta/Iceberg/Hudi DuckLake

메타데이터 저장	JSON 로그/Avro (object storage)	SQL DB 테이블
카탈로그	별도 Hive Metastore / REST 카탈로그	SQL DB 자체가 카탈로그
데이터 파일	Parquet / ORC	Parquet
동시성 제어	OCC (파일 레벨)	SQL DB 트랜잭션

Data Inlining: Small File 문제 원천 해소

소량 변경(수십~수백 행)을 Parquet으로 저장하지 않고 카탈로그 SQL DB에 직접 인라인 저장합니다. 누적되면 CHECKPOINT 명령으로 Parquet으로 플러시합니다. 소규모 스트리밍 쓰기에서 소파일 폭발 문제를 원천적으로 회피합니다.

메타데이터 규모

1PB 데이터 기준 메타데이터 크기 약 10GB 수준. SQL DB가 처리하기에 적합한 크기입니다.

지원 클라이언트

DuckDB 외에도 Apache DataFusion, Apache Spark, Trino, Pandas 클라이언트 구현이 완료되었습니다.

단점 & 주의사항

SQL DB가 단일 장애점(SPOF): PostgreSQL 등 외부 DB에 의존 — 순수 object-storage 아키텍처를 선호하는 팀에 부적합
커뮤니티 성숙도 낮음 (생태계 초기 단계)
멀티 엔진 대규모 동시성에서의 검증 부족
파티션 진화, 스키마 진화 기능이 기존 포맷 대비 단순

적합한 케이스

DuckDB 중심 소규모 팀 / 단일 엔진 환경
로컬 또는 소규모 클라우드 분석 워크로드
운영 복잡도를 최소화하고 싶은 경우
기존 SQL 인프라(PostgreSQL 등)를 메타데이터 저장소로 재활용하고 싶은 경우

스트리밍 스토리지 레이어 (Hot Tier)

6. Apache Fluss

[스트리밍 스토리지 — Lakehouse 테이블 포맷 아님] Fluss는 Delta Lake/Iceberg/Hudi/Paimon 같은 레이크하우스 파일 포맷이 아닙니다. 분산 스트리밍 스토리지 시스템으로, Paimon/Iceberg의 hot tier 보완재입니다. Kafka + RocksDB의 schematized 후계자에 가깝습니다.

배경 및 거버넌스

출처: Alibaba/Ververica → Flink Forward Asia 2024 오픈소스 공개
거버넌스: Apache Software Foundation Incubating (2025년 6월)
라이선스: Apache 2.0
최신 버전: v0.9.0 (2026년 3월)
운영 규모 (Taobao): 3PB+, 40 GB/s ingest, 500K QPS 포인트 룩업, 단일 테이블 500B+ rows

클러스터 아키텍처

[Flink Job / Spark Client]
        │
        ▼
CoordinatorServer ── 메타데이터 관리, Tablet 할당, 리밸런싱, Tiering 조정
        │
        ▼
TabletServer (N개)
  ├── LogStore (Apache Arrow IPC Columnar)
  │     → append-only, Kafka 스타일 복제, 서버 측 Column Pruning
  └── KvStore (RocksDB)
        → PK 기반 mutable 저장소, 500K QPS 포인트 룩업
        → CDC Changelog 출력 (+I / +U / -U / -D)
ZooKeeper ── 분산 조정 (향후 KvStore로 대체 예정)

파일 기반 포맷과의 핵심 차이: 파일 + 메타데이터 규약이 아닌 서버 클러스터가 필수인 분산 시스템입니다.

데이터 포맷 이중 구조

계층 포맷 저장 위치 레이턴시

핫 (Fluss 직접)	Apache Arrow IPC (열 기반, zero-copy)	TabletServer NVMe/SSD	밀리초 미만 (sub-second)
콜드 (Tiering 이후)	Parquet (Paimon / Iceberg / Lance)	S3/OSS 객체 스토리지	분~시간 단위

테이블 타입

타입 특징 적합 사용처

Log Table	append-only, schematized Kafka topic. Arrow IPC 저장	이벤트 스트림, 메시지 큐 대체
Primary Key (PK) Table	RocksDB KvStore + WAL. CRUD + CDC Changelog 출력 (+I/+U/-U/-D)	실시간 차원 테이블, A/B 카운터, CDC 핫 경로, Lookup Join 외부화

Union Read — 핫·콜드 통합 쿼리

-- 핫(Fluss) + 콜드(Paimon/Iceberg) 통합 조회
SELECT * FROM fluss_table;

-- 콜드(Paimon/Iceberg) 전용 — $lake suffix
SELECT * FROM fluss_table$lake;

Flink SQL에서 hot/cold 데이터를 자동 통합합니다. Tiering Service가 백그라운드에서 Fluss → Paimon/Iceberg로 데이터를 자동 이관합니다.

엔진 지원

엔진 지원 수준

Apache Flink	1급 네이티브 (설계 1순위)
Apache Spark	v0.9부터 추가
Trino / StarRocks	로드맵 단계 (Union Read 포함)
Paimon / Iceberg 클라이언트	Tiering 후 표준 방식으로 자동 지원

Fluss vs Paimon vs Kafka 비교

항목 Fluss Paimon Kafka

본질	분산 스트리밍 스토리지 시스템	레이크하우스 파일 포맷	분산 메시지 큐
쓰기 레이턴시	밀리초 미만	초~분 단위	밀리초 미만
스키마 강제	예 (강한 타입)	예	아니오 (기본)
PK/Upsert	예 (RocksDB, 500K QPS)	예 (LSM Tree)	아니오
Time Travel	제한적 (cold 계층 의존)	예 (스냅샷)	아니오
OLAP 직접 쿼리	Tiering 후 가능	예 (Spark/Trino)	아니오
서버 클러스터 필요	예 (CoordinatorServer + TabletServer)	아니오 (라이브러리)	예
핫 데이터 포맷	Apache Arrow IPC	없음 (파일 직접)	바이너리 로그

카탈로그 아키텍처

자체 분산 카탈로그 (CoordinatorServer + ZooKeeper). Hive Metastore, Glue, Polaris 같은 파일 기반 외부 카탈로그와 다른 모델입니다. Tiering 시 Iceberg/Paimon 카탈로그에 메타데이터를 자동 등록합니다.

단점 & 주의사항

서버 클러스터 필수: 파일 기반 포맷 대비 운영 복잡도 높음 (k8s 배포 필요)
Flink 중심 생태계: Spark(0.9 신규), Trino/StarRocks(로드맵) — 성숙도 제한
ASF Incubating 단계: v0.9, 아직 안정화 진행 중
Time Travel 약함: 사용자 대면 Time Travel은 Paimon/Iceberg에 의존
채택 사례 편중: 대부분 Alibaba 그룹 (외부 기업 공개 사례 제한적)

적합한 케이스

sub-second freshness가 요구되는 실시간 대시보드 및 서비스
Flink Lookup Join 외부 상태 저장소 (Fluss PK Table)
CDC 핫 경로 처리 후 Tiering으로 자동 배치 분석 연동
실시간 개인화 추천, A/B 테스트 카운터, 실시간 특성 저장소
Kafka에 스키마 강제 + OLAP 쿼리 연동이 동시에 필요한 경우

상호운용 레이어

Apache XTable (구 OneTable)

새로운 포맷이 아니라 포맷 간 메타데이터 변환 레이어입니다. 데이터 파일 복사 없이 메타데이터만 변환합니다.

2024년 2월: Apache Incubating 프로젝트 편입
Delta Lake ↔ Apache Iceberg ↔ Apache Hudi 간 양방향 변환
Paimon 지원 로드맵 포함

Delta UniForm과의 차이

항목 Delta UniForm Apache XTable

주체	Databricks (Delta Lake 내장)	독립 오픈소스
방향	Delta → Iceberg/Hudi (단방향 중심)	모든 포맷 간 양방향
의존성	Delta Lake 필수	포맷 무관
거버넌스	Databricks 주도	ASF 중립

적합한 케이스

기존 Delta Lake 테이블을 Iceberg 기반 툴에서도 읽어야 하는 경우
포맷 전환 없이 멀티 포맷 환경을 운영해야 하는 경우
특정 벤더에 종속 없이 포맷 상호운용성을 유지하고 싶은 경우

심화 비교

Deletion Vector 구현 방식 비교

포맷 방식 저장 위치 특이사항

Delta Lake	Compressed Bitmap (3.1+)	_delta_log/*.bin 사이드카	REORG로 물리 정리
Iceberg v3	Puffin 파일 + Compressed Bitmap	데이터 파일 옆 sidecar	파일당 DV 1개 제한, v2 대비 삭제 55% 빠름
Iceberg v2	Position Delete File (행 위치) + Equality Delete File (값 기반)	별도 Parquet 파일	파일 폭발 문제 있음
Hudi	Delta Log File (append-only)	.log 파일	이벤트 타임 정렬 지원이 강점
Paimon	LSM multi-level compaction	LSM 구조 자체	별도 DV 없음, LSM이 삭제/갱신 흡수

Iceberg v3 + Delta가 유사한 DV 방식으로 수렴 중. Hudi는 이벤트 타임 처리에서 차별화. Paimon은 LSM 구조 자체가 DV 역할.

Small File 문제 해결 전략

포맷 발생 원인 해결 메커니즘 자동화 수준

Delta Lake	스트리밍 micro-batch마다 파일 생성	OPTIMIZE 수동 실행 + Auto Optimize (Databricks 전용)	낮음 (OSS) / 높음 (Databricks)
Iceberg	스냅샷 기반 쓰기로 파일 누적	rewrite_data_files 수동 트리거	낮음
Hudi	MOR log 파일 누적	파일 그룹 단위 비동기 compaction (writer와 독립)	중간
Paimon	스트리밍 flush마다 소규모 SST 파일 생성	LSM compaction이 Flink 파이프라인 내 상시 자동 실행	높음
DuckLake	소량 변경	Data Inlining (SQL DB에 직접 저장 후 CHECKPOINT)	원천 회피

데이터 레이아웃 최적화 (클러스터링)

포맷 알고리즘 자동화 비고

Delta Lake	Hilbert Curve (Liquid Clustering)	Databricks 전용 Auto	Z-ORDER는 레거시
Iceberg	Z-order	수동	Hilbert Curve 미지원 (2026 기준)
Hudi	Linear Sort, Z-order, Hilbert Curve 모두	인라인 또는 비동기	알고리즘 선택 폭 가장 넓음
Paimon	Primary Key 기준 자동 정렬 (LSM)	자동	별도 clustering 명령 불필요

동시 다중 Writer 지원

포맷 메커니즘 특이사항

Iceberg	OCC — metadata.json atomic swap	충돌 시 rollback + retry
Delta Lake	OCC + 비겹침 파일 변경 동시 허용	Coordinated Commits (4.0)로 클라우드 환경 보강
Hudi	OCC + NBCC (1.0)	TrueTime 기반 completion-time ordering. 명시적 락 없이 여러 writer 동시 진행
Paimon	Snapshot isolation + 버킷 레벨 writer 제한	DV 모드에서 버킷 내 병렬 읽기 가능

Hudi NBCC 가장 유리 — 대규모 스트리밍 upsert 파이프라인에서 lock contention 없이 다중 writer 동시 실행

오픈소스 거버넌스 & 벤더 독립성

포맷 거버넌스 실질 주도 벤더 독립성

Apache Iceberg	Apache Software Foundation	Netflix, Apple, AWS, Snowflake 등 30개+ 기업 공동	최고 — 클라우드 3사 모두 네이티브 지원
Apache Hudi	Apache Software Foundation	Onehouse(구 Uber 팀) 주도	높음
Apache Paimon	Apache Software Foundation	Alibaba/Ververica 주도	중간 (Flink 의존성)
Delta Lake	Linux Foundation	Databricks 코드 기여 대부분	중간 — OSS에 없는 Databricks 전용 기능 다수
DuckLake	DuckDB Labs	DuckDB Labs	중간 (DuckDB 의존)

Delta Lake Databricks 전용 기능 (OSS에 없음): Auto Optimize · Auto Loader · Bloom Filter Index · Primary Key 제약

카탈로그 Federation & 글로벌 메타데이터 서비스

서비스 역할 지원 포맷

Apache Gravitino	"Catalog of Catalogs" — Hive, Iceberg REST, Kafka Schema Registry 통합	Delta, Iceberg, Hudi, Paimon 1등급 목표
Project Nessie	Git 스타일 브랜치/태그, 멀티 테이블 트랜잭션	Iceberg 주력
Apache Polaris	Iceberg REST 표준 구현	Iceberg 중심
Unity Catalog	Delta 네이티브 + 외부 Iceberg 테이블 지원. RLS/Column Masking	Delta 네이티브
AWS Lake Formation	Tag 기반 ABAC, 행/열 수준 접근 제어	Iceberg, Delta

멀티 테이블 트랜잭션: 포맷 자체 스펙에는 없음. Project Nessie + Iceberg가 현재 가장 성숙한 크로스 테이블 원자 커밋 솔루션입니다. (Branch → 여러 테이블 변경 → Merge 패턴)

카탈로그 의존성 핵심 차이

1. Iceberg — 카탈로그가 필수인 이유

[카탈로그 없이]
  v1.metadata.json  ← 구버전?
  v2.metadata.json  ← 최신 버전? 어느 것이 현재인지 알 수 없음
  v3.metadata.json  ← 충돌로 중복 생성?

[카탈로그 있을 때]
  Catalog: orders → v2.metadata.json  ← 원자적 CAS로 관리되는 단일 진실 공급원

2. Delta Lake — 카탈로그 없이 동작 가능한 이유

_delta_log/
  00000000000000000000.json  # 버전 0
  00000000000000000001.json  # 버전 1
  00000000000000000010.parquet  # 체크포인트
  _last_checkpoint  # "최신 체크포인트는 버전 10" 명시

→ 파일 번호 자체가 순서를 보장, 별도 포인터 불필요

3. Hudi — Delta Lake와 유사

.hoodie/
  20250101000000.commit   # 완료됨
  20250101000100.commit   # 완료됨
  20250101000200.inflight # 진행 중

→ 파일명 자체가 순서 표현, inflight/completed로 원자성 보장
→ HMS에 스키마 싱크하지만 테이블 자체는 독립 동작 가능

4. Paimon — FilesystemCatalog로 외부 서비스 없이 동작

FilesystemCatalog:
  파일시스템 내 파일의 어휘 정렬로 최신 스냅샷 파악
  → Iceberg의 Hadoop Catalog와 유사한 개념
  → 외부 서비스 없이 동작 가능

5. DuckLake — SQL DB가 카탈로그 자체

SQL DB (SQLite / PostgreSQL):
  테이블명 → 스냅샷 ID → 파일 목록 매핑 모두 SQL 테이블로 관리
  → SQL ACID 트랜잭션으로 원자성 보장
  → 외부 파일 기반 카탈로그 불필요

6. Fluss — 자체 분산 카탈로그 (CoordinatorServer + ZooKeeper)

CoordinatorServer + ZooKeeper (자체 분산 카탈로그):
  테이블 메타데이터, Tablet 위치, Tiering 상태를 직접 관리
  → Hive/Glue/Polaris 같은 파일 기반 카탈로그와 전혀 다른 모델
  → Flink Job이 CoordinatorServer에 직접 연결하여 메타데이터 조회
  → Tiering 시 Iceberg/Paimon 카탈로그에 메타데이터 자동 등록
  → 서버 클러스터가 카탈로그 역할 통합 (ZooKeeper 향후 KvStore로 대체 예정)

포맷 혼합 사용 아키텍처 패턴

단일 포맷보다 두 가지 포맷을 역할에 따라 분리해 사용하는 패턴이 2024~2025년부터 급증하고 있습니다. 실시간 수집의 강점과 배치 분석 생태계를 동시에 활용하는 것이 핵심 동기입니다.

혼합 패턴 비교

혼합 패턴 주요 채택 기업 핵심 동기 브리징 수단 운영 복잡도

Paimon + Iceberg	알리바바, ByteDance, Bondex	Flink 실시간 + 멀티엔진 분석	Paimon Iceberg 호환 스냅샷 (네이티브)	중간
Hudi + Iceberg	Uber, Robinhood, Onehouse	CDC/Upsert + 다중 엔진 분석	Apache XTable (양방향 변환)	중간
Delta + Iceberg	Capital One, Databricks	Spark 최적화 + 멀티클라우드	Delta UniForm (단방향)	낮음~중간
Fluss + Paimon + Iceberg	알리바바/Ververica	핫-웜-콜드 3계층 Streamhouse	Flink SQL Union Read	높음
DuckLake + Iceberg	MotherDuck 생태계	로컬 처리 + 중앙 공유 분석	Iceberg 메타데이터 임포트	낮음

1. Paimon + Iceberg — 가장 주목받는 조합

실제 사례: 알리바바(Taobao/Tmall, 수백 PB), ByteDance/TikTok, Bondex, StreamNative

각 포맷의 강점이 명확하게 분리됩니다.

역할 Paimon Iceberg

설계 철학	스트리밍 우선, LSM Tree	배치 분석 우선, 불변 스냅샷
갱신 방식	초단위 CDC/Upsert (LSM 흡수)	Copy-on-Write (배치 최적화)
Flink 통합	네이티브 1급 지원	커넥터 수준
분석 생태계	성장 중	Spark, Trino, Snowflake, BigQuery 폭넓게 지원

데이터 흐름:

Kafka / Flink CDC
        │
        ▼
[Flink + Paimon]  ─── 실시간 수집 레이어 (초~분 단위 freshness)
   LSM Tree              ├── Lookup Join / 실시간 OLAP (StarRocks, Doris)
   Changelog Producer    └── Flink SQL 집계 / 대시보드
        │
        │ Paimon Iceberg 호환 스냅샷 자동 생성
        │ (metadata.iceberg.storage = 'rest-catalog')
        ▼
[Iceberg REST Catalog]  ─── 배치 분석 레이어 (시간~일 단위)
   불변 스냅샷                 ├── Spark 대용량 배치 집계
   Time Travel                ├── Trino / Athena 다중 엔진
   Hidden Partitioning        └── Snowflake / BigQuery 분석 서비스

브리징 메커니즘: Paimon 테이블에 metadata.iceberg.storage = 'rest-catalog' 설정 시 쓰기 커밋마다 Iceberg 메타데이터를 REST Catalog에 자동 등록합니다. Iceberg 클라이언트는 동일 Parquet 파일을 Iceberg 테이블로 인식합니다.

주의사항:

기존 대형 테이블은 신규 커밋 전까지 Iceberg 클라이언트에 비가시 (lazy generation)
Paimon 메타데이터 + Iceberg 메타데이터 이중 유지 필요
LSM compaction 타이밍과 Iceberg 스냅샷 생성 타이밍 별도 튜닝 필요

2. Hudi + Iceberg — CDC 특화 수집 + 멀티엔진 분석

실제 사례: Uber(Hudi 창시, CDC 수집), Robinhood(Kafka→Hudi→Iceberg), Onehouse(XTable 기반 다중 포맷)

데이터 흐름:

MySQL / PostgreSQL / MongoDB
        │ (Debezium CDC)
        ▼
    Kafka Topics
        │ (Hudi DeltaStreamer)
        ▼
[Hudi MOR Tables]  ─── 수집 레이어 (분 단위 freshness)
   Record-level Upsert      ├── 실시간 조회 (Read Optimized View)
   NBCC 다중 Writer          ├── CDC 히스토리 보존
   이벤트 타임 정렬          └── 증분 처리 파이프라인
        │
        │ Apache XTable (메타데이터 양방향 변환)
        │ (실제 Parquet 파일 복사 없음)
        ▼
[Iceberg Tables]  ─── 분석 레이어
   COW 최적화                 ├── Spark 대용량 배치 분석
   파티션 진화                ├── Trino / Presto OLAP
   Time Travel               ├── Snowflake / BigQuery 외부 테이블
                             └── Dremio 셀프서비스 분석

Apache XTable 브리징: 소스 포맷의 메타데이터를 읽어 타겟 포맷의 메타데이터를 재생성합니다. Parquet 데이터 파일은 복사 없이 메타데이터만 변환됩니다. Hudi ↔ Iceberg ↔ Delta 3방향 양방향 지원합니다.

Delta UniForm과의 차이: Delta UniForm은 Delta → Iceberg 단방향이며 Databricks 종속. XTable은 완전 양방향, 벤더 중립입니다.

3. Delta + Iceberg — Spark 최적화 + 멀티클라우드

실제 사례: Capital One(Lakehouse Convergence 패턴 공개), Databricks(2024년 Tabular 인수 후 Unity Catalog에서 Delta+Iceberg 동시 지원)

데이터 흐름:

Spark Structured Streaming / Batch
        │
        ▼
[Delta Lake]  ─── Spark 처리 레이어
   _delta_log/           ├── ETL/ELT 변환 (Databricks)
   Auto-Optimize         ├── ML/AI 워크플로우
   ACID 트랜잭션          └── Delta Live Tables
        │
        │ Delta UniForm (Delta 커밋 시 Iceberg 메타데이터 자동 생성)
        │ 또는 Apache XTable (양방향 변환)
        ▼
[Iceberg 메타데이터 레이어]  ─── 멀티엔진 분석
   (동일 Parquet 파일 공유)      ├── AWS Athena / Glue
   Time Travel                  ├── Snowflake External Tables
   Partition Pruning            ├── Google BigQuery Iceberg
                                └── Trino / Dremio

주의사항: Delta UniForm은 단방향(Delta → Iceberg 읽기 전용). Iceberg 엔진에서 쓰기 불가. 최적 경험을 위해 Unity Catalog 의존성이 생깁니다.

4. Streamhouse: Fluss + Paimon + Iceberg (핫-웜-콜드 3계층)

실제 사례: 알리바바/Ververica — "From Kappa Architecture to Streamhouse" (2025)

2025년 주목받는 신규 아키텍처 패턴입니다. 단순 레이크하우스를 넘어 실시간 스트리밍과 배치 분석을 통합하는 Streamhouse 개념을 구현합니다.

데이터 소스 → Kafka
        │
        ▼
[핫 레이어: Fluss]  ─── 초~분 단위 freshness
   스트리밍 스토리지       ├── Flink 실시간 처리
   Changelog 네이티브     ├── 실시간 집계/조인
   낮은 레이턴시           └── 이벤트 시간 처리
        │ (Fluss → Paimon 자동 싱크)
        ▼
[웜 레이어: Paimon]  ─── 분~시간 단위 freshness
   LSM Tree 갱신          ├── OLAP 엔진 쿼리 (Doris, StarRocks)
   Iceberg 호환 스냅샷    ├── Flink Lookup Join
   배치 처리 가능          └── 중기 데이터 보존
        │ (Paimon Iceberg 호환 스냅샷)
        ▼
[콜드 레이어: Iceberg]  ─── 시간~일 단위 freshness
   불변 스냅샷              ├── Spark 대용량 배치
   멀티엔진 접근           ├── Trino / Athena
   장기 보존               └── Snowflake / BigQuery

Flink SQL에서 UNION ALL로 핫·웜·콜드 레이어를 통합 쿼리합니다.

메달리온 아키텍처에서의 레이어별 포맷 전략

2024~2025년 기준 메달리온 아키텍처(Bronze → Silver → Gold)에서 레이어별 포맷을 달리 사용하는 패턴이 증가하고 있습니다.

┌──────────────────────────────────────────────────────────┐
│  Gold Layer (비즈니스 집계, BI/분석 소비 준비)            │
│  → Iceberg 또는 Delta  (멀티엔진, BI 도구 연동)          │
│  → 소규모 고활용 테이블, 파티션 최적화                   │
├──────────────────────────────────────────────────────────┤
│  Silver Layer (정제, 표준화, 도메인 모델)                 │
│  → Iceberg  (스키마 진화, Time Travel, 검증)             │
│  → Hudi  (CDC 소스의 경우 Upsert 정합성 유지)            │
├──────────────────────────────────────────────────────────┤
│  Bronze Layer (원시 데이터, 수집 즉시 저장)               │
│  → Paimon  (Flink 실시간 수집, 초단위 갱신)              │
│  → Hudi MOR  (CDC 소스, 고처리량 upsert)                 │
│  → Iceberg  (단순 Append-only, S3 Tables)                │
└──────────────────────────────────────────────────────────┘

2025년 주류 구현 패턴 4가지:

패턴 Bronze Silver/Gold 브리징 적합 조직

A. Hudi → Iceberg	Hudi MOR (CDC/Upsert)	Iceberg (Spark 정제 + 집계)	XTable 변환	CDC 중심, 멀티엔진 필요
B. Paimon → Iceberg	Paimon (Flink 실시간)	Iceberg (Spark 정제 + 집계)	Iceberg 호환 스냅샷	Flink 중심 조직
C. Delta 단일 + UniForm	Delta (Spark Streaming)	Delta (Spark 처리)	Gold에만 UniForm 적용	Databricks 전용 환경
D. Iceberg 단일 포맷	Iceberg (Append-only)	Iceberg (Spark/Flink 정제)	불필요	멀티클라우드, 벤더 중립 우선

2025년 트렌드: AWS S3 Tables · Snowflake · Google BigQuery · Azure 모두 Iceberg 네이티브 지원으로, Silver/Gold는 Iceberg로 통일하고 Bronze만 수집 특성에 맞는 포맷(Hudi/Paimon)을 쓰는 패턴이 급증하고 있습니다.

사용 사례별 선택 가이드

사용 사례 권장 포맷 이유

Databricks 기반 배치 ETL	Delta Lake	가장 깊은 Databricks 통합, Unity Catalog
멀티 엔진 (Spark + Trino + Flink + Snowflake)	Apache Iceberg	최고 수준 엔진 호환성, REST Catalog 표준, 벤더 중립
고빈도 CDC/Upsert 파이프라인	Apache Hudi	Record-level upsert 특화, NBCC 다중 Writer
Flink 기반 실시간 스트리밍	Apache Paimon	스트리밍 네이티브, 100ms 미만 레이턴시, Flink 네이티브
DuckDB 중심 소규모 분석	DuckLake	운영 단순성, SQL DB 기반 메타데이터, Data Inlining
Snowflake/BigQuery 연동	Apache Iceberg	Snowflake Iceberg Tables, BigQuery BigLake
실시간 집계/부분 업데이트	Apache Paimon	Partial Update Merge Engine, Aggregation Engine
멀티 테이블 원자 트랜잭션	Iceberg + Nessie	현재 유일하게 성숙한 크로스 테이블 원자 커밋
포맷 혼용 환경 상호운용	Apache XTable	데이터 복사 없이 포맷 간 메타데이터 변환
동시 다중 스트리밍 Writer	Apache Hudi (NBCC)	락 없는 다중 writer 동시 실행
벤더 독립성 최우선	Apache Iceberg	ASF 30개+ 기업 공동 거버넌스, 클라우드 3사 네이티브
sub-second freshness + Flink Lookup Join + CDC 핫 경로	Apache Fluss	PK Table 500K QPS 포인트 룩업, Flink 차원 테이블 외부화, A/B 카운터 — Paimon/Iceberg Tiering으로 배치 쿼리까지 자동 연동
실시간 수집 + 배치 멀티엔진 동시 필요	Paimon + Iceberg 혼합	Flink 실시간 수집은 Paimon, 멀티엔진 분석은 Iceberg — Iceberg 호환 스냅샷으로 무복사 브리징
CDC 수집 + 장기 대용량 배치	Hudi(Bronze) + Iceberg(Silver/Gold)	CDC/Upsert는 Hudi MOR, 정제·집계는 Iceberg — XTable로 메타데이터 변환
Databricks Spark + 멀티클라우드 분석	Delta + Iceberg (UniForm)	Delta 단일 쓰기, UniForm으로 Iceberg 메타데이터 자동 생성 — Snowflake/Athena 직접 읽기
Flink 실시간 스트리밍 + 장기 마이크로배치	Fluss + Paimon + Iceberg	핫(Fluss) → 웜(Paimon) → 콜드(Iceberg) 3계층 Streamhouse — Flink SQL Union Read 통합

참고 자료

[Spark] 메모리 관리

불곰1 — Mon, 27 Apr 2026 21:21:24 +0900

1. Unified Memory Manager 구조

Spark 1.6부터 도입된 UnifiedMemoryManager는 Executor JVM 힙을 세 가지 영역으로 구분합니다.

메모리 영역 구조

┌──────────────────────────────────────────────────────────┐
│                  Executor JVM Heap (예: 20GB)             │
├──────────────────────────────────────────────────────────┤
│  Reserved Memory       │  300MB (고정, 변경 불가)          │
├──────────────────────────────────────────────────────────┤
│  User Memory           │  Usable × (1 - 0.6) = 40%       │
│  (사용자 코드, UDF 등)   │                                  │
├──────────────────────────────┬───────────────────────────┤
│  Storage Memory  (30%)       │  Spark Memory             │
│  캐시, 브로드캐스트 변수       │  Usable × 0.6 = 60%       │
├──────────────────────────────┤                           │
│  Execution Memory (30%)      │                           │
│  셔플, 조인, 정렬, 집계        │                           │
└──────────────────────────────┴───────────────────────────┘

동적 메모리 차용 (Dynamic Borrowing)

Execution → Storage 강제 퇴출 가능: Execution 메모리가 부족하면 Storage 캐시 블록을 내보냄
Storage → Execution 유휴 공간 활용 가능: 단, 나중에 Execution이 요청하면 즉시 반환해야 함
spark.memory.storageFraction은 Storage의 최소 보장선으로 작용

메모리 계산 공식

# 실제 예시 (executor.memory = 20GB, 기본값 기준)
executor_memory    = 20 * 1024  # MB
reserved_memory    = 300        # MB (고정)
usable_memory      = executor_memory - reserved_memory  # 19,900MB

user_memory        = usable_memory * (1 - 0.6)   # 7,960MB (~40%)
spark_memory       = usable_memory * 0.6          # 11,940MB (~60%)

storage_memory     = spark_memory * 0.5           # 5,970MB
execution_memory   = spark_memory * 0.5           # 5,970MB

2. 핵심 설정 파라미터

파라미터	기본값	설명
`spark.executor.memory`	1g	Executor당 JVM 힙 메모리
`spark.executor.memoryOverhead`	max(10%, 384MB)	JVM 외부 오버헤드 (Metaspace, 네이티브 등)
`spark.driver.memory`	1g	Driver JVM 힙 메모리
`spark.driver.maxResultSize`	1g	collect() 결과 최대 크기
`spark.memory.fraction`	0.6	힙 중 Spark가 관리하는 비율
`spark.memory.storageFraction`	0.5	Spark Memory 중 Storage 최소 보장 비율
`spark.sql.shuffle.partitions`	200	셔플 파티션 수
`spark.memory.offHeap.enabled`	false	Off-Heap 메모리 활성화 여부
`spark.memory.offHeap.size`	0	Off-Heap 크기 (bytes)

설정 예시 (PySpark)

from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .appName("MemoryTuning") \
    .config("spark.executor.memory", "8g") \
    .config("spark.executor.memoryOverhead", "2g") \
    .config("spark.driver.memory", "4g") \
    .config("spark.driver.maxResultSize", "2g") \
    .config("spark.memory.fraction", "0.6") \
    .config("spark.memory.storageFraction", "0.5") \
    .config("spark.sql.shuffle.partitions", "400") \
    .getOrCreate()

설정 예시 (Scala)

import org.apache.spark.SparkConf
import org.apache.spark.sql.SparkSession

val conf = new SparkConf()
  .setAppName("MemoryTuning")
  .set("spark.executor.memory", "8g")
  .set("spark.executor.memoryOverhead", "2g")
  .set("spark.driver.memory", "4g")
  .set("spark.memory.fraction", "0.6")
  .set("spark.memory.storageFraction", "0.5")
  .set("spark.sql.shuffle.partitions", "400")

val spark = SparkSession.builder().config(conf).getOrCreate()

spark-submit 명령어 예시

spark-submit \
  --class com.example.MyJob \
  --master yarn \
  --deploy-mode cluster \
  --executor-memory 8g \
  --driver-memory 4g \
  --conf "spark.executor.memoryOverhead=2g" \
  --conf "spark.memory.fraction=0.6" \
  --conf "spark.sql.shuffle.partitions=400" \
  myapp.jar

3. 캐시와 퍼시스트 전략

StorageLevel 종류 비교

StorageLevel	메모리	디스크	직렬화	특징
`MEMORY_ONLY`	O	X	X	RDD 기본값. 메모리 부족 시 재계산
`MEMORY_AND_DISK`	O	O	X	DataFrame 기본값. 메모리 초과 시 디스크로
`MEMORY_ONLY_SER`	O (직렬화)	X	O	메모리 절약, CPU 오버헤드 증가
`MEMORY_AND_DISK_SER`	O (직렬화)	O	O	직렬화 + 디스크 조합, 안전한 선택
`DISK_ONLY`	X	O	O	메모리 매우 부족할 때 사용
`MEMORY_ONLY_2`	O	X	X	2 복제본 유지, 내결함성 필요 시
`OFF_HEAP`	Off-heap	X	O	JVM GC 부하 없음, offHeap 설정 필요

StorageLevel 선택 가이드

코드 예시 (PySpark)

from pyspark import StorageLevel
from pyspark.sql import SparkSession

spark = SparkSession.builder.appName("CacheDemo").getOrCreate()
df = spark.range(10_000_000)

# cache() — DataFrame 기본: MEMORY_AND_DISK
df.cache()

# 명시적 StorageLevel 지정
df.persist(StorageLevel.MEMORY_ONLY)          # 메모리만, 부족 시 재계산
df.persist(StorageLevel.MEMORY_AND_DISK)      # 메모리 후 디스크 스필
df.persist(StorageLevel.MEMORY_ONLY_SER)      # 직렬화로 메모리 절약
df.persist(StorageLevel.MEMORY_AND_DISK_SER)  # 직렬화 + 디스크 조합
df.persist(StorageLevel.DISK_ONLY)            # 디스크만
df.persist(StorageLevel.OFF_HEAP)             # Off-Heap (설정 필요)

# 캐시 해제 (중요: 안 하면 메모리 누수)
df.unpersist()

코드 예시 (Scala)

import org.apache.spark.storage.StorageLevel
import org.apache.spark.sql.SparkSession

val spark = SparkSession.builder().appName("CacheDemo").getOrCreate()
val df = spark.range(10000000L)

df.cache()
df.persist(StorageLevel.MEMORY_ONLY)
df.persist(StorageLevel.MEMORY_AND_DISK)
df.persist(StorageLevel.MEMORY_ONLY_SER)
df.persist(StorageLevel.OFF_HEAP)

df.unpersist()
spark.stop()

4. Off-Heap 메모리

전체 메모리 구성

Total Container Memory
= spark.executor.memory         (JVM 힙)
+ spark.executor.memoryOverhead (JVM 외부 오버헤드)
+ spark.memory.offHeap.size     (Spark 관리 Off-Heap)
+ pyspark.executor.memory       (Python 프로세스, PySpark만)

설정 및 사용 예시

from pyspark.sql import SparkSession
from pyspark import StorageLevel

spark = SparkSession.builder \
    .appName("OffHeapDemo") \
    .config("spark.executor.memory", "4g") \
    .config("spark.memory.offHeap.enabled", "true") \
    .config("spark.memory.offHeap.size", "4294967296")  # 4GB in bytes
    .getOrCreate()

df = spark.range(5_000_000)

# OFF_HEAP StorageLevel로 캐시
df.persist(StorageLevel.OFF_HEAP)
df.count()  # 액션 실행으로 캐시 활성화

print(df.count())  # 캐시에서 읽기
df.unpersist()

Off-Heap 권장 상황

매우 큰 데이터셋을 캐시할 때 GC 부하 감소가 필요할 경우
긴 GC pause로 성능이 저하될 때
Tungsten 기반 연산 최적화가 필요할 때

5. GC 튜닝 (G1GC + Kryo 직렬화)

Kryo 직렬화

spark = SparkSession.builder \
    .appName("KryoDemo") \
    .config("spark.serializer", "org.apache.spark.serializer.KryoSerializer") \
    .config("spark.kryoserializer.buffer.max", "512m") \
    .config("spark.kryoserializer.buffer", "64m") \
    .getOrCreate()

val conf = new SparkConf()
  .set("spark.serializer", "org.apache.spark.serializer.KryoSerializer")
  .set("spark.kryoserializer.buffer.max", "512m")
  // 커스텀 클래스 등록으로 직렬화 크기 최소화
  .registerKryoClasses(Array(
    classOf[MyDataClass],
    classOf[AnotherClass]
  ))

G1GC 설정

Spark 4.0부터 G1GC가 기본 GC입니다. Spark 3.x에서는 명시적으로 설정해야 합니다.

PySpark에서도 JVM Executor에 그대로 적용됩니다. 단, Python Worker 프로세스는 Python GC로 별도 관리되며 G1GC 설정의 영향을 받지 않습니다.

spark-submit \
  --conf "spark.executor.extraJavaOptions=\
    -XX:+UseG1GC \
    -XX:G1HeapRegionSize=16m \
    -XX:+UseCompressedOops \
    -XX:InitiatingHeapOccupancyPercent=35 \
    -XX:ConcGCThreads=4 \
    -verbose:gc \
    -XX:+PrintGCDetails" \
  --conf "spark.driver.extraJavaOptions=-XX:+UseG1GC" \
  myapp.jar

spark = SparkSession.builder \
    .config("spark.executor.extraJavaOptions",
            "-XX:+UseG1GC "
            "-XX:G1HeapRegionSize=16m "
            "-XX:+UseCompressedOops "
            "-XX:InitiatingHeapOccupancyPercent=35") \
    .config("spark.serializer", "org.apache.spark.serializer.KryoSerializer") \
    .getOrCreate()

GC 진단 가이드

증상	원인	해결책
Full GC 빈번 발생	Execution 메모리 부족	`spark.memory.fraction` 증가
Minor GC 잦음	Eden 영역 부족	`-Xmn` 값 증가
OldGen 거의 꽉 참	캐시 과다 사용	`storageFraction` 감소
GC pause > 1초	G1GC 설정 미최적화	`G1HeapRegionSize` 증가

6. OOM 해결 방법

6-1. Executor OOM

# 원인: 파티션당 데이터 과다, 셔플/조인 시 메모리 부족

# 해결 1: 파티션 수 증가 (파티션당 128~256MB 목표)
df_repartitioned = df.repartition(500)

# 해결 2: 셔플 파티션 수 증가
spark.conf.set("spark.sql.shuffle.partitions", "500")

# 해결 3: Executor 메모리 및 Overhead 증가
spark = SparkSession.builder \
    .config("spark.executor.memory", "12g") \
    .config("spark.executor.memoryOverhead", "2g") \
    .getOrCreate()

# 해결 4: Execution 메모리 비율 증가 (Storage 줄이기)
spark.conf.set("spark.memory.storageFraction", "0.3")

6-2. Driver OOM

# 잘못된 방법 — Driver OOM 위험
result = df.collect()  # 전체 데이터를 Driver로 가져옴

# 올바른 방법
result = df.take(100)             # 일부만 가져오기
df.write.parquet("/output/path")  # 스토리지에 직접 쓰기

# Driver 메모리 설정
spark = SparkSession.builder \
    .config("spark.driver.memory", "8g") \
    .config("spark.driver.maxResultSize", "4g") \
    .getOrCreate()

# 브로드캐스트 임계값 조정
spark.conf.set("spark.sql.autoBroadcastJoinThreshold", "100m")

6-3. Skew (데이터 편향) 처리

# AQE로 Skew Join 자동 처리 (Spark 3.0+)
spark.conf.set("spark.sql.adaptive.enabled", "true")
spark.conf.set("spark.sql.adaptive.skewJoin.enabled", "true")
spark.conf.set("spark.sql.adaptive.skewJoin.skewedPartitionFactor", "5")
spark.conf.set("spark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes", "256m")

# 수동 Salting 기법 (AQE 미지원 환경)
from pyspark.sql.functions import col, rand, concat, lit, floor

df_salted = df.withColumn(
    "salted_key",
    concat(col("key"), lit("_"), (floor(rand() * 10)).cast("string"))
)

종합 프로덕션 설정 템플릿

spark = SparkSession.builder \
    .appName("ProductionJob") \
    # === 메모리 기본 설정 ===
    .config("spark.executor.memory", "8g") \
    .config("spark.executor.memoryOverhead", "2g") \
    .config("spark.driver.memory", "4g") \
    .config("spark.driver.maxResultSize", "2g") \
    # === 메모리 비율 ===
    .config("spark.memory.fraction", "0.6") \
    .config("spark.memory.storageFraction", "0.4") \
    # === 직렬화 ===
    .config("spark.serializer", "org.apache.spark.serializer.KryoSerializer") \
    .config("spark.kryoserializer.buffer.max", "512m") \
    # === AQE (Spark 3.0+) ===
    .config("spark.sql.adaptive.enabled", "true") \
    .config("spark.sql.adaptive.coalescePartitions.enabled", "true") \
    .config("spark.sql.adaptive.skewJoin.enabled", "true") \
    # === 파티션 ===
    .config("spark.sql.shuffle.partitions", "400") \
    # === GC ===
    .config("spark.executor.extraJavaOptions",
            "-XX:+UseG1GC -XX:G1HeapRegionSize=16m -XX:+UseCompressedOops") \
    .getOrCreate()

7. Spark 3.x 메모리 관리 개선사항

버전별 주요 변경사항

Spark 3.0 — AQE 도입 및 StaticMemoryManager 제거
- StaticMemoryManager 완전 제거: UnifiedMemoryManager만 남음
- AQE (Adaptive Query Execution) 정식 도입
- Off-Heap 분리: memoryOverhead와 offHeap.size가 완전히 별개 항목으로 분리
- REST API 메모리 메트릭 강화: Peak JVM heap, execution/storage 메모리 추적 가능
- # AQE 활성화 (3.0에서는 기본값 false) spark.conf.set("spark.sql.adaptive.enabled", "true") spark.conf.set("spark.sql.adaptive.coalescePartitions.enabled", "true")
Spark 3.2 — AQE 기본 활성화
- AQE 기본 활성화: spark.sql.adaptive.enabled=true가 기본값으로 변경
- AQE 파티션 자동 병합: 소규모 셔플 파티션을 자동으로 코얼레스
- Push-Based Shuffle: 메모리 효율 향상
- # 3.2+에서는 별도 설정 없어도 AQE 활성화됨 spark.conf.set("spark.sql.adaptive.advisoryPartitionSizeInBytes", "128m") spark.conf.set("spark.sql.adaptive.coalescePartitions.minPartitionNum", "1")
Spark 3.4 / 3.5 — Bloom Filter 및 ZSTD 압축
- Bloom Filter Join: 메모리 효율적 조인 전략 도입
- ZSTD 압축 기본 지원: 셔플 데이터 압축으로 메모리/디스크 절약
- State Store 메모리 개선: 구조적 스트리밍 상태 저장소 최적화
- spark = SparkSession.builder \ .config("spark.sql.adaptive.enabled", "true") \ .config("spark.sql.optimizer.runtime.bloomFilter.enabled", "true") \ .config("spark.sql.optimizer.runtime.bloomFilter.creationSideThreshold", "10m") \ .config("spark.io.compression.codec", "zstd") \ .getOrCreate()

AQE가 OOM을 방지하는 원리

8. 메모리 관리 체크리스트

✨ 설정 단계 체크리스트

기본 메모리 설정

spark.executor.memory 데이터 크기에 맞게 설정
spark.executor.memoryOverhead 설정 완료 (executor.memory의 10% 이상 또는 384MB)
spark.driver.memory 설정 완료
spark.driver.maxResultSize 제한 설정 (collect() 남용 방지)
spark.sql.shuffle.partitions 데이터 크기에 맞게 조정 (파티션당 128~256MB 목표)

직렬화 설정

Kryo 직렬화 활성화 (spark.serializer=KryoSerializer) — Scala/Java 권장 (PySpark는 JVM 셔플 일부에만 적용됨)
spark.kryoserializer.buffer.max 설정 (512m 권장)
Scala 프로젝트라면 코드내 커스텀 클래스 Kryo 등록 여부 확인
PySpark라면 Python UDF 대신 Pandas UDF 사용 여부 검토 (Arrow 기반, 성능 대폭 향상)

GC 설정

spark.executor.extraJavaOptions에 G1GC 설정 포함 (-XX:+UseG1GC)
spark.memory.fraction 기본값(0.6) 사용 여부 검토
spark.memory.storageFraction 케시 비율 요구사항에 맞게 조정

Off-Heap (필요 시에만)

spark.memory.offHeap.enabled=true 설정
spark.memory.offHeap.size 적절히 설정
컨테이너 전체 메모리 = executor.memory + memoryOverhead + offHeap.size 카운팅 확인

코드 단계 체크리스트

캐시 관리

반복 사용되는 DataFrame/RDD에만 캐시 적용
사용 완료된 캐시는 unpersist() 명시적으로 해제
데이터 크기에 맞는 StorageLevel 선택 (메모리 부족 시 MEMORY_AND_DISK_SER 고려)
사용되지 않는 컨럼은 조기에 select()/drop()으로 제거

데이터 처리

collect() 호출 없음 (대신 write() 또는 take() 사용)
브로드캐스트 변수 크기 확인 (100MB 이하 권장)
파티션 크기 적절함 (파티션당 128~256MB 목표)
Skew 위험이 있는 조인에 AQE 또는 Salting 적용 검토

운영 모니터링 체크리스트

Spark UI 확인 항목

Executors 탭 → Storage Memory Used 비율 80% 이하 유지
Stages 탭 → Spill (Memory) / Spill (Disk) 발생 여부
Stages 탭 → GC Time 비율 5% 이하 유지
Tasks 탭 → Duration 편차 확인 (Skew 여부)

메모리 지표 임계값

지표	정상	경고	위험
GC Time 비율	< 5%	5 ~ 10%	> 10%
Storage Memory 사용률	< 70%	70 ~ 85%	> 85%
Spill (Disk)	0	가끔 발생	빈번 발생
Task 최대/평균 Duration 비율	< 2x	2 ~ 5x	> 5x (Skew 의심)

OOM 발생 시 진단 체크리스트

Executor OOM 진단

에러 메시지에 Java heap space 포함 여부 확인
Spark UI에서 가장 크거나 느린 Task 식별
Spill (Memory/Disk) 발생 여부 확인
spark.sql.shuffle.partitions 증가 (2배씨 조정)
spark.executor.memory 증가
spark.executor.memoryOverhead 증가 (네이티브 라이브러리 사용 시)

Driver OOM 진단

에러 메시지에 Java heap space 포함 여부 확인
코드내 collect() 호출 여부 확인
spark.driver.maxResultSize 초과 여부 확인
브로드캐스트 변수 크기 확인 (100MB 이상 제한 검토)
spark.driver.memory 증가

Skew OOM 진단

Task Duration 편차가 큰지 Spark UI에서 확인
특정 키에 데이터가 편중되는지 확인
AQE skewJoin 활성화 여부 확인
필요 시 Salting 기법 적용 검토

참고 자료

LLM, RAG, LangChain, LangGraph, MCP 개념 및 예시

불곰1 — Mon, 27 Apr 2026 02:25:18 +0900

I. LLM (대규모 언어 모델)

개념

대규모 언어 모델(LLM)은 방대한 텍스트로 학습된 AI 시스템으로, 자연어를 이해하고 생성합니다. 핵심 원리는 다음 토큰 예측이며, 이를 통해 번역·요약·코드 생성 같은 다양한 작업을 수행합니다.

LLM의 한계

LLM에는 내재적 한계가 있으며, 이 때문에 RAG·MCP·LangChain 같은 기술이 등장했습니다.

환각(Hallucination): 사실이 아닌 내용을 그럴듯하게 생성
지식 단절(Knowledge Cutoff): 마지막 훈련 날짜 이후 정보 없음
도메인 특수성 부족: 전문 분야 깊이 있는 지식 부족
높은 컴퓨팅 비용: 대규모 자원 필요
편향(Bias): 훈련 데이터의 편향을 학습·증폭

산업별 응용

고객 서비스: 자동화 챗봇 및 대화형 에이전트
의료: 환자 보고서 분석 및 관리 업무 간소화
금융: 사기 탐지, 금융 리스크 평가
콘텐츠 제작: 기사, 마케팅 문구 등 텍스트 생성

기본 LLM 호출 예시

# pip install langchain-openai
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)
response = llm.invoke("셀프 어텐션 개념을 한 문장으로 설명해줘.")
print(response.content)

II. RAG (검색 증강 생성)

개념

검색 증강 생성(RAG)은 응답 생성 전에 외부 지식 베이스에서 관련 정보를 검색하여 LLM 출력을 향상시키는 아키텍처 패턴입니다. LLM의 환각과 지식 단절 문제를 해결합니다.

RAG 파이프라인 구조

1단계: 데이터 인덱싱 (오프라인)

데이터 로딩: PDF, 데이터베이스, API 등에서 데이터 수집
청킹: 큰 문서를 작은 단위로 분할
임베딩: 텍스트를 수치 벡터로 변환
인덱싱: 벡터 DB에 저장 (Pinecone, Chroma, FAISS 등)

2단계: 검색 및 생성 (실시간)

사용자 쿼리 입력
쿼리 임베딩: 쿼리를 벡터로 변환
검색: 유사한 문서 청크 검색
증강: 검색 결과를 프롬프트에 추가
생성: LLM이 맥락을 바탕으로 답변 생성

장단점

장점

정확성 향상 및 환각 감소
실시간 최신 데이터 접근
미세 조정보다 비용 효율적
출처 인용 가능 (투명성)
독점 데이터 프라이버시 보호

과제

검색 품질에 크게 의존
청킹 전략이 성능에 큰 영향
대규모 데이터 인덱싱 비용

RAG 파이프라인 vs. RAG 플랫폼

기능 RAG 파이프라인 (직접 구축) RAG 플랫폼 (통합 제품)

통합 노력	높음 — 구성 요소 직접 통합	낮음 — 즉시 사용 가능
프로덕션 준비성	낮음 — 직접 구축 필요	높음 — 엔터프라이즈급
확장성	복잡 — 수동 관리 필요	간편 — 자동 확장
유연성	매우 높음	제한적
가치 실현 시간	길다 (수개월)	짧다 (즉시)

주요 RAG 라이브러리

라이브러리 특징 최적 사용 사례

LangChain	방대한 통합, LCEL 체인	다양한 LLM 앱 프로토타이핑
LlamaIndex	데이터-LLM 연결 특화	대규모 데이터셋 RAG
Haystack	검색·QA 파이프라인	프로덕션급 검색 시스템

RAG 구현 예시

# pip install langchain langchain-openai faiss-cpu beautifulsoup4
from langchain_community.document_loaders import WebBaseLoader
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import FAISS
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain.chains.combine_documents import create_stuff_documents_chain
from langchain_core.prompts import ChatPromptTemplate
from langchain.chains import create_retrieval_chain
from langchain_openai import ChatOpenAI

loader = WebBaseLoader("<https://en.wikipedia.org/wiki/Large_language_model>")
docs = loader.load()

text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=200)
splits = text_splitter.split_documents(docs)

embeddings = OpenAIEmbeddings()
vectorstore = FAISS.from_documents(documents=splits, embedding=embeddings)
retriever = vectorstore.as_retriever()

llm = ChatOpenAI(model="gpt-4o-mini")
prompt = ChatPromptTemplate.from_template("""다음 컨텍스트만 사용해서 답해줘:


{context}


질문: {input}""")

document_chain = create_stuff_documents_chain(llm, prompt)
retrieval_chain = create_retrieval_chain(retriever, document_chain)

response = retrieval_chain.invoke({"input": "What is a large language model?"})
print(response["answer"])

III. LangChain

개념

LangChain은 LLM 기반 애플리케이션 개발을 위한 오픈소스 프레임워크로, 다양한 구성 요소를 연결하는 '접착제' 역할을 합니다.

핵심 구성 요소

모델(Models): LLM·채팅 모델·임베딩 모델을 위한 표준 인터페이스
프롬프트(Prompts): 동적 프롬프트 템플릿 관리
체인(Chains): LLM과 다른 구성 요소를 순차 결합 (LCEL 사용)
검색(Retrieval): 문서 로더·분할기·벡터 저장소·검색기 (RAG 핵심)
에이전트(Agents): LLM을 추론 엔진으로 사용, 도구 선택·실행
메모리(Memory): 호출 간 상태 유지, 다중 턴 대화

장단점

강점

수백 개 서드파티 통합 제공
고수준 추상화로 빠른 프로토타이핑
공통 구성 요소 표준 인터페이스

약점

추상화가 디버깅을 어렵게 할 수 있음
빠른 변화로 호환성 문제 가능
복잡한 순환 워크플로우 구현 어려움 → LangGraph 사용

주요 사용 사례

RAG 챗봇: 내부 문서 기반 Q&A
메모리 챗봇: 과거 대화를 기억하는 에이전트
문서 요약: 맵-리듀스 방식으로 긴 문서 요약
자동화 에이전트: 웹 검색 등 도구를 활용하는 에이전트

맵-리듀스 요약 예시

# pip install langchain langchain-openai
from langchain_openai import ChatOpenAI
from langchain.chains.summarize import load_summarize_chain
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_core.documents import Document

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

long_text = """
Large language models are advanced AI systems that understand and generate natural language.
LLMs are trained on vast amounts of text data.
However, LLMs have limitations such as knowledge cutoff and hallucination.
RAG connects LLMs to external knowledge bases to address these issues.
"""

docs = [Document(page_content=long_text)]
text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=100)
split_docs = text_splitter.split_documents(docs)

chain = load_summarize_chain(llm, chain_type="map_reduce")
summary = chain.invoke(split_docs)
print(summary['output_text'])

IV. LangGraph

개념

LangGraph는 LangChain의 확장으로, 상태를 가진 다중 에이전트 애플리케이션을 그래프 형태로 구성합니다. 루프·분기·조건 로직이 필요한 복잡한 워크플로우에 적합합니다.

핵심 구성 요소

상태(State): 그래프 전체에서 공유되는 데이터 구조 (TypedDict)
노드(Nodes): 작업 단위인 파이썬 함수 (LLM 호출, 도구 실행 등)
엣지(Edges): 노드 간 흐름 제어. 조건부 엣지로 동적 라우팅 가능

LangChain vs. LangGraph

기준 LangChain LangGraph

워크플로우	선형, 순차적 (DAG)	순환 그래프, 루프, 복잡한 분기
상태 관리	암시적 (메모리 객체)	명시적 중앙 집중 상태 객체
Human-in-the-Loop	구현 복잡	중단점 기능으로 기본 지원
다중 에이전트	제한적	기본 설계 목적
단순 작업	간단하고 직관적	설정 많이 필요, 과도할 수 있음

언제 사용할까?

LangChain 사용: 단순 순차 워크플로우, 기본 RAG 파이프라인

LangGraph 사용: 루프·자기 교정이 필요한 경우, 명시적 상태 관리, 다중 에이전트 협업, Human-in-the-Loop

LangGraph 상태 기반 에이전트 예시

# pip install langgraph langchain-openai pydantic
from typing import TypedDict, List, Optional
from langchain_core.pydantic_v1 import BaseModel, Field
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langgraph.graph import StateGraph, END

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

class AgentState(TypedDict):
    task: str
    plan: Optional[List[str]]
    executed_steps: Optional[List[str]]
    response: str

class Plan(BaseModel):
    steps: List[str] = Field(description="실행할 단계 목록")

planner_prompt = ChatPromptTemplate.from_template("다음 작업을 위한 단계별 계획을 세워줘: {task}")
planner = (planner_prompt | llm).with_structured_output(Plan)

def plan_step(state: AgentState) -> dict:
    result = planner.invoke({"task": state['task']})
    return {"plan": result.steps, "executed_steps": []}

executor_prompt = ChatPromptTemplate.from_template(
    "'{step}' 단계를 실행해줘. 이전 단계: {executed_steps}. 작업: {task}"
)
executor = executor_prompt | llm

def execute_step(state: AgentState) -> dict:
    plan = state['plan']
    executed = state['executed_steps']
    current_step = plan[len(executed)]
    result = executor.invoke({
        "step": current_step,
        "executed_steps": ", ".join(executed) if executed else "없음",
        "task": state['task']
    })
    executed.append(f"{current_step}: {result.content}")
    return {"executed_steps": executed}

def final_response(state: AgentState) -> dict:
    return {"response": "\\n".join(state['executed_steps'])}

def should_continue(state: AgentState) -> str:
    return "continue" if len(state['executed_steps']) < len(state['plan']) else "end"

workflow = StateGraph(AgentState)
workflow.add_node("planner", plan_step)
workflow.add_node("executor", execute_step)
workflow.add_node("final_responder", final_response)

workflow.set_entry_point("planner")
workflow.add_edge("planner", "executor")
workflow.add_conditional_edges("executor", should_continue, {
    "continue": "executor",
    "end": "final_responder"
})
workflow.add_edge("final_responder", END)

app = workflow.compile()
result = app.invoke({"task": "RAG의 장점에 대한 블로그 포스트 작성"})
print(result['response'])

V. MCP (모델 컨텍스트 프로토콜)

개념

MCP(Model Context Protocol)는 AI 시스템이 외부 도구 및 데이터 소스와 통신하는 방식을 표준화한 오픈 표준입니다. "AI를 위한 USB-C" — 어떤 AI 모델도 MCP를 구현한 도구에 연결할 수 있습니다.

Anthropic이 만들었으며 OpenAI, Google DeepMind, Microsoft 등 주요 AI 기업이 채택했습니다.

구조

MCP 서버: 도구와 데이터를 노출하는 애플리케이션
MCP 클라이언트: AI 호스트에 내장되어 서버에 연결

주요 사용 사례

엔터프라이즈 어시스턴트: 챗봇을 내부 문서·CRM·지식 베이스에 연결
다중 도구 에이전트: 여러 도구 조율 (Google Drive 조회 후 Slack 전송 등)
개발 도구: AI를 IDE 및 개발 환경에 통합

fastMCP 사용 예시

# pip install fastmcp
import asyncio
from fastmcp import Client

async def main():
    client = Client("mcp://calendar.example.com")

    async with client:
        tools = await client.list_tools()
        print(f"사용 가능한 도구: {[tool.name for tool in tools]}")

        response = await client.call_tool(
            "create_event",
            {"title": "팀 미팅", "date": "2025-12-01"}
        )
        print(f"서버 응답: {response}")

asyncio.run(main())

<aside> ⚠️

보안 주의: MCP는 도구 및 데이터 접근을 허용하므로 프롬프트 주입, 과도한 권한 부여, 악의적 도구 등 보안 위험에 주의해야 합니다.

</aside>

VI. 기술 스택 통합

전체 아키텍처

각 기술은 경쟁 관계가 아닌 상호 보완적인 계층입니다.

LLM: 생성 능력의 기초
RAG: 외부 지식 베이스 연결, 환각 감소
LangChain: RAG 파이프라인 구성 및 오케스트레이션
LangGraph: 루프·조건·다중 에이전트 워크플로우 관리
MCP: 외부 도구·API와 표준화된 통신

도구 선택 가이드

RAG: 정확성이 필요한 모든 앱의 출발점
LangChain: 단순 순차 체인, 빠른 프로토타이핑
LangGraph: 루프·조건·다중 에이전트 필요 시
MCP: 외부 서비스 연결 표준화

미래 방향

패러다임은 단일 모델에서 모듈식·전문화·오케스트레이션된 시스템으로 이동 중입니다.

"플로우 엔지니어링": 프롬프트 최적화보다 에이전트 행동 설계에 집중
MCP 표준화로 도구 생태계 통합 가속
Multi-Agent 시스템이 복잡한 실무 문제 해결의 핵심

VII. CrewAI

개념

CrewAI는 역할 기반 AI 에이전트들이 팀을 이루어 협업하는 Python 프레임워크입니다. 각 에이전트가 직무(role)·목표(goal)·배경(backstory)·도구(tools)를 가지고 일하며, Crew가 Process에 따라 Task를 처리합니다. 2026년 기준 안정 버전은 v1.14.3이며, Crew(자율 협업)와 Flow(이벤트 기반 결정론 워크플로우) 두 축으로 구성됩니다.

LangChain / LangGraph와의 차이

항목 LangChain LangGraph CrewAI

핵심 추상	LLM/도구/체인 빌딩 블록	상태 머신 그래프	역할 기반 에이전트 팀
코드량	중간	많음 (명시적 제어)	적음 (~20줄로 동작)
강점	도구 생태계, RAG	결정론, 체크포인트, HITL	빠른 프로토타이핑, 직관적 역할 분담
약점	멀티에이전트 추상 약함	보일러플레이트 많음	분기/루프 복잡한 워크플로에 부적합
LangChain 도구 호환	—	완전 호환	완전 호환 (LiteLLM 기반)

핵심 구성 요소

Agent: role + goal + backstory + tools + llm + allow_delegation
Task: description + expected_output + agent + context (이전 태스크 출력 주입)
Crew: 에이전트·태스크 컨테이너. memory=True, cache=True, verbose=True 설정 가능
Process: sequential (순서대로) / hierarchical (매니저 에이전트가 동적 위임)

뉴스 리서처 + 작가 예시

# pip install "crewai>=1.14" "crewai-tools"
from dotenv import load_dotenv
from crewai import Agent, Task, Crew, Process, LLM
from crewai_tools import SerperDevTool

load_dotenv()  # OPENAI_API_KEY, SERPER_API_KEY

llm = LLM(model="openai/gpt-4o-mini", temperature=0.2)
search_tool = SerperDevTool(n_results=5, search_type="news")

researcher = Agent(
    role="시니어 AI 뉴스 리서처",
    goal="{topic}에 대한 최근 7일 내 뉴스 5건을 찾아 요약한다.",
    backstory="10년 경력의 IT 저널리스트. 출처 URL과 발행일을 항상 포함한다.",
    tools=[search_tool],
    llm=llm,
    verbose=True,
)

writer = Agent(
    role="테크 콘텐츠 작가",
    goal="리서치 결과를 한국어 뉴스레터로 작성한다.",
    backstory="비전공 독자도 이해할 수 있는 기술 트렌드 작가.",
    llm=llm,
)

research_task = Task(
    description="{topic} 관련 최신 뉴스 5건 수집. 제목/날짜/출처/요점 3개/URL 포함.",
    expected_output="5개 항목의 마크다운 리스트",
    agent=researcher,
)

writing_task = Task(
    description="리서치 결과로 한국어 뉴스레터를 작성한다. 각 기사는 H3 + 4~5문장 + 원문 링크.",
    expected_output="발행 가능한 한국어 마크다운 뉴스레터",
    agent=writer,
    context=[research_task],
    output_file="newsletter.md",
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, writing_task],
    process=Process.sequential,
    memory=True,
    verbose=True,
)

result = crew.kickoff(inputs={"topic": "온디바이스 LLM 최신 동향"})
print(result.raw)

MCP 통합 예시

# pip install "crewai-tools[mcp]"
from mcp import StdioServerParameters
from crewai_tools import MCPServerAdapter
from crewai import Agent, Task, Crew

params = StdioServerParameters(command="uvx", args=["pubmedmcp@0.1.3"])
with MCPServerAdapter(params) as tools:
    agent = Agent(role="Medical Researcher", goal="PubMed 검색", tools=tools)
    task = Task(description="CRISPR 최신 논문 5건 요약", agent=agent,
                expected_output="요약 리스트")
    Crew(agents=[agent], tasks=[task]).kickoff()

언제 사용할까?

CrewAI: 명확한 역할 분담, 빠른 프로토타이핑, 콘텐츠/리서치 파이프라인
LangGraph: 분기·루프·Human-in-the-Loop·체크포인트가 필요한 경우
조합: LangGraph(외곽 컨트롤러) + CrewAI(내부 창의 협업 노드) + MCP(도구 표준)

VIII. Claude Code 개념

Claude Code vs Claude Desktop

항목 Claude Code (CLI) Claude Desktop (GUI)

설치	npm install -g @anthropic-ai/claude-code	claude.ai/download 에서 .dmg/.exe
주 사용 사례	코드베이스 작업, git 자동화, 멀티파일 리팩터링	일반 대화, 문서 작업, Artifacts 생성
에이전트/서브에이전트	Task 도구로 서브에이전트 스폰, 병렬 실행	없음
스킬 (Skill)	~/.claude/skills/ 슬래시 커맨드	Custom Skills (Claude.ai)
Hooks	settings.json 라이프사이클 이벤트	없음
Artifacts	없음 (파일 직접 편집)	우측 패널 인터랙티브 콘텐츠
MCP 추가 방법	claude mcp add <name>	.mcpb 더블클릭 또는 config.json
커넥터	제한적	Notion, GDrive, GitHub, Slack 등 50+

에이전트 & 서브에이전트

메인 에이전트는 사용자와 직접 대화하는 세션입니다. 서브에이전트는 Task 도구로 스폰되는 격리된 워커로, 독립적인 컨텍스트·권한·모델을 보유합니다.

# 단일 메시지에서 독립 태스크를 병렬로 실행 (최대 7개 동시)
Task({ subagent_type: "general-purpose", model: "haiku",  prompt: "파일 검색" })
Task({ subagent_type: "code-reviewer",  model: "sonnet", prompt: "코드 리뷰" })
Task({ subagent_type: "executor",       model: "opus",   prompt: "복잡한 구현" })

모델 라우팅: haiku (빠른 조회) / sonnet (표준, 기본) / opus (복잡한 분석)

서브에이전트 정의 파일: .claude/agents/<name>.md (프로젝트) 또는 ~/.claude/agents/<name>.md (글로벌)

스킬 (Skill)

/skill-name 슬래시 커맨드로 호출하거나 description 매칭으로 자동 트리거됩니다.

파일 위치: ~/.claude/skills/<name>/SKILL.md (글로벌) / .claude/skills/<name>/SKILL.md (프로젝트)

---
name: my-skill
description: When user asks for X, do Y...
---

# Skill 내용
구체적인 instructions...

초기에는 name + description만 로드하고 (≈100 토큰), 매칭되면 full body를 로드합니다 (≤5K 토큰).

툴 (Tool)

내장 툴: Read, Write, Edit, Bash, Task, Grep, Glob, WebFetch, WebSearch

Deferred 툴: 모든 툴 스키마를 한 번에 로드하지 않고 ToolSearch로 필요할 때 로드 → 컨텍스트 절약

# MCP 외부 툴 추가
claude mcp add github --scope user
claude mcp add playwright npx @playwright/mcp@latest

Hooks

주요 이벤트: PreToolUse / PostToolUse / UserPromptSubmit / Stop / SessionStart

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit|MultiEdit",
      "hooks": [{
        "type": "command",
        "command": "npx prettier --write \\"$CLAUDE_TOOL_INPUT_FILE_PATH\\""
      }]
    }],
    "Stop": [{
      "hooks": [{ "type": "command", "command": "scripts/notify-done.sh" }]
    }]
  }
}

Exit code: 0 (통과) / 2 (PreToolUse에서 툴 차단, 또는 Stop hook에서 계속 강제)

메모리 (Memory)

**CLAUDE.md 계층** (우선순위 높은 순):

Managed Policy (관리자 배포)
Project Memory (./CLAUDE.md)
Project Rules (.claude/rules/*.md 자동 로드)
User Memory (~/.claude/CLAUDE.md)
Local Project (./CLAUDE.local.md)
Auto Memory

좋은 CLAUDE.md 예시:

# 프로젝트명

## 기술 스택
- Python 3.12, FastAPI, Postgres 16

## 빌드/테스트
- 빌드: `make build`
- 테스트: `pytest tests/`

## 컨벤션
- snake_case 함수, PascalCase 클래스
- public API는 type hint 필수

## 금지사항
- main 브랜치 직접 push 금지
- print() 디버깅 금지

@.claude/rules/api-design.md

자동 메모리 시스템: ~/.claude/projects/<encoded-cwd>/memory/MEMORY.md (인덱스)

타입: user / feedback / project / reference
<remember>: 7일 단기 / <remember priority>: 영구 저장

아티팩트 (Artifact)

Claude.ai Web / Desktop 전용 기능. 우측 패널에 렌더링되는 독립 콘텐츠입니다.

생성 조건: 15줄 이상의 자립적 콘텐츠, 편집/재사용 가능성 높은 콘텐츠

유형: 코드, HTML/CSS/JS 웹페이지 (실제 렌더링), React 컴포넌트 (실행), Mermaid 다이어그램, SVG

Claude Code에서는 아티팩트 개념이 없으며 파일을 직접 편집합니다.

디스패치 (Dispatch)

서브에이전트로 작업을 위임하는 패턴입니다.

병렬: 단일 메시지에서 여러 Task 호출 → 독립 태스크에 적합
순차: 앞 Task 결과가 다음 Task 입력일 때 — 메시지를 분리해서 호출

루틴 (Routine)

2026년 4월 출시. Anthropic 클라우드 인프라에서 실행되는 스케줄 작업으로, 노트북을 닫아도 실행됩니다.

# 스케줄링 방식
1. Cloud Routines: /routine 커맨드
2. Desktop Scheduled Tasks: 로컬 머신
3. /loop 커맨드: 세션 내 반복

내장 도구: CronCreate (5필드 cron 표현식) / CronDelete / CronList

사용 사례: 매일 PR 리뷰, 주간 의존성 업데이트, 새벽 빌드 모니터링

settings.json 전체 구조

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git commit *)", "Read(**)"],
    "ask":   ["Bash(git push *)"],
    "deny":  ["Bash(rm -rf *)", "Write(/etc/**)"] 
  },
  "env": {
    "DEBUG": "true"
  },
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{ "type": "command", "command": "scripts/audit.sh" }]
    }]
  },
  "model": "claude-opus-4-7"
}

위치 (우선순위 순): .claude/settings.local.json > .claude/settings.json > ~/.claude/settings.json

Claude API 빠른 참조

# pip install anthropic
from anthropic import Anthropic

client = Anthropic()  # ANTHROPIC_API_KEY 자동 인식

# 기본 호출
message = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=1024,
    system="You are a helpful coding assistant.",
    messages=[{"role": "user", "content": "Explain async/await."}],
)
print(message.content[0].text)

# 스트리밍
with client.messages.stream(
    model="claude-opus-4-7", max_tokens=1024,
    messages=[{"role": "user", "content": "Write a haiku"}]
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

# Prompt Caching (최대 90% 비용 절감)
response = client.messages.create(
    model="claude-opus-4-7", max_tokens=1024,
    system=[{
        "type": "text",
        "text": "<긴 정적 지시사항...>",
        "cache_control": {"type": "ephemeral"}  # 5분 캐시
    }],
    messages=[{"role": "user", "content": "질문"}]
)

oh-my-claudecode (OMC)

Claude Code용 멀티에이전트 오케스트레이션 레이어입니다.

스킬 용도

/oh-my-claudecode:autopilot	계획 → 구현 → 검증 → 리뷰 자동 파이프라인
/oh-my-claudecode:ralph	Architect 승인까지 계획/수정/검증 반복
/oh-my-claudecode:ultrawork	다중 에이전트 동시 발사, 모델 티어 라우팅
/oh-my-claudecode:team	명시적 팀 오케스트레이션
/oh-my-claudecode:cancel	실행 모드 종료

IX. Playwright / tmux / 부수 도구

Playwright

Playwright는 Microsoft가 만든 오픈소스 E2E(End-to-End) 테스트 프레임워크입니다. Chromium·Firefox·WebKit 브라우저를 코드로 제어하며, AI 에이전트가 웹 브라우저를 자동화할 때도 폭넓게 활용됩니다.

주요 특징

크로스 브라우저: Chromium / Firefox / WebKit 단일 API
자동 대기(Auto-wait): 요소가 안정될 때까지 자동 대기 → 불안정한 sleep 불필요
네트워크 가로채기: 요청 모킹, 응답 스텁
스크린샷·PDF: 전체 페이지/특정 요소 캡처
MCP 서버: npx @playwright/mcp@latest — Claude Code에서 브라우저 조작 가능

기본 사용 예시

# pip install playwright && playwright install
from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()

    page.goto("<https://example.com>")
    page.fill("#search", "LLM")
    page.click("button[type=submit]")
    page.wait_for_selector(".results")

    title = page.title()
    screenshot = page.screenshot(path="result.png")
    print(f"페이지 제목: {title}")

    browser.close()

Claude Code에서 Playwright MCP 사용

# MCP 서버 추가
claude mcp add playwright npx @playwright/mcp@latest

# 이후 Claude가 브라우저를 직접 제어 가능
# mcp__playwright__browser_navigate, browser_click, browser_snapshot 등

pytest-playwright E2E 테스트 예시

# pip install pytest-playwright
# pytest --browser chromium
import pytest
from playwright.sync_api import Page, expect

def test_login(page: Page):
    page.goto("<https://myapp.com/login>")
    page.fill("[name=email]", "user@example.com")
    page.fill("[name=password]", "secret")
    page.click("button[type=submit]")
    expect(page).to_have_url("<https://myapp.com/dashboard>")
    expect(page.locator("h1")).to_contain_text("대시보드")

tmux

tmux는 터미널 다중화(multiplexer) 도구입니다. 하나의 터미널 세션에서 여러 창(window)과 패널(pane)을 관리하고, SSH 연결이 끊겨도 세션이 유지됩니다. AI 에이전트 실습에서 백그라운드 프로세스를 관찰하거나 병렬 작업을 모니터링할 때 핵심 도구입니다.

구조

Session: tmux 최상위 단위. 여러 Window 포함
Window: 브라우저의 탭처럼 독립된 터미널 화면
Pane: 하나의 Window 안에서 분할된 터미널

주요 명령어

목적 명령어

세션 생성	tmux new -s mySession
세션 목록	tmux ls
세션 재연결	tmux attach -t mySession
세션 분리	Ctrl+B → D
세션 종료	tmux kill-session -t mySession
창 새로 만들기	Ctrl+B → C
창 전환	Ctrl+B → 숫자키 (0, 1, 2…)
수직 분할 pane	Ctrl+B → %
수평 분할 pane	Ctrl+B → "
pane 간 이동	Ctrl+B → 화살표키
pane 닫기	exit 또는 Ctrl+D
화면 캡처	tmux capture-pane -pt mySession

AI 에이전트 실습에서의 활용

# 백엔드 서버 / 프론트엔드 / 에이전트 로그를 pane 3개로 분할 모니터링
tmux new -s dev
tmux split-window -h          # 우측 pane 추가
tmux split-window -v          # 우측에서 수평 추가

# Pane 0: 백엔드
tmux send-keys -t dev:0.0 'uvicorn main:app --reload' Enter

# Pane 1: 프론트엔드
tmux send-keys -t dev:0.1 'npm run dev' Enter

# Pane 2: 에이전트 로그
tmux send-keys -t dev:0.2 'tail -f agent.log' Enter

벡터 DB 비교

RAG 파이프라인에서 임베딩 벡터를 저장하고 검색하는 데이터베이스입니다.

DB 특징 호스팅 최적 사용 사례

ChromaDB	로컬/인메모리, 설정 최소화, Python 친화	로컬 / 자체 호스팅	프로토타이핑, 소규모 RAG
FAISS	Meta 오픈소스, 초고속 CPU/GPU 검색	로컬 (인메모리)	오프라인 대규모 배치 검색
Pinecone	완전 관리형, 실시간 업데이트, 메타데이터 필터	클라우드 SaaS	프로덕션 RAG, 엔터프라이즈
Weaviate	그래프 + 벡터 하이브리드, 멀티모달	클라우드 / 자체 호스팅	복잡한 지식 그래프 + 검색
pgvector	PostgreSQL 확장, SQL + 벡터 통합	자체 Postgres 서버	기존 Postgres 스택에 벡터 추가

AI 에이전트 패턴

에이전트가 문제를 해결하는 대표적인 실행 패턴입니다.

패턴 동작 방식 구현 도구

ReAct	Reasoning(추론) + Acting(행동) 반복: 생각 → 도구 실행 → 관찰	LangChain Agent, LangGraph
Reflection	출력 생성 후 자기 비평 → 개선 루프	LangGraph (순환 그래프)
Plan-and-Execute	먼저 전체 계획 수립, 이후 단계별 실행	LangGraph, CrewAI hierarchical
Multi-Agent	역할별 전문 에이전트가 협업·위임	CrewAI, LangGraph Multi-Agent

LLM 관찰성 (Observability) 도구

LLM 애플리케이션의 호출 추적, 평가, 디버깅을 위한 도구입니다.

도구 특징 LangChain 통합

LangSmith	LangChain 공식, 트레이스·평가·데이터셋 관리	환경변수만 설정하면 자동 수집
W&B Weave	Weights & Biases, 실험 추적 + LLM 로깅 통합	weave.init() 후 자동 패치
Arize Phoenix	오픈소스, 로컬 실행, RAG 평가 특화	OpenInference 계측

LangSmith 빠른 설정

export LANGCHAIN_TRACING_V2=true
export LANGCHAIN_API_KEY=<your-key>
export LANGCHAIN_PROJECT=my-rag-project

# 이후 LangChain 코드 그대로 실행 → LangSmith에 자동 트레이스 수집

기타 유용한 라이브러리

라이브러리 역할 주요 특징

LlamaIndex	데이터-LLM 연결 RAG 프레임워크	대규모 데이터 인덱싱, 쿼리 엔진
Pydantic AI	구조화된 LLM 출력 + 에이전트	타입 안전 결과, 유효성 검사
Instructor	LLM 응답을 Pydantic 모델로 파싱	response_model 파라미터 하나로 구조화
Semantic Kernel	Microsoft의 LLM 오케스트레이션 SDK	C# / Python / Java, Azure AI 통합

[Spark] 카탈리스크 옵티마이저

불곰1 — Mon, 27 Apr 2026 02:09:16 +0900

1. 개요

Apache Spark의 쿼리 실행 성능을 결정하는 핵심 엔진이 바로 카탈리스트 옵티마이저(Catalyst Optimizer)입니다. Spark SQL은 사용자가 작성한 SQL 쿼리나 DataFrame/Dataset API 코드를 내부적으로 최적의 실행 계획으로 변환하는데, 이 과정 전체를 카탈리스트 옵티마이저가 담당합니다.

카탈리스트 옵티마이저는 Spark 1.3(2014년)에 처음 도입되었으며, Scala의 함수형 프로그래밍 특성을 적극 활용하여 확장 가능한 구조로 설계되었습니다. 규칙 기반(Rule-Based) 최적화와 비용 기반(Cost-Based) 최적화를 모두 지원하며, Parquet·Hive·JDBC 등 다양한 데이터 소스와의 통합도 지원합니다.

사용자는 "무엇을(What)" 쿼리할지만 기술하면 되고, "어떻게(How)" 실행할지는 카탈리스트가 자동으로 결정합니다.

Catalyst Optimizer 4단계 파이프라인 개요 (출처: Databricks)

2. 카탈리스트 옵티마이저 동작 원리

2.1 핵심 개념: 트리 변환 (Tree Transformation)

카탈리스트 내부는 모든 쿼리 표현을 트리(Tree) 구조로 표현합니다. 모든 노드는 불변(Immutable) 객체이며, 최적화는 이 트리에 변환 규칙을 반복 적용하는 방식으로 이루어집니다.

기본 노드 유형:

Literal(value) — 상수값
Attribute(name) — 입력 행의 속성(컬럼)
Add(left, right) — 두 표현식의 합

변환 규칙 예시:

tree.transform {
  case Add(Literal(c1), Literal(c2)) => Literal(c1 + c2)
  case Add(left, Literal(0)) => left
}

트리 변환 전/후 시각화 (x + 1 + 2 예시):

변환 전:                    변환 후:
      Add                       Add
     /   \          →          /   \
   Add   Lit(2)            x(Attr)  Lit(3)
  /   \
x(Attr) Lit(1)
→ Add(Lit(1), Lit(2)) = Lit(3) 으로 상수 폴딩

Catalyst 트리 변환 다이어그램 (출처: Databricks)

규칙들은 배치(Batch)로 묶여 트리에 변화가 없을 때까지 반복(고정점, Fixed-Point) 실행됩니다. Spark 2.4.7 기준 25개 배치, 109개 규칙(고유 69개)이 존재합니다.

2.2 4단계 파이프라인

SQL / DataFrame API
        ↓
┌──────────────────────────────────────────────────┐
│  1. Analysis                                     │
│     Unresolved Logical Plan → Analyzed LP        │
│     (컬럼명·타입 해석, Catalog 조회)              │
└───────────────────┬──────────────────────────────┘
                    ↓
┌──────────────────────────────────────────────────┐
│  2. Logical Optimization                         │
│     Analyzed LP → Optimized LP                   │
│     (Predicate Pushdown, Constant Folding 등)    │
└───────────────────┬──────────────────────────────┘
                    ↓
┌──────────────────────────────────────────────────┐
│  3. Physical Planning                            │
│     Optimized LP → SparkPlan                     │
│     (BroadcastHashJoin vs SortMergeJoin 선택)    │
└───────────────────┬──────────────────────────────┘
                    ↓
┌──────────────────────────────────────────────────┐
│  4. Code Generation                              │
│     SparkPlan → Java Bytecode                    │
│     (Whole-Stage CodeGen, Janino 컴파일)         │
└───────────────────┬──────────────────────────────┘
                    ↓
              RDD 실행

Analysis (분석 단계)

SQL 파서 또는 DataFrame API로 생성된 Unresolved Logical Plan을 Analyzed Logical Plan으로 변환합니다.

df = spark.sql("SELECT name, age FROM employees WHERE dept = 'Engineering'")

# Unresolved Logical Plan (분석 전) — 모든 참조가 미해결 상태
# Project [unresolvedAttr(name), unresolvedAttr(age)]
# └── Filter unresolvedAttr(dept) = 'Engineering'
#     └── UnresolvedRelation employees

# Analyzed Logical Plan (분석 후) — Catalog에서 해석 완료
# Project [name#10, age#11]
# └── Filter (dept#12 = 'Engineering')
#     └── Relation employees [name#10, age#11, dept#12, salary#13]
#                                        ^^^^ 고유 ID 부여됨

Logical Optimization (논리 최적화 단계)

분석이 완료된 논리 계획에 규칙 기반 최적화를 적용하여 Optimized Logical Plan을 생성합니다.

규칙	설명
Constant Folding	`1+2` → `3`, 컴파일 시점에 상수 계산
Predicate Pushdown	필터를 데이터 소스 방향으로 이동
Projection Pruning	필요 없는 컬럼 제거
Combine Filters	인접한 필터 조건 병합
Null Propagation	Null 값 처리 최적화
Boolean Simplification	불린 연산 단순화
OptimizeIn	단일 원소 IN 리스트를 등호 비교로 변환

df = spark.read.parquet("/data/employees") \
    .filter("age > 20").filter("age > 30") \
    .select("name", "age", "salary")

df.explain(True)

# ── Optimized Logical Plan ──
# Project [name#10, age#11]          ← salary 제거 (Projection Pruning)
# └── Filter (age#11 > 30)           ← 두 Filter 병합 + 약한 조건 제거
#     └── Relation employees

Physical Planning (물리 계획 단계)

최적화된 논리 계획을 Spark 실행 엔진이 수행할 SparkPlan으로 변환합니다. SparkPlanner가 10가지 전략으로 물리 연산자를 매핑하고, CBO로 최적 계획을 선택합니다.

orders = spark.read.parquet("/data/orders")
customers = spark.read.parquet("/data/customers")  # 소규모 (10MB 이하)

orders.join(customers, "customer_id").filter("order_date > '2024-01-01'").explain()

# ── Physical Plan ──
# *(2) BroadcastHashJoin [customer_id#2], [customer_id#21]
#    :- *(2) Filter (order_date#4 > 2024-01-01)
#    :  +- *(2) FileScan parquet orders
#    +- BroadcastExchange HashedRelationBroadcastMode  ← 소규모 테이블 브로드캐스트
#       +- *(1) FileScan parquet customers

Code Generation (코드 생성 단계)

Whole-Stage Code Generation: 여러 물리 연산자를 단일 Java 함수로 묶어 컴파일합니다. *(1) 프리픽스가 단일 코드젠 스테이지를 의미합니다. Janino 컴파일러가 런타임에 바이트코드를 생성합니다.

df = spark.range(1_000_000).selectExpr("id * 2 + 1 as value").filter("value > 100")
df.explain()

# *(1) Filter (((id#0L * 2) + 1) > 100)   ← 두 연산자가
# +- *(1) Range (0, 1000000, step=1)      ← 단일 Java 함수로 컴파일됨
#
# for (long id = 0; id < 1000000; id++) {
#   long value = id * 2 + 1;
#   if (value > 100) emit(value);  ← 인라인 처리, 함수 호출 오버헤드 없음
# }

Code Generation 성능 비교 (출처: Databricks):

Code Generation 성능 비교 — Volcano 모델 vs Whole-Stage CodeGen

3. I/O 최적화 전략

I/O 최적화는 카탈리스트가 제공하는 가장 강력한 성능 개선 수단입니다. 3개 계층이 함께 동작하면 쿼리가 실제로 읽는 데이터를 전체의 1% 미만으로 줄일 수 있습니다.

3계층 I/O 최적화:

┌─────────────────────────────────────────────────────────┐
│  Layer 1: Partition Pruning                             │
│  디렉토리 레벨 — 관련 없는 파티션 폴더 자체를 스킵     │
│  예) dt=2025-01-15/ 만 접근, 나머지 364개 폴더 무시    │
├─────────────────────────────────────────────────────────┤
│  Layer 2: Data Skipping (File-level)                    │
│  파일 레벨 — min/max 통계로 전체 파일 스킵             │
│  예) file.parquet min=100, max=200 → value=50 조건 스킵 │
├─────────────────────────────────────────────────────────┤
│  Layer 3: Predicate Pushdown + Column Pruning           │
│  행·컬럼 레벨 — 조건 행만 읽고, 필요 컬럼만 읽음      │
│  예) PushedFilters, ReadSchema 컬럼 제한               │
└─────────────────────────────────────────────────────────┘

3.1 Predicate Pushdown (술어 푸시다운)

필터 조건을 데이터 소스 레벨로 이동시켜 조건을 만족하지 않는 행은 처음부터 읽지 않습니다.

푸시다운 없음:                         푸시다운 적용:

┌───────────────┐                    ┌───────────────┐
│  Spark Filter │ ← 1억 건 처리      │  Spark        │ ← 10만 건만 처리
└───────┬───────┘                    └───────┬───────┘
        │ 1억 건 전송                         │ 10만 건만 전송
┌───────┴───────┐                    ┌───────┴───────┐
│  Parquet      │ → 전체 스캔        │  Parquet      │ → 조건 행만 반환
└───────────────┘                    └───────────────┘

df = spark.read.parquet("/data/sales") \
    .filter("region = 'KR' AND amount > 10000") \
    .select("product_id", "amount")

df.explain()

# *(1) FileScan parquet [product_id#5, amount#7, region#9]
#      PushedFilters: [IsNotNull(region), EqualTo(region,KR),
#                      IsNotNull(amount), GreaterThan(amount,10000)]
#      ReadSchema: struct<product_id:string, amount:long>

지원 포맷: Parquet, ORC, JDBC, Delta Lake 등 FileScan 기반 소스

푸시다운이 작동하지 않는 경우:

UDF 사용 시 — 옵티마이저가 내부 로직을 분석할 수 없음
복잡한 Window 함수 — 일부 제한 존재

# ❌ UDF → PushedFilters: []  (전체 로드 후 처리)
df.filter(my_udf(df.age)).explain()

# ✅ 내장 함수 → PushedFilters: [GreaterThan(age,60)]
df.filter(df.age > 60).explain()

3.2 Column Pruning (컬럼 제거)

쿼리 결과에 필요한 컬럼만 읽고 나머지는 I/O 단계에서 완전히 제외합니다.

# 원본 테이블: employees(id, name, age, salary, dept, phone, address, join_date)
df = spark.read.parquet("/data/employees").select("id", "name")
df.explain()

# *(1) FileScan parquet [id#1, name#2]
#      ReadSchema: struct<id:int, name:string>
#      → 나머지 6개 컬럼은 디스크에서 아예 읽지 않음 (I/O 75% 절감)

Parquet·ORC 같은 컬럼 단위 저장 포맷과 결합 시 I/O 절감 효과가 극대화됩니다.

3.3 Partition Pruning (파티션 프루닝)

파티션 디렉토리 자체를 접근하지 않는 기법입니다. Predicate Pushdown이 파일 내부의 행을 필터링한다면, 파티션 프루닝은 디렉토리 자체를 건너뜁니다.

Static Partition Pruning — 쿼리 컴파일 시점에 파티션 결정:

# 파티션 구조: /data/sales/dt=2025-01-01/ ~ dt=2025-12-31/ (365개)
df = spark.read.parquet("/data/sales")
df.filter("dt = '2025-01-15'").explain()

# *(1) FileScan parquet [amount#1, dt#2]
#      PartitionFilters: [isnotnull(dt#2), (dt#2 = 2025-01-15)]  ← 프루닝 적용
#      → dt=2025-01-15/ 하나만 접근 (364개 파티션 스킵)

Dynamic Partition Pruning (DPP, Spark 3.0+) — 조인 시 런타임에 파티션 결정:

spark.conf.set("spark.sql.optimizer.dynamicPartitionPruning.enabled", "true")

fact = spark.read.parquet("/data/sales")       # 파티션: dt
dim  = spark.read.parquet("/data/promotions")  # 소규모 차원 테이블

result = fact.join(dim, "campaign_id").filter("dim.region = 'KR'")
result.explain()

# FileScan parquet sales
#   PartitionFilters: [dynamicpruningexpression(dt#2 IN subquery#1)]  ← DPP
#   → dim의 KR 캠페인 날짜에 해당하는 파티션만 런타임에 스캔

3.4 Data Skipping (데이터 스키핑)

Parquet 파일은 각 Row Group(기본 128MB)마다 컬럼별 min/max 통계를 저장합니다. Spark은 이 통계를 읽어 조건을 만족할 수 없는 Row Group 전체를 스킵합니다.

Parquet 파일 내부:

┌──────────────────────────────────────┐
│  Row Group 1  │ age: min=18, max=35  │ ← age > 80 → 스킵 (max=35 < 80)
│  Row Group 2  │ age: min=36, max=60  │ ← age > 80 → 스킵 (max=60 < 80)
│  Row Group 3  │ age: min=61, max=85  │ ← age > 80 → 읽음 (max=85 >= 80)
└──────────────────────────────────────┘
→ 3개 중 1개만 스캔 (67% I/O 절감)

df = spark.read.parquet("/data/employees")
df.filter("age > 80").explain()

# *(1) FileScan parquet [age#1, name#2]
#      PushedFilters: [IsNotNull(age), GreaterThan(age,80)]
#      RowGroups: 3 out of 10 read   ← 10개 Row Group 중 3개만 읽음
# 설정: spark.sql.parquet.filterPushdown = true (기본값)

Delta Lake Data Skipping + Z-Order:

# Delta Lake: 트랜잭션 로그(_delta_log/)에 파일별 min/max 통계 자동 저장 (기본 32컬럼)

# Z-Order로 같은 값의 데이터를 같은 파일에 클러스터링 → min/max 범위 최소화
spark.sql("""
    OPTIMIZE delta.`/data/events`
    ZORDER BY (user_id, event_date)
""")
# → user_id 기반 조회 시 대부분의 파일 min/max 범위 밖 → 스킵 가능

4. 조인 & 실행 최적화

4.1 Broadcast Join (브로드캐스트 조인)

한쪽 테이블이 충분히 작을 경우, 셔플 없이 작은 테이블을 모든 노드에 복사(broadcast)하여 조인합니다.

from pyspark.sql.functions import broadcast

orders = spark.read.parquet("/data/orders")        # 10억 건
country_codes = spark.read.parquet("/data/codes")  # 200건 (소규모)

# 자동 감지 (10MB 이하 → 자동 브로드캐스트)
spark.conf.set("spark.sql.autoBroadcastJoinThreshold", "10m")

# 명시적 강제 적용
orders.join(broadcast(country_codes), "country_code").explain()

# BroadcastHashJoin vs SortMergeJoin
# ┌──────────────────────┬──────────────────────┐
# │  BroadcastHashJoin   │   SortMergeJoin      │
# ├──────────────────────┼──────────────────────┤
# │ 네트워크 셔플 없음   │ 전체 데이터 셔플     │
# │ 소규모 테이블 필요   │ 테이블 크기 무관     │
# │ 훨씬 빠름            │ 대규모 조인에 안정적 │
# └──────────────────────┴──────────────────────┘

4.2 Join Reordering & CBO (조인 재정렬 & 비용 기반 최적화)

CBO는 데이터 통계(행 수, 컬럼 분포, NDV 등)를 바탕으로 여러 실행 계획 중 비용이 가장 낮은 계획을 선택합니다. 조인 재정렬에 주로 활용됩니다.

spark.conf.set("spark.sql.cbo.enabled", "true")

# 통계 수집
spark.sql("ANALYZE TABLE orders COMPUTE STATISTICS FOR ALL COLUMNS")
spark.sql("ANALYZE TABLE products COMPUTE STATISTICS FOR ALL COLUMNS")

# 수집된 통계 확인
spark.sql("DESCRIBE EXTENDED my_table").show(truncate=False)
# Statistics: 1234567890 bytes, 10000000 rows
# col_stats: age → min:18, max:80, ndv:62 | region → ndv:8

# CBO 비활성화: 작성 순서 그대로
orders.join(customers, "cid").join(products, "pid").explain()
# SortMergeJoin orders × customers → 결과 × products (비효율)

# CBO 활성화: 통계 기반 최적 순서
orders.join(customers, "cid").join(products, "pid").explain()
# BroadcastHashJoin products(소규모 먼저) → 결과 × orders  ← 재정렬

4.3 Adaptive Query Execution (AQE, Spark 3.0+)

런타임에 수집한 실측 통계를 기반으로 실행 중 계획을 동적으로 재최적화합니다.

기능	설명
파티션 동적 조정	초기 200 파티션 → 실제 데이터 기반 15개로 병합
조인 전략 변경	Sort-Merge → Broadcast (런타임 크기 확인 후)
스큐 조인 처리	특정 키에 데이터가 몰려도 자동 파티션 분할

spark.conf.set("spark.sql.adaptive.enabled", "true")          # Spark 3.2+에서 기본 true
spark.conf.set("spark.sql.adaptive.coalescePartitions.enabled", "true")
spark.conf.set("spark.sql.adaptive.skewJoin.enabled", "true")

df = spark.read.parquet("/data/events").groupBy("event_type").agg({"user_id": "count"})
df.explain()

# AdaptiveSparkPlan isFinalPlan=false    ← AQE 활성화 표시
# +- HashAggregate
#    +- Exchange hashpartitioning(event_type, 200)  ← 초기 200 파티션
#
# 실행 후: 실제 데이터 있는 15개로 자동 병합 (빈 태스크 185개 제거)

5. 실무 주의사항: 파티션 키와 함수

5.1 파티션 키에 함수를 감싸면 안 되는 이유 (오픈소스 Spark)

파티션 키 컬럼을 함수로 감싸면 파티션 프루닝이 완전히 무력화됩니다.

옵티마이저가 파티션 프루닝을 적용하려면 컴파일 시점에 어느 파티션 디렉토리를 읽을지 결정해야 합니다. to_date(dt) = '2025-01-01'이라고 쓰면, 옵티마이저 입장에서는 dt의 모든 값을 실제로 읽어서 함수를 적용해 봐야 결과가 맞는지 알 수 있습니다. 따라서 프루닝을 포기하고 전체 파티션을 스캔합니다.

파티션 디렉토리: /data/logs/dt=2025-01-01/ ~ dt=2025-12-31/ (365개)

[BAD] to_date(dt) = '2025-01-01'
  → 옵티마이저: 어느 dt= 폴더를 써야 하는지 알 수 없음
  → 전체 365개 파티션 스캔 후 함수 적용

[GOOD] dt = '2025-01-01'
  → 옵티마이저: dt=2025-01-01 폴더만 직접 접근
  → 1개 파티션만 스캔

❌ 프루닝 무력화 패턴 vs ✅ 올바른 패턴:

-- ❌ 함수 적용 → PartitionFilters: [] (전체 스캔)
WHERE to_date(dt) = '2025-01-01'
WHERE datetime(dt) >= '2025-01-01 00:00:00'
WHERE date_format(dt, 'yyyy-MM') = '2025-01'
WHERE YEAR(dt) = 2025 AND MONTH(dt) = 1

-- ✅ 직접 비교 → PartitionFilters 적용 (스킵)
WHERE dt = '2025-01-01'
WHERE dt >= '2025-01-01' AND dt < '2025-01-02'
WHERE dt BETWEEN '2025-01-01' AND '2025-01-31'

EXPLAIN으로 차이 확인:

df = spark.read.parquet("/data/logs")  # dt 컬럼으로 파티션됨

# ❌ 잘못된 패턴
from pyspark.sql.functions import to_date
df.filter(to_date(df.dt) == '2025-01-01').explain()
# FileScan parquet
#   PartitionFilters: []   ← 비어 있음! 전체 파티션 스캔

# ✅ 올바른 패턴
df.filter("dt = '2025-01-01'").explain()
# FileScan parquet
#   PartitionFilters: [isnotnull(dt#1), (dt#1 = 2025-01-01)]  ← 프루닝 적용

Z-Order 클러스터링에서도 동일하게 적용됩니다:

-- ❌ 함수 적용 → min/max 통계 비교 불가 → 데이터 스키핑 안 됨
WHERE CAST(user_id AS STRING) = '12345'

-- ✅ 직접 비교 → min/max 통계 활용 → 대부분 파일 스킵
WHERE user_id = 12345

5.2 Databricks Delta Lake의 자동 해법: Generated Columns

위의 문제를 Databricks Delta Lake는 Generated Columns(생성 컬럼)으로 자동 해결합니다.

Generated Column은 다른 컬럼의 함수로 자동 계산되는 특수 컬럼입니다. 파티션 컬럼을 Generated Column으로 정의하면, Delta Lake가 기본 컬럼으로 필터링해도 파티션 필터를 자동 생성합니다.

동작 원리:

[테이블 스키마]
  event_time  TIMESTAMP          ← 실제 데이터 컬럼
  event_date  DATE (Generated)   ← CAST(event_time AS DATE) 로 자동 계산

[쿼리]
  WHERE event_time >= '2025-01-01'

[Delta Lake 내부 처리]
  event_time과 event_date의 관계를 알고 있음
  → event_date = '2025-01-01' 파티션 필터 자동 추가
  → 해당 파티션만 스캔

생성 컬럼으로 테이블 정의:

CREATE TABLE events (
  event_id   BIGINT,
  event_time TIMESTAMP,
  user_id    BIGINT,
  -- Generated Column: event_time으로부터 자동 계산, 직접 삽입 불필요
  event_date DATE GENERATED ALWAYS AS (CAST(event_time AS DATE))
)
USING DELTA
PARTITIONED BY (event_date);

-- 쓰기 시: event_date를 직접 지정할 필요 없음 (Delta가 자동 계산)
INSERT INTO events (event_id, event_time, user_id)
VALUES (1, '2025-01-15 14:30:00', 12345);
-- → event_date = '2025-01-15' 자동 저장

기본 컬럼으로 필터링해도 파티션 프루닝 자동 적용:

-- event_date 조건 없이 event_time으로만 필터링
SELECT * FROM events
WHERE event_time >= '2025-01-01'
  AND event_time <  '2025-01-02';

-- Delta Lake 내부 처리:
-- event_time >= '2025-01-01' → event_date = '2025-01-01' 자동 추가
-- → EXPLAIN 출력: PartitionFilters: [(event_date = 2025-01-01)]
-- → event_date=2025-01-01/ 파티션 하나만 스캔

지원 표현식 목록:

표현식	컬럼 타입	설명
`CAST(col AS DATE)`	TIMESTAMP	타임스탬프 → 날짜 변환
`YEAR(col)`	TIMESTAMP	연도 추출
`YEAR(col)` • `MONTH(col)`	TIMESTAMP	연·월 파티션
`YEAR(col)` • `MONTH(col)` • `DAY(col)`	TIMESTAMP	연·월·일 파티션
`YEAR(col)` • `MONTH(col)` • `DAY(col)` • `HOUR(col)`	TIMESTAMP	시간 단위 파티션
`DATE_FORMAT(col, 'yyyy-MM')`	TIMESTAMP	월별 파티션
`SUBSTRING(col, pos, len)`	STRING	문자열 부분 파티션

Photon 요구사항:

Databricks Runtime 10.4 LTS 이하 → Photon 필수
Databricks Runtime 11.3 LTS 이상 → Photon 불필요 (자동 적용)

오픈소스 Spark vs Databricks 비교:

항목	오픈소스 Spark	Databricks Delta Lake
`to_date(dt) = '2025-01-01'`	PartitionFilters: [] (전체 스캔)	Generated Column 설정 시 자동 프루닝
`YEAR(dt) = 2025`	프루닝 불가	Generated Column 설정 시 자동 프루닝
`dt = '2025-01-01'`	정상 프루닝	정상 프루닝
설정 필요 여부	없음 (직접 비교만 동작)	테이블 생성 시 Generated Column 정의 필요

5.3 다중 파티션 키 (ym + dt) 와 프루닝 범위

실무에서는 파티션을 ym(연월) + dt(날짜) 두 계층으로 구성하는 경우가 많습니다. 이 때 WHERE dt = '2025-01-15' 조건만 사용하면 상위 파티션 ym까지 프루닝되는지는 오픈소스 Spark와 Databricks 간에 동작이 다릅니다.

파일시스템 계층 구조 (ym + dt 2단계 파티션):

/data/logs/
  ym=2025-01/
    dt=2025-01-01/  ← part-00000.parquet
    dt=2025-01-15/  ← part-00000.parquet  (찾고자 하는 파티션)
    dt=2025-01-31/
  ym=2025-02/
    dt=2025-02-01/
    ...
  ym=2025-12/
    ...

오픈소스 Spark — dt 조건만으로는 ym 프루닝 안 됨:

오픈소스 Spark는 ym과 dt 사이의 논리적 관계를 모릅니다. dt = '2025-01-15'라고 써도 옵티마이저는 해당 dt가 어느 ym= 폴더 아래 있는지 추론할 수 없습니다. 결국 모든 ym=*/ 디렉토리를 열어 안에 있는 dt= 서브파티션을 하나씩 확인합니다.

df = spark.read.parquet("/data/logs")  # PARTITIONED BY (ym, dt)

# ❌ dt만 명시 → ym 전체 스캔
df.filter("dt = '2025-01-15'").explain()
# FileScan parquet
#   PartitionFilters: [isnotnull(dt#2), (dt#2 = 2025-01-15)]
#   ← dt 만 프루닝. ym은 비어있어 12개 ym 폴더 모두 진입
#   → 실제로는 ym=2025-01/dt=2025-01-15/ 1개만 필요하지만
#      ym=2025-02/ ~ ym=2025-12/ 도 모두 열어서 dt 확인 후 버림

# ✅ ym 까지 명시 → 두 레벨 모두 프루닝
df.filter("ym = '2025-01' AND dt = '2025-01-15'").explain()
# PartitionFilters: [(ym#1 = 2025-01), (dt#2 = 2025-01-15)]  ← 두 레벨 동시 적용

Databricks Delta Lake — Generated Column으로 ym 자동 프루닝:

ym을 dt의 Generated Column으로 정의하면 Delta Lake가 두 컬럼의 관계를 인식하여, dt 조건만 있어도 상위 파티션 ym을 자동으로 프루닝합니다.

CREATE TABLE logs (
  log_id   BIGINT,
  dt       DATE,
  -- ym 은 dt 로부터 자동 계산되는 Generated Column
  ym       STRING GENERATED ALWAYS AS (DATE_FORMAT(dt, 'yyyy-MM')),
  message  STRING
)
USING DELTA
PARTITIONED BY (ym, dt);

-- dt 조건만 사용 → Delta Lake 가 ym 파티션 필터 자동 추가
SELECT * FROM logs WHERE dt = '2025-01-15';
-- Delta Lake 내부:
--   dt = '2025-01-15'  →  ym = '2025-01' 자동 추론
--   PartitionFilters: [(ym = '2025-01'), (dt = '2025-01-15')]
--   → ym=2025-01/dt=2025-01-15/ 1개 파티션만 스캔

오픈소스 Spark vs Databricks — 다중 파티션 키 프루닝 비교:

필터 조건	오픈소스 Spark	Databricks Delta Lake
`WHERE dt = '2025-01-15'`	dt만 프루닝, ym 전체 스캔	Generated Column 정의 시 ym도 자동 프루닝
`WHERE ym='2025-01' AND dt='2025-01-15'`	두 레벨 모두 프루닝	두 레벨 모두 프루닝
상위 파티션 자동 추론	불가 (독립적으로 처리)	dt → ym 관계 인식 (Generated Column)
설정 필요 여부	없음 (명시 조건만 동작)	테이블 생성 시 Generated Column 정의 필요

핵심: 오픈소스 Spark에서 계층형 다중 파티션을 사용할 때, 상위 파티션(ym)을 프루닝하려면 WHERE 절에 반드시 명시해야 합니다. Databricks Delta Lake는 Generated Column 정의만으로 이 제약을 자동으로 해결합니다.

6. 요약

카탈리스트 옵티마이저는 Apache Spark의 쿼리 최적화 핵심 엔진으로, 사용자의 쿼리를 최적의 실행 계획으로 변환합니다.

4단계 파이프라인:

단계	역할	방식
Analysis	이름·타입 해석	규칙 기반
Logical Optimization	논리 계획 단순화	규칙 기반 (25배치, 69규칙)
Physical Planning	물리 연산자 매핑	규칙 + 비용 기반
Code Generation	Java 바이트코드 컴파일	Whole-Stage CodeGen

핵심 최적화 기법:

기법	계층	설명
Predicate Pushdown	행 레벨	조건 행만 읽음
Column Pruning	컬럼 레벨	필요 컬럼만 읽음
Partition Pruning	디렉토리 레벨	관련 파티션 폴더만 접근
Data Skipping	Row Group 레벨	min/max 통계로 블록 스킵
Broadcast Join	조인 전략	소규모 테이블 셔플 없이 복사
CBO	계획 선택	통계 기반 최소 비용 계획 선택
AQE	런타임 재최적화	실측 기반 동적 조정 (Spark 3.0+)

실무 핵심 주의사항:

파티션/클러스터링 키를 to_date(), datetime(), YEAR() 등 함수로 감싸면 Partition Pruning과 Data Skipping이 완전히 무력화됩니다. 직접 리터럴 비교를 사용해야 합니다.

단, Databricks Delta Lake는 테이블 생성 시 Generated Columns를 정의하면, 기본 컬럼에 함수를 적용한 필터에서도 파티션 프루닝을 자동으로 처리합니다 (DBR 11.3 LTS 이상, Photon 불필요).

7. 레퍼런스

[Spark] 파티션 전략과 성능 최적화

불곰1 — Mon, 27 Apr 2026 01:29:17 +0900

파티션 전략 개요

Apache Spark에서 파티션(Partition)은 데이터를 분산 처리하는 기본 단위입니다. 파티션의 수와 크기, 분배 방식에 따라 성능이 크게 달라지므로 파티션 전략을 이해하고 올바르게 적용하는 것이 매우 중요합니다.

1. 파티션이란?

Spark는 데이터를 여러 파티션으로 나누어 각 Executor의 Task가 하나의 파티션을 담당하는 방식으로 동작합니다.

파티션 수가 너무 적으면 병렬성이 낮아져 일부 Executor가 유휴 상태가 됩니다.
파티션 수가 너무 많으면 Task 스케줄링 오버헤드가 증가하여 오히려 성능이 저하됩니다.
따라서 데이터 크기와 클러스터 자원에 맞는 적정 파티션 수를 유지하는 것이 핵심입니다.

2. repartition(100)은 어떻게 데이터를 나누는가?

repartition(100)과 같이 숫자를 지정하면 데이터를 100개 파티션으로 나눈다는 뜻입니다. 그런데 실제로 어떤 기준으로 각 Row를 파티션에 배정하는지가 핵심입니다. Spark는 크게 두 가지 방식을 사용합니다.

2-1. Round-Robin 방식 — `repartition(n)` 컬럼 미지정

컬럼을 지정하지 않으면 RoundRobinPartitioning이 적용됩니다. Row를 순서대로 돌아가며 각 파티션에 하나씩 배분하는 방식입니다.

Row1 → P0,  Row2 → P1,  Row3 → P2
Row4 → P0,  Row5 → P1,  Row6 → P2  ...

행 수(Row Count) 기준으로 균등 분배됩니다.
바이트 크기는 보장하지 않습니다. Row 하나가 1KB인 파티션과 1MB인 파티션이 생길 수 있습니다.
전체 셔플(Full Shuffle)이 발생합니다.

df.repartition(100)
# 100개 파티션, 각 파티션에 (전체 행 수 / 100)개의 Row가 배분됨

2-2. Hash 방식 — `repartition(n, col)` 컬럼 지정

컬럼을 지정하면 HashPartitioning이 적용됩니다. 해당 컬럼 값의 해시를 파티션 수로 나눈 나머지(modulo)가 파티션 번호가 됩니다.

파티션 번호 = MurMur3_hash(컬럼 값) % 파티션 수

같은 키 값은 반드시 같은 파티션에 들어갑니다. 조인·집계 시 셔플 없이 처리하기 위해 사용합니다.
특정 키에 데이터가 몰리면 파티션 크기가 불균형해집니다(→ 스큐 문제 발생).

df.repartition(100, "user_id")
# user_id의 hash % 100 → 파티션 번호 결정
# 같은 user_id를 가진 Row는 항상 같은 파티션에 모임

2-3. 방식 비교 요약

구분	repartition(n)	repartition(n, col)	coalesce(n)
내부 방식	Round-Robin	Hash (MurMur3)	파티션 병합
분배 기준	행 수 균등	키 해시값	인접 파티션 병합
셔플 여부	전체 셔플	전체 셔플	셔플 없음
키 동일성 보장	X	O (같은 키 → 같은 파티션)	X
스큐 가능성	낮음	높음 (키 쏠림 시)	낮음

3. repartition vs coalesce

repartition

지정한 수만큼 파티션을 새롭게 재분배합니다.
전체 셔플(Full Shuffle)이 발생하므로 비용이 높습니다.
파티션 수를 늘리거나 데이터를 균등하게 재분배해야 할 때 사용합니다.

df.repartition(200)
df.repartition(200, "join_key")  # 특정 컬럼 기준 해시 분배

coalesce

파티션 수를 줄이는 데 사용합니다.
셔플 없이 인접 파티션을 병합하므로 비용이 낮습니다.
단, 데이터 편향(Skew)이 발생할 수 있으므로 주의가 필요합니다.

df.coalesce(50)  # 파티션 수 축소, 셔플 없음

상황	권장 방법
파티션 수를 늘려야 할 때	repartition(n)
필터링 이후 파티션을 줄일 때	coalesce(n)
특정 키 기준으로 균등 분배해야 할 때	repartition(n, "key_column")

4. 파티셔닝(Partitioning) vs 버케팅(Bucketing)

파티셔닝 (partitionBy)

컬럼 값 기준으로 디렉토리를 나눠 데이터를 저장합니다.
카디널리티가 낮은 컬럼(예: 날짜, 국가, 상태값)에 적합합니다.
파티션 프루닝(Partition Pruning)이 가능하여 불필요한 파일 읽기를 방지합니다.

df.write.partitionBy("year", "month").parquet("path/to/output")

버케팅 (bucketBy)

해시 함수로 데이터를 고정 크기 버킷으로 분산하여 저장합니다.
카디널리티가 높은 컬럼(예: user_id, order_id)에 적합합니다.
같은 컬럼과 버킷 수로 버케팅된 테이블 간 조인 시 셔플이 제거됩니다.

df.write.bucketBy(64, "user_id").sortBy("user_id").saveAsTable("bucketed_table")

5. 적정 파티션 수와 크기

권장 파티션 크기: 파티션 하나의 크기는 128MB ~ 256MB가 최적입니다.

# 파티션 수 산정 공식
# 방법 1: 데이터 크기 기준
파티션 수 = 총 데이터 크기 / 128MB ~ 256MB

# 방법 2: 클러스터 자원 기준
파티션 수 = Executor 수 × Executor당 코어 수 × 2~4

# 셔플 파티션 수 설정
spark.conf.set("spark.sql.shuffle.partitions", 200)

6. 데이터 스큐(Skew) 문제와 해결 방법

데이터 스큐는 특정 파티션에 데이터가 집중되어 해당 Task만 오래 걸리는 현상입니다.

스큐 진단: Spark UI > Stages 탭에서 Task 실행 시간 분포를 확인합니다. 최장 Task 시간이 중앙값 대비 5배 이상이면 스큐를 의심합니다.

6-1. 솔팅(Salting) 기법

스큐된 키에 임의의 숫자(Salt)를 붙여 여러 파티션에 분산시키는 방법입니다.

from pyspark.sql.functions import rand, col, lit, concat, explode, array

salt_factor = 10

# 큰 테이블에 salt 추가
df_large = df_large.withColumn("salt", (rand() * salt_factor).cast("int"))
df_large = df_large.withColumn("salted_key", concat(col("join_key"), lit("_"), col("salt")))

# 작은 테이블을 salt_factor배로 복제
salts = array([lit(i) for i in range(salt_factor)])
df_small = df_small.withColumn("salt", explode(salts))
df_small = df_small.withColumn("salted_key", concat(col("join_key"), lit("_"), col("salt")))

result = df_large.join(df_small, "salted_key")

6-2. AQE Skew Join 자동 처리 (권장)

spark.conf.set("spark.sql.adaptive.enabled", "true")
spark.conf.set("spark.sql.adaptive.skewJoin.enabled", "true")
spark.conf.set("spark.sql.adaptive.skewJoin.skewedPartitionFactor", "5")
spark.conf.set("spark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes", "268435456")

7. 동적 파티션 프루닝(Dynamic Partition Pruning, DPP)

DPP란?

동적 파티션 프루닝은 조인 전략이 아니라, 조인 성능을 높이기 위한 최적화 기법입니다. 작은 차원 테이블의 필터링 결과를 활용하여 큰 팩트 테이블에서 불필요한 파티션을 아예 읽지 않도록 합니다.

DPP 적용 조건

팩트 테이블이 조인 키 컬럼으로 파티셔닝되어 있어야 합니다.
차원 테이블 쪽에 선택적인 WHERE 조건이 있어야 합니다.
Equi-Join (=) 조건에서만 동작합니다.
Star Schema 구조에서 가장 효과적입니다.

spark.conf.set("spark.sql.optimizer.dynamicPartitionPruning.enabled", "true")  # 기본 활성화

구분	Predicate Pushdown	Dynamic Partition Pruning
적용 시점	컴파일 타임	런타임
조건 출처	고정 필터 (WHERE)	조인 상대 테이블의 필터 결과
테이블 조건	없음	조인 키로 파티셔닝 필요
적합 패턴	단순 필터 쿼리	Star Schema 조인

8. AQE와 파티션 자동 최적화

Spark 3.2부터 기본 활성화된 AQE는 런타임 통계를 기반으로 파티션을 자동으로 최적화합니다.

spark.conf.set("spark.sql.adaptive.enabled", "true")
spark.conf.set("spark.sql.adaptive.coalescePartitions.enabled", "true")
spark.conf.set("spark.sql.adaptive.advisoryPartitionSizeInBytes", "134217728")  # 128MB
spark.conf.set("spark.sql.adaptive.coalescePartitions.minPartitionSize", "1048576")  # 1MB

설정 키	기본값	설명
spark.sql.adaptive.enabled	true (3.2+)	AQE 마스터 스위치
spark.sql.adaptive.coalescePartitions.enabled	true	셔플 후 파티션 자동 병합
spark.sql.adaptive.advisoryPartitionSizeInBytes	64MB	목표 파티션 크기
spark.sql.adaptive.skewJoin.enabled	true	스큐 조인 자동 처리
spark.sql.adaptive.skewJoin.skewedPartitionFactor	5	스큐 판단 배수
spark.sql.adaptive.skewJoin.skewedPartitionThresholdInBytes	256MB	스큐 판단 최소 크기

9. 파티션 최적화 운영 체크리스트

설계 단계

파티셔닝 컬럼은 카디널리티가 낮은 컬럼(날짜, 상태값 등)으로 선택하였습니까?
조인/집계가 잦은 고카디널리티 컬럼은 버케팅을 고려하였습니까?
Star Schema 구조에서 팩트 테이블을 조인 키로 파티셔닝하여 DPP를 활성화하였습니까?

개발 단계

AQE가 활성화되어 있습니까? (spark.sql.adaptive.enabled = true)
셔플 파티션 초기값을 충분히 크게 설정하였습니까? (AQE가 런타임에 자동 축소)
대용량 필터링 이후 coalesce()로 파티션 수를 정리하였습니까?
스큐가 예상되는 조인에서 AQE skewJoin 설정을 확인하였습니까?

모니터링

Spark UI > Stages 탭에서 Task 실행 시간 분포를 확인하고 있습니까?
최장 Task 시간이 중앙값 대비 5배 이상이라면 스큐를 의심합니다.
파티션 크기가 128MB ~ 256MB 범위에 있는지 확인합니다.
실행 계획에서 dynamicpruningexpression으로 DPP 적용 여부를 확인합니다.

성능 튜닝 기준

파티션 크기를 128MB ~ 256MB로 유지하면 처리 시간이 20~50% 개선될 수 있습니다.
솔팅 기법 사용 시 salt_factor는 스큐 비율에 맞게 조정합니다 (10:1 스큐 → salt_factor=10).
동일 컬럼·버킷 수로 버케팅된 테이블 간 조인은 셔플을 제거하여 성능을 크게 향상시킵니다.

중앙 메타스토어란

불곰1 — Sun, 26 Apr 2026 23:58:50 +0900

1. 개요

중앙 메타스토어(Central Metastore 또는 Data Catalog)는 데이터 레이크·레이크하우스 환경에서 테이블 스키마, 파티션 정보, 위치(Location), 통계, 직렬화 방식(SerDe) 등 데이터의 메타데이터를 통합 관리하는 핵심 인프라 컴포넌트입니다.

Spark, Trino, Flink, Hive 등 다수의 처리 엔진이 동일한 데이터 자산에 접근할 때, 각 엔진이 개별적으로 스키마 정보를 관리하면 불일치와 중복이 발생합니다. 중앙 메타스토어는 이러한 문제를 해결하기 위해 단일 진실 공급원(Single Source of Truth) 역할을 수행합니다.

초기에는 Apache Hive Metastore(HMS)가 사실상 표준으로 자리 잡았으나, 데이터 레이크하우스 시대에 접어들면서 트랜잭션 지원, REST 표준 호환, 멀티 포맷 지원, 세밀한 거버넌스 등을 제공하는 현대적 카탈로그들이 등장하였습니다.

2. 중앙 메타스토어가 왜 필요한지

멀티 엔진 환경의 일관성 확보

Spark, Trino, Flink, Hive, Presto 등 다양한 엔진이 S3·GCS·ADLS 같은 공용 오브젝트 스토리지의 동일 데이터를 조회합니다. 중앙 메타스토어가 없으면 각 엔진마다 별도로 테이블 스키마와 파티션 정보를 관리해야 하며, 스키마 변경 시 모든 엔진에 개별 반영해야 하는 운영 부담이 발생합니다.

데이터 거버넌스 및 보안

테이블과 컬럼 단위의 접근 권한을 중앙에서 관리하지 않으면 엔진별로 정책이 달라질 위험이 있습니다. 중앙 메타스토어는 RBAC(Role-Based Access Control), 행·열 수준 보안, Tag 기반 정책을 한 곳에서 적용하는 거버넌스 기반을 제공합니다.

데이터 발견성(Discoverability) 향상

수천 개의 테이블이 오브젝트 스토리지에 흩어져 있을 때, 중앙 카탈로그 없이는 필요한 데이터를 찾는 것 자체가 어렵습니다. 중앙 메타스토어는 스키마·통계·태그·Lineage 정보를 통해 데이터 탐색과 이해를 지원합니다.

레이크하우스 포맷의 트랜잭션 관리

Apache Iceberg, Delta Lake, Apache Hudi, Apache Paimon 같은 레이크하우스 테이블 포맷은 메타데이터를 통해 ACID 트랜잭션과 Time Travel을 구현합니다. 중앙 메타스토어는 이 메타데이터의 버전 관리와 카탈로그 등록을 책임집니다.

운영 자동화

테이블 최적화(Compaction), 스냅샷 만료(Snapshot Expiration), 컬럼 통계 수집 등 운영 작업을 카탈로그 레벨에서 자동화할 수 있어, 팀의 운영 부담을 크게 줄입니다.

메타스토어 없이 접근할 때의 문제 — 데이터 늪(Data Swamp)

메타스토어 없이 오브젝트 스토리지 경로를 직접 지정해 데이터에 접근하는 것은 기술적으로 가능합니다. 그러나 규모가 커질수록 데이터 늪(Data Swamp) 으로 전락할 위험이 높아집니다.

# 메타스토어 없이 Parquet 파일 직접 읽기 (물리적 경로 의존)
df = spark.read.format("parquet").load("s3://sales/2020/01/1.parquet")
df.printSchema()
df.show()

# Delta Lake 테이블 직접 읽기 (경로 기반)
df = spark.read.format("delta").load("s3://sales/")
df.printSchema()
df.show()

위 방식의 핵심 한계:

물리적 경로 의존: 논리적 테이블명 없이 S3 경로를 직접 지정하므로, 스토리지 구조 변경 시 모든 파이프라인이 깨집니다.
스키마 변경 추적 불가: 각 팀·엔진이 독립적으로 메타데이터를 관리하면 스키마 불일치가 발생합니다.
ACID 보장 불가 / 동시성 손상: 동시 쓰기 시 데이터 손상 위험이 있으며, 트랜잭션 격리를 보장할 수 없습니다.
접근 권한·Lineage 관리 불가: 컬럼·행 수준 보안 정책을 일관되게 적용할 수 없습니다.
성능 최적화 불가: 파일 프루닝(File Pruning)·파티션 통계는 카탈로그에 등록된 메타데이터 없이는 활용되지 않습니다.

3. 중앙 메타스토어 제품 조사

Hive Metastore (HMS)

유형: 오픈소스 (Apache 2.0)

2010년경 Apache Hive 프로젝트의 일부로 시작된 가장 전통적인 메타스토어입니다. 데이터베이스, 테이블, 스키마, 파티션, SerDe 정보를 RDBMS(MySQL, PostgreSQL 등) 백엔드에 저장하며, Thrift 서비스를 통해 다중 엔진이 동일한 메타데이터에 접근합니다.

특징

가장 성숙하고 광범위하게 채택된 표준으로, 거의 모든 빅데이터 엔진과 호환됩니다.
단일 테이블 단위 트랜잭션만 지원하며, 멀티 테이블 원자적 변경은 불가능합니다.
Thrift 기반 비공식 표준으로, REST가 아니어서 클라우드 네이티브 환경에 어색합니다.
파티션 메타데이터가 많아질 경우 RDBMS 병목이 발생합니다.
2026년 기준 업계 컨센서스는 신규 프로젝트에서는 HMS 대신 REST Catalog로 시작하라는 방향입니다.

매니지드 서비스 옵션: AWS Glue Data Catalog, GCP Dataproc Metastore, Cloudera CDP, EMR/HDInsight/Dataproc 내장

AWS Glue Data Catalog

유형: 클라우드 매니지드 (AWS, Closed Source)

AWS의 완전 매니지드 통합 메타데이터 저장소로, S3·RDS·Redshift·Athena 전반에 걸쳐 테이블 정의와 스키마를 관리합니다. 서버리스 구조로 자동 스키마 디스커버리(Crawlers), Schema Registry, Iceberg 테이블 자동 최적화(Compaction·Snapshot Expiration·컬럼 통계)를 제공합니다.

특징

AWS 생태계(Athena, EMR, Redshift, SageMaker, Lake Formation) 전체에서 사실상 표준 카탈로그입니다.
Iceberg 네이티브 자동 최적화는 타 매니지드 카탈로그 대비 차별화된 기능입니다.
월 100만 객체·요청까지 무료 티어를 제공합니다.
AWS 종속(Vendor Lock-in)이 강하며, Iceberg REST 표준 미준수로 외부 엔진은 어댑터가 필요합니다.

가격: 객체 수($1/100만 개) + 요청 수($1/100만 건) + 최적화 작업($0.44/DPU-시간)

Google Cloud Dataproc Metastore

유형: 클라우드 매니지드 (GCP, 백엔드는 OSS HMS)

GCP의 완전 매니지드 Apache Hive Metastore 서비스입니다. HMS Thrift API를 100% 호환하여 기존 Hive 기반 워크로드를 그대로 이전할 수 있습니다. 2024년 이후 GCP는 Iceberg 중심 신규 워크로드를 위해 BigLake Metastore(Iceberg REST 카탈로그 규격 준수)를 별도 출시하였습니다.

특징

HMS 100% 호환으로 Hadoop/Hive 생태계 마이그레이션 부담이 최소화됩니다.
Zonal HA 기본 제공, Regional HA·DR 옵션으로 엔터프라이즈 SLA를 충족합니다.
항상 켜진 인스턴스 기반 과금으로 소규모·간헐적 워크로드에서 비용이 높습니다.
Iceberg 신규 워크로드는 BigLake Metastore와 병행 운영이 필요합니다.

가격: Enterprise 기준 Scaling Factor × $3.42/시간 (최소 프로덕션 권장 시 월 약 $2,462)

Delta Lake Unity Catalog — 상용 버전 (Databricks)

유형: 상용 매니지드 (Databricks SaaS)

Databricks가 2022년 GA한 통합 거버넌스 솔루션으로, 3-Level Namespace(catalog.schema.table)를 도입하여 기존 Hive의 2-Level 한계를 해결하였습니다. HMS와 Apache Ranger의 기능을 Databricks 플랫폼 내에서 통합한 형태로, 단순 메타스토어를 넘어 AI·ML 자산까지 거버넌스 범위를 확장합니다.

특징

ANSI SQL 기반 GRANT/REVOKE, ABAC, 행·열 수준 보안(Row Filter·Column Mask)을 제공합니다.
컬럼 단위 Lineage 자동 추적, Audit 로그(System Tables), Delta Sharing 통합이 포함됩니다.
MySQL·PostgreSQL·Snowflake·BigQuery·Redshift 등을 Lakehouse Federation으로 가상 마운트합니다.
Databricks 워크스페이스 종속이 강하며, Apache Ranger와의 공식 연동은 없습니다(대체 포지셔닝).

Delta Lake Unity Catalog — 오픈소스 버전

유형: 오픈소스 (Apache 2.0, LF AI & Data Foundation)

2024년 6월 Databricks가 Apache 2.0 라이선스로 공개하고 LF AI & Data Foundation에 기증한 버전입니다. OpenAPI 기반 REST API, Iceberg REST Catalog API 호환, 멀티 포맷·멀티 엔진 지향 설계가 핵심입니다.

상용 vs 오픈소스 주요 차이

영역 OSS 상용 (Databricks)

인증/SSO	기본 Bearer 토큰	OIDC/SAML SSO, SCIM
권한 모델	기본 GRANT/REVOKE	ABAC, Row Filter, Column Mask
Lineage	미지원 (로드맵)	컬럼 단위 자동 캡처
Audit Log	미지원	System Tables 자동 제공
Lakehouse Federation	미지원	MySQL/Snowflake/BigQuery 등
자동 최적화	미지원	Predictive Optimization
AI/ML 자산	추상화만	MLflow·Feature Store 완전 통합
Delta Sharing	별도 서버 필요	네이티브 통합

OSS는 "카탈로그 API + 멀티 포맷 추상화" 가 핵심이며, 거버넌스 심화 기능(ABAC, Lineage, Audit, Federation)은 상용 버전의 차별점으로 남아 있습니다.

Tabular

유형: 상용 매니지드 (2024년 6월 Databricks 인수, 신규 채택 비권장)

Apache Iceberg 공동 창시자 Ryan Blue가 2021년 설립한 Iceberg 전용 매니지드 카탈로그·자동 최적화 서비스입니다. 2024년 6월 Databricks가 인수하여 신규 고객 온보딩이 중단되었으며, 기존 고객은 Unity Catalog로 이전이 안내됩니다.

핵심 가치 (인수 이전)

Iceberg Auto-compaction·Auto-clustering·Snapshot Expiration 등 자동화
Iceberg REST Catalog 사양의 레퍼런스 구현 수준
멀티 엔진(Spark, Trino, Flink, Snowflake, Athena) 동시 접근 안정성

Project Nessie

유형: 오픈소스 (Apache 2.0, Dremio 주도) / 매니지드: Dremio Arctic

Dremio가 주도하여 시작한 트랜잭셔널 카탈로그로, Git-like 의미론(branch, tag, commit, merge)을 데이터 레이크에 적용합니다. 카탈로그 메타데이터를 버전 관리되는 데이터 구조에 저장하여 격리된 dev/test 환경, 데이터 실험, 롤백, Zero-copy Clone을 지원합니다.

특징

Multi-table Atomic Commit을 지원하여 여러 테이블에 걸친 트랜잭션 보장이 가능합니다.
Iceberg 외 포맷(Delta, Hudi, Paimon) 지원이 약해 실질적으로 Iceberg 전용에 가깝습니다.
메타데이터 백엔드로 RocksDB, MongoDB, DynamoDB, PostgreSQL 등 다양한 옵션을 지원합니다.
매니지드 서비스: Dremio Arctic (자동 Compaction, Garbage Collection 등 추가)

Apache Polaris

유형: 오픈소스 (Apache 2.0 Incubating, Snowflake 기증) / 매니지드: Snowflake Open Catalog

2024년 7월 Snowflake가 오픈소스화하고 ASF에 기증한 Apache Iceberg REST Catalog 표준의 레퍼런스 구현체입니다. Vendor-neutral 멀티 엔진 상호운용성에 초점을 맞추며, Credential Vending(엔진별 임시 자격증명 발급)과 Fine-grained RBAC을 기본으로 포함합니다.

특징

Iceberg REST 표준의 레퍼런스 구현으로 미래 표준에 가장 잘 정렬되어 있습니다.
Snowflake, Databricks, Dremio, AWS, GCP 어디에도 락인되지 않는 벤더 중립성을 표방합니다.
Delta Lake와 Hudi 지원이 추가되며 Unified Catalog로 확장 중입니다.
2024년 오픈소스화로 성숙도 한계가 있으며, Git-like Branching 같은 고급 기능은 없습니다.

Snowflake Open Catalog

유형: 클라우드 매니지드 (백엔드는 OSS Apache Polaris)

Snowflake가 제공하는 Apache Polaris 기반 매니지드 카탈로그 서비스로, 2024년 10월 GA되었습니다. Internal Catalog(직접 관리, R/W)와 External Catalog(Snowflake·Glue 등에서 동기화, R/O) 두 모드를 지원합니다.

특징

Iceberg REST 표준 100% 준수로 진정한 멀티 엔진 상호운용성을 제공합니다.
오픈소스(Apache Polaris) 기반으로 자체 호스팅도 가능합니다.
Snowflake 워크로드와 외부 OSS 엔진 간 단일 카탈로그 운영이 가능합니다.
2026년 상반기부터 REST API 요청 단위 빌링 시작 예정으로 TCO 예측이 불확실합니다.

Apache Gravitino

유형: 오픈소스 (Apache 2.0, Datastrato 기증 → ASF TLP) / 매니지드 서비스: 없음 (자체 호스팅만)

2023년 Datastrato가 개발하여 2024년 6월 Apache Incubator에 기증, 2025년 6월 Apache Top-Level Project(TLP)로 정식 졸업한 AI-native 유니버설 메타스토어입니다. "카탈로그의 카탈로그(catalog of catalogs)"를 표방하며, 테이블·파일셋·ML 모델·벡터·메시징 토픽까지 통합 거버넌스를 제공합니다.

참고: LinkedIn의 오픈소스 프로젝트는 별도의 OpenHouse(Iceberg 테이블 RESTful 프로비저닝)이며, Gravitino는 Datastrato가 기증한 별개 프로젝트입니다.

핵심 아키텍처: Metalake → Catalog → Schema → Table/Fileset/Model

Metalake: 최상위 컨테이너/테넌트 (조직 단위)
Catalog: 특정 메타데이터 소스(Hive, Iceberg, MySQL 등)와 연결되는 Connector 묶음
Schema / Table / Fileset / Model / Topic: 테이블뿐 아니라 ML 모델, 파일셋, 메시징 토픽까지 1급 객체로 모델링

데이터를 복제·동기화하지 않고 원본 시스템에서 직접 관리(direct management) 하는 방식으로 sync 지연·불일치가 없습니다.

특징

Iceberg / Delta Lake(1.2+) / Hudi / Paimon을 모두 Generic Lakehouse Catalog로 지원합니다.
Trino, Spark, Flink, Apache Doris, ClickHouse 등 폭넓은 MPP 엔진을 지원합니다.
ML 모델(Model Catalog), 파일셋(Fileset), Lance 벡터 임베딩, MCP Server를 1급 시민으로 통합하는 AI-native 설계입니다.
HMS, JDBC 기반 RDB(MySQL, PostgreSQL, ClickHouse 등), Kafka 토픽을 Federation으로 직접 관리합니다.
2026년 3월 기준 최신 버전은 1.2.0이며, Uber·Pinterest·Apple·Cloudflare 등에서 프로덕션 운영 중입니다.
매니지드 SaaS 서비스는 없으며, Kubernetes/EC2 기반 자체 호스팅이 기본 운영 모델입니다.

4. 제품들과 Data Lakehouse 포맷과의 조합

카탈로그 Apache Iceberg Delta Lake Apache Hudi Apache Paimon

HMS	HiveCatalog 지원 (단일 테이블 한계)	Spark Delta Sync 경유 (제한적)	HiveSync 지원	HiveCatalog 지원
AWS Glue	네이티브 + 자동 최적화	네이티브	네이티브	공식 미지원 (Flink 경유)
GCP Dataproc Metastore	Spark/Trino 경유 (BigLake 권장)	Spark 경유 지원	Dataproc 1.3+ 지원	Flink 커넥터 경유 가능
UC 상용 (Databricks)	UniForm + REST API	1급 시민 (최우선)	External Table만	미지원
UC OSS	REST API 네이티브	네이티브	External Table	약함
Tabular (단종)	1급 시민 (유일)	미지원	미지원	미지원
Project Nessie	1급 시민 (핵심)	약함/비공식	약함/비공식	약함/비공식
Apache Polaris	1급 시민 (레퍼런스)	Generic Table API 추가 지원	로드맵/제한적	미지원
Snowflake Open Catalog	1급 시민	Polaris Generic Table 경유	로드맵	미지원
Apache Gravitino	1급 시민 (REST)	Generic Lakehouse Catalog 지원 (1.2+)	지원	1급 시민

포맷별 최적 조합 요약

Iceberg 중심 → Apache Polaris / Snowflake Open Catalog / Project Nessie / AWS Glue / Apache Gravitino
Delta Lake 중심 → UC 상용 (Databricks) / UC OSS / Apache Gravitino
Hudi 중심 → HMS / AWS Glue / GCP Dataproc Metastore / Apache Gravitino
Paimon 중심 → HMS (Flink + HiveCatalog) / AWS Glue (Flink 경유) / Apache Gravitino (1급 시민)
멀티 포맷 → HMS (넓지만 낡음) / UC OSS (Iceberg·Delta 지원) / Apache Gravitino (4대 포맷 통합)

Apache Paimon 자체 카탈로그 옵션: Paimon은 외부 중앙 메타스토어에 의존하지 않는 경량 카탈로그를 자체적으로 제공합니다. Filesystem Catalog(로컬·S3·HDFS 경로 기반, 운영 부담 최소), JDBC Catalog(MySQL·PostgreSQL 기반, 팀 공유), REST Catalog(HTTP 기반, 분산 환경) 세 가지 옵션이 있어, 소규모 환경이나 Flink 전용 파이프라인에서 HMS 없이 독립 운영이 가능합니다. HMS 운영 부담을 줄이고 싶은 Paimon 중심 팀에게 유효한 선택지입니다.

5. 제품들과 MPP 엔진, 클라우드 서비스, DB와의 조합

MPP 엔진 호환성

카탈로그 Spark Trino / Presto Flink Hive Doris / StarRocks

HMS	✅ 완전	✅ 완전	✅	✅ 네이티브	✅ (대부분)
AWS Glue	✅ (EMR)	✅ Athena (Trino 기반)	✅	✅ (EMR Hive)	부분 (어댑터 필요)
GCP Dataproc Metastore	✅	✅	✅	✅	간접
UC 상용	✅ (DBR 최적화)	✅ (커넥터)	제한적	—	간접
UC OSS	✅ (Spark 3.5+)	✅	제한적	—	Iceberg REST 경로
Project Nessie	✅	✅	✅	제한적	Dremio 경유
Apache Polaris	✅	✅	✅	—	✅ Doris, StarRocks
Snowflake Open Catalog	✅	✅	✅	—	✅ (REST 호환 엔진)
Apache Gravitino	✅	✅	✅	—	✅ Doris, ClickHouse

클라우드 서비스 통합

카탈로그 AWS EMR GCP Dataproc Azure HDInsight Snowflake BigQuery

HMS	✅ 기본	✅ (Dataproc Metastore)	✅ 기본	—	—
AWS Glue	✅ 1급	—	—	External Catalog	—
GCP Dataproc Metastore	—	✅ 1급	—	—	BigLake 연계
UC 상용	간접 (OSS 커넥터)	간접	간접	Federation	Federation
UC OSS	✅ (직접 배포 가능)	✅	✅	Iceberg REST	Iceberg REST
Project Nessie	사용자 구성	사용자 구성	사용자 구성	—	—
Apache Polaris	사용자 구성 (REST)	사용자 구성 (REST)	사용자 구성	✅ Open Catalog	—
Snowflake Open Catalog	✅ (REST 연결)	✅ (REST 연결)	✅	✅ 네이티브	—
Apache Gravitino	사용자 구성	사용자 구성	사용자 구성	—	—

RDB / 외부 DB 페더레이션

UC 상용: MySQL, PostgreSQL, Snowflake, BigQuery, Redshift, SQL Server, Salesforce, Oracle, Teradata 페더레이션
AWS Glue: Lake Formation 통해 RDS·Redshift·Aurora 메타데이터 통합
GCP Dataproc Metastore: BigQuery와 메타데이터 노출 가능
Apache Polaris / Snowflake Open Catalog: Federation 로드맵 (Unity Catalog, Glue, HMS에서 점진적 통합 예정)
Apache Gravitino: HMS, MySQL, PostgreSQL, ClickHouse, Kafka 등을 Connector로 직접 Federation. Snowflake는 JDBC Catalog 또는 Iceberg REST 방식으로 연동 가능 (→ 9번 아키텍처 패턴 참고)
HMS / Nessie / UC OSS: 외부 DB 페더레이션 기능 없음 (엔진 레벨에서 처리)

6. 거버넌스 도구 통합

중앙 메타스토어는 메타데이터 관리의 기술 계층을 담당하지만, 엔터프라이즈 데이터 거버넌스는 인가(Authorization), 데이터 계보(Lineage), 데이터 발견(Discovery)·분류(Classification)를 별도 레이어에서 처리하는 경우가 많습니다.

Apache Ranger — 정책 기반 인가 엔진

Apache Ranger는 Hadoop 생태계에서 출발한 오픈소스 인가 프레임워크로, 중앙화된 정책 관리와 감사 로깅을 제공합니다.

메타스토어 통합 방식 성숙도

HMS/Hive	RangerHiveAuthorizerFactory 플러그인으로 네이티브 통합. 테이블·켼럼·태그 기반 정책	Production (CDP/EMR 표준)
AWS Glue	직접 플러그인 없음. EMR + Ranger 조합으로 콤퓨트 레벨 인가. Glue 자체는 Lake Formation 사용	간접 지원
Databricks UC	네이티브 미지원. Privacera(Ranger 상용 fork)가 UC 정책을 Ranger UX로 매핑	써드파티 우회
Apache Polaris	RANGER-4910에서 플러그인 개발 요청 중. 2026년 4월 기준 미출시. Polaris 자체 RBAC 사용	로드맵 / 부재
Apache Gravitino	Gravitino 자체 RBAC으로 인가. Ranger 직접 통합 없음	부재

Ranger가 여전히 필요한 케이스

HDFS, HBase, Kafka, Solr 등 레거시 Hadoop 자산 비중이 높은 환경
온프레미스·엠어개플(air-gapped) 데이터 플랫폼 (CDP, MapR-legacy)
다중 엔진(Trino + Hive + HBase)에 동일 Tag 기반 정책(TBAC) 적용이 필요한 경우
컴플라이언스 요건으로 OSS 자체 호스팅이 필수인 경우

Apache Atlas — 데이터 계보 및 분류

Apache Atlas는 JanusGraph + Solr 기반 메타데이터·거버넌스 프레임워크로, Lineage 자동 캐포와 태그 기반 분류(Classification)를 제공합니다.

카탈로그 통합 방식

HMS/Hive	HiveHook 네이티브 통합. 가장 성숙. 테이블·켼럼 레벨 Lineage 자동 캐포
AWS Glue	Glue 메타데이터를 Atlas로 import하는 패턴 (자동 sync 아님 import 기반)
UC / Polaris / Gravitino	네이티브 미지원. UC는 자체 Lineage 제공

2026년 기준 Atlas는 Hadoop/CDP 레거시 환경에 최적화되어 있으며, 클라우드 네이티브 카탈로그와의 통합이 약합니다. 신규 환경에서의 Atlas 도입은 권장하지 않으며, OpenMetadata나 DataHub 같은 모던 거버넌스 카탈로그가 대안입니다.

OpenMetadata — 모던 오픈소스 거버넌스 카탈로그

OpenMetadata는 120개 이상의 커넥터를 제공하는 모던 오픈소스 메타데이터 플랫폼으로, Ranger+Atlas 조합을 대체하는 단일 거버넌스 레이어를 목표로 합니다.

카탈로그 커넥터 상태

HMS/Hive	GA, 성숙. 메타데이터 + Lineage + Profiling 지원
AWS Glue	GA. 메타데이터·Lineage·파티션 정보 수집
Databricks UC	GA (unity-catalog 커넥터). UC Lineage 활용
Apache Polaris	Iceberg REST 커넥터로 우회. 전용 커넥터는 미출시
Project Nessie	Iceberg 커넥터 + Nessie REST로 Branch 메타데이터 활용
Apache Gravitino	직접 커넥터 없음. HMS/Iceberg 경로로 우회

거버넌스 아키텍처 권장 패턴 — Two-Layer Architecture

업계는 Two-Layer Architecture로 수렴하고 있습니다.

기술 카탈로그(Technical Catalog): Polaris, UC, Glue, HMS, Nessie, Gravitino — Iceberg/Delta REST 스펙 구현, 엔진 인가의 source of truth
거버넌스 카탈로그(Governance Catalog): OpenMetadata, DataHub, Atlan, Collibra — 비즈니스 메타데이터, Lineage, Discovery, Stewardship

선택 가이드

환경 권장 조합

Greenfield (신규 2026)	카탈로그 네이티브 RBAC (UC/Lake Formation/Polaris) + OpenMetadata
Brownfield (Hadoop 레거시)	Ranger + Atlas 유지. 클라우드 마이그레이션 시 Privacera로 정책 연속성 확보
하이브리드 멀티 클라우드	카탈로그 네이티브가 Enforcement, OpenMetadata/Collibra가 Governance Layer

7. TCO 비교

카탈로그별 비용 구조

카탈로그 소형 (월) 중형 (월) 대형 (월) 과금 모델

HMS (자체)	~$200 + 0.1 FTE	~$780 + 0.3 FTE	~$3,250 + 0.7 FTE	인프라 + 운영 인력
AWS Glue	~$4	~$140	~$2,500	객체 수 + 요청 수
GCP DPMS Enterprise	$2,500 (항상 켜집)	$2,500	$5,000	인스턴스 시간 (고정)
UC 상용 (Databricks)	+$750 추가	+$7,500 추가	+$75,000 추가	DBU 프리미엄 차액
Polaris / Open Catalog	$0 → ~$50 (H1 과금 후)	$0 → ~$200	$0 → ~$2,000	API 요청 (2026 H1~)
Project Nessie OSS	~$200	~$700	~$2,500	인프라
Apache Gravitino OSS	~$200	~$700	~$2,500	인프라

소규모 워크로드: AWS Glue(~$4/월) 또는 Polaris(현재 무료)가 압도적으로 저렴합니다.
GCP Dataproc Metastore는 워크로드가 없어도 항상 과금되므로 소형 환경에는 비효율적입니다.
UC 상용은 Databricks를 이미 사용 중인 환경에서는 증분 비용(marginal cost)이지만, 비-Databricks 환경에서는 매우 비싘니다.

숨겨진 비용 요소

운영 인력 (가장 큰 숨겨진 비용)

자체 운영(HMS·Polaris OSS·Nessie·Gravitino)은 시니어 데이터 엔지니어 기준 대형 환경에서 연 $75K–$150K의 운영 인건비가 발생합니다. 매니지드 서비스(Glue·DPMS·UC)는 0.05–0.3 FTE 수준으로 감소합니다.

마이그레이션 비용

경로 예상 공수

HMS → Glue / DPMS	메타데이터 export/import + 파티션 재등록. 중형 1–3 person-month
HMS → Unity Catalog	External table 변환 + UC catalog 등록 + 권한 재정의. 1–6 person-month
HMS → Iceberg REST (Polaris/Nessie)	Hive→Iceberg 테이블 변환(스냅샷/리라이트) + 카탈로그 등록. 테이블당 컴퓨트 비용 발생
Ranger → UC 거버넌스	정책 자동 변환 도구 부재로 수작업 변환 + 검증 필요. 6–12 person-month (대규모)

Lock-in 탈출 비용

UC 상용 → 타 카탈로그: Managed Table을 External/Iceberg로 변환, 정책 재구성 필요. 사실상 재마이그레이션 수준
Glue → 타 카탈로그: Iceberg 테이블이면 거의 무비용. Hive 테이블은 중간 수준
OSS 카탈로그(Polaris·Nessie·HMS·UC OSS·Gravitino): 락인 거의 없음. OSS의 핵심 TCO 장점

Snowflake Open Catalog 과금 주의

2026년 H1부터 과금이 시작될 예정입니다. 현재 무료 기간에 마이그레이션을 완료하면 전환 비용 없이 진입 장벽을 낙었습니다.

8. 마이그레이션 전략

HMS에서 현대적 카탈로그로의 이전

레거시 Hive Metastore에서 현대적 카탈로그로 이전할 때는 점진적 접근(Incremental Migration) 이 권장됩니다. Big Bang 방식은 롤백이 어렵고 운영 중단 위험이 높습니다.

단계별 마이그레이션 로드맵

Phase 1 — 인벤토리 및 의존성 분석 (1–2개월)

전체 테이블 목록, 파티션 수, 접근 엔진, 권한 정책 문서화
비즈니스 크리티컈 테이블과 배치 파이프라인 식별
대상 카탈로그 선택 및 POC 진행

Phase 2 — Iceberg 포맷 변환 (테이블당)

신규 테이블: 처음부터 Iceberg 포맷으로 작성
기존 Hive 테이블: ALTER TABLE ... SET TBLPROPERTIES ('table_type'='ICEBERG')로 인플레이스 마이그레이션 또는 CALL system.rewrite_data_files()로 전체 재작성

Phase 3 — 카탈로그 등록 및 이중 운영

새 카탈로그(Polaris·Nessie·Glue 등)에 변환된 테이블 등록
HMS와 새 카탈로그를 병행 운영(dual-write/dual-read) 기간 유지
엔진별 카탈로그 설정 변경 (Spark spark.sql.catalog.*, Trino catalog.properties)

Phase 4 — 트래픽 이전 및 HMS 폐기

팀별·도메인별 순차 이전
HMS 메타데이터 아카이브 보관 후 폐기

클라우드별 권장 마이그레이션 경로

현재 환경 대상 카탈로그 주요 도구/서비스

HMS + AWS EMR	AWS Glue Data Catalog	AWS Glue Crawler, EMR Iceberg 설정
HMS + GCP Dataproc	GCP Dataproc Metastore → BigLake Metastore	Dataproc Metastore import, BigLake REST Catalog API
HMS + Databricks	Databricks Unity Catalog	Databricks UPGRADE TABLE 명령, HMS Federation → UC External Location
HMS + 멀티 클라우드	Apache Polaris / Nessie (자체 호스팅)	PyIceberg migration tool, Iceberg REST 카탈로그 마이그레이션 스크립트

마이그레이션 주요 함정(Pitfall)

파티션 수 과다: HMS에서 수억 개 파티션이 있는 테이블은 Iceberg 변환 시 메타데이터 재생성 비용이 큰 점을 쿠사해야 합니다. 먼저 파티셔닝 전략을 재검토하십시오.
직렬화 포맷(SerDe) 불일치: 특수 SerDe를 사용하는 테이블은 Iceberg 변환 전 Parquet/ORC 재작성이 필요합니다.
권한 정책 공백: Ranger 정책을 새 카탈로그의 RBAC 모델로 1:1 매핑하는 자동화 도구가 없으므로, 수작업 변환 및 검증 기간을 충분히 확보하십시오.
엔진별 동작 차이: HMS와 Iceberg 카탈로그는 파티션 프루닝, 통계 활용 방식이 다를 수 있어 쿼리 성능 회귀(regression) 검증이 필요합니다.

9. 아키텍처 패턴

단일 카탈로그 vs 멀티 카탈로그

항목 단일 카탈로그 멀티 카탈로그

운영 복잡도	낙음	높음
벤더 종속 위험	높음 (단일 벤더 의존)	낙음
멀티 클라우드 지원	어려움	자연스러움
엔진 다양성	제한	유연
거버넌스 일관성	강함	별도 Federation Layer 필요
권장 상황	단일 클라우드·단일 팀	멀티 클라우드·대형 조직·Data Mesh

Two-Layer Architecture

┌──────────────────────────────────────────────────┐
│    거버넌스 카탈로그 (Governance Layer)       │
│  OpenMetadata / DataHub / Collibra / Atlan  │
│  Lineage, Discovery, Classification         │
└──────────────────────────────────────────────────┘
          ↑ 메타데이터 수집 (Ingest)
┌──────────────────────────────────────────────────┐
│     기술 카탈로그 (Technical Layer)           │
│  HMS / Glue / Polaris / UC / Nessie / Gravitino │
│  스키마 관리, 엔진 인가, REST API, RBAC    │
└──────────────────────────────────────────────────┘
          ↑ 메타데이터 등록
┌──────────────────────────────────────────────────┐
│              스토리지 레이어                  │
│         S3 / GCS / ADLS / HDFS              │
│  Iceberg / Delta Lake / Hudi / Paimon       │
└──────────────────────────────────────────────────┘

멀티 카탈로그 Federation 패턴

방법 1 — 쿼리 엔진 레벨 Federation

Trino/Presto에서 여러 카탈로그를 catalog.properties로 동시 등록
SELECT * FROM glue_catalog.db.table JOIN nessie_catalog.db.table 형태로 크로스 카탈로그 조인 가능
운영 복잡도가 낙지만 쿼리 레이어에서만 통합

방법 2 — 카탈로그 레이어 Federation (Gravitino 방식)

Gravitino Metalake가 HMS·Glue·MySQL 등을 Connector로 흡수
엔진은 Gravitino 단일 엔드포인트에만 연결
양방향 direct management로 카탈로그 간 일관성 보장

방법 3 — 데이터 메시(Data Mesh) 분산 카탈로그

도메인별 독립 카탈로그 운영 (Domain Ownership)
중앙 거버넌스 카탈로그(OpenMetadata)가 각 도메인 카탈로그를 수집·조율
자율성과 거버넌스를 동시에 달성하는 현대적 패턴

Data Mesh에서의 카탈로그 역할

Data Mesh 아키텍처에서 카탈로그는 데이터 제품(Data Product) 의 메타데이터를 관리하는 계약(contract) 레지스트리 역할을 합니다.

각 도메인은 자체 기술 카탈로그(HMS·Iceberg REST·UC OSS 등)를 운영합니다.
중앙 거버넌스 카탈로그는 각 도메인의 데이터 제품 스펙, SLO, 오너십을 등록·검색합니다.
Apache Gravitino의 Metalake 개념은 이 패턴과 잘 정합합니다 — 도메인별 Catalog을 Metalake에서 연합 관리합니다.

Apache Gravitino + Snowflake 연동

Gravitino와 Snowflake를 연동하는 방법은 두 가지이며, 기존 환경과 목표에 따라 선택합니다.

방법 1 — JDBC Catalog 페더레이션 (Snowflake → Gravitino 데이터 소스 등록)

Gravitino가 Snowflake JDBC 드라이버를 통해 Snowflake를 Catalog로 등록합니다. Trino·Spark 등 엔진이 Gravitino 단일 엔드포인트를 통해 Snowflake 테이블과 Iceberg·HMS 테이블을 크로스 조인할 수 있습니다.

적합한 상황: Snowflake 워크로드가 이미 존재하고, Gravitino로 다른 데이터 소스(HMS, Iceberg, MySQL 등)와 통합해야 할 때

Gravitino REST API — Snowflake 카탈로그 등록

POST /api/metalakes/{metalake}/catalogs
{
  "name": "snowflake_catalog",
  "type": "RELATIONAL",
  "provider": "jdbc-postgresql",
  "comment": "Snowflake federation via Gravitino JDBC",
  "properties": {
    "jdbc-url": "jdbc:snowflake://<account>.snowflakecomputing.com/?db=<database>&warehouse=<warehouse>",
    "jdbc-user": "<username>",
    "jdbc-password": "<password>",
    "jdbc-driver": "net.snowflake.client.jdbc.SnowflakeDriver"
  }
}

Trino에서 크로스 소스 조인 예시

-- Gravitino를 통해 Snowflake 테이블 + Iceberg 테이블 조인
SELECT s.customer_id, s.revenue, r.region_name
FROM gravitino.snowflake_catalog.sales_db.orders s
JOIN gravitino.iceberg_catalog.warehouse.dim_region r
  ON s.region_id = r.region_id;

방법 2 — Iceberg REST (Gravitino → Snowflake Open Catalog 노출)

Gravitino가 관리하는 Iceberg 테이블 메타데이터를 Iceberg REST Catalog API로 노출하고, Snowflake Open Catalog(Polaris 기반)가 이를 구독하여 Snowflake가 동일 Iceberg 테이블을 External Iceberg Table로 직접 읽는 구조입니다.

적합한 상황: Iceberg 기반 레이크하우스를 Gravitino로 관리하고, Snowflake도 같은 테이블에 읽기 접근해야 할 때

아키텍처 흐름

Gravitino (Iceberg 메타데이터 관리 + 엔진 인가)
    ↕ Iceberg REST Catalog API
Snowflake Open Catalog (Polaris, Iceberg REST 클라이언트로 동기화)
    ↕ External Iceberg Table
Snowflake Warehouse (읽기 전용 쿼리)

Snowflake — External Catalog 통합 설정 예시

-- 1. Gravitino Iceberg REST를 External Catalog로 등록
CREATE CATALOG INTEGRATION gravitino_iceberg
  CATALOG_SOURCE = ICEBERG_REST
  TABLE_FORMAT = ICEBERG
  CATALOG_NAMESPACE = 'warehouse'
  REST_CONFIG = (
    CATALOG_URI = 'https://<gravitino-host>:8090/iceberg/api'
    CATALOG_NAME = 'iceberg_catalog'
  )
  REST_AUTHENTICATION = (
    TYPE = OAUTH
    OAUTH_TOKEN_URI = 'https://<gravitino-host>:8090/oauth/token'
    OAUTH_CLIENT_ID = '<client_id>'
    OAUTH_CLIENT_SECRET = '<client_secret>'
    OAUTH_ALLOWED_SCOPES = ('PRINCIPAL_ROLE:ALL')
  )
  ENABLED = TRUE;

-- 2. Gravitino가 관리하는 Iceberg 테이블을 Snowflake External Table로 마운트
CREATE ICEBERG TABLE snowflake_db.public.orders
  EXTERNAL_VOLUME = 's3_iceberg_vol'
  CATALOG = 'gravitino_iceberg'
  CATALOG_TABLE_NAME = 'orders';

-- 3. Snowflake에서 조회
SELECT * FROM snowflake_db.public.orders LIMIT 100;

방법 비교

항목 방법 1 — JDBC Federation 방법 2 — Iceberg REST

Snowflake 역할	데이터 소스 (Gravitino가 읽음)	Iceberg 테이블 소비자 (Snowflake가 읽음)
데이터 흐름 방향	Snowflake → Gravitino → 엔진	Gravitino → Snowflake Open Catalog → Snowflake
Snowflake 쓰기	Gravitino 경유 가능 (JDBC Write)	Snowflake는 읽기 전용
구성 복잡도	낮음 (JDBC 드라이버 설치 + REST 등록)	중간 (Iceberg REST + OAuth 설정 필요)
권장 상황	기존 Snowflake 데이터를 다른 소스와 통합	Iceberg 레이크하우스 + Snowflake 동시 활용
락인 위험	없음 (JDBC 표준)	없음 (Iceberg REST 표준)

하이브리드 구성 — 방법 1 + 방법 2 동시 운용

단방향의 한계를 행과적으로 해결하는 구성입니다. Snowflake 원체 데이터는 JDBC로 Gravitino가 읽어 Iceberg 레이크하우스에 올리고, 처리된 Iceberg 테이블은 Snowflake Open Catalog을 통해 Snowflake가 다시 읽는 주기를 형성합니다.

아키텍처 흐름

[Snowflake 원체 데이터]
    ↓ 방법 1 — JDBC 읽기 (Gravitino JDBC Catalog)
[Gravitino]
    ↓ Iceberg ETL 변환 · 저장 (Spark / Trino)
[S3 / GCS — Iceberg 테이블]
    ↓ 방법 2 — Iceberg REST (Gravitino REST API)
[Snowflake Open Catalog (Polaris)]
    ↓ External Iceberg Table
[Snowflake Warehouse — 분석 쿼리]

시나리오 예시

Snowflake에 잘 정리된 판매 원렓 데이터를 JDBC로 가져와 Spark로 전처리(Cleansing, Aggregation)한 뒤 Iceberg로 저장
처리된 Iceberg 마트 테이블을 Snowflake이 Open Catalog을 통해 다시 읽어 대시보드나 ML 입력 데이터로 활용
Gravitino가 양쪽 커넥터를 단일 Metalake에서 관리하므로 엔진은 Gravitino 하나만 바라보면 됨

하이브리드 방식에서의 양방향성

방향 구현 방법 지원 여부

Snowflake → Gravitino (읽기)	방법 1 JDBC Catalog	✅
Snowflake → Gravitino (쓰기)	방법 1 JDBC Write	✅ (소량 쓰기 한정 권장)
Gravitino → Snowflake (읽기)	방법 2 Iceberg REST + External Table	✅
Gravitino → Snowflake (쓰기)	Snowflake External Iceberg Table 한계	❌ (불가)

Snowflake에서 Iceberg 테이블에 쓰기가 필요한 경우 Snowflake-managed Iceberg Table을 쓰는 것이 유일한 선택이지만, 이 때는 메타데이터 소유권이 Snowflake로 넘어가 Gravitino가 모듨 마스터 역할을 잃게 됩니다. 대부분의 엔터프라이즈 환경에서는 Gravitino가 카탈로그 주수, Snowflake는 소비자로 역할을 나누는 하이브리드 구성이 현실적인 최선안입니다.

10. 요약

제품 유형별 분류

오픈소스

Hive Metastore(HMS) — 레거시 표준, 가장 광범위한 호환성
Project Nessie — Git-like 브랜칭, Multi-table Atomic Commit
Apache Polaris — Iceberg REST 표준 레퍼런스 구현, 벤더 중립
Unity Catalog OSS — 멀티 포맷 추상화, Iceberg REST 호환
Apache Gravitino — AI-native 유니버설 메타스토어, 4대 포맷(Iceberg·Delta·Hudi·Paimon) + ML 모델·벡터 통합 (ASF TLP)

클라우드 매니지드

AWS Glue Data Catalog — AWS 생태계 표준, Iceberg 자동 최적화
GCP Dataproc Metastore — HMS 완벽 호환, GCP 레거시 워크로드
Snowflake Open Catalog — Polaris 기반, Iceberg REST 표준, 벤더 중립 매니지드

상용 SaaS

Unity Catalog (Databricks) — 가장 깊은 거버넌스, AI·ML 자산 포함
Tabular — Iceberg 전문 (Databricks 인수로 신규 채택 비권장)
Dremio Arctic — Nessie 기반 매니지드

시나리오별 선택 가이드

시나리오 권장 제품

AWS 생태계 + Iceberg 자동 최적화	AWS Glue Data Catalog
GCP + 레거시 Hive 워크로드 마이그레이션	GCP Dataproc Metastore
Databricks 중심 + 심화 거버넌스 필요	Unity Catalog (상용)
멀티 클라우드 + Iceberg REST 표준 + 락인 회피	Apache Polaris / Snowflake Open Catalog
Iceberg + 데이터 브랜칭·실험 워크플로우	Project Nessie / Dremio Arctic
셀프 호스팅 + 멀티 포맷 + 비용 최소화	Unity Catalog OSS
Hudi/Paimon 중심 + 레거시 호환	HMS (+ Glue/Dataproc Metastore 매니지드)
AI-native 멀티 포맷 + 멀티 엔진 + 자체 호스팅	Apache Gravitino

2026년 기준 업계 방향성

현재 업계의 큰 흐름은 Iceberg REST Catalog 표준 중심으로의 수렴입니다. HMS는 레거시 호환을 위해 유지되지만 신규 아키텍처 설계에서는 사용을 지양하는 추세이며, Apache Polaris가 레퍼런스 구현으로 자리 잡고 있습니다. Databricks는 Tabular 인수를 통해 Delta와 Iceberg를 통합하는 방향을 선택하였습니다. 멀티 포맷·멀티 엔진·벤더 중립을 모두 만족하는 완전한 오픈소스 솔루션은 아직 성숙 단계에 있으며, 엔터프라이즈는 대부분 오픈소스 카탈로그 + 매니지드 클라우드 서비스의 조합으로 운영하고 있습니다.

Apache XTable이란

불곰1 — Sun, 26 Apr 2026 23:44:08 +0900

개요

Apache XTable™(Incubating)은 데이터 레이크하우스의 서로 다른 오픈 테이블 포맷 간 상호운용성을 제공하는 오픈소스 메타데이터 변환 도구입니다. Apache Iceberg, Apache Hudi, Delta Lake 세 가지 주요 포맷 사이에서 데이터를 복사하거나 이동하지 않고 메타데이터만 번역하여, 하나의 물리적 데이터 셋을 여러 포맷으로 동시에 읽을 수 있게 해줍니다.

원래 OneTable이라는 이름으로 Microsoft, Google, Onehouse가 공동으로 오픈소스화하였으며, 이후 Apache Software Foundation에 기증되어 현재 Apache XTable™ (Incubating) 으로 불리고 있습니다.

핵심 포인트: XTable은 새로운 테이블 포맷이 아닙니다. 기존 포맷 간의 메타데이터 변환기입니다.

Apache XTable이 필요한 이유

데이터 레이크하우스 생태계에는 세 가지 주요 오픈 테이블 포맷이 공존하고 있습니다.

포맷	주요 강점	주요 지지 업체
Apache Hudi	고빈도 업서트, 낮은 레이턴시 스트리밍 수집	Uber, AWS
Apache Iceberg	대규모 분석, 강력한 스키마 진화	Netflix, Apple, Snowflake
Delta Lake	Databricks 최적화, ACID 트랜잭션	Databricks, Microsoft

문제는 각 도구나 플랫폼이 특정 포맷만 지원하는 경우가 많다는 점입니다.

Databricks는 Delta Lake에 최적화되어 있습니다.
Snowflake는 주로 Iceberg를 지원합니다.
Apache Hudi로 수집하는 팀과 Iceberg로 분석하는 팀이 같은 조직 안에 공존하기도 합니다.

이처럼 포맷 파편화(format fragmentation) 가 발생하면 동일한 데이터를 중복 저장하거나, 포맷을 전환할 때 전체 데이터를 재작성해야 하는 비용이 발생합니다. Apache XTable은 이 문제를 메타데이터 변환만으로 해결합니다.

아키텍처 및 동작 원리

Apache XTable는 다음 원칙으로 동작합니다.

데이터 파일은 그대로 유지됩니다. 모든 포맷은 공통적으로 Parquet 파일을 사용하며, XTable은 이 파일을 건드리지 않습니다.
메타데이터만 번역합니다. 각 포맷의 메타데이터 디렉토리(_delta_log/, metadata/, .hoodie/)에 새 메타데이터를 생성합니다.
Primary(원본) + Secondary(대상) 구조입니다. 쓰기는 Primary 포맷으로만 이루어지고, XTable이 Secondary 포맷의 메타데이터를 동기화합니다.

두 가지 동기화 모드:

Incremental(증분) 모드: 마지막 동기화 이후 변경된 커밋만 처리합니다. 대용량 테이블에 적합하며 성능이 우수합니다.
Full(전체) 모드: 테이블 전체를 처음부터 재동기화합니다.

Apache XTable 장단점 및 한계

장점

데이터 복사 없음: 물리적 데이터 파일을 이동하거나 복사하지 않아 스토리지 비용이 증가하지 않습니다.
전방향(omni-directional) 변환: Hudi ↔ Iceberg ↔ Delta Lake 간 어떤 방향으로도 변환이 가능합니다.
점진적 마이그레이션 지원: 전환 기간 동안 두 포맷을 동시에 유지할 수 있어 무중단 마이그레이션이 가능합니다.
카탈로그 동기화: Hive Metastore, AWS Glue와의 메타데이터 등록 자동화를 지원합니다.
증분 모드 효율성: 마지막 변경분만 처리하므로 대용량 테이블에서도 효율적입니다.
벤더 중립: 특정 클라우드나 플랫폼에 종속되지 않습니다.

단점 및 한계

MoR(Merge-on-Read) 미지원: Hudi와 Iceberg의 MoR 테이블은 지원하지 않습니다. 로그 파일이 동기화되지 않아 데이터가 불완전하게 보일 수 있습니다.
Delta Delete Vectors 미지원: Delta Lake의 Delete Vectors가 동기화되지 않습니다.
쓰기 최적화 손실: Secondary 포맷 고유의 쓰기 최적화(Iceberg의 Hidden Partitioning, Delta의 Deletion Vectors 등)가 적용되지 않습니다.
Generated Columns 제한: Delta Lake의 Generated Columns 동기화가 제한적입니다.
타임스탬프 불일치: Secondary 포맷 커밋 타임스탬프가 Primary와 정확히 일치하지 않을 수 있습니다.
구조화 데이터 전용: 비정형 데이터는 지원하지 않습니다.
Hudi 요구사항: Hudi를 소스로 사용할 경우 버전 0.14.0 이상, 메타데이터 테이블 및 Hive 스타일 파티셔닝 활성화가 필요합니다.
운영 오버헤드: 별도 JAR 실행 및 동기화 스케줄 관리가 필요합니다.

Delta Lake Uniform과의 비교

Delta Lake Uniform은 XTable과 자주 비교되는 기능입니다. 차이를 명확히 이해하고 선택해야 합니다.

항목	Apache XTable	Delta Lake Uniform
변환 방향	전방향 (Hudi↔Iceberg↔Delta)	단방향 (Delta → Iceberg/Hudi)
소스 포맷	Hudi, Iceberg, Delta 모두 가능	Delta Lake만 소스 가능
Databricks 의존성	없음 (독립 실행)	Databricks 플랫폼에 통합
운영 방식	별도 JAR 실행 필요	Delta 쓰기 시 자동 동기화
Liquid Clustering	제약 없음	함께 사용 불가
적합한 케이스	포맷 간 마이그레이션, 다중 포맷 유지, Hudi 중심 환경	Databricks에서 쓰고 Snowflake에서 읽는 단순 패턴

Apache XTable와 비슷한 오픈소스 및 매니지드 서비스

XTable과 Delta Uniform이 해결하는 문제는 "데이터 복사 없이 여러 테이블 포맷을 동시에 지원하는 것" 입니다. 이 관점에서 동일한 문제를 다루는 도구들을 정리합니다.

포맷 변환/번역 도구 (직접 비교 대상)

이름	방향	특징
Delta Lake Uniform	Delta → Iceberg / Hudi (단방향)	Databricks에 내장. Delta 쓰기 시 자동 동기화. 별도 비교 섹션 참고.
Iceberg Snapshot / Migrate 프로시저	Parquet · Hive · Delta → Iceberg (단방향)	Iceberg 자체 내장 기능. 운영 중 지속 동기화가 아닌 1회성 마이그레이션에 적합.
Hudi Sync Tool (HoodieHiveSync 등)	Hudi → Hive Metastore / Iceberg (단방향)	Hudi 내장. 커밋마다 외부 카탈로그에 메타데이터를 자동 등록. XTable보다 범위가 좁음.

다른 접근법으로 같은 문제 해결 (쿼리 레이어 통합)

메타데이터를 번역하는 대신, 쿼리 엔진 레이어에서 여러 포맷을 직접 해석하는 방식입니다.

이름	설명
Dremio	Iceberg, Delta, Hudi, Parquet 등을 단일 쿼리 레이어로 통합. 포맷 변환 없이 다중 포맷 동시 접근.
Starburst / Trino	Trino 기반으로 다양한 포맷 및 데이터 소스를 단일 SQL로 조회.
Apache Spark	Hudi / Iceberg / Delta 모두 읽기 지원. 변환 없이 쿼리만으로 포맷 간 접근 가능.

매니지드 서비스 (XTable 기반 또는 포맷 상호운용 지원)

이름	설명
Onehouse	XTable을 만든 회사의 매니지드 레이크하우스 서비스. XTable 동기화, 테이블 최적화, 멀티 포맷 수집을 완전 관리형으로 제공. AWS · GCP · Azure 지원.
AWS EMR + Glue	EMR에서 XTable JAR를 실행하고 Glue Catalog에 멀티 포맷 테이블을 등록하는 조합으로 매니지드에 가깝게 운영 가능.

사용 예시

예시 1: Hudi → Iceberg + Delta 동시 동기화

Hudi로 수집한 스트리밍 데이터를 Dremio(Iceberg)와 Databricks(Delta) 양쪽에서 동시에 읽어야 하는 경우입니다.

1단계: Hudi 테이블 생성 (PySpark)

# pyspark --packages org.apache.hudi:hudi-spark3.2-bundle_2.12:0.14.0

from pyspark.sql.types import *

table_name = "people"
base_path  = "s3://my-bucket/hudi-dataset"

records = [
    (1, 'Alice', 25, 'Seoul', '2024-01-01 00:00:00'),
    (2, 'Bob',   30, 'Busan', '2024-01-01 00:00:00'),
]
schema = StructType([
    StructField("id",        IntegerType(), True),
    StructField("name",      StringType(),  True),
    StructField("age",       IntegerType(), True),
    StructField("city",      StringType(),  True),
    StructField("create_ts", StringType(),  True),
])

df = spark.createDataFrame(records, schema)

hudi_options = {
    'hoodie.table.name': table_name,
    'hoodie.datasource.write.partitionpath.field': 'city',
    'hoodie.datasource.write.hive_style_partitioning': 'true',
}

df.write.format("hudi").options(**hudi_options).save(f"{base_path}/{table_name}")

2단계: XTable 동기화 설정 (my_config.yaml)

sourceFormat: HUDI
targetFormats:
  - DELTA
  - ICEBERG
datasets:
  - tableBasePath: s3://my-bucket/hudi-dataset/people
    tableName: people
    partitionSpec: city:VALUE

3단계: 동기화 실행

java -jar xtable-utilities_2.12-0.2.0-SNAPSHOT-bundled.jar \
  --datasetConfig my_config.yaml

실행 후 s3://my-bucket/hudi-dataset/people/ 아래에 _delta_log/와 metadata/ 디렉토리가 생성됩니다. 데이터 파일은 변경되지 않습니다.

예시 2: Delta → Iceberg 마이그레이션 (무중단)

기존 Delta Lake 테이블을 Iceberg로 전환 중이며, 전환 기간 동안 두 포맷을 모두 지원해야 하는 경우입니다.

sourceFormat: DELTA
targetFormats:
  - ICEBERG
datasets:
  - tableBasePath: s3://my-bucket/delta-dataset/sales
    tableName: 2024_sales
    partitionSpec: partitionpath:department

Dremio에서 Iceberg 테이블 등록

CALL dremio.system.register_table(
  table        => 'analytics.sales_2024',
  metadata_file => 's3://my-bucket/delta-dataset/sales/metadata/v1.metadata.json'
);

예시 3: 실시간 스트리밍 파이프라인 패턴

Hudi로 실시간 업서트를 수행하고, 다운스트림 소비는 Iceberg로 제공하는 패턴입니다.

[Kafka] → [Spark Structured Streaming] → [Hudi 쓰기 (low-latency upsert)]
                                                       ↓
                                        [XTable 증분 동기화 (스케줄 실행)]
                                                       ↓
                                          [Iceberg 메타데이터 생성]
                                                       ↓
                              [Snowflake / Dremio / AWS Athena 에서 읽기]

이 패턴을 통해 Hudi의 고속 수집 능력과 Iceberg의 넓은 쿼리 엔진 지원을 동시에 활용할 수 있습니다.

예시 4: Iceberg → Delta Lake 변환

Apache Iceberg로 운영 중인 테이블을 Databricks에서도 읽어야 하는 경우입니다. Iceberg를 Primary로 유지하면서 Delta Lake 메타데이터를 동기화합니다.

1단계: Iceberg 테이블 생성 (PySpark)

pyspark \
  --packages org.apache.iceberg:iceberg-spark-runtime-3.2_2.12:1.4.1 \
  --conf "spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions" \
  --conf "spark.sql.catalog.spark_catalog=org.apache.iceberg.spark.SparkSessionCatalog" \
  --conf "spark.sql.catalog.spark_catalog.type=hadoop" \
  --conf "spark.sql.catalog.spark_catalog.warehouse=s3://my-bucket/iceberg-warehouse"

from pyspark.sql.types import *

table_name = "orders"
warehouse  = "s3://my-bucket/iceberg-warehouse"

records = [
    (1001, 'Alice', 'laptop',   1200000, '2024-03-01'),
    (1002, 'Bob',   'monitor',   450000, '2024-03-01'),
    (1003, 'Carol', 'keyboard',   89000, '2024-03-02'),
]
schema = StructType([
    StructField("order_id",   IntegerType(), True),
    StructField("customer",   StringType(),  True),
    StructField("product",    StringType(),  True),
    StructField("amount",     IntegerType(), True),
    StructField("order_date", StringType(),  True),
])

df = spark.createDataFrame(records, schema)

df.write \
  .format("iceberg") \
  .partitionBy("order_date") \
  .saveAsTable(f"spark_catalog.default.{table_name}")

실행 후 s3://my-bucket/iceberg-warehouse/default/orders/ 아래에 metadata/와 data/가 생성됩니다.

2단계: XTable 동기화 설정 (my_config.yaml)

sourceFormat: ICEBERG
targetFormats:
  - DELTA
datasets:
  - tableBasePath: s3://my-bucket/iceberg-warehouse/default/orders
    tableDataPath: s3://my-bucket/iceberg-warehouse/default/orders/data
    tableName: orders

⚠️ tableDataPath 필수: Iceberg는 메타데이터(metadata/)와 데이터(data/) 디렉토리가 분리되어 있으므로 반드시 tableDataPath를 명시해야 합니다.

3단계: 동기화 실행

java -jar xtable-utilities_2.12-0.2.0-SNAPSHOT-bundled.jar \
  --datasetConfig my_config.yaml

실행 후 같은 경로에 _delta_log/가 추가됩니다. Parquet 데이터 파일은 변경되지 않습니다.

4단계: Databricks에서 Delta로 읽기

# Databricks 노트북에서 실행

# 방법 1: 경로 직접 지정
df = spark.read.format("delta").load(
    "s3://my-bucket/iceberg-warehouse/default/orders"
)
df.show()

# 방법 2: 테이블로 등록 후 SQL 사용
spark.sql("""
  CREATE TABLE IF NOT EXISTS orders_via_delta
  USING DELTA
  LOCATION 's3://my-bucket/iceberg-warehouse/default/orders'
""")

spark.sql("""
  SELECT * FROM orders_via_delta WHERE order_date = '2024-03-01'
""").show()

동일한 S3 경로에 Iceberg와 Delta 메타데이터가 공존하며, Parquet 파일은 하나만 존재합니다.

XTable 운영 가이드

XTable 자체는 단순한 CLI 도구이지만, 프로덕션 환경에서는 주기적 실행, 카탈로그 등록, 모니터링을 어떻게 설계할지가 중요합니다.

실행 모드

모드	방식	적합한 상황
일회성 실행	`java -jar xtable.jar --datasetConfig config.yaml`	초기 마이그레이션, 수동 테스트
스케줄 실행	cron / Airflow / EventBridge 등으로 주기 호출	배치성 파이프라인, 허용 지연이 분 단위 이상인 경우
연속 실행 (RunSync)	수집 태스크 직후 자동 트리거	수집 후 즉시 동기화가 필요한 스트리밍 파이프라인

운영 패턴 1: cron 스케줄 (가장 단순)

# crontab -e

# 15분마다 증분 동기화
*/15 * * * * java -jar /opt/xtable/xtable.jar \
  --datasetConfig /etc/xtable/config.yaml \
  >> /var/log/xtable/sync.log 2>&1

배치성 파이프라인이 실행되는 EMR, Dataproc 등의 워커 노드에 배포하는 가장 단순한 패턴입니다. 동기화 주기는 데이터 신선도 요구 수준에 맞춰 조정합니다.

운영 패턴 2: AWS Lambda + EventBridge (서버리스)

서버 관리 없이 자동화하는 권장 패턴입니다.

[EventBridge 스케줄 (1시간마다)]
          ↓
[Detector Lambda] → Glue Catalog 스캔
  (xtable_table_type, xtable_target_formats 태그 보유 테이블 탐지)
          ↓ 비동기 호출
[Converter Lambda × N개 테이블]
  각 테이블별로 XTable JAR 실행
          ↓
[S3에 Secondary 포맷 메타데이터 생성 + Glue Catalog 자동 등록]

Glue 테이블에 XTable 태그 설정 (테이블별 1회)

glue_client.update_table(
    DatabaseName='my_db',
    TableInput={
        'Name': 'orders',
        'Parameters': {
            'xtable_table_type':     'ICEBERG',   # Primary 포맷
            'xtable_target_formats': 'DELTA',     # 변환 대상
        }
    }
)

Detector Lambda가 Glue를 스캔하여 위 태그가 있는 테이블만 자동으로 변환합니다. 새 테이블 추가 시 태그만 달면 이후 자동 관리됩니다.

운영 패턴 3: Apache Airflow DAG

데이터 파이프라인이 Airflow로 관리되는 환경에서 XTable 동기화를 파이프라인에 통합하는 패턴입니다.

from airflow import DAG
from airflow.operators.bash import BashOperator
from datetime import datetime

with DAG(
    dag_id='xtable_sync',
    schedule_interval='*/30 * * * *',  # 30분마다
    start_date=datetime(2024, 1, 1),
    catchup=False,
) as dag:

    sync_orders = BashOperator(
        task_id='sync_orders_iceberg_to_delta',
        bash_command=(
            'java -jar /opt/xtable/xtable.jar '
            '--datasetConfig /opt/xtable/configs/orders.yaml'
        ),
    )

    sync_users = BashOperator(
        task_id='sync_users_hudi_to_iceberg',
        bash_command=(
            'java -jar /opt/xtable/xtable.jar '
            '--datasetConfig /opt/xtable/configs/users.yaml'
        ),
    )

    # 두 테이블은 독립적이므로 병렬 실행
    [sync_orders, sync_users]

수집(ingest) 태스크 다음에 XTable 동기화 태스크를 연결하면 수집 완료 후 즉시 동기화를 보장할 수 있습니다.

증분(Incremental) vs 전체(Full) 동기화

구분	동작	사용 시점
Incremental	마지막 동기화 이후 새 커밋만 처리	일반 운영 (기본값)
Full	전체 커밋 재처리	Incremental 실패 시 자동 폴백, 또는 테이블 재구성 시 수동 실행

XTable은 Incremental 실패 시 자동으로 Full로 폴백하므로 별도 예외 처리 코드가 필요하지 않습니다.

카탈로그 동기화 (CatalogSync)

XTable은 메타데이터 파일 생성 후 외부 카탈로그에 자동 등록하는 CatalogSync도 지원합니다.

카탈로그	지원 포맷	비고
AWS Glue	Iceberg, Delta, Hudi	`catalogImpl: glue` 설정
Hive Metastore	Iceberg, Delta, Hudi	HMS 주소 + `catalogImpl: hms` 설정
Unity Catalog	로드맵 예정	현재 미지원

카탈로그 동기화를 활성화하면 Athena, Spark SQL, Trino 등에서 수동 등록 없이 즉시 조회할 수 있습니다.

모니터링 포인트

S3에서 메타데이터 생성 확인

# Iceberg → Delta 동기화 후 Delta 메타데이터 존재 확인
aws s3 ls s3://my-bucket/iceberg-warehouse/default/orders/_delta_log/

# Hudi → Iceberg 동기화 후 Iceberg 메타데이터 확인
aws s3 ls s3://my-bucket/hudi-dataset/people/metadata/

주요 경보 조건

_delta_log/ 또는 metadata/가 예상 주기보다 오래 업데이트되지 않는 경우 → XTable 프로세스 상태 확인
Incremental 실패로 Full Sync 폴백이 반복되는 경우 → 커밋 히스토리 크기 및 실행 시간 검토
Primary 포맷 커밋 수와 Secondary 커밋 수의 차이가 커지는 경우 → 동기화 주기 조정

운영 시 주의사항

Secondary 포맷으로는 절대 쓰지 않습니다. XTable이 생성한 메타데이터를 외부 도구가 덮어쓰면 데이터 일관성이 깨집니다.
Full Sync 비용 관리: Full Sync는 커밋 수에 비례해 시간이 소요됩니다. 일반 운영은 Incremental로만 사용하고, Full은 장애 복구 시에만 수동 실행하는 것이 권장됩니다.
MoR 테이블 회피: Hudi/Iceberg의 Merge-on-Read 테이블은 XTable에서 지원하지 않습니다. CoW로 설정하거나 별도 전략을 검토하십시오.
첫 동기화 후 검증 필수: 변환된 포맷으로 실제 쿼리를 실행하여 데이터 정합성을 확인하는 절차를 반드시 거치십시오.

요약

Apache XTable은 데이터 레이크하우스의 포맷 파편화 문제를 메타데이터 변환만으로 해결하는 도구입니다.

항목	내용
핵심 가치	데이터 복사 없이 Hudi↔Iceberg↔Delta 상호 운용
동작 방식	Primary 포맷으로 쓰기 → XTable이 Secondary 포맷 메타데이터 생성
적합한 케이스	멀티 포맷 팀, 포맷 마이그레이션, 스트리밍+분석 혼합 환경
주의 사항	MoR 테이블, Delete Vectors, Generated Columns 미지원
대안	Delta Uniform(단방향), Iceberg Migrate, Dremio/Trino
현재 상태	Apache Software Foundation Incubating 프로젝트

언제 XTable을 선택해야 할까요?

조직 내 여러 팀이 서로 다른 레이크하우스 포맷을 사용하는 경우
포맷을 전환하면서도 다운타임 없이 기존 워크로드를 유지해야 하는 경우
Hudi로 수집하고 Iceberg/Delta로 분석하는 패턴이 필요한 경우
특정 벤더에 종속되지 않고 여러 플랫폼에서 동일한 데이터에 접근해야 하는 경우

[Spark] 스파크 Structured Streaming 정리

불곰1 — Sun, 26 Apr 2026 23:37:09 +0900

1. 개요

Spark Structured Streaming은 Apache Spark 2.0에서 도입되고 2.2에서 정식 안정화된 확장 가능한 스트림 처리 엔진입니다. 기존 배치 처리에서 사용하던 DataFrame/Dataset API를 그대로 스트리밍에 적용할 수 있어 "한 번 작성, 배치/스트리밍 모두 실행"이 가능합니다.

핵심 설계 철학: Unbounded Table 모델

스파크 Structured Streaming은 입력 데이터 스트림을 무한히 추가되는 테이블로 개념화합니다.

새로 도착하는 레코드 = 테이블에 추가되는 새 행(row)
이 입력 테이블에 대한 쿼리가 결과 테이블(Result Table) 을 생성
결과 테이블은 주기적으로 싱크(Sink)에 기록됨
이 추상화 덕분에 배치 쿼리와 완전히 동일한 로직으로 스트리밍 처리 가능

# 기본 예시: 소켓에서 단어 수 집계
spark = SparkSession.builder.appName("WordCount").getOrCreate()

lines = spark.readStream \
    .format("socket") \
    .option("host", "localhost") \
    .option("port", 9999) \
    .load()

wordCounts = lines.select(explode(split(lines.value, " ")).alias("word")) \
                  .groupBy("word").count()

query = wordCounts.writeStream \
    .outputMode("complete") \
    .format("console") \
    .start()

query.awaitTermination()

2. Spark Structured Streaming 장단점

장점

Unified Batch/Streaming API: 동일한 DataFrame/Dataset API로 배치와 스트리밍 코드를 작성할 수 있습니다. 기존 배치 파이프라인을 스트리밍으로 전환할 때 코드 변경이 최소화됩니다.
Exactly-Once 보장: 마이크로 배치 모드에서 end-to-end exactly-once 처리를 기본 제공합니다. Delta Lake와 조합 시 멱등 쓰기(idempotent write)로 중복 레코드를 방지할 수 있습니다.
Fault Tolerance (체크포인트): 체크포인트를 통한 자동 장애 복구를 지원합니다. 최근에는 changelog 기반 체크포인팅이 도입되어 전체 상태 스냅샷 대신 변경분만 저장해 I/O가 대폭 감소했습니다.
Catalyst Optimizer 활용: 스트리밍 쿼리에도 Catalyst 쿼리 최적화 엔진이 적용됩니다. 조건 푸시다운, 파티션 프루닝 등 배치 최적화 기법이 스트리밍에도 자동 적용됩니다.
Delta Lake 완벽 통합: Delta Lake를 소스/싱크로 직접 사용할 수 있습니다. ACID 트랜잭션, 스키마 진화, 타임 트래블 등 Lakehouse 기능을 풀로 활용할 수 있습니다.
높은 확장성: 수십~수백 노드 클러스터로 수평 확장이 가능하며, 안정 조건에서 초당 최대 100만 이벤트 처리를 달성할 수 있습니다.

단점

Micro-Batch 레이턴시: 기본 마이크로 배치 모델의 레이턴시는 수백 ms~수 초 수준으로, Flink의 ms급에 비해 불리합니다. 다만 2025년 12월 Spark 4.1에서 Real-Time Mode(RTM) 가 공개되어 p99 레이턴시 한 자릿수 ms가 달성되었습니다.
복잡한 Stateful 연산: mapGroupsWithState/flatMapGroupsWithState 사용 시 상태 스키마나 타임아웃 타입을 변경하면 기존 체크포인트가 무효화됩니다. 또한 shuffle.partitions 수를 스트림 시작 후에는 변경할 수 없습니다.
메모리 관리 복잡성: State Store가 메모리와 디스크 리소스를 점유하며, 상태 크기가 커질수록 GC 압박 및 지연이 증가합니다.
복잡한 Checkpoint 관리: 입력 소스 추가, Kafka 토픽 변경, stateful 연산 타입 변경 등이 발생하면 새 체크포인트가 필요합니다. 장기 운영 시 체크포인트 디렉토리 용량이 증가하여 주기적인 관리가 필요합니다.
운영 비용: 스트리밍 특성상 클러스터를 24/7 상시 운영해야 하므로 배치 대비 고정 비용이 높습니다.

Spark Structured Streaming vs Apache Flink

항목	Spark Structured Streaming	Apache Flink
처리 모델	마이크로 배치 (기본) / RTM(Spark 4.1+)	네이티브 이벤트 스트리밍
레이턴시	수백 ms ~ 수 초 (RTM: 단 자릿수 ms)	기본 ms 이하
Exactly-Once	기본 지원	기본 지원
Stateful 처리	제한적 (스키마 변경 불가)	강력 (세밀한 시간/상태 제어)
배치 통합	완전 통합 (Unified API)	별도 배치 API (제한적)
Lakehouse 통합	Delta Lake 완벽 통합	상대적으로 약함

선택 기준: 레이턴시 허용 + Lakehouse/배치 통합 필요 → Spark Structured Streaming / ms급 레이턴시 필수 + 복잡한 stateful 연산 → Apache Flink

3. 핵심 개념 및 내부 아키텍처

처리 모드

Micro-Batch (기본)

데이터를 시간 간격 또는 데이터 가용성에 따라 이산(discrete) 배치로 처리합니다. 드라이버가 매 배치마다 소스를 폴링하고 새 오프셋을 결정하여 플랜을 생성하고 실행합니다. end-to-end 레이턴시는 최소 ~100ms이며 exactly-once를 보장합니다.

Continuous Processing (Spark 2.3+)

레코드가 도착하는 즉시 처리하며, epoch 기반 체크포인팅을 사용합니다. 레이턴시는 ~1ms이지만 at-least-once만 보장하며, stateless 단순 변환(map, filter)만 지원합니다.

Real-Time Mode (Spark 4.1, 2025년 12월 출시)

마이크로 배치와 달리 처리 스테이지가 동시에 실행되며, 셔플 파일이 생성되는 즉시 리듀서가 시작됩니다. epoch 경계는 복구 북마크로만 사용되고, p99 레이턴시 한 자릿수 ms를 달성했습니다.

Trigger 모드

Trigger	구문	동작
Default	`.trigger()` 없음	이전 배치가 끝나는 즉시 새 배치 시작
ProcessingTime	`processingTime="2 seconds"`	고정 시간 간격 스케줄링
Once	`Trigger.Once()`	가용 데이터 처리 후 종료 (Deprecated)
AvailableNow	`availableNow=True`	가용 데이터를 증분 배치로 처리 후 종료
Continuous	`continuous="1 second"`	연속 처리, N초마다 체크포인트

4. Output Modes

결과 테이블의 어느 행이 싱크에 기록될지를 결정합니다.

모드	동작	사용 시기
Append (기본)	마지막 트리거 이후 새로 추가된 행만 기록	집계 없는 쿼리, 워터마크가 있는 집계
Update	마지막 트리거 이후 변경된 행만 기록	집계 (쓰기 볼륨 최소화)
Complete	전체 결과 테이블을 매 트리거마다 재기록	집계 (전체 상태가 항상 필요한 경우)

# Update 모드 예시
wordCounts.writeStream.outputMode("update").format("kafka") \
    .option("kafka.bootstrap.servers", "localhost:9092") \
    .option("topic", "output").start()

5. Watermarking과 Late Data 처리

이벤트는 네트워크 지연, 재시도 등으로 인해 순서가 뒤바뀌어 도착할 수 있습니다. Watermark 없이는 엔진이 모든 이벤트 타임 윈도우의 상태를 영구적으로 유지해야 하므로 메모리가 무한히 증가합니다.

동작 원리

withWatermark(이벤트 시간 컬럼, 지연 임계값) 으로 설정
엔진이 수신된 모든 이벤트에서 최대 이벤트 시간을 추적
워터마크 = 최대 이벤트 시간 - 임계값
이벤트 시간이 워터마크보다 이전인 데이터는 "너무 늦은 데이터"로 간주되어 드롭
워터마크를 지난 윈도우의 상태는 자동 정리

from pyspark.sql.functions import window

# 최대 10분까지 지연 도착을 허용
windowedCounts = events \
    .withWatermark("eventTime", "10 minutes") \
    .groupBy(
        window("eventTime", "10 minutes", "5 minutes"),  # 10분 윈도우, 5분 슬라이드
        "userId"
    ) \
    .count()

핵심 규칙: withWatermark는 반드시 groupBy 이전에 적용해야 합니다. 다중 스트리밍 소스가 있는 쿼리에서 전역 워터마크는 개별 소스 워터마크 중 최솟값으로 결정됩니다.

6. Stateful Operations (상태 기반 연산)

내장 Stateful 연산자

groupBy().count(), groupBy().agg() — 실행 집계
dropDuplicates() — 중복 제거
join() (스트림-스트림 조인) — 매칭을 위한 버퍼 상태

임의 상태 처리 (Arbitrary Stateful Processing)

mapGroupsWithState (Spark 2.2+)

그룹 키별 사용자 정의 상태를 유지하며, 트리거마다 그룹당 정확히 하나의 출력 행을 반환해야 합니다. 실행 중 총합, 고정 출력 형태의 세션 추적 등에 활용합니다.

flatMapGroupsWithState (Spark 2.2+)

mapGroupsWithState와 유사하지만 그룹당 0개 이상의 행을 반환할 수 있습니다. 세션 윈도우, 복잡 이벤트 처리(CEP) 등에 활용합니다.

transformWithState (Spark 4.0+ — 차세대 API)

mapGroupsWithState/flatMapGroupsWithState를 대체하는 차세대 API로, 객체 지향 방식의 StatefulProcessor 클래스를 구현합니다. ValueState, ListState, MapState 등 풍부한 상태 프리미티브와 TTL 기반 상태 소멸, 키별 다중 타이머, 스키마 진화를 지원합니다.

7. Sources & Sinks

주요 소스

소스	Format	주요 옵션
Kafka	`"kafka"`	`kafka.bootstrap.servers`, `subscribe`, `startingOffsets`
Delta Lake	`"delta"`	`path`, `maxFilesPerTrigger`, `ignoreChanges`
File	`"parquet"`, `"json"` 등	`path`, `maxFilesPerTrigger`
Rate	`"rate"`	`rowsPerSecond` (테스트용)

주요 싱크

싱크	Format	출력 모드
Kafka	`"kafka"`	Append, Update, Complete
Delta Lake	`"delta"`	Append, Complete
File	`"parquet"` 등	Append only
ForeachBatch	—	모두 지원 (가장 유연)

# ForeachBatch: 다중 싱크에 동시 쓰기
def write_to_multiple(batch_df, batch_id):
    batch_df.persist()
    batch_df.write.format("delta").mode("append").save("/delta/output")
    batch_df.write.format("jdbc").mode("append") \
        .option("url", "jdbc:postgresql://...").save()
    batch_df.unpersist()

df.writeStream.foreachBatch(write_to_multiple) \
    .option("checkpointLocation", "/checkpoints/multi") \
    .start()

8. Exactly-Once 보장 및 Fault Tolerance

Spark Structured Streaming은 세 가지 핵심 요소로 exactly-once를 보장합니다.

재생 가능한 소스(Replayable Sources): Kafka는 특정 오프셋부터, Delta Lake는 특정 트랜잭션 버전부터 데이터를 재생할 수 있습니다.
멱등 싱크(Idempotent Sinks): 동일 데이터를 여러 번 기록해도 결과가 같아야 합니다. 파일 싱크는 원자적 파일 생성(임시 파일 → 이름 변경)으로, Delta Lake는 트랜잭션 로그로 이를 보장합니다.
체크포인팅 + Write-Ahead Log(WAL): 오프셋 로그(소스에서 읽은 위치), 커밋 로그(싱크에 완전히 커밋된 배치), 상태 스토어(집계·조인 상태)를 체크포인트에 저장합니다.

query = df.writeStream \
    .format("delta") \
    .option("checkpointLocation", "/checkpoints/my-query") \  # 필수
    .start("/delta/output")

장애 복구 흐름

장애 감지 → 체크포인트에서 쿼리 재시작 → 마지막 커밋 오프셋부터 소스 재생 → 변환 재실행 → 멱등 싱크에 기록

9. Spark Structured Streaming vs DStream (레거시)

항목	DStream (Spark Streaming)	Structured Streaming
API	RDD 기반 (`DStream[T]`)	DataFrame/Dataset API
도입	Spark 0.7	Spark 2.0 (안정 2.2)
상태	Deprecated	현행 권장
최적화	없음 (수동 RDD 연산)	Catalyst + Tungsten
Event-Time	미지원	기본 지원
Watermarking	없음	`withWatermark()` 내장
보장 수준	At-least-once	Exactly-once (마이크로 배치)
최소 레이턴시	~500ms	~100ms (마이크로 배치) / ~1ms (연속 처리)
스트림-스트림 조인	미지원	기본 지원

10. EMR에서 사용 예시

배포 방식 선택

방식	장점	단점	권장 시나리오
EMR on EC2	Spot 활용 최대화, 세밀한 제어	클러스터 관리 부담	대용량 안정 워크로드, 비용 최적화 최우선
EMR on EKS	K8s 환경 통합, 멀티 테넌시	K8s 운영 지식 필요	EKS 인프라를 이미 보유한 팀
EMR Serverless	인프라 Zero, 자동 스케일	콜드 스타트, 일부 제약	빠른 도입, 예측 불가 워크로드

EMR Serverless 클러스터 생성 및 잡 제출

# 1단계: EMR Serverless Application 생성
aws emr-serverless create-application \
  --name "streaming-app" \
  --type SPARK \
  --release-label emr-7.2.0 \
  --initial-capacity '{
    "DRIVER": {"workerCount": 1, "workerConfiguration": {"cpu": "4vCPU", "memory": "16GB"}},
    "EXECUTOR": {"workerCount": 10, "workerConfiguration": {"cpu": "4vCPU", "memory": "16GB"}}
  }'

# 2단계: STREAMING 모드로 잡 제출
aws emr-serverless start-job-run \
  --application-id <APPLICATION_ID> \
  --execution-role-arn arn:aws:iam::ACCOUNT_ID:role/EMRServerlessRole \
  --mode 'STREAMING' \
  --job-driver '{
    "sparkSubmit": {
      "entryPoint": "s3://my-bucket/scripts/kafka_to_s3.py",
      "sparkSubmitParameters": "--packages org.apache.spark:spark-sql-kafka-0-10_2.12:3.5.1,software.amazon.msk:aws-msk-iam-auth:2.2.0"
    }
  }' \
  --retry-policy '{"maxFailedAttemptsPerHour": 5}'

MSK Kafka → S3 파이프라인 (PySpark)

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, from_json, year, month, dayofmonth
from pyspark.sql.types import *

spark = SparkSession.builder.appName("KafkaToS3").getOrCreate()

schema = StructType([
    StructField("order_id", StringType(), True),
    StructField("customer_id", StringType(), True),
    StructField("amount", DoubleType(), True),
    StructField("event_time", TimestampType(), True),
])

# MSK Kafka 소스 (IAM 인증)
raw_df = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "<MSK_BOOTSTRAP>:9098") \
    .option("subscribe", "orders") \
    .option("kafka.security.protocol", "SASL_SSL") \
    .option("kafka.sasl.mechanism", "AWS_MSK_IAM") \
    .option("kafka.sasl.jaas.config",
            "software.amazon.msk.auth.iam.IAMLoginModule required;") \
    .option("kafka.sasl.client.callback.handler.class",
            "software.amazon.msk.auth.iam.IAMClientCallbackHandler") \
    .load()

parsed_df = raw_df \
    .select(from_json(col("value").cast("string"), schema).alias("data")) \
    .select("data.*") \
    .withWatermark("event_time", "10 minutes") \
    .withColumn("year", year("event_time")) \
    .withColumn("month", month("event_time")) \
    .withColumn("day", dayofmonth("event_time"))

query = parsed_df.writeStream \
    .format("parquet") \
    .option("path", "s3://my-bucket/output/") \
    .option("checkpointLocation", "s3://my-bucket/checkpoints/") \
    .partitionBy("year", "month", "day") \
    .trigger(processingTime="5 minutes") \
    .start()

query.awaitTermination()

Kinesis Data Streams 연동

EMR 7.1.0부터 Kinesis Connector가 릴리즈 이미지에 내장되어 별도 JAR가 필요 없습니다. GetRecords(공유 처리량)와 SubscribeToShard(Enhanced Fan-Out, 저지연 전용 처리량) 두 가지 모드를 지원합니다.

kinesis_df = spark.readStream \
    .format("aws-kinesis") \
    .option("kinesis.region", "ap-northeast-2") \
    .option("kinesis.streamName", "sensor-data-stream") \
    .option("kinesis.consumerType", "GetRecords") \
    .option("kinesis.startingposition", "LATEST") \
    .load()

AWS 서비스 통합 요약

AWS 서비스	연동 방식
MSK (Kafka)	spark-sql-kafka + aws-msk-iam-auth JAR, IAM 인증
Kinesis Data Streams	aws-kinesis 커넥터 (EMR 7.1+ 내장)
S3	EMRFS(S3A 내장), `s3://` 경로 직접 사용
Glue Data Catalog	Hive Metastore Factory Class 설정

모니터링: CloudWatch 연동

from pyspark.sql.streaming import StreamingQueryListener
import boto3

class CloudWatchListener(StreamingQueryListener):
    def __init__(self):
        self.cw = boto3.client("cloudwatch", region_name="ap-northeast-2")

    def onQueryProgress(self, event):
        progress = event.progress
        self.cw.put_metric_data(
            Namespace="SparkStreaming/Production",
            MetricData=[
                {"MetricName": "InputRowsPerSecond",
                 "Value": progress.inputRowsPerSecond or 0,
                 "Unit": "Count/Second",
                 "Dimensions": [{"Name": "JobName", "Value": "kafka-to-s3"}]},
            ]
        )
    def onQueryStarted(self, event): pass
    def onQueryTerminated(self, event): pass

spark.streams.addListener(CloudWatchListener())

11. Dataproc에서 사용 예시

클러스터 생성

gcloud dataproc clusters create my-streaming-cluster \
  --region=us-central1 \
  --master-machine-type=n2-standard-4 \
  --num-workers=4 \
  --worker-machine-type=n2-standard-4 \
  --image-version=2.2-debian12 \
  --enable-component-gateway \
  --metric-sources=spark \
  --properties="spark:spark.streaming.stopGracefullyOnShutdown=true" \
  --project=my-project

주의: Dataproc의 Autoscaling은 Spark Structured Streaming을 지원하지 않습니다. 스트리밍 클러스터에서는 autoscaling 없이 고정 클러스터를 운영하는 것이 권장됩니다.

Managed Kafka → BigQuery 파이프라인 (PySpark)

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, from_json, current_timestamp
from pyspark.sql.types import *

spark = SparkSession.builder.appName("KafkaToBigQuery").getOrCreate()

schema = StructType([
    StructField("user_id", StringType(), True),
    StructField("event_type", StringType(), True),
    StructField("amount", DoubleType(), True),
    StructField("event_time", LongType(), True),
])

raw_df = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers",
            "bootstrap.CLUSTER_ID.us-central1.managedkafka.PROJECT.cloud:9092") \
    .option("kafka.security.protocol", "SASL_SSL") \
    .option("kafka.sasl.mechanism", "OAUTHBEARER") \
    .option("subscribe", "user-events") \
    .option("startingOffsets", "latest") \
    .load()

parsed_df = raw_df \
    .select(from_json(col("value").cast("string"), schema).alias("data")) \
    .select("data.*") \
    .withColumn("ingested_at", current_timestamp())

def write_to_bigquery(batch_df, epoch_id):
    batch_df.write \
        .format("bigquery") \
        .option("writeMethod", "direct") \
        .option("table", "my-project.analytics.events") \
        .mode("append") \
        .save()

query = parsed_df.writeStream \
    .foreachBatch(write_to_bigquery) \
    .option("checkpointLocation", "gs://my-bucket/checkpoints/kafka-to-bq") \
    .trigger(processingTime="30 seconds") \
    .start()

query.awaitTermination()

GCS에 Parquet으로 쓰기

query = df.writeStream \
    .format("parquet") \
    .outputMode("append") \
    .option("path", "gs://my-bucket/data/events/") \
    .option("checkpointLocation", "gs://my-bucket/checkpoints/gcs-parquet") \
    .trigger(processingTime="5 minutes") \
    .partitionBy("process_date", "process_hour") \
    .start()

GCP 서비스 통합 요약

GCP 서비스	연동 방식	비고
Managed Kafka	표준 Kafka 커넥터, OAUTHBEARER 인증	Pub/Sub Lite 대체 권장 (2026년 종료 예정)
BigQuery	spark-bigquery-connector, `writeMethod=direct`	Dataproc 2.1+ 내장
GCS	`gs://` 경로 직접 사용	체크포인트/싱크 모두 지원
Bigtable	spark-bigtable-connector (v1.1+)	Data Boost로 분석 부하 분리 가능

잡 제출

gcloud dataproc jobs submit pyspark gs://my-bucket/jobs/streaming.py \
  --cluster=my-streaming-cluster \
  --region=us-central1 \
  --packages=org.apache.spark:spark-sql-kafka-0-10_2.12:3.5.0 \
  --properties=spark.executor.memory=4g,spark.executor.cores=2,spark.executor.instances=8

12. 데이터브릭스에서 사용 예시

DLT vs 일반 Structured Streaming 선택 기준

Structured Streaming 권장	Delta Live Tables (DLT) 권장
foreachBatch로 외부 DB 쓰기	멀티-스테이지 ETL 파이프라인
세밀한 클러스터 제어 필요	데이터 품질 거버넌스 필요
SLA-민감 레이턴시 파이프라인	자동 체크포인트·스케일링 필요
특수 소스/싱크 필요	Unity Catalog 기반 거버넌스

Auto Loader (cloudFiles)

Auto Loader는 S3, ADLS, GCS에 새로 도착하는 파일을 자동으로 감지하여 점진적으로 처리하는 Databricks 전용 Structured Streaming 소스입니다. 시간당 수백만 개 파일 처리가 가능하며, Directory Listing Mode(기본)와 File Notification Mode(대규모 권장) 두 가지를 지원합니다.

# Auto Loader: S3 JSON → Delta Lake
streaming_df = (
    spark.readStream
        .format("cloudFiles")
        .option("cloudFiles.format", "json")
        .option("cloudFiles.schemaLocation", "s3://my-bucket/checkpoints/schema/")
        .option("cloudFiles.inferColumnTypes", "true")
        .option("recursiveFileLookup", "true")
        .load("s3://my-bucket/raw/events/")
)

query = (
    streaming_df.writeStream
        .format("delta")
        .outputMode("append")
        .option("checkpointLocation", "s3://my-bucket/checkpoints/events/")
        .option("mergeSchema", "true")
        .trigger(processingTime="30 seconds")
        .toTable("catalog.bronze.raw_events")
)

Kafka → Delta Lake 파이프라인 (전체 예시)

from pyspark.sql.functions import from_json, col, current_timestamp
from pyspark.sql.types import *

event_schema = StructType([
    StructField("order_id", StringType(), False),
    StructField("user_id", StringType(), True),
    StructField("price", StringType(), True),
    StructField("event_time", TimestampType(), True),
])

kafka_options = {
    "kafka.bootstrap.servers": "kafka-broker:9092",
    "subscribe": "orders-topic",
    "startingOffsets": "latest",
    "kafka.security.protocol": "SASL_SSL",
    "kafka.sasl.mechanism": "PLAIN",
    # Databricks Secret 사용 (하드코딩 금지)
    "kafka.sasl.jaas.config": (
        "kafkashaded.org.apache.kafka.common.security.plain.PlainLoginModule required "
        f"username='{dbutils.secrets.get('kafka', 'username')}' "
        f"password='{dbutils.secrets.get('kafka', 'password')}'; "
    ),
    "maxOffsetsPerTrigger": "50000",
    "failOnDataLoss": "false",
}

raw_kafka_df = spark.readStream.format("kafka").options(**kafka_options).load()

parsed_df = (
    raw_kafka_df
        .select(from_json(col("value").cast("string"), event_schema).alias("data"),
                col("offset"), col("timestamp").alias("kafka_timestamp"))
        .select("data.*", "offset", "kafka_timestamp", current_timestamp().alias("ingested_at"))
        .filter(col("order_id").isNotNull())
)

query = (
    parsed_df.writeStream
        .format("delta")
        .outputMode("append")
        .option("checkpointLocation", "s3://my-bucket/checkpoints/kafka-orders/")
        .option("mergeSchema", "true")
        .trigger(processingTime="10 seconds")
        .toTable("catalog.bronze.orders_raw")
)

Delta MERGE INTO (Upsert / CDC)

def upsert_to_delta(micro_batch_df, batch_id):
    micro_batch_df.createOrReplaceTempView("batch_updates")
    micro_batch_df.sparkSession.sql("""
        MERGE INTO catalog.silver.customers AS target
        USING (
            SELECT * FROM (
                SELECT *, ROW_NUMBER() OVER (PARTITION BY customer_id ORDER BY updated_at DESC) AS rn
                FROM batch_updates
            ) WHERE rn = 1
        ) AS source
        ON target.customer_id = source.customer_id
        WHEN MATCHED AND source.op = 'D' THEN DELETE
        WHEN MATCHED THEN UPDATE SET *
        WHEN NOT MATCHED AND source.op != 'D' THEN INSERT *
    """)

spark.readStream.table("catalog.bronze.customer_cdc") \
    .writeStream \
    .foreachBatch(upsert_to_delta) \
    .option("checkpointLocation", "s3://my-bucket/checkpoints/customers/") \
    .trigger(processingTime="2 minutes") \
    .start()

Delta Live Tables (DLT) 파이프라인

import dlt
from pyspark.sql.functions import col, current_timestamp

# Bronze: 원본 인제스트
@dlt.table(name="bronze_orders", comment="Auto Loader로 S3에서 수집한 원본 주문 데이터")
def bronze_orders():
    return (
        spark.readStream.format("cloudFiles")
            .option("cloudFiles.format", "json")
            .option("cloudFiles.schemaLocation", "/pipelines/bronze_orders/schema")
            .load("s3://my-bucket/raw/orders/")
            .withColumn("_ingested_at", current_timestamp())
    )

# Silver: 정제 + 품질 검증
@dlt.table(name="silver_orders")
@dlt.expect("order_id_not_null", "order_id IS NOT NULL")
@dlt.expect_or_drop("valid_amount", "amount > 0")
@dlt.expect_or_fail("valid_event", "event_type IN ('CREATE', 'UPDATE', 'CANCEL')")
def silver_orders():
    return (
        dlt.read_stream("bronze_orders")
            .withColumn("amount", col("amount").cast("decimal(18,2)"))
            .withColumn("event_date", col("event_time").cast("date"))
    )

# Gold: 집계
@dlt.table(name="gold_daily_revenue")
def gold_daily_revenue():
    return (
        dlt.read("silver_orders")
            .filter(col("event_type") == "CREATE")
            .groupBy("event_date")
            .agg({"amount": "sum", "order_id": "count"})
    )

비용 최적화 전략

전략	효과	방법
Job Cluster 사용	유휴 비용 제거	All-purpose 대신 Job Cluster로 실행
Spot Instances	최대 80% 절감	Worker 노드에 Spot 적용, Driver는 On-demand
`availableNow` Trigger	배치화로 비용 최소화	연속 스트리밍 대신 주기적 실행 후 자동 종료
DLT Enhanced Autoscaling	부하에 따라 자동 축소	DLT 파이프라인 설정에서 활성화

# availableNow: 배치 패턴으로 비용 최적화
query = (
    spark.readStream.format("cloudFiles").option("cloudFiles.format", "parquet")
        .load("s3://my-bucket/raw/")
    .writeStream.format("delta")
        .option("checkpointLocation", "/checkpoints/batch/")
        .trigger(availableNow=True)  # 처리 완료 후 자동 종료 → 클러스터 자동 종료
        .toTable("catalog.silver.processed")
)
query.awaitTermination()

권장 런타임: Databricks Runtime 17.3 LTS (현재 최신 LTS, 2025.10 출시). 프로덕션 스트리밍에는 LTS 버전 사용을 강력 권장합니다.