转载本文需注明出处：微信公众号EAWorld，违者必究。


前言：


元数据应用中对数据关系的分析，是元数据的核心能力，基于这项核心能力能够衍生出对诸多实际应用场景的支持，例如辅助数据运维，数据风险管控等。大部分组织实施元数据管理也是出于这两点应用的考虑，主要的核心应用包括如下：
（1）通过元数据做到对数据资源台账的准确掌握。
（2）构建数据关系地图，形成对数据关系的把控。
（3）管理元数据变更，规避数据结构变更的风险。
当然基于元数据产品也能衍生出的数据标准管理、数据模型管理、数据安全管理甚至与数据价值评估的应用有很多。我们主要从元数据管理本身的价值出发来说。

目录：

1、数据地图关系定义与分类
2、数据流向关系分析的缺陷
3、切片分析提升分析准确性
4、区块链技术与数据地图结合
5、展望


1. 数据地图关系定义与分类



从数据地图关系来说，主流的元数据产品支持的是数据流向关系、数据模型关系两类。

数据流向关系：从数据传递和加工的角度，表示数据在系统内部或系统之间逻辑流向和逻辑变化的关系。

数据实体关系：数据实体之间的一对一，一对多，多对多的关系以及实体间的继承等关系。

数据实体关系的来源：数据模型的设计工具，具体有ERWin、PD以及ERArchitector等。采集的准确度较高，基本上采集到大部分的关系。

数据流向关系的来源：来源比较多，ETL工具、传统的Sql脚本为核心的存储过程、Shell脚本、Perl脚本以及大数据中应用的Spark sql、sqoop脚本等。关系解析比较复杂正确率有待提升。


有些厂商的元数据产品解析正确率较高，但通常是一种ETL工具深度绑定，并不适合做企业级的元数据关系方案。数据关系地图的构建依赖与强大的采集适配器。普元元数据产品提供的采集适配器能够覆盖企业大部分数据关系的采集。

2.数据流向关系分析的缺陷



当前元数据产品对数据流向关系的分析是逐层分析，例如 A、B、C元数据与D元数据有关系，D元数据与E、F、G元数据有关系，通过对A做影响分析的时候，我得出的是A—>D—>（E、F、G）而实际上数据流向关系是A->D->E，同理，我们对E进行血缘分析的时候，也会出现D的数据来源于A、B、C元数据。

举个实际的例子：这是指标管理模块中的实际数据流向。用颜色来区分数据流向，同一颜色代表了数据流动路径。





基于上图展示的事实，从某一指标进行溯源，通常情况下（基于元数据）的溯源分析，首先找到汇总表，再往前追溯时，往往是基于汇总表进行溯源，找到汇总表所有的来源表，分析呈现泛化，导致分析结果不够精确，缺乏指导意义，如下图所示：





这个问题会让使用元数据的人很纠结，数据明明没有流到这里，怎么分析出对后面有影响呢。我想要的效果应该是这样的：






那是不是现有的元数据分析没用用处了吗？从数据加工的角度想，还是有用处的，试想下如果A的数据结构发生了变化，删除了一个字段，80%的几率会影响到C表数据加工过程。

如何准确标注数据的的坐标，是将来元数据厂商要抢占的制高点。

3.切片分析提升分析准确性



切片分析就是利用数据加工处理的程序的逻辑（通常是Sql脚本中的where条件），将中间的物理的汇总表切分为几个逻辑表，分别从汇总表前切分及汇总后进行切分。汇总表前切分，建立明细数据表A与逻辑汇总表A（虚拟的）关系。汇总表后切分，建立逻辑汇总表A（虚拟的）与指标A之间的关系。

1、 汇总表前切片分析：

假如以下SQL是“明细数据A”到“指标汇总表”加工ETL

insert into C(c01, c02, c03)
select '100', T.t02, T.t03 from (
    select tt.a01 as t01, tt.a02 as t02, tt.a03 as t03 from A tt 
) T

以下SQL是“明细数据B”到“指标汇总表”加工ETL

insert into C(c01, c02, c03)
select '200', T.t02, T.t03 from (
    select tt.b01 as t01, tt.b02 as t02, tt.b03 as t03 from B tt 
) T  

通过Jsqlparese解析 Where条件中的逻辑，建立A与C100（物理表名称+kpid）关系，B与C200（物理表名称+kpid）的数据流向关系。
    
2、 汇总表后切片分析：

从指标汇总表进入单一的指标表的数据加工过程，也需要进行切片分析。通常进行加工的sql语句长这样的

insert into K(kpid, value1, value2)
select C.kpid, C.c01, C.c02 from (
    select tt.b01 as t01, tt.b02 as t02, tt.b03 as t03 from C tt where kid = 100 and name like '公司% '
) C

解析Insert、update语句中case when和where条件表达式，依照指标编号字段和指标值字段的配置信息，构建业务指标对象K100(物理表+kpi)，解析出业务指标表与虚拟汇总表C100（物理表+kpi）的依赖关系。

这种解决方案，能够从一定程度上提升分析结果的准确性。但是实现起来比较复杂，同时还需要部分的人工梳理切片字段工作。实施起来难度较大，且不具备通用性。 

4.区块链技术与数据地图结合


区块链技术的出现为数据流向的精细化分析提供了可以参考的依据。区块链是由一个个区块组成，区块就像数据库的记录，每次写入数据，就是创建一个区块，每个区块内包含了区块头和区块体。而区块头的里包含（上一区块的Hash、当前区块的Hash、当前时间等）。假设在企业中数据的加工、流转都带着这个区块头。标识数据从哪里来的，那么数据流向的问题就迎刃而解了。





5.展望



数据地图关系的精细化分析是数据管理要解决的一个难题，当前解决方案大都是通过自动化解析辅以人工处理的方式来提升正确性。需要定制、二次开发采集器的场景比较普遍，效果往往不够好。随着区块链、人工智能技术等新技术出现，实现全自动的数据流向关系精细化分析将要成为现实。


关于作者：川枫，普元云计算和大数据产品部架构师，主要负责普元大数据治理产品研发和项目实施，十年大型企业信息数据治理架构设计与建设经验，为多家大型金融机构、企业设计与规划数据管理整体框架和项目实施。数据行业有着深入的研究和洞察，并对企业信息化平台建设，数据治理及大数据平台建设有着丰富经验。



关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。长按二维码关注！