一、引言

随着企业信息化进程的快速推进，各类应用程序持续产生海量数据。过去近一个世纪的发展历程中，数据管理系统经历了从关系型数据库（RDBMS）到 NoSQL 数据库、文档数据库及对象存储等多样化演进。这些异构数据系统虽然为企业提供了多元化的数据管理方案，但也带来了数据开发与管理的显著挑战。无论是传统的关系型数据库（如 Oracle、MySQL、SQL Server），还是 Hadoop 生态系统中的 Hive、Spark、Impala 等组件，都采用了各自特定的 SQL 方言实现。

这种技术碎片化现状给数据分析工作带来了显著障碍。数据分析师不仅需要精通多种 SQL 方言，还必须通过不同的客户端工具连接多个数据源，导致分析架构复杂化、访问入口分散化、系统集成难度加剧。特别是在处理海量数据时，传统 BI 工具往往只能支持有限的数据源对接或小规模数据集分析；当面对大规模数据且需要跨多个数据源进行关联分析时，系统性能和效率面临严峻挑战。在此类场景下，数据分析师通常难以独立完成分析任务，而需要依赖 ETL 工程师进行数据预处理，导致分析流程冗长且效率低下。同时， ETL 工程师也面临着频繁处理复杂数据集成需求的巨大工作压力。

二、传统数据仓库架构

2.1. 数据仓库基本概念

数据仓库（Data Warehouse，简称 DW 或 DWH）旨在构建面向分析的集成化数据环境，为企业决策提供支持。数据仓库本身并不“生产”数据，也不直接“消费”数据，其数据来源于外部系统，并开放给外部应用使用，这正是其被称为“仓库”而非“工厂”的原因。

数据仓库具有四个基本特征：面向主题的（Subject-Oriented）、集成的（Integrated）、非易失的（Non-Volatile）和时变的（Time-Variant）数据集合，这些特征共同支持管理决策的制定。
数据仓库与数据库的区别：数据库是为捕获数据而设计，数据仓库是为分析数据而设计。

以银行业务为例，数据库作为事务系统的数据平台，记录客户每笔交易数据，可简单理解为记账系统；而数据仓库作为分析系统的数据平台，从事务系统获取数据，经过汇总和加工，为决策者提供支持。例如，分析某地区分行月交易量、存款余额等数据，若发现存款量大且交易频繁，则可决策在该地区增设 ATM。

分析系统具有事后性的特征，需要提供特定时间段内的所有有效数据。这些数据规模庞大，汇总计算耗时较长，但只要能够提供有效的分析结果即可达到目的。数据仓库是在数据库大量存在的基础上，为深入挖掘数据价值、满足决策需求而产生的，并非简单的“大型数据库”。

2.2. 数据仓库的典型架构

在传统数据仓库架构中，数据通过各类采集工具物理汇聚到 Staging Area，形成数据仓库的贴源层（Operational Data Store 简称 ODS ）。随后，通过业务建模及物理建模，将 ODS 层数据加工成面向分析场景的基础数据，形成中间层。具体包括以下层次:

• DWD（Data Warehouse Details）明细数据层DWD 是业务层与数据仓库的隔离层。主要对 ODS 层数据进行基础清洗和规范化处理，包括基础模型构建、空值处理、脏数据清理、异常值过滤、维度编码统一等。这一层存储的是客观数据，一般用作大量指标的基础数据层。

• DWS（Data Warehouse Service）数据服务层基于 DWD 层基础数据进行整合汇总，形成面向特定分析主题域的宽表数据，以支持业务查询、OLAP 分析和数据分发等。其主要功能包括：1. 用户行为数据的轻度聚合2. 对 ODS/DWD 层数据进行轻度汇总

• ADS（Application Data Service）应用数据服务层ADS 是基于 DWS 层构建的面向各业务领域的数据应用集市（Data Marts），直接面向消费端。通常会将这层加工好的数据存储到 OLAP 引擎或高性能查询引擎（如 ES）。我们通常说的报表数据或大宽表通常存储于此层。

2.3. 传统数仓方案选型

在构建面向数据物理集中的数据仓库解决方案时，主要可选方案可分为以下几类：

传统数据仓库解决方案经过数十年的发展，当下市场已涌现众多成熟的大数据解决方案、数据中台方案及配套产品体系，国内亦有基于开源技术构建的大数据产品。尽管这些技术方案不断发展完善，但仍有大量企业，尤其是缺乏专业 ETL 工程师团队的企业，在实施这些方案后，面临投入产出比严重失衡的问题。

许多企业以很高的目标规划建设企业级数仓，最终却难以实现预期效果，甚至实际落地成果与规划严重脱节，最终不得不放弃。那么，造成这一现象的根本原因究竟是什么？

2.4. 传统数仓架构面临的三大问题挑战

2.4.1. 基于物理表的主题式仓库设计 - 带来资产研发效率问题

传统数仓采用分层划域的研发模式，往往在数据仓库中形成层层依赖的资产加工链路。这些链路短则数层，长则可达数十甚至上百层。对于一些建设时间较长的数仓，其末端表可能依赖上游的几十甚至上百张表，从而形成一张极其复杂的树状依赖关系图。然而，在以物理表为核心的资产建设过程中，数仓中的每个资产通常对应一个物理表，并需要配套生成该物理表的数据调度作业（如批量处理、实时处理或数据同步作业等）。这些调度作业通常会形成如下图的数据加工依赖关系：

• 需求开发问题：一个全新的业务需求通常需要经过完整的流程，包括需求分析、逻辑建模、数据集成、物理建模、模型开发，直到最终数据消费。由于物理加工链路较长，数据变更及加工口径调整的成本极高。因此，在数仓建设中，真实数据模型的开发往往需要综合考虑未来业务的变化需求，力求设计具有高度复用性和扩展性的数据模型。然而，这种超前设计通常会进一步拉长新数据的交付周期，导致响应业务需求的效率大幅降低。

• 复杂依赖链路的维护问题：在数仓的数据研发和日常维护过程中，需要确保依赖关系图中每张表的数据质量和产出时效均满足业务需求。否则，链路中任何一张表出现问题，都会直接影响最终表的数据可用性。例如，当某张表的加工口径发生变化时，不仅需要重新生成该表的数据，还需依次刷新其所有下游表，以确保下游表的数据准确性。此外，还需要保障日常调度作业的稳定运行，以避免链路断裂或数据延迟对业务造成影响。

综上，要维持数仓的日常正常产出，通常需要专人负责资产的维护与开发。然而，在业务快速灵活变化的场景下，这种模式往往带来冗长的研发流程和复杂的物理表依赖管理问题。新数据从集成入数仓到最终被业务使用，不可避免地要经历漫长的等待过程，从而显著影响业务交付效率。

2.4.2. 庞大的数仓技术栈和繁杂的工具体系 - 带来数仓的高投入问题

1）大规模软硬件投入问题

• 传统数据仓库由于需要存储大量数据和进行数据计算，需要大规模的硬件投入，例如专用的服务器和存储设备。这些硬件的采购、维护以及升级都需要大量的资金投入。
  

• 与此同时，数据仓库相关的软件体系繁杂，包含各类计算和存储软件、数据集成、开发和资产管理软件等，软件种类繁多且企业级软件许可证费用也往往非常高昂。

2） ETL 工程的复杂性导致人员成本问题
数据仓库的运维、开发和管理需要高度专业化的技能，例如 ETL 开发需要熟悉数据建模、熟悉计算引擎的特性，还需要熟悉各类数据管理软件的使用，这意味着企业需要投入大量资金来招聘和培训专业人员。特别是对于传统数据仓库，数据建模、调优和管理的复杂性对人员的技术要求非常高，极大地增加了相关人力成本。

3）技术体系的不可变性带来的技术架构升级换代问题
传统数据仓库的架构一旦选定，数仓中的数据资产及其加工逻辑通常对底层的配套技术体系都是强制绑定关系。因此，当新的引擎技术或应用层软件出现时，企业若想升级，往往只能完全摒弃原有的技术体系。这种强绑定关系导致企业难以实现平滑的技术升级和兼容，进而引发数据孤岛、多套数据仓库工具体系并存等问题。

2.4.3. 长期运行后面临大量资产膨胀带来的 ROI 不匹配问题
数据仓库的属性决定了它本质上是一个“只进不出”的系统，数据会随着时间的推移不断累积。

在面向物理建模的数仓中，数据增长的维度主要体现在两个方面：物理表的数量和物理表的数据量。

• 物理表数量：随着业务需求的扩展，物理表的数量会不断增加。
  

• 物理表数据量：物理表中的数据量则是随着时间自然积累的。例如，对于常见的数仓分区表，假设单表每天产生 1 万条数据，一年即会积累 365×10,000 条数据。通常，这些数据会按照年累积持续增长。

假设每年物理表的数量增长 1 倍，物理表的数量和存储数据量的增长关系可以通过如下表格体现：

一、引言

随着企业信息化进程的快速推进，各类应用程序持续产生海量数据。过去近一个世纪的发展历程中，数据管理系统经历了从关系型数据库（RDBMS）到 NoSQL 数据库、文档数据库及对象存储等多样化演进。这些异构数据系统虽然为企业提供了多元化的数据管理方案，但也带来了数据开发与管理的显著挑战。无论是传统的关系型数据库（如 Oracle、MySQL、SQL Server），还是 Hadoop 生态系统中的 Hive、Spark、Impala 等组件，都采用了各自特定的 SQL 方言实现。

这种技术碎片化现状给数据分析工作带来了显著障碍。数据分析师不仅需要精通多种 SQL 方言，还必须通过不同的客户端工具连接多个数据源，导致分析架构复杂化、访问入口分散化、系统集成难度加剧。特别是在处理海量数据时，传统 BI 工具往往只能支持有限的数据源对接或小规模数据集分析；当面对大规模数据且需要跨多个数据源进行关联分析时，系统性能和效率面临严峻挑战。在此类场景下，数据分析师通常难以独立完成分析任务，而需要依赖 ETL 工程师进行数据预处理，导致分析流程冗长且效率低下。同时， ETL 工程师也面临着频繁处理复杂数据集成需求的巨大工作压力。

二、传统数据仓库架构

2.1. 数据仓库基本概念

数据仓库（Data Warehouse，简称 DW 或 DWH）旨在构建面向分析的集成化数据环境，为企业决策提供支持。数据仓库本身并不“生产”数据，也不直接“消费”数据，其数据来源于外部系统，并开放给外部应用使用，这正是其被称为“仓库”而非“工厂”的原因。

数据仓库具有四个基本特征：面向主题的（Subject-Oriented）、集成的（Integrated）、非易失的（Non-Volatile）和时变的（Time-Variant）数据集合，这些特征共同支持管理决策的制定。
数据仓库与数据库的区别：数据库是为捕获数据而设计，数据仓库是为分析数据而设计。

以银行业务为例，数据库作为事务系统的数据平台，记录客户每笔交易数据，可简单理解为记账系统；而数据仓库作为分析系统的数据平台，从事务系统获取数据，经过汇总和加工，为决策者提供支持。例如，分析某地区分行月交易量、存款余额等数据，若发现存款量大且交易频繁，则可决策在该地区增设 ATM。

分析系统具有事后性的特征，需要提供特定时间段内的所有有效数据。这些数据规模庞大，汇总计算耗时较长，但只要能够提供有效的分析结果即可达到目的。数据仓库是在数据库大量存在的基础上，为深入挖掘数据价值、满足决策需求而产生的，并非简单的“大型数据库”。

2.2. 数据仓库的典型架构

在传统数据仓库架构中，数据通过各类采集工具物理汇聚到 Staging Area，形成数据仓库的贴源层（Operational Data Store 简称 ODS ）。随后，通过业务建模及物理建模，将 ODS 层数据加工成面向分析场景的基础数据，形成中间层。具体包括以下层次:

• DWD（Data Warehouse Details）明细数据层DWD 是业务层与数据仓库的隔离层。主要对 ODS 层数据进行基础清洗和规范化处理，包括基础模型构建、空值处理、脏数据清理、异常值过滤、维度编码统一等。这一层存储的是客观数据，一般用作大量指标的基础数据层。

• DWS（Data Warehouse Service）数据服务层基于 DWD 层基础数据进行整合汇总，形成面向特定分析主题域的宽表数据，以支持业务查询、OLAP 分析和数据分发等。其主要功能包括：1. 用户行为数据的轻度聚合2. 对 ODS/DWD 层数据进行轻度汇总

• ADS（Application Data Service）应用数据服务层ADS 是基于 DWS 层构建的面向各业务领域的数据应用集市（Data Marts），直接面向消费端。通常会将这层加工好的数据存储到 OLAP 引擎或高性能查询引擎（如 ES）。我们通常说的报表数据或大宽表通常存储于此层。

2.3. 传统数仓方案选型

在构建面向数据物理集中的数据仓库解决方案时，主要可选方案可分为以下几类：

传统数据仓库解决方案经过数十年的发展，当下市场已涌现众多成熟的大数据解决方案、数据中台方案及配套产品体系，国内亦有基于开源技术构建的大数据产品。尽管这些技术方案不断发展完善，但仍有大量企业，尤其是缺乏专业 ETL 工程师团队的企业，在实施这些方案后，面临投入产出比严重失衡的问题。

许多企业以很高的目标规划建设企业级数仓，最终却难以实现预期效果，甚至实际落地成果与规划严重脱节，最终不得不放弃。那么，造成这一现象的根本原因究竟是什么？

2.4. 传统数仓架构面临的三大问题挑战

2.4.1. 基于物理表的主题式仓库设计 - 带来资产研发效率问题

传统数仓采用分层划域的研发模式，往往在数据仓库中形成层层依赖的资产加工链路。这些链路短则数层，长则可达数十甚至上百层。对于一些建设时间较长的数仓，其末端表可能依赖上游的几十甚至上百张表，从而形成一张极其复杂的树状依赖关系图。然而，在以物理表为核心的资产建设过程中，数仓中的每个资产通常对应一个物理表，并需要配套生成该物理表的数据调度作业（如批量处理、实时处理或数据同步作业等）。这些调度作业通常会形成如下图的数据加工依赖关系：

• 需求开发问题：一个全新的业务需求通常需要经过完整的流程，包括需求分析、逻辑建模、数据集成、物理建模、模型开发，直到最终数据消费。由于物理加工链路较长，数据变更及加工口径调整的成本极高。因此，在数仓建设中，真实数据模型的开发往往需要综合考虑未来业务的变化需求，力求设计具有高度复用性和扩展性的数据模型。然而，这种超前设计通常会进一步拉长新数据的交付周期，导致响应业务需求的效率大幅降低。

• 复杂依赖链路的维护问题：在数仓的数据研发和日常维护过程中，需要确保依赖关系图中每张表的数据质量和产出时效均满足业务需求。否则，链路中任何一张表出现问题，都会直接影响最终表的数据可用性。例如，当某张表的加工口径发生变化时，不仅需要重新生成该表的数据，还需依次刷新其所有下游表，以确保下游表的数据准确性。此外，还需要保障日常调度作业的稳定运行，以避免链路断裂或数据延迟对业务造成影响。

综上，要维持数仓的日常正常产出，通常需要专人负责资产的维护与开发。然而，在业务快速灵活变化的场景下，这种模式往往带来冗长的研发流程和复杂的物理表依赖管理问题。新数据从集成入数仓到最终被业务使用，不可避免地要经历漫长的等待过程，从而显著影响业务交付效率。

2.4.2. 庞大的数仓技术栈和繁杂的工具体系 - 带来数仓的高投入问题

1）大规模软硬件投入问题

• 传统数据仓库由于需要存储大量数据和进行数据计算，需要大规模的硬件投入，例如专用的服务器和存储设备。这些硬件的采购、维护以及升级都需要大量的资金投入。
  

• 与此同时，数据仓库相关的软件体系繁杂，包含各类计算和存储软件、数据集成、开发和资产管理软件等，软件种类繁多且企业级软件许可证费用也往往非常高昂。

2） ETL 工程的复杂性导致人员成本问题
数据仓库的运维、开发和管理需要高度专业化的技能，例如 ETL 开发需要熟悉数据建模、熟悉计算引擎的特性，还需要熟悉各类数据管理软件的使用，这意味着企业需要投入大量资金来招聘和培训专业人员。特别是对于传统数据仓库，数据建模、调优和管理的复杂性对人员的技术要求非常高，极大地增加了相关人力成本。

3）技术体系的不可变性带来的技术架构升级换代问题
传统数据仓库的架构一旦选定，数仓中的数据资产及其加工逻辑通常对底层的配套技术体系都是强制绑定关系。因此，当新的引擎技术或应用层软件出现时，企业若想升级，往往只能完全摒弃原有的技术体系。这种强绑定关系导致企业难以实现平滑的技术升级和兼容，进而引发数据孤岛、多套数据仓库工具体系并存等问题。

2.4.3. 长期运行后面临大量资产膨胀带来的 ROI 不匹配问题
数据仓库的属性决定了它本质上是一个“只进不出”的系统，数据会随着时间的推移不断累积。

在面向物理建模的数仓中，数据增长的维度主要体现在两个方面：物理表的数量和物理表的数据量。

• 物理表数量：随着业务需求的扩展，物理表的数量会不断增加。
  

• 物理表数据量：物理表中的数据量则是随着时间自然积累的。例如，对于常见的数仓分区表，假设单表每天产生 1 万条数据，一年即会积累 365×10,000 条数据。通常，这些数据会按照年累积持续增长。

假设每年物理表的数量增长 1 倍，物理表的数量和存储数据量的增长关系可以通过如下表格体现：

根据上述表格统计， 即便不考虑中间层的冗余，到第三年，尽管物理表的数量增长为第一年的 3 倍，但存储数据量却增长到第一年的 6 倍。这表明，数据仓库的存算成本并非与业务增长呈线性关系，而是随着时间呈现出放大的趋势。

从业务视角来看，实际情况往往更为复杂。通常在第二年或第三年，随着业务对数据仓库需求的增加，表数量并非像表格中那样简单线性增长（每年增加 1 倍），而是可能出现急剧增长的情况，而整体数据量的增长则又将是表增长规模的数倍。对此，在传统数据仓库的设计和运营中，为了支撑不断扩大的业务需求，如何有效控制物理表数量的增长，已成为衡量数据仓库投资回报率（ROI）甚至成败的关键指标。

为何有些企业的数据仓库和大数据平台建设能够取得成功，而另一些企业却失败，其核心原因在于企业如何应对和克服上述三个层面的问题。毫无疑问，那些成功的企业无一例外地在数据仓库建设中投入了大量的人力、物力和资源，通过有效的手段解决了上述问题，从而确保了数仓体系的稳定性和实用性。相比之下，那些实施不成功的企业往往在规划和实施过程中忽视了这些问题的复杂性，缺乏充分的应对措施，导致仓促上马，最终数仓建设未达预期，甚至以失败告终。这表明，是否能够正视并解决数仓建设中的关键问题，是决定企业数仓建设成败的关键所在。

三、逻辑数据编织架构

概念解释：

• 数据编织：数据编织（Data Fabric）作为一种新兴的数据管理架构理念，近年来获得广泛的关注，主要用于简化企业或机构中的数据访问，从而促进自助数据消费。此架构与数据环境、底层存储格式、数据源的类型和数据所在的地理位置无关，同时集成了端到端的数据管理功能。借助数据编织，无论数据位于何处，企业均可在正确的时间提供正确的数据，从而提升其数据的价值。
  

• 数据虚拟化：数据虚拟化技术是一种通过逻辑表（Logical Table）和逻辑视图 (View) 实现跨源、跨地域数据逻辑映射与加工的技术，通常由数据虚拟化引擎实现，无需物理数据迁移，可快速整合分散数据，提升数据访问效率。是数据编织理念的重要支撑技术。
  

• 逻辑数据编织平台：是基于数据虚拟化技术实现数据编织架构理念的大数据平台。Aloudata AIR 是该品类的典型代表。
  

• 逻辑数仓：应用逻辑数据编织平台，基于数据虚拟化技术搭建的数据仓库，我们称之为逻辑数仓。有别于传统数仓，逻辑数仓里面的数据资产并不都是物理存储的，存在大量逻辑化的数据资产。

3.1. 什么是数据编织

数据编织（Data Fabric）是一种新兴的数据管理理念，旨在通过数据虚拟化技术，逻辑统一管理异构数据，将来自所有相关数据源的数据以灵活且业务友好的形式交付给数据消费者，从而实现比传统数据管理更高的价值。Gartner 将数据编织定义为一种跨平台的数据整合方法，不仅能够整合所有业务信息，还具备灵活性和弹性，使用户能够随时随地访问和使用任何数据。数据编织的核心在于通过数据虚拟化技术消除传统数据整合方式中复杂的数据物理迁移，使得数据可以直接从源系统被消费，极大地提升了数据交付的效率和灵活性，同时降低了数据管理的复杂性和成本。

数据虚拟化技术是一种为数据使用者提供统一、抽象且封装的视图的方法，用于查询和操作存储在异构数据存储集合中的数据。本质上，数据虚拟化是一种资源封装技术，通过在数据使用者和数据存储之间引入一个中间层，屏蔽了数据存储的位置、技术接口、实现细节以及使用平台等复杂性。

数据虚拟化的架构涉及三个层面：

• 数据虚拟化层：作为数据使用者与底层数据存储之间的桥梁，提供统一的访问接口，隐藏数据存储的实现细节。
  

• 数据使用者：通过虚拟化层与数据交互，无需了解数据存储的实际位置和技术细节。
  

• 数据源：可以是分布式的、异构的存储系统，例如关系型数据库、NoSQL 数据库、云存储等。

简而言之，数据虚拟化封装了数据资源，屏蔽了底层技术细节，使应用程序能够通过一个简单的接口与数据交互，显著降低了数据访问的复杂性并提升了灵活性。如下图所示，数据虚拟化层通过统一视图实现数据使用者与存储之间的无缝连接：

数据使用者 ? 数据虚拟化层（统一接口） ? 数据源（分布式或异构存储系统）

这种设计在复杂数据环境中，尤其是异构数据整合场景下，极大地提高了数据访问效率和开发灵活性。

3.2. 什么是逻辑数据编织平台

逻辑数据编织平台 = 异构数据编织 + 计算引擎编织 + AutoETL

逻辑数据编织平台通过整合异构数据编织、计算引擎编织和 AutoETL（NoETL）技术，为数据使用者提供了一种高效、智能、灵活的统一数据处理平台，彻底降低了异构数据处理和开发的复杂性。以下是平台的核心组成及其功能特点：

• 异构数据编织：通过统一的 SQL 查询能力实现对异构数据源的整合，类似于 Presto、Trino、Spark 等跨源查询引擎。数据虚拟化引擎在连接层统一集成各类数据源，并通过标准化的 SQL 接口提供跨源查询和数据处理功能，使用户能够高效访问和操作多种数据类型而无需关注底层存储细节。

• 异构数据编织：通过统一的 SQL 查询能力实现对异构数据源的整合，类似于 Presto、Trino、Spark 等跨源查询引擎。数据虚拟化引擎在连接层统一集成各类数据源，并通过标准化的 SQL 接口提供跨源查询和数据处理功能，使用户能够高效访问和操作多种数据类型而无需关注底层存储细节。

• 计算引擎编织：通过引擎虚拟化技术，根据不同场景智能路由数据处理和查询请求（如数据同步、批处理、实时处理、OLAP 分析等）到最适合的计算引擎。计算引擎编织能够根据任务类型，将数据处理请求分发到底层不同的引擎，以充分发挥各类引擎在特定场景下的性能优势。同时，它为用户提供了统一且简化的数据操作界面，屏蔽底层复杂性，提升使用体验和开发效率。

• AutoETL（ETL 作业自管理）：ETL 工程是传统大数据处理中不可或缺的关键环节，不仅涉及业务建模与物理建模（数据加工逻辑），还包含为所有数据资产配置任务调度，由于涉及大量底层技术细节，传统 ETL 通常对工程师的技术要求极高。在 逻辑数据编织平台中，通过自研的关系投影技术（Relational Projection 简称 RP），将底层的物理作业和物理表与上层用户编写的数据加工逻辑完全解耦，使数据开发人员只需专注于数据加工逻辑本身。具体的 ETL 作业生成与编排均由平台中的虚拟化引擎自动完成。此外，由于引入了隔离层，用户在处理和使用数据时无需感知底层作业和物理表的存在，相关作业和物理表的创建和回收都由系统自动实现。这种 AutoETL 能力显著降低了数据加工的技术门槛和开发成本，让用户更专注于业务逻辑，从而提高开发效率。

3.3. 逻辑数据编织平台的核心能力

逻辑数据编织平台只需通过简单的三步流程（连接、合并、消费），即可实现企业全域数据的集成、加工和消费。

• 统一数据连接层：通过定义统一的数据连接层，实现数据的互联，无需搬运数据或关注其物理存储位置。该层支持多种类型数据源的无缝连接，包括传统关系型数据库（如 MySQL、Oracle、SQL Server、PostgreSQL 等）、NoSQL 数据库（如 Elasticsearch、HBase 等）、文件和对象存储（如 Iceberg、Hudi、HDFS 等），以及常见的 MPP 引擎（如 ClickHouse、 GaussDB 等）。统一数据连接层还支持基于视图定义维度模型（如星型模型和雪花模型），通过基于业务语义的方式进行数据模型的定义和使用，使数据开发人员能够在一个抽象层面上构建和操作复杂的跨源数据模型，从而大幅提升数据整合和分析的效率。

• 多层数据视图（View）：实现数据分层组织：在逻辑数据仓库的定义过程中，实践表明使用多层视图有助于实现清晰的数据分层组织。通常建议至少定义以下四层视图：

  1. 虚拟基础层（VODS）：虚拟基础层是存储在源系统中的数据映射。我们为源系统中的每个物理表或文件都定义一个 VODS，这层无任何业务加工逻辑，和源头表是一一对应的。

  2. VDWD 虚拟数据明细层：第二层的视图提供了源系统中所有数据的集成视图，因此称为虚拟化的数据明细层。每个视图的结构都是“中性的”，换句话说，它不针对某个数据消费者的需求，而是支持尽可能多的使用形式。如果可能的话，每个视图都应根据第三范式构建。如果需要保存数据历史，我们一般也建议只在这层通过 RP 来实现。3.VDWS 虚拟数据服务层：主要用于存储经过清洗、加工和汇总后的数据，以供用户进行查询和分析。在 VDWS 层，数据通常以更高层次的汇总（或称之为细粒度汇总、轻粒度汇总）和聚合形式进行存储，以支持各种业务分析需求。

  4. VADS 虚拟数据消费层数据消费层：每个视图的结构侧重于简化消费者的数据访问。例如，某些数据消费者希望将数据组织为星型模式，而另外一些数据消费者则希望能够在一个包含大量列的视图中查看所需的所有数据。在数据消费层指定过滤、映射、转换和聚合等操作，仅向数据消费者展示他们所需的相关数据。

  查询加速（下方核心技术部分具体展开）
  当面对大规模数据量下，数据查询响应慢的情况，支持人工指定物化加速和 AI 增强自适应物化加速两种方式。人工指定物化加速，只需要通过勾选需要加速的数据，系统将自动化进行链路编排和加速，当有查询请求时，如果命中该物化数据，系统将会进行自动化的路由改写，从而提升查询响应性能。AI增强自适应物化加速则更进一步，不需要主动指定需要加速的数据，系统会根据用户查询行为，自动生成需要加速的方案。

  
  

• 基于虚拟表实现统一数据安全管控企业数据安全管控面临三大核心问题：1. 数据治理分散：多源异构数据系统激增，缺乏统一安全机制与共享平台；2. 访问控制困难：孤立的工具与分散的规则导致难以制定统一的内外部访问策略；3. 地理合规挑战：跨国数据复制增加成本，影响数据质量，并可能违反区域数据保护法规。

• 通过使用数据虚拟化作为业务用户和应用程序的数据交付平台，可以大大简化这个维护问题。企业可以使用一组预定义的规则和流程，统一数据访问出口、安全管控、访问监控和安全策略，来确保其散落在各个地方的数据的可用性、完整性和安全性。在跨云、跨地域的联合分析场景中，通过“联邦本地计算”的跨境数据查询方案，在数据不流动的情况下实现境内外数据的统一关联分析和快速查询，确保数据使用过程中的合规和敏感性保护。虚拟表还可基于实时血缘，查询时动态评估字段的敏感等级，支持动态脱敏展示与加工，安全管控无死角。

• 基于开放 API 实现统一数据服务提供跨源的，基于湖仓一体化的全域资产秒级查询服务，为了满足数据各类数据消费场景的需要，Aloudata AIR 支持以下数据消费方式：

• 1. JDBC & ODBC：支持 Presto 客户端通过 ODBC、JDBC 连接，支持 Presto DQL 语法和函数。支持 MySQL 客户端通过 ODBC、JDBC 连接，支持 MySQL DQL 语法和函数。
  可同各类 BI、AI 或者数据治理等第三方工具与平台无缝集成。

• 2. 数据服务：支持数据服务的上下线和版本管理。支持数据服务的流量管控。支持数据服务的权限管理。支持数据服务的访问监控。 3. 数据导出：用于大规模数据交换的场景，可将大数据量的逻辑表导出到关系型数据库、对象存储、数据仓库等目标源。

• 4. 数据下载：用于小规模数据交换场景，可将逻辑表数据以 CSV、TXT、Hyper 等格式下载到本地。

3.4.  逻辑数据编织平台的核心优势

与传统的数据处理技术相比，逻辑数据编织平台具有以下四大优势：

• 零复制：数据虚拟化通过将各种不同的、分布式的数据源（无论是本地还是云端）进行统一映射，创建一个具有语义一致性的虚拟数据层，统一数据定义语法，统一数据模型定义，实现对企业所有数据的统一访问。

• 免运维：隐藏了数据环境和 ETL 链路的复杂性，让数据开发工程师更专注于数据模型的设计，而不是陷于琐碎枯燥的物理数据管道的运行监控、变更响应、性能调优、链路变更等运维工作上，能在降低成本的同时带来更高的扩展性，实现敏捷开发。

• 自治理：依据查询行为自动回收低收益的关系投影或重新选择最佳投影构建方案，相比传统 ETL 工程可降低至少 30% 数据存储成本和 70% ETL 运维成本。

• 实时性：数据虚拟化实时“连接”底层数据源，可向下游各个应用程序提供最新数据。

3.5. 逻辑数据编织平台的查询性能优化

逻辑数据编织平台通过哪些技术手段，使得企业访问虚拟化的资产，仍然能够获得同本地物理数仓一样、甚至更好的数据处理体验？

智能查询下推，数据就近计算：传统的跨源查询引擎如 Presto/Trino/Spark 等下推限制较多，导致很多场景的下推支持有限，例如跨源的 AGG 下推、Union下推及全下推等等。Aloudata AIR 虚拟化引擎具备更加灵活的下推策略，在复杂的业务场景下可进行更加灵活的适配。