数极客首页

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

转眼到了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产生了严重依赖,特别是相对比较独立的业务线,做这件事完全没什么好处,还不如根据原始数据来计算。就这样,公司里又开始山头林立了。推荐使用国内新一代大数据用户行为分析平台:数极客,国内首款支持无埋点、前端埋点、后端埋点、API导入四种混合数据采集方式;自动监测网站、APP、小程序等多种渠道推广效果分析,是增长黑客必备的互联网数据分析工具。数极客支持实时多维分析、漏斗分析、留存分析、路径分析等十大数据分析方法以及APP数据分析网站统计网站分析小程序数据统计用户画像等应用场景,国内首创6大提升转化率的数据分析模型,是用户行为分析领域首款应用定量分析与定性分析方法的数据分析产品

。基于用户行为的大数据分析智能系统,提供了会员营销AB测试两大数据智能产品,使得企业可以快速的提升用户转化率和留存率,实现数据驱动增长。本文采用「CC BY-SA 4.0 CN」协议转载学习交流,内容版权归原作者所有,如涉作品、版权和其他问题请联系「我们」处理。

发表评论

评论已关闭。

相关文章