ClickHouse 면접 단골 질문 모음
ClickHouse 공식 문서(clickhouse.com/docs) 및 기술 블로그 종합 — MergeTree부터 분산 아키텍처까지 (웹 리서치, 2026) — ClickHouse 공식 문서 + Altinity/Tinybird 등 기술 블로그 교차 확인
이 모듈을 다 읽으면
- 면접에서 반복적으로 나오는 ClickHouse 핵심 질문에 짧고 정확하게 답할 수 있다
- 각 질문의 답이 이 카테고리의 어느 심화 모듈과 연결되는지 알아 필요하면 더 깊이 파고들 수 있다
이 카테고리의 1~7번 모듈에서 다룬 내용을 전제로, 실제 면접에서 반복적으로 나오는 질문만 뽑아 짧고 정확한 모범답안 형태로 재구성했다.
Q. ClickHouse는 왜 이렇게 빠른가?
핵심은 컬럼 지향 저장이다. 분석 쿼리는 보통 전체 컬럼 중 일부만 필요로 하는데, 컬럼 지향 저장은 그 필요한 컬럼만 순차적으로 읽고 나머지는 아예 디스크에서 안 건드린다. 여기에 같은 타입의 값이 연속으로 모여 있어 압축률이 높고(I/O가 더 줄어듦), 희소 프라이머리 인덱스로 불필요한 그래뉼을 통째로 건너뛰며, 벡터화된 쿼리 실행 엔진이 컬럼 단위로 CPU 연산을 배치 처리한다(clickhouse-learn-01, 03 참고).
핵심 포인트
- 컬럼 지향 저장(필요한 컬럼만 I/O) + 높은 압축률 + 희소 인덱스의 그래뉼 스킵 + 벡터화 실행
Q. ORDER BY와 PARTITION BY는 어떻게 다른가?
ORDER BY(프라이머리 키를 겸함)는 각 파트 내부의 물리적 정렬 순서를 정해 압축·쿼리 가속에 쓰인다. PARTITION BY는 정렬과 무관하게 데이터를 관리 단위(보통 시간 단위)로 나누는 것으로, 가장 중요한 실무 규칙은 '병합이 파티션 경계를 못 넘는다'는 것이다 — 파티션을 고카디널리티 키로 잘게 나누면 병합이 안 일어나 파트가 쌓인다(clickhouse-learn-03 참고).
핵심 포인트
- ORDER BY = 파트 내 정렬(쿼리 가속), PARTITION BY = 관리 단위 분리(병합은 파티션 내부로 국한)
Q. ReplacingMergeTree로 중복 제거했는데 SELECT하면 중복이 그대로 보인다. 왜?
ReplacingMergeTree의 중복 제거는 파트가 실제로 백그라운드 병합될 때만 일어나고, 병합 시점은 예측 불가능하다. 방금 INSERT한 중복 데이터는 아직 병합 전이라 그대로 보일 수 있다. 즉시 최신값만 보려면 SELECT ... FINAL을 쓰되, 대용량에서는 쿼리가 느려질 수 있다는 트레이드오프를 감안해야 한다(clickhouse-learn-04 참고).
핵심 포인트
- 중복 제거는 병합 시점에만 일어남(예측 불가) — 즉시 필요하면 FINAL, 단 느려질 수 있음
Q. ClickHouse의 Materialized View는 일반 RDB 뷰와 뭐가 다른가?
일반 뷰는 조회 시점에 쿼리를 즉석 실행하지만, ClickHouse의 Materialized View는 원본 테이블에 INSERT가 일어날 때 그 새 데이터에 대해서만 변환/집계를 실행해 대상 테이블에 저장하는 'INSERT 트리거'다. 그래서 생성 시점 이전의 과거 데이터는 자동으로 반영되지 않고, 별도 백필이 필요하다(clickhouse-learn-05 참고).
핵심 포인트
- 일반 뷰=조회 시 즉석 실행, ClickHouse MV=INSERT 시 트리거 실행 — 과거 데이터는 자동 소급 안 됨
Q. 'Too many parts' 에러는 왜 나고 어떻게 막는가?
작고 잦은 동기 INSERT나 고카디널리티 파티션 키 때문에 파트가 병합 속도보다 빠르게 쌓이면 발생한다. 예방책은 배치를 크게(최소 1,000행, 이상적으로 1만~10만행) 묶어 드물게(초당 약 1회 수준) INSERT하는 것이다(clickhouse-learn-03, 07 참고).
핵심 포인트
- 잦고 작은 INSERT나 고카디널리티 파티션이 원인 — 큰 배치로 드물게 INSERT하는 게 예방책
Q. Distributed 테이블은 실제로 어디에 데이터를 저장하는가?
Distributed 테이블 자체는 데이터를 저장하지 않는다 — 각 샤드 노드의 로컬 MergeTree 테이블에 실제 데이터가 있고, Distributed 테이블은 그 샤드들의 주소를 알고 쿼리를 팬아웃/병합해주는 라우팅 계층일 뿐이다(clickhouse-learn-06 참고).
핵심 포인트
- Distributed 테이블 = 라우팅 계층(데이터 없음), 실제 데이터는 각 샤드의 로컬 테이블에 있다