2장. 내부 컴포넌트와 쿼리 처리

SELECT 한 줄이 결과가 되기까지 — Parser, Interpreter, Processor, Block이라는 부품들이 조립 라인처럼 맞물리는 과정을 따라갑니다.

2.1 조감도 — 쿼리 하나가 통과하는 파이프라인

ClickHouse 내부를 이해하는 가장 좋은 방법은 쿼리 하나를 끝까지 따라가 보는 것입니다. 이 장 전체에서 아래 쿼리를 예시로 사용합니다.

SELECT event_type, max(amount)
FROM user_events
WHERE user_id = 123
GROUP BY event_type;

2.2 데이터 표현의 4총사 — IColumn · Field · IDataType · Block

파이프라인 속을 흐르는 데이터는 네 가지 자료구조로 표현됩니다.

IColumn의 대표 연산이 그대로 SQL 절과 대응된다는 점이 재미있습니다.

// IColumn의 연산 = SQL 절의 구현체
IColumn::filter(mask)    // WHERE / HAVING
IColumn::permute(perm)   // ORDER BY
IColumn::cut(start, n)   // LIMIT

// 정수 컬럼은 연속 배열 → SIMD를 바로 적용 가능
// ColumnString은 데이터 벡터 + 오프셋 벡터의 2중 구조

2.3 Parser와 Interpreter — 문자열에서 실행 계획으로

ClickHouse의 파서는 손으로 작성한 재귀 하강 파서(hand-written recursive descent parser)입니다. yacc나 ANTLR 같은 파서 생성기를 쓰지 않는 덕에, 에러 메시지를 세밀하게 제어하고 독자적 SQL 확장을 유연하게 추가할 수 있습니다.

Interpreter는 AST를 받아 QueryPipeline을 만듭니다. 파이프라인에는 세 가지 모드가 있습니다.

쿼리 분석·변환을 담당하던 ExpressionAnalyzer는 공식 문서 스스로 "quite messy and should be rewritten"이라 평가할 만큼 복잡해졌고, 이를 대체하기 위해 AST와 파이프라인 사이에 QueryTree라는 추상화 레이어를 둔 새 분석기가 도입됐습니다. enable_analyzer 설정으로 제어하며 기본값은 true입니다.

-- 새 분석기(QueryTree 기반) 활성화 여부 확인
SELECT name, value FROM system.settings WHERE name = 'enable_analyzer';

-- 동작 차이가 의심되면 쿼리 단위로 끄고 비교 가능
SELECT ... SETTINGS enable_analyzer = 0;

2.4 Processor DAG — 멀티코어를 채우는 병렬 실행

Processor는 포트(port)로 서로 연결되어 Block을 소비하고 생산하는 실행 단위입니다. 테이블의 read 메서드가 Processor를 여러 개 반환하면, 이들이 서로 다른 파트를 병렬로 읽습니다. 이것이 ClickHouse가 쿼리 하나로 모든 코어를 채우는 메커니즘입니다.

2.5 Functions — 강타입, 그리고 short-circuit이 없는 세계

일반 함수(ordinary functions)는 행 수를 바꾸지 않고 Block 단위로 벡터화 실행됩니다. 두 가지 특성에 주의해야 합니다.

• 강타입(Strong Typing): 암묵적 타입 변환이 없습니다. 지원하지 않는 타입 조합이면 예외를 던지며, 대신 plus 함수처럼 수많은 타입 조합의 오버로드를 제공합니다.
• Short-circuit 평가 없음: WHERE f(x) AND g(y)에서 f(x)가 false여도 g(y)가 계산됩니다.

한편 집계 함수(aggregate functions)는 상태를 가지는(stateful) 함수입니다. count의 상태는 UInt64 하나지만, uniqCombined는 선형 배열 + 해시 테이블 + HyperLogLog의 조합입니다. 고카디널리티 GROUP BY에서는 수많은 상태를 Arena(메모리 풀)에서 할당하고, 분산 쿼리에서는 이 상태를 직렬화해 네트워크로 전송합니다. 집계 상태를 테이블에 저장하는 AggregatingMergeTree의 증분 집계가 이 직렬화 위에 서 있습니다.

2.6 IStorage와 I/O — 테이블 엔진의 경계

테이블은 IStorage 인터페이스로 표현되고, 그 구현체가 곧 테이블 엔진입니다(StorageMergeTree, StorageMemory, StorageDistributed…). 설계 원칙은 명확합니다 — read()는 지정된 컬럼을 읽는 것까지만 담당하고, 이후 처리는 파이프라인에 위임합니다. 단 두 가지 예외가 있습니다.

1. 인덱스 활용: AST가 read()에 전달되므로 테이블 엔진이 인덱스로 읽기 범위를 줄일 수 있습니다.
2. 분산 푸시다운: StorageDistributed는 쿼리를 원격 서버로 보내 일정 단계까지 처리된 결과를 받아옵니다.

바이트 수준 I/O는 C++ iostream 대신 자체 ReadBuffer/WriteBuffer를 씁니다. CompressedWriteBuffer(압축), ConcatReadBuffer(연결), HashingWriteBuffer(해시 계산)처럼 조합 가능한 부품들입니다.

2.7 서버 인터페이스 — 무엇으로 접속해야 하나

서버 자체는 코루틴·파이버 없는 단순한 멀티스레드 서버입니다. 대량의 단순 쿼리가 아니라 소수의 복잡한 쿼리(각각 방대한 데이터 처리)를 위한 의도적 설계입니다. TCP 프로토콜은 전·후방 호환성을 유지하되, 약 1년 후 구버전 지원을 제거합니다.

✍️ 이해도 체크