具体实施方式
为了使本申请实施例中的技术方案及优点更加清楚明白,以下结合附图对本申请的示例性实施例进行进一步详细的说明,显然,所描述的实施例仅是本申请的一部分实施例,而不是所有实施例的穷举。需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。
本申请实施例中的方案能够应用于如数据字典等工具的依赖关系(血缘)影响分析功能上,但本领域技术人员应当理解,上述应用只是为便于本技术技术人员理解本申请的目的示出,并不用于限制本申请。
图1为本申请实施例一所示数据仓库的数据处理方法流程图。
如图1所示,根据本申请实施例一所示的数据仓库的数据处理方法包括以下步骤:
S102,接收用户输入的查询条件,查询条件包括待查询数据的关键词;
S104,根据关键词确定待查询数据与数据仓库中其他数据的依赖关系,依赖关系是下述的一种:无依赖、强依赖、弱依赖;
S106,向用户返回依赖关系;
S108,接收用户根据依赖关系下发的数据处理指令;
S110,触发数据仓库对待查询数据执行数据处理指令。
本领域技术人员应当理解,数据仓库中存储的数据主要是数据开发产出的物理表或视图。表是数据仓库最重要的组成部分,表通常由关键词key,度量,属性数据组成,例如员工表由员工号(key),员工姓名,年龄等员工属性数据组成。视图同表一样,也包含一系列带有名称的列和行数据,但是,视图在数据库中并不以存储的数据值集的形式存在,而是由查询定义,可以视为虚拟的表。
依赖关系是指数据仓库数据研发过程中,表或视图被下游其他视图或任务使用、消费而形成的关系,或者表或视图在形成过程中对上游其他表或视图的使用、消费而形成的关系。
无依赖是指数据与其他数据之间没有任何的依赖关系;强依赖是指数据与其他数据之间存在调度关系,是最强也是最直观的一种依赖关系;弱依赖是指数据之间不是调度关系,但可以通过执行例如SQL((Structured Query Language,结构化查询语言)日志或视图DDL(Data Definition Language,数据库模式定义语言)语句解析出来的依赖关系;弱依赖在数据研发过程中比较隐蔽,很容易被忽略掉;例如,表被视图使用、表或视图被数据工厂、定时任务、数据回流生产任务等使用均是弱依赖关系。
各表或视图被下游任务所依赖使用,也被数据使用者在IDE(IntegratedDevelopment Environment,集成开发环境)、报表工具、定时任务等工具使用,目前数据仓库有上万张表,存在错综复杂的依赖关系。
在具体实施时,用户输入的该查询条件包括待查询数据的关键词,该关键词可以是表的名字,也可以是节点ID(IDentity的缩写,身份标识号码),例如,待查询数据是员工表时,该关键词可以是作为该表的关键词的员工号。
在具体实施时,采用oracle、mysql、teradata传统数据库或者Greenplum、hadoop、odps等分布式数据库都可以实施本申请实施例中的数据处理方法。
在具体实施时,本申请实施例中待查询数据与数据仓库中其他数据的依赖关系可以是预先生成的,也可以是在接受到用户输入的查询请求之后生成的,本申请对此并不做限制。
采用本申请实施例中的数据仓库的数据处理方法,能够在接收到用户输入的查询条件后,确定并向用户返回待查询数据与其他数据的依赖关系;供用户根据依赖关系下发针对待查询数据的数据处理指令,然后再触发数据仓库执行数据处理指令;从而能够根据依赖关系对数据仓库中的数据进行处理,避免了现有技术中不对数据进行处理导致的资源浪费。
优选地,根据关键词确定待查询数据与数据仓库中其他数据的依赖关系具体包括:根据关键词确定待查询数据;调用元数据生成待查询数据与数据仓库中其他数据的依赖关系。
元数据是指描述数据的数据,对数据及信息资源的描述性信息,包括业务表结构信息、数仓表结构信息等。
优选地,元数据包括调度元数据、SQL执行日志元数据、表结构元数据、同步中心元数据、定时任务元数据中的一个或多个。
优选地,在向用户返回依赖关系之后,在接收用户根据依赖关系下发的数据处理指令之前;还包括:根据依赖关系向用户提供针对待查询数据的数据处理指令。
为了便于用户对查询的数据进行数据处理,还可以在查询到相应待查询数据的依赖关系之后,向用户提供对应的处理指令,包括:如果查询数据的依赖关系是“无依赖”,则向用户提供对应于无依赖数据的数据处理指令;如果查询数据的依赖关系是“强依赖”,则向用户提供对应于强依赖数据的数据处理指令;如果查询数据的依赖关系是“弱依赖”,则向用户提供对应于弱依赖数据的数据处理指令。
优选地,数据处理指令是下线或变更。
本领域技术人员应当理解,下线是指对表进行物理删除或重命名备份;变更是指对表的内容或视图逻辑进行更新。
在具体实施时,对于无依赖关系的数据,则提供“下线”和“变更”处理指令,对于存在强依赖关系的数据,则提供“变更”功能及“变更通知”功能;对于存在弱依赖关系的数据,则提供“变更”等,本领域技术人员应当理解,上述依赖关系与处理指令之间的关系仅是为示例的目的而示出,并不用于限制本申请。
在现有技术中,由于数据仓库中的表与视图之间的错综复杂的依赖或使用关系,在数据工程师想要对数据进行下线或变更时,只能手动查询该数据与其他数据的依赖关系,然后再根据该依赖关系进行下线或是变更,但是手动的查询不能穷尽数据仓库,导致变更的影响范围不确定,会造成使用数据的工程师产出指标错误或数据业务逻辑出现缺陷,导致资损或客户投诉;同时手动的维护工作量也较繁重;如果想要穷尽,则手动查询的成本很高。
而采用本申请实施例中的方案,数据工程师可以查询想要下线或是变更的数据的依赖关系;然后根据该依赖关系选择下线或是变更;例如,如果无依赖,则进行下线,如果是强依赖,则进行变更并通知;如果是弱依赖,则进行变更等,从而使得数据工程师能够根据依赖关系对数据仓库中的数据进行处理,方便了数据处理,提升影响评估准确性,提高了数据处理的效率和准确度。
在具体实施时,查询条件还可以进一步包括查询数据的依赖关系的方向和层级,例如,向上游回溯N级,或者向下游查询N级。
向上游回溯是指向上游查询待查询数据所依赖的N级表或视图;向下游查询是指向下游查询待查询数据所被依赖的N级表或视图。
根据待查询数据与上游数据的依赖关系,用户可以用于待查询数据的出错检查、模型健康检查、数据路径长度检测、数据处理效率评估等。
对于待查询数据与下游数据的依赖关系,用户可以用于待查询数据的下线或变更处理等。
下面结合图2对根据本申请实施例二的数据处理方法进行介绍。
本申请实施例中的数据处理方法可以基于元数据整合的依赖关系结果进行功能展现,并提供向上游、下游设定N级依赖关系查询及展现,具体的依赖关系结果展现如图2所示。
图2中,查询血缘类型即是指用户想要查询的依赖关系的分类,包括:表血缘、视图血缘、任务血缘等。
在具体实施时,用户选择想要查询的血缘类型为“表血缘”,待查询的数据是表名为“dwb_fnd_dback_all_dd”的表;查询层次为1,查询方向为下游。
经本申请实施例的数据处理方法处理后,向用户反馈与“dwb_fnd_dback_all_dd”表存在依赖关系的有以下节点:“dwd1”、“dws1”、“dws2”、“dwb1”、“dws3”、“st1”、“dws4”、“st2”、“adm1”,并提供了与这些节点相应的节点名、表名、以相应的依赖关系和表类型。
用户在相应的节点处点击右键可以选择相应的处理方式,本申请实施例中查询得到的结果均为“强依赖”,因此向用户提供“变更”及“变更通知”功能。
采用本申请实施例中的方案,能够在接收到用户输入的查询条件后,确定并向用户返回待查询数据与其他数据的依赖关系;供用户根据依赖关系下发针对待查询数据的数据处理指令,然后再触发数据仓库执行数据处理指令;从而能够根据依赖关系对数据仓库中的数据进行处理,避免了现有技术中的资源浪费,提升了数据仓库的资源使用效率,降低了数据处理的出错概率,提高了数据处理的效率和准确度。
基于同一发明构思,本申请实施例中还提供了一种数据仓库的数据处理装置,由于该装置解决问题的原理与数据处理方法相似,因此该装置的实施可以参见方法的实施,重复之处不再赘述。
图3是根据本申请实施例三的数据仓库的数据处理装置的结构框图。
如图3所示,根据本申请实施例二的数据仓库的数据处理装置20包括:查询模块202,用于接收用户输入的查询条件,查询条件包括待查询数据的关键词;依赖关系确定模块204,用于根据关键词确定待查询数据与数据仓库中其他数据的依赖关系,依赖关系是下述的一种:无依赖、强依赖、弱依赖;反馈模块206,用于向用户返回依赖关系;指令接收模块208,用于接收用户根据依赖关系下发的数据处理指令;触发模块210,用于触发数据仓库对待查询数据执行数据处理指令。
优选地,依赖关系确定模块具体包括:确定子模块,用于根据关键词确定待查询数据;依赖关系生成子模块,用于根据元数据生成待查询数据的依赖关系。
优选地,元数据包括调度元数据、SQL执行日志元数据、表结构元数据、同步中心元数据、定时任务元数据中的一个或多个。
优选地,该数据处理装置还包括:指令提供模块,用于根据依赖关系向用户提供针对待查询数据的数据处理指令。
优选地,数据处理指令是下线或变更。
在具体实施时,可以使用java、jsp或者.net等语言实现本申请实施例中的数据处理装置。
数据仓库的表或视图的下游生产任务依赖、数据消费是错综复杂的,建立起全覆盖的数据影响分析,对于数据生产管理至关重要,可以降低工作复杂度、提升开发效率、保障工作质量。通过本申请实施例中的数据处理装置,数据开发工程师可以基于该装置很直观地判断将要处理的表或视图与其他数据的依赖关系,从而很直观的确定将要执行的数据处理指令的影响范围、以及能否进行下线处理和变更。
在具体实施时,本申请实施例中的数据处理装置可以通过查询模块向用户提供依赖关系查询服务、下线、变更通知查询服务等。
在具体实施时,本申请实施例中的数据处理装置可以通过依赖关系生成子模块,对调度元数据、SQL执行日志元数据、表结构元数据、同步中心元数据、定时任务元数据等进行整合,以精准、全面分析数据之间的依赖关系,并产出接口表。
在具体实施时,本申请实施例中的数据处理装置可以基于元数据整合的依赖关系结果进行功能展现,并提供向上游、下游设定N级影响查询及展现。
在具体实施时,本申请实施例中的数据处理装置可以对下游没有依赖、使用的表或视图提供一键下线功能,还可以提供对下游没有依赖的任务进行下线,对表进行物理删除或重命名备份等功能。
在具体实施时,本申请实施例中的数据处理装置还可以对变更后的表或视图提供变更通知功能,以便于数据开发工程师可以基于依赖关系对变更后的表或视图的下游任务所有者(owner)或使用者发送变更通知邮件。
采用本申请实施例中的方案,用户输入表或名字、设定层级、选择向上游或向下游进行依赖关系查询,数据处理装置调用元数据服务查询依赖关系结果并展示出来,用户可以基于结果判定是进行下线操作还是变更通知,如果有下游或使用信息,则不能进行下线操作;如果选择下线操作,则数据处理装置触发数据仓库对表或视图进行物理删除或重命名并将对应的任务进行下线处理;如果选择变更,则填写变更描述后,触发变更,并发送变更通知,系统自动对下游任务owner、使用数据工程师发送变更邮件,内容包括变更描述、变更影响清单等。
采用本申请实施例中的方案,能够在接收到用户输入的查询条件后,确定并向用户返回待查询数据与其他数据的依赖关系;供用户根据依赖关系下发针对待查询数据的数据处理指令,然后再触发数据仓库执行数据处理指令;从而能够根据依赖关系对数据仓库中的数据进行处理,避免了现有技术中不对数据进行处理导致的资源浪费,提升了数据仓库的资源使用效率,降低了数据处理的出错概率,提高了数据处理的准确度。
为了描述的方便,以上所述装置的各部分以功能分为各种部件或单元分别描述。当然,在实施本申请时可以把各部件或单元的功能在同一个或多个软件或硬件中实现。
本领域内的技术人员应明白,本申请的实施例可提供为方法、系统、或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例作出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。