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

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

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

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

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

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

接下来看一下>

Data Fabric到底是什么？Data Fabric 中文翻译成数据网格。而数据的虚拟化是实现数据网格化很关键的一项技术。当然> 3.数据虚拟化让数据随手可得、按需计算

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

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

前文中介绍了>

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

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

我们提供的解决方案是，首先这些数据源通过虚拟化逻辑层连接，这一层映射成最原始的 PDS(Physical> 其中有两个比较关键的策略。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在本次分享中讲到了很多概念，包括>

首先>

本文的两个主要观点为：

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

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 的核心是建立一套映射关系吗？