clickhouse到底有哪些吊炸天的优化？

ClickHouse 能被称为 "列式数据库的王者" 并非浪得虚名，它的性能之所以如此炸裂，背后是大量精妙绝伦的优化策略。下面我将从多个维度，尽可能详细地阐述 ClickHouse 的那些“吊炸天”的优化之处：

1. 列式存储的本质优势与 ClickHouse 的极致发挥

列式存储本身就为 ClickHouse 的高性能奠定了基础：

数据局部性 (Data Locality) 与 CPU Cache 命中率:
原理: 当你查询一个列时，所有该列的数据在磁盘上是连续存储的。这意味着 CPU 加载数据时，可以更高效地利用 CPU Cache。传统行式数据库为了读取一行数据，需要访问跨越多个列的数据，容易导致 Cache Miss。
ClickHouse 的极致: ClickHouse 充分利用这一点。即使是数据类型不同的列，也会被存储在独立的、按列组织的块中。查询时，只读取需要的列块，极大地减少了 I/O 和 CPU 的不必要工作。

数据压缩 (Data Compression) 与 I/O 节省:
原理: 同一列的数据通常具有更高的相似性，因此压缩效果更好。压缩比越高，磁盘 I/O 越少，数据传输也越快。
ClickHouse 的极致:
丰富的压缩算法: ClickHouse 支持多种压缩算法，如 LZ4, ZSTD, Delta, DoubleDelta, Gorilla, T64 等。你可以为不同的列选择最适合的压缩算法（例如，对于数值型字段选择 Delta 编码，对于字符串字段选择 LZ4 或 ZSTD）。
按块压缩: 数据不是一条一条地压缩，而是按数据块（Chunk）进行压缩。这使得在读取少量数据时，可以先解压整个块，然后从块中提取所需数据，平衡了压缩率和随机访问性能。
智能选择压缩算法: ClickHouse 的很多引擎（如 MergeTree 系列）在插入数据时，可以根据数据的特性（如数值范围、重复度等）自动选择更有效的压缩方式（例如，对于单调递增的整数，Delta 编码会非常有效）。

向量化执行 (Vectorized Execution / SIMD):
原理: CPU 的 SIMD (Single Instruction, Multiple Data) 指令集允许 CPU 使用一条指令同时处理多个数据项。向量化执行就是利用这一特性，将数据以向量（批量）的形式进行处理，而不是逐行处理。
ClickHouse 的极致: ClickHouse 的核心查询执行引擎就是基于向量化设计的。
批处理: 所有操作（过滤、聚合、计算等）都是对一组数据（一个向量）进行的。这意味着一个操作指令可以同时应用于多个数据行。
CPU 优化: 向量化操作能显著提高 CPU 的利用率，减少指令流水线的停滞。例如，一个简单的 SUM 操作，在向量化执行下，可以比逐行累加快几倍到几十倍。
Branch Prediction 友好: 向量化操作通常能减少分支预测的失败，进一步提升性能。

2. 查询优化与执行引擎的精妙设计

预聚合 (Preaggregation) 与物化视图 (Materialized Views):
原理: 对于经常需要进行聚合（如 COUNT, SUM, AVG）的查询，可以在数据写入时就进行预先聚合，生成汇总数据。这样在查询时，只需要读取聚合好的数据，无需再次扫描和计算。
ClickHouse 的极致:
物化视图: ClickHouse 的物化视图可以理解为一种特殊的表，它包含一个聚合函数和 GROUP BY 子句。当基表插入数据时，物化视图会自动更新。查询时，ClickHouse 可以自动将查询“路由”到物化视图，而不是基表，实现极速查询。
多级聚合: 可以创建多个物化视图，进行多级聚合，例如先按天聚合，再按周聚合，满足不同时间粒度的查询需求。

索引机制 (Indexes) 的创新与高效:
原理: 索引可以快速定位到满足条件的数据块，避免全表扫描。
ClickHouse 的极致:
主键 (Primary Key) / 数据跳数 (Data Skipping Indexes): ClickHouse 的 MergeTree 系列表引擎使用主键来物理排序数据。在数据块内部，还可以创建各种“数据跳数”索引，例如：
一二级索引 (Primary Key Index): 实际是 稀疏主键索引 (Sparse Primary Key Index)。它为数据块（通常是 8MB）的起始偏移量创建索引项。查询时，可以快速定位到可能包含目标数据的块范围，跳过大量不相关的数据块。
二级索引 (Secondary Indexes): ClickHouse 支持多种二级索引，例如：
MinMax 索引: 记录列在数据块内的最小值和最大值。用于过滤那些最小值或最大值就落在查询条件之外的数据块。
Set 索引: 记录列在数据块内的所有唯一值（通常是较小的集合）。用于过滤那些包含特定值的查询。
Bloom Filter 索引: 一种概率性数据结构，用于快速判断一个元素是否存在于集合中。对于存在性检查非常高效，但有误报率。
ngrambf_v1, tokenbf_v1 索引: 用于全文搜索或字符串匹配。
延迟物化 (Lazy Materialization): 当执行一个包含多个列的查询时，ClickHouse 只会加载并解压那些真正被查询所需要的列的数据。其他列的数据直到需要时才会被加载，减少了不必要的内存开销和 I/O。

查询计划优化 (Query Plan Optimization) 与剪枝 (Pruning):
原理: 数据库会分析查询语句，生成一个最优的执行计划。
ClickHouse 的极致:
谓词下推 (Predicate Pushdown): 将过滤条件尽可能早地应用到数据源（包括索引和压缩块）上，从而减少需要处理的数据量。
列剪枝 (Column Pruning): 只加载和处理查询中真正需要的列，这是 ClickHouse 列式存储的关键优势。
子查询优化: ClickHouse 能有效地处理子查询，并进行相应的优化。
JOIN 优化: 支持多种 JOIN 类型，并有针对性地优化。例如，对于小表 JOIN 大表，会采用 Broadcast JOIN 策略，将小表广播到所有节点；对于大表 JOIN 大表，则采用 Hash Join 或 Merge Join。

后台数据合并 (Background Data Merging) 与数据结构管理:
原理: MergeTree 系列引擎将数据按照主键排序后存储在独立的“数据部分”（Data Parts）中。随着数据的不断插入，会产生大量的小数据部分。为了提高查询性能并减少磁盘碎片，需要定期将这些小部分合并成较大的部分。
ClickHouse 的极致:
异步合并: 合并操作在后台异步进行，不影响前台的插入和查询。
智能合并策略: ClickHouse 的合并过程是智能的。它会根据数据部分的年龄、大小以及是否有重复数据（取决于主键设置）来决定合并策略，以最小化合并开销并最大化合并效果。
去重 (Deduplication): 如果主键包含能够唯一标识行的列，ClickHouse 在合并过程中可以自动去除重复的行。

3. 并行处理与分布式能力的强大支持

多线程并行执行 (Multithreaded Execution):
原理: 利用多核 CPU 的优势，将一个查询的不同阶段（如扫描、过滤、聚合、排序）并行化，或者将不同分片的数据并行处理。
ClickHouse 的极致: ClickHouse 的所有算子和操作都设计为高度并行的。
CPU 核心利用: ClickHouse 会充分利用服务器的所有 CPU 核心来执行查询。
任务分解: 一个复杂的查询会被分解成多个可以并行执行的小任务，并在不同的线程上同时运行。
SIMD 与多线程协同: 向量化执行的优势与多线程并行进一步结合，使得 ClickHouse 在拥有大量数据时能够爆发出惊人的速度。

分布式查询处理 (Distributed Query Processing):
原理: 当数据分布在多个节点上时，查询引擎需要能够协调这些节点，收集结果并返回给用户。
ClickHouse 的极致:
分布式表引擎: ClickHouse 提供 `Distributed` 表引擎，它允许你在一个节点上查询分布在多个其他节点上的数据，就像查询本地表一样。
查询路由与协调: 当你向一个集群的入口节点发起查询时，它会负责将查询分解，发送到所有包含所需数据的节点，并收集和汇总结果。这个过程是高效且透明的。
分片 (Sharding) 与副本 (Replication): ClickHouse 支持数据分片存储在不同的服务器上，并可以通过副本提供高可用性和读扩展性。分布式引擎能够有效地在这些分片和副本之间执行查询。

4. 内存管理与 I/O 调度的精细控制

内存数据结构 (InMemory Data Structures):
原理: 对于一些聚合操作或中间结果，使用内存中的数据结构（如哈希表、排序树）可以显著提高效率。
ClickHouse 的极致:
Hash 聚合: ClickHouse 在执行 GROUP BY 聚合时，通常会使用哈希表来存储中间结果，这比排序聚合更高效。
内存排序: 对于 ORDER BY 子句，如果内存足够，ClickHouse 会将数据加载到内存中进行排序。

零拷贝 (ZeroCopy) 或低拷贝 I/O:
原理: 尽量避免数据在用户空间和内核空间之间的不必要复制。
ClickHouse 的极致: ClickHouse 在某些情况下会利用 Linux 的 `splice()` 或其他机制来减少数据复制，直接将数据从磁盘读入网络缓冲区，或在内存之间移动。

异步 I/O 与事件驱动:
原理: 使用非阻塞 I/O 和事件循环来处理并发请求，避免线程阻塞。
ClickHouse 的极致: ClickHouse 的底层网络和存储引擎很多都采用了异步的 I/O 模型，能够更有效地处理大量并发连接和 I/O 操作。

5. 特殊场景的优化

MergeTree 系列引擎的强大:
MergeTree (主引擎): 核心引擎，提供数据按主键排序、分区、数据压缩和索引。
ReplacingMergeTree: 在合并时根据主键和一个指定列来替换重复数据。
SummingMergeTree: 在合并时对具有相同主键的行进行求和。
AggregatingMergeTree: 最强大的聚合引擎，允许你在插入数据时进行部分聚合，并在查询时完成最终聚合。
CollapsingMergeTree: 用于处理“加一”和“减一”的场景，如事件的开始和结束。

其他高效引擎:
Memory 引擎: 用于测试或内存中数据的小规模操作。
TinyLog / Log / StripeLog: 更简单的日志式存储引擎，适用于少量写入、大量读取的场景，或作为数据写入的临时缓冲。
Kafka / RabbitMQ / MySQL / PostgreSQL / HDFS / S3 等外部数据源的集成: ClickHouse 可以直接读取和查询这些外部数据源，并利用其自身的优化能力来加速查询。

总结来说，ClickHouse 的“吊炸天”优化体现在：

1. 极致的列式存储利用: 深度结合 SIMD、向量化执行，实现极高的 CPU 和 I/O 效率。
2. 强大的数据压缩与编码: 大幅减少 I/O 量，加速数据传输。
3. 智能索引与数据跳过: 精准定位数据，跳过大量无用数据块。
4. 预聚合与物化视图: 将计算前置，加速聚合类查询。
5. 高度并行的执行引擎: 最大化利用多核 CPU 资源。
6. 高效的分布式架构: 轻松扩展到 PB 级别数据。
7. 灵活且专业的引擎设计: 针对不同场景提供最优化的数据存储和处理方式。

正是这些技术的集大成，使得 ClickHouse 在分析型数据库领域拥有无与伦比的性能优势，能够处理海量数据并提供亚秒级的查询响应。

利益相关: OLAP查询引擎开发者，TPC-H 30TB榜单排名第一的系统的开发者之一。

先放结论: Clickhouse没有任何吊炸天的优化，它只是把论文和社区中大家都讨论过的那些优化技巧，很好地实现了一下而已。(本回答只讨论查询链路)

谈起数据库查询引擎或者大数据执行引擎，你一定听说过这些关键词：向量化、列式执行、SIMD、LLVM等等等。每个人都会讨论这些，但是很少有人能够把这些东西讲的很透彻。现在大部分生产用的查询引擎，还是最原始的火山模型那一套，顶多带个并行查询和LLVM-based code generation。很多产品都在PR稿子中宣传自己实现了向量化之类的技术、然后放个demo的测试结果，但是基本上经不起推敲。如果我们把现在所有讨论过的查询引擎优化技术的总分设定为100，那么大部分查询引擎只能得1分，clickhouse可以得30分。Clickhouse做的无非就是把这些技术一个一个地进行工程优化、实现到生产系统中。这不是我说的，这是clickhouse自己的文档说的[1]。

为什么会这样呢？我觉得是因为在数据库这个圈子，大家太在意一个概念是不是够新、算法是不是够优美，觉得“工程”是很trivial的东西。实际上，只需要招一些有性能优化、HPC经验的工程师做些简单分析，就能找到查询引擎的性能瓶颈，然后照着之前大家讨论过的那些概念去实现就好了。但是这东西不能上PPT、也不能发论文，所以在意的人不多。

举个例子，内存分配。很多人可能都做过系统内存分配的优化，大家一讨论内存分配都是tcmalloc之类的高大上得词。但是在OLAP查询引擎里，执行引擎是迭代式的、生成大量的中间结果。比如某个算子需要不断生成很多个长度20字节的内存块。实际上开发的时候只需要一次分配个16KB的内存、然后一块一块的去切，问题就解决了。这只是一个很小的开发技巧，不需要任何高大上的算法。

再举个例子，很多论文讨论用LLVM之类的代码生成工具去完整地生成一颗查询树的代码。有这个想法的人肯定没基于LLVM做过开发。先不说性能是否有优势，纯粹用LLVM开发复杂工程的工程难度是指数级别的，现实中不可实现。早在2011年的一篇文章，这个问题就已经有了结论[2]，但是现在学术圈还是讨论这个概念。

Clickhouse就是典型的不管概念是否听起来炫酷、只在乎性能的产品。比如clickhouse的hash agg，用模板实现了30多个版本，覆盖了最常见的group key的类型。这么做的目的就是为了减少一些类型判断的时间。Clickhouse的性能，就是大量类似的工程优化堆积起来的。

当然clickhouse也有缺陷。从我自己做过的测试来看，clickhouse主要关注单表优化，不能很好地处理复杂表达式和多表join的场景，而且在需要落盘的场景clickhouse也没有做过很好的优化。有些原因是clickhouse没有在这个点上花太多功夫，有些原因则是clickhouse的列式架构本身的限制。

下一个五年，希望自己能够有机会做出clickhouse这样的产品。

对了，clickhouse默认开8线程，当然快。

[1]Why ClickHouse is so fast?

[2] Sompolski, Juliusz, Marcin Zukowski, and Peter Boncz. "Vectorization vs. compilation in query execution." InProceedings of the Seventh International Workshop on Data Management on New Hardware, pp. 33-40. 2011.