携程用ClickHouse轻松玩转每天十亿级数据更新

作者引见

蔡岳毅，携程酒店大数据高级研发经理，担任酒店数据智能平台研发，大数据技术创新工作。喜欢探求研讨大数据的开源技术框架。

一、背景

携程酒店每天有上千表，累计十多亿数据更新，如何保证数据更新过程中消费运用高可用；每天有将近百万次数据查询央求，用户可以从粗粒度国家省份城市汇总不断下钻到酒店，房型粒度的数据，我们往往无法对海量的明细数据做进一步层次的预聚合，大量的关键业务数据都是好几亿数据关联权限，关联基础信息，根据用户场景获取不同维度的汇总数据；为了让用户无论在app端还是pc端查询数据提供秒出的效果，我们需求不断的探求，研讨找到最合适的技术框架。

对此，我们尝试过关系型数据库，但千万级表关联数据库基本上不太能够做到秒出；思索过Sharding，但数据量大，各种成本都很高；热数据存储到ElasticSearch，但无法跨索引关联，导致不得不做宽表，由于权限，酒店信息会变，所以每次要刷全量数据，不适用于大表更新，维护成本也很高；Redis键值对存储无法做到实时汇总；也测试过Presto、GreenPlum、Kylin......

真正让我们停上去深化研讨，不断扩展运用场景的，是ClickHouse。

二、ClickHouse引见

ClickHouse是一款用于大数据实时分析的列式数据库管理系统，而非数据库。经过向量化执行以及对CPU底层指令集（SIMD）的运用，它可以对海量数据停止并行处理，从而加快数据的处理速度。

次要优点有：

为了高效的运用CPU，数据不只仅按列存储，同时还按向量停止处理；数据紧缩空间大，减少IO；处理单查询高吞吐量每台服务器每秒最多数十亿行；索引非B树结构，不需求满足最左准绳；只需过滤条件在索引列中包含即可；即便在运用的数据不在索引中，由于各种并行处理机制ClickHouse全表扫描的速度也很快；写入速度非常快，50-200M/s，对于大量的数据更新非常适用。

ClickHouse并非万能的，正由于ClickHouse处理速度快，所以也是需求为“快”付出代价。选择ClickHouse需求有下面留意以下几点：

不支持事务，不支持真正的删除/更新；不支持高并发，官方建议qps为100，可以经过修正配置文件添加衔接数，但是在服务器足够好的状况下；SQL满足日常运用80%以上的语法，join写法比较特殊；最新版已支持相似SQL的join，但功能不好；尽量做1000条以上批量的写入，避免逐行insert或小批量的insert，update，delete操作，由于ClickHouse底层会不断的做异步的数据合并，会影响查询功能，这个在做实时数据写入的时分要尽量避开；Clickhouse快是由于采用了并行处理机制，即便一个查询，也会用服务器一半的CPU去执行，所以ClickHouse不能支持高并发的运用场景，默许单查询运用CPU核数为服务器核数的一半，安装时会自动辨认服务器核数，可以经过配置文件修正该参数。

三、ClickHouse在酒店数据智能平台的实际

1、数据更新

我们的次要数据源是Hive到ClickHouse，如今次要采用如下两种方式：

① Hive到MySQL，再导入到ClickHouse

初期在DataX不支持Hive到ClickHouse的数据导入，我们是经过DataX将数据先导入MySQL，再经过ClickHouse原生API将数据从MySQL导入到ClickHouse。

为此我们设计了一套残缺的数据导入流程，保证数据从Hive到MySQL再到ClickHouse能自动化，波动的运转，并保证数据在同步过程中线上运用的高可用。

② Hive到ClickHouse

DataX如今支持Hive到ClickHouse，我们部分数据是经过DataX直接导入ClickHouse。但DataX暂时只支持导入，由于要保证线上的高可用，所以仅仅导入是不够的，还需求继续依赖我们下面的一套流程来做ReName，增量数据更新等操作。

针对数据高可用，我们对数据更新机制做了如下设计：

1）全量数据导入流程

全量数据的导入过程比较简单，仅需求将数据先导入到暂时表中，导入完成之后，再经过对正式表和暂时表停止ReName操作，将对数据的读取从老数据切换到新数据下去。

2）增量数据的导入过程

增量数据的导入过程，我们运用过两个版本。

由于ClickHouse的delete操作过于沉重，所以最早是经过删除指定分区，再把增量数据导入正式表的方式来完成的。

这种方式存在如下成绩：一是在增量数据导入的过程中，数据的准确性是不可保证的，假如增量数据越多，数据不可用的工夫就越长；

二是ClickHouse删除分区的动作，是在接收到删除指令之后内异步执行，执行完成工夫是未知的。假如增量数据导入后，删除指令也还在异步执行中，会导致增量数据也会被删除。最新版的更新日志说已修复这个成绩。

针对以下状况，我们修正了增量数据的同步方案。在增量数据从Hive同步到ClickHouse的暂时表之后，将正式表中数据反写到暂时表中，然后经过ReName方法切换正式表和暂时表。

经过以下流程，基本可以保证用户对数据的导入过程是无感知的。

2、数据导入过程的监控与预警

由于数据量大，数据同步的语句常常性超时。为保证数据同步的每一个过程都是可监控的，我们没有运用ClickHouse提供的JDBC来执行数据同步语句，一切的数据同步语句都是经过调用ClickHouse的RestfulAPI来完成的。

调用RestfulAPI的时分，可以指定本次查询的QueryID。在数据同步语句超时的状况下，经过轮询来获得某QueryID的执行进度。这样保证了整个查询过程的有序运转。在轮询的过程中，会对异常状况停止记录，假如异常状况出现的频次超过阈值，JOB会经过短信给相关人员发出预警短信。

3、服务器分布与运维

如今次要根据场景分国内，海外/供应商，实时数据，风控数据4个集群。每个集群对应的两到三台服务器，互相之间做主备，程序外部将查询央求分散到不同的服务器上做负载平衡。

假如某一台服务器出现缺点，经过配置界面修正某个集群的服务器节点，该集群的央求就不会落到有缺点的服务器上。假如在某个工夫段某个特定的数据查询量比较大，组建虚拟集群，将一切的央求分散到其他资源富于的物理集群上。

我们会监控每台服务器每天的查询量，每个语句的执行工夫，服务器CPU，内存相关目的，以便于及时调整服务器上查询量比较高的央求到其他服务器。

四、ClickHouse运用探求

我们在运用ClickHouse的过程中遇到过各种各样的成绩，总结出来供大家参考：

1）关闭Linux虚拟内存。在一次ClickHouse服务器内存耗尽的状况下，我们Kill掉占用内存最多的Query之后发现，这台ClickHouse服务器并没有如预期的那样恢复正常，一切的查询依然运转的非常缓慢。

经过查看服务器的各项目的，发现虚拟内存占用量异常。由于存在大量的物理内存和虚拟内存的数据交换，导致查询速度非常缓慢。关闭虚拟内存，并重启服务后，运用恢复正常。

2）为每一个账户添加join_use_nulls配置。ClickHouse的SQL语法是非标准的，默许状况下，以Left Join为例，假如左表中的一条记录在右表中不存在，右表的相应字段会前往该字段相应数据类型的默许值，而不是标准SQL中的Null值。对于习气了标准SQL的我们来说，这种前往值常常会形成困扰。

3）JOIN操作时一定要把数据量小的表放在左边，ClickHouse中无论是Left Join 、Right Join还是Inner Join永远都是拿着右表中的每一条记录到左表中查找该记录能否存在，所以右表必须是小表。

4）经过ClickHouse官方的JDBC向ClickHouse中批量写入数据时，必须控制每个批次的数据中触及到的分区的数量，在写入之前最好经过Order By语句对需求导入的数据停止排序。无序的数据或者数据中触及的分区太多，会导致ClickHouse无法及时的对新导入的数据停止合并，从而影响查询功能。

5）尽量减少JOIN时的左右表的数据量，必要时可以提早对某张表停止聚合操作，减多数据条数。有些时分，先GROUP BY再JOIN比先JOIN再GROUP BY查询工夫更短。

6）ClickHouse版本迭代很快，建议用去年的波动版，不能太激进，新版本我们在运用过程中遇到过一些bug，内存走漏，语法不兼容但也不报错，配置文件并发数修正后无法失效等成绩。

7）避免运用分布式表，ClickHouse的分布式表功能上性价比不如物理表高，建表分区字段值不宜过多，太多的分区数据导入过程磁盘能够会被打满。

8）服务器CPU普通在50%左右会出现查询波动，CPU达到70%会出现大范围的查询超时，所以ClickHouse最关键的目的CPU要非常关注。我们外部对一切ClickHouse查询都有监控，当出现查询波动的时分会有邮件预警。

9）查询测试Case有：6000W数据关联1000W数据再关联2000W数据sum一个月间夜量前往结果：190ms；2.4亿数据关联2000W的数据group by一个月的数据大概390ms。但ClickHouse并非无所不能，查询语句需求不断的调优，能够与查询条件有关，不同的查询条件表是左join还是右join也是很有讲究的。

五、总结

酒店数据智能平台从去年7月份试点，到如今80%以上的业务都已接入ClickHouse。满足每天十多亿的数据更新和近百万次的数据查询，支撑app功能98.3%在1秒内前往结果，pc端98.5%在3秒内前往结果。

从运用的角度，查询功能不是数据库能相比的，从成本上也是远低于关系型数据库成本的，单机支撑40亿以上的数据查询毫无压力。与ElasticSearch、Redis相比ClickHouse可以满足我们大部分运用场景。

我们会继续更深化研讨ClickHouse，跟进最新的版本，同时也会继续保持对外界更好的开源框架的研讨，尝试，寻觅到更合适我们的技术框架。

更多大数据架构、实战阅历，欢迎关注【大数据与机器学习】，等待与你一同长大！

不是qps上不去么

分享了

分享了

有空一起交流一下

看起来不错

只看文字不过瘾啊~