Gavin Zhu，携程软件技术专家，负责监控系统运维开发、ES系统运维及Clickhouse技术应用推广及运维工做。数据库
ElasticSearch是一种基于Lucene的分布式全文搜索引擎，携程用ES处理日志，目前服务器规模500+，日均日志接入量大约200TB。随着日志量不断增长，一些问题逐渐暴露出来：一方面ES服务器愈来愈多，投入的成本愈来愈高；另外一方面用户的满意度不高，日志写入延迟、查询慢甚至查不出来的问题一直困扰着用户；而从运维人员的角度看，ES的运维成本较高，运维的压力愈来愈大。性能优化
1、为何选择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来处理日志。
2、用ClickHouse处理日志
ClickHouse高可用部署方案
1）容灾部署与集群规划
咱们采用多Shards、2 Replicas的方式，经过Zookeeper进行服务器间互相备份，容许一个shard一台服务器down机数据不丢失。为了接入不一样规模的日志，咱们将集群分红6台、20台两种规模的多个集群。
2） 跨IDC部署
借助于ClickHouse分布式表的特性，咱们实现了跨集群搜索。携程有多个IDC，日志分布在不一样的IDC，为了不跨IDC搬迁日志，咱们在每一个IDC都部署一套ClickHouse，而后配置ClickHouse的跨IDC的Cluster，建立分布式表，实现跨多个IDC数据搜索，以下图所示：
3）几个重要的参数说明
-
max_threads：32 # 用于控制一个用户的查询线程数；
-
max_memory_usage：10000000000 #单个查询最多可以使用内存大小9.31G；
-
max_execution_time：30 #单个查询最大执行时间；
-
skip_unavailable_shards：1 # 在经过分布式表查询的时候，当某一个shard没法访问时，其余shard的数据仍然能够查询。
4） 踩过的坑
咱们以前将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迁移。
3、接入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日志的处理，并能提供比如今更好的用户体验。
4、ClickHouse基本运维
整体来讲ClickHouse的运维比ES简单，主要包括如下几个方面的工做：
1)新日志的接入、性能优化；
2) 过时日志的清理，咱们经过一个定时任务天天删除过时日志的partition；
3) ClickHouse的监控，使用ClickHouse-exporter+VictoriaMetrics+Grafana的实现；
4) 数据迁移，经过ClickHouse分布式表的特性咱们通常不搬迁历史数据，只要将新的数据接入新集群，而后经过分布式表跨集群查询。随着时间的推移，历史数据会被清理下线，当老集群数据所有下线后，新老集群的迁移就完成了。确实须要迁移数据时，采用ClickHouse_copier或者复制数据的方式实现。
5) 常见问题处理：
慢查询，经过kill query终止慢查询的执行，并经过前面提到的优化方案进行优化。
Too many parts异常：Too many parts异常是因为写入的part过多part的merge速度跟不上产生的速度，致使part过多的缘由主要包括几个方面：
-
设置不合理 ；
-
小批量、高频次写ClickHouse；
-
写的是ClickHouse的分布式表；
-
ClickHouse设置的merge线程数太少了。
没法启动：以前遇到过ClickHouse没法启动的问题，主要包括两个方面：
-
文件系统损坏，经过修复文件系统能够解决；
-
某一个表的数据异常致使ClickHouse加载失败，能够删除异常数据后启动，也能够把异常的文件搬到detached目录，等ClickHouse起来后再attach文件恢复数据。
5、总结
将日志从ES迁移到ClickHouse能够节省更多的服务器资源，整体运维成本更低，并且提高了查询速度，特别是当用户在紧急排障的时候，这种查询速度的成倍提高，对用户的使用体验有明显的改善。
咱们将继续致力于将ES的日志迁移到ClickHouse，并优化日志查询性能，让ClickHouse在日志分析领域为用户提供更大的价值。
可是ClickHouse毕竟不是ES，在不少业务场景中ES仍然不可替代；ClickHouse也不只只能处理日志，进一步深刻研究ClickHouse，让ClickHouse在更多领域发挥更大的价值，是咱们一直努力的方向。
做者丨Gavin Zhu 来源丨携程技术（ID:ctriptech) dbaplus社群欢迎广大技术人员投稿，投稿邮箱： editor@dbaplus.cn