ClickHouse at Seoul (Druid Meetup)

발표 주제

Helmar(ClickHouse 소속)이 오픈소스와 ClickHouse가 데이터 웨어하우스 시장을 어떻게 재정의하고 있는지에 대해 발표.

주요 초점은 데이터 웨어하우징, 데이터 레이크, 실시간 분석 DB의 장단점과 결합 방식.

1. 데이터 웨어하우스의 역사와 한계

• 30년 전부터 전통적 데이터 웨어하우스(Oracle, Teradata, IBM 등) 사용.
• 클라우드 시대에 Snowflake, BigQuery 등이 등장 → 접근성 향상, 확장성과 SQL 지원.
• 한계점
• 벤더 락인
• 실시간 처리 및 고동시성 처리 부적합
• 빠른 응답 속도 확보 시 비용 급증

2. 데이터 레이크의 등장과 발전

• Hadoop → Hive → 최신 오픈 테이블 포맷(Parquet, Iceberg, Delta Lake, Hudi).
• Iceberg가 사실상 표준으로 자리잡는 분위기.
• 장점: 오픈 포맷, 다양한 쿼리 엔진 접근 가능.
• 단점: 성능(특히 읽기 속도)과 동시성에서 한계, 다단계 메타데이터 접근 지연.

3. 실시간 분석 DB (ClickHouse)

• 특징
• 2009년 Yandex에서 개발, 2016년 Apache 2.0 오픈소스 공개.
• 컬럼 지향 OLAP DB, 분산 아키텍처, 고속 쿼리/압축.
• Append-only 구조지만 최근에는 트랜잭션 기반 업데이트 지원.
• 높은 동시성 처리, 스트리밍 데이터(Kafka 등) 실시간 수집 최적화.
• 성능 비교
• Snowflake 대비 3~5배 적은 컴퓨팅, 38배 더 효율적인 압축, 2배 속도.
• 비용 절감 효과 평균 4.7배.

4. 데이터 레이크와 실시간 분석 DB의 결합

• Lambda 아키텍처 접근:
• 빠른 실시간 경로(ClickHouse) + 대용량 이력 데이터 경로(Data Lake)
• 또는 Data Lake를 중심에 두고 ClickHouse를 속도 레이어로 활용:
• Data Lake에서 일부 데이터를 ClickHouse로 적재하여 빠른 쿼리 제공.
• ClickHouse에서 집계 결과를 다시 Data Lake에 저장 가능.
• 이유:
• Data Lake 읽기 속도는 ClickHouse 대비 2~14배 느림.
• ClickHouse는 동시 인서트와 쿼리에 최적화.

5. ClickHouse 배포 및 사용

• 설치 용이: 로컬, 분산 서버, Python 패키지, 클라우드 서비스(ClickHouse Cloud).
• 다양한 데이터 소스 연동: S3, Iceberg, Hudi, Glue 등.
• AI Copilot 기능: 자연어 → SQL 변환.
• 내장 모니터링/로그 기능 제공.

6. 결론

• 데이터 웨어하우스: 안정적, SQL 친화적이지만 비용·실시간성 한계.
• 데이터 레이크: 개방성과 호환성 장점, 성능 한계.
• 실시간 분석 DB: 빠른 응답·저비용, 하지만 단독으로는 부족할 수 있음.
• 전략:
• 인터랙티브·실시간 워크로드 → ClickHouse로.
• 대규모 비정기 데이터 → Data Lake로.
• 두 기술을 조합해 성능·비용·호환성을 모두 확보.