干货 | 每天十亿级数据更新,秒出查询结果,ClickHouse在携程酒店的应用

  • 时间:
  • 浏览:2

本文转自 | 携程技术中心  作者 | 蔡岳毅

作者简介

蔡岳毅,携程酒店大数据高级研发经理,负责酒店数据智能平台研发,大数据技术创新工作。喜欢探索研究大数据的开源技术框架。

一、背景

1)携程酒店每天有上千表,累计十多亿数据更新,怎么才能 才能 保证数据更新过程中生产应用高可用;

2)每天有将近百万次数据查询请求,用户能不不 从粗粒度国家省份城市汇总不断下钻到酒店,房型粒度的数据,亲戚亲戚朋友往往无法对海量的明细数据做进一步层次的预聚合,少量的关键业务数据全部都不 好几亿数据关联权限,关联基础信息,根据用户场景获取不同维度的汇总数据;

3)为了让用户无论在app端还是pc端查询数据提供秒出的效果,亲戚亲戚朋友还要不断的探索,研究找到最大概的技术框架。

对此,亲戚亲戚朋友尝试过关系型数据库,但千万级表关联数据库基本上不太机会做到秒出,考虑过Sharding,但数据量大,各种成本都很高。热数据存储到ElasticSearch,但无法跨索引关联,意味不得不做宽表,机会权限,酒店信息会变,什么都有 每次要刷全量数据,不适用于大表更新,维护成本也很高。Redis键值对存储无法做到实时汇总,也测试过Presto,GreenPlum,kylin,真正让亲戚亲戚朋友停下来深入研究,不断的扩展使用场景的是ClickHouse。

二、ClickHouse介绍

ClickHouse是一款用于大数据实几点几分 析的列式数据库管理系统,而非数据库。通过向量化执行以及对cpu底层指令集(SIMD)的使用,它能不不 对海量数据进行并行解决,从而加快数据的解决速度。

主要优点有:

1)为了高效的使用CPU,数据不仅仅按列存储,一并还按向量进行解决;

2)数据压缩空间大,减少io;解决单查询高吞吐量每台服务器每秒最多数十亿行;

3)索引非B树型态,不还要满足最左原则;以后过滤条件在索引列饱蕴藏即可;即使在使用的数据不在 索引中,机会各种并行解决机制ClickHouse全表扫描的速度也快一点 ;

4)写入速度非常快,1000-1000M/s,对于少量的数据更新非常适用;

ClickHouse不不说万能的,正机会ClickHouse解决速度快,什么都有 也是还要为“快”付出代价。选取ClickHouse还要有下面注意以下几点:

1)不支持事务,不支持真正的删除/更新;

2)不支持高并发,官方建议qps为1000,能不不 通过修改配置文件增加连接数,因此在服务器足够好的情况汇报下;

3)sql满足日常使用1000%以上的语法,join写法比较特殊;最新版已支持这类sql的join,但性能不好;

4)尽量做10000条以上批量的写入,解决逐行insert或小批量的insert,update,delete操作,机会ClickHouse底层会不断的做异步的数据合并,会影响查询性能,你这些 在做实时数据写入的过回会尽量避开;

5)Clickhouse快是机会采用了并行解决机制,即使有一另二个查询,也会用服务器一半的cpu去执行,什么都有 ClickHouse只能支持高并发的使用场景,默认单查询使用cpu核数为服务器核数的一半,安装都不 自动识别服务器核数,能不不 通过配置文件修改该参数;

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

3.1 数据更新

亲戚亲戚朋友的主要数据源是Hive到ClickHouse,现在主要采用如下一种生活 法子:

1)Hive到MySql,再导入到ClickHouse

初期在DataX不支持hive到ClickHouse的数据导入,亲戚亲戚朋友是通过DataX将数据先导入mysql,再通过ClickHouse原生api将数据从mysql导入到ClickHouse。

为此亲戚亲戚朋友设计了一套全部的数据导入流程,保证数据从hive到mysql再到ClickHouse能自动化,稳定的运行,并保证数据在同步过程中线上应用的高可用。

2)Hive到ClickHouse

DataX现在支持hive到ClickHouse,亲戚亲戚朋友次要数据是通过DataX直接导入ClickHouse。但DataX暂时只支持导入,机会要保证线上的高可用,什么都有 仅仅导入是不够的,还还要继续依赖亲戚亲戚朋友上边的一套流程来做ReName,增量数据更新等操作。

针对数据高可用,亲戚亲戚朋友对数据更新机制做了如下设计:

3.1.1全量数据导入流程

全量数据的导入过程比较简单,仅还要将数据先导入到临时表中,导入完成以后,再通过对正式表和临时表进行ReName操作,将对数据的读取从老数据切换到新数据上来。

3.1.2增量数据的导入过程

增量数据的导入过程,亲戚亲戚朋友使用过有一另二个版本。

机会ClickHouse的delete操作过于沉重,什么都有 最早是通过删除指定分区,再把增量数据导入正式表的法子来实现的。

你这些 法子处在如下大问题:一是在增量数据导入的过程中,数据的准确性是不可保证的,机会增量数据越来越来越多,数据不可用的时间就越长;二是ClickHouse删除分区的动作,是在接收到删除指令以后内异步执行,执行完成时间是未知的。机会增量数据导入后,删除指令也还在异步执行中,会意味增量数据也会被删除。最新版的更新日志说已修复你这些 大问题。

针对以上情况汇报,亲戚亲戚朋友修改了增量数据的同步方案。在增量数据从Hive同步到ClickHouse的临时表以后,将正式表中数据反写到临时表中,因此通过ReName法子切换正式表和临时表。

通过以上流程,基本能不不 保证用户对数据的导入过程是无感知的。

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

机会数据量大,数据同步的一段话无缘无故性超时。为保证数据同步的每有一另二个过程全部都不 可监控的,亲戚亲戚朋友越来越使用ClickHouse提供的JDBC来执行数据同步一段话,所有的数据同步一段话全部都不 通过调用ClickHouse的RestfulAPI来实现的。

调用RestfulAPI的以后,能不不 指定本次查询的QueryID。在数据同步一段话超时的情况汇报下,通过轮询来获得某QueryID的执行进度。另有一另二个保证了整个查询过程的有序运行。在轮询的过程中,会对异常情况汇报进行记录,机会异常情况汇报冒出的频次超过阈值,JOB会通过短信给相关人员发出预警短信

3.3 服务器分布与运维

现在主要根据场景分国内,海外/供应商,实时数据,风控数据有一另二个集群。每个集群对应的两到三台服务器,相互之间做主备,系统系统进程内控 将查询请求分散到不同的服务器上做负载均衡。

以后某一台服务器冒出故障,通过配置界面修改某个集群的服务器节点,该集群的请求就不不落到有故障的服务器上。机会在某个时间段某个特定的数据查询量比较大,组建虚拟集群,将所有的请求分散到某些资源富足的物理集群上。

下3天计划把每个集群的两台机器分散到不同的机房,能不不 继续起到现有的主备,负载均衡的作用还能起到dr的作用。一并为了保障线上应用的高可用,亲戚亲戚朋友会实现自动健康检测机制,针对突发异常的服务器自动拉出亲戚亲戚朋友的虚拟集群。

亲戚亲戚朋友会监控每台服务器每天的查询量,每个一段话的执行时间,服务器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一般在1000%左右会冒出查询波动,CPU达到70%会冒出大范围的查询超时,什么都有 ClickHouse最关键的指标CPU要非常关注。亲戚亲戚朋友内控 对所有ClickHouse查询全部都不 监控,当冒出查询波动的之都不 有邮件预警。

9)查询测试Case有:100000W数据关联10000W数据再关联10000W数据sum有一另二个月间夜量返回结果:190ms;2.4亿数据关联10000W的数据group by有一另二个月的数据大概390ms。但ClickHouse不不说无所只能,查询一段话还要不断的调优,机会与查询条件有关,不同的查询条件表是左join还是右join也是很有讲究的。

五、总结

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

从使用的淬硬层 ,查询性能全部都不 数据库能相比的,从成本上也是远低于关系型数据库成本的,单机支撑40亿以上的数据查询毫无压力。与ElasticSearch,Redis相比ClickHouse能不不 满足亲戚亲戚朋友大次要使用场景。

亲戚亲戚朋友会继续更深入的研究ClickHouse,跟进最新的版本,一并也会继续保持对外界更好的开源框架的研究,尝试,寻找到更大概亲戚亲戚朋友的技术框架。

本文由

转载

发布在

ITPUB

,转载此文请保持文章全部性,并请附上文章来源(ITPUB)及本页链接。

原文链接:http://www.itpub.net/2019/07/05/2352/