Data Fabric 在数据集成场景的实践

导读 本文将介绍 Data Fabric 的基本概念及其在数据集成场景的实践案例。

主要内容包括以下几大部分：

1.  什么是 Data Fabric 与数据虚拟化

2. 数据虚拟化在数据集成场景落地实践

3. 数据虚拟化同传统方案的差异

4. 总结

5. 问答环节

分享嘉宾｜余俊 Aloudata大应科技  技术副总裁

编辑整理｜刘金辉 杭州硕磐智能科技有限公司

内容校对｜李瑶

出品社区｜DataFun

01什么是 Data Fabric 与数据虚拟化

1. 集中式数仓面临的困境

在正式介绍 Data Fabric 之前，先来看一下现有数仓体系面临的问题。提到数仓，很多做数据的同学都会想到 ETL，以及 Hive、Hadoop、Spark 这些技术。但很多数仓使用者，包括数据的生产者、消费者、甚至是老板，都对数仓有着各种不满。

从数据生产者的角度来看，他们每天会面临大量的分析、取数需求，从前端提出的需求各种各样，甚至一个需求还会不断变化。从数据消费者的角度来看，比如分析师、运营同学，他们常常觉得需求难以得到满足，可能要等候排期，或者是数据还没有等等。

再站在老板的视角，数仓跟物理世界的仓库类似，都是用来存放东西的，只不过数仓存储的是数据，数据搬进去之后，还需要分门别类去维护，以便在要用的时候能快速找到并拿出来。但是它跟物理仓库有一个很大的差别，那就是物理仓库是有进有出的，而数据仓库却只进不出，随着业务的快速增长，数据仓库也会急剧增长，但数据仓库能解决的问题却不是成比例增长的，其业务价值不但没有成比例增加，反而由于数仓规模的增大导致投入和维护成本成急剧增加，进而导致很多数仓建设有一定时间的公司都急需数据治理。

其实数据治理本质就是通过人为手段去解决数仓业务价值不能匹配的问题，因此，站在老板视角来看，数仓的投入产出比是极低的。所以传统数仓有两个很严重的矛盾：第一个是生产者跟消费者供需的矛盾，第二个是数仓整体投入产出比的矛盾。

对于用户来讲，可能有些数据在数仓里面，有些数据在 MySQL 里面，有些数据甚至是一个文件，他会希望拿到这些数据就可以直接去分析，而不是还得先把这个数据入仓，再转换一下，最后才能用。这就是传统数仓与实际需求之间的 GAP。

总结来讲，传统集中式数仓面临着三个方面的挑战：第一个方面是成本；第二个方面是合规，因为大家对数据隐私方面的要求越来越高，企业、政府以及法律法规上也越来越严格；第三个方面是效率。

2. Data Fabric，新一代数据架构的思想

接下来看一下 Data Fabric。Gartner 发布的《2021 年十大数据和分析技术趋势》中，Data Fabric 被列在首位，它是一项加速变革的技术。作为一项颠覆性的技术，Data Fabric 的出现是有它的原因的。首先，Data Fabric 认为哪怕企业有成熟的数仓，甚至有数据湖，仍然需要 Data Fabric。因为在现实世界中我们无法把所有的数据物理集中到一个地方给用户使用，过去数十年无数企业和技术方案都验证过，这是一条很难实现并只能停留在理想世界中的方案，这是其最基本的理念。

Data Fabric 到底是什么？Data Fabric 中文翻译成数据网格。而数据的虚拟化是实现数据网格化很关键的一项技术。当然 Data Fabric 还有一些其他的相关概念，比如 Data Ops、主动元数据等等。本文主要介绍数据虚拟化这一部分。如果大家对其他 Data
Fabric 概念感兴趣，可以通过上图中的二维码来获取我们的 Data Fabric 白皮书。

3. 数据虚拟化让数据随手可得、按需计算

我们将数据虚拟化定义为三层。第一层是连接层，最主要的作用是为各种各样的异构存储介质，不同的物理层定义一个统一的访问接入模型层，将异构数据的访问标准化。第二层是真正做数据处理加工的地方，叫合并层。第三层是消费层，将加工后的数据提供给消费端使用，接下来会借助案例详细展开各层的作用。

02

数据虚拟化在数据集成场景落地实践

前文中介绍了 Data Fabric 以及数据虚拟化的概念。接下来通过一个真实案例，来介绍如何将数据虚拟化技术应用到实际场景中。

1. 在某券商应用案例

这是一个券商的案例。在用我们的方案之前，他们是没有数仓的，报表是通过写 Java 程序去实现的。客户经过调研发现所有的同行都在使用 Hadoop 这一套大数据体系，去构建一套完整的数据仓库，但对他们来讲这种方案投入成本太多，而且方案也太重了，因此他们急需更加轻量化的数据解决方案。

这个券商客户那边有很多业务库，并且这些业务库沉淀了很多年，有些放在 MySQL 里面，有些放在 Oracle 里面，也有些在 SQL Server，甚至还有一些网上爬下来的数据。他们希望通过这些数据汇集在一起来实现企业的信息化大屏，包括资产管理、数据管理月报、数据分析等等，为管理层及各个业务部门清晰地展示企业关键业务经营情况。

我们提供的解决方案是，首先这些数据源通过虚拟化逻辑层连接，这一层映射成最原始的 PDS(Physical Dataset)，只逻辑定义，不做物理数据的迁移。基于这层逻辑映射的 PDS 之上，再去定义各层，与数仓的分层架构类似，只不过这里的 DWD、DWS、ADS 都是虚拟化的 VDS（Virtual Dataset）。消费端的报告、报表直连到虚拟化引擎，像访问传统数据库里面的普通物理表一样使用任一层里面的 VDS 数据。

其中有两个比较关键的策略。

第一个策略是客户希望能保留数仓的功能。首先，保留数仓数据的历史性，所以我们为他们构建的第一个策略就是在 DWD 明细这一层，统一按照天去保留历史快照，与传统数仓一样，只不过是基于虚拟化技术去做，引擎会在这一层统一构建物理作业。

第二个策略是 DWD 之上的这一层，按需去做物理作业的构建。

有了这两个策略之后，通过我们的策略引擎去生成真正的作业。当用户查询视图或虚拟表时，虚拟化引擎会根据用户的查询 SQL 路由到真正的物理数据上去做查询（底层会基于不同物理作业产生的数据做关联和合并）。

2. 在某券商应用效果

通过上述方案，发现没有采用传统的数据体系，也能把常见、典型的用户场景实现出来。客户连到逻辑数据平台里面的库有一百多个，PDS 层虚拟映射的表有两万多张。但实际上完成所有关注的看板、报表，真正用到的表还不到 1%。所以有大量的表对这些经营报表是没有用处的。实际的物理作业也不多，不超过 100 个，支撑其一百多个核心指标。

如果采用传统数仓的方案，因为其数据散落在各个业务库，如果把两万多张表都同步过来，而且是在数仓里面去写 ODS 的话，那么成本和代价是完全不一样的。而我们的方案在以下三个方面带来了显著的提升：

• 首先，整个交付效率相对于以前的 Java 开发提升了至少十倍。即使与传统数仓方案对比，也是有明显优势的。
• 第二，整个研发链路的管理工作量减少了 30%。因为在我们的方案中传统 ETL 中的 E 和 L 层都虚拟化掉了。
• 第三，减少了计算存储的成本。因为两万多张表里面，用到的物理作业很少。所以整体的成本相对于传统方案来讲，是有巨大节省的。

3. 数据虚拟化应用架构

上图中展示了两种典型的数据虚拟化应用架构，适用于不同的场景。

前面的券商案例中，用的是典型的单层虚拟化架构，通过一个虚拟化层，把公司所有源的数据连接在一起。

多层虚拟化架构，更多用于集团性公司，或者分地域的公司。因为各种各样的原因（比如权限、安全、合规、数据归属和管理权等等），如果企业不希望这些数据从各个地域或者分公司物理拷贝出来，如果上层还要使用这些数据，那么多层虚拟化非常适合去解决这类问题。

03

数据虚拟化同传统方案的差异

1. 数据虚拟化让 ETL 专注于 T(Transform)

接下来看一下虚拟化方案与传统方案的差别。

数据虚拟化并不是突然冒出来的一个概念，而是经历了一系列的发展过程。早期的数据仓库，是 ETL 的模式，随着各种非结构化数据的出现，慢慢演变成了数据湖的解决方案。数据湖中最大的变化是把 transform 这个阶段放到了最终使用数据的时候去执行，也就是变成了 ELT。但是不管是数据仓库还是数据湖，都是集中化的物理数据存储方案。而逻辑数仓是基于虚拟化技术的数据解决方案。在逻辑数仓里面，更强调让用户只聚焦在 transform，而不需要关注 E 和 L。

通过上图中的对比，可以看到逻辑数仓与传统数仓的差别。首先逻辑数仓完全缩减掉了数据抽取过程，它只是一个逻辑映射，相当于把所有库连的元数据爬进来，数据就可用了。第二个差异是在消费端，在逻辑数仓中不需要把数据导到 OLAP 引擎里去，直接就能给 BI、报表或其它工具用。E 和 L 这两层去掉之后，用户可以将重心放在中间 transform 这一层，专注于处理数据、加工数据。

真正做到这个技术可用，有两个关键点。第一个是自动化生成 ETL 作业。其实让用户聚焦在 transform 里面，通过虚拟化的技术去实现他的需求，不代表没有 ETL 作业，ETL 还是在的，只不过这个过程自动化了。第二个是因为用户不会感知到物理作业，所以当有作业产生物理数据时，这些查询的改写、构建，都由虚拟化引擎完成了，对用户是透明的。

2. 数据虚拟化=Presto？

大家可能会有两个疑问，一是这个虚拟化方案与传统的 Presto 方案有什么差别，二是这里的 ETL job，是不是类似于物化视图，接下来解答一下这两个问题。

首先绝大部分用 Presto 的场景都是放在ETL的最末端，当然这跟 Presto 的架构也有关系。因为 Presto 就是一个 MPP 引擎，它本身是面向 OLAP 查询的，只不过支持跨源查询的能力。如果想延伸到数据仓库这一层的话，就意味着需要支持大规模数据稳定且低成本的构建能力，而这是 Presto 这类纯 OLAP 引擎架构所支持不了的，因为 OLAP 引擎的设计就是追求最大化的利用所有计算和内存资源将每个查询的性能拉到极致。所以数据虚拟化不等于 Presto，因为它可以解决一部分类似于虚拟化的问题，但是解决不了传统数仓的困境。Aloudata 的数据虚拟化是可以解决全场景的。最关键的部分在于 RP 技术的突破。

RP 与物化视图的差别在哪里呢？举个简单的例子，传统的物化视图，是为了加速一些大的 SQL 而诞生的，其实更多的是一种加速缓存，也就意味着数据丢掉了是没关系的。但是在 RP 这一层，因为 RP 是对标 ETL 研发的作业，如果作业有问题，或者是数据有问题，查询不会绕过它。所以 RP 的定位与物化视图有着很大的不同，也正因为此，两者在技术设计方案上也存在很大的差别。

首先，RP 会支持多层的构建和调度，与真实的物理上生成的 ETL 作业没有差别，也会有强弱依赖，也会有分区对齐，也会有跨周期依赖等等。只不过这些是自动生成的，而不是人工去配置的。同时，RP 也支持大规模数据量构建，也支持自动推导是全量构建、增量构建，还是分区构建。

另外，在物化视图中，数据一旦构建出错就失效了，数据就丢了。但在 RP 里面是不会的，因为数据有多个版本，这是很重要的一个能力。

RP 同物化视图一样也会基于算子实现 SPJG 的查询改写能力，但同时它也极大增强了物化改写能力。在传统物化改写中，对于 SQL 的复杂性是有一定限制的。例如：在 VDS 多层嵌套的场景，多层视图展开后会生成一个极其庞大的算子树，传统物化改写算法在这类规模的算子树上改写，性能和准确性都存在极大的限制。

最后，RP 技术根据用户的查询历史以及资产的关系构建了智能加速方案。并且能够自动回收。在数据仓库里面，作业越来越多，很多没有用的作业无人负责下线，必然要去人肉治理，以降低计算、存储成本。在虚拟化之后，因为消费端对作业是否在用是有感知的，所以能做到自动回收。这也是相对于传统数据治理一个很重要的差别。

3. 传统数仓VS逻辑数仓

逻辑数仓与传统数仓的区别可以总结为以下几个维度：

• 成本方面，逻辑数仓的实施成本更低，因为只需要部署一套虚拟化引擎，所以也比较轻巧。同时，存算成本也比较低，因为是按需计算的，数据随时可用。另外，自动数据治理，可以将重复资源自动合并、复用，并基于一定策略自动回收。
• 安全合规方面，数据逻辑集中，可以更好地控制其访问策略、安全策略等。
• 效率方面，因为它省略掉了很多过程，所以整个研发效率更高，而且门槛也会比较低。
• 整体技术方案简单，一套方案就可以很好地满足主流数据报表和分析场景。

既然逻辑数仓有这么多优点，那么有了逻辑数仓，传统数仓就不再需要了吗？显然不是。因为传统数仓经过多年的发展，有其自己的理论、技术体系、人才的沉淀。传统数仓最大的问题是无法适应非稳定的、临时性的或者创新性的需求，这些业务需求有个共同的诉求就是取数、用数的敏捷化，这是传统数仓架构天然无法具备的。所以逻辑数仓更像是传统数仓的补充，通过传统数仓加上逻辑数仓，可以满足更多的场景。

04

总结

在本次分享中讲到了很多概念，包括 Data
Fabric、数据虚拟化、逻辑数仓以及 RP。下图中展示了它们之间的关系。

首先 Data Fabric 是一个理念，数据虚拟化是 Data Fabric 理念下数据网格化能力的具体实现。有了数据虚拟化技术，我们去构建了一个虚拟化的数据仓库，叫做逻辑数仓。而真正的突破，是因为有了 RP 这样的技术，才让数据虚拟化能够真正去落地，从而实现逻辑数仓的能力。

本文的两个主要观点为：

• 因为数据虚拟化的技术，让数据集成不等于数据同步。这与传统的解决方案有很大的差别。因为不等于数据同步，反而让数据可以随时可用。
• 逻辑数仓让数据的使用更经济、便捷、高效。

以上就是本次分享的内容，谢谢大家。

05

问答环节

Q1：怎么保证在查询时不影响业务库的稳定或业务系统的正常使用。

A1：这是被问到最多的一个问题。回顾文中的案例，其实在 DWD 这一层做了一个物理作业的映射，因此对于所有 DWD 上的这些查询，是不会打到业务库内存的。有些访问如果是直接查询，比如说绕过了这一层，直接查询 PDS 这一层，查询引擎有做一部分的限流控制。根据不同的业务库的容量，我们可以针对数据源做一些容量的限流。

Q2：RP 本身是什么？能否解释一下？

A2：RP 全称是关系投影。以前是 ETL 自己去写物理作业，写 SQL，最后把数据插到一张物理表中。现在我们把这个过程简化成了 ETL 同学去写真正生成数据的逻辑，不用管这个逻辑是不是插到一张物理表中。当定义了很多视图之后，我们发现比如说它这两个视图合在一起去生成一个物理作业更高效的情况下，就会把它的代码合在一起去生成真正的物理作业。所以 RP 与视图之间的差别就是用户定义了视图之后，RP 其实是视图底层物理作业的一个映射。

Q3：采集的数据时效性如何？

A3：采集的实时性取决于不同的场景。有些场景是有实时采集需求的，而有些场景虚拟化之后，数据的时效性能够得到提升。当然这种时效性的提升取决于几个方面的能力。第一个方面是，如果查询下推能力足够强，用户原始的 SQL，原始的那个库，能支撑这样的查询的话，可能很多地方就不会去采集过来，而是尽量在源端库进行计算，这是一个方案。另外一个是，有些采集，如果源端库不允许访问，或者性能很差的情况下，可以在 PDS 层建 RP，也可以在 DWD 层建 RP。进入这个 RP 之后，跑的作业就分两层，一层是定时去跑，或者说依据调度系统的调度周期去跑，比如说可以调度到小时级，这是一类。另外一类是如果在 PDS 层建，这种加速作业的采集是可以更实时化的。比如通过定义 bin log 的方式生成 RP。RP 就是一个订阅 bin log 的实时采集作业了。

Q4：Data
Fabric 的核心是建立一套映射关系吗？

A4：首先，Data
Fabric 的基础是虚拟化。但是 Fabric 不仅仅是这一个概念，其实它上面还有很多，比如主动元数据，是很关键的一个点。虚拟化数据的来源是因为有主动元数据的能力，才让用户无感知，不用去操心怎样用他所有的库。更多的概念，可以参考我们的白皮书。以上就是本次分享的内容，谢谢大家。

分享嘉宾

INTRODUCTION

余俊

Aloudata大应科技

技术副总裁

Aloudata 合伙人 & 技术副总裁余俊，拥有 18 年互联网技术和大数据平台相关架构经验。作为主架构师及核心研发主导并完成了 Alibaba B2B 首个海量分布式 KV 存储系统，作为网站架构师负责 Aliexpress 全球买全球卖交易系统的第一代架构设计。

曾任蚂蚁集团大数据研发平台技术负责人。从零开始主导完成蚂蚁第一和第二代数据研发平台产品体系的建设，涵盖数据集成、研发、运维、质量基线及资产平台等完整数据研发平台产品体系，支撑蚂蚁数以千计的 ETL 研发工程师，搭建了蚂蚁面向金融行业的逻辑化智能数据研发平台，有丰富的海量数据及智能化数仓的落地实践经验。

往期推荐

如何从0-1使用 Apache Arrow 构建新数据系统

当”狂飙”的大模型撞上推荐系统

大数据分析平台之云原生 OLAP 架构的最佳实践

B 站标签系统落地实践

因果性学习范式初探

OLAP的统一及技术趋势：StarRocks 架构和实践分享

快手基于 Flink on K8s 的生产应用实践

快手专家：如何成为好的数据产品经理？

百度基于云原生的推荐系统设计与实践

高性能 LLM 推理框架的设计与实现

点个在看你最好看