导航
在完成将公司日志数据从Elasticsearch(下称ES)转战到Clickhouse后,个人认为有必要将过程记录分享。限于篇幅及便于分类组织,我会以一个系列文章的形式记录:
- 01 《Elasticsearch vs Clickhouse》
- 02 《Clickhouse的基础知识扫盲》
- 03 《Clickhouse多分片多副本集群部署》
- 04 《Clickhouse表引擎选择和表结构设计》
- 05 《clickhouse高效数据处理工具vector》
- 06 《clickhouse的数据可视化工具clickvisual》
- 07 《kibana自定义插件跳转clickvisual》
- 08 《妙用clickvisual api实现用户自动管理》(敬请期待)
一、常见的日志解决方案ELK
跟大部分企业一样,在日志解决方案选型时,优先选择了业界成熟方案elk + kafka + beats;顾名思义,该方案是使用ES进行数据存储的。
二、现状与挑战
ES 是一种基于 Lucene 的分布式全文搜索引擎,我司用ES存储日志,目前服务器规模 20+,总容量6TB SSD+15TB HDD,日均日志接入量大约 2TB;数据按日期生成ES索引,按照既定的索引生命周期策略(iLM)进行冷热数据存放。
随着日志量的增加,ES集群的一些问题逐渐暴露:
- 资源成本问题:ES集群使用20+台规格为16c32g的服务器,总容量6TB SSD+20TB HDD。作为一个非利润部门的工具平台,占用的资源过多;
- 数据安全问题:出于资源成本考虑,没有开启数据副本功能(一旦开启,资源成本会成倍增加,且副本写入不是异步的,会影响数据写入速率),如此一来,存在数据丢失风险;
- 性能问题(查询超时或慢):因数据按日期生成ES索引且冷热分离,当用户查询冷数据或跨天查询数据时,经常会出现查询超时;
- 性能问题(写入延迟):因数据进行冷热分离,每天需将数据从热节点(SSD)迁移到冷节点(HDD),迁移过程中会占用大量的资源(譬如带宽、磁盘IO、ES队列等),期间会导致写入延迟。
站在运维人员的角度,资源成本和运维成本的增加,无疑压力是越来越大,亟需寻找优化方案
三、为什么选择Clickhouse
ClickHouse 是一款高性能列式分布式数据库管理系统,我们对 ClickHouse 进行了大量的资料搜集,发现有下列优势:
- ClickHouse 写入吞吐量大
单服务器日志写入量在 50MB 到 200MB/s,每秒写入超过 60w 记录数,是 ES 的 5 倍以上。在 ES 中比较常见的写 Rejected 导致数据丢失、写入延迟等问题,在 ClickHouse 中不容易发生。
- 查询速度快
官方宣称数据在 pagecache 中,单服务器查询速率大约在 2-30GB/s;没在 pagecache 的情况下,查询速度取决于磁盘的读取速率和数据的压缩率。经测试 ClickHouse 的查询速度比 ES 快 5-30 倍以上。
- 查询语法门槛低
ClickHouse的SQL语法与标准SQL语法基本相同,相对于ES的Lucene语法,学习门槛要更低,且在复杂的查询条件下表现更好
- ClickHouse 比 ES 服务器成本更低
一方面 ClickHouse 的数据压缩比比 ES 高,相同数据占用的磁盘空间只有 ES 的 1/3 到 1/30,节省了磁盘空间的同时,也能有效的减少磁盘 IO,这也是ClickHouse查询效率更高的原因之一。
Elasticsearch | Clickhouse | 说明 | |
版本 | 7.4.2 | 22.7.4 | |
分布式支持 | √ | √ | |
扩展性 | 高 | 中 | 增加节点后ES会自动均衡数据,CK需手工均衡数据 |
写入速度 | 慢 | 快 | |
数据压缩率 | 低 | 高 | |
精确匹配查询 | 一般 | 快 | |
模糊匹配查询 | 快 | 一般 | |
权限管理 | 支持 | 支持 | |
查询难度 | 高 | 低 | CK支持通用SQL语法 |
可视化支持 | 高 | 低 | |
维护难度 | 一般 | 一般 |
在了解Clickhouse的特点后,结合我司实际情况,决定使用Clickhouse代替ES存储日志数据。期间以Clickhouse为存储的新日志系统与ELK并行,数据同时写入ES和Clickhouse;同时在kibana添加入口以查询Clickhouse上的日志数据,以逐渐过渡到新日志系统。
下回预告
Clickhouse的基础知识扫盲,欢迎关注后续更新的系列文章~