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

  • 时间:
  • 浏览:3

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

作者简介

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

一、背景

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

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

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

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

二、ClickHouse介绍

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

主要优点有:

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

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

3)索引非B树形态,不时要满足最左原则;但会 我过滤条件在索引列含晒 晒 即可;即使在使用的数据什么都这么索引中,原困各种并行解决机制ClickHouse全表扫描的带宽也更快;

4)写入带宽非常快,500-500M/s,对于极少量的数据更新非常适用;

ClickHouse从不万能的,正原困ClickHouse解决带宽快,全都也是时要为“快”付出代价。确定ClickHouse时要有下面注意以下几点:

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

2)不支持高并发,官方建议qps为5000,还要能 通过修改配置文件增加连接数,但会 在服务器足够好的状态下;

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

4)尽量做50000条以上批量的写入,解决逐行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 服务器分布与运维

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

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

下半年计划把每个集群的两台机器分散到不同的机房,还要能 继续起到现有的主备,负载均衡的作用还能起到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一般在500%左右会出现查询波动,CPU达到70%会出现大范围的查询超时,全都ClickHouse最关键的指标CPU要非常关注。亲戚亲戚我们 歌词 实物对所有ClickHouse查询全是监控,当出现查询波动的并且会有邮件预警。

9)查询测试Case有:50000W数据关联50000W数据再关联5000W数据sum另另一个多多 月间夜量返回结果:190ms;2.4亿数据关联5000W的数据group by另另一个多多 月的数据共要390ms。但ClickHouse从不无所还要能了,查询说说时要不断的调优,原困与查询条件有关,不同的查询条件表是左join还是右join也是很有讲究的。

五、总结

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

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

亲戚亲戚我们 歌词 会继续更深入的研究ClickHouse,跟进最新的版本,一起去也会继续保持对外界更好的开源框架的研究,尝试,寻找到更共要亲戚亲戚我们 歌词 的技术框架。

本文由

转载

发布在

ITPUB

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

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