云数据库技术沙龙｜多云多源下的数据复制技术解读 -NineData

摘要：随着数据智能时代的到来，多云多源架构下的数据管理是企业必备的基础设施，我们认为数据存取、数据集成与分发、数据安全与数据质量是基础，也是走向多云多源架构的起点。本议题介绍云原生的多云多源数据管理 NineData，重点介绍 MySQL、ClickHouse 相关的数据管理和复制技术。 

2023 首届云数据库技术沙龙 MySQL x ClickHouse 专场，在杭州市海智中心成功举办。本次沙龙由 NineData、菜根发展、良仓太炎共创联合主办。本次，玖章算术技术副总裁陈长城（天羽），为大家分享一下《多云多源下的数据复制技术揭秘-NineData》的技术内容。

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

陈长城（天羽），玖章算术技术副总裁，前阿里云资深技术专家，在数据库领域深耕 15 年，主导了阿里数据库基础架构演进（IOE 到分布式、异地多活、容器化存计分离）和云原生数据库工具体系建设。

我接下来这个分享主题：多云多源下的数据复制技术揭秘-NineData，主要是涉及到产品和技术解读，对大家来讲，理解会更加轻松一些。

大家好。我是陈长城，来自玖章算术团队。我们团队的使命是让每个人用好数据和云。我们团队中很多是来自阿里、华为和 IBM 等资深技术专家。我们的 CEO 叶正盛曾担任阿里云数据库事业部产品管理和解决方案事业部的总经理。而我个人之前在阿里工作了十多年，主要负责整个基础架构 PASS 层的演进，以及云原生数据库的工具体系建设。

接下来，我先介绍本次的分享议程。首先是探讨多云时代和数据时代下，企业数字化转型所遇到的机遇和挑战。随后，我将介绍 NineData 的产品平台，重点介绍 NineData 的数据复制技术，以及分享两个典型的客户案例。

首先，我们来看一下 Gartner 的报告。该报告显示，80%以上的企业会选择多云或混合云。从 Percona 报告显示，超过 70%的企业会选择使用多种数据库来应对多源数据的情况。在行业的分析报告中，我们发现，如果企业能够有效使用多源基础架构和新的数据架构，它们的创新能力和整体盈利能力将会明显提升。然而，在这个新的多云和数据时代下，企业还是面临着一些问题，例如数据孤岛、多源数据管理复杂度以及开发效率等，目前是急需解决的。

如果今天去看企业整个数据治理和数据管理，各方面涉及的问题是非常多的。从 NineData 角度出发，我们应该思考如何解决这些问题。

我们是这样思考的，在整个企业数据管理过程中，通过内置安全能力来提升企业的开发效率和安全性。这包括企业数据库的设计、开发、变更和发布的完整生命周期中实现安全。同时，使用多源数据复制技术促进数据流动；通过数据备份技术和在线查询技术保护企业的数据资产，提高冷数据的数据价值；通过创新技术方法，既能保护数据资产，也能提高数据的价值。此外，我们可以通过结构对比、数据对比和多环境数据对比等技术手段来提高企业的数据质量。

下面我的第二个话题，讨论的是整个 NineData 数据管理平台的主要架构。底层是一个基于多云和多源的基础架构设计，而我们的核心四大功能模块，如备份、复制、对比和 SQL 开发，已经在之前介绍过了。接下来，我会从多源和多云这两个角度来介绍整个平台。

从多云架构来看，NineData 最主要的目的是帮助企业统一管理分散在多云或混合云的各种数据源。为此，我们设计了灵活的云原生架构、弹性架构、网络结构等，让企业能够管理分散在各个云厂商和线下的数据源。同时，我们通过专属集群的技术，能够让企业独享本身的资源。包括我们可以把企业的 worker 节点放置在企业本地或 VPC 内部，实现数据的内部闭环，提高企业数据安全和 worker 执行效率。

我们可以看到，NineData 作为一个云原生的 SAAS 产品，按需拉起、弹性伸缩是最基本的能力。

针对企业的网络方面，因为很多客户不愿意或不希望暴露数据库的公网端口，特别是对于关键数据。因此，我们设计了一个数据库网关，通过这种设计，用户只需起一个我们的数据库网关，就能够连接我们的中心管理节点，从而建立反向访问通道，能够把散落在各地、以及包括内部的数据源的统一管理。此外，我们的 NineData worker 也可以放到用户本地，实现数据链路的内部闭环，而管理链路就可以通过中心的控制台管理实例级别的任务，整个数据通道都在用户本地内部，实现统一管理。

在多源方面，我们主要设计了一个数据的统一接入层。为了接入众多数据源，我们对整个数据源进行了抽象，并对其属性配置、连接检查和安全认证等方面做了一个包连接管理在内的统一抽象。这样可以将所有的数据源统一接入，并基于上述四大主要功能模块，都使用相同的数据源进行接入，实现一次接入所有功能都可用。对于用户来说，将所有的数据源注册后，最重要的是能够实现统一管理。

因此，我接下来会介绍 SQL 开发的相关内容。NineData 希望能够通过我们的产品进行企业在线数据的管理、查询以及整个数据开发到变更发布的生命周期的能够进行统一管理。因此，NineData 个人版更像类似于 MySQL Workbench，或者是 Navicat 这种的客户端工具等，只不过我们是一个 SAAS 版的功能。未来，我们也会推出客户端版本。对于企业版，我们希望能够通过可视化的界面来提升企业效率，进行数据库设计、开发和变更发布，同时在整个生产过程中内置安全和权限能力。

如何提升个人和团队的效率？实际上，在企业内部有多个环境，这些环境希望能够进行结构同步等操作。不同环境之间可能存在不同级别的要求。例如，对于敏捷的业务，您可能希望减少管理，以便更快地创新。而对于一些核心业务，您会更加注重稳定性和权限管理。

对此，NineData 制定了许多 SQL 开发规范，涵盖了各种情况，例如大批量数据变更如何判断是否会影响生产数据库的稳定性，并进行隔离和阻断；对于表结构变更，如何判断 Online DDL 是否会增加大的负载等。此外，我们支持用户定义安全执行策略，并提供了超过 90 个开发规范模板，支持用用户使用模板，或者自定义的方式。

NineData SQL 开发一直致力于提升用户的效率。目前，智能化如业界非常火的 ChatGPT，我们也是基于这种大模型的技术，去加强了 NineData 的整个产品能力，提升面向用户的效率能力。主要体现在用户只需要基于一个数据源，通过实时对话的形式就可以快速查询所需数据。例如，用户可以轻松查找薪资超过一定数额的员工。同时，对于数据库同学而言，NineData 也支持 SQL 语句的优化和表结构的优化。欢迎大家体验，还是会非常惊喜。

接下来我将重点介绍 NineData 在数据复制方面的一些技术。在多源多云的数据复制方面，主要的挑战在于数据库的类型非常多，以及每种数据库背后的数据类型、数据结构也是独立设计的。因此，如何实现数据间的联动，使其能够自由流动，是一个很大的挑战。同时，许多云厂商提供了丰富的数据源，但它们之间存在细微或者大的差别。在客户业务发展过程中，许多企业的数据中心和国际化业务等，可能需要涉及跨越长距离的数据拓扑。

如图下方所示，是一个典型的数据复制链路拓扑，当您配置完源和目标之后，NineData 就会让整个链路开始运行。一开始会有一个预检查，检查您的网络连接、账号密码等是否正确。接下来会进行迁移结构，抓取和写入全量数据和增量数据。我们的产品设计理念是希望它能支持多源和多种数据源接入，并具有很好的可扩展性。当新的数据源接入时，它能够很方便地接入。刚才我们介绍了许多不同的数据源，它们之间存在一些微小的差别。因此，为了确保整个同步链路能够长期稳定地运行，我们也是重点去建设其可观测性和可干预性。

在整个传输内核模块中，最基本的能力是确保一致性，这也是我们的底线。另外，还需要具备高吞吐量和低延时能力。接下来，后面的分享也会围绕这几个点进行展开。

关于 NineData 整个模块的架构，我们刚才已经进行了简单的介绍。相比业界其他产品，我们会在性能采集、异常处理、数据一致性等方面进行大量投入。

首先，我们来看一下吞吐能力。以全量性能为例，假设我们在源端有一些数据需要处理，其中有许多表，而且它们的数据量都不同。如果我们同时启动三个并发线程进行处理，那么可能会出现一些数据量小的表已经处理完了，但是一些数据量较大的表仍然在等待单个线程进行处理的情况。如果表级并发，就会类似的问题。因此，为了提高整个效率，我们必须增强表内的并发能力。具体来说，我们需要考虑表的切片是否均匀。为此，我们制定了一项策略，即默认组件支持一键拆分，依次通过主键、非空唯一键、可空唯一键、普通键等这种顺序支持拆分，以尽力最均衡的方式实现并发处理。

那么在源端的抓取性能能够达到良好的时候，并且它可以线性扩展之后，吞吐量的瓶颈可能不在通道上，而在目标库的写入上。因此，在目标库的写入姿势就是非常重要。如果每条 SQL 都需要在目标端进行解析，那么性能肯定会很差。因此，我们需要采用一些批量提交的方式。同时在处理压缩开关时，需要注意 CPU 的数量。在 CPU 数量较少的情况下，启用压缩会对性能产生较大的影响。在我们的测试中，如果 CPU 数量可能超过四核，则开不开压缩的影响将比较小。

在使用过程中，您可能会遇到一些问题。例如，在平常进行并发写入时，在源端如果您将 100G 的数据写入，在目标端它可能会变成 150G。这是因为如果单个表乱序提交的话，就可能会产生一些数据空洞。为此，NineData 在切片大小和并发顺序方面进行了一些优化。

因为整个全量复制是单端写入而且快速流入目标，这个数据就被淘汰了。所以整个 JVM 的参数上做一些针对性的优化，也是基于整个全量数据复制的模型本身具备这种特点。

第二个部分是低延时，那么如何构建低延时呢？我们从两个角度考虑，一个是整个通道的性能角度，包括一些如 Batch、热点数据的合并等。其中热点数据的合并，如果一条记录从 A1 改到 A2，再改到 A3，一般同步模型是全轨迹修改，但开启热点能力后，它可能直接映射 A3，不会插入 A1 或 update A2，通过这种能力直接以终态的数据写入，在内存中把这个队列直接合并掉。在性能层面，还有一些技术应用。例如，我们可以是在 redis 的复制链路中，减少队列的序列化代价，从而让整个队列的消耗降到最低。

在整个管理层面，对于整个低延迟的系统也非常重要，这是在我们多年的实践中得出的经验。举两个例子，一个是数据库出现延迟，但是数据服务端的日志已经被清除；作为我们云原生的产品，我们会怎么做呢？我们会拉取用户的接口，检查是否存在被上传到 OSS 或者其他对象存储的日志。如果有，我们会自动获取并接续上之前的记录，从而避免重新进行全量拉取，减少延时。

此外，我们还会记录安全位点。假设有 16 个并发写入目标库，每个并发都提交不同的库表和记录。在记录位点时，我们应该记录这 16 个中最慢的那个，以避免数据丢失。这意味着其他 15 个并发运行得更快。如果发生异常宕机并重新启动的时候，就会出现这样的问题：快速运行的几个线程会重新回放它们曾经运行过的数据。导致用户感觉这个是数据回退了。

因此，我们现在已经做了两个优化。首先是表级位点，每张表都会有一个自己最新的位点。如果在回放过程中，这张表的位点曾经被使用过，我们会将其抛弃，以避免位点回退。第二个优化是针对正常的运维操作，它会使队列中的所有数据都提交完成，使得 16 个线程到达一个一致的位点，然后再关闭进程。通过这种能力，我们实现了一个干净的 cleandown，用户重新启动后就不会遇到需要回放数据，这是非常优雅的方式之一。

在保证一致性方面是比较重要的，有两个关键点需要考虑。首先，是数据本身的一致性问题。举个例子，假设我们有 T1 到 T5 这五个事务，其中 B1 是订单状态，从 B1 创建订单，到 B3 可能是用户付款，这时会产生一个物流订单 L。如果我们采用正常的行级同步方式，订单和物流订单会分别存储在不同的表中，也就是不同的队列中。但是由于行级的并发性，无法保证它们的顺序性。因此，B1 和 L 可能同时出现在目标库中，也就是说在创建订单时，物流订单也已经被创建了。对于在线业务来说，这肯定是违背业务逻辑，无法支持在线业务的正常运行。

因此，我们构建了一个事务一致性能力，用户可以开启事务能力。当用户开启事务能力时，我们会检查 T3 这个事务中的每条记录与之前所有事务是否存在依赖关系。如果存在，T3 将等待其他事务都提交完毕后再提交，确保数据的一致性。因此，第一次提交只会提交 T1 到 T4，T3 会等待 T2 提交完毕后再提交。这是一种保证数据一致性的同步机制。

第二个问题涉及到 reader 解析端的一致性。具体来说，以表结构为例，如果我们遇到了表结构的变更，一般的解决方法是查看源端的表结构。然而，由于数据日志中大部分只有数据和表名，缺少结构和类型等信息，因此我们需要回查数据源来获取结构信息，并拼接出最终的结果。但是，很可能在回查时源端已经发生了第二次 DDL，导致我们获取到的是已经又被修改过的 DDL，从而拼接出的数据不一致和出现错误。

因此，我们开发了一种 DDL 解析能力，即在 DDL 解析完成后，直接在同步线程解析线程中进行重放。同时，我们记录每个变更的版本，重放的同时生成新版本，旧版本不删除。这样，任何表在任何时刻都可以随时查到其 Meta 结构，而不需要像其他业界实践一样，需要从头开始重新回放一遍，这种方式对于问题诊断的难度很高，无法获取最新的或当时 Meta 的状态。

在数据对比方面，我们 NineData 将其作为一个重要的产品能力对外展示，因为我们认为数据对比对整个数据质量的影响非常重要。因此，在结构对比、数据对比以及订正 SQL 生成等方面，我们在功能上做得非常全面。其次，我们会考虑数据对比对用户的源库和目标库带来的负载。这些负载对于许多生产人员来说非常重要。因此，我们制定了许多策略，例如：仅对不一致的数据进行复检，可以控制并发和限流，设置抽样比例和条件过滤，仅对某一范围内的数据进行比较等等。同时，在性能方面，我们也做了一些工作。因为如果拉出源和目标的所有数据，就会耗费大量计算资源和带宽，因此我们需要做比较优雅地计算的下推。

在可扩展性方面，如何在 NineData 里面支持快速的新增数据源？意味着我们需要快速支持结构和数据类型的转换，以及快速将通道产品化，这些都是我们的目前重要的思考因素。我们的整个设计思路就希望说，把原来的各种源到目标的这种 N 乘 M 的这种拓扑方法，能够通过 N 加 M 的这种方式来实现。

我们先讲一下数据类型，因为数据类型可能会对于最终一致性，大家会更加的在意，业界无论是在 FiveTran、Airbvte、NIFI、NineData 等方面的开源项目或者还是商用项目中，都定义了很多中间类型。今天，NineData 也是定义了一些中间类型，因为中间类型抽象得越好，它的种类就越少，这意味着新增的数据源我们需要开发 convert 的工作量就越少。因此，如何更好地抽象到更少的样本集里，是整体更好的抽象方法。

第二个插件化的事情，是我们提供了一个叫做关系数据提交框架。要实现足够的插件化，意味着我们底层需要在各个地方都提供一些框架来提升整体的复用能力。例如，当所有数据进入我们的 writer 时，提交时都要考虑 DDL 和 DML 是否需要等待。确保表结构已经变更支持完，再把后续的 DML 放过来。此外，库级别和表级别都会有一些 DDL 的内存结构用于实现锁冲突的排序。其实，表级别里面是放在同一张表中的 DML，这意味着我们可以进行攒批来优化 SQL 使得写入次数更少。在行级别操作中，如果是同一个 UK，那么可以进行热点合并，如前面所述。这样的框架抽象能力使得后面接入的数据源可以天然地具备这些能力。同时，在数据流动过程中，还可以去构建事务依赖拓扑关系，以判断数据是否可以提交，以及前面的数据是否已经完成。

今天是 MySQL 和 ClickHouse 技术专场，我们也是在这两方面进行了大量的实践。由于 MySQL 与 ClickHouse 在数据类型方面差异还是比较大的，ClickHouse 支持的引擎类型也很多。首先来看下引擎的选择，我们也调研了包括 MaterializeMySQL 和类似 Airbyte 等业界实现。我们认为，虽然 ReplacingMergeTree 可以实现，它也是 MaterializeMySQL 内部使用的引擎，虽然 MaterializeMySQL 在查询方面做了一些封装，但是如果没有足够的查询封装，由于不同厂商的中间同步工具在 version 和 sign 等值方面存在差异，最终会使得用户的查询结果可能不同。

这个 CollapsingMergeTree 的 sign 可以取-1 或 1，针对你的增删改查操作，增量复制中可以自然地进行映射。因此，我们第一次是实现了这个 CollapsingMergeTree，通过它可以将数据同步到预期目标。在实践中，我们发现一些客户仍在使用 ReplacingMergeTree，因此我们也对此进行了支持，这样就提供了两种方式。

在 ClickHouse 中数据类型相对较多，可能比类似 MySQL 的云原生类型更多。因此，在进行类型映射时有许多选择，同时也有许多默认值。如果您不将其指定为"NA"，则可能会出现一些初始值，例如对于"point"类型，它可能是"00"。这些行为可能会导致用户在源和目标数据对比时，发现数据存在差异。

在提交过程中，通道的性能上，类似于 Airbyte 的做法会将所有增量数据合成一个文件，因为 ClickHouse 引擎中的许多增删改都是变成直接增加，因此这种方式相对简单。但这种方式会带来较大的延迟。因此，在实现过程中，我们考虑使用 SQL 的方式进行提交，来了多少条就立即转集批提交，可以动态地控制，例如超过 1000 条或 0.5 秒”，可以几百毫秒就提交。此外，ClickHouse 的 Jdbc 在解析每条语句时性能较差，因此我们进行了一些优化，采用批量提交的方式来提高性能。

接下来，我将介绍“可观测性”和“可干预能力”这两个方面。由于各个类型特别多，例如，在同步过程中，用户可能会在目标端、新的写入等可能会遇到一些问题，导致这个两边写数据冲突等。因此，我们在可观测性方面不仅会将基本状态完全透露给用户，还会提供每个线程提交的语句。例如，如果有 16 个线程正在运行，我们会显示这 16 个线程分别在执行哪条 SQL，或者任务是否被 DDL 卡住等信息。可以通过类似于 MySQL Processlist 的方式查看每个线程正在执行哪些操作，已经执行了多长时间等信息。

在“可干预能力”方面，我们也作为重点建设，因为在同步过程中，用户可能需要添加新的对象到同步链路中，或者遇到一些异常情况需要进行干预。或者需要进行重写并提交操作等，这种问题也是经常会遇到的。

比如在下面这张图，精细化控制异常就是例子。如果说有条语句提到目标，在执行过程中遇到了结构上的冲突，系统会弹出一条语句，用户直接在对话框里面修改 SQL 语句，然后再执行，这样就可以以新的 SQL 执行通过。在表结构变更过程中，这种问题经常会遇到，用户也可以选择跳过或忽略这些问题，继续执行后面的操作。

关于多云多源的 NineData 数据复制功能，我们在产品的功能完备性、结构、预检查和性能方面进行了大量的工作，以确保其在市场竞争中具有极高的竞争力。目前，该产品已经 ready，大家可以在云上使用和体验。

下面是两个简单的案例。第一个案例是关于一个大型地产企业的。该企业拥有大量的数据库，但其开发流程涉及许多合作伙伴，例如 ISV 或第三方软件开发提供商。因此，他们需要将数据源的权限控制委托给这些合作伙伴。在以往的人工管理过程中，权限管理变得非常复杂且流程繁琐，难以统一管理。为此，NineData 提供了一个统一管理数据源的解决方案。通过该方案，统一纳管了企业的所有数据源，开发人员的账户初始化、权限申请以及数据开发流程的可视化等均得到了优化，从而大大提升了开发效率和协同效率。 

第二个案例是一个跨境电商的场景，他的分析和运营活动基于 ClickHouse。他的 MySQL 生产是分散在世界各地，比如日本、韩国等，他将各个地方的在线数据汇聚到国内的 ClickHouse 进行统一分析和运营决策。在这个过程中，他使用了我们的 NineData 复制产品，NineData 在跨地域的复制方面是具备一些优势。我们的解析模块、读取模块和写入模块可以异地部署，解析模块能够靠近用户的源端，写入端能够靠近用户的目的端，从而实现了整个性能的更加优化。

OK，我的分享就到这里，好，谢谢大家。

本次大会围绕“技术进化，让数据更智能”为主题，汇聚字节跳动、阿里云、玖章算术、华为云、腾讯云、百度的 6 位数据库领域专家，深入 MySQL x ClickHouse 的实践经验和技术趋势，结合企业级的真实场景落地案例，与广大技术爱好者一起交流分享