从三个场景看如何玩转元数据应用

之前的元数据系列文章（《90后美女程序员：元数据什么鬼？》、《轻松理解元数据，只需懂点心理学》......）让我们了解到，元数据的概念已经充分体现在企业数据建设的方方面面。很多企业也意识到了元数据重要性，并购买了元数据系统，但系统如何发挥价值，是需要考虑的问题。元数据到底应该管理哪些数据？分析哪些环节？看似抽象的系统的功能在企业IT、数据建设中有哪些应用场景？下面我们举三个例子让你更形象地理解元数据在业务中的作用。

场景一：元数据对比分析——让系统上线/变更高效、可控

在企业IT运维上线的时，我们有没有碰到过以下场景？

系统上线的Deadline临近了，BUG还没改完，需求还在天天变。程序员每天还在加班加点的写代码，脑子已经昏昏沉沉了。系统上线的前几天，各位程序员同学提交代码。经过从测试环境中简单测试后，打包最后一个上线版本提交给上线运维部门。

上线的那一天晚上项目经理心里没底啊，程序员都想早点回家，项目经理要求同学们再坚持一晚上，“您回去了，万一有问题我去找谁呢”项目经理说到。

上线开始了，运维人员给配置好操作权限，程序员开始按照上线操作步骤进行上线操作。一开始操作建表语句还很顺利，导入初始化数据时候发现报错。

一问程序员发现，最后提交程序上线脚本的时候，测试库的模型建表语句与生产库提交的版本不一致，提交上线包的时候是程序员疏漏了。怎么办？

运维管理人员与整个项目组的气氛都不好了。只有一个字“改”。表那么多怎么改？重新从测试环境传一个上线包到生产环境还要走审批流程。我们试想一下后面的场景，谁也别想早回家了，此处省略一万字……

类似上面的场景还很多，是不是似曾相识呢？想一下为什么会发生上面的问题，那么咱们以银行为例分析一下，一般银行内的系统建设环境分为三个：开发环境、测试环境与生产环境，每一个系统建设的周期都需要经过前两个环境才能正式进入生产环境。然而在系统的设计、开发、测试、上线过程中，无论是需求变更还是BUG修改都避免不了数据模型也就是元数据的改动。大到库表结构重新设计，小到一个字段类型的变更，都可能对程序造成影响。我们以往只重视程序功能测试，却往往忽视了对元数据的管控。往往在开发库、或测试库测试通过，而由于人工疏忽在在上线过程中遇到问题。运维部门也很头疼，由于对系统的数据结构并不了解，事先无法判断，但是每次出了问题我们都需要陪着解决。

有没有好的办法呢？我们先来看看元数据系统的对比分析功能。元数据系统可以自动化采集三个环境的库结构、表结构、字段结构、视图与存储过程结构等等。自动化采集保证了各自环境中都是最新的、最真实的、最准确的元数据结构。我们把系统提交上线的数据环境与测试库进行对比，与测试环境中元数据不一致的地方则一目了然。试想一下如果，如果把系统的开发库、测试库、生产库的元数据都管理起来，运维部门上线则不再被动的接受上线脚本，而是对元数据结构了如指掌，将元数据管控环节作为系统上线的必经环节之一，类似问题发生的概率则会大大降低。

场景二：数据流向分析——让IT部门迅速响应业务数据问题，降低技术调研成本

很多企业都有做了数据平台方面的建设，如数据平台、数据仓库、数据集市等。主要目标无外乎于由操作型数据向分析型数据的转换。通过大量的数据ETL过程最终形成业务分析统计数据。我们来看一个元数据分析典型的例子，业务人员拿到分析报表，发现其中的若干业务数据项明显不符合业务逻辑，则找到IT部门说你们加工出的报表有明显错误，今天必须改出来，明天要看到正确的数字并给业务部门的领导汇报。

由于数据加工链路往往很长，由：业务生产类系统->数据仓库->数据集市->报表系统内往往需要跨多个系统库。涉及多个项目组、不同公司程序员通过不同的技术手段实现，有的项目组用存储过程进行数据加工，有的项目组则使用ETL加工工具。所以没有一个人能把问题所涉及的业务相关的表与具体字段定位清晰。因此需要组织相关人员讨论，而且每次开会都要叫上许多人，分析问题的速度很慢，成本很高。

有没有比较快速定位问题的方法？我们看一下元数据系统的数据流向分析，也就是影响分析（上游->下游）与血统分析（下游->上游），提供了字段级的数据解析，上下游之间的数据加工链路可以通过图形的方式快速定位。每次分析问题都可以快速定位在特定的几张表的某些字段，然后再详细逻辑分析。大大简化了数据问题分析的环节，今后再有类似问题的分析，再也不需要叫上原本不相关的人员进行开会。分析问题的平均时间只有原来的1/3。

场景三：交易链路分析-助力快速梳理服务调用关系

上面两个场景介绍了系统运维与数据中心的两个应用场景，下面我们再来看元数据如何辅助快速梳理系统服务之间的调用关系与服务间的接口。

我们还以银行为例，银行的IT业务系统众多，之间的业务交易链路复杂。比如最常见的我在银行网点存钱，就涉及到记账、存取客户信息等业务。所涉及的银行业务系统包括柜面、核心、ECIF等，以及一系列复杂的系统接口服务调用。我们把一整套的接口服务调用关系称之为交易链路。当业务系统的交易链路逻辑关系复杂达到一定程度，往往会需要对服务重新梳理、整合。

随之而来的问题就是如何梳理交易链路。系统之间调用的服务方与提供方复杂度不同，输入与输出的参数各异，只能访谈每一个相关的开发项目组，投入大量的人力与时间成本。也有企业通过管理制度解决，新的系统上线、现有系统升级改造需要经过系统服务治理小组进行评审。但是服务治理小组本身梳理工作就很忙，无暇评估其他系统的变更，最后制度难以落实到位。这样人工的系统梳理花费了大量人力成本却难以见到效果。

有没有有效的自动化的的办法呢？答案是肯定的，用元数据的链路分析能力可以自动化的完成服务梳理。元数据可以通过服务接口的采集，自动获取服务的信息，包括参与接口调用的输入字段、输出字段的长度、类型等信息，并通过系统自动采集相关的数据字典与关系映射，避免了人工梳理的问题。更进一步，我们可以让元数据驱动，以元数据为核心，用服务的业务元数据规范新的服务，完善了整个服务体系，大大提高了服务治理的水平。

总结

其实像上面的元数据在企业中应用场景还很多，我们只要管理了企业的元数据信息，无论在企业的数据治理、数据管理、数据应用，企业应用架构，企业服务等等方面都可以发挥重要的作用。随后的系列文章我们还会具体讲解元数据产品在具体项目中的实施案例，更深入介绍元数据的价值。