图数据库：一种解决元数据管理“两张皮”的方法！

这是傅一平的第293篇原创

作者：傅一平

个人微信：fuyipingmnb

我们在数据管理中碰到的一个很大挑战是如何端到端的评估数据对于应用的影响？

业界有很多的解决方案，很多元数据管理工具中的影响分析和溯源分析也是奔着这个去的，其可以通过图形化的方式清晰的展现数据的处理过程，如下图所示：

但能展现是一回事，能否应用是另一回事，所谓华而不实的问题，也就是元数据管理中的经典问题：两张皮问题，这里至少存在两个问题：

首先是灵活性问题。

实践中，我们很少会用这种图形化的方式去处理问题，因为我们具体核查问题时要的其实是定制化的关系路径，而不是将所有关系进行呈现，否则，展现的这些其他关系往往就成了分析问题的噪声，而且即使是有关系也有强弱之分，在数据资产表动辄几千上万的情况下，用这种图形化的方式去处理某个具体问题几乎是不可能的。

因此，在很多企业购买的元数据管理软件中，这种好看的展示往往并不实用，特别是对于运维人员来讲，他需要的是针对特定问题的灵活的关系路径的定义和核查，而不是不分主次的全局呈现，这种分析方式对于展示体验的要求太高了。

其次是长流程问题。

元数据管理管的是数据，一般它的流程管理针对的往往是数据处理流程，但一个数据跟应用的关系，在流程上，不仅仅跟数据本身的处理有关，也跟数据采集、数据导出、数据到主机、数据库甚至是其他的平台各个节点都有关系。

以前我们往往站在内部的视角看元数据管理，反正就是表-脚本-表-脚本，但从解决问题的角度看，我们往往要从外部视觉看，从影响程度看，比如假如一张表变动了，我们首先要评估的是对于重要应用的影响，而不是对其他表和脚本的影响。

比如某个机房的某集群要断电，领导让我们评估下哪些表有影响，这些表会影响哪些变现应用，我们的运维人员往往只能做大致评估，根本无法在很短的时间内梳理清楚这些表到底会影响哪些重要应用，应用越多，就越梳理不清楚，最后就是凭经验，拍脑袋。

究其原因，还是因为从数据表到应用，它经历的实际是个长流程，横跨的首先是不同的平台，系统，数据库等等实体，然后才是实体内部的数据处理，它的复杂性远超简单的数据处理过程。

因此，传统的元数据管理中的流程分析是解决不了很多的数据运维问题的，运维人员在实践中大多还是要靠经验去进行数据问题的判断，好在大多数数据问题都是单点问题，比如某张表的数据有异常，马上凭经验就可以去判断要么是调度、要么是源头、要么是依赖出了问题，很少涉及长流程的核查。

但一旦某个应用的数据表出了问题，这个核查的复杂度就高了很多，特别是要评估某个重大事件的重大影响，或者要做一些重大的数据优化，轮到你去做一些重大数据决策的时候，基本大多数时候我们是缺乏决策依据的，这是大数据运维的痛点。

那么，怎么办？

最近我们在优化大数据运维体系，发现当引入图数据库方案后，很多问题是可以得到很好解决的，这里做一分享，也希望有经验的同仁能给予指导：

1、图数据库的特点

图数据库名字的由来其实与其在底层的存储方式有关，Neo4j底层会以图的方式把用户定义的节点以及关系存储起来，通过这种方式，可是高效的实现从某个节点开始，通过节点与节点间关系，找出两个节点间的联系。

从这段描述中可以猜得到，在Neo4j中最重要的两个元素就是节点和关系。说到节点和关系，就必须引出一个非常重要的概念，属性图模型(Property Graph Model)。如下所示:

如果你要存储的业务逻辑是以节点和关系为核心的，图数据库就具有极大的优势，其不仅能够很直观表达节点及节点间的关系，而且能够快速灵活的进行关系的查询，而元数据中的血统分析、影响分析等等，恰恰满足这个特点，比如从脚本生成表，再针对表进行脚本处理，如此循环，用图数据库非常容易表达。

2、图数据库纳管元数据的方法

我们的目标是实现数据到应用的全流程影响分析和溯源分析，基于图数据库来实现需要以下几个关键步骤：

首先，我们要定义清楚涉及的节点类型，包括表、作业、接口、标签、文件、平台、产品、数据库、中间件、主机等等，同步构建关系矩阵，如下图所示：

比如定义出表跟各种节点的关系，包括作业会使用表，接口会调用表，标签会使用表，数据库会存储表等等。

又比如定义出作业与各种节点的关系，包括作业会生成表，作业会触发作业，作业会生成文件，作业属于某个平台等等。

其次，这些节点与平台的关系矩阵也要梳理清楚，比如任何一个作业与运行平台的关系，如下所示：

最后，还需要定义清楚每个节点的属性，如下示例：

整个定义和梳理的过程是非常耗时的，如果企业有较好的元数据管理基础，则比较方便，比如我们就从DACP中直接导出了表和作业的定义和关系，以下示例了一阶段梳理的成果。

3、基于图数据库的元数据应用

首先，图数据库具有快速数据查询能力，任何一个节点的关系查询变得非常简单，展示也很清晰，如下示例：

你输入要查询的某个节点“咪咕音乐-表”，则相关的上下游关系都会清晰的展现出来，比如上游来自于蓝色的节点“咪咕音乐-数据库”，下游的绿色节点是“应用产品”。

其次，从数据采集到应用(XX应用)的完整流程可以通过简单编程完美呈现，语句如下:match(p:Partner) where p.name='XX应用' return p，结果展示如下：

每个节点都是可以展开和收缩的，这才是让运维人员看得懂，可操作的元数据分析平台，灵活性非常高。

最后，基于图数据库的语言还可以进行灵活的高阶数据分析，如基于Pagerank算法对表和作业的重要程度进行打分，从而决定运维处理的优先级，这样元数据的价值就真正发挥出来了，以下是个简单示例：统计出未被引用的融合模型表清单。

4、机制和流程的建立

跟元数据一样，图数据库的节点信息录入的前向控制是最为关键的，你必须建立元数据变更的协同机制，确保信息纳管不留死角，比如上线变更的控制等等，否则这个系统就会逐渐失去价值，这对数据管理的组织、流程和机制提出了最大的挑战，关于具体实施的方法笔者以前在数据管理相关文章中已经有所阐述，这里就不再累述了。

当然图数据库最大的应用之一还不在元数据，而在于社交网络的分析能力，下面是一个网上的测试案例：在一个社交网络里找到最大深度为5的朋友的朋友。

假设随机选择两个人，是否存在一条路径，使得关联他们的关系长度最多为5，对于一个包含100万人，每人约有50个朋友的社交网络， 图数据库与关系型数据库执行时间对比如下：

我们也在进行测试，假如你对6000万用户进行六度社交网络分析，关系型数据库是跑不出来的，而强悍的图数据库可以，有机会再与大家分享。

完

作者：傅一平 （微信号：fuyipingmnb）

---

可能错过的近期精选文章（点击链接即可阅读）

---

一起成长，让我们与数据同行

忙完工作，偷得浮生半日闲，讲述自己的数据人生

大叔/电信博士/500强央企/大数据/人工智能/统计取数/数据挖掘/数据产品/数据管理/数据仓库/数据变现