摘要：社区 ClickHouse 的单机引擎性能非常惊艳，然而部署运维 ClickHouse 集群，以及 troubleshoot 都不是很好上手。本次分享阿里云数据库 ClickHouse 产品能力和个性，蕴含同步 MySQL 库、ODPS 库、本地盘及多盘性价比实例以及自建集群上云的迁徙工具。最初介绍阿里云在云原生 ClickHouse 的停顿状况。
在 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，最终查问后果返回给用户。为了实现读写拆散，咱们将数据的写入和后盾合并工作线程别离用不同的服务过程解决，从而使计算节点齐全无状态。
这张图具体介绍了 ClickHouse 的存算拆散计划。在 ClickHouse 中，这个计划是在形象的 ID 层实现的，相似于虚构文件系统中的存算拆散。
在那个弹性计算组上，咱们次要解决的是节点计算资源程度扩缩容的问题。咱们能够动静地减少计算节点，由多个节点协调所有计算查问工作，最初将后果汇总给发动节点，并返回查问后果。
为了解决不同业务或多租户之间相互影响的问题，咱们应用多计算组实现资源隔离。用户能够在管制台上秒级创立并部署计算资源，以响应用户的疾速查问和大数据量解决，从而防止影响惯例业务。
OK，，我明天的分享就到这里。
本次大会围绕“技术进化，让数据更智能”为主题，汇聚字节跳动、阿里云、玖章算术、华为云、腾讯云、百度的 6 位数据库领域专家，深刻 MySQL x ClickHouse 的实践经验和技术趋势，联合企业级的实在场景落地案例，与宽广技术爱好者一起交换分享