紧张内容包括以下几个部分：

1. 背景

2. 逻辑数据平台的构建方法与技能详解

3. 范例场景与案例

4. Q&A

分享高朋｜余俊 Aloudata 合资人 & 技能副总裁

编辑整理｜刘金辉

内容校正｜李瑶

出品社区｜DataFun

01

背景

传统数据仓库的一个显著特点是数据集中化管理。
详细来说，数据会被网络并存储在数据仓库中，集中进行处理。
数据经由加工后，常日会被导出到 OLAP 引擎，用于 BI 报告和各种剖析。
可以将这种传统数据仓库类比为现实天下中的仓库，但它们之间有一个根本差异：现实中的仓库有物品进出以保持平衡，而数据仓库则每每只有数据积累，并随着业务增长，数据量持续膨胀，这也是从事数据开拓的职员的共同感想熏染。

如果依旧采取传统的 ETL 处理办法来应对这种数据量增长，将面临本钱、规模和效率三者之间难以兼顾的困境。
从实际用户角度来看，无论是业务职员还是数据开拓者，最空想的情形是无论数据存放于何处，都能够便捷、迅速地利用这些数据，然而现实每每不如人意。
因此近年来逐渐盛行起一个观点——Data Fabric。

Data Fabric 的核心理念认为，将所有数据完备集中存储既不现实也不经济，该当通过虚拟化和其他技能手段实现逻辑上的集中管理。
这个理念承认了数据分散的现状，提出用新的思路来办理问题，并将其转化成行之有效的方法。

图 1：Data Fabric 示意图

个人而言，我认为 Data Fabric 与其说是一种技能的进步，不如说是技能蜕变一定走向的一个妥协的结果。
Data Fabric 的核心技能是数据虚拟化。
数据虚拟化紧张由几个层次构成，首先是底层的连接层。
这一层的关键特点在于它能够把各种不同构造、来源、地域和存储介质的数据映射为一个统一的模型层，为用户供应了一个数据交互的统一平面。
这种通过连接层屏蔽差异性来实现数据虚拟化的做法，为上层的各种数据整合奠定了根本。

有了这个根本之后，我们就可以在其之上进行各种数据加工处理逻辑定义，然后让终端消费者通过上层产品来利用这些数据。
这便构成了数据虚拟化的范例架构。
在这个架构下，我们面临的最大寻衅，正如我之条件到的，是在查询虚拟化的数据时如何办理性能问题，确保无论数据的规模有多大，用户都能得到近似于在本地直接进行数据查询的性能和利用体验。

02逻辑数据平台的构建方法与技能详解

那么如何构建一个企业级的逻辑数据平台呢？逻辑数据平台与传统数据仓库存在着哪些差异？Aloudata 打破了哪些技能限定，才实现了一个可靠、生产级的企业级逻辑数据平台？本文将考试测验回答上述问题。

逻辑数据平台的核心上风在于以下几点：首先，由于它履行逻辑集成，数据集成速率快，减少了韶光和人力本钱。
其次，数据能够保持实时更新，由于所有查询都是直接针对根本数据层进行的，因此可及时获取数据。
再次，总体本钱较低，由于它避免了大量源端数据重复存储和同步的本钱。

此外，逻辑数据平台支持异构数据源的统一接入，供应了一个通用的SQL 查询和剖析能力。
用户无需理解底层数据是否存储于 MySQL、HBase、Mongo、ES 或 GaussDB 等数据库，就可以像操作本地数据库一样平常方便地进行查询。
基于逻辑集成，可以在这一层上构建一个跨公司所有数据资产的统一资产管理和数据目录功能。
末了，得益于这种集中逻辑数据集成和整合的打算体系，我们可以为消费侧产品供应统一的数据访问做事、集中的权限和安全管控，所有这些能力共同构成了我们逻辑数据平台的整体架构。

图 2：逻辑数据平台上风

那么逻辑数据平台在实行数据集成和整合时，事情事理是若何的呢？这里我们有一个简化的模型图。
对付有 ETL 履历的工程师而言，应该不难明得，在传统数据仓库中，数据源采集进来后会构建贴源层的 ODS。
在逻辑数据平台中，同样存在一个类似的以虚拟表为根本的“贴源层”。

根据这一层虚拟表，我们连续向上进行更深入的数据整合，终极形成一个供外部利用的表，这便是供应给用户利用的数据表，例如客户的 360 全景视图或门店的 360 视图。

图 3：逻辑数据平台事情事理

但逻辑数据平台与传统 ETL 开拓办法存在着显著差异，在传统数据仓库中，所有表都是物理存储的，并且须要相应的人工 ETL 作业来支持，同时，我们还须要管理它们的依赖性和作业调度等等。
然而，在虚拟化的逻辑数据平台中，并不是所有表都须要建立物理 ETL 作业，而是只要在关键节点天生 ETL 作业，就可以知足用户对查询性能的哀求。

第二点差异在于，在逻辑数据平台上，用户不必关注底下的物理 ETL 作业细节，由于逻辑层的存在已经将这些细节封装起来了。
用户所看到的只是对外的视图，而至于这些视图后面是否建立了物理作业，是否与其他视图复用了同一个作业，这些都不再须要用户关心。

实现上述能力须要三项核心技能的保障。

第一项关键技能是查询下推。
查询下推的最大益处在于，它能最大化地利用用户现有的根本举动步伐。
例如，在用户已经支配了数据仓库及相应的 OLAP 引擎情形下，借助查询下推技能，就可以在逻辑数据平台中充分利用企业已有的这些算力。

第二项关键技能是自动化的 RP 创建与回收（RP - Relational Projection，一种将视图和物理 ETL 作业进行关联的工具）。
实际场景中，并非所有视图都须要创建 RP。
逻辑数据平台下面的虚拟化引擎，会自动（或者人工）为须要的视图创建 RP，在 RP 永劫光不被利用的时候还会进行资源回收。
这个技能相较于传统 ETL，能够在存储和打算资源上实现显著的本钱节约。

第三项关键技能是 RP 的命中率问题。
当实行 SQL 查询时，虚拟化引擎须要判断，查询语句的哪些部分能够复用这些已天生的 RP 数据。
这一过程由虚拟化引擎的查询改写自动完成，从而可以对用户的查询要求进行性能加速。

接下来会简要先容这些技能的细节。

1. 查询下推

谈及查询下推，虽然如 Presto、Spark 等跨源引擎已广泛采取，但是它们更多的还是作为 MPP 引擎来利用，因此他们一样平常只会进行很有限的查询下推。
然而在虚拟化引擎中，查询下推扮演着更为关键的角色。
虚拟化引擎的设计理念是，只要底层源系统具备足够的打算能力，它会最大化地进行查询的下推。
因此，虚拟化引擎与常规跨源查询 MPP 引擎不才推方面存在显著差异。

以一个实际例子解释，如果进行一个事实表和维度表的 join 操作，假设事实表存储在一个 Gauss 数据库中，而维度表位于一个 MySQL 数据库里。
如果事实表中有 2 亿条记录，而维度表有 100 条记录，那么当我们两个表 join 在一起并基于某个维度进行 AGG 操作时，如果利用 Spark 或其他传统跨源查询引擎，它们在 join 操作时须要将 Gauss 中的 2 亿条数据和 MySQL 中的 100 条数据全部拉取到打算引擎中进行关联，而这将导致巨大的数据传输本钱。

图 4：查询下推示例

然而，在逻辑虚拟化引擎中，我们可以看到，下推后，打算结果可能仅有 100 条记录。
当这 100 条记录被提取并与其他数据再次关联时，数据传输量从原始的 2 亿条减少到 100 条，大幅减轻了网络传输负载，以及在 join 层所须要的打算量。
在跨地理位置的场景中，尤其是那些网络传输时延较高的情形下，这种优化的效果尤为明显。

在我们的虚拟化引擎中，与传统的跨源查询引擎比较，查询下推的能力得到了显著增强。
这一增强紧张表示在几个方面：首先，虚拟化引擎能够根据不同数据源实例，配置完备不同的下推策略。
比如，对付一些承载业务操作的数据库，由于我们不肯望下推而对业务库造成过大压力，因此，我们可以为这些数据库配置较为守旧的下推策略。
而对付像 Gauss 这种本身就设计为处理大量繁芜数据的数据库集群，我们则可以采取更为激进的下推策略。

其次，在某些环境下，乃至全体查询都可能在数据源端完成。
除了这些常规下推能力外，我们的虚拟化引擎还实现了更多下推操作，比如聚合（AGG）下推、联合（Union）下推，包括跨源 join 裁剪等，这些每每都是传统的跨源查询引擎不具备的能力。

2. 智能 RP

图 5：自动 RP 创建与回收

自动 RP 创建事理

在 Aloudata AIR 逻辑数据平台的虚拟化引擎内部，引擎的输入紧张包括三部分：第一部分，前端业务系统提交的 SQL 查询要求；第二部分，用户在逻辑数据平台内定义的视图，以及这些视图的嵌套依赖关系；第三部分，某些视图创建的 RP，这些 RP 构建时也会天生构建时实行的 SQL 语句。
这三部分数据汇总到 AIR 的虚拟化引擎之后，引擎将实行两项紧张任务。
首先是查询的实行行为提取和 RP 命中识别，这包括提取查询算子和进行算子的模式组合判断，其次是基于这些查询模式组合，结合查询本身的行为特色进行刻画。
特色刻画又分为两个维度：一个是基于用户查询目标表维度，比如用户查询的是哪一张或哪几张表的凑集；其余一个是查询所需的数据维度，例如哪些频繁利用的数据范围会被包含在内。
基于这两个维度，AIR 的虚拟化引擎将天生相应的 RP 创建策略。
有了这些 RP 策略之后，策略实行引擎会自动创建背后的 RP，后续查询或构立功课就可以利用这些 RP 天生的物理数据，优先从这些预先打算好的数据返回查询结果，从而提升用户查询和构建的性能。

自动 RP 回收

我们引入了 RP 的无效回收机制，也便是说，当某些视图永劫光不被利用时，系统将根据配置的策略，逐渐回收这些视图背后的 RP 作业，以及 RP 在底层创建的物理表数据，从而根据用户的利用数据行为实现自动化的数据管理。

3. RP 查询命中改写

关于 RP 改写的部分，紧张先容当某个 RP 创建后，如何来加速用户的查询 SQL。

举个例子，假设我们有一个名为 Category Sales 的表，个中也包含一个名为 item 的维度表。
这是由事实表和维度表组成的一个比较范例的剖析场景。

图 6：RP 查询命中与改写示例

在我们的虚拟化引擎中，有一种基于事实表及对应的 item ID 进行轻粒度汇总的能力，我们可以在事实表上选择对应的维度关联键（哀求必须是主外键情形），创建一个聚合的归天视图（聚合 RP）。
如果，用户写一个查 SQL，这个查询须要关联发卖和 item 表，并基于 item 表的某个属性进行 group 时，该查询将被改写。
查询改写后，不是直接针对原始的两亿条记录与百万条记录进行 join 和 group by，而是先利用已经建立的聚合 RP 结果与 item 表进行 join 和 group by。
这种查询改写的紧张好处是，实际实行的查询将只针对经由轻粒度汇总后的结果（约百万条数据）进行 join 和 group by 操作。
这极大提升了用户实行 SQL 的查询性能。
如果剖析维度有所增加，例如不仅仅局限于 item 表的 catalog_id，还可能包括 item 表的其他字段，这样的查询也同样能够被优化的聚合 RP 命中并进行改写。

因此，在这类运用处景中，虽然市情上有一些工具或引擎可能会通过打 Cube 来实现类似效果，但打 Cube 过程须要对 item 表中所有字段预处理，代价相对较高。
与创建 Cube 比较，我们的虚拟化引擎供应了一种更为灵巧且本钱效率更高的办理方案。

目前，我们在 RP 改写方面取得了两项紧张进展。
首先，我们实现了常规归天视图中的 SPJG 的查询改写。
其次，我们结合智能 RP 策略，可以实现对任意嵌套层次的 VIEW 进行查询改写。
末了是各种轻粒度汇总的查询改写如前面举例的 Case。

前面提到的三项关键技能，是我们虚拟化引擎在技能层面所做的紧张技能创新，为企业履行数据虚拟化供应了底层的技能支撑，确保在数据虚拟化之后，仍旧可以得到比传统数仓更好的性能查询体验。

图 7：逻辑数据平台的 NoETL 之道

逻辑数据平台与传统数仓比较，展现出了显著上风：

生产模式改造

传统数据仓库采纳“预处理模式”，即在用户实际利用数据前，预先完成所有ETL 过程及物理数据表的构建事情。
而逻辑数据平台则借鉴了“按需生产”的理念，以业务数据需求为导向，优前辈行数据探查并制订逻辑取数规则，而非预前辈行物理数据加工。
系统依据用户对数据的实际运用处景和性能需求动态相应，仅在必要时，如碰着性能瓶颈时，才针对性地创建 RP 以实现物理数据的天生与优化。
相较于传统数仓“师长西席产后消费”的模式，更加灵巧高效。

数据集成能力提升

逻辑数据平台能够更大略单纯地实现全域数据资产的集成，战胜了传统数仓物理集成的寻衅，集成过程更为灵巧且全面。

数据加工自动化

在逻辑数据平台中，能够无缝实行传统数据仓库中的各种数据处理任务，包括构建常规视图与具备历史快照功能的视图，以及利用分层加工和资产管理等策略。
相较于传统模式，逻辑数据平台的一大改造在于自动化处理原来须要人工创建和管理的 ETL 任务及其发布、回收流程，从而极大地减轻了用户的后台运维包袱，提升了系统的智能化水平，并显著优化了整体数据处理效率。

数据消费便捷化

在数据消费层面，传统数据仓库常日需将数据迁移至独立的 OLAP 引擎以进行深度处理，但逻辑数据平台通过其内置的虚拟化引擎智能适配跑批与 OLAP 剖析查询功能，从而肃清了这一需求。
当 BI 工具或其他消费者访问逻辑数据时，无需关注查询应被导向哪个详细实行引擎，所有查询均统一通过逻辑数据平台的虚拟化引擎进行处理。
这一特性极大地减少了用户在数据消费过程中因对接不同引擎和数据导出所带来的额外本钱与繁芜性，提升了数据利用的便捷性和效率。

资产管理范围扩大

传统数仓局限于管理已同步的数据资产，而逻辑数据平台则能对企业的所有数据资产进行全面整合和管理，不受资产是否同步至仓库的限定。

根本举动步伐解耦升级便捷

逻辑数据平台实现了逻辑层与底层引擎的完备解耦，使得技能升级或引擎更换时，对上层业务的影响降到最低，确保业务连续性和稳定性。

03范例场景与案例

在第三部分，我们将简要先容逻辑数据平台在两个范例场景如何帮助客户办理特定问题。

第一种，针对中大型企业，特殊是那些拥有多元化数据存储资源（如数据仓库、数据湖以及分布于分子公司和稠浊多云平台的业务系统）的企业场景，我们供应的逻辑数据平台与虚拟化技能相结合的办理方案能够实现关键性打破。
此方案将企业的离散数据在逻辑层面高效整合，以极低的本钱沉淀全域数据资产并供应统一的数据做事。
这样不仅集中知足了所有数据消费场景的需求，还实现了统一的数据访问掌握机制，首创了一种全新的数据整合模式，充分展现了虚拟化技能的核心上风。

图 8：中大型机构的统一数据资产与做事平台

例如，在能源行业的某大型央企集团案例中，由于历史发展和技能迭代，企业内部形成了多套基于不同平台（如 SAPBW）构建的数据仓库，还有自己的数据湖，且包含多个数据库系统，导致数据分散，难以进行一体化剖析和利用，同时，原有的封闭式技能办理方案也限定了与其他外部系统的集成能力。

该集团下辖浩瀚分、子公司，集团层面希望能对这些公司的数据进行统一管理和运用。
为此，我们利用虚拟化引擎打造了一个覆盖全部数据源的逻辑数据平台，对集团的所有数据资产进行全面管理，并在此平台上供应统一的数据做事接口，成功实现了对各数据仓库、数据湖等根本举动步伐内数据资源的一体化管理和利用。

图 9：中大型机构案例

第二种范例场景聚焦于企业在构建数据仓库或数据中台时的选择困境。
逻辑数仓作为一种轻量级且高效的替代方案，为用户供应了快速支配的新路径。
在这一架构下，逻辑数据平台无缝对接多元数据源，使得用户能够直策应用平台进行数据开拓与资产管理，涵盖构建数据目录等做事，从而实现对企业整体数据资产的全面管控，并终极通过 BI 工具及 AI 运用消费数据。
这种办法不仅涵盖了传统数仓的所有功能，而且由于其逻辑化的处理办法，使全体过程更为灵巧和高效。

以某证券公司为例，该公司原操持采取如 Hadoop 等技能培植数仓，但在详细评估后创造此类办理方案涉及高昂的本钱投入，包括硬件购置本钱和 IT 职员本钱，且后续掩护事情量弘大。
为此，逻辑数仓成为他们更优的计策选择，兼顾了敏捷性和经济效益。

Aloudata 为该券商设计了一套逻辑化数据仓库办理方案，创新性地在数据明细层（DWD）直接履行物理 RP 创建，用于逐日快照存储历史累积数据，构建起数仓的根本架构。
在此根本上，上层的汇总层（DWS）和运用层（ADM）依据业务需求进行数据归天，有效降落了整体数仓链路的存储本钱。

这家证券公司的案例颇具代表性。
其拥有超过两万张数据表，但实际核心业务仅需利用个中一小部分来支持 100 多个关键指标的数据需求，充分表示了逻辑数仓的高效资源整合上风。
实践证明，这一方案显著提升了交付效率，相较于传统的定时开拓报告和资产门户办法，速率提升至少十倍以上。
同时，通过虚拟化技能，自动化作业程度提高，大幅减轻了研发管理的事情包袱。
此外，与传统数据仓库比较，逻辑数据平台极大地降落了存储本钱，由于其能灵巧调用两万多张表的数据，而在传统模式下同步这些数据的本钱极为高昂。

图 10：逻辑数仓场景案例效果

末了总结一下。
逻辑数据平台的核心代价表示在四大关键领域：

数据集成方面，该平台能够实现秒级的数据快速集成，显著提升了数据整合效率，为企业供应高效便捷的数据处理路子。
在全域资产管理上，凭借逻辑集成技能，平台不仅简化了大规模资产的管理流程，而且数据处理的稳定性与性能表现卓越，能适应各种规模数据的寻衅。
查询性能层面，逻辑数据平台具有突出上风，其加速后的查询速率比较 Presto 和 Spark 可提升 5 至 20 倍。
此外，平台还可兼容客户自有 OLAP 引擎，逻辑数据平台可将加速后的数据通过客户自有 OLAP 引擎来查询，从而可以最大程度避免客户在打算层的重复投资。
下推策略及归天命中引擎技能方面，平台创新改进下推策略配置，根据不同的措辞环境支持不同层级的策略设定，相较于传统方案实现了质的飞跃。
同时，自主研发的归天命中引擎增强了查询命中能力，确保用户在任何场景下都能获取同等的查询命中和查询下推能力，且不依赖底层详细某一 OLAP 或存储的特性。

综上所述，逻辑数据平台在数据集成、全域资产管理、查询性能优化以及下推策略增强等方面展现了卓越效能，为企业的数据管理和运用供应了高效稳定的整体办理方案。

看完这篇文章，您是否对海内首个 Data Fabric 逻辑数据平台 Aloudata AIR 产生了更多好奇，是否提出了新的疑问。
下方是在客户互换过程中涌现的高频问题，我们整理成 Q&A，考试测验为您解答。

04

Q&A

Q1：如果全部都是逻辑模型，相对付物理落表，如何担保性能和时效？数仓反应历史的功能如何担保？会不会给业务端数据库造成很大的压力？

A1：一样平常情形下不会给业务库造成很大的压力，在虚拟化引擎层可以配置源的下推策略（掌握什么类型的打算下推，什么类型的打算不下推），其余可以限定对底层引擎的查询并发掌握，防止查询并发过多导致底层引擎压力过大。

逻辑模型实质上也是会落物理表（通过 RP 创建实现），数据的失落效取决于 RP 构建的刷新频率（有两种刷新办法：上游有数仓的情形，RP 的刷新可以根据上游的刷新关照来实现数据的刷新；其余一种办法是定时自动刷新）。

数仓反应历史的功能可以通过参数化视图来实现。

Q2：传统 DW 会有好多层，逻辑数仓的观点便是 ods 层之后直接做视图，原来好几层的逻辑全都压缩在视图里，是这么理解么？

A2：不是，传统 DW 会有好多层，在逻辑数仓里面也可以构建很多层视图。

Q3：数据处理的压力是给到数据源了吗？不按照传统数仓的分层落盘，逻辑数仓怎么办理重复打算呢？

A3：数据处理的压力是按照用户的配置决定是否下推到源，不是所有场景都将数据处理的压力下推到源。
不按照传统数仓的分层落盘，逻辑数仓里面用户数据也可以分层开拓，然后去复用数据。

Q4：站在全局上看一定会减少本钱吗？

A4：剖析全体数仓的本钱须要从不同的维度来看：

从物理的存算本钱视角来看，第一、逻辑数仓在数据集成这层抛弃了传统数仓的数据集中存放办法，无需物理集成，产生了对 ODS 层的数据集成存储本钱节省。
第二、对付可下推场景，逻辑数仓做数据构建或者查询可以充分利用已有引擎的算力，让企业无需重复投资。
第三、在传统数仓里面，用户分层加工，很多场景实在并没有特殊清晰的规则去限定用户重复冗余加工数据，这就会导致大量类似重复冗余的表，在逻辑数仓里面，虚拟化引擎通过算子级的 RP 命中能力，能将用户写的大量逻辑类似视图命中同一个 RP，从而避免大量的数据存储和打算的摧残浪费蹂躏；末了，用户创建的多层视图，比如用户创建了 5 层视图依赖，实际上并不是每个视图都值得去创建物理 RP 做加速的，实际情形创建的 RP 数量<=5，从而也节省了干系存储本钱；

从整体的研发效率来看，第一、由于逻辑数仓具备逻辑化集成数据的能力，可以比传统数仓让用户更随意马虎去探查原始的数据（由于传统数仓数据如果没同步进来，数据就无法去探查），极大地提升了用数的效率；第二、用户在逻辑数仓里面不用关系逻辑视图的存算本钱，一旦视图变多了往后，对付那些不生动或者不用的视图，RP 作业的回收和优化由系统自动来完成，一旦作业回收了上层视图本身不占用用户额外的打算和存储，就可以极大节省传统数仓数据管理和干系重构的投入本钱。
第三、逻辑数仓可以自动完成查询路由到对应的 OLAP 引擎查询数据，因此数据无需导出即可消费数据，无需切换到其它引擎去利用数据。

Q5：公司已经有存量数仓，如何 Aloudata 运用到存量数仓上？须要将贴源模型全部录入到 Aloudata 里，其余，存量的 ETL 任务和任务也要录入，是否有工具可以一键录入？还是须要很多人力本钱，这些作业都要被算子血缘收录，是如何收录的？算子血缘的数据来源是从 Spark、Hive 的 EventLog 里获取的吗？

A5：公司已经有存量数仓的情形，可以通过 AIR 连接到用户的存量数仓，通过 AIR 去做跨源、跨地域或者是多数仓的数据领悟及查询。

Q6：逻辑数据平台个中一个特性是本钱低，问下在存量的数仓中数据湖（Iceberg、Hudi）和 Hive 的数据是相似的，该怎么节省相似存储的本钱？

A6：存量数仓或者数据湖里面的重复数据，只能通过数据管理来办理。

Q7：逻辑层最大的问题，便是 OLAP 查询效率比较低，想听听怎么办理。

A7：逻辑层底层有 RP 加速和集成 OLAP 查询引擎的能力，可以实现逻辑层的查询自动路由到高效的 OLAP 引擎上，从而实现快速和灵巧的查询剖析。

Q8：对付已经有存量数仓，也有各引擎（Spark、Hive、Presto、Flink），如果要运用逻辑数仓，那现有的引擎是否都不能用了，只能利用Aloudata 的数据虚拟化引擎？

A8：基于 AIR 搭建的逻辑数仓并不是要更换存量的数仓，逻辑数仓是基于传统存量数仓之上逻辑整合，整合客户已有的 hive、spark 和 Flink 引擎的数据，并对业务供应一个超过各种源的统一 SQL 访问层，让客户不用关注数据在哪里由哪个引擎产生，都可以去被消费和利用。

Q9：RP 命中率怎么保障？如果没有命中，直接查底层数据，会不会比传统数据仓库更慢？

A9：一个视图一旦创建了 RP，理论上 RP 只有手工禁用的场景下才会失落效，由于 RP 和归天视图不一样，会优先保障 RP 的命中，类似传统数仓的 ETL 加工过程，下贱消费上游的某张表数据，不会考虑上游任务昨天是否运行成功，所消费物理表的数据是否有脏数据，以是 RP 的查询命中也是遵照同样的逻辑。

Q10：虚拟数仓在开拓调试过程数据质量问题怎么办理？

A10：逻辑数据平台内置了部分根本的数据质量策略，例如值非空，值范围，是否唯一等等。
但像传统数仓那种繁芜的数据质量管控能力暂时还不会去培植，一旦公司有极其严格的数据质量管控的场景，数据加工建议还是通过传统数仓来实现。

Q11：预天生 RP 的数据，是否与根本数据或者数据更新等，存在时延导致的事务不一致的问题？

A11：预天生 RP 的数据跟传统数仓中 ETL 加工的数据类似，都有可能存在更新时延导致数据不一致的问题。
在虚拟化引擎里面可以通过设置数据可见性的策略来掌握是否保持所有 RP 的数据都更新成功了之后才让查询命中全体链路上的 RP 新数据，这个策略的坏处是数据可见的韶光依赖最长链路的 RP Ready 的韶光，会导致数据可用的韶光有较大延时，但好处是绝对担保不会看到不一致的数据。

其余一个策略是许可看到不一致的数据，这样一旦链路上的某个RP 数据更新成功，最新的数据即可被查询利用。

以上便是本次分享的内容，感激大家。