作者简介： 余俊，Aloudata 合伙人 & 技术副总裁。拥有 18 年互联网技术和大数据平台相关架构经验。作为主架构师及核心研发主导并完成了 Alibaba B2B 首个海量分布式 KV 存储系统，作为网站架构师负责 Aliexpress 全球买全球卖交易系统的第一代架构设计。曾任蚂蚁集团大数据研发平台技术负责人。从零开始主导完成蚂蚁第一和第二代数据研发平台产品体系的建设，涵盖数据集成、研发、运维、质量基线及资产平台等完整数据研发平台产品体系，支撑蚂蚁数以千计的 ETL 研发工程师，搭建蚂蚁面向金融行业的逻辑化智能数据研发平台，有丰富的海量数据及智能化数仓落地实践经验。

本文主旨是介绍逻辑数据平台的技术原理与核心价值，包含几个部分的内容：首先，简要阐述逻辑数据平台出现的背景；其次，详细讲解逻辑数据平台的构建方法，以及与之相关的技术问题。尽管大家可能已经听说过逻辑数据平台，但实际上逻辑化后带来的技术挑战不容小觑，特别是在跨源查询及查询性能方面。当企业将数仓虚拟化后，保证其能够满足生产环境中的查询性能需求，这是一个相当大的挑战。因此，第二部分将特别强调这方面的内容。第三部分，我们将介绍一些典型的应用场景。

过去十年，随着数字化的深入，社会整体数据量有着近 10 倍的增长，数据的形态也在从传统的结构化数据转变为越来越多的非结构化数据。与此同时，数据来源和形态变得更加多样化，包括云上云下数据、客户数据和各种公开数据，同时企业内部各类信息系统的数量也在不断增长。此外，使用数据的人群也发生了变化。在传统数仓环境下，处理数据的通常是 IT 专业人员。但随着数据规模的扩大和业务场景的演进，越来越多的非技术人员也开始直接使用数据。这些变化给企业的数据技术侧带来了不少挑战。传统数据仓库的一个显著特点是数据集中化管理。具体来说，数据会被收集并存储在数据仓库中，集中进行处理。数据经过加工后，通常会被导出到 OLAP 引擎，用于 BI 报告和各种分析。可以将这种传统数据仓库类比为现实世界中的仓库，但它们之间有一个根本区别：现实中的仓库有物品进出以保持平衡，而数据仓库则往往只有数据积累，并随着业务增长，数据量持续膨胀，这也是从事数据开发的人员的共同感受。如果依旧采用传统的 ETL 处理方式来应对这种数据量增长，将面临成本、规模和效率三者之间难以兼顾的困境。从实际用户角度来看，无论是业务人员还是数据开发者，最理想的情况是无论数据存放于何处，都能够便捷、迅速地使用这些数据，然而现实往往不如人意。因此近年来逐渐流行起一个概念——Data Fabric。Data Fabric 的核心理念认为，将所有数据完全集中存储既不现实也不经济，应该通过虚拟化和其他技术手段实现逻辑上的集中管理。这个理念承认了数据分散的现状，提出用新的思路来解决问题，并将其转化成行之有效的方法。 图 1：Data Fabric 示意图

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

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

那么如何构建一个企业级的逻辑数据平台呢？逻辑数据平台与传统数据仓库存在着哪些差异？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 数据。这一过程由虚拟化引擎的查询改写自动完成，从而可以对用户的查询请求进行性能加速。

接下来会简要介绍这些技术的细节。

• 查询下推

谈及查询下推，虽然如 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 裁剪等，这些都是传统的跨源查询引擎往往不具备的能力。

• 智能 RP

图 5：自动 RP 创建与回收

- 自动 RP 创建原理

在 Aloudata AIR 逻辑数据平台的虚拟化引擎内部，引擎的输入主要包括三部分：一部分，前端业务系统提交的 SQL 查询请求；第二部分，用户在逻辑数据平台内定义的视图，以及这些视图的嵌套依赖关系；第三部分，某些视图创建的 RP，这些 RP 构建时也会生成构建时执行的 SQL 语句。

这三部分数据汇总到 AIR 的虚拟化引擎之后，引擎将执行两项主要任务。首先是查询的执行行为提取和 RP 命中识别，这包括提取查询算子和进行算子的模式组合判断，其次是基于这些查询模式组合，结合查询本身的行为特征进行刻画。

特征刻画又分为两个维度：一个是基于用户查询目标表维度，比如用户查询的是哪一张或哪几张表的集合；另外一个是查询所需的数据维度，例如哪些频繁使用的数据范围会被包含在内。基于这两个维度，AIR 的虚拟化引擎将生成相应的 RP 创建策略。有了这些 RP 策略之后，策略执行引擎会自动创建背后的 RP，后续查询或构建作业就可以利用这些 RP 生成的物理数据，优先从这些预先计算好的数据返回查询结果，从而提升用户查询和构建的性能。

- 自动 RP 回收

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

• 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 之道

逻辑数据平台与传统数仓相比，展现出了显著优势：

1、生产模式革新： 传统数据仓库采取“预处理模式”，即在用户实际使用数据前，预先完成所有 ETL 过程及物理数据表的构建工作。而逻辑数据平台则借鉴了“按需生产”的理念，以业务数据需求为导向，优先进行数据探查并制定逻辑取数规则，而非预先进行物理数据加工。系统依据用户对数据的实际应用场景和性能需求动态响应，仅在必要时，如遇到性能瓶颈时，才针对性地创建 RP 以实现物理数据的生成与优化。相较于传统数仓“先生产后消费”的模式，更加灵活高效。

2、数据集成能力提升 ： 逻辑数据平台能够更简易地实现全域数据资产的集成，克服了传统数仓物理集成的挑战，集成过程更为灵活且全面。

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

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

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

6、基础设施解耦升级便捷： 逻辑数据平台实现了逻辑层与底层引擎的完全解耦，使得技术升级或引擎替换时，对上层业务的影响降到最低，确保业务连续性和稳定性。

在第三部分，我们将简要介绍逻辑数据平台在两个典型场景如何帮助客户解决特定问题。

第一种， 针对中大型企业，特别是那些拥有多元化数据存储资源（如数据仓库、数据湖以及分布于分子公司和混合多云平台的业务系统）的企业场景，我们提供的逻辑数据平台与虚拟化技术相结合的解决方案能够实现关键性突破。此方案将企业的离散数据在逻辑层面高效整合，以极低的成本沉淀全域数据资产并提供统一的数据服务。这样不仅集中满足了所有数据消费场景的需求，还实现了统一的数据访问控制机制，开创了一种全新的数据整合模式，充分展现了虚拟化技术的核心优势。

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

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

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

图 9：中大型机构案例

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

以某证券公司为例，该公司原计划采用如 Hadoop 等技术建设数仓，但在详细评估后发现此类解决方案涉及高昂的成本投入，包括硬件购置成本和 IT 人员成本，且后续维护工作量庞大。为此，逻辑数仓成为他们更优的战略选择，兼顾了敏捷性和经济效益。

Aloudata 为该券商设计了一套逻辑化数据仓库解决方案，创新性地在数据明细层（DWD）直接实施物理 RP 创建，用于每日快照存储历史累积数据，构建起数仓的基础架构。在此基础上，上层的汇总层（DWS）和应用层（ADM）依据业务需求进行数据物化，有效降低了整体数仓链路的存储成本。

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

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

最后总结一下。逻辑数据平台的核心价值体现在四大关键领域：

1、数据集成方面，该平台能够实现秒级的数据快速集成，显著提升了数据整合效率，为企业提供高效便捷的数据处理途径。

2、在全域资产管理上，凭借逻辑集成技术，平台不仅简化了大规模资产的管理流程，而且数据处理的稳定性与性能表现卓越，能适应各类规模数据的挑战。

3、查询性能层面，逻辑数据平台具有突出优势，其加速后的查询速度相比 Presto 和 Spark 可提升 5 至 20 倍。此外，平台还可兼容客户自有 OLAP 引擎，逻辑数据平台可将加速后的数据通过客户自有 OLAP 引擎来查询，从而可以最大程度避免客户在计算层的重复投资。

4、下推策略及物化命中引擎技术方面，平台创新改进下推策略配置，根据不同的语言环境支持不同层级的策略设定，相较于传统方案实现了质的飞跃。同时，自主研发的物化命中引擎增强了查询命中能力，确保用户在任何场景下都能获取一致的查询命中和查询下推能力，且不依赖底层具体某一 OLAP 或存储的特性。

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

---

看完这篇文章，您是否对国内首个 Data Fabric 逻辑数据平台 Aloudata AIR 产生了更多好奇，是否提出了新的疑问。下方是在客户交流过程中出现的高频问题，我们整理为了 Q&A，尝试为您解答。1、如果全部是逻辑模型，相对于物理落表，如何保证性能和时效？数仓反应历史的功能如何保证？会不会给业务端数据库造成很大的压力？

• 一般情况下不会给业务库造成很大的压力，在虚拟化引擎层可以配置源的下推策略（控制什么类型的计算下推，什么类型的计算不下推），另外可以限制对底层引擎的查询并发控制，防止查询并发过多导致底层引擎压力过大。
• 逻辑模型本质上也是会落物理表（通过RP创建实现），数据的失效取决于 RP 构建的刷新频率（有两种刷新方式：上游有数仓的情况，RP 的刷新可以根据上游的刷新通知来实现数据的刷新；另外一种也可以定时的方式来自动刷新；）。
• 数仓反应历史的功能可以通过参数化视图来实现。

2、传统 DW 会有好多层，逻辑数仓的概念就是 ods 层之后就直接做视图，原本好几层的逻辑全都压缩在视图里，是这么理解么？

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

3、数据处理的压力是给到数据源了吗？如不按照传统数仓的分层落盘，逻辑数仓怎么解决重复计算呢？

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

4、站在全局上看一定会减少成本吗？

• 要分析整个数仓的成本需要从不同的维度来看。
• 从物理的存算成本视角来看，第一、逻辑数仓在数据集成这层抛弃了传统数仓的数据集中存放方式，无需物理集成，产生了对 ODS 层的数据集成存储成本节省。第二、对于可下推场景，逻辑数仓做数据构建或者查询可以充分利用已有引擎的算力，让企业无需重复投资。第三、在传统数仓里面，用户分层加工，很多场景其实并没有特别清晰的规则去限制用户重复冗余加工数据，这就会导致大量类似重复冗余的表，在逻辑数仓里面，虚拟化引擎通过算子级的 RP 命中能力，能将用户写的大量逻辑类似视图命中同一个 RP，从而避免大量的数据存储和计算的浪费；另外，用户创建的多层视图，比如用户创建了 5 层视图依赖，实际上并不是每个视图都值得去创建物理RP做加速的，实际情况创建的 RP 数量<=5，从而也节省了相关存储成本；
• 从整体的研发效率来看，第一、由于逻辑数仓具备逻辑化集成数据的能力，可以比传统数仓让用户更容易去探查原始的数据（因为传统数仓数据如果没同步进来，数据就无法去探查），极大的提升了用数的效率；第二、用户在逻辑数仓里面不用关系逻辑视图的存算成本，一旦视图变多了以后，对于哪些不活跃或者不用的视图，RP 作业的回收和优化由系统自动来完成，一旦作业回收了上层视图本身不占用用户额外的计算和存储，从而可以极大节省传统数仓数据治理和相关重构的投入成本。第三、逻辑数仓可以自动完成查询路由到对应的 OLAP 引擎查询数据，因此数据无需导出即可消费数据，无需切换到其它引擎去使用数据。

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

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

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

• 通过数据治理来解决。

7、 逻辑层最大的问题，就是 OLAP 查询效率比较低，想听听怎么解决？

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

8、对于已经有存量数仓，也有各引擎（Spark、Hive、Presto、Flink），如果要应用逻辑数仓，那现有的引擎都不能用了，只能使用Aloudata 的数据虚拟化引擎？

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

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

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

10、虚拟数仓在开发调试过程数据质量问题怎么解决？

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

11、 预生成 RP 的数据，是否与基础数据或者数据更新等，存在时延导致的事务不一致的问题？

• 预生成 RP 的数据跟传统数仓中 ETL 加工的数据类似，都有可能存在更新时延导致数据不一致的问题。在虚拟化引擎里面可以通过设置数据可见性的策略来控制是否保持所有 RP 的数据都更新成功了之后才让查询命中整个链路上的 RP 新数据，这个策略的坏处是数据可见的时间依赖最长链路的 RP Ready 的时间，会导致数据可用的时间会有较大延时，但好处是绝对保证不会看到不一致的数据。
• 另外一个策略是允许看到不一致的数据，这样一旦链路上的某个 RP 数据更新成功，最新的数据即可被查询使用。