主动元数据平台详解(上):算子级血缘,创新数据管理新范式

2024-06-13 21:52

本文主要是介绍主动元数据平台详解(上):算子级血缘,创新数据管理新范式,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

01、数据血缘成为数据管理的“关键基建”

随着企业从传统的数字化管理迈向更为先进的数智化运营,数据已成为企业决策和运营的核心驱动力。在这个过程中,找数、用数已经成为企业实现精细化运营、智能化决策的重要环节。因此,实现更高效、全面、精准地管理数据,确保数据的完整性、可用性和准确性,对于推动企业数智化运营、提升整体业务效率、提升商业竞争力具有至关重要的意义。

然而,数据规模快速增长、数据资产日益增多、加工链路愈发复杂,导致企业数据管理面临前所未有的压力。这些压力包括复杂数据链路难以梳理、上下游数据变化难以高效同步、数据口径难以理解等,给企业数智化运营的推进构成了严重阻碍。

  • 数据链路的高效盘点与理解:数据链路层级不断增长,数据交叉依赖日益加深,导致数据加工链路变得如蛛网般错综复杂,使得数据盘点和加工逻辑的理解越来越难。对于用数人员而言,需要解析字段的上游加工逻辑或追溯、梳理字段来源时,不得不投入大量人力进行链路盘点。然而,这种依赖人工的盘点方式不仅效率低下,而且难以保证数据口径梳理结果准确性。特别在数仓迁移、监管指标梳理等场景中,对数据链路的精准分析并快速理解加工逻辑的需求愈发迫切,这不仅关乎数据使用的效率和准确性,更直接影响到业务决策的质量和速度。
  • 风险影响的及时全面分析:当上游数据发生变化时,必须确保这些变化能够及时、准确地同步到下游,以避免数据不一致和错误决策。这就要求开发团队具备高效的数据监控和预警机制,能够实时追踪数据变化,并自动触发相应的通知。企业对与从业务数据生产、到数据平台加工、再到业务应用的全链路影响分析也有强烈述求,上游的变化可以穿透到最下游的应用场景中,实现对重点应用的差异化保障和预警。
  • 数仓模型的长效优化机制:随着业务的不断发展和数据量的不断增长,数据链路越来越长、产出时间越来越晚,同时不断增加的冗余资产造成了资源浪费。上述问题已经成为企业数据架构治理的首要目标,而传统运动式治理普遍存在“治了又治”的情况,不仅投入大成本高、效果还难持续,亟需建立完善的数仓模型的长效优化机制。
  • 重复指标的发现和持续治理:数据口径的一致性是确保分析结果准确性的基础,但由于不同部门或团队对数据口径的理解存在差异,或者由于技术口径的不一致,导致数据分析结果难以对齐,增加了数据分析的成本和难度,影响决策的准确性。对“同名不同义、同义不同名”的重复指标能够快速甄别和持续治理,这也是对数据管理工作的巨大挑战。

目前看来,传统模式解决这些难题的专业门槛、人力投入要求很高,效果还难以保障,不持续、难复制、不经济,最终不能满足治理需求和业务需要。在此背景下,基于新一代数据血缘技术的“自治理”数据管理模式受到越来越多关注。

顾名思义,数据血缘如“家族图谱”一样,描绘了数据的起源、流经路径及其转换过程的详尽记录,可以精确追溯数据的初始来源,明晰其历经的各类处理流程,以及最终的应用方式,从而帮助企业分析并监控数据在业务链条中的上下游依赖关系,为企业提升数据管理效率和质量提供“洞察能力”

数据血缘技术发展历经“表级”、“列级”血缘,到具备精细化、自动化和智能化能力的“算子级”数据血缘,逐步实现了数据管理的“自治理”,开始成为企业数据管理的“关键基建”。

02、从表级血缘到列级血缘,再到算子级血缘

提到数据血缘技术,我们不得不谈一下其演进历程:

  • 第一代:表级血缘。过去提到血缘,很多时候讲的是“表级血缘”,即关注表与表之间的依赖关系。然而,即便实现了 100% 准确的“表级血缘”追踪,其在实际业务场景中的应用仍显局限。这是因为表与表之间的关系往往具有高度的泛化性,在下探或上溯多层后扩散出百倍甚至千倍的上下游,使用难度极大。比如,表级血缘下探 3 层后,可能会搜索出超过数千的下游表,导致用户在需要执行精细化的影响分析时,不得不深入到代码层面,逐一审查逻辑,并理解为何某张表的变化会影响另一张表,这种低效的分析方式让表级血缘聊胜于无。这也是在过去很长一段时间内,表级血缘作为资产管理平台等产品必备组件,但是存在感和应用范围极度有限的原因。
  • 第二代:列级血缘。在“表级血缘”的局限下,业务需求得不到有效满足,业界开始推动血缘精度进一步细化至字段级别,“列级血缘”技术应运而生。诸多厂商,包括开源界的 Atlas 项目等,都在尝试通过关系推断和正则匹配方式构建上下游字段之间的依赖关系。然而,由于技术解析的复杂性和局限性,绝大多数厂商对于列级血缘的解析准确率持谨慎态度,不敢轻易承诺。根据人工抽检统计,多数厂商的列级血缘准确率普遍低于 80%,这一现状使得众多企业在实际应用中对此技术持保留态度,担忧其稳定性和可靠性。所以“列级血缘”仅作为“表级血缘”的应用场景补充,无法独挡一面,用户在数据管理的“深水区”开展工作仍缺少关键支撑。

  • 第三代:算子级血缘“算子级血缘”是 Aloudata 独创的技术。借助 Aloduata 自研的多平台 SQL 方言解析器,能够深入剖析复杂的代码计算逻辑,从而准确、精细地刻画字段间的精细加工关系,并提供代码的改写能力,实现字段加工口径的提取和转换。如下图所示,“算子级血缘”可以清晰地展现数据上下游的列级加工关系和行级影响关系。例如,当上游表通过 Join 操作并应用特定的过滤条件时,会直接影响下游产出的记录行数量。通过“算子级血缘”技术,系统能够智能地分析 SQL 代码的 Where 条件,准确判断哪些下游表的行数受到了影响。整个过程如同一位经验丰富的数据专家在分析数据仓库的代码,全天候、不间断地执行这一任务,无需休息,确保数据加工关系的准确性和完整性。

03、Aloudata BIG:全球首个算子级血缘的主动元数据平台

Aloudata 凭借在数据管理和技术研发领域的深厚积累,通过独创的“算子级血缘”技术,打造了 Aloudata BIG 主动元数据平台,能够助力企业自动构建端到端、跨平台、可扩展的血缘图谱,为数据管理提供自动化、智能化的强大支持,实现数据管理模式的转变,推动数据管理走向自治化的新阶段。

作为全球首个算子级血缘的主动元数据平台,Aloudata BIG 平台具备强大的多源采集解析能力,已经成功支持了市场上主流的数据库的血缘解析,包括 Hive、Gauss、Oracle、MySQL 、PostgreSQL、Greeplum、Analytic Database 等,支持 Presto、Spark、Impala 等计算平台的血缘解析,支持 Oracle 等 PLSQL 存储过程血缘解析。未来还会支持市面上主流报表工具、调度平台或者 ETL 工具的血缘解析。

Aloudata BIG 平台支持配置式、扩展式的采集器结构,可以在算子级血缘图谱中快速接入企业自定义资产,助力企业形成数据资产“一张图”,全面整合和分析公司所有数据资产元数据。该图谱支持属性扩展,以支持各种数据推理任务,如识别管理驾驶舱中的 KPI 数据是否来源于特定数据表。通过将技术元数据、管理元数据、业务元数据与该图谱紧密绑定,Aloudata BIG 平台还能够为企业提供了从数据源到应用端的全连通能力,为数据管理场景提供端到端的自动化解决方案。

此外,Aloudata BIG 平台还具备反向元数据集成能力,提供标准化的元数据 API 和场景 API,可轻松融入企业的 DataOps 体系。通过该平台,企业能够将算子级血缘能力无缝集成到数据研发、数据资产管理和数据质量管控等平台中,为企业数据基础设施技术底座的升级提供强大支持。

04、算子级血缘图谱可视化,提升数据盘点和理解效率

通过 Aloudata BIG 平台,企业可以生成一张高精准、全链路可视化的算子级血缘图谱(如下图所示)。该图谱上游连接各种业务数据源,中间可以精准刻画数据加工链路,下游的应用系统血缘也可以通过标准化接口导入图谱,将各类自定义资产无缝连接到血缘图谱中,构建一个端到端连通、全链路覆盖的血缘图谱体系。

例如,可以通过解析BI报表的“数据源->数据集->指标->报表->看板”等元数据配置或者报表定义文件,将“报表内血缘”轻松集成到算子级血缘图谱中。凭借此图谱,企业可以全面打通数据生产、加工到消费的完整链路,实现穿透式的影响分析和精准溯源,让业务人员可以自助分析数据指标或报表的来源和加工口径,让数据集市管理人员可以主动评估数据变更和质量影响,实现上下游高效的数据协同,大幅提升数据盘点和理解效率。

在图谱可视化设计方面,我们巧妙地运用实线和虚线来区分各表中不同字段之间的血缘关系:实线血缘代表了“直接血缘”,表达了字段间的计算关系;虚线代表了“间接血缘”,用于刻画 Join 关系、Where 过滤条件和汇总维度。此外,算子级血缘解析技术还能精准裁剪和提取字段口径,以 SQL 代码形式展示,并支持字段多层链路的数据口径压缩,实现口径归一化溯源,帮助企业迅速、全面地掌握数据加工完整逻辑。

05、Aloudata BIG 核心特征:更全面、更精细、更准确

Aloudata BIG 平台在血缘解析技术上实现了“全面、精细、准确”的显著突破。

在全面性上,Aloudata BIG 平台能够自动采集并管理库、表、列、报表、模型、指标、标签、脚本等所有数据资产全生命周期的元数据,支持自定义元数据实体及关系数据的上报,可以将分散的元数据统一整合,形成相互关联的元数据图谱。通过 Aloudata BIG 平台,企业可以清晰地洞察所有数据的来龙去脉,构建出真正意义上的端到端、跨平台、可扩展且自动化的企业级主动元数据管理平台。

在精细度上,Aloudata BIG 平台的血缘解析能力达到了国际领先水平,并具备对复杂 SQL 代码的深入解析能力,即便是最复杂的数据链路,也可轻松打开链路加工“黑盒”。BIG 平台的血缘解析能力对 SQL 写法没有约束,支持几乎所有DDL、DML 语法;其次,不受任何函数限制或子查询的嵌套限制,能够穿透临时表解析出正确的数据来源;最后,BIG 的方言解析能力覆盖了市场上主流的数据仓库和计算平台产品,能够理解非常复杂的任务脚本,覆盖了超过 99% 的任务编写场景。这些能力已在招商银行、杭州银行等头部银行的生产环境和 POC 测试环境中得到了充分验证,证明其高效性和实用性。

同时,Aloudata BIG 平台还兼容多种数据逻辑的简化展示,如临时表会被隐藏在任务内血缘。通过其强大的任务解析能力,各种代码逻辑都能被准确地转化为血缘图谱并呈现出来。

为解决血缘泛化问题,Aloudata BIG 平台独创了“行级裁剪”技术。在数据加工链路中,核心公共数据模型或者主数据模型(如会员表、订单表、账户表等)通常汇聚了多个上游系统的数据,并且被多个下游表依赖使用。如果是普通的表列血缘关系,上下游会形成“多对多”的血缘映射关系。通过“行级裁剪”技术,可以精确确定下游表的实际来源,避免血缘多对多关系的干扰,可以显著提升溯源和影响分析的工作效率。在头部银行的POC中,该技术的验证结果与人工判定几乎一致,充分证明了 Aloudata BIG 平台“行级裁剪”技术的领先性和可靠性。

在准确率上,Aloudata BIG 平台能够稳定提供和保持 95% 以上的数据血缘准确率。这一卓越性能的达成,首先归功于严格的产品出厂质量门禁,即在产品出厂前,会通过多解析器进行交叉比对验证,确保“血缘解析成功即形成正确的血缘、血缘解析不成功即报错”。然后,我们会深入分析错误日志,针对无法解析或解析失败的案例进行错误分类和归因分析,不断完善和优化血缘解析器能力。经过多年技术沉淀和在头部客户真实环境的验证,Aloudata BIG 平台公开承诺:算子级血缘准确率可稳定在 95% 以上

在实际应用中,我们为招商银行、杭州银行生产环境均交付了超过 99%准确率的算子级血缘图谱。在产品交付给客户后,为长期维持血缘准确率,我们采用双重方案来推进准确率运营:

  • 从技术视角出发:Aloduata BIG 提供血缘准确率的量化评估模型,可以计算出整体血缘准确率的精确结果。针对错误,产品提供白盒化运维能力,对每日解析任务的错误日志进行错误归因,元数据管理员可以针对性推进错误数据的修正运营,确保准确率的稳定提升。
  • 从业务视角出发:赋能客户利用血缘 API开发定制化的业务校验程序,例如从末端节点溯源到 ODS 层,检查中间血缘是否存在断点,从而确保血缘准确率和用户感知的一致性。业务校验规则是 Aloudata 在多年服务头部金融企业中积累并沉淀的,是一套高效的数据血缘准确率保障和衡量机制。客户可以基于这些业务规则或自有数据规范进行创新,适配企业内部对血缘准确的业务要求。

鉴于出色的性能表现,Aloudata BIG 平台已在多个极高复杂度的数据环境中完成实地验证。

其中招商银行构建起全链路算子级血缘图谱,将算子级血缘分析技术应用到模型优化和变更协同的场景中,服务全行的数据开发人员,血源解析成功率提升至 99.9%,全链路协同保障效率提升 10 倍,平均数据链路缩短 50%。该案例已入选中国信通院 2023 大数据“星河”标杆案例和《2024 IDC PeerScape:金融领域数据管理分析服务最佳实践案例》报告。(点击此处查看案例详情)

杭州银行数据资产管理平台以 Aloudata BIG 平台的算子级血缘为底座,实现全域数据资产统一采集和连接,端到端连通从业务源端数据库到应用端报表的算子级血缘图谱,从依赖人工盘点到自动化挖掘元数据知识,丰富了数据治理手段,提升了治理方案落地效果和效率。该案例获选沙丘社区「2024 中国数据资产管理最佳实践案例」。(点击此处查看案例详情)

那么,在具体在实际应用中,该如何集成、应用 Aloudata BIG 主动元数据平台,我们下篇将给出详细回答,期待您的关注与交流。

这篇关于主动元数据平台详解(上):算子级血缘,创新数据管理新范式的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1058529

相关文章

十四、观察者模式与访问者模式详解

21.观察者模式 21.1.课程目标 1、 掌握观察者模式和访问者模式的应用场景。 2、 掌握观察者模式在具体业务场景中的应用。 3、 了解访问者模式的双分派。 4、 观察者模式和访问者模式的优、缺点。 21.2.内容定位 1、 有 Swing开发经验的人群更容易理解观察者模式。 2、 访问者模式被称为最复杂的设计模式。 21.3.观察者模式 观 察 者 模 式 ( Obser

【操作系统】信号Signal超详解|捕捉函数

🔥博客主页: 我要成为C++领域大神🎥系列专栏:【C++核心编程】 【计算机网络】 【Linux编程】 【操作系统】 ❤️感谢大家点赞👍收藏⭐评论✍️ 本博客致力于知识分享,与更多的人进行学习交流 ​ 如何触发信号 信号是Linux下的经典技术,一般操作系统利用信号杀死违规进程,典型进程干预手段,信号除了杀死进程外也可以挂起进程 kill -l 查看系统支持的信号

创新、引领、发展——SAMPE中国2024年会在京盛大开幕

绿树阴浓夏日长,在这个色彩缤纷的季节,SAMPE中国2024年会暨第十九届国际先进复合材料制品原材料、工装及工程应用展览会在中国国际展览中心(北京朝阳馆)隆重开幕。新老朋友共聚一堂,把酒话桑麻。 为期4天的国际学术会议以“先进复合材料,引领产业创新与可持续化发展”为主题,设立了34个主题分会场,其中包括了可持续化会场、国际大学生会场、中法复合材料制造技术峰会三个国际会场和女科技工作者委员会沙龙,

【服务器运维】MySQL数据存储至数据盘

查看磁盘及分区 [root@MySQL tmp]# fdisk -lDisk /dev/sda: 21.5 GB, 21474836480 bytes255 heads, 63 sectors/track, 2610 cylindersUnits = cylinders of 16065 * 512 = 8225280 bytesSector size (logical/physical)

Jitter Injection详解

一、定义与作用 Jitter Injection,即抖动注入,是一种在通信系统中人为地添加抖动的技术。该技术通过在发送端对数据包进行延迟和抖动调整,以实现对整个通信系统的时延和抖动的控制。其主要作用包括: 改善传输质量:通过调整数据包的时延和抖动,可以有效地降低误码率,提高数据传输的可靠性。均衡网络负载:通过对不同的数据流进行不同程度的抖动注入,可以实现网络资源的合理分配,提高整体传输效率。增

springboot家政服务管理平台 LW +PPT+源码+讲解

3系统的可行性研究及需求分析 3.1可行性研究 3.1.1技术可行性分析 经过大学四年的学习,已经掌握了JAVA、Mysql数据库等方面的编程技巧和方法,对于这些技术该有的软硬件配置也是齐全的,能够满足开发的需要。 本家政服务管理平台采用的是Mysql作为数据库,可以绝对地保证用户数据的安全;可以与Mysql数据库进行无缝连接。 所以,家政服务管理平台在技术上是可以实施的。 3.1

SQL Server中,查询数据库中有多少个表,以及数据库其余类型数据统计查询

sqlserver查询数据库中有多少个表 sql server 数表:select count(1) from sysobjects where xtype='U'数视图:select count(1) from sysobjects where xtype='V'数存储过程select count(1) from sysobjects where xtype='P' SE

Steam邮件推送内容有哪些?配置教程详解!

Steam邮件推送功能是否安全?如何个性化邮件推送内容? Steam作为全球最大的数字游戏分发平台之一,不仅提供了海量的游戏资源,还通过邮件推送为用户提供最新的游戏信息、促销活动和个性化推荐。AokSend将详细介绍Steam邮件推送的主要内容。 Steam邮件推送:促销优惠 每当平台举办大型促销活动,如夏季促销、冬季促销、黑色星期五等,用户都会收到邮件通知。这些邮件详细列出了打折游戏、

比较学习难度:Adobe Illustrator、Photoshop和新兴在线设计平台

从入门设计开始,几乎没有人不知道 Adobe 公司两大设计软件:Adobe Illustrator和 Photoshop。虽然AI和PS很有名,有一定设计经验的设计师可以在早期探索和使用后大致了解AI和PS的区别,但似乎很少有人会系统地比较AI和PS。目前,设计软件功能多样,轻量级和网页设计软件已成为许多设计师的需求。对于初学者来说,一篇有针对性的AI和PS比较总结文章具有非常重要的指导意义。毕竟

探索Elastic Search:强大的开源搜索引擎,详解及使用

🎬 鸽芷咕:个人主页  🔥 个人专栏: 《C++干货基地》《粉丝福利》 ⛺️生活的理想,就是为了理想的生活! 引入 全文搜索属于最常见的需求,开源的 Elasticsearch (以下简称 Elastic)是目前全文搜索引擎的首选,相信大家多多少少的都听说过它。它可以快速地储存、搜索和分析海量数据。就连维基百科、Stack Overflow、