一种基于图形数据库的元数据关系的构建方法与流程

1.本发明属于图形数据库技术领域，尤其涉及一种基于图形数据库的元数据关系的构建方法。


背景技术：

2.为贯彻落实国家数字政府建设总体规划，加快推动数字政府建设，使政府职能逐步转变，从原先的管理方式转变为先进的服务方式。在政府职能转变过程中，必须打破现有政府部门之间的信息壁垒，不断推动政府数据开发共享、推动资源整合，提升治理能力。同时，政府部门通过建设省市县大数据中心方式，对各个部门使用的业务系统数据库进行集中整合，形成数据仓库对外开放共享。在数据仓库对外共享使用的过程中，存在数据标准不统一、数据关联关系不清晰等情况，导致很多共享数据变成问题元数据，造成数据共享效率低下，共享数据无法直接使用等问题。
3.当前广泛使用的元数据血缘关系构建主要以传统关系型数据库为主，虽然能够对元数据进行追溯，但在实际使用过程中存在一定的限制和缺陷。如首先无法追溯关系深度大于一定数据值的元数据，在对关系深度小于一定数据值的元数据进行追溯时，运行效率较差；其次，需要开发技术接口配合数据追溯，有比较高的技术门槛；再次，支持并发度较低，无法支撑高并发业务等。而政务类元数据更加强调对数据追溯的时效性与准确性，因此现有元数据血缘关系构建在政务数据应用上存在缺陷，无法有效支撑。


技术实现要素：

4.针对现有技术不足，本发明的目的在于提供一种基于图形数据库的元数据关系的构建方法，基于janusgraph图数据库构建元数据管理容器，提升在政务大规模数据管理与应用过程中元数据识别、建模、元数据关系管理与数据视图生成的效率与直观性，解决关系深度深时的元数据追溯问题慢，运行效率差，不能集群化部署，支持并发度低的问题。
5.本发明提供如下技术方案：一种基于图形数据库的元数据关系的构建方法，包括以下步骤：s1，通过对各部门业务系统数据库表进行分析，并生成数据普查报告；s2，根据各业务系统特点及数据库版本，通过etl工具对各个业务系统进行etl任务配置； s3，将配置好的任务通过大数据平台进行注册、治理、调度操作。将配置好的任务注册到大数据平台任务调度中心，对业务系统数据库进行采集。
6.优选的，在步骤s1中，所述数据库表分析步骤为：首先整理现有各部门业务系统数据库表结构，然后分析各业务系统字段之间的关联关系和真实的字段含义。
7.优选的，所述大数据平台包括数据治理平台、任务调度平台。
8.优选的，在步骤s2中，所述etl工具用于对各业务系统数据进行采集，并将各个元数据与数据进行耦合，并将采集完成的元数据和数据通过所述数据治理平台对元数据进行管理。
9.优选的，所述数据治理平台对元数据进行管理的实现方式为：通过微服务方式对采集元数据进行数据关联，并将生成的关联关系直接写入到janusgraph库。
10.优选的，所述任务调度平台用于对数据治理平台治理完成的数据进行数据仓库分层构建综合库或专题数据库。
11.优选的，所述任务调度平台在对数据进行调度过程中，数据流向通过日志组件将数据最终流向更新到janusgraph库。
12.优选的，在步骤s3中，所述大数据平台包括还包括运维监控平台，用于实时监控任务采集情况。
13.优选的，所述日志组件包括系统日志、错误日志、中间表日志，所述系统日志用于记录对数据源和数据仓库的操作，系统日志记录的内容包括当前用户、系统时间、所做的操作以及用户总数目；所述错误日志用于在流程错误点产生时记录错误信息，错误日志可以帮助业务开发人员调试；所述中间表日志用于记录系统对数据转移过程中组建的创建信息、系统运行时间和运行周期以及在数据转换时程序的流程情况。显示数据是怎样从源数据库中抽取出来装载到目标数据库中的。
14.优选的，所述etl工具的工作方式是通过先抽取再装载最后在系统仓库中进行数据转换的方式实现。即数据转换在数据装载之后。
15.与现有技术相比，本发明具有以下有益效果：(1)本发明一种基于图形数据库的元数据关系的构建方法，通过基于janusgraph图数据库构建元数据管理容器，提升在政务大规模数据管理与应用过程中元数据识别、建模、元数据关系管理与数据视图生成的效率与直观性，解决关系深度深时的元数据追溯问题慢，运行效率差，不能集群化部署，支持并发度低的问题。
16.(2)本发明一种基于图形数据库的元数据关系的构建方法，通过采用的etl工具支持多类型关系或非关系数据库的采集，可进行多链路采集，能保证断点续传，不仅能对元数据进行采集也支持对数据的采集，且采集过程不需要复杂治理过程。
17.(3)本发明一种基于图形数据库的元数据关系的构建方法，通过数据治理平台能对数据建立统一标准，检核数据质量，准确描述数据元属性，分析数据之间关联关系，形成数据资源目录，实现数据快速检索，和对数据全生命周期进行管理。
18.(4)本发明一种基于图形数据库的元数据关系的构建方法，元数据追溯关系深度越大，本方法的优势越明显，在政务元数据管理应用过程中，数据的深度能够反映数据的价值，而处理数据深度也是构建元数据模型的基础，本发明基于janusgraph图形数据库实现了对元数据的设计管理，能够成功追溯到源头业务系统数据，并且以图形的方式展示元数据之间的关系，展示效果更加直观、清晰。
附图说明
19.为了更清楚地说明本发明实施方式的技术方案，下面将对实施方式中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
20.图1为本发明的共晶磷去除方法的流程图。
21.图2为本发明的血缘关系图。
22.图3为本发明的etl工作原理图。
具体实施方式
23.为使本发明实施方式的目的、技术方案和优点更加清楚，下面将结合本发明实施方式中的附图，对本发明实施方式中的技术方案进行清楚、完整地描述。显然，所描述的实施方式是本发明一部分实施方式，而不是全部的实施方式。基于本发明中的实施方式，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式，都属于本发明保护的范围。
24.因此，以下对在附图中提供的本发明的实施方式的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施方式。基于本发明中的实施方式，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式，都属于本发明保护的范围。
25.实施例1请参阅图1-2所示，一种基于图形数据库的元数据关系的构建方法，包括以下步骤：s1，通过对各部门业务系统数据库表进行分析，并生成数据普查报告；s2，根据各业务系统特点及数据库版本，通过etl工具对各个业务系统进行etl (extract-transform-load)任务配置；s3，将配置好的任务通过大数据平台进行注册、治理、调度操作。
26.在步骤s1中，所述数据库表分析步骤为：首先整理现有各部门业务系统数据库表结构，然后分析各业务系统字段之间的关联关系和真实的字段含义。
27.所述大数据平台包括数据治理平台、任务调度平台。
28.在步骤s2中，所述etl工具用于对各业务系统数据进行采集，并将各个元数据与数据进行耦合，可以有效获取到任意一个数据归属于那个字段、那个表、那个库，并将采集完成的元数据和数据通过所述数据治理平台对元数据进行管理。
29.所述数据治理平台对元数据进行管理的实现方式为：通过微服务方式对采集元数据进行数据关联，并将生成的关联关系直接写入到janusgraph库。血缘关系图如图2，如将人社业务系统(yw_rs)下面的业务库(yw_ku)中的用户表(user)中的姓名(name)形成关联关系yw_re-ye_ku-user-name。
30.通过元数据血缘关系，重建了整个元数据家族的构建过程，刻画了家族成员彼此连接的脉络和途径。当某数据出现错误或者异常时，可通过向上分析锁定问题产生的源头；当对某些数据进行修改时，可通过向下分析，得到哪些数据实体中的数据会受到影响。还通过提供列级的访问，将追踪的粒度精确到字段。
31.所述任务调度平台用于对数据治理平台治理完成的数据进行数据仓库分层构建综合库或专题数据库。
32.所述任务调度平台在对数据进行调度过程中，数据流向通过日志记录的方式将数据最终流向更新到janusgraph库。如数据从ods(原始数据)到dwd(明细数据层)到dws (服务数据层)到最后专题库或ads(数据应用层)，特别说明在流转过程中只需记录数据到综合
库或专题库的位置，无需记录中间流程。如上述人社系统的血缘关系就是 yw_re-ye_ku-user-name-ads_zh_ku(人社业务系统(yw_rs)下面的业务库(yw_ku)中的用户表(user)中的姓名(name)形成综合人口库(ads_zh_ku))。
33.在步骤s3中，所述大数据平台包括还包括运维监控平台，用于实时监控任务采集情况。
34.前期数据普查，对采集的业务系统进行全面深刻的理解，对该业务系统数据库、字段、属性有清晰的普查报告。
35.采用的etl工具支持多类型关系或非关系数据库的采集，可进行多链路采集，能保证断点续传，不仅能对元数据进行采集也支持对数据的采集，且采集过程不需要复杂治理过程。
36.搭建数据任务调度平台及运维监控平台，对整个任务链条进行数据调度和运维管控等。
37.数据治理平台能对数据建立统一标准，检核数据质量，准确描述数据元属性，分析数据之间关联关系，形成数据资源目录，实现数据快速检索，和对数据全生命周期进行管理。
38.元数据追溯关系深度越大，本方法的优势越明显。在政务元数据管理应用过程中，数据的深度能够反映数据的价值，而处理数据深度也是构建元数据模型的基础。本文基于janusgraph图形数据库，实现了对元数据的设计管理，能够成功追溯到源头业务系统数据，并且以图形的方式展示元数据之间的关系，展示效果更加直观、清晰。
39.实施例2在实施例1的基础上，请参阅图3所示，所述日志组件包括系统日志、错误日志、中间表日志，所述系统日志用于记录对数据源和数据仓库的操作，系统日志记录的内容包括当前用户、系统时间、所做的操作以及用户总数目；所述错误日志用于在流程错误点产生时记录错误信息，错误日志可以帮助业务开发人员调试；所述中间表日志用于记录系统对数据转移过程中组建的创建信息、系统运行时间和运行周期以及在数据转换时程序的流程情况。显示数据是怎样从源数据库中抽取出来装载到目标数据库中的。
40.所述etl工具的工作方式是通过先抽取再装载最后在系统仓库中进行数据转换的方式实现。即数据转换在数据装载之后。传统etl工具有几个缺点，1，性能问题，etl过程的数据转换步骤显然是三个步骤中运算最多的一步，传统的etl方法转换步骤完全由etl 在专门的服务器上运行。etl工具逐条的对数据进行转换或者是质量检测，这很容易使转换流程变成整个etl过程的瓶颈。此外，数据在源、目的和工具之间转递也增加了网络通信量并导致附加运行问题。例如这样的一个etl流程：数据从数据库端源表抽取出来，并且需要从数据仓库的某参照表中选择一些数据来完善自身，然后装载到数据仓库目的表中。传统的etl工具一般采取如下几种方式完成该流程：a.在内存中加载仓库端参照表；整个参照表从数据仓库中检索出来并载入中央引擎内存中。然后再在引擎内存中完成源表抽取数据的重组(转化)，最后装载到数据仓库的目的表中。如果参照表很大，运行时要求大量内存和很长时间来加载并对引擎中的数据重编索引。b.一行行地检索参照表；对于每一次抽取etl工具去查询数据仓库的参照表。查询返回一个匹配源数据的单独行。如果源表有1000万行，etl引擎就要发送1000万个查询。这将显著减慢etl过程并显著增加数据仓库的额外开销。对于
大型商业数据集成来说几乎不可能完成。显然这两种方式都是低效的，由此可见传统的etl方法在性能上存在一定缺陷。2，费用问题：一般来说，实施etl过程的费用将通过节省劳动力得以补偿。在etl过程的roi(return oninvestment)分析中，必须考虑到额外的和潜在的花销。最明显的花费是购买专用服务器和etl引擎软件。由于etl引擎是一种中间级组件,执行大量的预算,因此需要一个强大的服务器,甚至是服务器集群来满足高强度的运算要求。随着数据仓库的规模增大,etl服务器还需要在运行期间还有不断的硬件和软件维护升级费用。此外,传统的etl工具还有许多潜在的花费,包括部署、调试所需要的咨询开支及集成需求变化时的代码重写费用。而本发明设计的数据转移体系结构与传统的过程不同之处就是数据转换在数据装载之后；把数据转移放在加载之后,这样就弥补了传统etl工具的几个缺点。如图3所示，先抽取再装载最后在系统仓库中通过进行数据转换，在装载时或装载后可以利用pl/sql语言编写转换函数或者是触发器完成数据的转换。这种数据转移并不是简单的将数据源完全复制到数据仓库端，而在数据仓库端建立数据源的镜像。对于跨平台的大型数据库，可以通过tcp/ip协议进行跨平台访问，因为大型数据库(如db2等)都提供了数据服务的ip地址和对应的端口, 可以通过ip和端口得到服务.然后通过加用户名和密码的方式增加安全级别,来对数据库进行访问。
41.以上所述仅为本发明的优选实施方式而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化；凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。