傅一平：如何完成一本企业数据字典的编写？

数据字典应该是数据管理领域非常核心的东西，如果说，语言是人类世界沟通的方法，数据字典则是数据世界沟通的语言，任何数据都需要通过看得懂的方式表达出来，只有懂这个数据什么意思，才有基于数据创造的可能，才能实现数据知识的传承。

但很多企业没做数据字典这个事，或者也不重视，为什么？

一是非眼前事，以后做也成，不做暂时也没影响。

二是难度比较高，产出却遥遥无期，做个取数好歹有个工单，搞本数据字典有啥业务产出，想不明白。

三是不够显性化，数据字典这种练内功的事情，很难引起领导重视，BI创造亮点和业务价值才是正事。

有幸主导了所在企业数据字典的编写工作，因此来谈谈编写的心路历程，可能会有些启示。当企业的数据字典成为公司数据采集、开发、分析及应用的必备工具后，才感觉到这个工作完成实际迟到了很多年。

如何启动数据字典梳理这个事情？

企业数据字典的梳理是个浩大的工程，如果让一个人去启动这个事情，大多第一反应肯定是工作量巨大，有点茫然，这也是笔者当时的感觉。

但看似不可能完成的任务，真的花功夫去研究了，发现还是有可能做的，我当时作了初步判断，基于手头的公司各源系统给的各类PDM等文档，结合实际的统计，公司核心系统的重要的表，大概不到3万张，而真正有业务价值的表，估计不到1万张，假如我花100天，每天搞定100张表，这是个能突击完成的任务。

当然后来深入到表字段的分析，发现根本处理不了这么多，因此，决定先完成基于表级的梳理，搞清楚每张表的业务含义和获取方式 ，事实上，正是由于这个决定，才能尽快的完成一个阶段性成果，也正是有了表级的指导，后续才可以将字段级的梳理要求清晰的分配下去，8个人理2个月也基本完成了。

一个企业，肯定有一拨或几号人，其业务和数据的沉淀到了一定水平，能够干这活，但起头的确非常不易，毕竟梳理数据字典，也是讲究一定方法和套路的。

做这事的还有一个原因，是公司要建设大数据平台，如果没有完整的数据字典，那这个工程能否如期保质完成是个未知数，不能想着拿原来的BI的那点数据接口来应付，也不能期望他人（有谁比你更懂呢），还是要靠自己，利用一切机会把公司的资产梳理清楚。

作为一个BI老鸟，你不上，就没人能上了，还是要有这个觉悟。以下是我当初回顾PPT写得一段话：

“通过梳理XX公司全景数据，建立起大数据基线版本，明确大数据的分布，理解数据蕴含的意义，判断出这些数据的价值，指导未来大数据引入和建模等工作，并通过运营机制的建立盘活公司大数据的资产。”

“本次梳理以大数据营销及变现为驱动力，重点考虑B域及O域，后续在条件成熟时会逐步扩展到完整的M域，梳理的基准数据粒度是域-系统-表（或对应的数据实体），不对每个字段（或属性项）做具体描述。”

那采用什么样的方法和步骤呢？

一是确定规划目录：原则上应该自顶向下梳理，先通过调研确定总体结构分类，然后分主题进行，由于本次梳理的范围较大，暂时以源系统方式梳理开始，不强调目录分类的科学性，仅强调梳理的便捷性，以下是B域的目录示例。

二是确定参考材料：从源系统负责人搜刮到的BOSS/CRM等系统所有现存的PDM，SVN上存在的所有概要设计文档为依据，梳理的参考材料会按照系统分门别类保存，作为输出物，方便后来人参考，算是梳理的副产品，的确没有一个地方有完整的源系统资料。

三是确定干系人：很多知识都留在开发人员脑子里，现有的资料不足以解释当前的实际业务和数据，因此确定了干系人名单，这个工作也很重要，以下示例了各个系统对应的合作伙伴和联系人，有问题就直接真人PK。

做数据的，有必要跟源系统的开发等人员混熟，否则涉及一些深层次的问题，没人能够解答，必须要开发人员出马，以为文档很理想，但现实很骨干，国内的IT文化是代码写得快，领导说100天搞定就搞定，但文档就乏善可陈了。

四是理解逻辑视图：系统的逻辑模型对于理解数据的业务意义和价值至关重要，因此首先需要从PDM或概要设计找到模型去理解业务，这个是最艰难的，梳理数据字典不是拿着PDM来直接抄就可以了，要把业务理解清楚，才能写出很好的说明，反映出各种实体的关系。以下列出了产品系统中涉及的相关表，务必要搞清楚各个子主题及各表之间的关系，表的关系图在PDM，因此不罗列。

五是理解数据实体：

首先，针对每个表或数据实体查看实体的注释，大致理解用途，然后再看字段，然后再看建表语句，会有很多有用的枚举注释。

其次，在数据库中找到这张表，查看真实数据，加深对于数据的理解，比如假如表为空，一般表不会太重要，如果某字段值基本为空，则字段不会太重要，很多文档中的表早已经失效，需要亲力亲为去核验。

最后，理解数据的关键是实体间的关系，比如看到用户表，自然想到用户肯定能关联到客户，那如何关联起来呢，因此需要自己找实例去验证想法；比如看到策划订单，自然想到客户订单跟它是什么关系。

梳理的过程也是对以往零碎的知识的查漏补缺过程，非常有价值，对于源系统会有更深的理解。

那么，梳理的要素有哪些呢？

我列出了每个实体的13个梳理要素，方便参考，但不同企业情况不同，可以自己做增减。

一是实体名称：一般是表的中文表名，由于数据可能有层级关系，在一些主题梳理时候，会体现一定的分层表达。

二是实体说明：对于表的业务理解往往体现在这里，一部分来源于源系统文档表的备注说明，另一部分来源于自己的理解，理解的越深入，这个说明就越有力量。

三是来源系统：来源于哪个系统，由于系统越来越多，访问方式越来越多，因此对于系统的命名和访问方式做了归纳。

四是源系统表名：来源于哪个源系统哪张具体表，如果涉及分地市，月份，年份等，会以通配符方式表达，一般XXX代表地市、YYYYMM代表年月、YYYY代表年、F代表报结、H代表历史等。

五是引入状态（是，否）：与当前存量仓库模型的比对结果，如果仓库中有，就标识是，否则就标识否。

六是优先级：站在业务的角度看源系统数据的价值，高代表分析价值较大，应该优先引入，而一些前台配置表优先级就较低，当然这个判断带较多的个人色彩。

七是引入可行性：从技术角度和管理角度看数据引入的可行性，主要依赖主观判断。

八是业务用途：粗略判定数据可以用在哪个分析方面，主要依赖主观判断。

九是业务是否理解：对于源系统的业务和数据理解程度不够或有异议，暂时得不到解答，但不能死在这里吧，会填否，因为有时间要求。

十是联系人：对应的源系统的负责人，所谓冤有头债有主。

十一是访问代码：访问数据的原始SQL代码，方便验证数据，源系统库太多了，有时回过头来，忘记了哪是哪，因此务必梳理的时候记下来。

十二是采集周期：表明可以采集的最小周期。

十三是采集形式：表明是状态表还是流水表等，不同表影响具体的采集方式。

最后，梳理成什么样子呢？

首先是总体目录图，方便查看，如下图所示。

点击每个链接，就可以访问到对应的子系统，每个字系统的实体都作了说明，可以自己看有哪些要素：

以下示例了笔者当初作的一页PPT总结：

经过1个半月，每天12-14个小时的高强度梳理，基本将公司核心系统轮了一遍，对于公司的数据资产有了更深的理解。

通过这一遍的梳理，公司的核心数据资产较以往仓库已经引入的多了5倍，并且所有的表都重新进行了标注，这为后续字段级的梳理打下了坚实的基础。

整个梳理的过程，有点像古人整理四库全书，很枯燥，但看到EXCEL中被挖出来的静静躺在那儿的珍贵的表，还是有点成就感的。

那么，现今的数据字典怎么样了呢？

后来，建立起了自己的模型团队，各张表也责任到人了，在这个版本基础上，进行了大幅的扩展，不仅细化到字段级、表达也更为清晰、同时全部系统化了，这为大数据平台项目的数据完整引入奠定了坚实的基础。

表目录

表字段说明

系统化的字典

感到高兴的是，即使是刚到团队的新人，也能根据这个方法去开展工作，就好比我设计了个Hadoop的计算框架，其他人，只要沿着这个框架分布式去做即可，并且可以在此基础上进行扩展。

同时，再也不需要手把手的教新人这张表什么意思了，扔掉了PDM和那些无聊的文档，有个系统在那里，还是非常实在的。

数据字典虽然仅仅是数据管理中的一部分，但的确意义很大，在《数据管理工作为什么这么难》一文中，我也提到，当前公司的数据字典已经跟生产无缝结合了，但所有工作的起点，的确始于此。很怀念这段时光。