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

转眼到了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产生了严重依赖,特别是相对比较独立的业务线,做这件事完全没什么好处,还不如根据原始数据来计算。就这样,公司里又开始山头林立了。

本文为专栏文章,来自:桑文锋,内容观点不代表本站立场,如若转载请联系专栏作者,本文链接:https://www.afenxi.com/9763.html 。

(0)
上一篇 2016-03-08 06:00
下一篇 2016-03-09 06:00

相关文章

关注我们
关注我们
分享本页
返回顶部