数据仓库概念
数据仓库具有四个基本特征：面向 主题的 （Subject-Oriented）、 集成的 （Integrated）、 非易失的 （Non-Volatile）和 时变的 （Time-Variant）数据集合，这些特征共同支持管理决策的制定。
数据仓库与数据库的区别：数据库是为捕获数据而设计，数据仓库是为分析数据而设计。
数据仓库的架构
在传统数据仓库架构中，数据通过各类采集工具物理汇聚到 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）。我们通常说的报表数据或大宽表通常存储于此层。
逻辑数据编织架构
- 数据编织： 数据编织（Data Fabric）作为一种新兴的数据管理架构理念，近年来获得广泛的关注，主要用于简化企业或机构中的数据访问，从而促进自助数据消费。此架构与数据环境、底层存储格式、数据源的类型和数据所在的地理位置无关，同时集成了端到端的数据管理功能。借助数据编织，无论数据位于何处，企业均可在正确的时间提供正确的数据，从而提升其数据的价值。
- 数据虚拟化： 数据虚拟化技术是一种通过逻辑表（Logical Table）和逻辑视图 (View) 实现跨源、跨地域数据逻辑映射与加工的技术，通常由数据虚拟化引擎实现，无需物理数据迁移，可快速整合分散数据，提升数据访问效率。是数据编织理念的重要支撑技术。
- 逻辑数据编织平台： 是基于数据虚拟化技术实现数据编织架构理念的大数据平台。Aloudata AIR 是该品类的典型代表。
- 逻辑数仓： 应用逻辑数据编织平台，基于数据虚拟化技术搭建的数据仓库，我们称之为逻辑数仓。有别于传统数仓，逻辑数仓里面的数据资产并不都是物理存储的，存在大量逻辑化的数据资产。
关键技术
逻辑数据编织平台通过哪些技术手段，使得企业访问虚拟化的资产，仍然能够获得同本地物理数仓一样、甚至更好的数据处理体验？
1）智能查询下推，数据就近计算： 传统的跨源查询引擎如 Presto/Trino/Spark 等下推限制较多，导致很多场景的下推支持有限，例如跨源的 AGG 下推、Union 下推及全下推等等。Aloudata AIR 虚拟化引擎具备更加灵活的下推策略，在复杂的业务场景下可进行更加灵活的适配。
- 下推场景举例：我们以 TPCDS 中的 catalog_sales 和 call_center 表的查询为例，假设存在以下 SQL，两张表分别来自不同的源。
`SELECT sum(b.cs_sales_price),a.cc_class` `FROM gauss.tpcds.catalog_sales b``JOIN mysql.tpcds.call_center a` `ON a.cc_call_center_sk=b.cs_call_center_sk` `GROUP BY a.cc_class;`
通过下推优化，相同查询在开启下推和不开启下推的情况下，两者从远程库读取数据的数量存在数个数量级的差别，在源端计算能力强的场景下，下推开启可以带来极大的性能提升。
- 按源控制下推策略：Aloudata AIR 可以针对每个源配置完全不同的下推策略，以便适应灵活多样的查询场景。例如，假设客户存在两个不同的 PG 库数据源实例，一个连的是生产库、另外一个连的是生产备库，那么对于备库的实例，我们就可以配置更加彻底的下推策略，通过数据在源端就近计算，获取更好的查询性能。
- 本地化视图：针对某些源可能存在极特殊的语法或者是特定的函数（例如安全函数），在 Aloudata AIR 还可以直接使用源自有的语法去创建本地化方言的逻辑视图，等同于用户去源库自己手工在源内部创建一个视图，对该逻辑视图的查询会直接下发给源本身来执行
2）智能查询加速（RP：Relational Projection）： 智能查询加速（RP） 是一种高度自动化的预计算技术，通过提前保存耗时操作（如跨源 JOIN 和聚合）的结果，在查询时直接复用这些预计算结果，从而避免重复执行耗时操作，最终实现查询加速。其原理与许多引擎中的物化视图类似，但在物化视图的预计算能力上做了扩展，能够支持以下功能：
- 跨源数据预计算： 支持从多个异构数据源中整合数据，进行统一的预计算和存储。
- 增量分区预计算： 针对动态变化的数据，智能查询加速（RP）通过类似传统数仓中的分区存储和预计算机制，针对新增或变更的数据分区进行增量计算和更新，从而高效实现超大规模数据的预计算。
- 多重依赖预计算： 能够处理复杂的数据依赖关系，确保多层数据预计算的正确性和完整性。
- 实时任务预计算： 支持基于订阅数据库的变更日志进行实时数据预计算，为低延迟查询提供保障。
通过这些扩展能力，RP 不仅加速了查询性能，还显著提升了在复杂场景下的适应性和实用性。（后文为简化表达，在部分场景中将加速后生成的物理表也简称为 RP。）
3）透明查询改写（RP：Relational Projection）： 查询加速后的数据会在后续的查询和加速过程中被智能改写并自动命中，实现加速数据的高效复用。这不仅显著提升了相关查询的性能，还进一步优化了后续加速任务的执行效率。常见的改写案例如下：
- 通用查询改写：假设存在如下加速的 RP：
SELECT
"ss_addr_sk",
"ss_sold_date_sk"
FROM
"store_sales"
LEFT JOIN "date_dim" ON "ss_sold_date_sk" = "d_date_sk"进行以下查询时，查询都会自动命中 RP，且查询结果会自动改写：
SELECT
"ss_addr_sk",
"ss_sold_date_sk"
FROM
"store_sales"
INNER JOIN "date_dim" ON "ss_sold_date_sk" = "d_date_sk"
where "d_date_sk">2451167查询会自动改写成：
SELECT
"ss_addr_sk",
"ss_sold_date_sk"
FROM RP1
where "d_date_sk">2451167再看一个更加复杂的 SQL
select ss_addr_sk,ss_sold_date_sk
from (SELECT ss_addr_sk,ss_sold_date_sk FROM "store_sales" WHERE ss_sold_date_sk = 2451167)
inner join date_dim on ss_sold_date_sk = d_date_sk查询 SQL2 会自动改写成
SELECT
"ss_addr_sk",
"ss_sold_date_sk"
FROM RP1
where "d_date_sk"=2451167通过查询改写，原本是跨源 JOIN 查询会变成直接从本地存储的 RP 物理表中（单表）查询，从而可以极大的提升数据查询的性能。
- 多层嵌套视图的查询改写： 假设我们存在如下逻辑加工分层，View1 → View2 → View3 → View4，其中 View4 依赖 View3，而 View3 依赖 View2，以此类推，当然也可以某个 View 依赖 0~N 个上游的其它 View，从而形成一个分层的数据视图加工依赖链。当我们在 View2 视图上创建 RP 之后，那么所有查询 View2 及其下游的视图，例如 View3 和 View4 的 SQL 都会被自动改写成从 View2 的 RP 加工结果上查询数据。从而实现下游表的所有查询都可受益加速的效果。
- 聚合场景的查询改写： 在大数据分析场景下，我们经常会存在基于事实表（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 可以极大降低传统数仓中轻粒度汇总表的开发数量，以及加速轻粒度汇总逻辑表的查询性能
逻辑数据编织平台和传统数据研发平台
为什么说逻辑数据编织（逻辑数仓） + 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，无感地使用跑批引擎来对数据进行预计算处理。
通过 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 的自动回收只是把底层的定时调度的计算任务和存储的物理表回收了，逻辑资产在用户看起来仍然是存在的，并且仍然随时都可以使用。因此，应用层资产膨胀问题对逻辑数仓的影响几乎可以忽略不计。
4）逻辑数仓核心优势
通过数据编织理念构成的逻辑数仓方案，是一种全新的数据仓库构建形式，如果使用时将每个逻辑表都物化，即可以完全退化到和传统数仓一模一样的解决方案，因此，逻辑数仓架构可以完全兼容传统的物理数仓架构。同时它又具有传统物理数仓架构完全无法具备的优势。在同等资产规模的情况下，逻辑数仓的运维成本、经济性、查询性能等各个方面都远远优于传统数仓方案。
相较传统数仓面临的三大问题，利用逻辑数据编织技术实现的逻辑数仓优势明显：
- 逻辑资产相较物理资产，更容易变更、维护，成本也更低。 这意味着，可以更低成本去构建临时态的数据仓库。传统数仓架构下，由于存在大量物理表和加工作业，必须严格控制资产的建设思路，分层规划，精心建设，才可以最大化避免或者降低后期资产重构和数据复制的次数，从而降低资产构建的整体成本。类似传统软件的研发架构，面向物理表的数据仓库建设，是典型的瀑布式软件研发思路。而逻辑数仓，由于引入虚拟化技术，可以实现低成本、快速的资产变化和调整，类似软件开发中的敏捷开发思路，以不断快速迭代逻辑数据资产方式，让数据资产可以更快更好地贴近实际业务的需要。
- 去掉了庞大的数仓技术栈和繁杂的工具体系： 数据虚拟化技术隐藏了底层计算引擎的复杂性和高门槛，数据工程师在处理数据时可以无需关心原始数据的位置和计算引擎的差异，从底层的数据集成、引擎调优、数据消费同步等繁杂的技术细节中解放出来，专注于数据的加工逻辑本身。同时，由于虚拟化引擎向上提供的逻辑隔离层的存在，使得底层大数据计算引擎的更新换代，对上层的数据处理工程和数据分析过程透明，上层的业务代码对底层引擎的切换和升级几乎无感。
- 避免了长期运行后面资产膨胀带来的 ROI 不匹配问题： 在逻辑数据编织平台中进行数据开发，同样会面临资产膨胀的问题，但有了资产逻辑化 + 物理表自动复用技术的支持，资产膨胀并不会带来计算和存储的爆发式增加，从而可以从根本上避免传统数仓面临的存算成本挑战，让 ETL 工程师更加从容面对业务的快速变化及数仓内部逻辑资产的重构。
对逻辑数仓的评价
目前来看，基于逻辑数仓的方式跟物理数仓的方式
核心是使用方式上的区别。
传统数仓，需要从上层需求，去设计整个数仓结构。一旦需要变更需求，整个结构都需要变更。 灵活性差 ， 占用资源多
但是优势是性能好，将对性能的依赖完全转给数仓的性能。
逻辑数仓，也需要从上层需求，去设计整个数仓结构。但因为是在逻辑层面上，所以变动很容易，只需要在一个统一的平台进行增删改查的管理即可。灵活性高。占用资源少。
与此同时，Aloudata 通过 RP 的方案来构建数仓中的一些中间表作为物理表， 智能权衡占用资源和性能情况。
还有一个优势是，整个查询过程依托于 SQL， 各种异构资源统一用 SQL 进行查询。然后 Aloudata 内部通过 SQL 的解析来动态分析中间表。相当于我们目前 BI 中的步骤， 只是将步骤替换为 SQL，相比之下， 学习成本更低。
数据编织和数据湖
1. 核心定位不同
| 维度 | 数据湖 | 数据编织 |
|---|---|---|
| 核心目标 | 集中存储原始数据（Raw Data） | 动态整合数据并智能治理（Data Integration & Governance） |
| 关注点 | 存储成本、数据沉淀 | 数据可访问性、实时性、自动化治理 |
| 技术角色 | 数据存储层（Repository） | 数据管理层（Orchestration Layer） |
2. 数据处理逻辑对比
数据湖
- 存储优先 ：以低成本存储原始数据（如 Parquet、JSON 等），延迟处理（Schema-on-Read）。
- 被动连接 ：数据需先抽取并加载到湖中，才能被访问。
- 静态架构 ：依赖 ETL/ELT 管道，数据迁移成本高，扩展性受限。
数据编织
- 访问优先 ：通过虚拟化层直接连接数据源（无需迁移数据），按需处理（Schema-on-Demand）。
- 主动连接 ：动态路由请求到数据源，支持实时或近实时访问。
- 动态架构 ：基于元数据智能优化访问路径，适应业务变化。
3. 技术能力差异
| 能力 | 数据湖 | 数据编织 |
|---|---|---|
| 数据连接方式 | 需将数据复制到湖中 | 虚拟化连接，保留数据原位（无需复制） |
| 实时性 | 依赖批处理，延迟较高 | 支持实时/流式数据访问 |
| 治理能力 | 需额外工具（如数据目录、元数据管理） | 内置自动化治理（数据血缘、权限控制、合规检查） |
| 计算与存储耦合 | 存储与计算强绑定（如 Hadoop 生态） | 解耦存储与计算，按需调用资源 |