相伴十六载，讲讲我和数据仓库的故事（二）

Original 傅一平与数据同行 2021-10-16

收录于话题 #数据仓库的故事 12个内容

这是傅一平的第328篇原创

作者：傅一平

个人微信：fuyipingmnb

“与数据同行”开通了微信群，分为数据仓库、数据分析、产品经理、数据治理及数据建模五大专业，现已汇聚了4000位小伙伴了，加微信号：frank61822702 申请入群。

正文开始

第一篇文章里笔者简要的介绍了经营分析1.0起步建设的情况，今天首先讲讲2004-2006年这段期间自己和团队一起成长的故事，然后再谈谈2006年经营分析1.5的起步。

三、2004-2006，成长的故事

1、实习期间的笨鸟先飞

2004年自己进入公司后，马上被安排取温州实习，在去温州的大巴车上，我接到了一个电话：

“我是nova，欢迎博士加入经营分析组，希望你马上回来，这边缺人很厉害啊！”

这是主管给我打的第一个电话，还是很激动的，想着自己啥都不懂，主管就对于我寄予厚望，我一定得好好干哪。

现在走上管理岗位后，也经常会反思一下，新人是很需要上级鼓励的，也许你只是客套一下，但对于新人很重要，当然要做到这一点其实也蛮难的，有时候会觉得有些虚伪，情商太低的缘故吧。

自己当时实习的目标是希望回省公司后能立马上手干活，三个月的实习期，我每天二点一线，在宾馆和实习的温州公司之间往返穿梭，最有印象的就是每次在路上都会看到周杰伦动感地带那个广告牌，还有就是“在我地盘这你就得听我的......”。

实习期间看完了公司主要数据库的PDM，把历年的取数脚本研究了下，大致看懂了经分报表的代码，把几百张报表下载到电脑里研究，然后对每张报表的每个指标进行了注释，形成了自己第一本数据字典，同时把集团公司的经营分析的规范翻了几遍，对于数据仓库有了基本的了解。

我编写的青涩的数据字典

也许你会说好厉害啊，但其实只要勤奋点的人都能做到，我属于那种天赋一般，但相信勤能补拙的人，这可能跟大学的经历有关。

自己从浙江大学高级工程班出来，写过汇编、C、VC等等，博士期间干过很多工程项目，比如在2001年就已经开始用BP算法做牌照识别了，当然那个算法是我继承师兄的。

记得当时在南昌某个收费站待了一个月采集牌照来进行训练，而且还与师弟合作出过一本《Visual C++精彩实例详解》的书。但我看到过牛逼的人写得代码是什么水平，自己显然是达不到那个境界的，有时挺自卑。

能把单位的相关文档和代码看一遍仅仅是蛮力而已，至于为什么会准备的比较充分，也许是因为实习前自己已经在省公司呆了2个礼拜，有意识的把能拷贝的东西都拷贝到了，笨鸟先飞吧。

自己的求知欲还可以，在实习期间曾经大着胆子给集团的经营分析专家写过邮件，这不还找到了当年的那封邮件，分享给大家。

“您好,我是XX移动的新员工,领导要我做经营分析的项目,现在我在地市实习,估计2个月后就回省公司正式开始工作了,由于以前在学校没做过类似的项目,因此对这一块还是很陌生的,我希望在实习期间对经营分析有个比较详细的了解,这样我上岗后能快速的进入角色。

由于刚进公司,我对移动还不是太了解,我也没有任何接触使用开发BOSS系统的经验,我也知道对一个刚从学校出来的新手直接上马从事移动经营分析是有难度的。我现在希望能快速的融入这个角色,因此希望知道搞经营分析需要掌握的一些东西。

我有的资料是boss系统的比如计费,营业等的数据字典,还有是同事给我的一些关于经营分析的文档,比如很对规范,概要设计,物理设计等,对于这些文档我也看了不少，我在学校的时候也参加了很多项目开发,但发现经营分析这个项目太大了,对于其中的技术细节我不可能都能掌握,比如建设数据仓库,就要抽取,要用到datastage，前台展示要用到brio,要了解olap,比如XX移动用DB2,我还要了解DB2等大量的技术,当然对于源数据库,比如计费等,我还得了解其中的各种字段等的说明和大量的业务规范等,作为移动技术人员,我不知道自己需要掌握这些到什么程度,需要在跟开发商之间扮演什么角色，作为一名新人，我需要哪些技术储备。

偶然间我在dwway论坛和中国计费网看到了您的帖子,钦佩而且振奋,您是集团公司关于BOSS和经营分析系统的策划者,我想您的建议对我来说是很珍贵的,非常希望能得到您的建议,我也希望能为中国移动贡献自己的力量。

我主要问题可以归结为3个:

1、上手经营分析我需要了解哪些技术(比如数据仓库等)

2、需要了解哪些移动的东西,比如boss系统,牵扯到各种数据库以及细节

3、对于技术我需要掌握到的什么程度,我在与开发商协调过程种需要扮演什么角色,即我的任务是什么

非常希望能得到您的答复，谢谢"

一晃15年过去了，现在的我可能变成了以前的他，当然我不是什么专家，而很多网友就是当年的自己，对于未来充满憧憬和希望。

这一路走来我犯了很多错误，如果能写出来，可能对大家有益吧，这也是我写文章和开微信群的一个原因。

当3个月的实习完成后，我对于公司的数据已经有了很多的理解，起跑线其实是不错的，实习期后的个人成长经历以后再讲。

2、第一代数据开发平台BOSSREP

虽然我在第一篇文章中夸过PL/SQL Developer这个集成开发工具，但它也是有问题的，因为它只是个方便的取数工具，当取数需求越来越多的时候，你会发现管理的复杂度直线上升。

比如没有代码的管理、没有数据字典的管理、没有调度的管理，跑10个脚本要开10个窗口，那真叫一个混乱。

这个时候老朱上场了，老朱是对我影响很大的一名合作伙伴的数据专家，在职业生涯的初期几乎所有的疑难问题都会找他，无论团队碰到了什么问题，老朱几乎都能解答，代码的问题、数据质量的问题、数据库方面的问题等等，不一而足，老朱就是万能的代名词。

老朱研发了牛逼的第一代BOSSREP这个C/S架构的开发工具，阿里Dataphin等强大的开发工具近几年才出现，而BOSSREP这个开发工具2005年就出来了，它囊括了当前大多数开发管理工具的基本功能，包括元数据管理（那个时候主要管报表）、代码管理、调度管理、分布式管理等等。

牛逼的BOSSREP

我举2个很好的功能：

分布式管理其实就是做了一个事，将串行的任务做成并行，比如我们的数据仓库大多是按照地市分表设计的，以前PL/SQL Developer跑11个地市只能一个个串行跑或者开11个窗口跑，现在配置一下就可以了，效率提升了5倍以上。

代码管理则是采用拆分的思想，你可以把一段很长的脚本按照业务逻辑拆分成多段，运行的时候可以进行分段控制，调试和运行实在是太方便了。

现在都在提中台，BOSSREP就是那个时候最牛逼的中台，自从有了这个工具，我们取数和报表开发的效率直线上升，原来2004年刚进公司的时候一个月也就20-30个取数需求，2006年的时候已经上百了。

下面是一段当年的代码，你看里面已经出现了通配符“$AREACODE”了，BOSSREP自动会把它转化成11个脚本并行跑。

3、第一代宽表ALL_XXX_YYYYMM

虽然我们的数据仓库项目建设了统一的模型体系，但这套模型体系当初主要是围绕用户、业务、竞争几个主题构建的，基于这些主题出了公司的核心KPI，而KPI在很长的时间内是稳定的，决定了这套模型变化很少。

在日常的公司经营活动中，KPI是服务管理者的，管理者会分解KPI指标到基层，基层除了关注KPI，还要关注如何完成这些KPI，因此由KPI会衍生出大量的执行类指标。

执行类指标对于一线才是有实际指导价值的，比如市场占有率这个KPI指标，基层一线看光这个指标没用，还需要分解成一系列可操作的相关指标，比如放号用户数，而放号的粒度可能还太粗，因此还要分解到营业厅、社会渠道、电渠等等，这样才能压实责任，某某社会渠道每天要放号多少才是一线指标的刚需。

市场变化很快，执行类指标变动也会很快，因此日常的运营无法靠这套稳定的仓库模型体系支撑，当然你可以说去改啊，但改错了成本就太高了，我们得自己想办法。

老朱创造了一套贴近一线实际的宽表，我们叫它ALL表，意思是无所不能，后续大多数的取数和报表实际都是依赖ALL表的，我们对外谈的是面子，即标准化的仓库模型，对内实际运营的则是这套ALL表，由于ALL表没有什么负担，因此能够随着业务滋养而快速成长。

这就是稳定、责任和快速、创新的矛盾。

数据中台的共享说说容易，当真的在日常运营中要你去改一个中台模型，你还得掂量下改错的代价，因为风险随着共享变大了，新建一套仓库模型谁都会，但要会运营则是另一个境界的事情。

笔者后来在这个基础上也建立了一套ALL表，命名是ALL_XXX_YYYYMMDD，就是把月表演进为了日表，这是我的私货。你要提升效率，就得做些创新，让自己成为一个闲人，才有功夫去想些其他有趣的事情。

现在建表啥的都有规矩，今天你在库里建一张不规范的表，明天机器就给你揪出来，因此私活就很难做了，创新的苗子也往往被扼杀了，因此规范化的创新企业往往要在管理方面下大工夫。

四、2006，经营分析1.5的前奏

第一篇文章里笔者讲了中国移动经营分析系统1.0建设完成后，马上开始筹划1.5的建设，技术上就是在数据集市、元数据管理及数据质量管理方面进行探索，集团前期召集了很多省公司开展试点，笔者也参与其中。

1、数据集市

BASS1.0的九大主题推出后，应用情况实际并不理想，前文中我也已经提到，自顶向下的业务规范到了本地往往水土不服，而且DB2这类数据仓库是很难推广到一线使用的，这就形成了两张皮的现象，一方面省公司轰轰烈烈的在做建设和推广，另一方面一线仍然在自己老旧的本地机器上做着自己的报表。

为了解决这个问题，数据集市孕育而生，目标有三个：

扩大省级经营分析系统的服务范围，省级经营分析系统为地市数据集市提供充足的、准确的数据，同时提供全省统一部署的经营分析工具，地市数据集市面向地市应用开展建设，是对省级经营分析系统功能的延伸
地市数据集市作为省级经营分析系统的补充，为各地市一线生产营销人员提供更加灵活，更加及时，更有针对性的分析应用，更好地支持日趋激烈的市场竞争活动
地市数据集市作为各地市自主的数据分析和演练平台，可以充分针对地市个性化的业务需求进行满足，同时在个性化应用逐渐固化后，将亮点业务应用整合进各省级经营分析系统，实行全省推广，应验共享

集团召集了部分省公司实施数据集市的试点，效果还是非常显著的，数据集市上线后经分的使用点击率提升200%以上。

这个容易理解，地市不仅有了省公司提供的小型机，安装了自己喜欢的ORACLE数据库，还可以利用省公司的工具开发自己的报表，的确能提升生产力。

但这仅仅是试点的结果，实际的挑战可太大了，后面再讲吧。

2、元数据

笔者第一次听说元数据这个名词也是在2006年，因为集团在这一年开展了元数据的省公司试点。元数据关于数据的数据这个定义颇令人费解，一定程度上阻碍了其推广。

元数据本质上就是对数据的描述（也包括上下文），比如数据的所属区域、取值范围、数据间的关系、业务规则、数据来源等等，在一座图书馆中，如果认为每一本书的内容都是数据，用来查找每一本书的索引就是元数据。

理解了这个本质，你对元数据可以信手拈来，比如你有一个EXCEL，EXCEL包含数据，那么这个EXCEL的名字、EXCEL里的SHEET名字，SHEET里面任何行列的名字，都是元数据，因为它们都可以帮助你来解释EXCEL里面的数据。

元数据的目的跟语言也可以类比，语言让说话的双方都能听得懂是一个意思，而元数据让使用数据的双方也能理解为同一个意思，所谓的“书同文，车同轨”。

我翻开了尘封的一份元数据PPT文档，里面是这么描述管理元数据的意义的：

理解企业内部的信息资源

动态的数据字典
数据的浏览和归纳
数据在企业内部横向与纵向传递
保持整个企业的标准（保证企业内部统一的商业定义和商业规则）
数据生命周期的管理

元数据其实就是数据的知识库，而知识可以指导行动，以下是元数据的一张功能结构图，方便你去理解。

而为了在异构环境下，帮助不同的数据仓库工具、平台和元数据知识库进行元数据交换，OMG这个组织又定义了元模型（CWM，Common Warehouse Metamodel），元模型实际上是元数据的一个定义标准，有哪些标准呢，见下图，有点抓狂没关系，继续往下看。

在形成CWM标准以前，数据仓库要进行集成的情况如下图所示：

在形成标准以后的情况如下图所示：

比如描述一张表可以有很多种方式，你既可以用三个元数据来定义，比如表名、表描述、表主键，也可以用五个元数据来定义，比如表名、表描述、表主键、归属数据库、容量等等，假如你需要在异构数据库的表之间交换数据，就必须有个元数据标准，大家讲的表都是同一个模式，即都是五个元数据来描述，而且这五个元数据含义都一样，这就是CWM要做的事情。

表的描述是元数据，但要规定怎么描述一张表，则是元模型做的事情，这是抽象的抽象。

元模型的应用无处不在，比如我们的DACP开发管理平台，假如要新建一张表，这张表的填充要素有哪些呢？

其实就是由CWM控制的，只是很多企业没有用CWM那套标准而已，而现在数据仓库相关的企业往往需要遵循这个标准，否则就很难去做开放。

元数据作为试点是成功的，但真正纳入生产那坑就太多了，这个以后再说。

3、数据质量管理

除非一个企业做过很大的努力来提高数据质量，企业的数据错误率一般都会近似达到1-5%，这是Redman通过对多家企业的实际评估得出的结论。

我们搞数据的每天都在处理数据质量问题，但要体系化的建设数据质量管理体系则是巨大的挑战，因为影响数据质量的因素太多了，我给你看一个图，你就知道了，这张图还是很牛逼的。

为了保障经营分析系统的可靠和有效，统一考虑整个系统平台的数据质量问题，集团要求在经营分析系统中通过元数据实现方式，建立数据质量管理平台，以丰富完善系统各级数据质量的保障机制。下图是数据质量管理体系结构图示例，还是很清晰的。