第一章　ClickHouse 概述与发展历程（ClickHouse Overview and Evolution）

1.1　诞生背景与设计初衷

一、从日志到分析的痛点

在 2010 年前后，互联网企业的流量监控与日志分析体系大多依赖于 Hadoop + Hive 模型：

• 离线批处理；
• 延迟高（小时级）；
• 集群成本高昂；
• 无法满足实时数据分析需求。

Yandex（俄罗斯最大的搜索引擎公司）当时面临的核心问题是：

需要在秒级内，对数十亿条日志执行多维聚合、排序、过滤与统计。

传统的 Hadoop Hive 架构存在明显的瓶颈：

于是，Yandex 的工程团队在 2009 年启动了一个内部项目，代号 “ClickStream Analytics”，后来演化为 ClickHouse（Click + Warehouse）。

二、ClickHouse 的设计初衷

ClickHouse 的核心目标可以用一句话概括：

“让实时分析像查询数据库一样快。”

为此，它确立了三大核心设计原则：

Yandex 团队意识到：

• 分析型查询主要访问部分列；
• 聚合计算远多于随机写；
• 数据量极大但更新稀少；
• 需要高压缩、高吞吐、低延迟的架构。

于是 ClickHouse 从一开始就定位为OLAP（Online Analytical Processing）系统，而不是事务型数据库。

1.2　发展历程与版本演进

ClickHouse 的发展可分为四个阶段：

1.2.1　内部版本（2009–2015）

• 主要用于 Yandex.Metrica（类似于 Google Analytics 的网站统计服务）；
• 每天分析 超 100 亿条日志；
• 内部部署上千节点；
• 查询延迟平均 < 1 秒。

1.2.2　开源发布（2016）

• 由 Yandex 在 GitHub 上开源；
• MIT 许可；
• 短短一年内收获 10K+ Star；
• 成为欧洲最受欢迎的数据库项目之一。

1.2.3　社区与企业采用（2017–2020）

• Cloudflare、腾讯广告、字节跳动、美团点评、Bilibili 等开始采用；
• 成为 时序分析与日志分析事实标准；
• ClickHouse 被集成进 Grafana、Superset、Metabase；
• 支持 Kafka、MySQL、PostgreSQL 等数据源导入；
• 引入 ReplicatedMergeTree、Distributed 表、ZooKeeper 协调机制。

1.2.4　ClickHouse Inc 成立（2021–）

• 原始核心团队成立独立公司 ClickHouse Inc；

• 获得 2.5 亿美元融资；

• 推出 ClickHouse Cloud；

• 新增特性：

  • ClickHouse Keeper（替代 ZooKeeper）；
  • Iceberg / S3 兼容；
  • 新一代 SQL 优化器；
  • 向量化引擎优化；
  • Parquet/ORC 支持；
  • 云原生对象存储层。

1.3　设计理念与架构哲学

ClickHouse 的成功来自于工程哲学的极致贯彻。

一、核心理念：数据读优先、计算下推

与传统数据库（如 MySQL）强调事务安全不同，ClickHouse 的设计假设：

• 数据写入频繁但可批量；
• 数据主要用于分析查询；
• 更新、删除相对稀少；
• 延迟以亚秒级查询为目标。

它牺牲了部分 ACID 特性，换取了极致的读性能。

二、主要设计哲学

1.4　与传统数据库的差异

简单理解：

ClickHouse 不是 MySQL 的替代品，而是 MySQL 的“报表中心 / 分析仓库”伙伴。

1.5　ClickHouse 的技术特点概览

1.5.1　列式存储与高压缩

• 每列独立存储；
• 同类型数据连续分布；
• 支持 LZ4、ZSTD、Delta、Gorilla；
• 压缩率常达 10–20 倍；
• 提升 I/O 效率 5–10 倍。

1.5.2　向量化查询执行

• 一次操作数千条数据；
• 利用 CPU SIMD 指令；
• 减少函数调用与内存切换；
• 多核并行执行查询管线。

1.5.3　MergeTree 系列引擎

• 基础引擎：MergeTree

• 支持：

  • 主键排序（ORDER BY）
  • 数据分区（PARTITION BY）
  • 稀疏索引
  • 异步合并（后台任务）

• 衍生版本：

  • ReplacingMergeTree
  • SummingMergeTree
  • AggregatingMergeTree
  • CollapsingMergeTree
  • VersionedCollapsingMergeTree

1.5.4　分布式查询与副本机制

• Distributed 表协调跨节点查询；
• Shard + Replica 架构；
• 支持异步复制；
• 依赖 ZooKeeper / ClickHouse Keeper 管理元数据。

1.5.5　实时导入与物化视图

• 支持 Kafka、File、HTTP、TCP 导入；
• Materialized View 实现流式预聚合；
• 实时 ETL 方案简单高效。

1.5.6　系统表与可观测性

• 内置 system.* 系列表；

• 可实时查看：

  • 查询日志（system.query_log）
  • 资源使用（system.metrics）
  • 磁盘 I/O（system.parts）
  • Merge 状态（system.merges）

1.6　全球生态与应用案例

ClickHouse 已成为全球分析型数据库的事实标准之一。

这些案例的共性：

• 都需要高吞吐、低延迟、实时分析；
• ClickHouse 常作为 OLTP → ETL → OLAP 的终端；
• 与 Kafka、Flink、Airflow、Grafana 等生态深度结合。

1.7　ClickHouse 的社区与未来方向

一、社区生态

• GitHub Star 超过 50k+；
• 每年提交上万次；
• 主要维护者包括 ClickHouse Inc、Altinity、Yandex。

生态工具包括：

二、商业化与云服务

ClickHouse Inc 推出了 ClickHouse Cloud：

• 按量计费；
• 自动伸缩；
• 对象存储底层；
• Serverless 查询模型。

三、未来技术方向

• 完全替代 ZooKeeper；
• 原生云对象存储；
• SQL 优化器进一步智能化；
• 向量计算 + GPU 加速；
• HTAP 能力增强；
• 数据湖集成（Iceberg、Delta Lake）；
• WASM + Remote Function 扩展机制。

1.8　本章小结

• ClickHouse 源自 Yandex 内部需求，为海量日志分析而生；
• 采用列存 + 向量化 + 分布式无共享架构；
• 在读性能、压缩效率、扩展性上达到业界顶尖；
• 与 MySQL 等事务型数据库互补，而非替代；
• 被广泛用于日志、监控、BI、实时数据仓库等场景；
• 正在迈向云原生化与全球企业级生态阶段。

第二章　ClickHouse 架构总览（Architecture Overview）

2.1　系统总体结构与组件划分

ClickHouse 是一个分布式列式分析数据库系统，采用 Shared-Nothing 架构，即每个节点独立承担存储与计算职责，不共享磁盘或内存资源。

一、系统架构层次

整体可以划分为三层：

┌──────────────────────────────┐
│       Client Layer            │
│ (JDBC / HTTP / Native CLI)    │
└──────────────┬───────────────┘
               │ SQL 请求
┌──────────────▼───────────────┐
│       Server Layer            │
│  SQL Parser / Planner / Executor │
│  MergeTree Engine / Buffer / Cache │
└──────────────┬───────────────┘
               │ 读写数据块
┌──────────────▼───────────────┐
│     Storage Layer (Local/Dist) │
│  MergeTree Files / Disk / S3   │
└──────────────────────────────┘

ClickHouse 没有像传统数据库那样的“主节点 + 从节点”结构，而是：

• 每个节点既可执行查询，也可存储数据；
• 分布式表（Distributed）只是逻辑抽象层；
• 元数据由 ZooKeeper / ClickHouse Keeper 管理。

2.2　Shared-Nothing 架构原理

一、定义

“Shared-Nothing” 意味着：

每个节点完全独立，不共享 CPU、内存、磁盘或锁。

这种架构带来三大优点：

1. 线性扩展性：增加节点即提升容量与计算力；
2. 高容错性：单节点宕机不会影响整体；
3. 资源隔离性强：避免锁竞争与单点瓶颈。

二、ClickHouse 的实现方式

• 每个节点保存部分分区（Partition）；
• 不存在集中式调度器；
• 客户端或查询协调节点根据分布规则路由请求；
• 副本节点间通过 ZooKeeper 进行轻量同步。

简化示意：

   Query
     │
     ▼
┌────────────┐
│ Coordinator│
└──────┬─────┘
       │
 ┌─────┴─────────────────────┐
 │           Cluster          │
 │ ┌────────┐  ┌────────┐    │
 │ │ Node 1 │  │ Node 2 │... │
 │ └────────┘  └────────┘    │
 └────────────────────────────┘

2.3　Server、Client 与 Cluster 的关系

关键文件：

• /etc/clickhouse-server/config.xml：服务与集群配置；
• /etc/clickhouse-server/users.xml：用户与权限；
• /etc/clickhouse-server/clusters.xml：定义集群节点；
• /var/lib/clickhouse/data：存放表数据。

示例集群配置：

<remote_servers>
  <my_cluster>
    <shard>
      <replica>
        <host>ch-node1</host>
        <port>9000</port>
      </replica>
      <replica>
        <host>ch-node2</host>
        <port>9000</port>
      </replica>
    </shard>
    <shard>
      <replica>
        <host>ch-node3</host>
        <port>9000</port>
      </replica>
    </shard>
  </my_cluster>
</remote_servers>

2.4　查询执行路径（从 SQL 到结果）

当用户执行一条 SQL 查询（例如聚合统计）时，ClickHouse 的执行过程如下：

[1] SQL 解析与语法树生成
[2] 查询计划优化与分布式分解
[3] 任务分发至各 Shard 节点
[4] 节点局部执行（扫描 + 过滤 + 聚合）
[5] 汇总节点收集子结果并合并
[6] 输出最终结果

执行路径图：

Client
  │
  ▼
Parser → Analyzer → Planner
  │
  ▼
Coordinator
  ├──→ Shard 1 → MergeTree → Local Result
  ├──→ Shard 2 → MergeTree → Local Result
  └──→ Shard 3 → MergeTree → Local Result
      │
      ▼
  Final Aggregator (Merge + Sort + Limit)
      │
      ▼
   Result Output

特点：

• 查询被切分为多个子任务；
• 每个节点局部执行聚合；
• 最后在协调节点进行二次聚合；
• 通过 max_threads 参数控制并发。

2.5　MergeTree 存储引擎的核心角色

MergeTree 是 ClickHouse 的基础存储引擎，也是几乎所有数据表的底层实现。

存储结构：

/var/lib/clickhouse/data/db/table/
 ├── 202501_1_1_0/          ← 分区目录
 │   ├── data.bin            ← 数据块
 │   ├── marks.mrk2          ← 稀疏索引
 │   ├── columns.txt         ← 列描述
 │   └── checksums.txt       ← 校验信息
 ├── detached/               ← 临时数据
 └── metadata/               ← 表结构定义

2.6　数据分片、复制与分布式表

一、分片（Shard）

• 将大表数据拆分到多个节点；
• 每个分片存储部分分区；
• 实现水平扩展。

二、副本（Replica）

• 每个分片可有多个副本；
• 副本间数据一致性由 ZooKeeper 保证；
• 提升容灾能力与读并发。

三、分布式表（Distributed）

分布式表不是物理表，而是一个逻辑映射层：

• 将查询自动路由到对应 Shard；
• 在各分片执行本地查询；
• 最后在协调节点汇总结果。

定义示例：

CREATE TABLE events_local (
  event_date Date,
  user_id UInt64,
  action String
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, user_id);

CREATE TABLE events_all AS events_local
ENGINE = Distributed(my_cluster, default, events_local, rand());

用户查询 events_all，系统会自动访问 events_local 的所有分片节点。

2.7　数据流模型（Pipeline & Execution DAG）

ClickHouse 的执行引擎是典型的流水线模型（Pipeline Execution Model）。

一、Pipeline 概念

• 查询被拆分为多个算子（Operator），如 Scan、Filter、Aggregate、Sort；
• 每个算子以“Block”为单位处理数据；
• Block 是一组列向量（Column Vector）；
• 上下游算子以异步管道方式衔接。

┌──────────┐
│  Scan    │ → 读数据块
└────┬─────┘
     │ Block
┌────▼─────┐
│  Filter  │ → 条件过滤
└────┬─────┘
     │ Block
┌────▼─────┐
│ Aggregate│ → 聚合汇总
└────┬─────┘
     │ Block
┌────▼─────┐
│  Sort    │ → 排序输出
└──────────┘

二、DAG 调度与并行执行

• 每个算子节点形成 DAG；
• 调度器分配线程池；
• 自动多核并行执行；
• 支持“流式输出”与“边计算边传输”。

这种模型极大地减少了上下文切换与中间结果存储。

2.8　缓存、内存与 I/O 管理机制

ClickHouse 不依赖 OS Page Cache，而是自建高性能缓存层。

内存模型：

• 每个查询线程独立分配内存；
• 使用 Arena Allocator；
• 防止碎片化；
• 内存超限时自动中止查询。

2.9　系统表与元数据结构

ClickHouse 将几乎所有运行信息暴露为 system.* 表：

示例查询：

SELECT database, table, count() AS parts
FROM system.parts
GROUP BY database, table;

2.10　ClickHouse 的可扩展性设计

通过这些机制，ClickHouse 实现了几乎线性扩展：

数据量 ×10 → 节点数 ×10 → 性能保持稳定。

2.11　本章小结

• ClickHouse 的架构基于 Shared-Nothing 分布式模型；
• 每个节点集计算与存储于一体；
• SQL 查询通过 Coordinator 分解为分布式任务；
• MergeTree 引擎是核心，负责分区、索引、合并；
• Pipeline 模型实现高效的向量化执行；
• 系统表提供全面可观测性；
• 可通过 Shard/Replica 实现水平扩展与高可用。

第三章　存储引擎与数据组织（Storage Engines and Data Organization）

3.1　ClickHouse 存储引擎体系概览

ClickHouse 中的“表引擎（Table Engine）”相当于传统数据库的存储层 + 执行接口抽象。
不同引擎定义了数据的存储方式、写入策略、索引结构与分布规则。

一、引擎的分类

ClickHouse 引擎分为以下四大类：

3.2　MergeTree 家族全景

MergeTree 是 ClickHouse 的灵魂，它不仅是默认引擎，也是一系列变体引擎的基础。

这些引擎都共享 MergeTree 的底层机制，只在合并（Merge）逻辑上存在差异。

3.3　数据分区（Partition）与排序（Order）

一、Partition 分区机制

分区是 ClickHouse 提高查询性能和管理效率的核心手段之一。
每个分区是独立的物理目录，可按时间或业务维度划分。

CREATE TABLE events (
  event_date Date,
  user_id UInt64,
  action String
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, user_id);

上例中，数据会根据 event_date 的月份分区：

/var/lib/clickhouse/data/events/
 ├── 202501_1_1_0/
 ├── 202502_2_2_0/
 ├── 202503_3_3_0/
 ...

优点：

• 快速分区裁剪（Partition Pruning）；
• 支持 TTL 删除整个分区；
• 降低合并成本；
• 便于冷热数据分层。

二、ORDER BY 排序键（Primary Key）

ClickHouse 没有“唯一主键”概念，而是定义了一个排序键（Primary Key），用于：

• 按排序键组织数据；
• 支持范围扫描；
• 稀疏索引依据该键构建。

排序键的选择对性能至关重要，应遵循：

• 优先选择高选择性字段；
• 将常用于过滤、排序的字段放在前；
• 避免包含过多维度字段。

例如：

ORDER BY (event_date, user_id)

将确保每个分区内部的数据按日期、用户排序。

3.4　稀疏索引（Sparse Index）机制

ClickHouse 不像传统数据库维护行级索引，而是使用一种稀疏块索引（Mark Index）。

一、索引原理

• 每 8192 行（默认）建立一个索引标记（Mark）；
• 每个 Mark 记录列的最小值与最大值；
• 查询时通过范围过滤跳过不匹配的块。

数据行： [1..8192] [8193..16384] ...
索引：    Mark1      Mark2      ...

示意：

┌─────────────┐
│ column_data │→ blocks of 8192 rows
└──────┬──────┘
       │
┌──────▼──────┐
│ sparse marks│→ (min, max) pairs
└─────────────┘

二、优势

• 极低的索引存储成本（占比 <1%）；
• 读放大率小；
• 可在扫描前跳过大部分无关数据。

三、相关参数

<index_granularity>8192</index_granularity>
<index_granularity_bytes>10MiB</index_granularity_bytes>

可通过调节粒度平衡查询速度与存储占用。

3.5　数据压缩算法与存储格式

ClickHouse 的压缩机制是性能与成本的关键。

每列可独立指定压缩算法：

CREATE TABLE metrics (
  ts DateTime CODEC(Delta, ZSTD),
  value Float32 CODEC(Gorilla)
) ENGINE = MergeTree()
ORDER BY ts;

文件组成（以一个分区为例）：

3.6　数据写入与合并机制（Merge）

ClickHouse 写入机制为批量追加 + 后台合并模式。

一、写入流程

1. 新数据写入临时文件；
2. 校验并重命名为新的 part；
3. 后台线程异步触发合并；
4. 合并后小文件被整合为大块；
5. 最终持久化索引与校验。

INSERT → tmp_part → part_X_Y_Z → Merge → Optimized part

二、合并策略

• 小文件过多会触发后台 Merge；

• 每次合并 2～10 个相邻分区；

• 合并时执行：

  • 按 ORDER BY 重排；
  • 聚合（Summing/Collapsing）；
  • 删除标记应用；
  • TTL 清理。

合并日志：
可通过查看：

SELECT * FROM system.merges;

3.7　TTL 与数据生命周期管理

ClickHouse 支持为表或列定义 TTL（Time To Live），自动清理或迁移过期数据。

一、表级 TTL

ALTER TABLE events
MODIFY TTL event_date + INTERVAL 90 DAY DELETE;

表示保留 90 天数据，超过即自动删除。

二、列级 TTL

ALTER TABLE logs
MODIFY COLUMN user_ip TTL event_time + INTERVAL 30 DAY TO VOLUME 'cold_storage';

表示 30 天后将列数据移动至冷存储卷。

三、应用场景

• 日志归档；
• 冷热分层；
• 自动删除旧数据；
• 降低存储成本。

3.8　冷热分层与磁盘策略（Storage Policy）

一、Storage Policy 概念

通过配置不同磁盘路径（如 SSD、HDD、S3）并分配策略，ClickHouse 可实现数据生命周期分层。

配置示例（config.xml）：

<storage_configuration>
  <disks>
    <ssd>
      <path>/mnt/ssd/</path>
    </ssd>
    <hdd>
      <path>/mnt/hdd/</path>
    </hdd>
  </disks>

  <policies>
    <hot_cold>
      <volumes>
        <hot><disk>ssd</disk></hot>
        <cold><disk>hdd</disk></cold>
      </volumes>
    </hot_cold>
  </policies>
</storage_configuration>

然后建表时引用：

CREATE TABLE events (...)
ENGINE = MergeTree()
ORDER BY id
SETTINGS storage_policy = 'hot_cold';

二、迁移与平衡

• 后台任务自动监控磁盘使用；
• 满载后按优先级将老数据迁移至“冷卷”；
• 查询自动跨卷调度。

3.9　删除与版本控制（Mutations）

ClickHouse 的删除、更新通过“Mutation”机制实现，是一种延迟生效的批处理修改。

一、基本语法

ALTER TABLE events DELETE WHERE event_date < '2025-01-01';
ALTER TABLE users UPDATE age = 30 WHERE id = 1;

二、原理

• 执行后生成一个 Mutation 任务；
• 后台线程在 Merge 时应用；
• 无需锁表，异步生效；
• 状态可查询：

SELECT * FROM system.mutations;

三、注意事项

• 不适合频繁更新；
• 建议只用于批量清理；
• 小规模修改推荐“ReplacingMergeTree”。

3.10　文件系统与磁盘组织结构

一个 MergeTree 表的目录结构如下：

/var/lib/clickhouse/data/db/table/
 ├── detached/          # 临时脱离的分区
 ├── format_version.txt
 ├── metadata_version.txt
 ├── 202501_1_1_0/      # 分区目录
 │   ├── event_date.bin
 │   ├── event_date.mrk2
 │   ├── user_id.bin
 │   ├── user_id.mrk2
 │   ├── action.bin
 │   ├── action.mrk2
 │   ├── columns.txt
 │   ├── checksums.txt
 │   └── partition.dat
 ├── mutations/          # 待执行的 mutation
 └── metadata/           # 表定义缓存

每个 .bin 文件按列存储，.mrk2 文件记录偏移。

3.11　存储引擎参数优化实践

优化建议：

• 高频查询字段优先排序；
• 控制分区数量（避免过细）；
• 合理配置缓存与压缩算法；
• 使用 ReplacingMergeTree 替代频繁更新。

3.12　本章小结

• ClickHouse 的存储核心是 MergeTree 引擎系列；
• 采用分区 + 排序键 + 稀疏索引组合实现高效查询；
• 写入为批量追加，后台自动合并；
• 支持多种压缩算法与冷热分层；
• TTL 与 Mutation 提供数据生命周期与轻量更新能力；
• 合理的数据建模与存储策略是性能优化的关键。

第四章　查询引擎与执行优化（Query Engine and Execution Optimization）

4.1　查询执行生命周期概览

当用户通过 HTTP、TCP 或 CLI 提交一条 SQL 时，ClickHouse 内部执行的完整路径如下：

SQL Request
   │
   ▼
[1] Parser → 语法树生成
[2] Analyzer → 语义检查 + 类型推导
[3] Planner → 执行计划构建
[4] Interpreter → 计划转换为执行管线
[5] Executor → 执行节点调度与数据流
[6] ResultWriter → 格式化输出结果

整个过程由 InterpreterSelectQuery 等组件协同完成，每一步都可以在系统表或日志中追踪。

4.2　查询解析与语法树生成（Parser）

ClickHouse 内置的 SQL 解析器基于 自定义递归下降算法（Recursive Descent Parser），而非 ANTLR。

特点：

• 无外部依赖；
• 性能极快（C++ 编译期解析表定义）；
• 支持 ClickHouse 方言（如 SAMPLE, FINAL, FORMAT）。

解析阶段的核心输出是：

• 一棵抽象语法树（AST）；
• 每个节点包含：操作类型、表达式、函数、子查询等。

可通过系统表 system.query_log 查看解析耗时：

SELECT query, query_start_time_microseconds, query_duration_ms
FROM system.query_log
WHERE type = 'QueryStart';

4.3　语义分析与逻辑计划生成（Analyzer）

在语义阶段，系统会：

1. 验证表与列存在；
2. 校验类型兼容；
3. 分析聚合上下文；
4. 生成“逻辑执行计划”（Logical Plan）。

逻辑计划的中间表示类似于关系代数表达式，例如：

Project(columns=[user_id, COUNT(*)])
  └── Filter(predicate=event_date > '2025-01-01')
        └── Scan(table=events)

逻辑计划并不包含物理执行细节，它描述“做什么”，而非“如何做”。

4.4　物理计划与算子体系（Planner）

物理计划阶段，系统将逻辑计划映射为可执行算子（Physical Operators）。
主要算子类型如下：

算子间通过 Pipe（管道）连接，形成一个执行图（DAG）。

4.5　向量化执行引擎（Vectorized Engine）

一、核心思想

传统数据库逐行执行（Row-by-Row Execution）：

for each row:
    evaluate(expr)

而 ClickHouse 使用向量化执行（Vectorized Execution）：

for each block (N rows):
    evaluate(expr on SIMD batch)

即一次处理数千行数据，充分利用 CPU 的 SIMD（Single Instruction Multiple Data）能力。

二、Block 与 Column 概念

• Block：执行引擎的最小数据单元，包含多列；
• Column：存储列向量（数组）；
• 每个算子处理“列”而非“行”。

Block {
  Column1: [v1, v2, v3, ...]
  Column2: [x1, x2, x3, ...]
}

三、优势

4.6　表达式计算与函数执行引擎

ClickHouse 内置 2500+ 函数，涵盖字符串、数学、时间、JSON、聚合等。

函数执行通过 Expression Actions DAG 实现：

• 每个函数节点有输入输出列；
• 形成 DAG 拓扑结构；
• 系统自动推导执行顺序；
• 支持常量折叠（Constant Folding）优化。

例如，查询：

SELECT toYear(date) AS y, count() FROM logs GROUP BY y;

其表达式 DAG：

date ──> toYear ──> y ──> GROUP BY y

执行时引擎仅计算必要列，自动跳过未引用字段。

4.7　聚合引擎（Aggregate Engine）

ClickHouse 的聚合分为两阶段：

1. Partial Aggregation（局部聚合）

   • 各线程或节点独立聚合；
   • 结果为中间状态（AggregateState）。

2. Final Aggregation（全局聚合）

   • 对中间状态进行合并；
   • 得出最终结果。

这种两阶段设计允许：

• 并行化；
• 分布式聚合；
• 支持增量计算。

内部数据结构

聚合键 → 哈希表：

unordered_map<Key, AggregateState>

当键过多时自动溢出到外部存储（external aggregation）。

可监控聚合执行状态：

SELECT * FROM system.query_log WHERE type='QueryFinish';

4.8　Join 算子实现机制

ClickHouse 支持多种 Join 策略：

示例：

SELECT a.id, b.name
FROM t1 AS a
JOIN t2 AS b USING id;

执行流程：

1. 右表加载为哈希表；
2. 左表扫描匹配；
3. 输出匹配结果。

参数优化：

<join_use_nulls>1</join_use_nulls>
<join_algorithm>hash</join_algorithm>
<max_rows_in_join>100000000</max_rows_in_join>

4.9　排序与限制算子（Sort & Limit）

ClickHouse 的排序（ORDER BY）使用多阶段外部排序：

1. 每个线程局部排序；
2. 临时结果写磁盘（如超内存）；
3. 最终多路归并。

相关参数：

<max_bytes_before_external_sort>256MiB</max_bytes_before_external_sort>
<max_bytes_before_external_group_by>256MiB</max_bytes_before_external_group_by>

优化建议：

• 尽量先 LIMIT 再 ORDER BY；
• 合理设置 max_threads；
• 避免在巨量数据上排序。

4.10　分布式查询优化（Distributed Execution）

分布式表查询时，ClickHouse 执行两级聚合与合并：

Coordinator
  ├──→ Shard1: local aggregation
  ├──→ Shard2: local aggregation
  └──→ Shard3: local aggregation
       ↓
   Coordinator: merge + sort + limit

优化特性

参数示例：

<distributed_aggregation_memory_efficient>1</distributed_aggregation_memory_efficient>
<max_distributed_connections>1000</max_distributed_connections>

4.11　查询优化器（Optimizer）

ClickHouse 的优化器较轻量，但不断进化中（23.x 起引入新版 Cost-based Optimizer）。

优化器阶段

示例：

SELECT * FROM events WHERE toDate(time) = today();

系统会自动下推到分区裁剪，避免全表扫描。

4.12　查询并行与线程调度

ClickHouse 利用多核架构极致并行：

• 每个查询默认使用 max_threads 个工作线程；
• 各线程独立处理数据块；
• 聚合时使用并发哈希表；
• 结果通过异步队列合并。

配置参数：

<max_threads>auto</max_threads>
<max_execution_time>60</max_execution_time>
<max_concurrent_queries>100</max_concurrent_queries>

在分布式场景下：

• 每个分片独立执行；
• 上层协调节点并行等待。

监控：

SELECT query, read_rows, read_bytes, thread_numbers FROM system.query_log;

4.13　查询缓存与中间结果优化

ClickHouse 提供多级缓存：

配置示例：

<mark_cache_size>536870912</mark_cache_size> <!-- 512MB -->
<uncompressed_cache_size>2G</uncompressed_cache_size>

4.14　外部查询资源控制

ClickHouse 提供完善的资源隔离机制：

示例：

<profiles>
  <analyst>
    <max_threads>32</max_threads>
    <max_memory_usage>8G</max_memory_usage>
    <max_execution_time>120</max_execution_time>
  </analyst>
</profiles>

4.15　查询执行可观测性与诊断

ClickHouse 通过系统表提供极强的可观测性。

常见诊断查询：

-- 查看正在运行的查询
SELECT query_id, query, read_rows, memory_usage FROM system.processes;

-- 查询慢 SQL
SELECT query, query_duration_ms
FROM system.query_log
WHERE query_duration_ms > 5000
ORDER BY query_duration_ms DESC;

4.16　查询性能优化实战

案例一：高并发聚合慢

原因：

• 没有 ORDER BY；
• 分区过细；
• 内存溢出。

优化：

• 调整排序键；
• 合并分区；
• 启用 distributed_aggregation_memory_efficient = 1。

案例二：Join 过慢

原因：

• 大表对大表 Join；
• Hash 表过大。

优化：

• 先聚合再 Join；
• 使用预聚合物化视图；
• 调整 max_bytes_in_join。

案例三：排序 OOM

原因：

• 超大 ORDER BY；
• 内存溢出。

优化：

• 提前 LIMIT；
• 启用外部排序；
• 增加磁盘缓存空间。

4.17　本章小结

• ClickHouse 采用向量化执行引擎，一次处理多个行块；
• 查询流程包括解析、分析、计划、执行、合并；
• 聚合与 Join 均支持并行化；
• Pipeline 模型 + 多线程调度带来极致性能；
• 提供丰富的可观测与优化机制；
• 性能优化核心是“数据裁剪 + 向量执行 + 局部聚合”。

第五章　分布式架构与副本机制（Distributed Architecture & Replication Mechanism）

5.1　分布式设计目标与挑战

ClickHouse 在设计之初就立足于大规模数据分析场景，追求：

• 水平扩展（Horizontal Scalability）
• 高可用性（High Availability）
• 最终一致性（Eventual Consistency）
• 强吞吐低延迟（Throughput & Latency Balance）

一、面临的挑战

ClickHouse 采用 Shared-Nothing 架构 + 异步复制 + 最终一致模型 来应对这些问题。

5.2　ClickHouse 集群总体架构

整体集群结构如下：

                 ┌───────────────────────────┐
                 │        Client Layer       │
                 │ (clickhouse-client / JDBC)│
                 └─────────────┬─────────────┘
                               │
                      Distributed Table
                               │
        ┌────────────┬────────┴──────────┬────────────┐
        │             │                   │            │
┌───────▼──────┐ ┌────▼──────┐     ┌─────▼──────┐ ┌────▼──────┐
│   Shard 1    │ │  Shard 2  │ ... │   Shard N  │ │   Replica │
│ Local Table  │ │ Local Tbl │     │ Local Tbl  │ │   Backup  │
└───────┬──────┘ └────┬──────┘     └────┬──────┘ └────┬──────┘
        │              │                 │              │
        ▼              ▼                 ▼              ▼
    ZooKeeper / ClickHouse Keeper ———— 元数据与复制协调

每个 Shard 节点都是独立的存储与计算单元。
ZooKeeper（或新版本的 ClickHouse Keeper）承担全局协调任务。

5.3　集群配置（Cluster Configuration）

ClickHouse 的分布式拓扑在配置文件中定义：

<remote_servers>
  <my_cluster>
    <shard>
      <replica>
        <host>ch-node1</host>
        <port>9000</port>
      </replica>
      <replica>
        <host>ch-node2</host>
        <port>9000</port>
      </replica>
    </shard>

    <shard>
      <replica>
        <host>ch-node3</host>
        <port>9000</port>
      </replica>
      <replica>
        <host>ch-node4</host>
        <port>9000</port>
      </replica>
    </shard>
  </my_cluster>
</remote_servers>

每个 <shard> 对应一组副本，内部副本之间保持数据一致；
不同 Shard 之间的数据互不重复，实现分布式分片。

5.4　分布式表（Distributed Engine）

Distributed 表 是 ClickHouse 分布式架构的逻辑层核心。
它不直接存储数据，而是负责：

1. 路由请求至各 Shard；
2. 并行执行子查询；
3. 聚合与合并结果；
4. 管理连接池与副本容错。

定义示例：

CREATE TABLE hits_local (
  event_date Date,
  user_id UInt64,
  url String
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, user_id);

CREATE TABLE hits_all AS hits_local
ENGINE = Distributed(my_cluster, default, hits_local, rand());

rand() 表示随机分片写入，可根据字段实现自定义路由（如哈希分布）。

5.5　数据分片（Sharding）

一、分片的目的

• 扩展存储容量
• 提升并发性能
• 分担计算压力

二、分片策略

ClickHouse 支持多种分片算法：

三、查询时的行为

• 查询被拆分为多 shard 子查询；
• 每个 shard 本地执行；
• 最终结果由协调节点聚合。

示例：

SELECT count() FROM hits_all WHERE event_date > today() - 7;

=> 分布式查询分解：

hits_local@node1 → 局部count
hits_local@node2 → 局部count
...
Coordinator → SUM(all counts)

5.6　副本机制（Replication）

一、ReplicatedMergeTree 引擎

副本机制通过 ReplicatedMergeTree 引擎实现，它基于 ZooKeeper 实现同步协调。

定义示例：

CREATE TABLE hits_replica (
  event_date Date,
  user_id UInt64,
  url String
)
ENGINE = ReplicatedMergeTree(
  '/clickhouse/tables/{shard}/hits',
  '{replica}'
)
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, user_id);

路径解释：

• '/clickhouse/tables/{shard}/hits' → ZooKeeper 目录；
• '{replica}' → 当前节点副本名。

二、ZooKeeper 协调目录结构

在 ZooKeeper 中，每个表的节点结构如下：

/clickhouse/tables/shard1/hits/
 ├── metadata          (表结构定义)
 ├── log/              (写入操作日志)
 ├── replicas/
 │     ├── replica1/
 │     │     ├── queue/
 │     │     ├── is_active
 │     │     └── columns.txt
 │     ├── replica2/
 │     │     └── ...
 └── blocks/           (写入标识)

每个写入操作（INSERT）会产生一个日志条目，所有副本节点监听并按序执行，从而实现复制。

5.7　写入与同步流程

以两个副本的写入流程为例：

Client → Replica1 (Leader)
   │
   ├─► 写入本地 MergeTree
   │
   ├─► 生成写入日志节点 /log/N
   │
   └─► ZooKeeper 通知 Replica2
            │
            ├─► 读取 /log/N
            ├─► 执行相同 INSERT
            └─► 标记已完成

整个复制是异步的：Replica2 稍后会追上 Replica1。

优点

• 高写入吞吐；
• 低延迟；
• 自动断点恢复。

缺点

• 不能保证强一致；
• 副本间可能暂时不一致。

5.8　读取策略与一致性模型

ClickHouse 的一致性模型为：

Per-part eventual consistency

即：

• 每个分区最终保持一致；
• 查询可在任何副本上执行；
• 不保证跨分片的事务一致性。

读请求策略由 load_balancing 参数控制：

示例：

<load_balancing>nearest_hostname</load_balancing>

5.9　容错机制与自动恢复

当副本节点宕机或网络分区时：

• 其他副本仍可继续提供查询；
• 新节点恢复后自动追同步。

一、自动恢复流程

1. 新副本启动；
2. 检查 ZooKeeper 队列；
3. 对比本地 part；
4. 下载缺失数据；
5. 标记 is_active；
6. 重新加入集群。

二、故障检测

ClickHouse 使用心跳机制监控副本健康状态，异常副本会被自动剔除或降级。

查看状态：

SELECT * FROM system.replicas;

5.10　ClickHouse Keeper：新一代协调器

在 22.x 版本之后，ClickHouse 引入了自研的 ClickHouse Keeper，完全替代 ZooKeeper。

一、特点

Keeper 与 ClickHouse Server 一同运行，简化部署与协调通信。

配置：

<keeper_server>
  <tcp_port>9181</tcp_port>
  <server_id>1</server_id>
  <raft_configuration>
    <server>
      <id>1</id>
      <hostname>ch-node1</hostname>
    </server>
    <server>
      <id>2</id>
      <hostname>ch-node2</hostname>
    </server>
  </raft_configuration>
</keeper_server>

5.11　跨数据中心与高可用架构

ClickHouse 支持多机房容灾部署：

• 同城多副本；
• 异地只读副本；
• 通过 ON CLUSTER 语句跨区域管理。

典型架构：

       ┌───────────────────────┐
       │   DataCenter A        │
       │ Shard1 Replica1       │
       │ Shard2 Replica1       │
       └─────────┬─────────────┘
                 │ Async Replication
       ┌─────────▼─────────────┐
       │   DataCenter B        │
       │ Shard1 Replica2 (RO)  │
       │ Shard2 Replica2 (RO)  │
       └───────────────────────┘

• 写操作只在主集群；
• 备集群用于查询或灾备。

5.12　分布式查询容错与重试机制

分布式查询执行过程中，ClickHouse 具备以下容错能力：

相关参数：

<connections_with_failover_max_tries>2</connections_with_failover_max_tries>
<distributed_ddl_task_timeout>180</distributed_ddl_task_timeout>

可通过 SET distributed_fault_tolerance=1 启用容错查询模式。

5.13　分布式 DDL 与元数据同步

ClickHouse 的分布式 DDL 通过 ON CLUSTER 实现：

CREATE TABLE events ON CLUSTER my_cluster (...) ENGINE = MergeTree();

执行时：

• 生成 DDL 日志节点；
• 各节点自动拉取并执行；
• 状态存储于 system.distributed_ddl_queue。

可监控执行状态：

SELECT * FROM system.distributed_ddl_queue;

5.14　分布式表写入策略优化

默认写入方式：

• 由协调节点根据分片键决定目标 shard；
• 使用异步 TCP 连接批量写入。

参数优化：

<insert_distributed_sync>0</insert_distributed_sync>
<insert_distributed_timeout>60</insert_distributed_timeout>
<insert_distributed_one_random_shard>1</insert_distributed_one_random_shard>

最佳实践：

• 在每个 shard 建立 Buffer 表；
• 通过 Materialized View 汇聚到主表；
• 减少网络往返。

5.15　大规模集群部署实践

一、拓扑设计建议

二、负载均衡与调度

• 通过 Distributed 表自动分发；
• 支持连接池复用；
• 可与负载均衡器（如 HAProxy、ProxySQL）结合使用。

5.16　本章小结

• ClickHouse 的分布式架构基于 Shard + Replica + Distributed 表 三层模型；
• 数据分布由用户定义规则（随机、哈希、范围）；
• 副本机制依托 ZooKeeper / ClickHouse Keeper 实现异步复制；
• 一致性模型为“最终一致”；
• 宕机节点可自动恢复，集群具备强容错性；
• 分布式查询通过局部聚合与二次合并实现高性能；
• ON CLUSTER DDL 与异步写入机制显著提升了管理与可用性。

第六章　写入与导入机制（Data Ingestion and Streaming）

6.1　ClickHouse 写入模型概述

ClickHouse 的写入路径与传统数据库（如 MySQL）差异极大，它采用一种批量追加写入 + 异步合并的模式，而非行级事务。

一、设计目标

• 高吞吐：支持百万行/秒写入；
• 异步化：不阻塞查询；
• 最终一致：保证数据完整；
• 分布式写入可并行扩展。

二、写入核心特性

6.2　数据写入路径详解

写入流程（以单节点为例）：

Client (Insert)
   │
   ▼
[1] SQL Parser & Plan
   │
   ▼
[2] Block Formation (N rows)
   │
   ▼
[3] Write Buffer → Temporary Part
   │
   ▼
[4] Commit → Move to Active Parts
   │
   ▼
[5] Background MergeTask

步骤解释：

整个写入过程无锁、异步、支持并发写入。

6.3　写入性能影响因素

示例参数：

<background_pool_size>16</background_pool_size>
<max_partitions_per_insert_block>64</max_partitions_per_insert_block>
<min_insert_block_size_rows>1048576</min_insert_block_size_rows>

6.4　INSERT 语句与批量导入

一、INSERT 基本语法

INSERT INTO table_name (col1, col2, col3)
VALUES
(1, 'a', 10),
(2, 'b', 20);

或通过批量文件导入：

clickhouse-client --query="INSERT INTO table FORMAT CSV" < data.csv

二、支持的导入格式

示例：

clickhouse-client --query="INSERT INTO logs FORMAT JSONEachRow" < logs.json

6.5　HTTP 接口导入

ClickHouse 提供了 RESTful HTTP 接口，可以通过 curl 或 SDK 实现无状态写入。

一、HTTP 写入示例

curl -sS -u default: \
  -X POST 'http://ch-server:8123/?query=INSERT%20INTO%20events%20FORMAT%20CSV' \
  --data-binary @data.csv

二、分布式写入

通过 HTTP 写入 Distributed 表时，系统会自动将数据转发到各 Shard 节点，支持异步缓存。

参数：

<insert_distributed_sync>0</insert_distributed_sync>
<insert_distributed_timeout>60</insert_distributed_timeout>

6.6　流式数据导入（Kafka Engine）

一、Kafka 引擎简介

ClickHouse 原生支持 Kafka 数据接入，通过 Kafka Engine 表持续消费消息流。

定义示例：

CREATE TABLE kafka_source (
  user_id UInt64,
  action String,
  ts DateTime
) ENGINE = Kafka
SETTINGS
  kafka_broker_list = 'kafka1:9092',
  kafka_topic_list = 'user_action',
  kafka_group_name = 'ch_group',
  kafka_format = 'JSONEachRow',
  kafka_num_consumers = 4;

二、与物化视图联动

Kafka 表本身只是“虚拟源”，需要用物化视图接收数据：

CREATE MATERIALIZED VIEW consumer_mv TO actions_local AS
SELECT user_id, action, ts
FROM kafka_source;

整个链路：

Kafka → Kafka Engine Table → Materialized View → MergeTree

数据会自动从 Kafka 消费并写入目标表，实现准实时流入。

6.7　物化视图（Materialized View）机制

物化视图是 ClickHouse 的 实时 ETL 核心组件，用于：

• 数据清洗；
• 预聚合；
• 表间流转；
• 实时汇总。

定义方式：

CREATE MATERIALIZED VIEW mv_daily
TO daily_summary
AS
SELECT toDate(ts) AS d, count() AS cnt
FROM events
GROUP BY d;

当 events 表有新数据插入时，系统自动执行该 SELECT 逻辑并写入 daily_summary 表。

优点

• 自动触发，无需额外任务调度；
• 无延迟（在 INSERT 事务中执行）；
• 与 Kafka、Buffer 表结合可实现完整实时流。

6.8　Buffer 引擎（Buffer Engine）

Buffer 引擎用于高频写入场景下的写入缓冲。
它充当内存中间层，批量聚合后再写入底层 MergeTree 表。

定义示例：

CREATE TABLE buffer_events AS events_local
ENGINE = Buffer(default, events_local, 16, 10, 60, 100000, 1000000, 10000000);

参数解释：

优势

• 吞吐极高（百万级写入）；
• 避免频繁磁盘 I/O；
• 结合 Kafka 可构建高性能 ingestion 层。

6.9　File 引擎与离线导入

File 引擎提供了对文件系统的直接访问，可用于导入外部离线数据。

示例：

CREATE TABLE logs_file ENGINE = File(CSV, '/data/logs.csv');
SELECT * FROM logs_file;

可直接查询或插入外部文件，非常适合数据回放与归档分析。

6.10　异步写入与分布式缓存机制

分布式表的写入采用异步分发机制。
写入时数据首先写入本地队列（distributed_directory_monitor），由后台线程批量推送至各 Shard。

优点

• 减少网络延迟；
• 避免跨机同步阻塞；
• 自动断点续传。

配置：

<distributed_directory_monitor_sleep_time_ms>100</distributed_directory_monitor_sleep_time_ms>
<distributed_background_insert_batch>10000</distributed_background_insert_batch>

可以通过系统表查看未发送队列：

SELECT * FROM system.distribution_queue;

6.11　并行批量导入与工具生态

ClickHouse 提供多种高性能导入工具：

示例：
批量导入 CSV 至集群：

cat data.csv | clickhouse-client --query="INSERT INTO default.events FORMAT CSV"

并行导入（分片）：

cat data.csv | parallel -j8 "clickhouse-client --host={1} --query='INSERT INTO events FORMAT CSV'" ::: node1 node2 node3 node4

6.12　ETL 与数据管道设计实践

ClickHouse 通常位于数据管道的分析层或实时层。典型的三层 ETL 架构如下：

┌────────────┐     ┌────────────┐     ┌──────────────────┐
│  Data Source│ → │   Stream ETL │ → │ ClickHouse (OLAP) │
│  (Logs, DBs)│    │ (Kafka/Flink)│   │   + Materialized  │
└────────────┘     └────────────┘     │   Views           │
                                      └──────────────────┘

数据接入模式

1. 实时流式（Streaming）：Kafka + MV；
2. 批量同步（Batch ETL）：Flink / Spark + ClickHouse Sink；
3. 增量拉取（CDC）：Debezium / Maxwell + Kafka；
4. API / 文件导入：周期性加载。

实践建议

• 使用 Kafka + MV 处理实时埋点；
• 使用 Flink 预聚合减轻 ClickHouse 压力；
• 控制 part 数量；
• 对接 BI 工具实现数据可视化。

6.13　写入错误与调优

常见错误

性能优化要点

1. 批量插入而非单行；
2. 使用 Native 格式导入；
3. 控制分区数量；
4. 启用 Buffer 或 Kafka；
5. 优化硬盘与后台线程；
6. 使用 TTL 自动清理历史数据。

6.14　本章小结

• ClickHouse 采用 Append-Only 的高吞吐写入模型；
• 每次插入生成新的 part，通过后台合并优化存储；
• 支持多种导入方式：SQL、HTTP、Kafka、文件；
• Materialized View 与 Buffer 引擎构建实时数据管道；
• 异步分布式写入保证性能与容错；
• 结合 Kafka / Flink，可形成完整实时 ETL 流程；
• 性能优化的关键是 批量写入 + 合理分区 + 异步缓存。

第七章　SQL 功能详解与高级查询技巧（SQL Features and Advanced Querying）

7.1　ClickHouse SQL 方言概览

ClickHouse 的 SQL 是基于 ANSI SQL 的扩展方言，既兼容基础语法，又为高性能分析场景增加了大量专用关键字与函数扩展。

一、设计理念

• 兼容 SQL92 大部分语法；
• 精简事务、触发器等 OLTP 特性；
• 增强聚合、时间、数组、JSON 计算能力；
• 函数化设计：一切皆函数；
• 数据类型丰富且可组合。

二、与 MySQL 的主要差异

7.2　SELECT 查询语法结构

ClickHouse 的标准 SELECT 查询支持如下子句顺序（可灵活组合）：

SELECT [DISTINCT] expr_list
FROM table_expr
[PREWHERE cond]
[WHERE cond]
[GROUP BY expr_list]
[HAVING cond]
[ORDER BY expr_list [ASC|DESC]]
[LIMIT n [OFFSET m]]
[SETTINGS key=value]

关键扩展说明

示例：

SELECT url, count() FROM hits
PREWHERE event_date > today() - 7
WHERE region = 'CN'
GROUP BY url
ORDER BY count() DESC
LIMIT 10;

7.3　数据类型系统（Data Types）

ClickHouse 的类型系统灵活、紧凑、面向列式存储优化。

一、数值类型

二、日期与时间

三、字符串与定长类型

四、复杂类型

示例：

CREATE TABLE users (
  id UInt64,
  tags Array(String),
  meta Map(String, String)
);

7.4　内置函数体系（Functions）

ClickHouse 内置超过 2500+ 函数，可分为以下类别：

7.5　聚合函数与多阶段聚合

ClickHouse 的聚合分为两个层面：

1. 局部聚合（Partial Aggregation）
2. 全局聚合（Final Aggregation）

常见聚合函数

示例：

SELECT region, uniqExact(user_id), avg(duration)
FROM logs
GROUP BY region;

7.6　窗口函数（Window Functions）

ClickHouse 自 21.8 版本起原生支持窗口函数（ANSI SQL 风格）。

语法：

SELECT
  user_id,
  sum(amount) OVER (PARTITION BY user_id ORDER BY ts ROWS BETWEEN 3 PRECEDING AND CURRENT ROW) AS rolling_sum
FROM payments;

常用窗口函数：

窗口定义子句：

OVER (PARTITION BY key ORDER BY ts RANGE BETWEEN INTERVAL 7 DAY PRECEDING AND CURRENT ROW)

7.7　数组与高阶函数

ClickHouse 的数组支持函数化操作，与函数式编程风格一致。

示例：

SELECT user_id, arraySum(arrayFilter(x -> x > 100, spends)) FROM users;

7.8　JSON 与半结构化数据处理

ClickHouse 提供强大的 JSON 处理能力，支持高性能解析与提取。

示例：

SELECT
  JSONExtract(json_col, 'user_id', 'UInt64') AS uid,
  JSONExtract(json_col, 'action', 'String') AS act
FROM events;

性能优化建议：

• 使用 JSONCompactEachRow 格式；
• 避免频繁 JSON 解析，可提前 ETL。

7.9　Lambda 与函数式表达式

ClickHouse 独特支持 Lambda 表达式：

arrayMap(x -> x + 1, [1,2,3])

支持的形式：

• 单参数：x -> expr
• 多参数：(x,y) -> expr

应用场景：

• 数组处理；
• 动态计算；
• 嵌套函数。

示例：

SELECT arrayFilter(x -> x LIKE '%error%', messages) FROM logs;

7.10　Map 与嵌套结构（Nested Types）

一、Map 类型

CREATE TABLE metrics (
  meta Map(String, Float64)
) ENGINE = MergeTree();

访问方式：

SELECT meta['cpu'], meta['mem'] FROM metrics;

二、Nested 类型

Nested = 多列数组结构：

CREATE TABLE orders (
  items Nested(
    id UInt64,
    price Float32
  )
);

展开：

SELECT items.id, items.price FROM orders ARRAY JOIN items;

7.11　高级聚合与多维分析（OLAP Functions）

ClickHouse 为 BI 和多维分析提供丰富函数：

示例：

SELECT region, browser, count() FROM logs GROUP BY CUBE(region, browser);

7.12　查询技巧与优化模式

一、Prewhere

只加载过滤所需列：

SELECT * FROM logs PREWHERE event_date = today() AND user_id=123;

二、Sample

采样查询大表：

SELECT count() FROM hits SAMPLE 0.01;

三、Using TTL 自动汇总

ALTER TABLE metrics MODIFY TTL toStartOfMonth(ts) + INTERVAL 6 MONTH GROUP BY region;

四、物化视图优化

为常用聚合构建视图：

CREATE MATERIALIZED VIEW mv_browser TO browser_summary AS
SELECT browser, count() FROM logs GROUP BY browser;

五、分区裁剪

利用分区键自动跳过无关分区。

7.13　调试与性能分析函数

ClickHouse 提供一系列系统函数用于调试：

示例：

SELECT count(), read_rows, elapsed() FROM system.query_log WHERE query LIKE '%GROUP%';

7.14　本章小结

• ClickHouse 的 SQL 方言基于 ANSI 扩展，聚焦分析与高性能；
• 支持丰富的数据类型与函数体系；
• 聚合、窗口、数组、Map、JSON 等提供灵活的数据分析能力；
• Lambda 与高阶函数让 ClickHouse 具备函数式编程风格；
• Prewhere、Sample、TTL、MV 等是高性能查询利器；
• 通过合理利用系统函数与优化模式，可实现亚秒级复杂查询。

第八章　性能优化与资源管理（Performance Tuning and Resource Management）

8.1　性能优化概述

ClickHouse 的性能表现通常远超传统数据库（甚至比 SparkSQL 快 10~100 倍），但性能优劣差距也与配置、数据建模、查询方式密切相关。

一句话总结：

ClickHouse 的性能优化核心在于：
“减少 I/O + 降低扫描量 + 提高并行度 + 合理资源配额”。

性能调优主要分三层：

8.2　性能监控指标体系

ClickHouse 内置系统表提供极其丰富的性能指标。

示例：
查看节点 I/O 统计

SELECT metric, value FROM system.metrics WHERE metric LIKE '%IO%';

查看查询性能：

SELECT query, read_rows, read_bytes, memory_usage, query_duration_ms
FROM system.query_log
ORDER BY query_duration_ms DESC
LIMIT 10;

8.3　表结构与数据建模优化

正确的数据建模是 ClickHouse 性能的根本。

一、分区（PARTITION）

• 按时间或高维聚合字段；
• 控制分区数量在 1000 以内；
• 避免单分区包含数十亿行。

示例：

PARTITION BY toYYYYMM(event_date)

二、排序键（ORDER BY）

• 确保查询条件与排序键一致；
• 高选择性字段放前面；
• 可组合多字段。

推荐顺序：

(时间维度, 用户/设备维度, 分类维度)

三、数据压缩与低基数列

• 对低基数字段使用 LowCardinality；
• 使用 CODEC(ZSTD) 压缩冷数据；
• 对 JSON 转 Map 或 Enum 存储。

示例：

user_agent LowCardinality(String)

四、去重表引擎

• 更新频繁时使用 ReplacingMergeTree；
• 聚合预计算用 SummingMergeTree；
• 保持 Merge 过程轻量。

8.4　查询优化策略

一、使用 PREWHERE

ClickHouse 的 PREWHERE 可以在加载列前进行过滤，显著降低 I/O。

SELECT * FROM logs
PREWHERE event_date >= today() - 1
WHERE region = 'CN';

预过滤字段会先从索引读取，减少后续列扫描。

二、采样 SAMPLE

当查询分析不要求全量精度时可使用：

SELECT count() FROM hits SAMPLE 0.1;

等价于扫描 10% 数据，性能提升 5~10 倍。

三、限制返回行数

查询时尽量 LIMIT 或分页：

SELECT * FROM big_table ORDER BY ts DESC LIMIT 1000;

四、分区裁剪与索引利用

利用分区条件：

WHERE toYYYYMM(event_date) = 202510

系统会跳过不相关的分区。

五、避免低效操作

• 禁止 SELECT *；
• 避免高基数 GROUP BY；
• 避免 JOIN 大表；
• 尽量在写入时预聚合。

8.5　聚合优化与预计算策略

一、两阶段聚合

ClickHouse 默认执行：

• 局部聚合（local）；
• 分布式聚合（global）。

确保每个 Shard 执行局部聚合后再返回结果，可减少数据传输。

SET distributed_aggregation_memory_efficient = 1;

二、物化视图预聚合

对于固定维度聚合查询，可建立物化视图：

CREATE MATERIALIZED VIEW mv_country TO country_summary AS
SELECT country, count() AS cnt
FROM logs GROUP BY country;

这样用户查询直接命中聚合表，性能提升数十倍。

三、Summing/AggregatingMergeTree

利用引擎直接保存聚合状态：

CREATE TABLE sales_summary (
  region String,
  amount AggregateFunction(sum, Float64)
) ENGINE = AggregatingMergeTree()
ORDER BY region;

支持增量聚合合并。

8.6　JOIN 查询优化

JOIN 是分析型查询最昂贵操作之一。

一、原则

• 小表驱动大表；
• 尽量提前过滤；
• 尽量按 join key 排序；
• 对常用维表使用 Join Engine。

二、维表缓存

CREATE TABLE dict_users ENGINE = Join(ANY, LEFT, id) AS
SELECT id, name FROM user_dim;

查询时：

SELECT name FROM dict_users ANY LEFT JOIN logs USING (id);

维表常驻内存，JOIN 无需重复加载。

三、Join 算法选择

SET join_algorithm = 'hash';

可选：

• hash：默认；
• partial_merge：大表连接；
• grace_hash：外部磁盘 join。

8.7　排序与 LIMIT 优化

一、外部排序

当数据量过大时，ClickHouse 会使用外部排序：

<max_bytes_before_external_sort>256M</max_bytes_before_external_sort>

二、优化建议

• 优先使用 LIMIT N BY；
• 限制排序列数量；
• 配合物化视图或预聚合。

8.8　并行度与线程管理

一、线程模型

ClickHouse 采用多线程执行模型：

• 每个查询分配多个线程；
• 每线程处理一个数据 block；
• 自动分配 CPU。

参数：

<max_threads>auto</max_threads>
<max_concurrent_queries>100</max_concurrent_queries>
<max_thread_pool_size>500</max_thread_pool_size>

二、线程调度优化

• 设置 max_threads = CPU 核数 × 2；
• 控制系统总线程池大小；
• 避免单查询使用所有 CPU。

8.9　内存管理与溢出控制

ClickHouse 为每个查询分配独立内存空间，通过 Arena Allocator 管理。
默认行为为“硬限制 + 外部溢出”。

示例：

<max_memory_usage>8G</max_memory_usage>
<max_bytes_before_external_group_by>512M</max_bytes_before_external_group_by>

建议：

• 不同用户组设置不同 profile；
• 启用外部磁盘聚合；
• 避免使用过多 Array/Map 类型。

8.10　磁盘与 I/O 优化

一、存储层优化

• 使用 SSD；
• 数据盘与系统盘分离；
• 使用 RAID10 或 NVMe；
• 启用异步 IO（AIO）。

二、I/O 调度参数

<background_pool_size>32</background_pool_size>
<max_disks_to_merge>8</max_disks_to_merge>
<max_part_loading_threads>16</max_part_loading_threads>

三、冷热数据分层

使用 storage_policy 将老数据迁移至 HDD 或对象存储：

ALTER TABLE logs MODIFY TTL event_date + INTERVAL 90 DAY TO VOLUME 'cold';

8.11　网络与分布式优化

建议：

• 分片内优先局部聚合；
• 调整连接池；
• 同机房节点优先访问；
• 监控网络延迟（system.asynchronous_metrics）。

8.12　配置文件调优建议

配置位置：

/etc/clickhouse-server/config.xml
/etc/clickhouse-server/users.xml

8.13　资源配额与用户管理

通过 users.xml 管理资源与访问权限。

示例：

<profiles>
  <default>
    <max_threads>16</max_threads>
    <max_memory_usage>4G</max_memory_usage>
    <max_execution_time>60</max_execution_time>
  </default>

  <analyst>
    <max_threads>32</max_threads>
    <max_memory_usage>8G</max_memory_usage>
    <max_execution_time>120</max_execution_time>
  </analyst>
</profiles>

<quotas>
  <default>
    <interval length="3600" queries="10000" errors="100" result_rows="10000000"/>
  </default>
</quotas>

8.14　性能瓶颈分析与诊断

一、常见瓶颈类型

二、排查步骤

1. 查询 system.query_log 获取慢 SQL；
2. 查看 system.merges 是否积压；
3. 检查 system.metrics 中 I/O 等待；
4. 分析 dmesg/iotop；
5. 优化表结构与线程配置。

8.15　性能调优实战案例

案例一：日志分析集群延迟高

• 问题：每日 10 亿条日志写入，Merge 队列过多；

• 原因：分区太细（按小时）；

• 优化：

  • 改为按日分区；
  • 批量导入；
  • 调整后台线程数；
  • 使用 Buffer 引擎；
  • 启用 distributed_aggregation_memory_efficient。

案例二：聚合查询内存溢出

• 问题：复杂 GROUP BY 查询 OOM；

• 原因：单机聚合哈希表过大；

• 优化：

  • 启用外部聚合；
  • 拆分维度；
  • 使用物化视图；
  • 限制 max_memory_usage。

案例三：分布式 Join 性能差

• 问题：跨 Shard Join 传输量过大；

• 解决：

  • 在每个 Shard 上创建维表；
  • 使用 Join Engine；
  • 开启局部 Join；
  • 提前过滤右表。

8.16　本章小结

• ClickHouse 性能优化需从表设计、查询逻辑、系统配置三层入手；
• 分区、排序、索引设计是性能根基；
• 聚合、JOIN、排序可通过分布式与预计算策略优化；
• 系统层面应合理配置线程、内存、I/O 与缓存；
• 通过系统表可实时监控性能指标与瓶颈；
• 实践中要持续监测合并队列、慢查询、内存占用等关键指标。

第九章　ClickHouse 集群运维与监控（Cluster Operations and Monitoring）

9.1　集群运维的重要性

ClickHouse 在大规模生产环境中常运行于：

• 日志与监控分析平台（PB 级数据量）
• 实时 BI 与埋点分析系统
• 时序/IoT 数据集群
• 用户行为追踪与广告数据仓库

因此，它的稳定性与可观测性直接影响整个数据体系的 SLA（Service Level Agreement）。

“ClickHouse 不是 MySQL，它需要像管理一个分布式计算系统那样去运维。”

9.2　集群部署模型与拓扑结构

ClickHouse 支持灵活的部署拓扑，从单节点到多数据中心都可扩展。

一、常见部署模式

二、典型集群拓扑图

                  ┌─────────────────────┐
                  │  ClickHouse Client   │
                  └──────────┬───────────┘
                             │
                      Distributed Table
                             │
          ┌───────────┬───────────┬───────────┐
          │           │           │           │
 ┌────────▼──────┐ ┌──▼──────────┐ ┌──────────▼──┐
 │   Shard 1     │ │   Shard 2   │ │   Shard 3   │
 │  Replica A/B  │ │ Replica A/B │ │ Replica A/B │
 └───────────────┘ └─────────────┘ └─────────────┘
            │                  │                  │
          ZooKeeper / ClickHouse Keeper ———— 集群协调层

9.3　节点类型与职责划分

9.4　安装与基础配置

一、安装方式

示例：

sudo apt install clickhouse-server clickhouse-client
sudo systemctl start clickhouse-server

二、配置目录结构

/etc/clickhouse-server/
 ├── config.xml                # 主配置文件
 ├── users.xml                 # 用户与资源配置
 ├── macros.xml                # 集群宏定义
 ├── metrika.xml               # ZooKeeper / Keeper 配置
 └── config.d/、users.d/       # 分片配置文件

9.5　ZooKeeper / ClickHouse Keeper 配置

集群的同步与副本管理依赖 Keeper 服务（早期为 ZooKeeper）。

示例配置（metrika.xml）：

<zookeeper>
  <node index="1">
    <host>keeper1</host>
    <port>9181</port>
  </node>
  <node index="2">
    <host>keeper2</host>
    <port>9181</port>
  </node>
  <node index="3">
    <host>keeper3</host>
    <port>9181</port>
  </node>
</zookeeper>

使用 ClickHouse Keeper 的场景下：

<keeper_server>
  <tcp_port>9181</tcp_port>
  <server_id>1</server_id>
  <raft_configuration>
    <server><id>1</id><hostname>ch1</hostname></server>
    <server><id>2</id><hostname>ch2</hostname></server>
    <server><id>3</id><hostname>ch3</hostname></server>
  </raft_configuration>
</keeper_server>

9.6　分布式表与宏配置

每个节点需要定义自身在集群中的角色：

<macros>
  <shard>1</shard>
  <replica>ch1</replica>
</macros>

分布式表定义：

CREATE TABLE hits_all AS hits_local
ENGINE = Distributed(my_cluster, default, hits_local, rand());

9.7　系统启动与进程管理

服务管理：

systemctl start clickhouse-server
systemctl status clickhouse-server
systemctl restart clickhouse-server

查看日志：

tail -f /var/log/clickhouse-server/clickhouse-server.log

检查端口：

ss -lntp | grep clickhouse

默认端口：

9.8　版本升级与平滑迁移

ClickHouse 的版本升级非常频繁（每月一个稳定版），但需遵循安全流程。

一、升级原则

1. 先备份数据目录与配置文件；
2. 跨版本升级不超过两步；
3. 先升级副本节点，再升级主节点；
4. 观察 system.mutations 和 system.parts 状态；
5. 保持 Keeper 集群一致。

二、在线升级示例

apt update
apt install --only-upgrade clickhouse-server clickhouse-client
systemctl restart clickhouse-server

可滚动升级整个集群节点以避免中断。

9.9　数据备份与恢复

ClickHouse 提供多层备份机制。

一、内置 BACKUP 命令（23.x 起）

BACKUP TABLE hits_local TO Disk('backup_disk', 'hits_backup/');
RESTORE TABLE hits_local FROM Disk('backup_disk', 'hits_backup/');

支持：

• S3 / NFS / Local；
• 压缩与增量备份；
• 跨节点恢复。

二、文件系统快照

通过 rsync、LVM Snapshot、zfs send 等进行物理复制。

三、异地备份策略

/data/clickhouse → /mnt/nfs/backup → S3(跨区域)

9.10　监控体系与指标采集

ClickHouse 内置 /metrics HTTP 接口，可与 Prometheus + Grafana 无缝对接。

一、Prometheus Exporter

scrape_configs:
  - job_name: 'clickhouse'
    static_configs:
      - targets: ['ch1:9363', 'ch2:9363', 'ch3:9363']

二、核心监控指标

三、Grafana Dashboard 推荐指标集

• QPS（Query Per Second）
• TopN 慢查询统计
• Merge 队列堆积趋势
• I/O 吞吐量监控
• 内存使用与 Swap 趋势
• ZooKeeper 延迟与队列长度
• 各分片数据量对比
• 分区增长趋势（数据膨胀检测）

9.11　日志体系与诊断文件

日志目录：

/var/log/clickhouse-server/
 ├── clickhouse-server.log     # 主日志
 ├── clickhouse-server.err.log # 错误日志
 ├── trace.log                 # 栈跟踪
 └── text_log/                 # SQL 执行日志

日志级别调整：

<logger>
  <level>information</level> <!-- trace, debug, information, warning, error -->
</logger>

实时查看执行 SQL：

grep Query /var/log/clickhouse-server/clickhouse-server.log

9.12　常见告警策略

9.13　自动化与容器化运维

一、Docker Compose 部署示例

version: '3'
services:
  clickhouse1:
    image: clickhouse/clickhouse-server:24.3
    ports:
      - "8123:8123"
      - "9000:9000"
    volumes:
      - ./data1:/var/lib/clickhouse
      - ./config:/etc/clickhouse-server/config.d

二、Kubernetes Operator

可通过官方 Operator 或 Altinity Operator 进行管理：

apiVersion: clickhouse.altinity.com/v1
kind: ClickHouseInstallation
metadata:
  name: ch-cluster
spec:
  configuration:
    clusters:
      - name: main
        layout:
          shardsCount: 2
          replicasCount: 2

支持：

• 自动伸缩；
• 滚动升级；
• 持久卷 PVC；
• 监控自动注入。

9.14　备份与灾难恢复策略

一、集群级灾备设计

推荐结构：

主集群（城市A）—— 异步复制 —— 灾备集群（城市B）

策略：

• 异地冷备（延迟同步）
• 定期全量 + 每日增量备份
• 通过对象存储同步元数据与数据块

二、快速恢复流程

1. 恢复 Keeper 元数据；
2. 恢复本地 Part 文件；
3. 执行 SYSTEM RELOAD CONFIG；
4. 重启服务验证一致性；
5. 检查 system.replicas 状态。

9.15　集群安全与访问控制

ClickHouse 支持多层安全防护：

示例：

<users>
  <analyst>
    <password>sha256_password_hash</password>
    <networks>
      <ip>::/0</ip>
    </networks>
    <profile>analyst_profile</profile>
    <quota>default</quota>
    <grants>
      <grant>SELECT ON analytics.*</grant>
    </grants>
  </analyst>
</users>

9.16　典型运维问题与解决方案

9.17　本章小结

• ClickHouse 集群运维核心包括安装、配置、监控、备份与容灾；
• Keeper（或 ZooKeeper）是元数据与副本协调中心；
• Prometheus + Grafana 是监控的事实标准；
• 告警体系需关注 Merge、Replica、内存、磁盘与网络；
• Kubernetes Operator 实现了 ClickHouse 的云原生自动化；
• 通过分层备份与异地灾备可保障企业级高可用；
• RBAC 与网络安全机制可确保数据访问合规与安全。

第十章　典型应用场景与架构实践（Real-world Use Cases & Architecture Patterns）

10.1　ClickHouse 的场景定位

ClickHouse 的核心优势在于：

• 高并发聚合计算能力（亿级数据秒级聚合）；
• 列式压缩 + 向量化执行；
• 近实时分析（Near-real-time Analytics）；
• 天然的分布式可扩展性。

因此，它非常适合以下类别的场景：

10.2　架构模式一：日志分析平台（Log Analytics）

一、场景特征

• 数据量极大（TB–PB 级）；
• 写入速率高（百万行/秒）；
• 读查询以时间过滤为主；
• 聚合维度多（IP、region、url、device）。

二、典型架构

Nginx/Fluent Bit → Kafka → ClickHouse (via Materialized View)
                                  ↓
                           Grafana / Kibana

三、表结构设计

CREATE TABLE access_logs
(
  event_time DateTime,
  host String,
  ip String,
  method LowCardinality(String),
  path String,
  status UInt16,
  bytes UInt64,
  user_agent String
)
ENGINE = MergeTree()
PARTITION BY toYYYYMMDD(event_time)
ORDER BY (event_time, host, ip);

四、查询示例

SELECT
  toStartOfMinute(event_time) AS minute,
  count() AS reqs,
  sum(bytes) AS traffic
FROM access_logs
WHERE event_time > now() - INTERVAL 1 HOUR
GROUP BY minute
ORDER BY minute;

五、优化技巧

• 按日期分区；
• 对 method, status 使用 LowCardinality；
• 使用 TTL 自动清理 30 天前数据；
• 通过 Kafka + MV 实现实时接入。

10.3　架构模式二：BI 报表与多维分析

一、场景特征

• 聚合维度多、交互复杂；
• 查询模式类似“星型模型”；
• 接入 Tableau / Superset / Power BI；
• 需要灵活的 GROUP BY 与 JOIN。

二、典型架构

ETL (Flink / Airflow)
       ↓
ClickHouse (OLAP Storage)
       ↓
BI 前端 (Superset / Metabase)

三、事实表与维表设计

CREATE TABLE sales_fact (
  date Date,
  region LowCardinality(String),
  product_id UInt32,
  revenue Float64
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(date)
ORDER BY (date, region, product_id);

CREATE TABLE product_dim (
  product_id UInt32,
  category String
) ENGINE = MergeTree()
ORDER BY product_id;

四、典型查询

SELECT category, sum(revenue) FROM sales_fact
JOIN product_dim USING (product_id)
WHERE date >= today() - 30
GROUP BY category;

五、优化要点

• 小维表常驻内存 (Join Engine)；
• 聚合表 / 物化视图预计算；
• 控制分区大小（按月或季度）；
• 使用视图封装业务逻辑。

10.4　架构模式三：实时监控与告警系统

一、场景特征

• 数据实时写入；
• 高速聚合与可视化；
• 数据窗口化统计（分钟级）。

二、架构示意

Prometheus → Kafka → ClickHouse → Grafana

三、表结构设计

CREATE TABLE metrics
(
  ts DateTime,
  instance String,
  metric String,
  value Float64
)
ENGINE = MergeTree()
PARTITION BY toYYYYMMDD(ts)
ORDER BY (metric, ts);

四、实时聚合物化视图

CREATE MATERIALIZED VIEW mv_metric_1m
TO metrics_minute AS
SELECT
  metric,
  toStartOfMinute(ts) AS minute,
  avg(value) AS avg_value
FROM metrics
GROUP BY metric, minute;

五、Grafana 查询模板

SELECT minute, avg_value FROM metrics_minute
WHERE metric = 'cpu_usage'
AND minute > now() - INTERVAL 1 HOUR;

六、优化点

• 启用 Kafka Engine + MV；
• 对常见指标预聚合；
• TTL 保留近 90 天数据；
• 使用 Buffer 表应对写峰值。

10.5　架构模式四：广告与推荐分析

一、业务需求

• 事件：曝光（impression）、点击（click）、转化（conversion）；
• 维度：用户、广告、素材、渠道；
• 指标：CTR、CVR、收益；
• 数据量：每日数百亿条。

二、架构

SDK → Kafka → ClickHouse (real-time analytics)
                      ↓
                  Hive / S3 (archive)

三、表结构

CREATE TABLE ad_events
(
  event_time DateTime,
  ad_id UInt32,
  user_id UInt64,
  event_type Enum8('impression' = 1, 'click' = 2, 'conversion' = 3),
  cost Float32
)
ENGINE = MergeTree()
PARTITION BY toYYYYMMDD(event_time)
ORDER BY (ad_id, event_time);

四、查询

SELECT
  ad_id,
  countIf(event_type = 'click') / countIf(event_type = 'impression') AS ctr,
  sum(cost) AS spend
FROM ad_events
WHERE event_time >= today() - 7
GROUP BY ad_id;