大数据处理之ClickHouse概述及架构参考（未完）

一、概述

中移某业务拨测系统基于业务数据拨测指标及日志的分析需要，随着Clickhouse在OLAP领域的快速崛起，以及一些特性考虑，比如：

数据量会很大，最好需要分布式；
支持实时写入，支持快速计算，在较短时间内能完成计算；
强大的sql能力，实时指标sql化；
人力有限，运维需要简单；
高效的压缩比存储，服务器有限，可以用更少的服务器存储更多的数据；

我们也考虑在环境中引入ClickHouse组件，协助flink加强日志数据分析；

在这里插入图片描述
ClickHouse是由俄罗斯IT公司Yandex为Yandex.Metrica开发的一个列式数据库管理系统，可实现联机分析处理（OLAP）；ClickHouse允许使用实时更新的SQL查询生成数据分析报告。该系统以高性能著称。官方称，ClickHouse的性能超过了同类其他列式数据库，单主机每秒可理数十亿行和几十千兆字节的数据。ClickHouse是CPU的，因为它的矢量化查询执行涉及相关的处理器指令和运行时代码生成。它充分利用所有可用的硬件，以最快的速度处理每个查询。单个查询的峰值处理性能超过每秒2 TB。该项目于2016年6月在Apache2许可下作为开源软件发布。它可作为开源SQL数据仓库。它包括以下功能：

处理具有数万亿行和数千列的表的列存储。
由于内置了复制功能，因此具有容错能力和读取扩展能力。可在数百个节点集群上运行，很容易地安装在单个服务器或虚拟机上。
通过物化视图进行出色的聚合。
解决实际问题的功能，如漏斗分析和最后一点查询。

官方网站：https://clickhouse.com/
GitHub：https://github.com/ClickHouse/ClickHouse，版本说明；
安装文档：https://clickhouse.com/docs/en/development/architecture
文档参考：https://clickhouse.com/blog

二、架构说明

在这里插入图片描述

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

2）优势

查询速度快，可高效的使用CPU，利用多核并行处理单个查询数据，不仅仅按列存储，同时还按向量进行处理；
数据压缩空间大，减少IO；处理单查询高吞吐量每台服务器每秒最多数十亿行；
索引非B树结构，不需要满足最左原则；只要过滤条件在索引列中包含即可；即使在使用的数据不在索引中，由于各种并行处理机制ClickHouse全表扫描的速度也很快；
写入速度非常快，50-200M/s，对于大量的数据更新非常适用。
内置数较多（例如IP转化，URL分析等，预估计算/HyperLoglog等）；

3）劣势

不支持事务，不支持真正的删除/更新，不支持UPDATE/DELETE操作
不支持高并发，官方建议qps为100，可以通过修改配置文件增加连接数，但是在服务器足够好的情况下；
SQL满足日常使用80%以上的语法，join写法比较特殊；最新版已支持类似SQL的join，但性能不好；
尽量做1000条以上批量的写入，避免逐行insert或小批量的insert，update，delete操作，因为ClickHouse底层会不断的做异步的数据合并，会影响查询性能，这个在做实时数据写入的时候要尽量避开；
Clickhouse快是因为采用了并行处理机制，即使一个查询，也会用服务器一半的CPU去执行，所以ClickHouse不能支持高并发的使用场景，默认单查询使用CPU核数为服务器核数的一半，安装时会自动识别服务器核数，可以通过配置文件修改该参数。
聚合结果必须小于一台机器的内存大小，否则失败

4）性能数据参考

单个查询吞吐量：如果数据被放置在page cache中，则一个不太复杂的查询在单个服务器上大约能够以2-10GB／s（未压缩）的速度进行处理（对于简单的查询，速度可以达到30GB／s）。如果数据没有在page cache中的话，那么速度将取决于你的磁盘系统和数据的压缩率。例如，如果一个磁盘允许以400MB／s的速度读取数据，并且数据压缩率是3，则数据的处理速度为1.2GB/s。这意味着，如果你是在提取一个10字节的列，那么它的处理速度大约是1-2亿行每秒。对于分布式处理，处理速度几乎是线性扩展的，但这受限于聚合或排序的结果不是那么大的情况下。
处理短查询的延时时间：数据被page cache缓存的情况下，它的延迟应该小于50毫秒(最佳情况下应该小于10毫秒)。否则，延迟取决于数据的查找次数。延迟可以通过以下公式计算得知：查找时间（10 ms） * 查询的列的数量 * 查询的数据块的数量。
处理大量短查询：ClickHouse可以在单个服务器上每秒处理数百个查询（在最佳的情况下最多可以处理数千个）。但是由于这不适用于分析型场景。建议每秒最多查询100次。
数据写入性能：建议每次写入不少于1000行的批量写入，或每秒不超过一个写入请求。当使用tab-separated格式将一份数据写入到MergeTree表中时，写入速度大约为50到200MB/s。如果您写入的数据每行为1Kb，那么写入的速度为50，000到200，000行每秒。如果您的行更小，那么写入速度将更高。为了提高写入性能，您可以使用多个INSERT进行并行写入，这将带来线性的性能提升。
其他参考：
count: 千万级别，500毫秒，1亿 800毫秒 2亿 900毫秒 3亿 1.1秒
group: 百万级别 200毫米，千万 1秒，1亿 10秒，2亿 20秒，3亿 30秒
join：千万-10万 600 毫秒，千万 -百万：10秒，千万-千万 150秒

在这里插入图片描述

2.2、其他应用参考

1）快手应用实践案例
在这里插入图片描述
上图中：通过一个路由进行分流到CH多集群处理，Ps还做一些类似“切面”“网关”做的工作。数据则是通过 mapreduce（无论是 hive、sparksql 还是其他）和 flink 进入clickhouse。Clickhouse在单表的情况下性能比多表join好很多，快手给出一些实践经验，更多参见：文章1；另外，如果是普通企业，上图结构就满足了，但快手由于业务量大，提出了Clickhouse on Hdfs 的方案，即存储和计算分离，存储使用hadoop hdfs。自己基于接口重写了 HdfsMergeTree实现。
在这里插入图片描述
2）案例2：

在这里插入图片描述
3）案例3：

4）案例4：

5）案例5：

在这里插入图片描述

三、部署配置

在这里插入图片描述

四、使用

五、FAQ

六、附录：

6.1、优化参考

关闭虚拟内存，物理内存和虚拟内存的数据交换，会导致查询变慢。
为每一个账户添加join_use_nulls配置，左表中的一条记录在右表中不存在，右表的相应字段会返回该字段相应数据类型的默认值，而不是标准SQL中的Null值。
JOIN操作时一定要把数据量小的表放在右边，ClickHouse中无论是Left Join 、Right Join还是Inner Join永远都是拿着右表中的每一条记录到左表中查找该记录是否存在，所以右表必须是小表。
批量写入数据时，必须控制每个批次的数据中涉及到的分区的数量，在写入之前最好对需要导入的数据进行排序。无序的数据或者涉及的分区太多，会导致ClickHouse无法及时对新导入的数据进行合并，从而影响查询性能。
尽量减少JOIN时的左右表的数据量，必要时可以提前对某张表进行聚合操作，减少数据条数。有些时候，先GROUP BY再JOIN比先JOIN再GROUP BY查询时间更短。
ClickHouse的分布式表性能性价比不如物理表高，建表分区字段值不宜过多，防止数据导入过程磁盘可能会被打满。
CPU一般在50%左右会出现查询波动，达到70%会出现大范围的查询超时，CPU是最关键的指标，要非常关注。

6.2、MySQL VS ClickHouse

MySQL单条SQL是单线程的，只能跑满一个core，ClickHouse相反，有多少CPU，吃多少资源，所以飞快；
ClickHouse不支持事务，不存在隔离级别。ClickHouse的定位是分析性数据库，而不是严格的关系型数据库。
IO方面，MySQL是行存储，ClickHouse是列存储，后者在count()这类操作天然有优势，同时，在IO方面，MySQL需要大量随机IO，ClickHouse基本是顺序IO。