大数据治理中基于元数据和数据分析技术实现系统数据架构
梳理的方法
技术领域
本发明涉及计算机软件领域,尤其涉及大数据治理领域,具体是指一种大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法。
背景技术
随着大数据技术的快速发展,越来越多的企业开始将数据视为资产进行管理,更有不少企业在数据资产的基础上实现了数据运营,而要具备这些能力,企业对系统的数据架构需要有一个全面认识,例如:在系统的各种数据中,哪些是基础数据、哪些是核心数据、系统的数据主题有哪些、系统能够对外提供哪些数据等等,而企业的系统建设并不统一,往往由不同供应商采用不同技术架构在不同时期建成,企业对系统本身的数据情况并不完全掌握,因此想从全局出发进行数据架构梳理是非常不易的,当前市场上一般采用元数据技术盘点系统数据结构,再与业务专家进行调研,梳理数据架构,但由于元数据本身太技术化,缺少对业务的理解,而业务专家又大多不了解技术实现并且业务能力无法准确衡量,调研效果也有好有坏,往往费时、费力梳理之后得到的结果却差强人意,数据主题也因此变成“空中楼阁”,难以落地,因此,企业需要一个上手难度小、人员要求低、过程标准化,并且得到的结果准确、有效,具备较高可落地性的系统数据架构梳理方法。
现有元数据相关技术如下:
一种基于元数据链路的数据追踪方法及系统(申请号:CN201910095599.4),其提供了一种基于元数据链路的数据追踪方法,包括:收集数据传输日志;根据数据传输日志生成字段级元数据链路;根据上传的查询条件,追踪到与查询条件匹配的字段级元数据链路;对字段级元数据链路进行可视化处理以生成图形界面。本发明还公开了一种基于元数据链路的数据追踪系统,包括收集模块,用于收集数据传输日志;生成模块,用于生成字段级元数据链路;追踪模块,用于根据上传的查询条件追踪与查询条件相匹配的字段级元数据链路;可视化模块,用于对字段级元数据链路进行可视化处理以生成图形界面。采用本发明,通过字段级元数据链路,能够快速追踪到具体的数据。
通过上述一种基于元数据链路的数据追踪方法及系统技术,包括:通过收集数据传输日志,进一步生成字段级元数据链路,并可视化显示,通过元数据链路,追踪到具体的数据。通过获取模块能够获取到整个数据链路中每个流转节点的数据值,通过比较模块比较整个数据链路中每个流转节点的数据值,定位出有问题的流转节点及其数据值。通过范围判断模块,在定位出问题流转节点后,通过数据链路追踪,能够判断出哪些流转节点会受影响,哪些数据链路会受影响,从而发现问题,补救问题。通过质量反馈模块,对数据质量情况反馈,能够获悉数据传输过程中数据质量的变化,从而实现对整条数据链路的数据质量进行监控。该技术从元数据视角出发,通过技术手段追踪数据链路,但却缺少对业务的理解,更多作用在于事后快速定位问题,并不擅长梳理系统的数据架构,无法分析出系统中涉及的数据主题和系统能提供的数据能力。
发明内容
本发明的目的是克服了上述现有技术的缺点,提供了一种满足有效性高、分析能力强、适用范围较为广泛的大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法。
为了实现上述目的,本发明的大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法如下:
该大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法,其主要特点是,所述的方法包括以下步骤:
(1)系统信息录入,记录系统基本情况;
(2)通过标准元数据采集工具采集技术元数据;
(3)通过模拟系统业务场景采集系统中的数据流向,从系统的业务场景为源点采集业务元数据;
(4)通过业务元数据的关联分析元数据链路;
(5)识别业务元数据与技术元数据的业务含义;
(6)通过对不同维度元数据进行聚类、汇总、统计排序的分析策略,分析数据能力、数据全景和数据热度。
较佳地,所述的步骤(1)的系统基本情况包括系统名称、系统编码、系统供应商、系统版本号、上线时间、数据库信息、业务特性、菜单信息和功能信息。
较佳地,所述的步骤(2)的采集技术元数据包含客户端和服务端两部分,客户端与应用系统数据库适配并采集数据,服务端对数据进行整合及可视化展现,描述数据库之间、表之间以及字段之间的关联关系。
较佳地,所述的步骤(3)中业务元数据的采集范围包括业务特性、菜单、功能、API、界面、表单、请求、SQL、表和字段。
较佳地,所述的步骤(4)具体包括以下步骤:
(4.1)对重复或相似的业务元数据进行合并;
(4.2)形成业务元数据的血缘分析、影响分析、全链分析。
较佳地,所述的步骤(4.2)具体为:
通过数据之间的关联性,对业务元数据进行链路分析,以掌握数据的影响程度,形成业务元数据的血缘分析、影响分析、全链分析。
较佳地,所述的步骤(5)具体包括以下步骤:
(5.1)将采集到的业务元数据与技术元数据充分结合,快速识别数据的业务含义;
(5.2)业务元数据与技术元数据通过表进行关联,并根据业务元数据中获取到的功能、界面、表单、请求、SQL和表之间的关联关系识别字段的业务含义,并回写至技术元数据中的字段内。
较佳地,所述的步骤(6)中的分析数据能力的步骤具体包括以下处理过程:
通过对业务元数据中的功能和表单,以及技术元数据中的表和字段进行聚类分析。
较佳地,所述的步骤(6)中的分析数据能力的步骤具体包括以下处理过程:
通过对元数据链路的汇总计算,展示系统中所有表之间的关联关系,形成系统数据全景图。
较佳地,所述的步骤(6)中的分析数据热度的步骤具体包括以下处理过程:
通过对系统中表的被关联的次数进行统计排序,找出被关联次数较多的表,将其作为系统的核心数据。
采用了本发明的大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法,通过自上而下的采集业务元数据,自下而上的采集技术元数据,最终达到“技术”与“业务”融合的效果,使得梳理系统数据结构的工作从一个需要业务专家支持的高门槛、高成本、高难度工作转变为一个仅需技术人员参与的标准化梳理工作,并且由于对系统功能的全覆盖采集,数据的真实性、有效性得以保障,以此为参考梳理出的数据主题有更高的准确性且可落地性强,通过本发明,为企业在大数据治理领域,提供有力支撑,具有很好的推广应用价值。
附图说明
图1为本发明的大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法的流程示意图。
图2为本发明的大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法的业务元数据链路示意图。
图3为本发明的大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法的完整元数据模型示意图。
图4为本发明的大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法的数据架构梳理平台功能架构图。
图5为本发明的大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法的核心表之间的关系示意图。
图6为本发明的大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法的业务元数据合并过程示意图。
具体实施方式
为了能够更清楚地描述本发明的技术内容,下面结合具体实施例来进行进一步的描述。
本发明的该大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法,其中包括以下步骤:
(1)系统信息录入,记录系统基本情况;
(2)通过标准元数据采集工具采集技术元数据;
(3)通过模拟系统业务场景采集系统中的数据流向,从系统的业务场景为源点采集业务元数据;
(4)通过业务元数据的关联分析元数据链路;
(4.1)对重复或相似的业务元数据进行合并;
(4.2)形成业务元数据的血缘分析、影响分析、全链分析;
(5)识别业务元数据与技术元数据的业务含义;
(5.1)将采集到的业务元数据与技术元数据充分结合,快速识别数据的业务含义;
(5.2)业务元数据与技术元数据通过表进行关联,并根据业务元数据中获取到的功能、界面、表单、请求、SQL和表之间的关联关系识别字段的业务含义,并回写至技术元数据中的字段内;
(6)通过对不同维度元数据进行聚类、汇总、统计排序的分析策略,分析数据能力、数据全景和数据热度。
作为本发明的优选实施方式,所述的步骤(1)的系统基本情况包括系统名称、系统编码、系统供应商、系统版本号、上线时间、数据库信息、业务特性、菜单信息和功能信息。
作为本发明的优选实施方式,所述的步骤(2)的采集技术元数据包含客户端和服务端两部分,客户端与应用系统数据库适配并采集数据,服务端对数据进行整合及可视化展现,描述数据库之间、表之间以及字段之间的关联关系。
作为本发明的优选实施方式,所述的步骤(3)中业务元数据的采集范围包括业务特性、菜单、功能、API、界面、表单、请求、SQL、表和字段。
作为本发明的优选实施方式,所述的步骤(4.2)具体为:
通过数据之间的关联性,对业务元数据进行链路分析,以掌握数据的影响程度,形成业务元数据的血缘分析、影响分析、全链分析。
作为本发明的优选实施方式,所述的步骤(6)中的分析数据能力的步骤具体包括以下处理过程:
通过对业务元数据中的功能和表单,以及技术元数据中的表和字段进行聚类分析。
作为本发明的优选实施方式,所述的步骤(6)中的分析数据能力的步骤具体包括以下处理过程:
通过对元数据链路的汇总计算,展示系统中所有表之间的关联关系,形成系统数据全景图。
作为本发明的优选实施方式,所述的步骤(6)中的分析数据热度的步骤具体包括以下处理过程:
通过对系统中表的被关联的次数进行统计排序,找出被关联次数较多的表,将其作为系统的核心数据。
本发明的具体实施方式中,公开了一种在大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法,本方法从系统业务特性出发,基于元数据思想,将业务过程视为业务元数据,系统数据库表结构视为技术元数据,通过系统信息录入、技术元数据采集、业务元数据采集、元数据链路分析、元数据业务识别、数据架构分析六个步骤,以标准化的方式,简单、快速、有效的梳理系统数据逻辑,形成系统数据全景,打通数据从业务形态到技术形态的连接,从全局了解系统数据架构。利用本发明,可以帮助企业更加清晰的了解系统数据含义,快速梳理出系统的基础数据和核心数据,从而掌握系统的数据架构,为企业在大数据治理领域,提供有力支撑,具有很好的推广应用价值。
本发明涉及计算机软件领域,特别涉及大数据治理领域,具体是指一种在大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法。
本发明针对上述背景技术中存在的问题,提出了“技术”与“业务”两种元数据概念,通过自上而下的采集业务元数据,自下而上的采集技术元数据,最终达到“技术”与“业务”融合的效果,从系统业务特性出发,利用元数据和数据分析技术,通过系统信息录入、技术元数据采集、业务元数据采集、元数据链路分析、元数据业务识别、数据架构分析六个步骤,快速识别系统数据逻辑,还原系统数据全景,打通数据从业务形态到技术形态的转变,从全局了解系统的数据架构。
本发明的目的在于提供一种在大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法,将业务过程视为业务元数据,系统数据库表结构视为技术元数据,通过系统信息录入,收集系统基本情况,通过技术元数据采集,盘点系统数据结构,通过应用元数据采集,梳理出系统的数据使用链路,通过对元数据的业务识别,了解数据真实含义,通过对数据链路的汇总,了解系统数据全貌,通过对数据的聚类分析,提取出系统的主要数据能力,从而实现对系统数据架构的完整梳理,具体操作步骤如图1所示。
步骤1、系统信息录入:本步骤目的在于记录系统基本情况,用以支撑应用系统在不断更新升级中,梳理工作也能够迭代更新,是后续工作的重要输入项,系统基本情况包括但不限于:
系统名称、系统编码、系统供应商、系统版本号、上线时间、数据库信息、业务特性、菜单信息、功能信息。
步骤2、技术元数据采集:本步骤目的在于从技术角度盘点系统相关的数据结构,可使用标准元数据采集工具,技术元数据采集整体上可分客户端与服务端两部分,客户端负责与应用系统数据库的适配,采集数据,服务端负责对数据进行整合并可视化展现,描述数据库之间、表之间、字段之间的关联关系。
元数据模型包含但不限于:
元数据代码:元数据的唯一标识。
元数据名称:元数据的中文名称。
元数据类型:元数据存在不同层次中,具有多种类型。
元数据路径:描述了元数据的上游路径。
元数据版本:元数据的版本说明。
生效时间:元数据生效时间。
元数据采集范围包含但不限于:
数据库信息:数据库类型、用户名、密码、连接方式等信息。
Schema:数据库实例信息。
数据表:数据库中实体表的信息,表名、描述等。
视图:视图名称、SQL语句等信息。
ETL过程:对数据表清洗、转换、加工的过程。
字段:字段名称、字段类型、精度、初始值、中文含义等。
索引:建立的索引信息。
主外键:主键信息、外键信息。
步骤3、业务元数据采集:本步骤目的在于通过模拟系统业务场景的方式,采集系统中的数据流向。从系统的业务场景为源点进行采集,业务元数据的采集范围包含但不限于:
业务特性:描述系统中一个完整的业务需求场景,比如一个完整操作流程,一个独立模块等。
菜单:系统提供的菜单信息,一个业务特性一般包含多个菜单。
功能:菜单中提供的功能信息,一个菜单一般包含多个功能,如对某个数据的增、删、改、查。
API:系统对外提供的接口信息。
界面:菜单和功能对应的系统界面截图。
表单:功能对应的页面信息,如页面中的字段元素、使用的控件、数据选项等。
请求:表单提交后向系统后台发起的请求信息,一个表单中一般包含多种请求。
SQL:请求执行的SQL语句,一条请求一般包含多条SQL。
表:SQL语句中包含的表信息,一条SQL一般包含多张表。
字段:在表中执行的具体字段信息,一张表一般包含多个字段。
步骤4、元数据链路分析:本步骤目的在于通过业务元数据的关联,形成应用系统特性-菜单-功能-界面-表单-请求-SQL-表-字段之间的链路关系。包括:1、对重复或相似的业务元数据进行合并;2、形成业务元数据的血缘分析、影响分析、全链分析。
1、对重复或相似的业务元数据进行合并。
一般在系统实现中,系统的业务特性、菜单、功能、表单、请求、SQL、表之间会存在多对多关联的情况,比如在多个功能中可能会调用同一个请求或涉及同一张表,因此,需要将存在相同业务元数据的上下游元数据进行合并关联,使数据链路更具可读性及关联性,如图2所示。
2、形成业务元数据的血缘分析、影响分析、全链分析。
在业务元数据合并后,通过数据之间的关联性,对业务元数据进行链路分析,以便掌握数据的影响程度:
血缘分析:
描述了数据的上游链路,其具体思路是:以当前业务元数据为起点,向前追溯数据来源,目的是理清当前数据从哪里来,经过了怎么样的数据处理流程。
影响分析:
描述了如果当前数据发生变化,会影响到下游的哪些数据,其具体思路是:以当前业务元数据为起点,向后追溯数据流向,目的是理清当前数据到哪里去,经过了怎么样的数据处理流程。
全链分析:
描述了数据的“前世今生”,其具体思路是:以以当前业务元数据为中心,向前追溯数据来源,向后追溯数据流向,目的是理清当前数据从哪里来,到哪里去并且经过了怎么样的数据处理流程。
步骤5、元数据业务识别:本步骤目的在于将采集到的业务元数据与技术元数据充分结合,快速识别数据的业务含义。两类元数据通过表进行关联,并根据业务元数据中获取到的功能、界面、表单、请求、SQL、表之间的关联关系能够轻松识别出字段的业务含义,并回写到技术元数据中的字段内,从而使元数据兼备技术属性和业务属性。
业务识别后完整的元数据模型如图3所示。
步骤6、数据架构分析:本步骤作为梳理工作的最终成果,其目的在于通过对不同维度元数据进行聚类、汇总、统计排序等分析策略,梳理出系统的数据能力、数据全景、数据热度,从而掌握系统的数据架构。
(1)数据能力分析
通过对业务元数据中的功能、表单,和技术元数据中的表、字段进行聚类分析,了解系统的数据架构情况。
功能聚类:是对功能名称进行聚类分析,一般可视为系统的概念模型,为了解系统的数据主题提供参考。
表单聚类:是对表单中字段名进行聚类分析,为了解系统的数据分布情况提供参考。
表聚类:是对表名和表描述进行聚类分析,一般可视为系统的逻辑模型,为了解系统的数据架构提供参考。
字段聚类:是对数据库中表的字段名称和描述进行聚类分析,为了解系统拥有的数据能力提供参考。
(2)数据全景分析
通过对元数据链路的汇总计算,展示了系统中所有表之间的关联关系,形成系统数据全景图,便于直观了解系统数据的全局分布。并提供向下钻取能力,可以查看与某张表相关的其它表信息。
(3)数据热度分析
通过对系统中表的被关联的次数进行统计排序,找出被关联次数较多的表,一般可视为系统的核心数据。数据热度的统计维度可分为两种:1、功能数据热度,2、关联数据热度。
功能数据热度:按表被功能引用的次数进行倒序排序,排名靠前的表一般可视为系统的核心数据。
关联数据热度:按表被关联的次数进行倒序排序,排名靠前的表一般可视为系统的基础数据。
经过上述六个步骤,通过自上而下的采集业务元数据,自下而上的采集技术元数据,最终达到“技术”与“业务”融合的效果,使得梳理系统数据结构的工作从一个需要业务专家支持的高门槛、高成本、高难度工作转变为一个仅需技术人员参与的标准化梳理工作,并且由于对系统功能的全覆盖采集,数据的真实性、有效性得以保障,以此为参考梳理出的数据主题有更高的准确性且可落地性强,通过本发明,为企业在大数据治理领域,提供有力支撑,具有很好的推广应用价值。
下面结合附图,对本发明的技术方案进行具体说明:
本发明提供了一种在大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法,请参考附图1,是本发明的具体实施步骤。如图4所示为本实施例中使用的数据架构梳理平台功能架构。
1)系统监听器
部署在待采集的系统环境中,用来采集系统运行时产生的数据请求过程,包括:页面发起的请求、请求调用的SQL语句等,在本实施例中,监听器功能基于开源技术skywalking(见注释1)实现。
2)采集工具
部署在单独服务器中,用来模拟对系统的执行操作,用来采集系统的界面信息,包括:系统菜单信息、功能信息、界面截图、页面地址、数据字典项、表单元素等,在本实施例中,采集工具通过对系统页面的html、jsp、js等前端技术代码解析实现。
3)数据架构管理
部署在单独服务器中,提供数据架构梳理平台的核心管理能力,用来记录系统详细信息,实现对系统数据能力的梳理和查询,包括:系统名称、供应商、版本、数据库、系统业务特性、系统菜单、功能、API、界面、表单、请求、SQL、表、字段、操作文档等信息。
4)元数据管理
部署在单独服务器中,用来采集系统对应的数据库元数据信息,包括:数据源、schema、表名、表描述、字段名、字段描述、字段类型、视图、索引、主键、外键等信息,在本实施例中,元数据管理基于标准元数据采集工具完成。
5)数据汇集引擎
部署在“3)数据架构管理”同服务器中,用来对采集上来的业务元数据进行优化处理,并与技术元数据建立关联,形成数据全景链路图。
6)数据分析引擎
部署在“3)数据架构管理”同服务器中,用来对系统完整元数据进行聚类分析,并形成分词和索引,包括:功能聚类、表单聚类、表聚类、字段聚类等。在本实施例中,数据分析引擎基于开源技术solr(见注释2)实现。
具体实施步骤:
步骤1、系统信息录入:具体实施中,通过系统操作手册或系统设计说明书等资料,将系统信息录入到系统中,具体信息如下表所示:
步骤2、技术元数据采集:具体实施中,可通过元数据采集工具连接系统数据库方式进行采集表信息、字段信息,也可通过Excel模版方式,收集元数据信息以导入方式采集,本实施例中通过模版方式进行采集,采集模版如下:
1)表相关信息,其中深色部分为后续重点业务识别对象
| 数据库 |
表名 |
表中文名 |
表空间 |
描述 |
| META7 |
T_HARVEST_ADAPTER_MODE |
T_HARVEST_ADAPTER_MODE |
META7 |
元数据模型 |
| META7 |
COMP_GLOBAL_POLICY |
COMP_GLOBAL_POLICY |
META7 |
全局配置表 |
| META7 |
T_TASK_INSTANCE_DESC |
T_TASK_INSTANCE_DESC |
META7 |
任务实例描述 |
| META7 |
T_HARVEST_ADAPTER_MODE |
T_HARVEST_ADAPTER_MODE |
META7 |
元数据模型 |
| META7 |
COMP_GLOBAL_POLICY |
COMP_GLOBAL_POLICY |
META7 |
全局配置表 |
2)字段相关信息,其中深色部分为后续重点业务识别对象
步骤3、业务元数据采集:具体实施中,根据步骤1中所填的系统菜单顺序,通过采集工具进行系统操作,并收集操作对应的功能、界面、表单、请求、SQL、表的数据链路,本实施例中,各核心表关系如图5所示。
·菜单与功能为1:N关系,即1个菜单可能包含多个功能。
●界面与功能为1:N关系,即1个界面可能包含多个功能。
·功能与API接口为1:N关系,即1个功能可能开放多个接口。
●功能与表单为1:N关系,即1个功能可能包含多张表单。
·表单与请求为N:N关系,即1个表单可能调用多个请求,1个请求也可能被多个表单调用。
·请求与SQL为N:N关系,即1个请求可能执行多条SQL,1条SQL也可能被多个请求调用。
·SQL与实体表为N:N关系,即1条SQL可能执行多张表,1张表也可能被多条SQL执行。
·实体表与字段为1:N关系,即1张表对应多个字段。
步骤4、元数据链路分析:具体实施中,由于不同类型的元数据值各不相同,在做数据去重时相对繁琐,为了能够快速识别出重复元数据,并将链路合并,在表设计时,对每张核心表采用统一添加一个【MDCODE】字段,该字段值将元数据本身NAME值通过MD5加密后存储,系统通过统一长度、统一格式的【MDCODE】字段进行比较,将相同值的元数据进行合并,如图6所示。
元数据合并后,再通过对数据的链路关系进行正向追踪、反向追踪,形成对该数据的全链分析、影响分析、血缘分析,以SQL元数据为例,SQL的正向是追踪表的链路,代码片段如下:
SQL的反向是追踪请求或者API的链路,代码片段如下:
步骤5、元数据业务识别:具体实施中,根据功能对应的界面、表单的元素信息以及执行的SQL语句,可以直观的了解到该页面对应的表和字段中的业务含义,比如在表单user_list.jsp中有如下元素:
通过表单调用的请求到SQL最终找到相关的CAP_USER表,根据表单中字段名称可快速推断出表中相关字段含义,如下表所示(深色部分为推断出的业务含义):
步骤6、数据架构分析:具体实施中,分别对系统数据的能力、全景分析、热度分析进行梳理,
1)数据能力分析
通过Solr技术,对功能、表单、表、字段进行聚类,可以提取该系统的数据能力标签,例如,对字段进行聚类,可以了解到该系统的整体数据情况,以本实施系统数据能力为例,聚类字段信息(部分)后,得到如下列表:
| 数据 |
元数据 |
对象 |
存储 |
名称 |
元模型 |
字段 |
| 28 |
25 |
22 |
17 |
12 |
9 |
9 |
| 类型 |
标签 |
角色 |
系统 |
视图 |
用户 |
分类 |
| 9 |
9 |
7 |
6 |
6 |
5 |
5 |
可知本系统主要提供的数据能力存在于数据、元数据、对象、元模型等主题中。
2)数据全景分析
通过对数据表的关联情况进行汇总,可得出该系统的所有表的业务关联关系,计算表关联的相关SQL语句为:
其中,pamc_function_ui为页面表
pamc_function_ui_sql_relation为页面与SQL关系表
pamc_sql为SQL表
pamc_sql_table_relation为SQL与实体表的关系表
pamc_datasource_table为业务元数据中实体表
pamc_table_from_meta_data为技术元数据中实体表
3)数据热度分析
通过对数据表分别在功能中、SQL中的关联频度进行统计分析,得到1.功能数据热度,2.关联数据热度,以功能数据热度为例,相关的SQL查询语句为:
其中,pamc_function_ui为页面表
pamc_function_ui_sql_relation为页面与SQL关系表
pamc_sql为SQL表
pamc_sql_table_relation为SQL与实体表的关系表
pamc_datasource_table为业务元数据中实体表
pamc_table_from_meta_data为技术元数据中实体表
查询的结果为:
| 数据库 |
表描述 |
表名 |
次数 |
| EOS76_1 |
用户表 |
cap_user |
23 |
| EOS76_1 |
员工表 |
org_employee |
22 |
| EOS76_1 |
机构表 |
org_organization |
20 |
| EOS76_1 |
功能表 |
app_function |
19 |
| EOS76_1 |
角色表 |
cap_role |
17 |
| EOS76_1 |
功能角色关系表 |
cap_resauth |
17 |
| EOS76_1 |
机构人员关系表 |
org_emporg |
17 |
| EOS76_1 |
岗位表 |
org_position |
14 |
| EOS76_1 |
人员角色关系表 |
cap_partyauth |
14 |
| EOS76_1 |
业务字典表 |
eos_dict_type |
13 |
| EOS76_1 |
业务字典明细表 |
eos_dict_entry |
12 |
| EOS76_1 |
菜单表 |
app_menu |
10 |
| EOS76_1 |
人员岗位关系表 |
org_empposition |
10 |
附:
注释1:
SkyWalking创建与2015年,提供分布式追踪功能。从5.x开始,项目进化为一个完成功能的Application Performance Management系统。
他被用于追踪、监控和诊断分布式系统,特别是使用微服务架构,云原生或容积技术。提供以下主要功能:
·分布式追踪和上下文传输
·应用、实例、服务性能指标分析
·根源分析
·应用拓扑分析
·应用和服务依赖分析
·慢服务检测
·性能优化
注释2:
Solr是一个独立的企业级搜索应用服务器,它对外提供类似于Web-service的API接口。用户可以通过http请求,向搜索引擎服务器提交一定格式的XML文件,生成索引;也可以通过Http Get操作提出查找请求,并得到XML格式的返回结果。
采用了本发明的大数据治理中基于元数据和数据分析技术实现系统数据架构梳理的方法,通过自上而下的采集业务元数据,自下而上的采集技术元数据,最终达到“技术”与“业务”融合的效果,使得梳理系统数据结构的工作从一个需要业务专家支持的高门槛、高成本、高难度工作转变为一个仅需技术人员参与的标准化梳理工作,并且由于对系统功能的全覆盖采集,数据的真实性、有效性得以保障,以此为参考梳理出的数据主题有更高的准确性且可落地性强,通过本发明,为企业在大数据治理领域,提供有力支撑,具有很好的推广应用价值。
在此说明书中,本发明已参照其特定的实施例作了描述。但是,很显然仍可以作出各种修改和变换而不背离本发明的精神和范围。因此,说明书和附图应被认为是说明性的而非限制性的。