从日志统计到大数据分析（一）——洪荒年代

我2007年浙大研究生毕业后加入百度，先在百度知道做了一年的后端研发，2008年底开始负责日志统计的一个小团队，开发了一套基于Hadoop的日志统计平台，之后一直围绕数据这一方向，覆盖数据的采集、传输、建模存储、查询分析、数据可视化。今年4月份从百度离职创业，做一款针对互联网创业公司的数据分析产品Sensors Analytics，有兴趣的可以到sensorsdata.cn申请体验。

接下来我会写一个系列文章，讲述从2008年底开始，到2015年4月期间，我在百度从零构建大数据平台方面的经历。

洪荒年代

首先，我们回到2008年。那个时候，我是属于百度搜索新产品部(NS，New Search)的，像知道、贴吧、百科等，都属于这个部门的产品。部门里有个小团队叫Nslog，一共四个人，其中两个是实习生。所负责的工作就是NS部门的各种需求统计。

统计的方式是这样的，各个产品线的业务人员按照需求文档的格式要求，填写统计需求，提交到需求管理平台上，Nslog的团队负责人(开始不是我负责)每周末，将需求分别分配给团队的几个成员。每个成员拿到需求列表之后，就挨着做。需求的实现，一般都是写perl脚本，那个时候python还没流行起来。因为统计需求比较类似，一般都是拿一个已有的脚本复制一份，修改一下，测试逻辑，测试大数据量下的准确性，然后部署到线上去。一共有20台机器跑统计脚本，每台机器上都用crontab配置天级的例行任务。每个统计脚本的逻辑大概是这样的：通过wget从数据源服务器上抓取按小时切割的日志文件，完成后，跑统计逻辑，将生成的结果组织成html表格，邮件发送给相应的团队。如下图所示：

(图1 使用单机脚本跑统计)

这种模式有以下几个问题：

(1)需求响应周期长：从拿到需求，要和需求提出者确认需求细节，找一个类似的脚本修改，测试逻辑正确性，测试数据正确性，安排OP部署上线，平均每个需求要2天时间。这里还没算需求的等待时间，这可能要等一两周。

(2)运维成本高：20台统计服务器，每台机器通过crontab管理了几十个脚本。这些脚本之间，可能还存在依赖关系，比如凌晨4点跑的一个脚本B，依赖于凌晨2点启动的某个脚本A。如果脚本A挂了，脚本B还是会正常的启动。恢复任务非常麻烦，真是牵一发而动全身。OP同学经常抱怨就没有哪一天能睡好觉的。

(3)运行速度慢：因为每个脚本只能单机运行，对于像知道、贴吧这样的大流量业务线，每天原始日志就有好几百G，光跑个排序就得好几个小时。特别是像贴吧被人爆吧，数据量一下子就会增加很多，统计结果跑不出来。如果分成每台机器跑一部分，维护代价非常大。

(4)职业发展瓶颈：那个时候还没有大数据的概念，大家对数据的价值也没现在这么认可，甚至连招聘面试时，也是把能力一般的分配到统计团队。而写脚本满足需求这样的工作是很枯燥的，对一个新人，写上三个月会觉得能学到不少东西，写六个月，就开始反感了，写一年，就坚决要求转岗或走人了。

当时我们的技术经理(同时管理了知道、百科、Nslog三个团队)就觉得要做一套系统首要解决运维成本高的问题。但已有团队的人员光满足需求都忙不过来了，就从百科团队借调了两个人(不包括我)。那时候的我刚从百度知道转到百科团队，正想在百科团队大干一场。借调去的两个人其中一个是校招新人，我的项目经理就安排我也参与到项目中，培养新人的成长。于是我们三个人开始梳理需求和考虑设计方案。