阿里云数据库 ClickHouse 产品和技术解读

2023-05-16
浙江
本文字数：7317 字
阅读完需：约 24 分钟

摘要：社区 ClickHouse 的单机引擎性能十分惊艳，但是部署运维 ClickHouse 集群，以及 troubleshoot 都不是很好上手。本次分享阿里云数据库 ClickHouse 产品能力和特性，包含同步 MySQL 库、ODPS 库、本地盘及多盘性价比实例以及自建集群上云的迁移工具。最后介绍阿里云在云原生 ClickHouse 的进展情况。本次主题将介绍腾讯云数据库为满足此类场景而在 HTAP for MySQL 产品方面进行的尝试。

在 2023 云数据库技术沙龙 “MySQL x ClickHouse” 专场上，阿里云数据库 ClickHouse 技术研发刘扬宽，为大家分享一下《阿里云数据库 ClickHouse 产品和技术》的一些技术内容。

刘扬宽，阿里花名留白，从事数据存储与数据处理系统研发十余年，先后在中科院计算所，中国移动苏州研发中心参与存储系统研发。2019 年加入阿里云参与内部产品的存储计算分离的架构升级。在云原生 ClickHouse 的研发中，承担存储模块的负责人，根据计算层访问存储系统的特点，有针对地优化了存储系统，提升了云原生 ClickHouse 的整体性能。

本文内容根据演讲录音以及 PPT 整理而成。

首先来说，我们的 ClickHouse 是在 2019 年中旬开源的。虽然开源时间较晚，但它的上升势头非常迅猛。我们可以看到在 DB-Engine 的关系型数据库类目中，ClickHouse 排在第 28 位，相比去年上升了 29 位。在 DB-Engine 的趋势图中，红色曲线表示 ClickHouse 的增长情况。右侧是 GitHub 上的 Star 数，可以看到，虽然 ClickHouse 开源时间较晚，但相比其他同类型的分布式数据库，其热度排名遥遥领先。

让我们来看看社区版 ClickHouse 的系统架构。如前面的嘉宾所介绍，ClickHouse 是一个 Sharding 架构。对于集群版的 ClickHouse 实例来说，首先需要创建分布式表，并在分布式表上定义 Sharding key。数据将被下载到不同的计算节点上，并通过节点副本、复制同步机制来保证数据的高可用性。

接下来，让我们来看看查询的链路。用户在查询数据时，必须使用分布式表，并将查询分发到某个查询节点。查询节点会解析分布式表并找到对应的本地表，确定集群分布式表下载到哪些节点上，并将查询发送到这些节点上。然后，每个节点都会进行本地计算，并将中间结果返回给 Push 节点。最终，Push 节点将所有中间结果进行汇总，并返回给用户。这就是 ClickHouse 上的分布式查询。

ClickHouse 提供了多种表引擎，其中 Meterialized MySQL 主要使用 ReplacingMergeTree 进行去重操作，而 MergeTree 系列是其主打的就是表引擎。此外，其他的聚合表引擎，都是通过后台合并数据，根据自定义的合并逻辑进行聚合运算，并不断地聚合数据。因为已经在后台完成了合并，所以直接查询这些数据的效率更高。

在 ClickHouse 的其他社区生态或数据同步系统中，创建这些外部表引擎有利于从其他系统同步数据到 ClickHouse。右侧的 SQL 示例展示了 ClickHouse 用户需要创建的本地表和分布式表，其中本地表必须包含排序键。另外，如果没有指定分区键，它将默认将整个表作为一个分区。用户可以根据某些字段的时间属性或其他属性，指定数据的生命周期，并告知系统哪些数据可以移动到冷存储或删除。

包括这个 tbl 可以作用于某些列，对这些列进行生命周期管理。例如，当数据到达某个确定的状态时，可以对其进行更高级别的压缩。在 ClickHouse 中，我们有多个节点的分布式实例，必须定义分布式表，并指定 Sharding key。默认的话，就是随机的 rand Sharding key。

开源的 ClickHouse 它的高性能以及高可用分布式存储，主要是从这些方面去实现的。首先它的高性能读取，在数据存储时，它会根据排序键有序地存储数据。然后索引是组建的轻索引，它是 Block 级别的大粒度索引，所以在分析场景上是比较适合的。但是 ClickHouse 对于点查询来说，它的性能并不是很好。

ClickHouse 具有高吞吐量，主要体现在能够支持多点写入，并且建议用户进行攒批写操作。它采用 LSM 树的结构进行写入，数据会被有序地写入到磁盘中，因此写入吞吐量接近于 IO 带宽。另外，ClickHouse 采用 P2P 架构，并支持多种 Sharding 策略。在示例中，展示了 rand 任意表达式的一种策略。用户也可以根据业务需要，选择基于 group by 或哈希的策略，将不同的数据分布到不同的节点上，有利于进行分布式查询中的 join 或 log ajj 操作。此外，ClickHouse 支持后台异步执行的 Delete 和 Update 操作。

此外，由于 ClickHouse 采用了纯列存储的方式，因此具有高压缩比，同时支持多种压缩算法。

ClickHouse 实现高可用性的方式是通过设置任意数量的副本。内部数据同步是通过 JK 协调实现的，副本之间可以进行多点写入和多点查询，这是基于内部复制机制实现的。此外，ClickHouse 支持不同数量的副本数，以适应不同 Sharding 策略的需求。

ClickHouse 是专门为 OLAP 设计的一种存储引擎。它的底层存储格式是基于 MergeTree 的逻辑二维表，其中每行对应一个或多个数据目录下的 PART（数据块）。在 data 目录下，会有许多索引文件，包括 primary key index 和其他索引文件。对于每个列，都有一组对应的数据文件（.bin）和数据索引文件（.mrk）。因此，每个数据块（block）的格式如下：命名规则为 Part 名称、Block ID、MergeLevel 和 Mutation Version（如果存在）。

在读取数据的过程中，系统会根据主键(private key)的索引(index)，构建对应要读取的 mrk 文件的偏移量(offset)。接着，根据命中的具体列和该列对应的 mrk 文件，定位到文件的偏移量(offset)，最终读取目标的数据块（block）。这个数据格式可以在互联网和相关材料中找到一些可供解析的内容参考。

这张图可以看出，就是 ClickHouse 因为这个存储格式的设计，所以它在写入的时候，它的那个写入带宽是非常高的。

ClickHouse 在分析场景上的性能非常高，这归功于以下几点原因。首先，它进行了针对硬件的优化，采用了多线程模型，能够让多机多核充分发挥 CPU 的性能。其次，它采用了向量化执行，并使用了很多 Codegen 和 SIMD 指令，从而提高了向量化处理的性能。此外，它的列存特点使得它非常友好于 CPU-Cache。最后，它的 C++代码在设计重构上也进行了很多优化，处理了许多细节。

在分析场景上，ClickHouse 拥有许多近似算法、抽样方法、丰富的数据类型和支持窗口函数的功能。此外，它还具备查询队列和资源隔离的特点，虽然在这方面的表现相对较弱。

ClickHouse 具有预先建模的能力，主要体现在用户可以根据底表创建物化视图。这些物化视图可以定义为一些聚合 MergeTree，在后台不断地进行合并，根据建模的逻辑结构在后台进行一些计算。这种建模方式能够大大提高前台查询的速度。

这张图可以看出，ClickHouse 在许多场景下都有细致的设计。例如，它在不同的场景中提供了聚合算子，而这些算子针对不同类型的数据提供了不同的计算逻辑。

比如说，对于物理数据，根据不同的数据大小或物理特性，可以采用不同的聚合算子。此外，它还可以自适应地使用不同的函数来处理不同的数据量。例如，对于唯一键的转换，如果数据量较小、中等或超大规模，它会选择不同的函数进行处理。

然后他在不同大小的一个内存使用上，它也会使用不同的内存分配函数，去做做内存分配。

ClickHouse 的查询性能非常快。例如，在处理一百亿行数据时，它可以执行 UV 操作，这种性能非常可观。

这里就是 ClickHouse 跟同类型的分析型数据库的性能对比，这是官网公布的一个 PK 的数据，查询速度还是很快，单表过滤分组聚合查询优势显著。

在这张图中，我们可以看到 ClickHouse 在灰盒测试中的数据结果。这份测试数据是比较早期的，来自 2020 年，使用的是 2019 版本。通过时间上的对比，我们可以发现 ClickHouse 在灰化之后，查询速度是 Vertica 的两倍多。这里也是对 Greenplum 是不同版本和不同节点的一个比较。

然后这里是具体的一个性能数据，他是把 get 的数据集打包成了一个大宽表。接下来我们也将会介绍 ClickHouse 的性能表现。需要注意的是，在 Join 场景下 ClickHouse 的性能相对较弱。但是在大宽表的查询性能上是非常高，ClickHouse 表现非常出色，这个是有目共睹的。

然后再看一下我们社区 ClickHouse 版对有很多客户用上来之后有以下这些痛点，他的写入是有一些限制，他推荐你要聚合 bach，要高频的并发，小粒度写。然后它的那个数据一致性是保证数据最终一次性，就是修改完就会立即可见，这个可见是指我那个多副本之间，它的数据全部是保证最终一致性的，如果是单机上，你去写完他返回提交成功，你是可以立即查的。然后它支持那个支持 Delete/Update，但是异步生效的。而它不支持事务，最新版的这个 ClickHouse 社区版只支持 part 写入原子性。然后它需要后台的合并来保证主键的唯一性。

ClickHouse 在计算层次的限制，这个 join 不是他的优势，需要根据不同场景修改 SQL，进行专门的优化。此外，其优化器是否支持 CPU 优化也有待考虑。用户接口不够友好，创建表时需要同时建立本地表和分布式表，查询时只能查询分布式表，这些细节增加了用户使用 ClickHouse 的学习成本和困惑。此外，ClickHouse 的建表习惯与大部分数据库不同，并且其数据类型与 MySQL 有较大差异。此外，ClickHouse 采用 sharding 架构，存储和计算不分离，因此在弹性扩展容时缺乏弹性能力。

第三点是运维方面的限制。ClickHouse 相当于手动挡，因为其运维不够友好。在扩缩容时，数据不会自动 re-balance。在副本失败时，需要手动重建或恢复。此外，数据迁移工具也缺乏实时性，不支持备份恢复的功能。对于修改配置，有些设置不能持久化生效，需要手动修改配置文件或重启 server。ClickHouse 的调优和运维难度较高，需要用户具备一定的技术能力。因此，很多用户需要亲自查看源码并使用最新的 C++标准开发，而开发者相对较少，C++代码量也较大，门槛很高。

接下来，进行第二部分，阿里云数据库的产品简介。阿里云数据库，产品定位是为最快最便宜的列式数据库，它在极致性能，最极低成本、简单灵活的架构、便捷的运维等，这几个目标上，去主打场景化的最佳解决方案。

我们的主打场景是海量数据分析业务，包括大宽表查询和数据 hash 对齐的 join 场景等功能，这些功能虽然有很多限制，但能够满足大部分用户的需求。同时，我们的批量更新和删除操作，与其对应的 part 的 key 是有无关联，能够减少后续的更新和删除操作的开销，提高性价比，特别是对于那些对性价比比较敏感的用户来说。

这份表格对比了阿里云数据库 ClickHouse 和开源 ClickHouse 在运维、数据生态专家支持以及内核研发等方面的差异。我们发现，在运维方面，阿里云的 ClickHouse 提供了可视化的创建和实际管理集群的功能，而自建则只能手动部署。在 Failover 方面，我们的系统具备管控任务流，能够自动监控处理异常情况或自动拉起失败节点。容灾备份方面，阿里云数据库 ClickHouse 也提供了备份恢复功能。在安全性上，我们支持日志审计、白名单、RAM 授权等功能，并提供公网 SLB 和阿里云云网络等安全保障措施。另外，我们也支持通过 SQL 进行参数修改，并提供词典管理，控制台上可以直接操作。我们还提供完善的监控和多指标报警体系，能够对慢 SQL 进行分析。

在水平或扩缩容节点方面，我们可以自动迁移数据。目前，我们已经实现了数据无需锁写的迁移，并在切换 SLB 时进行了短暂的切换。在用户权限管理方面，我们支持对支持 RAM 子账号授权。此外，在数据生态和数据接入方面，我们支持阿里云内部的 DMS, SLS, DTS, DataWorks, OSS，MysQL 外表、ODPS、Kafka，这些数据可以从这些系统中同步到 ClickHouse 行查询分析。我们还提供了专家服务支持，为用户业务提供设计和优化建议，以及对问题的快速处理。

在内核研发方面，我们关注社区版本的更新，对 bugfix 及时响应问题以及在前后兼容的情况下建议用户升级。在内核优化方面，我们的分层存储已经在可分离 MPP 架构的功能上实现，同时也可以在我们的云产品上体验到。这就是开源自建会有很多的的用户痛点。

我们阿里云 ClickHouse 的冷热分层主要优势在于成本。可以提供更高性价比的查询分析引擎。用户在创建表时，可以告诉系统数据生命周期的关键字段，然后后台会根据这些信息，将 Data part 的数据移至冷盘、OSS 或 HDD 上。这样，相较于全部存储在 ESSD 上，整体成本将大幅降低。

在我们的存储设计中，针对用户进行数据过滤时产生的大量索引文件和小文件，我们也进行了一些优化。我们使用本地盘作为小文件的缓存（cache），这样在执行许多查询过滤操作时，不会直接访问到 OSS，从而提高查询分析性能。同时，我们访问 OSS 采用流式的 IO，其吞吐量可达到 200 MB 至 1 GB 的带宽，这个带宽接近或超过 ESSD，而成本仅为 ESSD 的 1/10。

对于存储在 OSS 上的数据，主备节点共享一份存储数据。在存储与计算分离的架构中，ClickHouse 采用存储磁化，并按量计费。在计算节点数量方面，我们是实现了按需扩容。

第三部分，我们将继续介绍阿里云 ClickHouse 的重要功能特性。主要内容包括数据同步工具、多盘存储，以及自建 ClickHouse 如何迁移到云端的工具介绍。

在本文中，我们将介绍如何在阿里云 ClickHouse 中创建从 MySQL 库同步到 ClickHouse 的任务。首先，在 RDS 控制台上，选择分析实例并进入到相应的界面。在此界面上填写 RDS 或 MySQL 的用户信息。接下来，在页面上勾选需要同步的库和表，然后点击“创建同步任务”。完成这些操作后，我们便可以在控制台上看到同步任务的状态。

对于习惯使用 SQL 创建任务的用户，可以参考页面右下角提供的 SQL 示例，创建 MeterializeMySQL 并配置同步表的白名单或黑名单以及其他设置。具体的配置信息可在阿里云的官网文档中查阅。

创建并启动同步任务后，系统将首先进行全量同步，随后进行增量同步。这样，用户便可以在 ClickHouse 中查询同步过来的表，并进行相关的数据分析任务。

如果用户在阿里云的 ODPS 上有大量数据，而 ODPS 无法进行查询分析或运行批处理等非实时查询引擎任务，那么可以在 ClickHouse 中创建 ODPS 外表。接着，通过使用 insert into select 语句从 ODPS 外表同步数据到 ClickHouse。完成同步后，便可以在 ClickHouse 中进行查询分析。

我们将介绍阿里云 ClickHouse 产品，它是一款主打性价比的解决方案。该产品支持用户购买本地盘，这里有和高效云盘和 ESSD 在规格和价格上的对比分析。我们可以看到，HDD 的成本要比高效云盘低一半，而 ESSD 的费用是本地盘的六倍多。但使用本地盘也存在一定问题，即数据与计算是强绑定的，如果本地盘损坏，可能会有数据丢失的风险。

然而，对于一些用户在存储日志或纯监控场景中，或者允许数据丢失的产品场景，它们可以接受这一限制。此外，有些用户对读写带宽有较高要求，而单个 ESSD 盘的 ClickHouse 在 IO 方面存在限制。阿里云的 ClickHouse 支持用户购买多个云盘或本地盘组成一个 RAID 零，也可以在 ClickHouse 配置中组建一个结构，底层使用 LVM，从而提供多盘聚合带宽能力。

在多盘性价比方案中，我们提供了冷温热三层的分层存储。下面是一个分层存储的架构示意图。当数据需要立即写入时，我们会先将其写入云盘 ESSD 中，以便快速合并。然而，一段时间后或者当达到特定的 TTL 时，数据会被移动到本地盘。最后，如果时间更长，数据会被移动到 OSS 上。因此，我们提供了三种不同的分层存储组合，以满足不同的使用场景。例如，将云盘与 OSS 组合使用可以实现冷热分层，根据 TTL 进行归档进冷存。而将云盘与本地盘组合使用则可以实现冷温分层，将最近 N 天的频繁查询 TTL 存储到本地盘中。我们将根据用户的实际业务场景选择最适合的冷温热组合。

如果用户已经存储了大量数据在自建集群中，但在使用过程中遇到了前文提到的运维困难和其他无法解决的问题，那么可以考虑使用阿里云 ClickHouse。我们提供了一个方便的迁移工具，其主要原理是解决数据实时同步的问题。但是数据同步可能存在一个问题，即原有的实例集群会在后台不断地合并 Data Part，如果我们在这里捕捉到了数据，有可能在后面就会被合并掉。例如，我开始追踪一个 Part 并读取它，但当我要同步这个 Part 时，它源头的集群已经将这两个 Part 合并成了一个，这样我就找不到了。为了解决这个数据同步问题，我们提供了一个配合 Pass Log 的方案。

Pass log 是我们刚才介绍的一个功能，通过该功能，我们可以将几个后台的数据进行合并，以实现数据的整合。当我们开始同步数据时，只同步了其中的一部分，即 SD1 的部分。如果后续需要读取整个合并后的大 part，我们可以通过追踪 part log 来了解它是由哪些原始 part 合并而成的。这样，我们就可以直接同步所需的 part，保证数据的一致性。同时，我们还可以将源头 part 之外的数据删除，以确保数据的完整性。

我们的迁移工具名为 cksync，相较于社区提供的 clickhouse-copier 工具，cksync 在语言、资源占用、上手使用、并发模型、write-lock-free 以及临时表机制等方面都有其独特的特点和优势。左侧是我们工具的命令行参数列表。

接下来，我们将介绍云原生 ClickHouse 的技术演进的第四部分，主要介绍存储计算分离方案以及多计算组。

阿里云云原生 ClickHouse 采用的架构与第一位嘉宾介绍的 ByteHouse 类似，首先解决了存算分离的问题，即数据存储与计算节点解耦。我们的方案是将数据存储在 OSS 上，源数据存储在 FDB 上，并在 worker 节点上设置了 OSS 的 Cache，使用本地盘作为 Cache 以降低直接访问 OSS 的网络开销。此外，我们采用中心化的 controller 协调查询，命中查询先传递到 controller，由具体的查询 computer worker 再将其转发，然后 controller 进行查询计划的生成和数据前期的 filter 过滤，再将要扫描的数据以及执行计划发送给 computer worker，最终查询结果返回给用户。为了实现读写分离，我们将数据的写入和后台合并工作线程分别用不同的服务进程处理，从而使计算节点完全无状态。