基于MaxCompute InformationSchema进行血缘关系分析

一、需求场景分析 在实际的数据平台运营管理过程中,数据表的规模往往随着更多业务数据的接入以及数据应用的建设而逐渐增长到非常大的规模,数据管理人员往往希望能够利用元数据的分析来更好地掌握不同数据表的血缘关系,从而分析出数据的上下游依赖关系。 本文将介绍如何去根据MaxCompute InformationSchema中作业ID的输入输出表来分析出某张表的血缘关系。 二、方案设计思路 MaxCompute Information_Schema提供了访问表的作业明细数据tasks_history,该表中有作业ID、input_tables、output_tables字段记录表的上下游依赖关系。根据这三个字段统计分析出表的血缘关系 1、根据某1天的作业历史,通过获取tasks_history表里的input_tables、output_tables、作业ID字段的详细信息,然后分析统计一定时间内的各个表的上下游依赖关系。 2、根据表上下游依赖推测出血缘关系。 三、方案实现方法 参考示例一: (1)根据作业ID查询某表上下游依赖SQL处理如下:

select t2.input_table, t1.inst_id, replace(replace(t1.output_tables,"[",""),"]","") as output_table from information_schema.tasks_history t1 left join ( select ---去除表开始和结尾的[ ] trans_array(1,",",inst_id, replace(replace(input_tables,"[",""),"]","")) as (inst_id,input_table) from information_schema.tasks_history where ds = 20190902 )t2 on t1.inst_id = t2.inst_id where (replace(replace(t1.output_tables,"[",""),"]","")) <> "" order by t2.input_table limit 1000;

结果如下图所示:

(2)根据结果可以分析得出每张表张表的输入表输出表以及连接的作业ID,即每张表的血缘关系。 血缘关系位图如下图所示:

中间连线为作业ID,连线起始为输入表,箭头所指方向为输出表。 参考示例二: 以下方式是通过设置分区,结合DataWorks去分析血缘关系: (1)设计存储结果表Schema

CREATE TABLE IF NOT EXISTS dim_meta_tasks_history_a ( stat_date STRING COMMENT ‘统计日期‘, project_name STRING COMMENT ‘项目名称‘, task_id STRING COMMENT ‘作业ID‘, start_time STRING COMMENT ‘开始时间‘, end_time STRING COMMENT ‘结束时间‘, input_table STRING COMMENT ‘输入表‘, output_table STRING COMMENT ‘输出表‘, etl_date STRING COMMENT ‘ETL运行时间‘ );

(2)关键解析sql

SELECT ‘${yesterday}‘ AS stat_date ,‘project_name‘ AS project_name ,a.inst_id AS task_id ,start_time AS start_time ,end_time AS end_time ,a.input_table AS input_table ,a.output_table AS output_table ,GETDATE() AS etl_date FROM ( SELECT t2.input_table ,t1.inst_id ,replace(replace(t1.input_tables,"[",""),"]","") AS output_table ,start_time ,end_time FROM ( SELECT * ,ROW_NUMBER() OVER(PARTITION BY output_tables ORDER BY end_time DESC) AS rows FROM information_schema.tasks_history WHERE operation_text LIKE ‘INSERT OVERWRITE TABLE%‘ AND ( start_time >= TO_DATE(‘${yesterday}‘,‘yyyy-mm-dd‘) and end_time <= DATEADD(TO_DATE(‘${yesterday}‘,‘yyyy-mm-dd‘),8,‘hh‘) ) AND(replace(replace(output_tables,"[",""),"]",""))<>"" AND ds = CONCAT(SUBSTR(‘${yesterday}‘,1,4),SUBSTR(‘${yesterday}‘,6,2),SUBSTR(‘${yesterday}‘,9,2)) )t1 LEFT JOIN( SELECT TRANS_ARRAY(1,",",inst_id,replace(replace(input_tables,"[",""),"]","")) AS (inst_id,input_table) FROM information_schema.tasks_history WHERE ds = CONCAT(SUBSTR(‘${yesterday}‘,1,4),SUBSTR(‘${yesterday}‘,6,2),SUBSTR(‘${yesterday}‘,9,2)) )t2 ON t1.inst_id = t2.inst_id where t1.rows = 1 ) a WHERE a.input_table is not null ;

(3)任务依赖关系

(4)最终血缘关系

以上血缘关系的分析是根据自己的思路实践去完成。真实的业务场景需要大家一起去验证。所以希望大家有需要的可以根据自己的业务需求去做相应的sql修改。如果有发现处理不当的地方希望多多指教。我在做相应的调整。

原文链接

本文为阿里云内容,未经允许不得转载。

原文地址:https://www.cnblogs.com/yunqishequ/p/12083658.html

时间: 2024-08-30 15:42:16

基于MaxCompute InformationSchema进行血缘关系分析的相关文章

基于MaxCompute打造轻盈的人人车移动端数据平台

以下内容根据演讲视频以及PPT整理而成. 一.人人车数据平台 快速搭建,一年时间完成6大平台的搭建 基于阿里云平台上成熟的技术,人人车企业只用了一年时间便实现了6大数据平台的设计与搭建,其中包括:Jarvis-BI报表平台.Metadata-元数据管理平台.Streaming-实时计算平台.Athena-数据工单平台.Cateye-监控平台与AD-HOC-自助取数平台. 上述数据平台的最底层均由阿里云的相关技术支撑运行,阿里云为平台的搭建提供了两种不同技术的支持,在储存计算技术方面,阿里云提供了

基于UML的毕业设计管理系统的分析与设计

基于UML的毕业设计管理系统的分析与设计 <本段与标题无关,自行略过 最近各种忙,天气不错,导师心情不错:"我们要写一个关于UNL的专著",一句话:"一个完整的系统贯穿整个UML的知识":我:"--o---k--".忙里偷闲,先回顾一下吧> 毕业设计是实现本科教学培养目标的重要环节,从选题到答辩一般需要四至六个月的时间,其间工作量很大,尤其需要保留大量的文件,以便于管理者对毕业设计工作进行监督.传统的.人工的方式管理各项事务和文件档案

基于共现发现人物关系的python实现

基于共现发现人物关系的python实现 参考链接: 提取<釜山行>人物关系, 用Python的networkx绘制精美网络图 1.共现关系 在文献计量学中,关键词的共词方法常用来确定该文献集所代表学科中各主题之间的关系.而在这里,我们需要通过分析一篇小说或剧本,来分析剧中各个角色之间的人物关系.两者有很相同的地方. 一般我们认为,在一篇文章中的同一段出现的两个人物之间,一定具有某种关联,因此我们的程序的大致流程也可以确定下来.我们可以先做分词,将每一段中的人物角色抽取出来,然后以段落为单位,统

文献综述四:基于 UML 技术的客户关系管理系统实现

一.基本信息 标题:基于 UML 技术的客户关系管理系统实现 时间:2015 出版源:电子设计工程 文件分类:uml技术的研究 二.研究背景 使用UML 建模技术和 B/S 架构访问模式,设计出可应用与银行和储户之间沟通的客户关系管理系统.,从而实现对客户管理的信息化,提升了企业对客户维护的能力. 三.具体内容 首先提到为什么要使用uml建模的技术,之后从四个方面来阐述客户关系系统. 1.系统用例分析:介绍了用例图,通过把系统用户分为客户经理和系统管理员.分别阐述了两种角色的功能. 2.系统功能

基于Java 生产者消费者模式(详细分析)

本文目录:1.等待.唤醒机制的原理2.Lock和Condition3.单生产者单消费者模式4.使用Lock和Condition实现单生产单消费模式5.多生产多消费模式(单面包)6.多生产多消费模式 生产者消费者模式是多线程中最为常见的模式:生产者线程(一个或多个)生成面包放进篮子里(集合或数组),同时,消费者线程(一个或多个)从篮子里(集合或数组)取出面包消耗.虽然它们任务不同,但处理的资源是相同的,这体现的是一种线程间通信方式. 本文将先说明单生产者单消费者的情况,之后再说明多生产者多消费者模

文献综述二十:基于UML技术的客户关系管理系统实现

一.基本信息 标题:基于UML技术的客户关系管理系统实现 时间:2015 出版源:电子设计工程 文件分类:uml技术的研究 二.研究背景 设计出可应用与银行和储户之间沟通的客户关系管理系统,从而实现对客户管理的信息化 ,提升了企业对客户维护的能力. 三.具体内容 文献的主要内容分为五个部分.基于UML建模技术的系统用例分析.系统功能设计.客户关系管理系统结构设计.系统开发工具.系统功能流程设计与实现代码. 基于UML建模技术的系统用例分析:包括银行客户经理系统用例图和管理员的用例分析.银行客户经

基于100,000篇演讲的分析数据科学家发现了最佳演讲者的特征——及时解释听众不懂的词语,必要时提高10%的音调,正确和恰当的手势,氛围的营造

[TD精选] 基于100,000篇演讲的分析数据科学家发现了最佳演讲者的特征 相信大部分人一定试图寻找过使得自己的演讲变得更加吸引人,更加有气势的方法.现如今,在大数据工具和机器学习技术的辅助下,找到完美演讲的答案已经变得十分容易.Noah Zandan, CEO of Quantified Communications, 为人们提供了第一个能够分析,衡量,评估以及提高人们交流和演讲技巧的分析平台.Zandan 的数据团队分析了100,000多篇来自于企业家,政治家和演说家的演讲.他们将分析重点

基于虎书实现LALR(1)分析并生成GLSL编译器前端代码(C#)

基于虎书实现LALR(1)分析并生成GLSL编译器前端代码(C#) 为了完美解析GLSL源码,获取其中的信息(都有哪些in/out/uniform等),我决定做个GLSL编译器的前端(以后简称编译器或FrontEndParser). 以前我做过一个CGCompiler,可以自动生成LL(1)文法的编译器代码(C#语言的).于是我从<The OpenGL ® Shading Language>(以下简称"PDF")找到一个GLSL的文法,就开始试图将他改写为LL(1)文法.等

基于虎书实现LALR(1)分析并生成GLSL编译器前端(C#)

基于虎书实现LALR(1)分析并生成GLSL编译器前端(C#) 为了完美解析GLSL源码,获取其中的信息(都有哪些in/out/uniform等),我决定做个GLSL编译器的前端(以后简称编译器). 以前我做过一个CGCompiler,能自动生成LL(1)文法的编译器代码(C#语言的).于是我从<The OpenGL ® Shading Language>(以下简称"PDF")找到一个GLSL的文法,就开始试图将他改写为LL(1)文法.等到我重写了7次后发现,这是不可能的.