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

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

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

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

三是不够显性化,数据字典这种练内功的事情,很难引起领导重视,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和那些无聊的文档,有个系统在那里,还是非常实在的。