共计 8449 个字符，预计需要花费 22 分钟才能阅读完成。
摘要：随着数据智能时代的到来，多云多源架构下的数据管理是企业必备的基础设施，咱们认为数据存取、数据集成与散发、数据安全与数据品质是根底，也是走向多云多源架构的终点。本议题介绍云原生的多云多源数据管理 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 的实践经验和技术趋势，联合企业级的实在场景落地案例，与宽广技术爱好者一起交换分享
