CLICK HOUSE

一、clickhouse简介

MPP架构的列式存储数据库（DBMS：Database Management System），能够使用 SQL 查询实时生成分析数据报告。ClickHouse的全称是Click Stream，Data WareHouse。

ClickHouse的全称由两部分组成，第一个是Click Stream点击流，第二个是数据仓库Data Ware House

clickhouse可以做用户行为分析，流批一体

线性扩展和可靠性保障能够原生支持 shard + replication

clickhouse没有走hadoop生态，采用 Local attached storage 作为存储

二、clickhouse特点

1、列式存储：

行式存储的好处：

想查找某个人所有的属性时，可以通过一次磁盘查找加顺序读取就可以；但是当想查所有人的年龄时，需要不停的查找，或者全表扫描才行，遍历的很多数据都是不需要的。

列式存储的好处

• 对于列的聚合、计数、求和等统计操作优于行式存储
• 由于某一列的数据类型都是相同的，针对于数据存储更容易进行数据压缩，每一列选择更优的数据压缩算法，大大提高了数据的压缩比重
• 数据压缩比更好，一方面节省了磁盘空间，另一方面对于cache也有了更大的发挥空间
• 列式存储不支持事务

2、DBMS功能：

几乎覆盖了标准 SQL 的大部分语法，包括 DDL 和 DML、，以及配套的各种函数；用户管理及权限管理、数据的备份与恢复

3、多样化引擎：

目前包括合并树、日志、接口和其他四大类20多种引擎。

4、高吞吐写入能力：

ClickHouse采用类LSM Tree的结构，数据写入后定期在后台Compaction。通过类 LSM tree的结构， ClickHouse在数据导入时全部是顺序append写，写入后数据段不可更改，在后台compaction时也是多个段merge sort后顺序写回磁盘。顺序写的特性，充分利用了磁盘的吞吐能力。

5、数据分区与线程及并行：

ClickHouse将数据划分为多个partition，每个partition再进一步划分为多个index granularity(索引粒度)，然后通过多个CPU核心分别处理其中的一部分来实现并行数据处理。在这种设计下， 单条 Query 就能利用整机所有 CPU。 极致的并行处理能力，极大的降低了查询延时。

所以， ClickHouse 即使对于大量数据的查询也能够化整为零平行处理。但是有一个弊端就是对于单条查询使用多cpu，就不利于同时并发多条查询。所以对于高 qps 的查询业务并不是强项。

6、ClickHouse 像很多 OLAP 数据库一样，单表查询速度优于关联查询，而且 ClickHouse的两者差距更为明显。

关联查询：clickhouse会将右表加载到内存。

三、clickhouse为什么快？

C++可以利用硬件优势

数据底层以列式存储

利用单节点的多核并行处理

为数据建立索引一级、二级、稀疏索引

使用大量的算法处理数据

支持向量化处理

预先设计运算模型-预先计算

分布式处理数据

⑤分布式架构

MPP架构，支持集群模式，支持数据分区、分片、副本。

1. 利用JIT提升数十倍查询性能

ClickHouse同时使用了Vectorize query execution（向量化执行）和Runtime code generation（运行时代码生成）。ClickHouse被大家所熟知的是向量行化执行，除此之外，其实它也用到了代码生成技术，这部分的好处主要是有助于L1和L2缓存重用，更好地利用编译器的优化，其中包括更好地执行分支预测，更好地利用cpu指令集。

JIT，Just-In-Time，即时编译是一种Runtime code generation技术。ClickHouse利用JIT可以获得数倍到数十倍的性能提升。

上图是现在CPU架构中各级储存的耗时，L1，L2缓存相比于内存和磁盘有20倍到200倍的性能提升。如果我们能很好的利用L1，L2缓存命中，从硬件角度会有非常大的提升。

从21.6版本开始就可以使用这个新特性了。JIT的基准编译时间在15ms左右，随着代码增长它会线性增长。第一种是在select里面有的表达式运算，ClickHouse会利用JIT去提升性能，普遍有1.5到3倍提升，特殊情况下能达到20倍。第二种是在聚合函数阶段去优化，普遍也有1到2倍提升。

高性能

• 基于shard+replica实现的线性扩展和高可靠

• 采用列式存储，数据类型一致，压缩性能更高

• 硬件利用率高，连续IO，提高了磁盘驱动器的效率

• 向量化引擎与SIMD提高了CPU利用率，多核多节点并行化大查询

不足：

• 不支持事务、异步删除与更新

• 不适用高并发场景

四、整体架构

clickhouse整体架构

我们依据数据的流向将Clickhouse的应用架构划分为4个层级。

数据接入层

提供了数据导入相关的服务及功能，按照数据的量级和特性我们抽象出三种Clickhouse导入数据的方式。

方式一：数仓应用层小表导入这类数据量级相对较小，且分布在不同的数据源如hdfs、es、hbase等，这时我们提供基于DataX自研的TaskPlus数据流转+调度平台导入数据，单分区数据无并发写入，多分区数据小并发写入，且能和线上任务形成依赖关系，确保导入程序的可靠性。

方式二：离线多维明细宽表导入这类数据一般是汇总层的明细数据或者是用户基于Hadoop生产的大量级数据，我们基于Spark开发了一个导入工具包，用户可以根据配置直接拉取hdfs或者hive上的数据到clickhouse，同时还能基于配置sql对数据进行ETL处理，工具包会根据配置集群的节点数以及Clickhouse集群负载情况(merges、processes)对local表进行高并发的写入，达到快速导数的目的。

方式三：实时多维明细宽表导入实时数据接入场景比较固定，我们封装了通用的ClickhouseSink，将app、pc、m三端每日百亿级的数据通过Flink接入clickhouse，ClickhouseSink也提供了batchSize(单次导入数据量)及batchTime(单次导入时间间隔)供用户选择。

数据存储层

数据存储层这里我们采用双副本机制来保证数据的高可靠，同时用nginx代理clickhouse集群，通过域名的方式进行读写操作，实现了数据均衡及高可靠写入，且对于域名的响应时间及流量有对应的实时监控，一旦响应速度出现波动或异常我们能在第一时间收到报警通知。

nginx_one_replication：代理集群一半节点即一个完整副本，常用于写操作，在每次提交数据时由nginx均衡路由到对应的shard表，当某一个节点出现异常导致写入失败时，nginx会暂时剔除异常节点并报警，然后另选一台节点重新写入。

nginx_two_replication：代理集群所有节点，一般用作查询和无副本表数据写入，同时也会有对于异常节点的剔除和报警机制。

数据服务层

• 对外：将集群查询统一封装为scf服务(RPC)，供外部调用。

• 对内：提供了客户端工具直接供分析师及开发人员使用。

数据应用层

• 埋点系统：对接实时clickhouse集群，提供秒级别的OLAP查询功能。

• 用户分析平台：通过标签筛选的方式，从用户访问总集合中根据特定的用户行为捕获所需用户集。

• BI：提供数据应用层的可视化展示，对接单分片多副本Clickhouse集群，可横向扩展。

五、核心概念

数据分片

数据分片是将数据进行横向切分，这是一种在面对海量数据的场景下，解决存储和查询瓶颈的有效手段，是一种分治思想的体现。

ClickHouse支持分片，而分片则依赖集群。每个集群由1到多个分片组成，而每个分片则对应了ClickHouse的1个服务节点。分片的数量上限取决于节点数量（1个分片只能对应1个服务节点）。ClickHouse并不像其他分布式系统那样，拥有高度自动化的分片功能。ClickHouse提供了本地表（Local Table）与分布式表（Distributed Table）的概念。一张本地表等同于一份数据的分片。而分布式表本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。这种设计类似数据库的分库和分表，十分灵活。例如在业务系统上线的初期，数据体量并不高，此时数据表并不需要多个分片。所以使用单个节点的本地表（单个数据分片）即可满足业务需求，待到业务增长、数据量增大的时候，再通过新增数据分片的方式分流数据，并通过分布式表实现分布式查询。这就好比一辆手动挡赛车，它将所有的选择权都交到了使用者的手中!

列式存储

1）如前所述，分析场景中往往需要读大量行但是少数几个列。在行存模式下，数据按行连续存储，所有列的数据都存储在一个block中，不参与计算的列在IO时也要全部读出，读取操作被严重放大。而列存模式下，只需要读取参与计算的列即可，极大的减低了IO cost，加速了查询。

2）同一列中的数据属于同一类型，压缩效果显著。列存往往有着高达十倍甚至更高的压缩比，节省了大量的存储空间，降低了存储成本。

3）更高的压缩比意味着更小的data size，从磁盘中读取相应数据耗时更短。

4）自由的压缩算法选择。不同列的数据具有不同的数据类型，适用的压缩算法也就不尽相同。可以针对不同列类型，选择最合适的压缩算法。

5）高压缩比，意味着同等大小的内存能够存放更多数据，系统cache效果更好。

官方数据显示，通过使用列存，在某些分析场景下，能够获得100倍甚至更高的加速效应。

向量化

ClickHouse不仅将数据按列存储，而且按列进行计算。传统OLTP数据库通常采用按行计算，原因是事务处理中以点查为主，SQL计算量小，实现这些技术的收益不够明显。但是在分析场景下，单个SQL所涉及计算量可能极大，将每行作为一个基本单元进行处理会带来严重的性能损耗：
1）对每一行数据都要调用相应的函数，函数调用开销占比高；
2）存储层按列存储数据，在内存中也按列组织，但是计算层按行处理，无法充分利用CPU cache的预读能力，造成CPU Cache miss严重；
3）按行处理，无法利用高效的SIMD指令；
ClickHouse实现了向量执行引擎（Vectorized execution engine），对内存中的列式数据，一个batch调用一次SIMD指令（而非每一行调用一次），不仅减少了函数调用次数、降低了cache miss，而且可以充分发挥SIMD指令的并行能力，大幅缩短了计算耗时。向量执行引擎，通常能够带来数倍的性能提升。
(SIMD全称Single Instruction Multiple Data，单指令多数据流，能够复制多个操作数，并把它们打包在大型寄存器的一组指令集。以同步方式，在同一时间内执行同一条指令。)

表

上层数据的视图展示概念 ,包括表的基本结构和数据

分区

ClickHouse支持PARTITION BY子句，在建表时可以指定按照任意合法表达式进行数据分区操作，比如通过toYYYYMM()将数据按月进行分区、toMonday()将数据按照周几进行分区、对Enum类型的列直接每种取值作为一个分区等。数据以分区的形式统一管理和维护一批数据!

副本

数据存储副本,在集群模式下实现高可用 , 简单理解就是相同的数据备份，在CK中通过复制集，我们实现保障了数据可靠性外，也通过多副本的方式，增加了CK查询的并发能力。这里一般有2种方式：（1）基于ZooKeeper的表复制方式；（2）基于Cluster的复制方式。由于我们推荐的数据写入方式本地表写入，禁止分布式表写入，所以我们的复制表只考虑ZooKeeper的表复制方案。