ClickHouse原理解析与应用实践
最近这些年大数据发展迅猛，涌现出了一大批以Hadoop为核心的大数据组件，包括HBase、Hive、Pig、Flume、Spark等。我们公司在前些年也基于Hadoop构建了一套基于Kafka+Spark+HDFS+Mongo的数据系统，然而近几年却感觉这套系统越来越力不从心了。因为它主要是以T+1的模式，隔日进行清洗，少部分核心指标通过Spark Stream进行实时的、预定义的运算。难以满足业务部门提出的实时的、自定义维度的查询。因为一旦涉及到自定义维度，就不可避免地去查询明细数据，而通过Spark作业对明细数据进行运算和统计，其实时性又无法达到要求。
除此以外，这些组件都比较耗费服务器资源，为了保证高可用，不论HDFS或是Spark都是以至少3台以集群模式进行搭建，如此下来，往往需要几十台服务器，成本比较高。有时候需要为个别项目单独部署一套的时候，硬件成本就更高了。
在对当前市面上的处理大数据的组件进行了一番调研后，我们发现了Clickhouse这款实时查询性能极高的OLAP数据库。它背后的研发团队是俄罗斯的Yandex公司，它的核心产品是搜索引擎，Google是它的直接竞争对手。对我们而言，主要是看重了它的几点：1.海量数据的实时查询，减少预先定义维度的清洗过程；2.精简架构，不再使用Hadoop+Spark这样重的组件；3.使用简便，支持标准的SQL语法。
Clickhouse这款产品还比较新，所以市面上关于它的书籍也相对比较少，除了查看官方文档以外，就只有这么一本书了。相对官方文档的繁杂冗长，这本书相对系统，有一定深度又不过分讨论细节，通读完这本书，可以对ClickHouse有一个初步和较好的理解，然后再根据需要反复研读一下官方文档，可以学习得更快一些。
这本书共分为了11个章节。第1章主要介绍了数据分析的演变历史，以及Clickhouse出现的原由，和我们公司的诉求是类似的，只是我们没有实力自己研发；第2章讲了Clickhouse的基本架构，以及它为何如此之快：多主架构，数据本地运算，列式存储，算法优化等；第3章讲了Clickhouse的安装与部署，以及访问Clickhouse的客户端工具。
第4章、第5章，讲了Clickhouse支持的数据类型，数据表的基本操作，数据的写入、删除、修改，因为Clickhouse列式存储的特性，针对单行数据进行删除或修改是很重的操作，要谨慎执行，或者使用CollapsingMergeTree表引擎来实现修改、删除操作。第5章讲了常驻内存的数据字典。数据字典适合经常使用，且数据量不大的基础维度，可以减少和避免不必要的JOIN查询（常见的例如根据ID转名称等）。数据字典支持Uint型的主键，也支持复合主键，数据源可以是文件、数据库、Http等。
第6章、第7章是全书的重头戏，讲了ClickHouse的主要表引擎：MergeTree家族。第6章主要讲了MergeTree引擎的工作机制，以及文件合并的过程，相对底层；第7章讲了MergeTree家族下的其他表引擎：自动去重的ReplacingMergeTree、可进行Sum汇总的SummingMergeTree、自动执行Group操作的AggregatingMergeTree、用于支持删除和更新操作的CollapsingMergeTree、VersionedCallapsingMergeTree，以及支持副本的ReplicatedMergeTree。
第8章，讲了Clickhouse所支持的其他类型的表引擎，包括外部存储（MySQL、文件、Kafka、HDFS等）、内存（Memory、Set、Join）、日志（不支持索引、分区、并发读写）、接口（自身并不存储任何数据，而是像黏合剂一样可以整合其他的数据表。在使用这类表引擎的时候，不用担心底层的复杂性，它们就像接口一样，为用户提供了统一的访问界面，所以我将它们归为接口类表引擎）等。
第9章，是大家相对会比较熟悉的章节：基于SQL的数据查询，讲解了Clickhouse所支持的SQL语句，例如WITH、JOIN、GROUP BY，LIMIT，HAVING等。
第10章，讲了副本与分片。副本是指同一份数据在另一台服务器上复制一份，主要通过Replicated开头的表引擎实现，当使用副本时，两张表的数据将完全相同。使用副本的主要目的是防止数据丢失（通过增加数据存储的冗余来实现），同时可以提升查询的性能；而使用分片时，两个服务器上表的数据将完全不同，分片主要是为了解决数据表的容量问题，因为单台服务器的容量总是有限的。
第11章，主要是偏运维层面的，包括用户和权限管理，熔断机制，数据备份等；因为我们主要使用阿里云，这些操作阿里云后台可以解决大部分，所以不用细看，大概了解一下就可以了。
感谢阅读，希望这篇文章能给你带来帮助！