ClickHouse 架构概述

Posted 2021-12-28 东海陈光剑

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了ClickHouse 架构概述相关的知识，希望对你有一定的参考价值。

ClickHouse 简介

ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。

ClickHouse是 Yandex 开发的高性能开源分析数据库。最初，ClickHouse 是为Yandex.Metrica任务创建的，但逐渐在 Yandex 和其他公司中发现了许多用途。

OLAP场景的关键特征

绝大多数是读请求

数据以相当大的批次(> 1000行)更新，而不是单行更新;或者根本没有更新。

已添加到数据库的数据不能修改。

对于读取，从数据库中提取相当多的行，但只提取列的一小部分。

宽表，即每个表包含着大量的列

查询相对较少(通常每台服务器每秒查询数百次或更少)

对于简单查询，允许延迟大约50毫秒

列中的数据相对较小：数字和短字符串(例如，每个URL 60个字节)

处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)

事务不是必须的

对数据一致性要求低

每个查询有一个大表。除了他以外，其他的都很小。

查询结果明显小于源数据。换句话说，数据经过过滤或聚合，因此结果适合于单个服务器的RAM中。

很容易可以看出，OLAP场景与其他通常业务场景(例如,OLTP或K/V)有很大的不同，因此想要使用OLTP或Key-Value数据库去高效的处理分析查询场景，并不是非常完美的适用方案。例如，使用OLAP数据库去处理分析请求通常要优于使用MongoDB或Redis去处理分析请求。

ClickHouse的特性

真正的列式数据库管理系统

在一个真正的列式数据库管理系统中，除了数据本身外不应该存在其他额外的数据。这意味着为了避免在值旁边存储它们的长度«number»，你必须支持固定长度数值类型。例如，10亿个UInt8类型的数据在未压缩的情况下大约消耗1GB左右的空间，如果不是这样的话，这将对CPU的使用产生强烈影响。即使是在未压缩的情况下，紧凑的存储数据也是非常重要的，因为解压缩的速度主要取决于未压缩数据的大小。

这是非常值得注意的，因为在一些其他系统中也可以将不同的列分别进行存储，但由于对其他场景进行的优化，使其无法有效的处理分析查询。例如：HBase，BigTable，Cassandra，HyperTable。在这些系统中，你可以得到每秒数十万的吞吐能力，但是无法得到每秒几亿行的吞吐能力。

需要说明的是，ClickHouse不单单是一个数据库，它是一个数据库管理系统。因为它允许在运行时创建表和数据库、加载数据和运行查询，而无需重新配置或重启服务。

数据压缩

在一些列式数据库管理系统中(例如：InfiniDB CE 和 MonetDB) 并没有使用数据压缩。但是, 若想达到比较优异的性能，数据压缩确实起到了至关重要的作用。

除了在磁盘空间和CPU消耗之间进行不同权衡的高效通用压缩编解码器之外，ClickHouse还提供针对特定类型数据的专用编解码器，这使得ClickHouse能够与更小的数据库(如时间序列数据库)竞争并超越它们。

数据的磁盘存储

许多的列式数据库(如 SAP HANA, Google PowerDrill)只能在内存中工作，这种方式会造成比实际更多的设备预算。

ClickHouse被设计用于工作在传统磁盘上的系统，它提供每GB更低的存储成本，但如果可以使用SSD和内存，它也会合理的利用这些资源。

多核心并行处理

ClickHouse会使用服务器上一切可用的资源，从而以最自然的方式并行处理大型查询。

多服务器分布式处理

上面提到的列式数据库管理系统中，几乎没有一个支持分布式的查询处理。

在ClickHouse中，数据可以保存在不同的shard上，每一个shard都由一组用于容错的replica组成，查询可以并行地在所有shard上进行处理。这些对用户来说是透明的

支持SQL

ClickHouse支持一种基于SQL的声明式查询语言，它在许多情况下与ANSI SQL标准相同。

支持的查询GROUP BY, ORDER BY, FROM, JOIN, IN以及非相关子查询。

相关(依赖性)子查询和窗口函数暂不受支持，但将来会被实现。

向量引擎

为了高效的使用CPU，数据不仅仅按列存储，同时还按向量(列的一部分)进行处理，这样可以更加高效地使用CPU。

实时的数据更新

ClickHouse支持在表中定义主键。为了使查询能够快速在主键中进行范围查找，数据总是以增量的方式有序的存储在MergeTree中。因此，数据可以持续不断地高效的写入到表中，并且写入的过程中不会存在任何加锁的行为。

索引

按照主键对数据进行排序，这将帮助ClickHouse在几十毫秒以内完成对数据特定值或范围的查找。

适合在线查询

在线查询意味着在没有对数据做任何预处理的情况下以极低的延迟处理查询并将结果加载到用户的页面中。

支持近似计算

ClickHouse提供各种各样在允许牺牲数据精度的情况下对查询进行加速的方法：

用于近似计算的各类聚合函数，如：distinct values, medians, quantiles

基于数据的部分样本进行近似查询。这时，仅会从磁盘检索少部分比例的数据。

不使用全部的聚合条件，通过随机选择有限个数据聚合条件进行聚合。这在数据聚合条件满足某些分布条件下，在提供相当准确的聚合结果的同时降低了计算资源的使用。

Adaptive Join Algorithm

ClickHouse支持自定义JOIN多个表，它更倾向于散列连接算法，如果有多个大表，则使用合并-连接算法

支持数据复制和数据完整性

ClickHouse使用异步的多主复制技术。当数据被写入任何一个可用副本后，系统会在后台将数据分发给其他副本，以保证系统在不同副本上保持相同的数据。在大多数情况下ClickHouse能在故障后自动恢复，在一些少数的复杂情况下需要手动恢复。

角色的访问控制

ClickHouse使用SQL查询实现用户帐户管理，并允许角色的访问控制，类似于ANSI SQL标准和流行的关系数据库管理系统。

限制

没有完整的事务支持。

缺少高频率，低延迟的修改或删除已存在数据的能力。仅能用于批量删除或修改数据，但这符合 GDPR。

稀疏索引使得ClickHouse不适合通过其键检索单行的点查询。

性能

根据Yandex的内部测试结果，ClickHouse表现出了比同类可比较产品更优的性能。许多其他的测试也证实这一点。你可以使用互联网搜索到它们，或者你也可以从我们收集的部分相关连接中查看。

单个大查询的吞吐量

吞吐量可以使用每秒处理的行数或每秒处理的字节数来衡量。如果数据被放置在page cache中，则一个不太复杂的查询在单个服务器上大约能够以2-10GB／s（未压缩）的速度进行处理（对于简单的查询，速度可以达到30GB／s）。

如果数据没有在page cache中的话，那么速度将取决于你的磁盘系统和数据的压缩率。例如，如果一个磁盘允许以400MB／s的速度读取数据，并且数据压缩率是3，则数据的处理速度为1.2GB/s。这意味着，如果你是在提取一个10字节的列，那么它的处理速度大约是1-2亿行每秒。

对于分布式处理，处理速度几乎是线性扩展的，但这受限于聚合或排序的结果不是那么大的情况下。

处理短查询的延迟时间

如果一个查询使用主键并且没有太多行(几十万)进行处理，并且没有查询太多的列，那么在数据被page cache缓存的情况下，它的延迟应该小于50毫秒(在最佳的情况下应该小于10毫秒)。

否则，延迟取决于数据的查找次数。如果你当前使用的是HDD，在数据没有加载的情况下，查询所需要的延迟可以通过以下公式计算得知：查找时间（10 ms） * 查询的列的数量 * 查询的数据块的数量。

处理大量短查询的吞吐量

在相同的情况下，ClickHouse可以在单个服务器上每秒处理数百个查询（在最佳的情况下最多可以处理数千个）。但是由于这不适用于分析型场景。因此我们建议每秒最多查询 100次。

数据的写入性能

我们建议每次写入不少于1000行的批量写入，或每秒不超过一个写入请求。当使用tab-separated格式将一份数据写入到MergeTree表中时，写入速度大约为50到200MB/s。如果您写入的数据每行为1Kb，那么写入的速度为50，000到200，000行每秒。如果您的行更小，那么写入速度将更高。为了提高写入性能，您可以使用多个INSERT进行并行写入，这将带来线性的性能提升。

ClickHouse 架构概述

ClickHouse 整体架构图如下：

ClickHouse 是一个真正的列式数据库管理系统（DBMS)。

在 ClickHouse 中，数据始终是按列存储的，包括矢量（向量或列块）执行的过程。只要有可能，操作都是基于矢量进行分派的，而不是单值，这被称为«矢量化查询执行»（SIMD），它有利于降低实际的数据处理开销。

矢量执行的思想，可以追溯到 APL 编程语言及其后代：A +、J、K 和 Q。

矢量编程被大量用于科学数据处理中。在关系型数据库中，矢量编程也被大量用于 Vectorwise 系统中。

两种加速查询处理的方法：矢量化查询执行和运行时代码生成。

运行时代码生成: 动态地为每一类查询生成代码，消除了间接分派和动态分派。运行时代码生成可以更好地将多个操作融合在一起，从而充分利用 CPU 执行单元和流水线。

矢量化查询执行不是特别实用，因为它涉及必须写到缓存并读回的临时向量。

如果 L2 缓存容纳不下临时数据，那么这将成为一个问题。但矢量化查询执行更容易利用 CPU 的 SIMD 功能。

将两种方法结合起来是更好的选择: ClickHouse 使用了矢量化查询执行，同时初步提供了有限的运行时动态代码生成。

列（Columns）

表示内存中的列（实际上是列块），使用 IColumn 接口。该接口提供了用于实现各种关系操作符的方法。操作都是不可变的：这些操作不会更改原始列，但会创建一个新的修改后的列。比如，IColumn::filter 方法接受过滤字节掩码，用于 WHERE 和 HAVING 关系操作符中。

另外的例子：IColumn::permute 方法支持 ORDER BY 实现，IColumn::cut 方法支持 LIMIT 实现等等。

不同的 IColumn 实现（ColumnUInt8、ColumnString 等）负责不同的列内存布局。内存布局通常是一个连续的数组。对于数据类型为整型的列，只是一个连续的数组，比如 std::vector。对于 String 列和 Array 列，则由两个向量组成：其中一个向量连续存储所有的 String 或数组元素，另一个存储每一个 String 或 Array 的起始元素在第一个向量中的偏移。而 ColumnConst 则仅在内存中存储一个值，但是看起来像一个列。

字段（Field）

用 Field 处理单个值。Field 是 UInt64、Int64、Float64、String 和 Array 组成的联合。IColumn 拥有 operator[] 方法来获取第 n 个值成为一个 Field，同时也拥有 insert 方法将一个 Field 追加到一个列的末尾。这些方法并不高效，因为它们需要处理表示单一值的临时 Field 对象，但是有更高效的方法比如 insertFrom 和 insertRangeFrom 等。

Field 中并没有足够的关于一个表（table）的特定数据类型的信息。比如，UInt8、UInt16、UInt32 和 UInt64 在 Field 中均表示为 UInt64。

数据类型

IDataType 负责序列化和反序列化：读写二进制或文本形式的列或单个值构成的块。IDataType 直接与表的数据类型相对应。比如，有 DataTypeUInt32、DataTypeDateTime、DataTypeString 等数据类型。

块（Block）

Block 是表示内存中表的子集（chunk）的容器，是由三元组：(IColumn, IDataType, 列名) 构成的集合。在查询执行期间，数据是按 Block 进行处理的。

Block 用于处理数据块。对于相同类型的计算，列名和类型对不同的块保持相同，仅列数据不同。最好把块数据（block data）和块头（block header）分离开来，因为小块大小会因复制共享指针和列名而带来很高的临时字符串开销。

块流（Block Streams）

块流用于处理数据。我们可以使用块流从某个地方读取数据，执行数据转换，或将数据写到某个地方。IBlockInputStream 具有 read 方法，其能够在数据可用时获取下一个块。IBlockOutputStream 具有 write 方法，其能够将块写到某处。

块流负责：读或写一个表。表仅返回一个流用于读写块。

完成数据格式化。

执行数据转换。

格式（Formats）

数据格式同块流一起实现。既有仅用于向客户端输出数据的"展示"格式，如 IBlockOutputStream 提供的 Pretty 格式，也有其它输入输出格式，比如 TabSeparated 或 JSONEachRow。

I/O

对于面向字节的输入输出，有 ReadBuffer 和 WriteBuffer 这两个抽象类。它们用来替代 C++ 的 iostream。不用担心：每个成熟的 C++ 项目都会有充分的理由使用某些东西来代替 iostream。

ReadBuffer 和 WriteBuffer 由一个连续的缓冲区和指向缓冲区中某个位置的一个指针组成。

ReadBuffer 和 WriteBuffer 的实现用于处理文件、文件描述符和网络套接字（socket），也用于实现压缩（CompressedWriteBuffer 在写入数据前需要先用一个 WriteBuffer 进行初始化并进行压缩）和其它用途。ReadBuffer 和 WriteBuffer 仅处理字节。为了实现格式化输入和输出（比如以十进制格式写一个数字），ReadHelpers 和 WriteHelpers 头文件中有一些辅助函数可用。

表（Tables）

表由 IStorage 接口表示。该接口的不同实现对应不同的表引擎。比如 StorageMergeTree、StorageMemory 等。这些类的实例就是表。

IStorage 中最重要的方法是 read 和 write，除此之外还有 alter、rename 和 drop 等方法。read 方法接受如下参数：需要从表中读取的列集，需要执行的 AST 查询，以及所需返回的流的数量。read 方法的返回值是一个或多个 IBlockInputStream 对象，以及在查询执行期间在一个表引擎内完成的关于数据处理阶段的信息。

在大多数情况下，read 方法仅负责从表中读取指定的列，而不会进行进一步的数据处理。进一步的数据处理均由查询解释器完成，不由 IStorage 负责。

AST 查询被传递给 read 方法，表引擎可以使用它来判断是否能够使用索引，从而从表中读取更少的数据。

解析器（Parsers）

查询由一个手写递归下降解析器解析。比如， ParserSelectQuery 只是针对查询的不同部分递归地调用下层解析器。解析器创建 AST。AST 由节点表示，节点是 IAST 的实例。

解释器（Interpreters）

解释器负责从 AST 创建查询执行流水线。既有一些简单的解释器，如 InterpreterExistsQuery 和 InterpreterDropQuery，也有更复杂的解释器，如 InterpreterSelectQuery。

查询执行流水线由块输入或输出流组成。比如，SELECT 查询的解释结果是从 FROM 字句的结果集中读取数据的 IBlockInputStream；INSERT 查询的结果是写入需要插入的数据的 IBlockOutputStream；SELECT INSERT 查询的解释结果是 IBlockInputStream，它在第一次读取时返回一个空结果集，同时将数据从 SELECT 复制到 INSERT。

InterpreterSelectQuery 使用 ExpressionAnalyzer 和 ExpressionActions 机制来进行查询分析和转换。这是大多数基于规则的查询优化完成的地方。ExpressionAnalyzer 非常混乱，应该进行重写：不同的查询转换和优化应该被提取出来并划分成不同的类，从而允许模块化转换或查询。

函数（Functions）

函数既有普通函数，也有聚合函数。

普通函数不会改变行数 - 它们的执行看起来就像是独立地处理每一行数据。实际上，函数不会作用于一个单独的行上，而是作用在以 Block 为单位的数据上，以实现向量查询执行。

还有一些杂项函数，比如块大小、rowNumberInBlock，以及跑累积，它们对块进行处理，并且不遵从行的独立性。

ClickHouse 具有强类型，因此不支持隐式类型转换。如果函数不支持某个特定的类型组合，则会抛出异常。

但函数可以通过重载以支持许多不同的类型组合。比如，plus 函数（用于实现 + 运算符）支持任意数字类型的组合：UInt8 + Float32，UInt16 + Int8 等。同时，一些可变参数的函数能够级接收任意数目的参数，比如 concat 函数。

由于向量查询执行，函数不会«短路»。比如，如果你写 WHERE f(x) AND g(y)，两边都会进行计算，即使是对于 f(x) 为 0 的行（除非 f(x) 是零常量表达式）。

聚合函数（AggregateFunction）

聚合函数是状态函数。它们将传入的值激活到某个状态，并允许你从该状态获取结果。聚合函数使用 IAggregateFunction 接口进行管理。状态可以非常简单（AggregateFunctionCount 的状态只是一个单一的UInt64 值），也可以非常复杂（AggregateFunctionUniqCombined 的状态是由一个线性数组、一个散列表和一个 HyperLogLog 概率数据结构组合而成的）。

为了能够在执行一个基数很大的 GROUP BY 查询时处理多个聚合状态，需要在 Arena（一个内存池）或任何合适的内存块中分配状态。状态可以有一个非平凡的构造器和析构器：比如，复杂的聚合状态能够自己分配额外的内存。这需要注意状态的创建和销毁并恰当地传递状态的所有权，以跟踪谁将何时销毁状态。

聚合状态可以被序列化和反序列化，以在分布式查询执行期间通过网络传递或者在内存不够的时候将其写到硬盘。聚合状态甚至可以通过 DataTypeAggregateFunction 存储到一个表中，以允许数据的增量聚合。

聚合函数状态的序列化数据格式目前尚未版本化。如果只是临时存储聚合状态，这样是可以的。但是我们有 AggregatingMergeTree 表引擎用于增量聚合，并且人们已经在生产中使用它。这就是为什么在未来当我们更改任何聚合函数的序列化格式时需要增加向后兼容的支持。

服务器（Server）

服务器实现了多个不同的接口：

一个用于任何外部客户端的 HTTP 接口。

一个用于本机 ClickHouse 客户端以及在分布式查询执行中跨服务器通信的 TCP 接口。

一个用于传输数据以进行拷贝的接口。

分布式集群查询执行（Distributed Query）

集群设置中的服务器大多是独立的。你可以在一个集群中的一个或多个服务器上创建一个 Distributed 表。Distributed 表本身并不存储数据，它只为集群的多个节点上的所有本地表提供一个«视图（view）»。

当从 Distributed 表中进行 SELECT 时，它会重写该查询，根据负载平衡设置来选择远程节点，并将查询发送给节点。Distributed 表请求远程服务器处理查询，直到可以合并来自不同服务器的中间结果的阶段。然后它接收中间结果并进行合并。分布式表会尝试将尽可能多的工作分配给远程服务器，并且不会通过网络发送太多的中间数据。

当 IN 或 JOIN 子句中包含子查询并且每个子查询都使用分布式表时，事情会变得更加复杂。我们有不同的策略来执行这些查询。

分布式查询执行没有全局查询计划。每个节点都有针对自己的工作部分的本地查询计划。我们仅有简单的一次性分布式查询执行：将查询发送给远程节点，然后合并结果。但是对于具有高基数的 GROUP BY 或具有大量临时数据的 JOIN 这样困难的查询的来说，这是不可行的：在这种情况下，我们需要在服务器之间«改组»数据，这需要额外的协调。ClickHouse 不支持这类查询执行，我们需要在这方面进行努力。

合并树（MergeTree）

MergeTree 是一系列支持按主键索引的存储引擎。

主键本身是«稀疏»的。它并不是索引单一的行，而是索引某个范围内的数据。一个单独的 primary.idx 文件具有每个第 N 行的主键值，其中 N 称为 index_granularity（通常，N = 8192）。

同时，对于每一列，都有带有标记的 column.mrk 文件，该文件记录的是每个第 N 行在数据文件中的偏移量。每个标记是一个 pair：文件中的偏移量到压缩块的起始，以及解压缩块中的偏移量到数据的起始。通常，压缩块根据标记对齐，并且解压缩块中的偏移量为 0。

primary.idx 的数据始终驻留在内存，同时 column.mrk 的数据被缓存。

当我们要从 MergeTree 的一个分块中读取部分内容时，我们会查看 primary.idx 数据并查找可能包含所请求数据的范围，然后查看 column.mrk 并计算偏移量从而得知从哪里开始读取些范围的数据。由于稀疏性，可能会读取额外的数据。ClickHouse 不适用于高负载的简单点查询，因为对于每一个键，整个 index_granularity 范围的行的数据都需要读取，并且对于每一列需要解压缩整个压缩块。