01 向量化引擎
在存储引擎的设计上，ClickHouse采用了基于列存储的存储结构设计。列存储在很多场景中极大地降低了数据分析过程中读取的数据量，图1展示了列存储相比于行存储减少数据量的原理。明显地，在宽表场景下，由于行存储在抽取某些列时必须读取该行的所有列，因此读取了大量无效的数据（图1种行存方案中未加▲的深色方块数据为无效的不参与计算的列），从而降低了读取效率。
▲图1 列存和行存的对比
在计算引擎的设计上,ClickHouse首次使用了向量化计算引擎。向量化计算引擎的计算原理如图2所示，借助CPU提供的SIMD技术，可以充分发挥现代计算机体系架构的优势，最大限度地压榨单机性能。
▲图2 SIMD加速原理示意图
而ClickHouse对单机性能的压榨，使得ClickHouse可以在单机部署的情况下处理非常大量的数据，在实际使用中，基本上百亿以下的数据表，都可以使用单机解决。这种程度的单机处理能力已经可以满足非常多企业的需要。这也很大程度上解决了传统大数据数仓带来的效率低和成本高的问题。
02 高效的数据压缩
列存储为ClickHouse带来的另一个非常明显的优势就是大幅度提高了数据压缩空间。列存储的本质是将同一列的数据存储在连续的空间，相比于行存储，列存储在连续的空间上更有规律。而规律的存储，带来了更大的压缩率。从而大幅减少压缩后的数据大小，极大地减少了磁盘的I/O时间。
作者在实际项目中，基本都能做到8:1的压缩比，即8T的数据只需要1T的存储空间即可。这个提高了计算效率的同时也降低了存储成本的。相比于Hadoop的三副本策略，存储成本大幅降低。
读者可能会存在这个疑问：Hadoop的三副本能保证数据不丢失，而ClickHouse的存储是无法保证数据不丢失的，那么二者是否不能放在一起比较？这个疑问是有一定道理的，二者应用场景不同，面临的问题也不同。Hadoop如果需要发挥能力，必须有一个庞大的集群来摊销低效率带来的额外处理时间，这意味着集群中任何一台机器出现故障，都有可能导致集群不可用，从概率学上看，假设一台机器的故障率是1%，那么100台机器中有一台出现故障的概率已经接近100%了。由此可见，在一个庞大的Hadoop集群中是必须考虑机器故障的。
而ClickHouse则不同，ClickHouse在设计时倾向于榨干单机性能，在很多场景下用单机解决问题。这种设计使得单机ClickHouse出现故障的概率只有1%，可以在一定程度上忽略机器故障。当然，具体场景需要读者依据业务需求进行分析，如果确实需要保证数据不丢失，可以使用RAID在物理层面提供保障，也可以使用ClickHouse提供的复制表从软件上来解决该问题。总之，ClickHouse提供了比较灵活的机制。
03 高效的I/O优化
超高的压缩率为ClickHouse带来到了更低的数据存储成本和更低的I/O时间，同时也带来了计算时的额外开销——解压。数据压缩后存储到磁盘上，意味着压缩的数据被读取后无法直接获取内容，也就无法参与分析的计算，必须经过解压还原原始数据，才可以参与计算分析。那么如何最大限度地减少压缩时间，甚至在数据被程序读取前就过滤掉一部分不相关的数据，成为具备压缩能力的存储引擎的一大挑战。
ClickHouse通过基于LSM技术的稀疏索引来应对这个挑战。通过LSM技术，保证数据写入磁盘前就已经按照要求做好了排序，这意味着数仓中非常常见的范围查询场景可以减少非常大量的I/O时间，从而提升查询速度。
本文摘编自《ClickHouse性能之巅：从架构设计解读性能之谜》，经出版方授权发布。（书号：9787111716587）转载请保留文章出处。
关于作者：陈峰，资深大数据专家和架构师，ClickHouse技术专家，滴普科技（2B领域独角兽）合伙人兼首席架构师。《ClickHouse性能之巅：从架构设计解读性能之谜》作者。
