数极客首页

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

设计一套日志统计平台的需求来源主要是Nslog的RD和OP同学,整理了好几十条,并出了一个基本的方案。我当时觉得实现一个提升运维管理的系统不难,难的是怎么是好用的?我很关心怎么提升需求处理的效率问题。这个时候其中一个人又被调到了一个基础库团队。也就是做这件事的就只剩我和校招新人了。而我们两个都还没做过需求处理,也不知道那几百个脚本里面都写的什么玩意儿。我说咱俩每人至少要看三个脚本,再抽查一些,看看这些脚本都有什么规律没有。我研究了之后,发现还是有些规律的。我发现常见的统计有这么三类:(1)计数统计:那个时代是流量时代,许多统计就是算PV(Page View)。一般是在Apache Web Server日志中,去用正则表达式匹配满足某些条件的记录,做计数。(2)去重统计:比如独立IP数,独立用户数等。(3)Top N统计:比如昨天检索量最大的100个Query是什么。我就问一直做统计的一位同学,这三类能不能占到所有统计需求的80%,他想了一下说有的。于是我就说咱们只要设计的系统,能够将这部分的需求处理工作量降下来,我们的系统就是成功的。这个时候技术经理又从其他团队借调了一个FE同学过来支援几周。我和校招新人都不会前端开发,这事儿没专业的人来搞不定。在接下来的两周时间,我就和FE同学研究怎么设计这部分的抽象。FE同学先提了一个方案,类似于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。设计出来的效果是这样的:

(图1 简单编辑界面)

上面是一个去重统计的例子,我选择一个日志源,点击“去重统计”按钮,生成一个模版,填写限制条件。一个统计任务就生成了。这里没有显示出来的是,每个日志源,都有一个对应的agent函数,所做的事是一段解析程序,将原始日志解析成若干个变量,如图中的去重字段部分,类似“_UserId”,这样在统计模板中就可以直接使用了。这样做了之后,可以让一个统计任务的开发工作量,降低到5分钟。还有一个问题是计算性能问题。在考虑可视化统计任务配置的同时,还在考虑的是计算性能的提升。当时Hadoop刚推出,还只是测试版。对于它能解决多少问题,我们心里是没底的。在百度内部已经有少量的需求在尝试使用,手工写MapReduce代码的方式。我也尝试写了一个,还是比较容易的,但有一定的学习代价。系统部有一个团队,在负责Hadoop的维护。为了保险,我把底层计算接口设计成两套,同样的代码,既可以提交到Hadoop,又可以提交到单机。在单机上用脚本串起来,模拟在集群上的运行。Hadoop本身支持将任务分割为Mapper和Reducer两个阶段,我又增加了一个Computer阶段,作用是将Reducer的结果(一般是统计数值)拿到执行机(分布式提交任务的节点),并将其插入到数据库。我当时的想法是如果Hadoop不靠谱,我就把这20台单机,组成一个小集群,管理提交的任务。当然,这样的话就实现不了单个任务的分布式化了。整个架构图是这样的:

(图2 初版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)组员积极性变高,终于在干一件有点技术含量的事了。平台在2009年4月正式发布后,各个团队的需求铺天盖地而来,日志源的中转上传很快就成了瓶颈。都是所有的日志源完成上传后,才开始统计计算,这样上传期间的几个小时时间就白白浪费掉了。我们首先将日志上传改成每份完成后单独打就绪标记。后来有次和Hadoop团队的同学沟通,我就提起能不能每个Mapper作为一个日志抓取的任务,这样可以让100多台机器同时抓数据,他们说没问题,已经有团队这么干。于是我们很快上线了新版本,实现分布式的抓取。架构改成了这样:

(图3 分布式抓取架构)

这时候的产品,已经是一个比较完整的产品了,我开始在公司范围内推广。本来公司里有十几个类似我们的统计团队,我就是要说服他们把任务迁移到我们平台。记得很深刻的一次是和网页搜索部的统计团队沟通,他们看了演示之后很震惊,说本来他们只是在设想这种系统的可能性,没想到你们已经做出来了。当时我们又入职了一位同学专门负责响应需求,有一天,业务部门的同学反馈说不能加他好友了(我们用的是百度自己的聊天软件Baidu Hi),我们就找Hi团队的同事咨询,他们说这位同学到了好友上限2000人,之前还没遇到过这种情况。他们的解决方案是修改人数配置,重启整个Baidu Hi服务。在整个推广的过程中,我就像拿着一款先进设备,去拯救那些水深火热的人们。我们一边推广,一边完善整个平台。从最开始平台是为统计而生,但我渐渐的发现,统计只是一类需求,其他Hadoop任务,也可以通过我们这个平台管理起来。我就想将Log平台发展为Hadoop的壳,所有提交给Hadoop的任务,都能通过Log平台管理起来。Log平台演化成一个通用计算平台。我前面提到通过三类常见统计的抽象,来解决80%的问题。但当这80%需求解决之后,你会发现又有新的80%的需求冒出来。如果让用户直接写MapReduce任务提交,这个代价太大了。平台开始上线时,提交任务就支持两种模式。一种是简单编辑,就是前面的三类抽象(后来加了更多的类别)。一种就是复杂编辑,直接贴MapReduce代码。对于后者,如果能抽象一个更好用的计算框架,将MapReduce隐藏起来,显然就又可以提升开发效率了。我就安排一个工程师(目前是我的合伙人之一)出一个方案,只用了一周时间,就设计出来原型了。下面是个例子(我们叫它DQuery):

(图4 DQuery代码样例)

对于一个输入,我们可以去选择某些字段,进行分组,每组在计数,然后输出到一个文件。这样就实现了一个统计任务。这种链式的处理方式,在现代已经很普遍了,特别是Spark里都是采用的类似表示方法。我们在2009底做了这个事情,在2011年公司号召多提交专利时,提交了发明专利。我前段时间查了一下专利的进程,已经进入了终审期。这种将数据流式的进行变换的思想,已经见诸于各大分布式计算系统,尤其在Spark上更是如出一辙。如果专利最终通过了,在国内使用Spark的地方,其实都在和我们的专利相冲突。当然,专利是百度的,只有百度有权利申诉。总之你最早去创造一些东西,是一件很有成就感的事。在给出DQuery原型后,我觉得团队太弱小了,只能有一个全职参与这件事。于是找基础库团队的同学寻求支持。他们最开始提出何不实现一个Google Sawzall,但我觉得太底层了。最终说服对方安排一位工程师参与进来。结果就是他们两个人花了2个半月,就把这个语言开发出来了。可能你会问为什么当时不选择使用Hive?事实上,那个时候Hive的工程师也来公司交流和推广了。但有两个需求不好满足:(1)任务合并:对于同一个数据源,可能有几百个统计任务。这种统计任务可能都很简单,但是都要将数据源读取一遍,也就是一个高IO低CPU的任务。我们当时想直接读取一遍,然后将多个任务同时计算,这样效率会高很多。这在Hive上是不支持的。(2)用户行为分析:我当时比较乐观,觉得我一年解决统计问题,第二年解决分析问题,第三年解决挖掘问题。事实上到现在分析问题也没解决彻底。我们知道Hive是基于SQL的,而SQL是上下文无关的。也就是说你取出的一批数据,有前后关系的话,是很难操作的。我需要在语言上支持。而在DQuery语言中,我们设计了一个方法叫process,可以嵌入用户的逻辑,非常灵活。这里要说的是DQuery是一个基于PHP语言的框架,这样DQuery表达不了的,都可以写原始PHP代码。就这样到2010年底的时候,实现了全公司日志统计全部统一到Log平台。这是我在百度八年,干的最有成就感的一件事情。推荐使用国内新一代大数据用户行为分析平台:数极客,新一代支持无埋点、前端埋点、后端埋点、API导入四种混合数据采集方式;自动监测网站、APP、小程序等多种渠道推广效果分析,是增长黑客必备的互联网数据分析工具。数极客支持实时多维分析、漏斗分析、留存分析、路径分析等十大数据分析方法以及APP数据分析网站统计网站分析小程序数据统计用户画像等应用场景,国内首创6大提升转化率的数据分析模型,是用户行为分析领域首款应用定量分析与定性分析方法的数据分析产品

。基于用户行为的大数据分析智能系统,提供了会员营销AB测试两大数据智能产品,使得企业可以快速的提升用户转化率和留存率,实现数据驱动增长。本文采用「CC BY-SA 4.0 CN」协议转载学习交流,内容版权归原作者所有,如涉作品、版权和其他问题请联系「我们」处理。

发表评论

评论已关闭。

相关文章