万字长文详解｜逻辑数据编织 VS 传统数据研发

一、引言

随着企业信息化进程的快速推进，各类应用程序持续产生海量数据。过去近一个世纪的发展历程中，数据管理系统经历了从关系型数据库（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

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

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

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

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

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

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

• 统一数据连接层：通过定义统一的数据连接层，实现数据的互联，无需搬运数据或关注其物理存储位置。该层支持多种类型数据源的无缝连接，包括传统关系型数据库（如 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 虚拟数据消费层数据消费层：每个视图的结构侧重于简化消费者的数据访问。例如，某些数据消费者希望将数据组织为星型模式，而另外一些数据消费者则希望能够在一个包含大量列的视图中查看所需的所有数据。在数据消费层指定过滤、映射、转换和聚合等操作，仅向数据消费者展示他们所需的相关数据。

• 查询加速（下方核心技术部分具体展开）：当面对大规模数据量下，数据查询响应慢的情况，Aloudata AIR 支持人工指定物化加速和 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. Aloudata AIR 逻辑数据编织平台的核心优势

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

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

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

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

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

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

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

智能查询下推，数据就近计算：传统的跨源查询引擎如 Presto/Trino/Spark 等下推限制较多，导致很多场景的下推支持有限，例如跨源的 AGG 下推、Union 下推及全下推等等。Aloudata AIR 虚拟化引擎具备更加灵活的下推策略，在复杂的业务场景下可进行更加灵活的适配。1.下推场景举例：我们以 TPCDS 中的 catalogsales 和 callcenter 表的查询为例，假设存在以下 SQL，两张表分别来自不同的源。

通过下推优化，相同查询在开启下推和不开启下推的情况下，两者从远程库读取数据的数量存在数个数量级的差别，在源端计算能力强的场景下，下推开启可以带来极大的性能提升。

2.按源控制下推策略：Aloudata AIR 可以针对每个源配置完全不同的下推策略，以便适应灵活多样的查询场景。例如，假设客户存在两个不同的 PG 库数据源实例，一个连的是生产库、另外一个连的是生产备库，那么对于备库的实例，我们就可以配置更加彻底的下推策略，通过数据在源端就近计算，获取更好的查询性能。3.本地化视图：针对某些源可能存在极特殊的语法或者是特定的函数（例如安全函数），在 Aloudata AIR 还可以直接使用源自有的语法去创建本地化方言的逻辑视图，等同于用户去源库自己手工在源内部创建一个视图，对该逻辑视图的查询会直接下发给源本身来执行。

• 智能查询加速（RP：Relational Projection）智能查询加速（RP） 是一种高度自动化的预计算技术，通过提前保存耗时操作（如跨源 JOIN 和聚合）的结果，在查询时直接复用这些预计算结果，从而避免重复执行耗时操作，最终实现查询加速。其原理与许多引擎中的物化视图类似，但在物化视图的预计算能力上做了扩展，能够支持以下功能：

1.跨源数据预计算：支持从多个异构数据源中整合数据，进行统一的预计算和存储。2.增量分区预计算：针对动态变化的数据，智能查询加速（RP）通过类似传统数仓中的分区存储和预计算机制，针对新增或变更的数据分区进行增量计算和更新，从而高效实现超大规模数据的预计算。3.多重依赖预计算：能够处理复杂的数据依赖关系，确保多层数据预计算的正确性和完整性。4.实时任务预计算：支持基于订阅数据库的变更日志进行实时数据预计算，为低延迟查询提供保障。

通过这些扩展能力，RP 不仅加速了查询性能，还显著提升了在复杂场景下的适应性和实用性。（后文为简化表达，在部分场景中将加速后生成的物理表也简称为 RP。）

1.透明查询改写（RP：Relational Projection）查询加速后的数据会在后续的查询和加速过程中被智能改写并自动命中，实现加速数据的高效复用。这不仅显著提升了相关查询的性能，还进一步优化了后续加速任务的执行效率。常见的改写案例如下：

2.通用查询改写：

假设存在如下加速的 RP：

进行以下查询时，查询都会自动命中 RP，且查询结果会自动改写：

查询会自动改写成：

再看一个更加复杂的 SQL

查询 SQL2 会自动改写成

通过查询改写，原本是跨源 JOIN 查询会变成直接从本地存储的 RP 物理表中（单表）查询，从而可以极大的提升数据查询的性能。

3.多层嵌套视图的查询改写：假设我们存在如下逻辑加工分层，View1 -> View2 -> View3 -> View4，其中 View4 依赖 View3，而 View3 依赖 View2，以此类推，当然也可以某个 View 依赖 0~N 个上游的其它 View，从而形成一个分层的数据视图加工依赖链。当我们在 View2 视图上创建 RP 之后，那么所有查询 View2 及其下游的视图，例如 View3 和 View4 的 SQL 都会被自动改写成从 View2 的 RP 加工结果上查询数据。从而实现下游表的所有查询都可受益加速的效果。

4.聚合场景的查询改写：在大数据分析场景下，我们经常会存在基于事实表（web_sales）和维表（item）进行关联的数据分析统计查询场景，例如：

如果我们经常会基于产品表（item）的不同维度去统计销售数量或者销售金额，那么我们可以创建如下 AGG RP：将“事实表”的产品键（ws_item_sk）设置为维度字段，将销售数量（ws_quantity）和销售金额（ws_sales_price）设置为度量字段，并设置需要支持的度量统计算子（例如 SUM, COUNT, MIN, MAX）等。RP 配置如下图：

当用户进行以下查询时

select sum("ws_sales_price")，sum("ws_quantity") from "web_sales" left join "item" on "web_sales"."ws_item_sk"="item"."i_item_sk" group by "item"."i_brand_id"

查询 SQL 会被改写成：

select sum(EXPR_1), sum(EXPR_2) from RP left join "item" on RP."ws_item_sk"="item"."i_item_sk" group by "item"."i_brand_id"

这个查询可以复用 AGG RP 预先基于产品键做的轻粒度汇总表，从而，将聚合操作的计算数量由事实表的几千万甚至上亿的数据计算变成基于产品表数量的几十万计算统计，从而极大降低每次查询计算扫描数据的数量，进而提升相关查询的查询性能。我们所有基于 item 表作为维度的汇总查询都可实现加速，通过 AGG RP 可以极大降低传统数仓中轻粒度汇总表的开发数量，以及加速轻粒度汇总逻辑表的查询性能。

四、逻辑数据编织平台和传统数据研发平台对比分析

4.1. 为什么说逻辑数据编织（逻辑数仓） + BI 工具的数据架构是大部分中小企业最经济、快捷的大数据解决方案？

通过逻辑数据编织平台构建的数据仓库，我们称之为逻辑数仓。

逻辑数仓为何可极大节省整个数仓的成本？

1）资产按需创建物理 ETL（RP）方案

• 逻辑数仓的资产建设方案：ODS 层通过逻辑集成自动生成，不保留数据历史。DWD 层通过加工逻辑生成逻辑视图，由于需要保留数据历史，因此 DWD 层建议对历史数据进行 RP 物化（类似于传统数仓中的各类快照表）。DWS 和 ADS 等层通过逻辑视图加工数据，仅对少部分常用且查询性能较慢的视图进行 RP 物化处理。

• 通过逻辑化后的按需物化可以节省哪些成本？ 那么，同样的分层资产建设，假设 ODS 层有 1,000 张表，DWD 层 500 张表，DWS 层 400 张表，应用层 500 张表（我们以客户刚建设数仓第一年的状态来假设数据，实际的情况是，随着数仓使用时间的增加，一般应用层的表数量往往会极度膨胀），那么传统数仓中我们需要建设：1,000 + 500 + 400 + 500 = 2,400 张物理表及其对应的调度任务。如下图：

图：物理数仓（2,400 张物理表及其对应的调度任务）

在逻辑数仓中，我们同样存在 2,400 张逻辑表，但物化的表数量只有 500 +（400+500）* 0.1（根据 Aloudata AIR 用户实践，通常应用层需要加速的表数量不足 10%）= 590，如下图：

图：逻辑数仓（2,400 张逻辑表，其中 590 张逻辑表进行物理加速）

我们可以看到，在建设同等规模的数仓资产情况下，逻辑数仓的真实物理表和对应的 ETL 调度作业数，只占传统数仓方案的：590/2,400 * 100 = 24%，意味着我们只需要通过 24% 左右的 RP 即可满足整个数仓资产建设的需求。换句话说，逻辑数仓可以通过 24% 的存储表和对应的计算调度任务，即可达到传统数仓通过 2,400 张物理表和对应任务的相同效果。

2）整个数仓只需 24% 的物理表和 ETL 作业，对 ETL 工程师日常工作意味着什么？

• 首先，数仓的数据是存储历史的数据，以比较极端的全量快照表为例，每天存储一份全量快照，那么一年就会存了 365 份快照数据，而且该表下游依赖的表大部分都要以类似的逻辑存储相应的数据，因此从数据存储量来看，整体的存储规模：总存储规模 = 物理表数量*天数*单天存储大小。所以物理表的数量的多少会成倍放大整个数仓的数据存算成本。

• 其次，以客户最终消费的末端表视角来看，其上游的每张物理表的数据产出质量都会直接影响最终数据的可用性，那么这就需要 ETL 工程师保障从 ODS 层开始的整个依赖链路上的表的日常运行状态。例如，是否存在任务失败，如果失败了，失败节点及下游都需要去手工重新补数；再比如，数据产出时效问题，如果某一层由于各种原因没有及时调度或者运行慢了，会直接影响最终表的数据是否可用。上述的问题都会随着加工表的依赖层级增加而逐步放大，进而导致最终资产的可用性降低，因此在传统数仓建设中，如果能降低这种物理依赖层次，就可以极大增强资产的可用性（这也是传统数仓链路数据治理优化的最基本思路）。而逻辑数仓的这种按需物化的资产构建思路，方案本身天然降低了整个数仓物理调度作业的数量和依赖层级，在大幅提升资产可用性的同时，也大大降低了数据工程师本身的运维成本。

• 最后，数据加工口径的变更成本。例如，当我们想变更 DWS 层某个加工逻辑的口径，在传统数仓架构中，我们变更逻辑后，从该表开始，下游所有依赖表都需手工回刷数据（甚至有些场景需要回刷所有历史数据），那么也意味着下游依赖的物理表越多，本次变更回刷的工作量就越大。而在逻辑数仓中，由于 DWS 及其下游的 ADS 层大部分表都是虚拟化的，每次变更，我们只需回刷少量的表甚至完全无需回刷任何数据，即中间层逻辑变更后数据可立即生效，这也极大降低了数据工程师变更数据加工口径时的工作量。

3）逻辑数仓为何通过 24% 的物理表，还能获得比传统数仓更好的查询和分析性能？

• 集成多引擎能力：

从技术视角来看大数据引擎分类在大数据体系中，面向批处理的 MPP 引擎主要分两大类，一类是面向大规模跑批作业的引擎，典型的代表如 Hive、Spark 等，这类引擎由于运行时中间数据会落盘，可以通过消耗有限的 CPU 和内存来运行大数据量且复杂的 SQL，因此非常适合跑大规模预计算作业（ETL 作业）。例如一次需要跑几分钟甚至几个小时的作业，并且具备高效的作业容错及服务器容错机制，这类引擎以极低的资源消耗运行复杂的数据处理逻辑，即 SQL 的执行成本低，且作业运行成功率高。一般来说，传统的数仓引擎基本都以这类引擎为底座。

另外一类的代表是面向分析场景的 OLAP 引擎，这类引擎主要面向查询性能做极致优化，通过向量化计算、流水线及并行执行等技术可以获取极快的查询性能，但缺点是需要大量的 CPU 和内存资源。这两类引擎因为设计目标不同导致计算架构和产品特性存在极大的差异，例如传统跑批引擎，尽管也引入了大量面向分析计算的优化，但单次查询的性能也远远无法匹配专门为单次查询性能优化设计的 OLAP 引擎；反之，OLAP 引擎想获得传统跑批引擎大规模数据场景下的经济性、稳定性就必须牺牲为追求极致性能而设计的架构。这是当前大数据计算引擎架构在查询性能与执行成本和稳定性两方面无法调和的矛盾，本质上是引擎架构的选择决定了引擎特性的差异。

从用户视角来看大数据引擎选择从用户的视角来看，当在跑大规模预计算作业（ETL 作业）的时候，会关注底层引擎运行的成功率（稳定性）及经济性（跑同样的作业消耗尽量少的资源）；但当在做数据探查和查询的时候，又希望引擎能够具备极高的查询性能。用户希望鱼和熊掌兼得，而现实情况则是通过单一引擎无法实现。企业在落地大数据方案时，只能选择适合跑批的计算引擎用于批处理场景，而分析场景则通过接入专门的 OLAP 分析引擎来实现。引入两套不同的方案，意味着用户使用场景的割裂或者体验的牺牲。

逻辑数据编织平台通过计算引擎编织，可以完美融合跑批引擎和 OLAP 引擎的优点，让用户获得一个兼顾跑批稳定性和经济性，同时又能在数据查询时获得极致查询性能的完美引擎，更重要的是，整个路由过程用户是无感的，计算引擎编织可以根据用户的每次查询行为（预计算还是分析查询），自动选择最适合的引擎来执行。这也意味着，数据开发工程师在数仓环境处理数据或者分析数据时，也可以享受到极致的查询性能；而数据分析师在分析数据过程中，当需要对部分数据量较大的表进行临时加工和处理时，也可以无需求助 ETL，无感地使用跑批引擎来对数据进行预计算处理。

4）通过 SQL 改写实现自动物理资产复用：

传统数仓的资产复用是一种人工登记式的复用，通过显式查询公共表来实现。如果使用方不知道这张公共表的存在，那就无法实现资产的复用，很容易出现重复资产加工的问题。复用别人的资产前，还需要人工分析资产的加工口径是否符合自身场景的需要，而这需要花费大量的时间去分析上游资产的加工逻辑（加工口径）。

逻辑数仓中的资产复用则是一种基于逻辑算子的自动复用。在逻辑数仓中，对所有用户而言，除去最基础的公共 VDWD 层，其它层的资产可以无需考虑资产复用的问题，每个人都可以独立建设自己的逻辑资产。举个简单的例子，假如张三将一张大表 A 和 B 做了 Join 计算，李四在另外一个场景也用到了 A Join B，并在之上进行了更进一步的汇总如 Group by 统计。只要张三对 A Join B 表的结果进行了 RP 加速，那么李四的查询会自动复用张三的加速计算结果，因为他们有共同 A Join B 的打宽逻辑。最终，对于单个用户而言，整个数据仓库会有“越用越快”的效果，实际上是总有人在数据处理过程中创建 RP，由于数据热点的存在（80%的业务场景聚焦在 20% 左右的热点表和数据上），使得其它用户也能从这种 RP 加速中受益，从而带来这种神奇的效果。

应用层资产膨胀问题的消除。我们知道，数仓建设越久，应用层资产膨胀就越严重，因为业务需求可能会快速变化，资产数量也就随之不断膨胀，这给传统数仓带来了极大的数据治理挑战。但在逻辑数仓中，一方面由于大部分应用层资产都是逻辑资产，这类逻辑资产的膨胀并不会直接导致计算和存储的大量浪费。另外一方面，逻辑数仓的资产一般都是直接开放给消费端使用，这就给了虚拟化引擎很大的优势，它可以真正感知，到底哪个资产被消费，哪个资产没人使用了（传统数仓中由于数据都是导出到外部系统使用，从而很难感知）。Aloudata AIR 逻辑数据编织平台具有 RP 的自动回收技术，会自动回收加速后不再被使用的物理表。RP 的自动回收只是把底层的定时调度的计算任务和存储的物理表回收了，逻辑资产在用户看起来仍然是存在的，并且仍然随时都可以使用。因此，应用层资产膨胀问题对逻辑数仓的影响几乎可以忽略不计。

5）逻辑数仓核心优势

通过数据编织理念构成的逻辑数仓方案，是一种全新的数据仓库构建形式，如果使用时将每个逻辑表都物化，即可以完全退化到和传统数仓一模一样的解决方案，因此，逻辑数仓架构可以完全兼容传统的物理数仓架构。同时它又具有传统物理数仓架构完全无法具备的优势。在同等资产规模的情况下，逻辑数仓的运维成本、经济性、查询性能等各个方面都远远优于传统数仓方案。

相较传统数仓面临的三大问题，利用逻辑数据编织技术实现的逻辑数仓优势明显：

• 逻辑资产相较物理资产，更容易变更、维护，成本也更低。这意味着，可以更低成本去构建临时态的数据仓库。传统数仓架构下，由于存在大量物理表和加工作业，必须严格控制资产的建设思路，分层规划，精心建设，才可以最大化避免或者降低后期资产重构和数据复制的次数，从而降低资产构建的整体成本。类似传统软件的研发架构，面向物理表的数据仓库建设，是典型的瀑布式软件研发思路。而逻辑数仓，由于引入虚拟化技术，可以实现低成本、快速的资产变化和调整，类似软件开发中的敏捷开发思路，以不断快速迭代逻辑数据资产方式，让数据资产可以更快更好地贴近实际业务的需要。

• 去掉了庞大的数仓技术栈和繁杂的工具体系。数据虚拟化技术隐藏了底层计算引擎的复杂性和高门槛，数据工程师在处理数据时可以无需关心原始数据的位置和计算引擎的差异，从底层的数据集成、引擎调优、数据消费同步等繁杂的技术细节中解放出来，专注于数据的加工逻辑本身。同时，由于虚拟化引擎向上提供的逻辑隔离层的存在，使得底层大数据计算引擎的更新换代，对上层的数据处理工程和数据分析过程透明，上层的业务代码对底层引擎的切换和升级几乎无感。

• 避免了长期运行后面资产膨胀带来的 ROI 不匹配问题。在逻辑数据编织平台中进行数据开发，同样会面临资产膨胀的问题，但有了资产逻辑化 + 物理表自动复用技术的支持，资产膨胀并不会带来计算和存储的爆发式增加，从而可以从根本上避免传统数仓面临的存算成本挑战，让 ETL 工程师更加从容面对业务的快速变化及数仓内部逻辑资产的重构。

通过上面的总结分析可以看到，通过逻辑数据编织平台的实施，传统数据仓库解决方案面临的核心问题基本都得到了很好的应对和解决。

借助逻辑数仓的敏捷数据研发，可以抛弃传统数仓方案的大开大合高举高打的建设思路，转向精打细算小步快跑的新一代数据仓库建设思路。使得企业的大数据解决方案可以变得更加务实，以更低成本为业务带来切实价值。