从零构建大数据平台方面的经验分享

 2008年底，我开始在百度负责一个日志统计的小团队，开发了一套基于Hadoop的日志统计平台，结果一年半的时间统一了全百度的日志统计工作。之后一直围绕数据这一方向，覆盖数据的采集、传输、建模存储、查询分析、数据可视化等，打造了全百度的用户数据仓库（User Data Warehouse），并推动全公司核心业务线的日志源结构化（Protocol Buffer）。这篇文章讲述我在百度从零构建大数据平台方面的经历。
　　洪荒年代
　　首先，我们回到2008年。那个时候，我是属于百度搜索新产品部的，像知道、贴吧、百科等，都属于这个部门的产品。部门里有个小团队叫Nslog，一共四个人，其中两个是实习生，所负责的工作就是部门内的各种需求统计。
　　统计的方式是这样的，各个产品线的业务人员按照需求文档的格式要求，填写统计需求，提交到需求管理平台上，Nslog的团队负责人（开始不是我负责）每周末，将需求分别分配给团队的几个成员。每个成员拿到需求列表之后，就挨着做。需求的实现，一般都是写 Perl 脚本，那个时候 Python 还没流行起来。因为统计需求比较类似，一般都是拿一个已有的脚本复制一份，修改一下，测试逻辑，测试大数据量下的准确性，然后部署到线上去。一共有20台机器跑统计脚本，每台机器上都用Crontab配置天级的例行任务。每个统计脚本的逻辑大概是这样的：通过Wget从数据源服务器上抓取按小时切割的日志文件，完成后，跑统计逻辑，将生成的结果组织成HTML表格，邮件发送给相应的团队。如下图所示：
　　
　　（图1 使用单机脚本跑统计）
　　这种模式有以下几个问题：
　　（1）需求响应周期长：从拿到需求，要和需求提出者确认需求细节，找一个类似的脚本修改，测试逻辑正确性，测试数据正确性，安排运维同学部署上线，平均每个需求要2天时间。这里还没算需求的等待时间，这可能要等一两周。
　　（2）运维成本高：20台统计服务器，每台机器通过Crontab管理了几十个脚本。这些脚本之间，可能还存在依赖关系，比如凌晨4点跑的一个脚本B，依赖于凌晨2点启动的某个脚本A。如果脚本A挂了，脚本B还是会正常的启动。恢复任务非常麻烦，真是牵一发而动全身。运维同学经常抱怨就没有哪一天能睡好觉的。
　　（3）运行速度慢：因为每个脚本只能单机运行，对于像知道、贴吧这样的大流量业务线，每天原始日志就有好几百G，光跑个排序就得好几个小时。特别是像贴吧被人爆吧，数据量一下子就会增加很多，统计结果跑不出来。如果分成每台机器跑一部分，维护代价非常大。
　　（4）职业发展瓶颈：那个时候还没有大数据的概念，大家对数据的价值也没现在这么认可，甚至连招聘面试时，也是把能力一般的分配到统计团队。而写脚本满足需求这样的工作是很枯燥的，对一个新人，写上三个月会觉得能学到不少东西，写六个月，就开始反感了，写一年，就坚决要求转岗或走人了。
　　当时我们的技术经理（同时管理了知道、百科、Nslog 三个团队）就觉得要做一套系统首要解决运维成本高的问题。但已有团队的人员光满足需求都忙不过来了，就从百科团队借调了两个人（不包括我）。那时候的我刚从百度知道转到百科团队，正想在百科团队大干一场。借调去的两个人其中一个是校招新人，我的项目经理就安排我也参与到项目中，培养新人的成长。于是我们三个人开始梳理需求和考虑设计方案。
　　盘古开天地一
　　设计一套日志统计平台的需求来源主要是Nslog的研发和运维同学，整理了好几十条，并出了一个基本的方案。我当时觉得实现一个提升运维管理的系统不难，难的是怎么是好用的？我很关心怎么提升需求处理的效率问题。这个时候其中一个人又被调到了一个基础库团队。也就是做这件事的就只剩我和校招新人了。而我们两个都还没做过需求处理，也不知道那几百个脚本里面都写的什么玩意儿。我说咱俩每人至少要看三个脚本，再抽查一些，看看这些脚本都有什么规律没有。我研究了之后，发现还是有些规律的。
　　我发现常见的统计有这么三类：
　　（1）计数统计：那个时代是流量时代，许多统计就是算PV（Page View）。一般是在 Apache Web Server日志中，去用正则表达式匹配满足某些条件的记录，做计数。
　　（2）去重统计：比如独立 IP 数，独立用户数等。
　　（3）Top N统计：比如昨天检索量最大的100个Query是什么。
　　我就问一直做统计的一位同学，这三类能不能占到所有统计需求的80%，他想了一下说有的。于是我就说咱们只要设计的系统，能够将这部分的需求处理工作量降下来，我们的系统就是成功的。这个时候技术经理又从其他团队借调了一个前端同学过来支援几周。我和校招新人都不会前端开发，这事儿没专业的人来搞不定。在接下来的两周时间，我就和前端同学研究怎么设计这部分的抽象。前端同学先提了一个方案，类似于 Dreamweaver中的页面HTML编辑界面，点选一个元素，可以进行修改配置。我觉得这种方案，还没直接写脚本效率高呢。
　　我从awk脚本语言获取了灵感。在awk语言中，都是awk condition { action } 这种模式，就是condition定义了满足的限制条件，action是执行的操作。比如：
　　awk ‘$6 == “Nov” { sum += $5 } END { print sum }’ 。/test.txt
　　就是把test.txt中，满足第6列等于 “Nov” 的记录，计算第5列的求和。
　　对于常见的那三类统计需求，都是一种统计类型，加上一堆限制条件。为了降低限制条件的难度，我让所有的条件之间只支持AND操作，不支持OR操作。我们知道AND和 NOT完全可以表示出来OR。
　　设计出来的效果是这样的：
　　
　　（图2 简单编辑界面）
　　上面是一个去重统计的例子，我选择一个日志源，点击“去重统计”按钮，生成一个模版，填写限制条件。一个统计任务就生成了。这里没有显示出来的是，每个日志源，都有一个对应的agent函数，所做的事是一段解析程序，将原始日志解析成若干个变量，如图中的去重字段部分，类似“_UserId”，这样在统计模板中就可以直接使用了。这样做了之后，可以让一个统计任务的开发工作量，降低到5分钟。
　　还有一个问题是计算性能问题。
　　盘古开天地二
　　当时Hadoop刚推出，还只是测试版。对于它能解决多少问题，我们心里是没底的。在百度内部已经有少量的需求在尝试使用，手工写 MapReduce 代码的方式。我也尝试写了一个，还是比较容易的，但有一定的学习代价。系统部有一个团队，在负责Hadoop 的维护。为了保险，我把底层计算接口设计成两套，同样的代码，既可以提交到Hadoop，又可以提交到单机。在单机上用脚本串起来，模拟在集群上的运行。Hadoop本身支持将任务分割为Mapper和Reducer两个阶段，我又增加了一个Computer阶段，作用是将Reducer的结果（一般是统计数值）拿到执行机（分布式提交任务的节点），并将其插入到数据库。我当时的想法是如果Hadoop不靠谱，我就把这20台单机，组成一个小集群，管理提交的任务。当然，这样的话就实现不了单个任务的分布式化了。