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

发布时间：2025-11-05 05:36:15 来源：创站工坊 作者：数据库

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

图片来自 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)

相关文章