导读: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 可以节省更多的�