Data Fabric：一站式数据管理与服务-阿里云开发者社区

数据生命周期中的挑战

李飞飞博士在主论坛上提出了一个四层的体系，就是DIKW，就是Data、Information、Knowledge、Wisdom。可以看到这四层架构中，数据在最基础的一层。在当今社会中，数据已经成为了最关键的生产资料之一，怎样提供高效、高质量的数据管理与服务十分重要。现在有非常多的数据库引擎，都能提供非常好的数据查询和数据写入性能，但我们如何能够打破数据孤岛，解决在数据全生命周期中的各项挑战，这是本次演讲主要讨论的内容。

在一个数据的全生命周期中可以简单分为四个阶段，在每个阶段都有自己独特的挑战，比如在数据的生成和开发阶段，由于大部分企业客户一般不会只使用单一的数据库引擎，像缓存数据库Redis、业务数据库使用PolarDB、分析数据库使用ADB等，当你有多个数据库引擎的时候，不同的引擎之间的最佳实践和库表的一些规则是不尽相同的。多数情况下我们会依赖于DBA在不同的库表、不同的数据库引擎怎么样进行最好的平衡实践。但是这样给DBA带来很大的压力和挑战，同时也对企业的稳定性带来一些风险。

当有了数据的产生以后，你需要在不同的数据引擎之间让数据自由流转，在自由流转的时候问题变得更挑战一些，因为在不同的引擎中，数据格式和存储方式都不一样。怎么样能够用一种工具让数据在各种不同的Ecosystem中自由流转，这是第二个挑战。

第三个挑战，数据的安全性、可靠性、完整性变得非常重要，我们能不能用一种工具来保证数据的可靠性和安全性。因为在多数企业中，我们需要满足国家或者行业的法律法规的时候，数据的可靠性和安全性可能在众多要求当中的第一条。最后当你使用数据的时候，由于在不同的生态、不同的引擎里面会有不同的工具，你去学习多种工具，多种生态中的最佳实践时，学习成本以及使用成本都变得非常高。

什么是Date Fabric

为了应对上述这些挑战，Date Fabric应运而生，也是Gartner重点推广的数据管理理念。这个理念是当你有许多不同的数据，在不同的数据孤岛中如何让这些数据有机结合在一起，完成一个共同的任务，为我们的客户能够更好的服务业务目标。数据孤岛最重要的特性是让数据适应了不同的生态、不同的引擎，进而产生了数据孤岛。但Date Fabric是相反的，让引擎、不同的模块更好的去适配数据，让数据成为整个体系架构中的First Citizen。

Date Fabric是去实现一种灵活的、可以重用的，增强数据集成的方法和服务。这里提到的两个关键词，一个是灵活。当客户的业务场景不一样的时候，我有相同的能力，TP引擎、AP引擎、NoSQL引擎等等，我们怎么能够灵活把这些原子能力结合在一起，服务于不同的客户，他们不同的业务目标。

第二个关键词是可重用，我们并不希望完全从头开发一套新的数据库管理系统，或者新的数据库计算存储的原子能力，我们去用复用现在已有的、非常成熟的原子能力，有机结合在一起，增强现在的数据管理、使用、分析的业务场景。

如何实现呢，关键几个技术点是主动元数据，知识图谱、数据语义、机器学习等等，把这些结合在一起，让数据在不同的生态、不同的存储环境下、不同的引擎之间能够真正流通起来，有一个地方能够看到所有的数据资产。

实现Date Fabric这样一个愿景，在瑶池数据库我们是依托于DMS，DMS在阿里已经有12年数据管理最佳实践，也服务了超过40万客户。这里我想用四个统一来总结一下DMS面向Date Fabric的设计：统一用数、统一管理、统一计算和统一存储。

在这个图里面最下面是数据存在在不同的生态和存储介质里。通过统一存储向上暴露一致的统一的数据访问方式。再向上结合不同的计算引擎，像行引擎、列引擎、向量引擎、流/批引擎、安全引擎。让这些不同的引擎都有统一的一种访问数据的方式。当我们去做用数和管数的时候，可以按需去选用最适合的计算引擎来进行数据的访问和操作。

生态工具新特性

接下来我就数据开发的四个不同阶段分别介绍一下阿里云瑶池数据库生态工具团队做的一些新的特性。

数据的生成和开发

首先是数据的生成和开发，有个词大家已经非常熟悉，就是Devops，就是开发和运维两个成为一个非常有机，无缝衔接的一个整体。在开发阶段中从部署、开发、测试到最后的发布，在整个过程中去吸取从运维里面通过各种基于数据的观察、调试得到的一些反馈，加入到开发流程中，使业务体系能够不断优化、提供更好的性能，甚至是更好的体验。

在Devops场景下，DMS有超过400种的研发规范，超过30种数据源，全流程的管控体系。在这里我们想share一下我们在DMS的一个新能力，就是DMS copilot，DMS智能助手。这是基于现在非常热门的LLM（大语言模型）构建的，能够帮助用户智能化更高效的进行数据的开发和管理。Copilot提供的优势，包括减少枯燥的重复的劳动，比如重复写代码，赋能更多的角色去参与数据开发和生成，以及在开发过程中尽量落地规范化，提升数据的稳定性和质量。

这是DMS copilot的简单架构图，在数据引擎之上构建的各种大模型。比如阿里的通义大模型，开源的大模型，甚至客户如果有自己私有的大模型也可以结合进来。通过这些大模型以及向量化的领域知识，能够向上提供智能模型的访问接口。而在同一个访问接口上我们提供四个核心的智能化能力。

第一个是NL2SQL，这是自然语言到SQL的转译，开发者只需要写自然语言，它自动会帮你转化成SQL。相应的也会有SQL2NL，就是当SQL写完了以后，可以自动生成注释。再进一步，我们也提供了SQL的纠错和优化能力，当你写完了一条SQL，甚至是一条错误的SQL的时候，DMS copilot可以帮助你改写或者提供改写的建议，提升SQL的性能，甚至把一条错误的SQL写成一条正确的SQL。

我们为什么能做到这点，简单总结一下DMS copilot三步核心优势。第一是依托于LLM，因为LLM能够从大量的公开的数据里面去学习代码能力，去学习SQL的语法和语义，去学习中文的语言是怎么进行表达的。第二是数据库特有的，它更了解数据库，通过数据库的元数据可以生成更好的内容。第三是理解用户，由于DMS可以基于用户历史的查询习惯，针对性选择用户相关的源数据，并参考历史的SQL去理解上下文。结合这三点DMS copilot可以提供一个非常好的使用体验。

数据的采集和传输

第二个阶段是数据的采集和传输。数据的采集和传输最挑战的一个事情是在不同的生态系统里面，当我们怎样实现不同语言之间自由的流动。为了服务这个目标，我们提供了数据传输服务叫DTS。DTS在源端和目标端我们支持非常多种不同的数据库类型，链路组合超过60种。不但有阿里云自有的数据库，同时也支持第三方数据库、开源自建数据库。通过支持不同的数据库类型，帮助数据在不同的生态里面，在不同的数据库引擎，以及不同的存储介质之间自由去流动。

DTS经典的应用场景有三个。第一个是帮助数据进行迁移，从源端迁移到目标端。该场景主要的优势是在数据迁移过程中尽量减少对客户业务的影响，在迁移过程中同步延时在秒级。同时我们可以支持同构、异构，在迁移过程中也可以可验证、可回滚。

第二个场景是实时的数据集成，在不同的生态里面，像TP、AP数据格式是不一样的，在不同的数据结构转化的时候非常挑战，怎么能够把性能做到最优等。DTS都可以帮你实现，包括瑶池数据库内部、他云也都内嵌了DTS的能力。

最后一个场景是容灾，如跨地的容灾、异地的热备，在不同的灾备级别方案里面，DTS都可以帮助进行异地的、长距离的数据传输，保证源端和目标端数据的延迟性。

我们在DTS上这一年也做了很多工作，这里重点介绍三个。第一个是成本，第二是功能，第三是体验。

第一个成本方向，我们做了DTS Serverless。根据源端库写入的流量，我们可以实时对DTS规格进行弹升或弹降，保障DTS的规格是最适配当前流量，保证我们的客户在进行数据传输的时候，我们只是使用合理资源来完成数据传输。

第二个数据校验。除了前面说的数据传输，当已经有了两个源库和目标库，它已经基于别的方式进行了数据同步，但是你可能希望进行数据校验，确保源库、目标库的数据一致，DTS提供了这样的能力。更进一步的，当源库和目标库有不一致数据的时候，它可以提供一个改写的SQL供你进行数据订正来保证源库和目标库保持数据完全一致。

最后一个是DTS Insight，是为了改善我们数据传输的体验。在数据传输过程中会因为受到不同问题的影响，进而影响客户的体验，比如我们可能是内存不够、规格不够大等等。在这个过程中，我们构建了DTS Insight，把内部的诊断、分析、观察的一些能力提供给客户。当客户发现数据传输的性能不符合预期的时候，可以借助DTS Insight了解我们如何改善当前的传输性能。

数据的存储和维护

完成了数据的采集以后，下一步就是存储和维护，首当其冲就是数据的机密性、安全性。对于保障数据资产的安全或者机密性，主要分为事前、事中、事后三个部分，事前进行配置，事中保证有权限的人和客户才能访问这个数据，事后进行审计和追溯。DMS对事前配置、事中控流和事后追溯都提供了非常完整的解决。

在事前我们可以进行数据的自动分类、分级，企业账号的自动对接，细颗粒度权限的分配等等。在事中进行权限控制的时候，我们可以进行数据权限的鉴权，可以进行动态脱敏，甚至在某些对于数据机密性要求非常高的场景下可以支持隐私计算这样非常高阶的能力。在事后，当我们有合规的要求，甚至不幸地发生一些数据泄露事件的时候，DMS也能够进行自动的审计，包括像水印溯源的能力，完整地从事前、事中、事后三个阶段完整地进行数据资产的安全保护。

除了数据机密性更重要的是数据的可靠性，因为数据不可以丢，数据丢了是一个灾难性事件。那怎么保证数据的可靠性，其实是通过备份实现，阿里云提供的数据备份服务（DBS）是提供给数据库的各个引擎支持我们去提升数据可靠性。在DBS中可以支持不同的异构数据库，像RDS、PolarBD、NoSQL、ADB、Oracle等等。通过DBS备份网关去实现高效的恢复和低成本的备份。在这里我想强调的是对于DBS，它是可以支持多云多端。所谓的多云就是不单单可以备份到阿里云，同时也可以备份到本地的存储，甚至可以备份到他云的存储。多端就是数据存的目标可以在热、温、冷三种不同的存储中，根据不同的性能要求和成本之间选择合适的管理进行备份。

数据备份我们今天主要发布的两个功能是面向两个最核心的点，第一是成本，第二是性能。性能是极速恢复，比如非常经典的整实例的恢复，可能需要小时级的恢复时间。我们通过库、表、行、细颗粒度的恢复以及数据页延迟加载的技术，把小时级的恢复时间大大缩短到到分钟级。在典型场景中观察到超过10倍的速度提升。第二个是成本，成本我们通过热、温、冷自动分成的快照和智能的疏密备份，把备份的成本最高下降90%。

数据的集成和处理

第四个阶段是怎么样让数据的价值最大化，怎么样进行数据的集成和处理。这里回到最开始说的几个统一。

第一个是统一的体验。我们其实面对的是用户各个不同的业务场景，甚至是不同的角色，可能这些角色是业务开发，可能是数据工程师，可能是数据分析师，可能是业务运营等等，这些角色所使用的环境和使用的习惯各不相同。我们怎么样有一个统一的体验，这里我们依赖于Notebook，对于Notebook来说，它的底层我们加入交互模块，基于像之前的DMS copilot，以及下面的交互的查询方式、流批的脚本的交互方式、任务编辑的交互方式、数据分析可视化的交互方式，通过Notebook把它们有机串联在一起，让用户通过写SQL或者写脚本的方式，把他们用数的需求写出来，同时可以直接构建成为最后展示的报表。

统一体验只是用户看到的第一层，下面怎么做整体的统一，第一是统一计算，这个我们需要屏蔽计算引擎的差异性。前面提到有行业引擎、列引擎、向量引擎等各种不同的引擎。我们怎么样提供这样一个统一计算，我们依赖的一件事情是元数据的统一或者元数据的统一管控。当我们将元数据放在同一个空间里面，统一进行管理起来的时候，通过血缘、数据结构、数据拓扑的一些分析可以分析出来，最适合去执行的引擎是哪一个，智能化的动态去选择最适合去执行的引擎。

最下面一层是统一存储。统一存储里面也有两层，第一是统一物理存储，所谓物理存储就是我们有不同的物理介质，比如我们会有本地的磁盘、云盘等，有热、温、冷不同的存储。首先第一层是将不同介质的访问方式统一起来，通过DBS本身已经有的多云多端的能力实现统一。第二层是当我已经从不同的物理介质中读取数据的能力以后，把这些数据放到一个统一的格式里面，让上层更方便去访问。这个我们是利用了DTS，因为DTS本身已经有了在内存中的统一数据的存储格式。通过这两层的抽象，对上来说就可以提供统一的数据格式和访问。