从日志统计到大数据分析(三)——盘古开天地二

从日志统计到大数据分析(三)——盘古开天地二

作者:桑文锋,Sensors Data的创始人&CEO,前百度大数据部技术经理

上一篇:

从日志统计到大数据分析(二)——盘古开天地一 - 瓦利哥的机器岁月 - 知乎专栏zhuanlan.zhihu.com图标

在考虑可视化统计任务配置的同时,还在考虑的是计算性能的提升。

当时Hadoop刚推出,还只是测试版。对于它能解决多少问题,我们心里是没底的。在百度内部已经有少量的需求在尝试使用,手工写MapReduce代码的方式。我也尝试写了一个,还是比较容易的,但有一定的学习代价。系统部有一个团队,在负责Hadoop的维护。为了保险,我把底层计算接口设计成两套,同样的代码,既可以提交到Hadoop,又可以提交到单机。在单机上用脚本串起来,模拟在集群上的运行。Hadoop本身支持将任务分割为Mapper和Reducer两个阶段,我又增加了一个Computer阶段,作用是将Reducer的结果(一般是统计数值)拿到执行机(分布式提交任务的节点),并将其插入到数据库。我当时的想法是如果Hadoop不靠谱,我就把这20台单机,组成一个小集群,管理提交的任务。当然,这样的话就实现不了单个任务的分布式化了。

整个架构图是这样的:

(图1 初版LSP平台架构图)


其中Code Engine和CWrapper是我设计和实现的,Scheduler和数据库表设计是校招新人实现的,Web UI是后来加入的实习生花了一周时间找了个网上的模板改的。日志的上传是OP同学开发的。为了说服OP同学完成部分开发工作,承诺让其将所有的数据上传之后,再更新数据库里的数据源就绪状态。在这个系统实现中,我们把PHP用到了极致,Web UI是PHP的,后端的几个模块是PHP的,就连生成的MapReduce代码,也是PHP的。有人可能会对PHP的运算性能有疑问,当时负责Hadoop维护的同学为了推动更多的人使用,承诺我们100多台机器随便用,不用考虑性能问题,缺机器了他们直接申请加,我们就没这方面的考虑。PHP的开发效率还是很高的,我的Code Engine实现任务配置到MapReduce代码的编译,最初的版本只花了我2个小时,140行代码。就这样,一个伟大的系统经过两三个月的时间拼凑完成了。其实到快发布,还没有名字。有一天经理问我叫什么,我说就叫Log Statistics Platform的前三个字母LSP,于是就有了名字(之后我为了方便记忆,让大家把平台叫做Log平台)。

平台带来了几点好处:

(1)需求响应周期大大缩短:因为对常用的三类统计做了很好的抽象,即使产品同学都能直接配置统计任务,开发周期从2天时间降低到5分钟。并且统计需求的处理,完全交还给了各个业务方,没有了需求等待时间。
(2)运维成本大大降低:由统一的系统进行任务的管理,具有依赖关系的管理,大大降低了出错带来的恢复成本。
(3)运行速度飞快:我现在仿佛还能回忆起从平台上提交第一个任务时的感觉,以前几个小时才能跑完的任务,只需要几分钟就跑完了。我之前担心的Hadoop不能覆盖所有统计需求的问题,也不存在。
(4)组员积极性变高,终于在干一件有点技术含量的事了。

下一篇:

从日志统计到大数据分析(四)——盘古开天地三 - 瓦利哥的机器岁月 - 知乎专栏zhuanlan.zhihu.com图标

编辑于 2018-06-21

文章被以下专栏收录