ClickHouse Certified Developer

ClickHouse 데이터 모델링, 적재, 분석 쿼리, 성능 최적화, 중복 제거와 뮤테이션을 다루는 개발자 실습 자격증

실전은 객관식이 아니라 실습형이에요. 과제를 읽고 SQL 을 직접 써서 채점받는 모의시험이 있어요. 12개 과제, 120분.

시험 정보

시험 버전	ClickHouse Certified Developer (2024-05 출시)
문항 / 시간	12과제, 120분
합격 기준	70%
형식	실습형 (HackerRank 환경에서 10~12개 과제를 직접 수행, AI 감독, 영어). 이 사이트에는 같은 형식의 실습형 모의시험(SQL 직접 작성, 12과제)과 개념 확인용 객관식 25문항이 있습니다. 실습형 모의시험 →
확인 시점	2026-10 기준. 응시 전에 공식 시험 가이드를 다시 확인하세요.

출제 영역과 내 정답률

데이터 모델링24%아직 안 풀었어요

데이터 적재24%아직 안 풀었어요

데이터 분석19%아직 안 풀었어요

쿼리 성능 최적화19%아직 안 풀었어요

중복 제거와 뮤테이션14%아직 안 풀었어요

문제 미리보기

정답과 해설은 문제지를 받아 풀어 보면 나와요.

1. 웹 로그 테이블의 쿼리는 대부분 특정 사이트(site_id)의 최근 며칠 치 이벤트를 시간 범위로 조회한다. site_id 는 수백 개, event_time 은 초 단위 타임스탬프이다. MergeTree 테이블의 ORDER BY 로 가장 적절한 것은?

① ORDER BY (site_id, event_time)
② ORDER BY (event_time, site_id)
③ ORDER BY user_id
④ ORDER BY toYYYYMM(event_time)

2. 다음 테이블 정의에 대한 설명으로 옳은 것은?

CREATE TABLE api_log
(
    tenant_id   UInt32,
    event_time  DateTime,
    request_id  UUID,
    status      UInt16,
    latency_ms  UInt32
)
ENGINE = MergeTree
ORDER BY (tenant_id, event_time, request_id)
PRIMARY KEY (tenant_id, event_time);

① PRIMARY KEY 는 ORDER BY 의 접두사여야 하며, request_id 는 정렬에만 쓰이고 기본 인덱스(마크)에는 들어가지 않아 메모리에 올리는 인덱스 크기가 줄어든다
② PRIMARY KEY 가 유일성을 강제하므로 같은 (tenant_id, event_time) 조합을 두 번 넣으면 INSERT 가 실패한다
③ ORDER BY 와 PRIMARY KEY 가 다르면 MergeTree 는 테이블 생성 자체를 거부한다
④ PRIMARY KEY 를 따로 적으면 ORDER BY 는 무시되고 PRIMARY KEY 순서로만 데이터가 저장된다

3. 한 개발자가 수백만 명의 사용자를 가진 이벤트 테이블에서 사용자별 조회가 빨라질 것이라 기대하며 PARTITION BY user_id 로 테이블을 만들었다. 운영에서 가장 먼저 나타날 문제는?

① INSERT 한 번에 수많은 파티션의 파트가 생겨 Too many partitions 오류와 Too many parts 경고가 나고, 머지와 메타데이터 부담이 급격히 커진다
② 파티션 수에는 제한이 없으므로 아무 문제 없이 동작하며 조회도 빨라진다
③ 파티션 키는 TTL 에만 쓰이므로 쿼리 성능과 무관하게 데이터만 많이 차지한다
④ PARTITION BY 를 지정하면 기본 인덱스가 만들어지지 않아 모든 쿼리가 전체 스캔이 된다

모의고사 기록

아직 본 모의고사가 없어요. 실전처럼 시간 재고 풀어 봐요.