공부/데이터 2026. 4. 29. 22:43

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 기여자 팀 운영
오픈소스 통제권 + 관리형 편의성을 동시에 원하는 팀에 적합

ABOUT ME