公司经营分析会提到家庭市场的重要性，我就问负责家庭模型的同事：去年做的家庭结构标签用得怎么样？然后同事给我拿出了下面这张表。
通过元数据跟踪分析能力，我们已经能够知道任何一张模型表的应用情况，从测试查询、程序调用、市场投放等等，只有在这个基础上，我们才能有资格说自己的模型在生产中发挥了多少价值。
没有这些元数据，做数据的就会像瞎子一样，没有改进的方向，也难说功劳，当业务人员大谈数据价值的时候，我们这些创造者却连使用的情况都取不到，的确对不住自己做的这份工作。
但为了做到这一点，我们却跌跌撞撞在元数据领域摸爬滚打了10多年，期间经历了很多挫折和失败，今天就来谈一谈。
1、元数据的抽象概念
元数据是用来描述数据的数据，是对数据的解释，元数据相较于数据的重要性，就好比图书目录相较于图书一样重要。但元数据这个取名不太容易让人理解，当我第一次接触这个概念的时候，觉得这是个哲学名词。
元数据难以理解到什么程度呢？
即使到了现在，当我看到PPT中出现元数据这三个字的时候，仍然有种违和感，因为会觉得别人难以理解。如果你去问别人元数据的概念和内涵，能答上来的估计很少，相比微服务这种名字，元数据在取名上已经输了。
元数据这个数据领域炒作出来的一个名词，虽然现在已经拥有了庞大的体系，但普及的工作做得并不是很好，现在公司领导对数据中台都有了很好的理解，但元数据还上不了台面。
我后来惊奇的发现，不属于事物本身的关于事物的任何描述，都可以叫做元数据，根本不需要去抽象出元数据这个名词。因此，在我们任何产品的设计中，都会尽量避免用元数据这个名词，跟领导汇报数据仓库的业务元数据就尽量用数据字典替代。
2、元数据产品的误区
一些厂商为了炒概念，硬生生的把每个系统其实都需要的元数据功能剥离出来单独形成一个元数据产品。事实上，元数据是系统正常运行的一个基础，它天生就在那里，没有元数据，你的系统就会不好用，无论是配置信息、业务解释、路径分析等等。
元数据本来是数据仓库的一部分，现在却作为产品被独立出来了，成了数据仓库的下游系统。大家都知道，数据仓库是IT系统的下游，IT系统是业务的下游，在数据仓库还在为生存奋斗的时候，作为下游的元数据产品就更加艰难了。
独立出来的元数据产品似乎变得更专业化了，出现了多如牛毛的功能，但这些功能往往水土不服，跟企业的生产系统无法很好兼容，而要改动这些标准化的产品又很难。
因此，只要企业购买了标准化的元数据产品，就会陷入了为元数据功能寻找应用场景的尴尬境地，比如为了做血统分析，你需要人工去解析脚本，将结果纳入元数据系统管理，然后有了吊炸天的各种炫酷的血统分析展示图，其实没有用。
我们并没有意识到也许当前阶段并不需要血统分析，也没有意识到为了建设和运营好这些元数据功能所要付出的代价，比如过去为了元数据产品的正常运行专门配置了人员去做元数据的采集、导入等工作，到底是谁服务谁呢？
各种数据管理理论都在强调元数据的重要性，助推了大家去买元数据产品以便一劳永逸的解决问题，但元数据跟现在炒作的数据中台一样，根本不是一个可以买到的东西。
3、我们关于元数据的探索
元数据产品当然也是有价值的，起码它启蒙了笔者这一代的数据仓库建设者，在那个时代就认识到元数据竟然还可以有这么多的功能和应用，但让元数据真正发挥出价值之前，我们经历了三次认知升级。
（1）商业化的元数据产品阶段
数据仓库在国内刚出现的时候，元数据属于高级功能，配套元数据产品是很高大上的事情，我们对其全盘接受并抱有极大的期望，影响分析、血统分析等高端功能让我们的数据运维人员眼睛一亮，认为自动化、智能化的元数据能够马上改变运维苦逼的现状。
遗憾的是，元数据产品要用起来首先要解决自身数据的采集问题，而我们的数据仓库在建设的时候就没考虑过自动化采集元数据，为了得到元数据我们甚至要去解析乱七八糟的数据仓库的代码脚本，然后把解析的结果数据导入到元数据产品。
为了让数据仓库吐出符合标准的元数据，我们花了巨大的代价去改造数据仓库体系，姑且不说解析覆盖率到底可以达到多少，等到你终于勉强的搞定并准备使用元数据功能时，发现原来那些高大上的可视化功能却是绣花枕头。
你难以想象依赖100张报表、10个脚本的的某张结果表的血统图应该怎么去做溯源分析，密密麻麻的关系连接线就已经把运维搞晕了。
可怕的是，元数据产品本身还在不停的增加功能，而且要求客户为其新增的功能买单，但客户却还在为如何使用这些功能犯愁，这种拿来主义、贴膏药式的后向元数据产品模式，备受争议。
（2）元数据跟交付过程的融合
我们认识到商业化的元数据产品很难直接从原生数据仓库系统自动获得元数据，事后补录元数据的这种模式不仅效率低下，而且元数据质量难以保障，为了自动获得最完整的元数据，就需要改变数据仓库的交付模式，在数据生成过程中自动获得元数据，这就是现在大火的前向元数据管理模式。
元数据必须在数据的交付过程中同步生成，这样才能确保其完整性和一致性，从而为后续的元数据应用打下基础，因此，带有元数据采集能力的数据开发平台应运而生，这些开发平台会按照元数据管理的要求，针对建表、开发、调度做了大量强制约束，比如不许后台建表，隔离DDL、DML操作等等。
开发过程的标准化大幅降低了元数据的自动获取门槛，比如你不再需要去解析五花八门的脚本了，但标准化的代价就是要建立配套的机制和流程，大家要按规矩在一个可视化的界面里去配置代码，以SQL为核心的数据仓库开发模式基本能符合这种要求。
但这种元数据管理的代价不是每个企业能够承受的，比如你可能约束不了开发人员，因为你的开发可能外包给了各类合作伙伴，不能强制他们用你规定的技术栈，比如你打造不出符合要求的数据开发管理平台，导致配套的机制和流程难以在生产中落地，比如你的存量包袱太重，导致没有足够的资源去进行改变。
很多互联网公司数据管理能力强大，是以对技术栈绝对的掌控力为基础的。
我们能做到首先是运气，因为大数据让我们有一次从0到1的机会，其次是共识，有一批懂数据的人认为这种开发模式可以从根本上改变数据管理效率低下的局面，最后是坚持，我们的数据开发管理平台经历了无数次迭代才到了今天的水平，比如我们的项目经理变成了产品经理。
以上三个环节缺了哪一样，都会导致这种模式的失败。
（3）回归业务的本质
如果别人问我，为什么要实现元数据跟交付过程的融合，我说是为了让元数据采集更为方便，那为什么要让元数据采集更为方便呢？也许我就要想一想，采集这些元数据到底是为了什么？
答案是很明确的，因为数据仓库已经达到了一定规模，比如有几千的集群，几万的数据模型，这个时候数据间的调用关系变得非常复杂，导致运维核查问题效率低下，需要用这些元数据来快速定位问题。
如果你的企业的确到了这个阶段，有这方面的元数据诉求是很自然的，但元数据其实并不是必需的，要不要建需要企业回归业务本身去寻找答案。
如果企业的数据仓库才刚刚起步，干这个事情的优先级其实是比较低的。现实情况是很多企业数据仓库刚立项就想着采购元数据产品，找各种合作伙伴来筹划构建元数据系统，有那功夫其实还不如多配点建模、产品和运营的资源来证明数据仓库的价值。
大数据平台起来后，数据开发管理平台是刚需，因此我们的前向元数据管理模式是很成功的。但之后在相当长的时间内，我们的主要精力投入在数据变现上，没有更多的元数据应用诉求。
去年开始我们又开始大幅去加强元数据的建设，主要有两个原因：
第一，大数据应用越来越多，很多收入规模还很大，因此快速核查应用的数据问题变得非常重要，而产品团队和数据团队的衔接也并不是很通畅，因此我们得去改进原有的元数据系统，采用图数据库去增强应用数据到仓库数据的端到端溯源能力。
第二，大数据的计算和存储开销越来越大，数据的冗余也越来越多，而企业对于降本增效提出了明确要求，因此需要定期下线或优化模型，从而降低资源消耗，节省成本。
今年数据中台起来后，评估数据中台的价值也变得非常迫切，必须要知道每个模型和标签到底应用的怎么样，这是大数据高质量规模运营的基础。
因此我们开始在核心应用平台部署元数据采集和解析服务来追踪数据的使用情况，这就是文章开头描述的场景。