文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

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

2024-12-03 18:48

关注

[[345865]]

 

图片来自 Pexels

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

而从运维人员的角度看,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 服务器成本更低:

④相比 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 数据搜索。

如下图所示:

 

③几个重要的参数说明

如下所示:

④踩过的坑

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

消费数据到 ClickHouse

 

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

数据展示

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

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

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

查询优化

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

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

经过这些优化,查询的时间可以缩短到原来的 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 无法启动的问题。

主要包括两个方面:

总结

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

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

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

 

作者:Gavin Zhu

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

编辑:陶家龙

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

 

来源:携程技术内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯