查看原文
其他

为什么我们要从ES迁移到ClickHouse?

51CTO技术栈 2021-12-16

The following article is from 携程技术 Author Gavin Zhu

ElasticSearch 是一种基于 Lucene 的分布式全文搜索引擎,携程用 ES 处理日志,目前服务器规模 500+,日均日志接入量大约 200TB。



图片来自 Pexels


随着日志量不断增加,一些问题逐渐暴露出来:

  • 一方面 ES 服务器越来越多,投入的成本越来越高。

  • 另一方面用户的满意度不高,日志写入延迟、查询慢甚至查不出来的问题一直困扰着用户。


而从运维人员的角度看,ES 的运维成本较高,运维的压力越来越大。


为什么选择 ClickHouse


ClickHouse 是一款高性能列式分布式数据库管理系统,我们对 ClickHouse 进行了测试,发现有下列优势:


ClickHouse 写入吞吐量大,单服务器日志写入量在 50MB 到 200MB/s,每秒写入超过 60w 记录数,是 ES 的 5 倍以上。


在 ES 中比较常见的写 Rejected 导致数据丢失、写入延迟等问题,在 ClickHouse 中不容易发生。


查询速度快,官方宣称数据在 pagecache 中,单服务器查询速率大约在 2-30GB/s;没在 pagecache 的情况下,查询速度取决于磁盘的读取速率和数据的压缩率。经测试 ClickHouse 的查询速度比 ES 快 5-30 倍以上。


ClickHouse 比 ES 服务器成本更低:

  • 一方面 ClickHouse 的数据压缩比比 ES 高,相同数据占用的磁盘空间只有 ES 的 1/3 到 1/30,节省了磁盘空间的同时,也能有效的减少磁盘 IO,这也是 ClickHouse 查询效率更高的原因之一。

  • 另一方面 ClickHouse 比 ES 占用更少的内存,消耗更少的 CPU 资源。我们预估用 ClickHouse 处理日志可以将服务器成本降低一半。


相比 ES,ClickHouse 稳定性更高,运维成本更低。


ES 中不同的 Group 负载不均衡,有的 Group 负载高,会导致写 Rejected 等问题,需要人工迁移索引;在 ClickHouse 中通过集群和 Shard 策略,采用轮询写的方法,可以让数据比较均衡的分布到所有节点。


ES 中一个大查询可能导致 OOM 的问题;ClickHouse 通过预设的查询限制,会查询失败,不影响整体的稳定性。


ES 需要进行冷热数据分离,每天 200T 的数据搬迁,稍有不慎就会导致搬迁过程发生问题,一旦搬迁失败,热节点可能很快就会被撑爆,导致一大堆人工维护恢复的工作。


ClickHouse 按天分 Partition,一般不需要考虑冷热分离,特殊场景用户确实需要冷热分离的,数据量也会小很多,ClickHouse 自带的冷热分离机制就可以很好的解决。


ClickHouse 采用 SQL 语法,比 ES 的 DSL 更加简单,学习成本更低。


结合携程的日志分析场景,日志进入 ES 前已经格式化成 JSON,同一类日志有统一的 Schema,符合 ClickHouse Table 的模式。


日志查询的时候,一般按照某一维度统计数量、总量、均值等,符合 ClickHouse 面向列式存储的使用场景。


偶尔有少量的场景需要对字符串进行模糊查询,也是先经过一些条件过滤掉大量数据后,再对少量数据进行模糊匹配,ClickHouse 也能很好的胜任。


另外我们发现 90% 以上的日志没有使用 ES 的全文索引特性,因此我们决定尝试用 ClickHouse 来处理日志。


用 ClickHouse 处理日志


ClickHouse 高可用部署方案


①容灾部署与集群规划


我们采用多 Shards、2 Replicas 的方式,通过 Zookeeper 进行服务器间互相备份,允许一个 Shard 一台服务器 Down 机数据不丢失。


为了接入不同规模的日志,我们将集群分成 6 台、20 台两种规模的多个集群。

②跨 IDC 部署


借助于 ClickHouse 分布式表的特性,我们实现了跨集群搜索。携程有多个 IDC,日志分布在不同的 IDC。


为了避免跨 IDC 搬迁日志,我们在每个 IDC 都部署一套 ClickHouse,然后配置 ClickHouse 的跨 IDC 的 Cluster,创建分布式表,实现跨多个 IDC 数据搜索。


如下图所示:

③几个重要的参数说明


如下所示:
  • max_threads:32  #用于控制一个用户的查询线程数。

  • max_memory_usage:10000000000  #单个查询最多能够使用内存大小 9.31G。

  • max_execution_time:30  #单个查询最大执行时间。

  • skip_unavailable_shards:1  #在通过分布式表查询的时候,当某一个 Shard 无法访问时,其他 Shard 的数据仍然可以查询。


④踩过的坑


我们之前将 Cluster 的配置放在 config.d 的目录下,当 ClickHouse 意外重启后,发现查询分布式表时部分 Shard 访问不到的问题,因此我们现在不再使用 config.d 配置方式,Cluster 配置放在 metrika.xml 中。


消费数据到 ClickHouse


我们使用 gohangout 消费数据到 ClickHouse,关于数据写入的几点建议:

  • 采用轮询的方式写 ClickHouse 集群的所有服务器,保证数据基本均匀分布。

  • 大批次低频率的写入,减少 parts 数量,减少服务器 merge,避免 Too many parts 异常。通过两个阈值控制数据的写入量和频次,超过 10w 记录写一次或者 30s 写一次。

  • 写本地表,不要写分布式表,因为分布式表接收到数据后会将数据拆分成多个 parts,并转发数据到其它服务器,会引起服务器间网络流量增加、服务器 merge 的工作量增加,导致写入速度变慢,并且增加了 Too many parts 的可能性。

  • 建表时考虑 partition 的设置,之前遇到过有人将 partition 设置为 timestamp,导致插入数据一直报 Too many parts 的异常。我们一般按天分 partition。

  • 主键和索引的设置、数据的乱序等也会导致写入变慢。


数据展示


我们调研了像 Supperset、Metabase、Grafana 等几个工具,最终还是决定采用在 Kibana3 上开发支持 ClickHouse 实现图表展示。


主要原因是 Kibana3 这种强大的数据过滤功能,很多系统都不具备,另外也考虑到迁移到其他系统成本较高,用户短期内难以适应。


目前 K3 上几种常用的图表(terms、histogram、percentiles、ranges、table),我们都开发了对应的 ClickHouse 版本,用户体验与原版基本保持一直,查询效率经过优化大幅提升。


查询优化


Kibana 中的 Table Panel 用于显示日志的明细数据,一般查询最近 1 小时所有字段的数据,最终只展示前 500 条记录。这种场景对于 ClickHouse 来说非常不友好。


针对这个问题,我们将 table Panel 的查询分两次进行:

  • 第一次查询单位时间间隔的数据量,根据最终显示的数据量计算出合理查询的时间范围。

  • 第二次根据修正后的时间范围,结合 Table Panel 中配置的默认显示的 Column 查询明细数据。


经过这些优化,查询的时间可以缩短到原来的 1/60,查询的列可以减少 50%,最终查询数据量减少到原来的 1/120。


ClickHouse 提供了多种近似计算的方法,用于提供相对较高准确性的同时减少计算量。


使用 MATERIALIZED VIEW 或者 MATERIALIZED COLUMN 将计算量放在平常完成,也能有效降低查询的数据量和计算量。


Dashboard 迁移


因为 Kibana3 上的 Dashboard 很多,我们开发了一个 Dashboard 迁移工具,通过修改 kibana-init-* 索引中 Dashboard 的配置来进行 Dashboard 迁移。


接入 ClickHouse 的效果


目前我们一个集群的日志量 100T 左右(压缩前 600T 左右),ClickHouse 服务器主要监控指标如下:

ClickHouse 相对 ES 占用更少的内存。ES 为了提高查询效率会将很多数据放在内存中,如:segment 的索引数据、filter cache、field data cache、indexing buffer 等。


ES 内存的使用量与索引量、数据量、写入量、查询量等成正比。删除(下线)索引、迁移索引或者扩容是应对 ES 内存问题的常用手段。


但是删除(下线)索引导致用户希望保存更长时间数据的需求无法满足,而服务器扩容导致又了成本上升。


ClickHouse 的内存消耗主要包括内存型的 engine,数据索引,加载到内存中待计算的数据,搜索的结果等。在 ClickHouse 中日志的数据量和保存时间主要和磁盘有关。


相比 ES,ClickHouse 后至少可以节省 60% 的磁盘空间。

如上图所示,Netflow 的日志占用的磁盘空间 ClickHouse 是 ES 的 32%,CDN 日志占用磁盘空间 ClickHouse 是 ES 的 18%,Dblog 的日志 ClickHouse 是 ES 的 22.5%。


比较查询速度提升,ClickHouse 比 ES 提升了 4.4 倍到 38 倍不等,原来 ES 上查询不出来的问题基本得到了解决,查询慢的问题有了很大的提升。


Netflow 由于数据量非常大,导致 ES 无法查询,ClickHouse 中经过优化,查询耗时 29.5s,CDN 的查询 CK 和 ES 快 38 倍,dbLog 的查询 CK 比 ES 快 4.4 倍。


关于查询速度的对比,因为在生产环境,无法保证 ES 和 ClickHouse 的环境一样,ES 使用的是 40 核 256G 的服务器,一台服务器部署一个 ES 实例,单服务器数据量 3T 左右。


ClickHouse 采用的是 32 核 128G 的服务器,单服务器数据量大约 18T 左右,一台服务器部署一个 ClickHouse 实例。

用 ClickHouse 处理日志查询速度得到了很大的提升,基本解决了数据保存时间短的问题,用户使用体验也得到了提升。


我们预估使用现在 ES 日志集群 50% 的服务器资源就能就能够完成现有 ES 日志的处理,并能提供比现在更好的用户体验。


ClickHouse 基本运维


总体来说 ClickHouse 的运维比 ES 简单,主要包括以下几个方面的工作:


新日志的接入、性能优化。


过期日志的清理,我们通过一个定时任务每天删除过期日志的 partition。


ClickHouse 的监控,使用 ClickHouse-exporter+VictoriaMetrics+Grafana 的实现。


数据迁移,通过 ClickHouse 分布式表的特性我们一般不搬迁历史数据,只要将新的数据接入新集群,然后通过分布式表跨集群查询。


随着时间的推移,历史数据会被清理下线,当老集群数据全部下线后,新老集群的迁移就完成了。


确实需要迁移数据时,采用 ClickHouse_copier 或者复制数据的方式实现。


常见问题处理:


慢查询:通过 kill query 终止慢查询的执行,并通过前面提到的优化方案进行优化。


Too many parts 异常:Too many parts 异常是由于写入的 part 过多 part 的 merge 速度跟不上产生的速度。


导致 part 过多的原因主要包括几个方面:

  • 设置不合。

  • 小批量、高频次写 ClickHouse。

  • 写的是 ClickHouse 的分布式表。

  • ClickHouse 设置的 merge 线程数太少了。


无法启动:之前遇到过 ClickHouse 无法启动的问题。


主要包括两个方面:

  • 文件系统损坏,通过修复文件系统可以解决。

  • 某一个表的数据异常导致 ClickHouse 加载失败,可以删除异常数据后启动,也可以把异常的文件搬到 detached 目录,等 ClickHouse 起来后再 attach 文件恢复数据。


总结


将日志从 ES 迁移到 ClickHouse 可以节省更多的服务器资源,总体运维成本更低,而且提升了查询速度,特别是当用户在紧急排障的时候,这种查询速度的成倍提升,对用户的使用体验有明显的改善。


我们将继续致力于将 ES 的日志迁移到 ClickHouse,并优化日志查询性能,让 ClickHouse 在日志分析领域为用户提供更大的价值。


但是 ClickHouse 毕竟不是 ES,在很多业务场景中 ES 仍然不可替代,ClickHouse 也不仅只能处理日志,进一步深入研究 ClickHouse,让 ClickHouse 在更多领域发挥更大的价值,是我们一直努力的方向。

线上公开课预告


作者:Gavin Zhu

简介:携程软件技术专家,负责监控系统运维开发、ES 系统运维及 Clickhouse 技术应用推广及运维工作。

编辑:陶家龙

出处:转载自公众号携程技术(ID:ctriptech)

精彩文章推荐:

阿里技术专家:架构制图方法论
我写的代码,又被CTO骂了......
动图演示:如何彻底理解红黑树?
: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存