对于一个输入,我们可以去选择某些字段,进行分组,每组在计数,然后输出到一个文件。这样就实现了一个统计任务。这种链式的处理方式,在现代已经很普遍了,特别是 Spark 里都是采用的类似表示方法。我们在2009底做了这个事情,在2011年公司号召多提交专利时,提交了发明专利。今年3月初时,专利刚被审核通过。这种将数据流式的进行变换的思想,已经见诸于各大分布式计算系统。
在给出 DQuery 原型后,我觉得团队太弱小了,只能有一个全职参与这件事。于是找基础库团队的同学寻求支持。他们最开始提出何不实现一个 Google Sawzall,但我觉得太底层了。最终说服对方安排一位工程师参与进来。结果就是他们两个人花了2个半月,就把这个语言开发出来了。
可能你会问为什么当时不选择使用 Hive?事实上,那个时候 Hive 的工程师也来公司交流和推广了。但有两个需求不好满足:
(1)任务合并:对于同一个数据源,可能有几百个统计任务。这种统计任务可能都很简单,但是都要将数据源读取一遍,也就是一个高 IO 低 CPU 的任务。我们当时想直接读取一遍,然后将多个任务同时计算,这样效率会高很多。这在 Hive 上是不支持的。
(2)用户行为分析:我当时比较乐观,觉得我一年解决统计问题,第二年解决分析问题,第三年解决挖掘问题。事实上到现在分析问题也没解决彻底。我们知道 Hive 是基于 SQL 的,而 SQL 是上下文无关的。也就是说你取出的一批数据,有前后关系的话,是很难操作的。我需要在语言上支持。而在 DQuery 语言中,我们设计了一个方法叫 process,可以嵌入用户的逻辑,非常灵活。这里要说的是 DQuery 是一个基于 PHP 语言的框架,这样 DQuery 表达不了的,都可以写原始 PHP 代码。
就这样到2010年底的时候,实现了全公司日志统计全部统一到 Log 平台。这是我在百度八年,干的最有成就感的一件事情。
秦天下
转眼到了2011年初,那个时候团队已经合并到了网页搜索部的相关性部门,我感觉这不利于发展。我的想法是要把团队面向全公司服务,甚至成为像 NLP(自然语言处理)部门在厂长心中的地位。但网页相关性部门的上司觉得先服务好本部门就够了。我和基础架构部的一个经理(最早在百度负责维护和开发 Hadoop 团队的负责人,在他完成了 Hadoop 在全百度的推广之后,改为负责一个分布式存储团队了)商量了一下,觉得两个团队合并,成立一个专门的数据团队,是一件更有意义的事。两人一拍即合。基础架构部的老大又从 Google 挖来了一位专家做我们团队的负责人,他之前在 Yahoo 做了7年,Google 做了5年,一直在做数据仓库,绝对的资深专家,我很崇拜的人。
记得在2011年的7月1日,团队开了个All Hands大会,公司 VP 在讲话中说:在中国是 D 说了算,在百度也是 D 说了算,后一个 D 是指 Data 。说起来在百度这八年,百度文化有29条,我第二喜欢的就是“用数据说话”,数据虽然有欺骗性,但总的来说有数据要比没有数据好,它不带有感情,冷静客观。就这样,我们 DataTeam 成立了,或者叫 DreamTeam。团队的一线人员一共二十来个,超过一半是我之前的下属。
有新总监的领导,我们的思路完全被打开了一圈。但在最开始,我们的思路依旧有些混乱,之前的产品还要维护,想做的新东西很多,我们似乎没有一个中心。眼看到了国庆,有一天我问新总监他觉得什么最重要,如果只挑一件事情的话,他说是 UDW(User Data Warehouse,意为用户数据仓库)。我说那咱们核心成员就用来做这个项目。于是我迅速将 Log 的核心成员,抽调到了这一项目,在之后的三年里,我的主要精力可以说都是围绕它展开的。
在新总监来到百度之后,很快发现了我们的数据源真叫一个混乱。公司有上百个业务线,每个业务线的数据格式都是不同的。如果你要基于所有的数据源做一个业务,比如个性化推荐,那么需要和所有的业务线沟通数据格式,并维护这条飞线。相比之下,在 Google 数据源都是被规范管理的,使用 Protocol Buffer 来规范数据格式。新总监认为我们要先把数据源给统一起来,形成一个好的数据基础,后续的数据分析完全依赖于它。
对于这种思路,我是有疑虑的。在2009年的时候,我就做了一个叫麦哲伦的用户行为查询平台,通过输入一个 ID,返回用户的行为记录,主要包括知道,百科,贴吧之类的产品。当时的做法是我把每个产品线的用户访问行为,比如在百度知道提问,用一个 Action ID 来标记,这个行为有一系列属性。对于有些属性,我还和业务线建立了专门的接口,用于获取这些属性的具体内容。比如通过问题的 ID,获取到问题的标题,以保证行为记录的可读性。这个系统是很快建立起来了,但被使用的频率非常低。花很大精力整理的数据,似乎一时半会儿看不到多大价值。还有个问题是业务线的数据格式变更,我的数据处理逻辑都要更新,很难维护。所以这种思路被重新提出时,我最顾虑的是做出来之后有什么用,在应用点不明确的时候,我们是不是该做这件事。但新总监在公司层面很快推动达成了一致,总之是公司支持做这件事情。执行从来不是我的问题,既然都确定要做了,我很快就带着团队做起来。最开始选择最核心的八条业务线,在2012年的 Q1 季度末,正式对公司内部发布了。
UDW 做了一件事情,将全公司的每个业务线的每一种用户行为,定义为一种 Event,这个 Event 包括一系列的属性,核心的是 UserID,Event Type,事件相关的其他属性。这样,一个用户在百度的任意行为就统一到了一张表上。再有人想做数据分析,就可以直接用干净统一的基础数据了。
从数据角度来看,是一个金字塔: