1. 数据分析网首页
  2. 大数据
  3. 大数据技术

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

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

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

联系我们

如有建议:>>给我留言

QR code