一、Data Fabric 与数据虚拟化简介
在正式介绍 Data Fabric 之前，我想先回顾一下我们现有的数据仓库体系面临的问题。当提到数据仓库时，许多从事数据工作的人可能会想到 ETL（抽取、转换、加载）和一些技术工具，如 Hive、Hadoop 和 Spark。我在过去十多年一直在数据仓库领域工作，与我类似的老一辈大数据从业者可能都有相似的经验。
我们遇到了哪些问题呢？归纳起来，不论是数据的生产者还是消费者，甚至是老板，似乎没有人对数据仓库感到满意。为什么呢？
从数据的生产者的角度来看，即 ETL 工程师，他们每天都面临大量不同的需求，包括数据分析、数据提取等等。一些需求甚至每天都在变化，因此他们不得不疲于奔命，工作非常繁重，成就感很低。
从数据的消费者的角度来看，例如分析师和运营人员，他们可能对数仓更加不满。因为提需求的时候，要么是没有排期，要么是需要清洗数据，要么是数据还没有导入到数仓中，导致需求要花很长时间才能被满足。
老板的角度又不同，他们将数据仓库视为一个物理仓库，用来存储数据。然而，与物理仓库不同的是，数据仓库是"只进不出"的，这意味着数据不会被删除。这导致了一个问题，即数据仓库的规模会不断增长，仓库管理员（ETL 工程师）的数量也在不断增长，但从业务价值的角度来看，数据仓库并没有产生相应的价值增长，尤其是在业务迅速增长的情况下。因此，老板认为数据仓库的投入产出比非常低。
伴随着数据应用场景和数据使用人数的快速增长，企业在数据安全、用户隐私保护和监管合规上的挑战也越来越大，企业不得不在“业务敏捷用数”和“数据安全合规”之间寻找“油门”和“刹车”的协同方案，而当前并没有成熟的方案可以兼顾两端。
总结来说，传统的数据仓库面临三个主要挑战：高成本、合规问题和效率问题。
但这并不是说 Data Fabric 是传统数仓的代替者，而是补充者。在接下来的案例中，我会具体探讨通过 Data Fabric 和虚拟化技术是如何解决这些挑战的。
Gartner 连续三年将 Data Fabric 列为 “十大数据和分析技术趋势”之一，甚至是“2022 年十大战略技术趋势”之首。Data Fabric 出现的一个重要原因在于：即使一个企业有成熟的数据仓库和数据湖，依然无法将所有的数据集中到一个地方给用户使用，Data Fabric 的概念顺势而生。
Data Fabric 翻译成中文叫“数据编织”，它是一种数据管理架构思想，包含了数据虚拟化、Data Ops、主动元数据等多种技术与概念，其核心理念是通过优化跨源异构数据的发现与访问，将可信数据从所有数据源中以灵活且业务可理解的方式交付给所有相关数据消费者，让数据消费者自助服务和高效协作，实现极致敏捷的数据交付，同时通过主动、智能、持续的数据治理让数据架构持续健康，从而提供比传统数据管理更多的价值。
数据虚拟化技术是 Data Fabric 的基石技术之一，我们这次主要围绕它来展开。
数据虚拟化技术是一种允许用户通过一个统一的接口访问分散在不同数据源中的数据的技术。它通过将多个数据源（如数据库、文件系统、云存储等）的数据实现逻辑整合，使得用户可以像访问单一数据源一样来查询、分析和操作数据。
在我看来，数据虚拟化的定义共有三层：
- 连接层：为各种各样的异构的、存储介质不同的物理层数据源定义一个统一的逻辑层
- 合并层：是做数据处理加工的地方
- 消费层：将加工后的数据提供给消费者使用
数据虚拟化技术可以在不复制数据的情况下，将不同数据源、不同位置和不同格式的数据进行整合，它隐藏了底层数据存储位置、技术接口、如何实现、使用平台等技术的复杂性和差异性，并通过逻辑视图层提供统一的数据服务，为多个应用和用户提供支持，从而实现实时的数据访问，减少数据复制搬运成本，提高数据开发与变更的敏捷性。
图 1：数据虚拟化让数据随手可得、按需计算
二、通过数据虚拟化技术构建逻辑数仓的实践
接下来我会通过一个真实的案例，介绍数据虚拟化技术到底是如何应用到具体场景中发挥价值的。某券商前段时间找到了我们，想找到一种更加简单、低成本的方式解决数据孤岛问题，让业务能够快速访问和分析企业的所有数据。该券商最初打算构建一个数据仓库，但调研大多数金融机构的方案后，他们认为传统数仓的投入过大，建设、管理和使用的负担也都太重了。该券商的业务库积累了多年数据，包括 MySQL、Oracle 和 SQL Server 等业务库中的数据，以及一些网络爬取的数据。他们希望利用这些数据来构建企业大屏和进行业务数据分析，如资产管理、数据管理月报等，以便管理层和各部门清晰了解公司的数据资产。
Aloudata 大应科技提供的解决方案如下：
- 通过虚拟化逻辑数据平台将这些数据源进行映射，形成最原始的 PDS（Persistent Data Store）；
- 基于这一层逻辑映射的 PDS，定义了各层逻辑数仓架构，如虚拟化的 DWD（Data Warehouse Layer）、DWS（Data Serving Layer）和 ADM（Asset Data Mart）；
- 报表等数据应用就可以直接连接到虚拟化引擎，从而访问其中任何一层的数据。
这套方案包含两个关键策略：
- 第一个策略是保留数仓的历史数据功能。我们在明细层统一按天保留历史快照，这与传统数仓类似，但基于虚拟化技术实现；
- 第二个策略是在所有 DWD 层上按需进行物理作业的生成和构建。
有了这两个策略，通过策略引擎可以生成真正的 ETL 作业。当用户查询视图或虚拟表时，虚拟化引擎会路由到真正的物理数据进行查询。通过这个方案，即使不使用传统的数据体系，也能实现这类典型的数据应用场景。
图 2：数据虚拟化在某券商的落地案例
最终，该券商通过 Aloudata 逻辑数据平台连接了 100 多个数据库，虚拟映射了 2 万多张表。可事实上，真正支持该券商最核心的 100 多个指标、业务看板和高管报表的物理表还不到总量的 1％，实际物理作业也不超过 100 个，就足以满足绝大部分需求。如果采用传统数据仓库方案，由于数据分散在各业务库中，要满足客户需求，首先必须同步这 2 万多张表，这会带来高昂的成本代价。
Aloudata 逻辑数据平台为该企业实现了三个方面的提升：
- 交付效率提升至少 10 倍；
- 研发链路管理工作量减少 30%；
- 数据存储和计算成本节约 50%。
三、数据虚拟化的架构与技术原理
介绍完真实案例后，我们就可以再回归关注虚拟化技术本身，看一下虚拟化都包含哪些要素。虚拟化共有两种典型的应用架构，不同的应用架构对应的应用场景也不相同：
- 单层的虚拟化架构：通过一个虚拟化层把公司所有元数据连接在一起，随时可用；
- 多层的虚拟化架构：更多的是用于集团性公司或分地域的、多层级的公司。由于组织架构的复杂性，对数据使用有着严格的隔离和权限要求，很多情况下不具备将数据进行物理集中的条件，但又希望能够实现全域数据要素的流通和价值挖掘。
图 3：数据虚拟化的两种典型应用架构
数据虚拟化并不是凭空产生的，它有个发展的过程，这是我们这一代的从业者都有的感知。
首先，数据仓库和 ETL 工程经过了长期的演变，随着非结构化的、各种类型的数据的增加，数据湖的解决方案应运而生，数据湖最大变化是把 Transform 阶段放到最终使用数据的时候执行。然而，不管是数据仓库还是数据湖，其实都是集中化存储的数据方案。后续逻辑数据平台出现了，它是基于虚拟化技术的一个逻辑数据仓库体系，它更多的强调让用户只聚焦在 Transform 上，而不需是整个 ETL 过程。
传统数仓的数据解决方案需要抽取、消费，而逻辑数仓与传统数仓有两个最大的差别：
- 完全缩减掉抽取过程，通过逻辑映射，把所有的数据库的元数据爬进来，使数据在逻辑数仓中立即可用；
- 消费端无需用户单独将数据导到 OLAP 引擎当中，可直接将数据引入 BI、报表等其他工具中使用。
因此，用户只需关心中间用来处理数据、加工数据的 Transform 层，这也是逻辑数仓与传统数仓的最大差别——能够节省掉 E 与 L 环节，实现这种能力有两个关键技术点支撑：
- 自动化生成 ETL 作业：让用户聚焦在 Transform 层，但物理 ETL 作业依然存在，其过程被自动化；
- 透明的物理作业处理：物理作业的生成和查询改写均通过虚拟化引擎实现，对用户而言是透明的。
图 4：数据虚拟化让 ETL 专注于 T (Transform)
面对传统数仓的弊端，业界过去经常采取的方式是通过 Presto 方案进行解决。虚拟化方案与 Presto 方案也有一定相似，但存在明显差别。Presto 的架构本质上是一个 MPP 的引擎，其架构导致绝大部分使用 Presto 的场景都是在 ETL 最末端的消费层 ，本身面向的是 OLAP 查询。但是 Presto 可以支持跨源查询，如果想延伸到数据仓库，就意味着需要获取支持大规模数据构建的能力，而 Presto 的架构便无法再支持。所以，数据虚拟化不等于 Presto，Presto 可以解决一部分类似于虚拟化的问题，但无法支持大规模数据构建，限制了其在数据仓库领域的应用。
其实，早期的虚拟化技术也能解决部分数据采集、数据转换的问题，而 Aloudata 的数据虚拟化技术却能做到面向全场景的能力，其核心最关键的就在于 RP 技术的突破。
RP（Relational Projection）的全称是关系投影，可以理解为是一个简化传统物理作业的过程。以前 ETL 工程师需要编写 SQL，并要将数据插入到物理表中，而现在，只需编写生成数据的逻辑，再也不必关心数据是否插入了物理表。
RP 跟传统的 OLAP 引擎里面的物化视图有明显不同。传统的物化视图更多面向一些大的 SQL 的性能加速，更多的是一种加速或缓存，这种特征代表了其丢失后不会产生影响。RP 实际对标着 ETL 同学研发的作业，以前在数仓中，如果 ETL 研发作业、作业数据出现问题，查询失误则不可避免。因此物化视图与RP 的定位是不同的，在技术设计方案上也有着极大差别：
- 多层 RP 构建与调度：这些真实物理作业生成的 RP 与 ETL 作业并无差别，也会有强弱依赖、分区对齐、跨周期依赖等，但其是自动生成的，而非人工配置。此外，RP 支持大规模的数据构建，支持自动推导判断全量构建、增量构建或分区构建；
- 数据的多版本能力 ：RP 的数据有多个版本，而物化视图则是缓存逻辑，数据一旦构建出错，其物化视图就失效了；RP和数据通过版本切换及数据缝合技术实现新老数据的切换和组合。
- PRP（Predictive Relational Projection）技术：这是我们在技术上取得的一个较大的突破，可以通过根据的用户的查询历史，以及定义资产的关系来实现自适应的智能加速方案；
- RP 的自动回收：从数据仓库或 ETL 同学的视角来看，很多数仓作业在上线之后便无人关心其使用情况和生命周期的问题，造成只上不下的局面。因此，数仓数据越堆越多，必然需要通过治理来降低其计算存储成本。在拥有虚拟化之后，此过程凭借自动回收能力，取消了人工操作步骤。
图 5：数据虚拟化 = Presto？
四、总结
做个总结，逻辑数仓相对于传统数仓具有以下主要优势：
- 成本方面
- 存算成本低：无需物理拷贝，逻辑集成，按需计算和存储，数据随时可用；
- 实施成本低：只需部署一套虚拟化引擎产品，一站式完成集成、处理和分析；
- 自动数据治理：重复资产自动合并和复用，策略回收数据。
- 安全合规方面
- 数据逻辑集中：数据可以通过查询下发 + 策略控制，使得数据不出域，满足数据合规要求；
- 全局数据安全：通过虚拟化为企业提供全链路的数据权限管控、数据脱敏等安全管控策略。
- 效率方面
- 数据研发效率高：传统数仓数据研发链路长，导致一个业务完整的交付时间长。逻辑数仓弱化了 E 和 L 的过程，让用户只聚焦 T，数据通过逻辑连接，随时可用。自动化的物理任务生成，降低用户对物理技术和存储感知；
- 用数和取数门槛低：技术方案简单，一套方案适用企业主流数据报表和分析场景。集成、研发、分析以及数据服务一体化，用户无需单独为不同场景准备不同技术方案，虚拟化引擎自动根据场景和查询特征完成跑批和分析查询路由。
传统数仓经过这么多年的发展，沉淀了一套完善的理论、架构、技术、人才。但传统数仓最大的问题在于不适合非稳定性的、临时的、创新的需求，更多适用于沉淀资产和成熟的、稳定的用数需求。所以我认为，逻辑数仓更像是传统数仓的一个补充。因为有了逻辑数仓和传统数仓，让我们整个大数据的解决方案满足了更多的场景。
在面对大量不确定性的、敏态的、临时性的数据分析场景时，传统数仓、数据湖都可以作为数据源，而虚拟化技术可以帮助我们构建一个逻辑化的企业统一数据服务平台，通过自动化的手段加速数据发现、集成、开发和分析的进程。
还有一种常见的情况，客观上企业内部有大量数据因为种种原因无法实现物理集中，那么通过虚拟化技术可以快速打破这些“孤岛”，实现全域数据的整合与分析。
最后，想和大家总体回顾一下今天提到的概念——Data Fabric、数据虚拟化、逻辑数仓、RP 等，它们的角色和之间的关系在下方这张图中比较清晰地表达了出来。首先，Data Fabric 是一个理念，数据虚拟化则是 Data Fabric 中实现数据网格化的一种能力。在数据虚拟化技术之上构建真正数据能力的是逻辑数仓，同时，正是因为有了 RP 这样的技术突破才让数据虚拟化能够真实落地，实现了逻辑数仓的能力。
图 6：总结
Data Fabric 架构的能力和带来的价值越来越受到市场关注，如果想要了解更多 Data Fabric 资料或 Aloudata 解决方案和案例，可直接在官网内浏览和下载，我们随时为大家提供帮助。