从日志统计到大数据分析（四）——秦天下

转眼到了2011年初，我感觉团队放在网页相关性部门，不利于发展。我的想法是要把团队面向全公司服务，甚至成为像NLP(自然语言处理)部门在厂长心中的地位。但网页相关性部门的上司觉得先服务好本部门就够了。我和基础架构部的一个经理(最早在百度负责维护和开发Hadoop团队的负责人，在他完成了Hadoop在全百度的推广之后，改为负责一个分布式存储团队了)商量了一下，觉得两个团队合并，成立一个专门的数据团队，是一件更有意义的事。两人一拍即合。基础架构部的老大又从Google挖来了一位专家做我们团队的负责人，他之前在Yahoo做了7年，Google做了5年，一直在做数据仓库，绝对的资深专家，我很崇拜的人。

记得在2011年的7月1日，团队开了个All Hands大会，公司VP在讲话中说：在中国是D说了算，在百度也是D说了算，后一个D是指Data。说起来在百度这八年，百度文化有29条，我第二喜欢的就是“用数据说话”，数据虽然有欺骗性，但总的来说有数据要比没有数据好，它不带有感情，冷静客观。就这样，我们DataTeam成立了，或者叫DreamTeam。团队的一线人员一共二十来个，超过一半是我之前的下属。

有新总监的领导，我们的思路完全被打开了一圈。但在最开始，我们的思路依旧有些混乱，之前的产品还要维护，想做的新东西很多，我们似乎没有一个中心。眼看到了国庆，有一天我问新总监他觉得什么最重要，如果只挑一件事情的话，他说是UDW。我说那咱们核心成员就用来做这个项目。于是我迅速将Log的核心成员，抽调到了这一项目，在之后的三年里，我的主要精力可以说都是围绕它展开的。

UDW是User Data Warehouse的缩写，意为用户数据仓库。在新总监来到百度之后，很快发现了我们的数据源真叫一个混乱。公司有上百个业务线，每个业务线的数据格式都是不同的。如果你要基于所有的数据源做一个业务，比如个性化推荐，那么需要和所有的业务线沟通数据格式，并维护这条飞线。相比之下，在Google数据源都是被规范管理的，使用Protocol Buffer来规范数据格式，关于Protocol Buffer我后面会单独讲。新总监认为我们要先把数据源给统一起来，形成一个好的数据基础，后续的数据分析完全依赖于它。

对于这种思路，我是有疑虑的。在2009年的时候，我就做了一个叫麦哲伦的用户行为查询平台，通过输入一个ID，返回用户的行为记录，主要包括知道，百科，贴吧之类的产品。当时的做法是我把每个产品线的用户访问行为，比如在百度知道提问，用一个Action ID来标记，这个行为有一系列属性。对于有些属性，我还和业务线建立了专门的接口，用于获取这些属性的具体内容。比如通过问题的ID，获取到问题的标题，以保证行为记录的可读性。这个系统是很快建立起来了，但被使用的频率非常低。花很大精力整理的数据，似乎一时半会儿看不到多大价值。还有个问题是业务线的数据格式变更，我的数据处理逻辑都要更新，很难维护。所以这种思路被重新提出时，我最顾虑的是做出来之后有什么用，在应用点不明确的时候，我们是不是该做这件事。但新总监在公司层面很快推动达成了一致，总之是公司支持做这件事情。执行从来不是我的问题，既然都确定要做了，我很快就带着团队做起来。最开始选择最核心的八条业务线，在2012年的Q1季度末，正式对公司内部发布了。

UDW做了一件事情，将全公司的每个业务线的每一种用户行为，定义为一种Event，这个Event包括一系列的属性，核心的是UserID，Event Type，事件相关的其他属性。这样，一个用户在百度的任意行为就统一到了一张表上。再有人想做数据分析，就可以直接用干净统一的基础数据了。

从数据角度来看，是一个金字塔：

(图1 数据金字塔)

最底层是上百条业务线的文本日志，通过LogFormat转成Protocol Buffer格式。在此基础上，构建UDW。在UDW基础之上，我们构建围绕各种主题的数据，形成DataMart。比如基于Query的基础数据。再进一步汇聚，就可以用于BI的Insight。

在完成了UDW 1.0之后，我们继续向前推进，我的目标是用最短的时间，覆盖所有的业务线，尽快把地基打好。这个数据处理的过程，特别是数据Diff的工作量是巨大的，相关的几个团队的工作压力都很大。我把最后一批扫尾的业务线的项目起名叫Normandy，要完成最后的登陆。在2012年的国庆后，我去台湾玩了一趟，等我回来，发现变天了，公司开始谈狼性。

公司上下开始反思现在所做的项目，到底是不是对的，分析的结果就是Normandy过于强调进度，但质量和价值都是有问题。我带头做了检讨，就这样Normandy被叫停了，其实差不多过了半年，我才从那种低沉的状态缓和过来。

那年的年会，我和老大一起喝酒。我说今年我们算是建了个高楼大厦，但是四处漏风，我明年的目标是把它坐实了。

这里我总结一下UDW思路的优缺点。优点是为上层应用提供了一套统一干净的基础数据，上层的使用变得非常简单。一个广告团队，仅仅是将数据源切换到UDW，就提升了接近20%的收入。更何况以前在做个需要多个业务线数据源的应用，只需要和我们UDW打交道，这减少了多大的工作量和沟通成本。

不好的地方是源头的数据并没有变更，我们中间是通过ETL过程将数据接入到UDW的，而这个过程工作复杂难以维护，具有很长的滞后性。并且因为多了一轮计算，实效性也降低了。一些业务线开始抱怨，对UDW产生了严重依赖，特别是相对比较独立的业务线，做这件事完全没什么好处，还不如根据原始数据来计算。就这样，公司里又开始山头林立了。