网站维护是不是很难做,怎么注册网站卖东西,为什么网站收录在百度突然没有了,私人定制网站建设一文为你介绍 Aloudata AIR 逻辑数据平台的技术原理与核心价值 本文主旨是介绍逻辑数据平台的技术原理与核心价值#xff0c;包含几个部分的内容#xff1a;
首先#xff0c;简要阐述逻辑数据平台出现的背景#xff1b;其次#xff0c;详细讲解逻辑数据平台的构建方法包含几个部分的内容
首先简要阐述逻辑数据平台出现的背景其次详细讲解逻辑数据平台的构建方法以及与之相关的技术问题。尽管大家可能已经听说过逻辑数据平台但实际上逻辑化后带来的技术挑战不容小觑特别是在跨源查询及查询性能方面。当企业将数仓虚拟化后保证其能够满足生产环境中的查询性能需求这是一个相当大的挑战。因此第二部分将特别强调这方面的内容第三部分我们将介绍一些典型的应用场景。 过去十年随着数字化的深入社会整体数据量有着近 10 倍的增长数据的形态也在从传统的结构化数据转变为越来越多的非结构化数据。与此同时数据来源和形态变得更加多样化包括云上云下数据、客户数据和各种公开数据同时企业内部各类信息系统的数量也在不断增长。
此外使用数据的人群也发生了变化。在传统数仓环境下处理数据的通常是 IT 专业人员。但随着数据规模的扩大和业务场景的演进越来越多的非技术人员也开始直接使用数据。这些变化给企业的数据技术侧带来了不少挑战。
传统数据仓库的一个显著特点是数据集中化管理。具体来说数据会被收集并存储在数据仓库中集中进行处理。数据经过加工后通常会被导出到 OLAP 引擎用于 BI 报告和各种分析。
可以将这种传统数据仓库类比为现实世界中的仓库但它们之间有一个根本区别现实中的仓库有物品进出以保持平衡而数据仓库则往往只有数据积累并随着业务增长数据量持续膨胀这也是从事数据开发的人员的共同感受。如果依旧采用传统的 ETL 处理方式来应对这种数据量增长将面临成本、规模和效率三者之间难以兼顾的困境。
从实际用户角度来看无论是业务人员还是数据开发者最理想的情况是无论数据存放于何处都能够便捷、迅速地使用这些数据然而现实往往不如人意。因此近年来逐渐流行起一个概念——Data Fabric。
Data Fabric 的核心理念认为将所有数据完全集中存储既不现实也不经济应该通过虚拟化和其他技术手段实现逻辑上的集中管理。这个理念承认了数据分散的现状提出用新的思路来解决问题并将其转化成行之有效的方法。 图 1Data Fabric 示意图
个人而言我认为 Data Fabric 与其说是一种技术的进步不如说是技术演化必然走向的一个妥协的结果。
Data Fabric 的核心技术是数据虚拟化。数据虚拟化主要由几个层次构成首先是底层的连接层。这一层的关键特点在于它能够把各种不同结构、来源、地域和存储介质的数据映射为一个统一的模型层为用户提供了一个数据交互的统一平面。这种通过连接层屏蔽差异性来实现数据虚拟化的做法为上层的各种数据整合奠定了基础。
有了这个基础之后我们就可以在其之上进行各种数据加工处理逻辑定义然后让终端消费者通过上层产品来使用这些数据。这便构成了数据虚拟化的典型架构。
在这个架构下我们面临的最大挑战正如我之前提到的是在查询虚拟化的数据时如何解决性能问题确保无论数据的规模有多大用户都能获得近似于在本地直接进行数据查询的性能和使用体验。 那么如何构建一个企业级的逻辑数据平台呢逻辑数据平台与传统数据仓库存在着哪些差异Aloudata 突破了哪些技术限制才实现了一个可靠、生产级的企业级逻辑数据平台下文将尝试回答上述问题。
逻辑数据平台的核心优势在于以下几点 首先由于它实施逻辑集成数据集成速度快减少了时间和人力成本。其次数据能够保持实时更新因为所有查询都是直接针对基础数据层进行从而可及时获取数据。再次总体成本较低因为它避免了大量源端数据重复存储和同步的成本。 此外逻辑数据平台支持异构数据源的统一接入提供了一个通用的 SQL 查询和分析能力。用户无需了解底层数据是否存储于 MySQL、HBase、Mongo、ES 或 GaussDB 等数据库就可像操作本地数据库一般方便地进行查询。基于逻辑集成可在这一层上构建一个跨公司所有数据资产的统一资产管理和数据目录功能。 最后得益于这种集中逻辑数据集成和整合的计算体系我们可为消费侧产品提供统一的数据访问服务、集中的权限和安全管控所有这些能力共同构成了我们逻辑数据平台的整体架构。 图 2逻辑数据平台优势
那么逻辑数据平台在执行数据集成和整合时工作原理是怎样的呢
这里我们有一个简化的模型图。对于有 ETL 经验的工程师而言应当不难理解在传统数据仓库中数据源采集进来后会构建贴源层的 ODS。在逻辑数据平台中同样存在一个类似的以虚拟表为基础的“贴源层”。
根据这一层虚拟表我们继续向上进行更深入的数据整合最终形成一个供外部使用的表这就是提供给用户使用的数据表例如客户的 360 全景视图或门店的 360 视图。
图 3逻辑数据平台工作原理
但逻辑数据平台与传统 ETL 开发方式存在着显著差异在传统数据仓库中所有表都是物理存储的并且需要相应的人工 ETL 作业来支持同时我们还需要管理它们的依赖性和作业调度等等。然而在虚拟化的逻辑数据平台中并不是所有表都需要建立物理 ETL 作业而是只要在关键节点生成 ETL 作业就可以满足用户对查询性能的要求。
第二点差异在于在逻辑数据平台上用户不必关注底下的物理 ETL 作业细节因为逻辑层的存在已经将这些细节封装起来了。用户所看到的只是对外的视图而至于这些视图后面是否建立了物理作业是否与其他视图复用了同一个作业这些都不再需要用户关心的。
实现上述能力需要三项核心技术的保障 A. 查询下推查询下推的最大益处在于它能最大化地利用用户现有的基础设施。例如若用户已经部署了数据仓库及相应的 OLAP 引擎情况下借助查询下推技术就可以在逻辑数据平台中充分利用企业已有的这些算力。 B. 自动化的 RP 创建与回收RPRelational Projection是一种将视图和物理 ETL 作业进行关联的对象。实际场景中并非所有视图都需要创建 RP。逻辑数据平台下面的虚拟化引擎会自动或人工为需要的视图创建 RP在 RP 长时间不被使用的时候还会进行资源回收。这个技术相较于传统 ETL能够在存储和计算资源上实现显著的成本节约。 C. 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 层所需要的计算量。在跨地理位置的场景中尤其是那些网络传输时延较高的情况下这种优化的效果尤为明显。
在 Aloudata AIR 虚拟化引擎中与传统的跨源查询引擎相比查询下推的能力得到了显著增强。这一增强主要体现在几个方面
首先虚拟化引擎能够根据不同数据源实例配置完全不同的下推策略。比如对于一些承载业务操作的数据库由于我们不希望下推而对业务库造成过大压力因此我们可以为这些数据库配置较为保守的下推策略。而对于像 Gauss 这种本身就设计为处理大量复杂数据的数据库集群我们则可以采用更为激进的下推策略。
其次在某些情形下甚至整个查询都可能在数据源端完成。除了这些常规下推能力外我们的虚拟化引擎还实现了更多下推操作比如聚合AGG下推、联合Union下推包括跨源 join 裁剪等这些都是传统的跨源查询引擎往往不具备的能力。
》智能 RP 图 5自动 RP 创建与回收
自动 RP 创建原理
在 Aloudata AIR 逻辑数据平台的虚拟化引擎内部引擎的输入主要包括三部分
前端业务系统提交的 SQL 查询请求
用户在逻辑数据平台内定义的视图以及这些视图的嵌套依赖关系
某些视图创建的 RP这些 RP 构建时也会生成构建时执行的 SQL 语句。
这三部分数据汇总到 Aloudata AIR 的虚拟化引擎之后引擎将执行两项主要任务。首先是查询的执行行为提取和 RP 命中识别这包括提取查询算子和进行算子的模式组合判断其次是基于这些查询模式组合结合查询本身的行为特征进行刻画。
特征刻画又分为两个维度一个是基于用户查询目标表维度如用户查询的是哪一张或哪几张表的集合另一个是查询所需的数据维度如哪些频繁使用的数据范围会被包含在内。
基于这两个维度AIR 的虚拟化引擎将生成相应的 RP 创建策略。有了这些 RP 策略之后策略执行引擎会自动创建背后的 RP后续查询或构建作业就可以利用这些 RP 生成的物理数据优先从这些预先计算好的数据返回查询结果从而提升用户查询和构建的性能。
自动 RP 回收
我们引入了 RP 的无效回收机制也就是说当某些视图长时间不被使用时系统将根据配置的策略逐渐回收这些视图背后的 RP 作业以及 RP 在底层创建的物理表数据从而根据用户的使用数据行为实现自动化的数据治理。
RP 查询命中改写
关于 RP 改写的部分主要介绍当某个 RP 创建后如何来加速用户的查询 SQL。举个例子假设我们有一个名为 Category Sales 的表其中也包含一个名为 item 的维度表。这是由事实表和维度表组成的一个比较典型的分析场景。 图 6RP 查询命中与改写示例
在 Aloudata AIR 虚拟化引擎中有一种基于事实表及对应的 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 相比Aloudata AIR 虚拟化引擎提供了一种更为灵活且成本效率更高的解决方案。
目前我们在 RP 改写方面取得了两项主要进展首先我们实现了常规物化视图中的 SPJG 的查询改写。其次我们结合智能 RP 策略可以实现对任意嵌套层次的 VIEW 进行查询改写。最后是各类轻粒度汇总的查询改写如前面举例的 Case。
前面提到的三项关键技术是我们虚拟化引擎在技术层面所做的主要技术创新为企业实施数据虚拟化提供了底层的技术支撑确保在数据虚拟化之后仍然可以获得比传统数仓更好的性能查询体验。 图 7逻辑数据平台的 NoETL 之道
逻辑数据平台与传统数仓相比展现出了显著优势
生产模式革新传统数据仓库采取“预处理模式”即在用户实际使用数据前预先完成所有 ETL 过程及物理数据表的构建工作。而逻辑数据平台则借鉴了“按需生产”的理念以业务数据需求为导向优先进行数据探查并制定逻辑取数规则而非预先进行物理数据加工。系统依据用户对数据的实际应用场景和性能需求动态响应仅在必要时如遇到性能瓶颈时才针对性地创建 RP 以实现物理数据的生成与优化。相较于传统数仓“先生产后消费”的模式更加灵活高效。
数据集成能力提升逻辑数据平台能够更简易地实现全域数据资产的集成克服了传统数仓物理集成的挑战集成过程更为灵活且全面。 数据加工自动化在逻辑数据平台中能无缝执行传统数据仓库中的各类数据处理任务包括构建常规视图与具备历史快照功能的视图以及运用分层加工和资产管理等策略。相较于传统模式逻辑数据平台的一大革新在于自动化处理原本需要人工创建和管理的 ETL 任务及其发布、回收流程从而极大地减轻了用户的后台运维负担提升了系统的智能化水平并显著优化了整体数据处理效率。 数据消费便捷化在数据消费层面传统数据仓库通常需将数据迁移至独立的 OLAP 引擎以进行深度处理但逻辑数据平台通过其内置的虚拟化引擎智能适配跑批与 OLAP 分析查询功能从而消除了这一需求。当 BI 工具或其他消费者访问逻辑数据时无需关注查询应被导向哪个具体执行引擎所有查询均统一通过逻辑数据平台的虚拟化引擎进行处理。这一特性极大地削减了用户在数据消费过程中因对接不同引擎和数据导出所带来的额外成本与复杂性提升了数据使用的便捷性和效率。 资产管理范围扩大传统数仓局限于管理已同步的数据资产而逻辑数据平台则能对企业的所有数据资产进行全面整合和管理不受资产是否同步至仓库的限制。 基础设施解耦升级便捷逻辑数据平台实现了逻辑层与底层引擎的完全解耦使得技术升级或引擎替换时对上层业务的影响降到最低确保业务连续性和稳定性。 在第三部分我们将简要介绍逻辑数据平台在两个典型场景如何帮助客户解决特定问题。
》典型场景一
第一种针对中大型企业特别是那些拥有多元化数据存储资源如数据仓库、数据湖以及分布于分子公司和混合多云平台的业务系统的企业场景我们提供的逻辑数据平台与虚拟化技术相结合的解决方案能够实现关键性突破。
此方案将企业的离散数据在逻辑层面高效整合以极低的成本沉淀全域数据资产并提供统一的数据服务。这样不仅集中满足了所有数据消费场景的需求还实现了统一的数据访问控制机制开创了一种全新的数据整合模式充分展现了虚拟化技术的核心优势。 图 8中大型机构的统一数据资产与服务平台
例如在能源行业的某大型央企集团案例中由于历史发展和技术迭代企业内部形成了多套基于不同平台如 SAP BW构建的数据仓库还有自己的数据湖且包含多个数据库系统导致数据分散难以进行一体化分析和利用同时原有的封闭式技术解决方案也限制了与其他外部系统的集成能力。
该集团下辖众多分、子公司集团层面希望能对这些公司的数据进行统一管理和应用。为此我们运用虚拟化引擎打造了一个覆盖全部数据源的逻辑数据平台对集团的所有数据资产进行全面管理并在此平台上提供统一的数据服务接口成功实现了对各数据仓库、数据湖等基础设施内数据资源的一体化管理和利用。 图 9中大型机构案例
》典型场景二
第二种典型场景聚焦于企业在构建数据仓库或数据中台时的选择困境。逻辑数仓作为一种轻量级且高效的替代方案为用户提供了快速部署的新路径。
在这一架构下逻辑数据平台无缝对接多元数据源使得用户能够直接利用平台进行数据开发与资产管理涵盖构建数据目录等服务从而实现对企业整体数据资产的全面管控并最终通过 BI 工具及 AI 应用消费数据。这种方式不仅涵盖了传统数仓的所有功能而且由于其逻辑化的处理方式使整个过程更为灵活和高效。
以某证券公司为例该公司原计划采用如 Hadoop 等技术建设数仓但在详细评估后发现此类解决方案涉及高昂的成本投入包括硬件购置成本和 IT 人员成本且后续维护工作量庞大。为此逻辑数仓成为他们更优的战略选择兼顾了敏捷性和经济效益。
Aloudata 为该券商设计了一套逻辑化数据仓库解决方案创新性地在数据明细层DWD直接实施物理 RP 创建用于每日快照存储历史累积数据构建起数仓的基础架构。在此基础上上层的汇总层DWS和应用层ADM依据业务需求进行数据物化有效降低了整体数仓链路的存储成本。
这家证券公司的案例颇具代表性。其拥有超过两万张数据表但实际核心业务仅需使用其中一小部分来支持 100 多个关键指标的数据需求充分体现了逻辑数仓的高效资源整合优势。
实践证明这一方案显著提升了交付效率相较于传统的定时开发报告和资产门户方式速度提升至少十倍以上。同时通过虚拟化技术自动化作业程度提高大幅减轻了研发管理的工作负担。此外与传统数据仓库相比逻辑数据平台极大地降低了存储成本因为其能灵活调用两万多张表的数据而在传统模式下同步这些数据的成本极为高昂。 图 10逻辑数仓场景案例效果
最后总结一下。逻辑数据平台核心价值体现在四大关键领域
01 数据集成方面该平台能够实现秒级的数据快速集成显著提升了数据整合效率为企业提供高效便捷的数据处理途径。
02 在全域资产管理上凭借逻辑集成技术平台不仅简化了大规模资产的管理流程而且数据处理的稳定性与性能表现卓越能适应各类规模数据的挑战。
03 查询性能层面逻辑数据平台具有突出优势其加速后的查询速度相比 Presto 和 Spark 可提升 5 至 20 倍。此外平台还可兼容客户自有 OLAP 引擎逻辑数据平台可将加速后的数据通过客户自有 OLAP 引擎来查询从而最大程度避免客户在计算层的重复投资。
04 下推策略及物化命中引擎技术方面平台创新改进下推策略配置根据不同的语言环境支持不同层级的策略设定相较于传统方案实现了质的飞跃。同时自主研发的物化命中引擎增强了查询命中能力确保用户在任何场景下都能获取一致的查询命中和查询下推能力且不依赖底层具体某一 OLAP 或存储的特性。
综上所述逻辑数据平台在数据集成、全域资产管理、查询性能优化以及下推策略增强等方面展现了卓越效能为企业的数据管理和应用提供了高效稳定的整体解决方案。
Aloudata AIR 快问快答
看完这篇文章你是否对国内首个 Data Fabric 逻辑数据平台 Aloudata AIR 产生了更多好奇是否提出了新的疑问。
下方是在客户交流过程中出现的高频问题我们整理为了 QA尝试为你解答。
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 数据更新成功最新的数据即可被查询使用。 如需了解 Aloudata 产品与 Data Fabric 最佳实践请联系我们。 观看视频了解 Aloudata AIR 更多功能。
