数据的前世今生：走进元数据分析

转载本文请注明出处：微信公众号EAWorld

前言

伴随中国企业数字化转型大提速，2020年5月13日下午，国家发展改革委官网发布“数字化转型伙伴行动”倡议，正式把数字化转型提到国家政策层面。发展数字化转型就避免不了要和数据打交道，数据治理的核心是元数据管理。元数据驱动数字化转型成为趋势，而随着业务系统体量逐渐扩大，对元数据管理、分析提出了新的挑战。及时性、可靠性、可视化等等方面提出了新的要求。

元数据分析做什么

首先需要探讨的是什么的问题。元数据分析实践需要做什么？

元数据分析可以做的事情有很多，比如：

1.统计分析，针对整合而来的元数据，提供跨系统、跨BI工具的统计数据。例如：A系统下的表数目统计信息；在一段时间内的表变更情况统计信息；表的使用情况统计等等

2.特征分析，针对整合而来的元数据，进行特征抽取。例如：表的特征信息可以包括总字段数、主键字段数、数值型字段数等等

3.血统分析，针对整合而来的元数据，进行溯源分析，进行以数据流向为主线的血缘追溯。

4.影响分析，针对整合而来的元数据，数据变化会对下游数据产生哪些影响，影响有多大。

为什么需要做元数据分析

通过元数据分析帮助我们识别元数据价值，提升企业数据可信度，为企业的数据融合提供质量保证，帮助业务部门和IT支撑部门实现信息共享、提升工作效率。

普元的元数据分析实践

①普元在XX物流公司的实践

实践背景：

•公司的数据集成依托于PowerCenter；

•数据服务提供依靠大量的存储过程以及视图完成其复杂的业务信息需求；

现实问题：

对数据服务的维护需要同时维护成百上千的PC模型文件以及存储过程。当数据服务出现变更需求或者出现数据质量问题维护的同时需要人工查阅文件，重新梳理数据流转过程，极大的影响了办公效率以及办公质量。

解决方案：

•实现对PowerCenter、以及存储过程、视图元数据采集

•实现PowerCenter、以及存储过程、视图元数据的自动关联，形成血缘脉络

普元元数据系统支持常见的关系型数据库（Mysql、Oracle、SqlServer以及国产数据库达梦、金仓、OceanBase），非关系型数据库、报表文件、ETL文件等元数据采集。通过不同的采集适配器将处于不同业务层次、不同环境下的数据进行抽取转化，形成符合CWM元模型规范的元数据集合。打破原有各IT系统，BI工具集数据模型、ETL工具数据模型等元数据各自隔离的现状。

数据间的依赖关系表现形式通过我们长期的实践，归纳为两种SQL以及Mapping映射。

在实现数据融合、数据转换的过程中，我们可以通过书写存储过程或者一系列的查询语句，也可以借助ETL、BI等工具实现数据端到端的传输和展现。我们的数据流向、依赖关系就存在于这个过程中。

存储过程不用多说自然是查询语句的一种，而在ETL、BI工具中我们看似没有或者很少有查询语句的出现，其实揭开它们的面纱，也只是将各种查询语句用另外一种形式做了一种包装，我们在这里就把他认定为是一种mapping映射，只不过这种映射对用户或者技术人员来看是更加通俗易懂的。这种映射关系显著的标明了源端、目标端的数据映射详情。从模型文件中抽取出这些映射关系就形成了对ETL、BI数据模型的依赖分析，这个在我们的实践过程中是较为简单的。而查询语句的依赖关系转化在我们的实践过程中向我们提出了挑战。

下面就说说我们在存储过程的依赖分析中遇到了哪些问题。

1.查询语句结构复杂

a.数据字段依赖于不同阶段的查询结果，比如游标查询与更新操作的结合使用

b.多级子查询嵌套查询，语义追溯问题

c.各种函数的混合使用，比如DECODE函数、CASE函数带来的分支选择，要进行非关联字段过滤，提高依赖关系的准确性

等等

2.查询语句语义模糊，比如select * 的嵌套使用；多表嵌套查询时，字段别名交叉使用；涉及UNION查询时，字段所属指示不明的问题

3.数据库版本引入新的关键字、函数等

4.查询语句上下文关联问题，比如存储过程是由一系列单条语句组合而成，具有上下文关联关系

针对以上问题我们做了如下努力解决问题：

1.词法、语法分析能力提升

数据库的迭代发展引入了新的关键字、方法、符号。我们完善了基于JavaCC和Antlr开发的词法分析器，以及语法解释器，提升词法、语法分析能力。

2.重构现有的分析模型

采取分而治之的思想，将复杂的查询语句以select查询为基础单元构建基于语法树的解释分析模型。

3.标注法和反向查询法理念的结合使用

在分析模型中我们采用标注的概念记录数据流转的层级顺序，在完成全部查询语句的结构分析时，反向递归查找所关联的数据源头。

基于企业数据整体的依赖关系，我们借助eCharts、GoJs等前端技术，将数据的流转方式进行可视化展示，摸清数据的来龙去脉。

这里我们列举一个最简单链路关系图，如图所示，数据共享层的表employee的数据来源于上游资产系统中的as_employee以及as_employee1，而employee的数据又通过一定的业务转换到达下游系统报表系统的rep_employee以及风控系统中的rks_employee表中。

以表为分析入口，进行全链分析展示，展示效果如图

在转换关系连线上双击下钻可以查看具体的转换过程，可以看到转化过程经历了源表的字段选择、通过记录的合并和选择最终到达目标表中。

在表级层次上展开还可以看到相关的字段的转换关系。

除了从表的维度去查看表结构的链路图，我们还可以直接查找相关字段，获取字段的转换关系。

以关注对象为节点我们向上寻亲，查看数据的血缘关系。血统分析让我们对企业数据来源可追溯，提升数据信息可信度，为企业数据的合规性提供验证手段。

向下延伸，查看数据的影响范围。影响分析提供基于数据流影响分析能力，快速识别元数据价值，掌握元数据变更可能造成的影响，为评估变更变化风险提供有效帮助，帮助用户高效准确的对数据资产进行清理、维护和使用。

以上场景分析是建立在企业各系统之间元数据是有关联的，如果一个企业中各个系统之间的元数据互相孤立，无法直接获取数据之间的关系怎么办呢？这就要说说我们的另一个探索方案

②普元在XX航空公司的实践

实践背景：

企业希望打通公司各部门业务壁垒，实现数据互通，统一管理，提升办公效率

现实问题：

公司各部门相互较为独立，但业务上却不完全独立。各部门对重叠的业务需求数据各自维护，发生数据变动的同时需要多部门协调联动修改。

解决方案：

汇总业务元数据，梳理数据特征，探索数据之间关系

我们针对这种场景提供基于元数据相似度分析的探查能力，从元数据特征出发，梳理数据特征、制定分析因子、分析规则，探查元数据之间存在的潜在关系，从而帮助企业打破数据孤岛现象。

结合企业业务范围，梳理元数据特征，根据数据特征描述数据含义，制定贴合业务的元数据相似度分析因子。我们提供了可扩展开发的接口，实现对相似度分析因子的计算逻辑，通过将一定的分析因子以不同的权重进行组合形成相似度分析规则，进一步将规则应用于对应的业务系统元数据，由元数据探索引擎实现元数据相似度的自动探查。

元数据探查、相似度分析系统架构：