架构探索之路-第一站-clickhouse | 京东云技术团队

京东云开发者
• 阅读 400

一、前言

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

本章以实时OALP引擎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查询(排除语法词法解析,优化等步骤)总结起来可以为以下两点:

  1. 磁盘读取数据到内存
  2. 内存中解析数据匹配结果返回

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

降低磁盘IO 原理 举例 列式
分布式 并行读取数据,降低单节点读取数据量 hive(texfile) 数据倾斜,网络耗时,资源浪费
列式存储 将每一列单独存储, 按需读取 hbase 适合列使用单一的业务

2. 架构

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

架构探索之路-第一站-clickhouse | 京东云技术团队

架构探索之路-第一站-clickhouse | 京东云技术团队

2.1 列式存储

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

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

架构探索之路-第一站-clickhouse | 京东云技术团队

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

2.2 block

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

2.3 LSM

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

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

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

  1. 每一批次数据写入,先记录日志, 保证高可用机制
  2. 记录日志之后存入内存排序, 后将有序结果写入磁盘,记录合并次数Level=0
  3. 定期将磁盘上Level=0或1的文件合并,并标记删除. 后续物理删除

2.4 索引

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

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

架构探索之路-第一站-clickhouse | 京东云技术团队

架构探索之路-第一站-clickhouse | 京东云技术团队

2.5 向量化执行

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

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

架构探索之路-第一站-clickhouse | 京东云技术团队

从左至右,距离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在实际生产中遇到的问题

2.1 zookeeper高负载影响

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

架构探索之路-第一站-clickhouse | 京东云技术团队

解决通用方案:

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

2.2 资源管控问题

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

易观性能对比: https://zhuanlan.zhihu.com/p/54907288

官网性能对比: https://clickhouse.com/

作者:京东科技 李丹枫

来源:京东云开发者社区 转载请注明来源

点赞
收藏
评论区
推荐文章
Wesley13 Wesley13
3年前
DDD分层架构最佳实践
还在单体应用的时候就是分层架构一说,我们用得最多的就是三层架构。而现在已经是微服务时代,在微服务架构模型比较常用的有几个,例如:整洁架构,CQRS(命令查询分离)以及六边形架构。每种架构模型都有自己的应用场景,但其核心都是“高内聚低耦合”原则。而运用领域驱动设计(DDD)理念以应对日常加速的业务变化对架构的影响,架构的边界越来越清晰,各司其职,这也符
Stella981 Stella981
3年前
Docker 部署SpringBoot项目不香吗?
  公众号改版后文章乱序推荐,希望你可以点击上方“Java进阶架构师”,点击右上角,将我们设为★“星标”!这样才不会错过每日进阶架构文章呀。  !(http://dingyue.ws.126.net/2020/0920/b00fbfc7j00qgy5xy002kd200qo00hsg00it00cj.jpg)  2
Wesley13 Wesley13
3年前
5 年前的 Dubbo,2 年前的 Spring Cloud,都输给了这个架构!
每年的QCon全球软件开发大会和ArchSummit全球架构师峰会,世界各地优秀的技术大佬们,在台上分享自己负责开发的项目,卓越的架构思想,引领着整个行业前进。作为一名开发工程师,及时掌握这些先进的方案和理念,对自己的成长是非常重要的,尤其是想要成为架构师的开发人员,如果仅仅是技术好,显然是做不了架构师的。曾有这样一位大厂的高级工程师去参加面试,
Wesley13 Wesley13
3年前
InfoQ 趋势报告:架构和设计领域技术演变详解
https://www.infoq.cn/article/R7lWXd0R4VFf3E0bB\38本文概述了我们对当前“架构和设计”领域的看法,这个领域侧重于基础设施模式、技术框架模式的实现,以及软件架构师必须掌握的设计流程和技能。关键要点:我们看到了“演化式架构”设计需求的增长,这种架构建立在可替换性设计和关注“胶水”
AMS 新闻视频广告的云原生容器化之路
作者卓晓光,腾讯广告高级开发工程师,负责新闻视频广告整体后台架构设计,有十余年高性能高可用海量后台服务开发和实践经验。目前正带领团队完成云原生技术栈的全面转型。吴文祺,腾讯广告开发工程师,负责新闻视频广告流量变现相关后台开发工作,熟悉云原生架构在生产实践中的应用,拥有多年高性能高可用后台服务开发经验。目前正推动团队积极拥抱云原生。陈宏钊,腾讯广告高级开发工程
互联网高可用架构探讨 | 京东云技术团队
在互联网架构设计中,高可用是必不可少的环节,要从网络架构、服务架构、数据架构以及软硬件架构等多方面来分析设计,是架构师必备的技能之一。
京东云开发者 京东云开发者
3个月前
探讨打造「高可用架构」秘籍
​背景高可用性的文章多如牛毛,看得人眼花缭乱。今天,咱们换个花样,以终为始,来聊聊如何实现系统业务的高可用性这个宏伟目标。本文覆盖高可用架构设计、常见架构模式、高可用开发运维、大促高可用保障、业务高可用、COE复盘等方面的理念和思考。高可用性是个宏大的主题