性能炸裂的ClickHouse,入坑后会遇到哪些难题?

京东科技 李丹枫 2024-07-11 15:28:54

 

ClickHouse是一款开源的列式数据库管理系统,适用于在线分析处理(OLAP)场景,本文通过介绍ClickHouse,帮助读者今后快速地处理大规模数据,并获得实时的分析结果,为业务提供有力支持。

 
 

 

一、前言

 

架构,软件开发中最熟悉不过的名词,遍布在我们的日常开发工作中,大到项目整体,小到功能组件,想要实现高性能、高扩展、高可用的目标都需要优秀架构理念辅助。所以作者尝试剖析市面上那些经典优秀的开源项目,学习优秀的架构理念来积累架构设计的经验与思考,在后续日常工作中遇到相同问题时能有更深一层的认知。

 

本章以实时OLAP引擎ClickHouse(简称ck)为例,以其面向场景,架构设计,细节实现等方面来介绍,深度了解其如何成为了OLAP引擎中的性能之王。

 

二、ClickHouse简介

 

ClickHouse是俄罗斯Yandex(俄罗斯网络用户最多的网站)于2016年开源的一个用于联机分析(OLAP)的列式数据库管理系统,采用C++语言编写,主要用于在线分析处理查询,通过SQL查询实时生成分析数据报告。

 

主要面向场景是快速支持任意指标、任意维度并且可以在大数据量级下实现秒级反馈的Ad-hoc查询(即席查询)

 

三、ClickHouse架构原理

 

ClickHouse以其卓越的性能著称,在相关性能对比报告中,ck在单表SQL查询的性能是presto的2.3倍、impala的3倍、greenplum的7倍、hive的48倍。可以看出ck在单表查询是非常出色的,那么ck究竟是如何实现高效查询的呢?

 

 
1.引子

    

介绍ck查询原理之前先以最常见的mysql为例,一条简单的查询语句是如何执行的,然后再以ck架构师的角度去考虑ck应该如何优化。mysql查数据时会先从磁盘读出数据所在页(innodb存储单元) 到内存中,然后再从内存中返回查询结果,所以在我们的认知中sql查询(排除语法词法解析,优化等步骤)总结起来可以为以下两点:

 

  • 磁盘读取数据到内存

  • 内存中解析数据匹配结果返回

 

在现代计算机中,CPU参与运算的时间远小于磁盘IO的时间。所以现代OLAP引擎大部分也选择通过降低磁盘IO的手段来提高查询性能,举例如下:

 

 

 
2.架构

 

通过以上推导分析,我们可以得出OLAP查询瓶颈在于磁盘IO,那么ck的优化手段也是借鉴了以上措施,采用了MPP架构(大规模并行处理)+列式存储,拥有类似架构设计的其他数据库产品也有很多,为什么ck性能如此出众?接下来我们具体分析ck的核心特性,进一步体会ck架构师的巧妙的架构理念。

 

 

 

1)列式存储

 

  • 行式存储:把同一行数据放到同一数据块中,各个数据块之间连续存储。

  • 列式存储:把同一列数据放到同一数据块中,不同列之间可以分开存储。

 

图片

 

如同上述所讲,分析类查询往往只需要一个表里很少的几个字段,Column-Store只需要读取用户查询的column,而Row-Store读取每一条记录的时候会把所有column的数据读出来,在IO上Column-Store比Row-Store效率高得多,因此性能更好。
 

2)block

 

ClickHouse能处理的最小单位是block,block是一群行的集合,默认最大为8192行。因为每一列单独存储,因此每个数据文件相比于行式存储更有规律,通过对block采用LZ4压缩算法,整体压缩比大致可以8:1。可以看出,ClickHouse通过出色的压缩比与block结构实现了批处理功能,对比海量数据存储下每次处理1行数据的情况,大幅减少了IO次数,从而达到了存储引擎上的优化。

 

3)LSM

 

LSM的思想:对数据的修改增量保持在内存中,达到指定的限制后将这些修改操作批量写入到磁盘中,相比较于写入操作的高性能,读取需要合并内存中最近修改的操作和磁盘中历史的数据,即需要先看是否在内存中,若没有命中,还要访问磁盘文件。

 

LSM的原理:把一颗大树拆分成N棵小树,数据先写入内存中,随着小树越来越大,内存的小树会flush到磁盘中。磁盘中的树定期做合并操作,合并成一棵大树,以优化读性能。

 

ClickHouse通过LSM实现数据的预排序,从而减少磁盘的读取量。原理就是将乱序数据通过LSM在内存中排序,然后写入磁盘保存,并定期合并有重合的磁盘文件。ClickHouse的写入步骤可以总结为以下几点:

 

  • 每一批次数据写入,先记录日志,保证高可用机制

  • 记录日志之后存入内存排序,后将有序结果写入磁盘,记录合并次数Level=0

  • 定期将磁盘上Level=0或1的文件合并,并标记删除,后续物理删除

 

4)索引

 

ClickHouse的采用一级索引(稀疏索引)+二级索引(跳数索引)来实现索引数据定位与查询。一级索引记录每个block块的第一个,每次基于索引字段查询只需要确定查询第几个block块即可,避免一个查询遍历所有数据。如上述介绍,一个block块为8192行,那么1亿条数据只需要1万行索引,所以一级索引占用存储较小,可常驻内存,加速查询。二级索引由数据的聚合信息构建而成,根据索引类型的不同,其聚合信息的内容也不同,跳数索引的目的与一级索引一样,也是帮助查询时减少数据扫描的范围,原则都是“排除法”,即尽可能的排除那些一定不满足条件的索引粒度。

 

另一方面可以发现,因ck存储引擎按有序集合存储,所以在索引结构上,并不需要再利用B+树排序特性来定位。所以在实际使用过程中,也不需要满足最左原则匹配,只要过滤条件中包含索引列即可。

 

图片

图片

 

5)向量化执行

 

向量化计算(vectorization),也叫vectorized operation,也叫array programming,说的是一个事情:将多次for循环计算变成一次计算。为了实现向量化执行,需要利用CPU的SIMD指令。SIMD的全称是Single Instruction Multiple Data,即用单条指令操作多条数据。现代计算机系统概念中,它是通过数据并行以提高性能的一种实现方式 ( 其他的还有指令级并行和线程级并行 ),它的原理是在CPU寄存器层面实现数据的并行操作

 

在计算机系统的体系结构中,存储系统是一种层次结构。典型服务器计算机的存储层次结构如图6所示。一个实用的经验告诉我们,存储媒介距离CPU越近,则访问数据的速度越快。

 

图片

 

从左至右,距离CPU越远,则数据的访问速度越慢。从寄存器中访问数据的速度,是从内存访问数据速度的300倍,是从磁盘中访问数据速度的3000万倍。所以利用CPU向量化执行的特性,对于程序的性能提升意义非凡。ClickHouse目前利用SSE4.2指令集实现向量化执行。

 

四、ClickHouse总结  

 

 
1. ClickHouse的舍与得

    

ClickHouse在追求极致性能的路上,采取了很多优秀的设计。如上述讲的列存、批处理、预排序等等。但是架构都有两面性,从另一方面也带来了一些缺点。

 

  • 高频次实时写入方面,因ck会将批量数据直接落盘成小文件,高频写入会造成大量小文件生成与合并,影响查询性能。所以ck官方也是建议大批低频的写入,提高写入性能。实际场景中建议在业务与数据库之间引入一层数据缓存层,来实现批量写入。

  • 查询并发问题,ClickHouse是采用并行处理机制,即一个查询也会使用一半cpu去执行,在安装时会自动识别cpu核数,所以在发挥查询快的优势下,也带来了并发能力的不足。如果过多的查询数堆积达到max_concurrent_queries阈值,则会报出too many simultaneous queries异常,这也是ck的一种限流保护机制。所以日常使用过程中注意慢sql的排查,并发请求的控制是保证ck高可用的关键。

 

了解其原理之后,能够对ClickHouse有更深的认知,也能够解释生产工作中曾经遇到的问题,站在ClickHouse架构师的角度去合理使用,规避劣势,发挥其特性。

 

 
2.ClickHouse在实际生产中遇到的问题

    

1)zookeeper高负载影响

 

目前ClickHouse开源版本ReplicatedMergeTree引擎强依赖zookeeper完成多副本选主,数据同步,故障恢复等功能,zookeeper在负载较高的情况下,性能表现不佳,甚至会出现副本无法写入,数据无法同步问题。分析ClickHouse对zookeeper相关的使用,以副本复制流程为例,ck对zookeeper频繁地分发日志、数据交换是引起瓶颈原因之一。

 

图片

 

外界解决通用方案:

 

重新实现HaMergeTree引擎,降低对zookeeper日志的请求次数并减少存储的数据量,来达到降低对zookeeper的负载。

 

京东零售:自研基于Raft分布式共识算法的zookeeper替代方案。

 

2)资源管控问题

 

ClickHouse的资源管控能力不够完善,在 insert、select 并发高的场景下会导致执行失败,影响用户体验。这是因为社区版ClickHouse目前仅提供依据不同用户的最大内存控制,在超过阈值时会杀死执行的 query。

 

外界解决通用方案:开发资源管理组件,将并发、内存、CPU等资源拆分给不同的资源组,同时通过资源组的父子关系实现不同资源组共享部分资源的能力。


 
作者丨京东科技 李丹枫
来源丨公众号:京东技术(ID:jingdongjishu)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告