年互联网技术和大数据平台相关架构经验。

作为主架构师及核心研发主导并完成了

Alibaba

年互联网技术和大数据平台相关架构经验。

作为主架构师及核心研发主导并完成了

Alibaba

全球买全球卖交易系统的第一代架构设计。

曾任蚂蚁集团大数据研发平台技术负责人。

从零开始主导完成蚂蚁第一和第二代数据研发平台产品体系的建设涵盖数据集成、研发、运维、质量基线及资产平台等完整数据研发平台产品体系支撑蚂蚁数以千计的

ETL

研发工程师搭建蚂蚁面向金融行业的逻辑化智能数据研发平台有丰富的海量数据及智能化数仓落地实践经验。

本文主旨是介绍逻辑数据平台的技术原理与核心价值包含几个部分的内容首先简要阐述逻辑数据平台出现的背景其次详细讲解逻辑数据平台的构建方法以及与之相关的技术问题。

尽管大家可能已经听说过逻辑数据平台但实际上逻辑化后带来的技术挑战不容小觑特别是在跨源查询及查询性能方面。

当企业将数仓虚拟化后保证其能够满足生产环境中的查询性能需求这是一个相当大的挑战。

因此第二部分将特别强调这方面的内容。

第三部分我们将介绍一些典型的应用场景。

倍的增长数据的形态也在从传统的结构化数据转变为越来越多的非结构化数据。

与此同时数据来源和形态变得更加多样化包括云上云下数据、客户数据和各种公开数据同时企业内部各类信息系统的数量也在不断增长。

此外使用数据的人群也发生了变化。

在传统数仓环境下处理数据的通常是

专业人员。

但随着数据规模的扩大和业务场景的演进越来越多的非技术人员也开始直接使用数据。

这些变化给企业的数据技术侧带来了不少挑战。

传统数据仓库的一个显著特点是数据集中化管理。

具体来说数据会被收集并存储在数据仓库中集中进行处理。

数据经过加工后通常会被导出到

OLAP

报告和各种分析。

可以将这种传统数据仓库类比为现实世界中的仓库但它们之间有一个根本区别现实中的仓库有物品进出以保持平衡而数据仓库则往往只有数据积累并随着业务增长数据量持续膨胀这也是从事数据开发的人员的共同感受。

如果依旧采用传统的

ETL

处理方式来应对这种数据量增长将面临成本、规模和效率三者之间难以兼顾的困境。

从实际用户角度来看无论是业务人员还是数据开发者最理想的情况是无论数据存放于何处都能够便捷、迅速地使用这些数据然而现实往往不如人意。

因此近年来逐渐流行起一个概念——Data

Fabric

的核心理念认为将所有数据完全集中存储既不现实也不经济应该通过虚拟化和其他技术手段实现逻辑上的集中管理。

这个理念承认了数据分散的现状提出用新的思路来解决问题并将其转化成行之有效的方法。

1Data

与其说是一种技术的进步不如说是技术演化必然走向的一个妥协的结果。

Data

Fabric

的核心技术是数据虚拟化。

数据虚拟化主要由几个层次构成首先是底层的连接层。

这一层的关键特点在于它能够把各种不同结构、来源、地域和存储介质的数据映射为一个统一的模型层为用户提供了一个数据交互的统一平面。

这种通过连接层屏蔽差异性来实现数据虚拟化的做法为上层的各种数据整合奠定了基础。

有了这个基础之后我们就可以在其之上进行各种数据加工处理逻辑定义然后让终端消费者通过上层产品来使用这些数据。

这便构成了数据虚拟化的典型架构。

在这个架构下我们面临的最大挑战正如我之前提到的是在查询虚拟化的数据时如何解决性能问题确保无论数据的规模有多大用户都能获得近似于在本地直接进行数据查询的性能和使用体验。

那么如何构建一个企业级的逻辑数据平台呢逻辑数据平台与传统数据仓库存在着哪些差异Aloudata

突破了哪些技术限制才实现了一个可靠、生产级的企业级逻辑数据平台本文将尝试回答上述问题。

逻辑数据平台的核心优势在于以下几点首先由于它实施逻辑集成数据集成速度快减少了时间和人力成本。

其次数据能够保持实时更新因为所有查询都是直接针对基础数据层进行从而可及时获取数据。

再次总体成本较低因为它避免了大量源端数据重复存储和同步的成本。

SQL

等数据库就可以像操作本地数据库一般方便地进行查询。

基于逻辑集成可以在这一层上构建一个跨公司所有数据资产的统一资产管理和数据目录功能。

最后得益于这种集中逻辑数据集成和整合的计算体系我们可以为消费侧产品提供统一的数据访问服务、集中的权限和安全管控所有这些能力共同构成了我们逻辑数据平台的整体架构。

2逻辑数据平台优势

那么逻辑数据平台在执行数据集成和整合时它的工作原理是怎样的呢这里我们有一个简化的模型图。

对于有

ETL

经验的工程师而言应当不难理解在传统数据仓库中数据源采集进来后会构建贴源层的

ODS。

在逻辑数据平台中同样存在一个类似的以虚拟表为基础的“贴源层”

根据这一层虚拟表我们继续向上进行更深入的数据整合最终形成一个供外部使用的表这就是提供给用户使用的数据表例如客户的

360

开发方式存在着显著差异在传统数据仓库中所有表都是物理存储的并且需要相应的人工

ETL

作业来支持同时我们还需要管理它们的依赖性和作业调度等等。

然而在虚拟化的逻辑数据平台中并不是所有表都需要建立物理

ETL

作业细节因为逻辑层的存在已经将这些细节封装起来了。

用户所看到的只是对外的视图而至于这些视图后面是否建立了物理作业是否与其他视图复用了同一个作业这些都不再需要用户关心的。

第一项关键技术是查询下推。

查询下推的最大益处在于它能最大化地利用用户现有的基础设施。

例如若用户已经部署了数据仓库及相应的

OLAP

引擎情况下借助查询下推技术就可以在逻辑数据平台中充分利用企业已有的这些算力。

创建与回收RP

RP。

逻辑数据平台下面的虚拟化引擎会自动或者人工为需要的视图创建

RP在

查询时虚拟化引擎需要判断查询语句的哪些部分能够复用这些已生成的

数据。

这一过程由虚拟化引擎的查询改写自动完成从而可以对用户的查询请求进行性能加速。

查询下推

引擎来使用因此他们一般只会进行很有限的查询下推。

但在虚拟化引擎中查询下推扮演着更为关键的角色。

虚拟化引擎的设计理念是只要底层源系统具备足够的计算能力它会最大化地进行查询的下推。

因此虚拟化引擎与常规跨源查询

MPP

条数据全部拉取到计算引擎中进行关联而这将导致巨大的数据传输成本。

4查询下推示例

层所需要的计算量。

在跨地理位置的场景中尤其是那些网络传输时延较高的情况下这种优化的效果尤为明显。

在我们的虚拟化引擎中与传统的跨源查询引擎相比查询下推的能力得到了显著增强。

这一增强主要体现在几个方面首先虚拟化引擎能够根据不同数据源实例配置完全不同的下推策略。

比如对于一些承载业务操作的数据库由于我们不希望下推而对业务库造成过大压力因此我们可以为这些数据库配置较为保守的下推策略。

而对于像

Gauss

这种本身就设计为处理大量复杂数据的数据库集群我们则可以采用更为激进的下推策略。

其次在某些情形下甚至整个查询都可能在数据源端完成。

除了这些常规下推能力外我们的虚拟化引擎还实现了更多下推操作比如聚合AGG下推、联合Union下推包括跨源

join

逻辑数据平台的虚拟化引擎内部引擎的输入主要包括三部分一部分前端业务系统提交的

SQL

查询请求第二部分用户在逻辑数据平台内定义的视图以及这些视图的嵌套依赖关系第三部分某些视图创建的

RP这些

的虚拟化引擎之后引擎将执行两项主要任务。

首先是查询的执行行为提取和

命中识别这包括提取查询算子和进行算子的模式组合判断其次是基于这些查询模式组合结合查询本身的行为特征进行刻画。

特征刻画又分为两个维度一个是基于用户查询目标表维度比如用户查询的是哪一张或哪几张表的集合另外一个是查询所需的数据维度例如哪些频繁使用的数据范围会被包含在内。

基于这两个维度AIR

生成的物理数据优先从这些预先计算好的数据返回查询结果从而提升用户查询和构建的性能。

的无效回收机制也就是说当某些视图长时间不被使用时系统将根据配置的策略逐渐回收这些视图背后的

在底层创建的物理表数据从而根据用户的使用数据行为实现自动化的数据治理。

查询命中改写

进行轻粒度汇总的能力我们可以在事实表上选择对应的维度关联键要求必须是主外键情况创建一个聚合的物化视图聚合

用户写一个查

时该查询将被改写。

查询改写后不是直接针对原始的两亿条记录与百万条记录进行

join

这种查询改写的主要好处是实际执行的查询将只针对经过轻粒度汇总后的结果约百万条数据进行

join

相比我们的虚拟化引擎提供了一种****更为灵活且成本效率更高的解决方案。

目前我们在

前面提到的三项关键技术是我们虚拟化引擎在技术层面所做的主要技术创新为企业实施数据虚拟化提供了底层的技术支撑确保在数据虚拟化之后仍然可以获得比传统数仓更好的性能查询体验。

NoETL

传统数据仓库采取“预处理模式”即在用户实际使用数据前预先完成所有

ETL

过程及物理数据表的构建工作。

而逻辑数据平台则借鉴了“按需生产”的理念以业务数据需求为导向优先进行数据探查并制定逻辑取数规则而非预先进行物理数据加工。

系统依据用户对数据的实际应用场景和性能需求动态响应仅在必要时如遇到性能瓶颈时才针对性地创建

以实现物理数据的生成与优化。

相较于传统数仓“先生产后消费”的模式更加灵活高效。

2、数据集成能力提升

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

3、数据加工自动化

在逻辑数据平台中能够无缝执行传统数据仓库中的各类数据处理任务包括构建常规视图与具备历史快照功能的视图以及运用分层加工和资产管理等策略。

相较于传统模式逻辑数据平台的一大革新在于自动化处理原本需要人工创建和管理的

ETL

任务及其发布、回收流程从而极大地减轻了用户的后台运维负担提升了系统的智能化水平并显著优化了整体数据处理效率。

4、数据消费便捷化

引擎以进行深度处理但逻辑数据平台通过其内置的虚拟化引擎智能适配跑批与

OLAP

工具或其他消费者访问逻辑数据时无需关注查询应被导向哪个具体执行引擎所有查询均统一通过逻辑数据平台的虚拟化引擎进行处理。

这一特性极大地削减了用户在数据消费过程中因对接不同引擎和数据导出所带来的额外成本与复杂性提升了数据使用的便捷性和效率。

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

6、基础设施解耦升级便捷

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

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

第一种

针对中大型企业特别是那些拥有多元化数据存储资源如数据仓库、数据湖以及分布于分子公司和混合多云平台的业务系统的企业场景我们提供的逻辑数据平台与虚拟化技术相结合的解决方案能够实现关键性突破。

此方案将企业的离散数据在逻辑层面高效整合以极低的成本沉淀全域数据资产并提供统一的数据服务。

这样不仅集中满足了所有数据消费场景的需求还实现了统一的数据访问控制机制开创了一种全新的数据整合模式充分展现了虚拟化技术的核心优势。

例如在能源行业

的某大型央企集团案例中由于历史发展和技术迭代企业内部形成了多套基于不同平台如SAP

BW构建的数据仓库还有自己的数据湖且包含多个数据库系统导致数据分散难以进行一体化分析和利用同时原有的封闭式技术解决方案也限制了与其他外部系统的集成能力。

该集团下辖众多分、子公司集团层面希望能对这些公司的数据进行统一管理和应用。

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

9中大型机构案例

第二种典型场景聚焦于企业在构建数据仓库或数据中台时的选择困境。

逻辑数仓作为一种轻量级且高效的替代方案为用户提供了快速部署的新路径。

在这一架构下逻辑数据平台无缝对接多元数据源使得用户能够直接利用平台进行数据开发与资产管理涵盖构建数据目录等服务从而实现对企业整体数据资产的全面管控并最终通过

工具及

应用消费数据。

这种方式不仅涵盖了传统数仓的所有功能而且由于其逻辑化的处理方式使整个过程更为灵活和高效。

Hadoop

等技术建设数仓但在详细评估后发现此类解决方案涉及高昂的成本投入包括硬件购置成本和

人员成本且后续维护工作量庞大。

为此逻辑数仓成为他们更优的战略选择兼顾了敏捷性和经济效益。

Aloudata

为该券商设计了一套逻辑化数据仓库解决方案创新性地在数据明细层DWD直接实施物理

创建用于每日快照存储历史累积数据构建起数仓的基础架构。

在此基础上上层的汇总层DWS和应用层ADM依据业务需求进行数据物化有效降低了整体数仓链路的存储成本。

这家证券公司的案例颇具代表性。

其拥有超过两万张数据表但实际核心业务仅需使用其中一小部分来支持

100

多个关键指标的数据需求充分体现了逻辑数仓的高效资源整合优势。

实践证明这一方案显著提升了交付效率相较于传统的定时开发报告和资产门户方式速度提升至少十倍以上。

同时通过虚拟化技术自动化作业程度提高大幅减轻了研发管理的工作负担。

此外与传统数据仓库相比逻辑数据平台极大地降低了存储成本因为其能灵活调用两万多张表的数据而在传统模式下同步这些数据的成本极为高昂。

10逻辑数仓场景案例效果

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

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

3、查询性能层面逻辑数据平台具有突出优势其加速后的查询速度相比

Presto

4、下推策略及物化命中引擎技术方面平台创新改进下推策略配置根据不同的语言环境支持不同层级的策略设定相较于传统方案实现了质的飞跃。

同时自主研发的物化命中引擎增强了查询命中能力确保用户在任何场景下都能获取一致的查询命中和查询下推能力且不依赖底层具体某一

OLAP

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

Data

产生了更多好奇是否提出了新的疑问。

下方是在客户交流过程中出现的高频问题我们整理为了

QA尝试为您解答。

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

一般情况下不会给业务库造成很大的压力在虚拟化引擎层可以配置源的下推策略控制什么类型的计算下推什么类型的计算不下推另外可以限制对底层引擎的查询并发控制防止查询并发过多导致底层引擎压力过大。

逻辑模型本质上也是会落物理表通过RP创建实现数据的失效取决于

的刷新可以根据上游的刷新通知来实现数据的刷新另外一种也可以定时的方式来自动刷新。

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

2、传统

层之后就直接做视图原本好几层的逻辑全都压缩在视图里是这么理解么

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

数据处理的压力是按照用户的配置决定是否下推到源不是所有场景都将数据处理的压力下推到源。

不按照传统数仓的分层落盘逻辑数仓里面用户数据也可以分层开发然后去复用数据。

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

要分析整个数仓的成本需要从不同的维度来看。

从物理的存算成本视角来看第一、逻辑数仓在数据集成这层抛弃了传统数仓的数据集中存放方式无需物理集成产生了对

ODS

层的数据集成存储成本节省。

第二、对于可下推场景逻辑数仓做数据构建或者查询可以充分利用已有引擎的算力让企业无需重复投资。

第三、在传统数仓里面用户分层加工很多场景其实并没有特别清晰的规则去限制用户重复冗余加工数据这就会导致大量类似重复冗余的表在逻辑数仓里面虚拟化引擎通过算子级的

RP从而避免大量的数据存储和计算的浪费另外用户创建的多层视图比如用户创建了

层视图依赖实际上并不是每个视图都值得去创建物理RP做加速的实际情况创建的

数量5从而也节省了相关存储成本从整体的研发效率来看第一、由于逻辑数仓具备逻辑化集成数据的能力可以比传统数仓让用户更容易去探查原始的数据因为传统数仓数据如果没同步进来数据就无法去探查极大的提升了用数的效率第二、用户在逻辑数仓里面不用关系逻辑视图的存算成本一旦视图变多了以后对于哪些不活跃或者不用的视图RP

作业的回收和优化由系统自动来完成一旦作业回收了上层视图本身不占用用户额外的计算和存储从而可以极大节省传统数仓数据治理和相关重构的投入成本。

第三、逻辑数仓可以自动完成查询路由到对应的

OLAP

引擎查询数据因此数据无需导出即可消费数据无需切换到其它引擎去使用数据。

5、公司已经有存量数仓如何

任务和任务也要录入吧是有工具可以一键录入吗还是需要很多人力成本这些作业都要被算子血缘收录吧是如何收录的算子血缘的数据来源是从

Spark、Hive

连接到用户的存量数仓通过AIR去做跨源、跨地域或者是多数仓的数据融合及查询。

6、逻辑数据平台其中一个特性是成本低问下在存量的数仓中数据湖Iceberg、Hudi和

Hive

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

AIR

搭建的逻辑数仓并不是要替换存量的数仓逻辑数仓是基于传统存量数仓之上逻辑整合整合客户已有的

hive、spark

访问层让客户不用关注数据在哪里由哪个引擎产生都可以去被消费和使用。

9、RP

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

RP如果理论上

加工过程下游消费上游的某张表数据不会考虑上游任务昨天是否运行成功所消费物理表的数据是否有脏数据。

所以

逻辑数据平台内置了部分基础的数据质量策略例如值非空值范围是否唯一等等。

但像传统数仓那种复杂的数据质量管控能力暂时还不会去建设一旦公司有极其严格的数据质量管控的场景数据加工建议还是通过传统数仓来实现。

11、

的数据是否与基础数据或者数据更新等存在时延导致的事务不一致的问题

预生成

加工的数据类似都有可能存在更新时延导致数据不一致的问题。

在虚拟化引擎里面可以通过设置数据可见性的策略来控制是否保持所有

Ready

的时间会导致数据可用的时间会有较大延时但好处是绝对保证不会看到不一致的数据。

另外一个策略是允许看到不一致的数据这样一旦链路上的某个