발표 주제
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로.
- 두 기술을 조합해 성능·비용·호환성을 모두 확보.