微信扫描登录
或者
请输入您的邮件地址来登录或者创建帐号
提 交取 消
GITBOOK.CN需要您的浏览器打开cookies设置以支持登录功能

打造又快又准的广告分析系统

本篇文章整理自Admaster资深架构师刘喆4月23日在『1024大数据技术峰会』上的分享实录:打造又快又准的广告分析系统。

enter image description here

今天讲的是打造又快又准的广告系统。

enter image description here

Admaster是做什么的呢?

以前是广告基本的监测,现在做广告的数据。

我们的挑战有哪些?

数据量大,100亿,一天。数据增长太快,不搞大数据就完蛋了。

互联网公司基本上最主要的收入来源就是广告,一提收入就要谨慎:

所以第一个要求是要准,一个不能差。今天有一万人看你的广告,明天人家找过来,怎么一万人,大约9千人,不行,一个都不能差。

第二,要快。不要说5分钟,出去跟他们说1分钟,我去看了一个广告,20秒之后就看到有人看了广告。

enter image description here

什么样的架构是好的?

好的架构是演化进来的,只要你这套架构解决你的问题就是好的,别人说你这儿有什么什么缺点,那可能你改了那些缺点的成本比你产生的价值高很多,所以不一定非要调整架构,只要它能解决你当前的问题就可以了,别人说你是不是太消极了,其实是我们还有很多更重要的事情。

架构怎么来的?

很多人认为是设计来的。一开始的时候,架构有一个人设计,大概这个样子可以干什么事情。其实随着你业务的发展和数据堆过来,你这个东西不调整不行,变变变,好多架构都是这样。

公司成立8年,几乎每年都会有一个大改动,变得越来越快。现在实时系统做到一分钟,大家猜猜用户反应是什么?用户说30秒行不行?

这个架构谁来主导?

不是架构师来做吗?这个东西要设计不是设计师来做吗?这个东西是用户提的,是不是用户来做?

其实都有,几个方面在共同做这件事情。人家问我,架构师干吗?我说扯皮吵架。说得更高大上一些,叫权衡。其实说得平民一点就是扯皮吵架, 各方面有各方面的需求,架构师面临的问题是”A的需求和 B的需求是矛盾的”,你这样跟你他扯这样扯行不行,不行,最后根据你的成本成效把大家叫到一起,你看这样行不行?架构师就干这个事。

enter image description here

今天的主要东西分享一下Admaster三个很基本的系统。

第一,数据传输系统。  
第二,数据清洗分析。  
第三,数据分析平台。  

这是几个单独的模块,可能没有大的架构图,大的架构图看起来都是差不多的,我分享一下我们做了点什么东西。希望给大家借鉴一下。

enter image description here

数据收集系统,为什么讲这个东西?

因为所有的数据要先进来,然后它主要的问题有什么东西呢?在我们现在面临主要问题:

第一个,跨广域网。我刚才其实不止一遍说了一个东西,就是我们要快快,这里提了一个词叫跨广域网,估计稍微有点感觉的同学就开始笑,跨广域网你要30秒?

第二个问题一个都不能少。我给你少传十个数据,会被打死。

第三,快快快。

开源工具有很多,最简单的有rsync、Flume、logStash还有scribe。

我们一开始很早的版本,翻以前架构图大概这个样子。

enter image description here

是左边这个图,那时候我们业务量很小,好多机器都放在同一个机房里面,大家只需要做的事情把各种机器上面的数据通过rsync放一起可以算了。现在有初创的公司,大概在20人、50人的公司基本这样。我跟好多这样公司员工还有一些同行去交流,他们就这个样子。

很快,这个架构承不住了,以前机房在北京,上海的客户开始闹。为什么你这个访问这么慢?大家应该听过以前网络名言,世界上最远的距离不是生与死,是电信和网通的距离。

我们终于有了第二个机房,架构就变了,主要机房在北京,第二个机房也有很多机器,那时候没有太高实时性的要求,保证数据OK都可以用。

机房更多了,我们发现单独一个一个往里扔好麻烦,然后我们的架构就变成这个样子,后边其实还有很多地方没有画,除了国内还有其它一些海外的机房,大家看一下跟第二个图不太一样,第二图是这个样子,第一个图看来还好,有没有感觉右边有点偏,不协调。

enter image description here

看这个图是不是美了一点?一眼看上去,这个人长了匀称一点。我们在本地汇聚,汇聚完之后再扔下去。

这是在架构设计里面直觉类的东西,你不能说它好不好?最起码看起来是好看的,就像数学一样,好的理论起码看起来是好看,看起来是难看就很不爽,难以理解。

enter image description here

再后来,机房建设成这个样子。下面一层好像没有变,但是我们看这个东西是不是更平稳了一点。有没有觉得下面中心节点像一个圆锥下面的尖?后来多了两个支撑,看起来是不是平稳一点,单纯从架构来说,架构看起来是好看,看起来是稳定,然后才能真稳定。

具体讲讲这里面做了什么事情。(结合上面3张PPT)

看这个里面,rsync,第二个版本还是rsync,这个版本把rsyns去掉了,我们不用rsync,为什么?用rsync这个东西来做是不是太low了一点,慢慢慢慢折腾,在这个版本把数据传输协议换掉了,换成了现在比较多的flume。

到这个版本里面,我们换到flume-ng做了改变,中心机房下面加了两个东西,一个叫实时计算,还有一个batch,批量计算。跟我们刚才讲的两个功能点的需求相关。我们实时是不准确的,告诉你这个数是不准的,大概不准率有多少?不准率是2%,98%数据是准的。我们真正结算和费用相关的东西是完全准确,是用了后面批量的东西,批量数据流我们做得还是保证数据完整和安全,而实时用flume-ng。

flume-ng多说一点,对我们来说有几个改进的点:

首先你看一下文档基本可以搭起来可以用,但是像我们这种结构搭完之后,第一要跨广域网,第二要保证数据安全。

它要快,够快,基本上的做法是压缩,传一大堆数据进来,一天100亿的数据,所以要压缩。flume-ng支持压缩,默认的一个压缩方式是 zip,我们设了一下,这个东西在我们的数据量级完全不适用,压缩是要靠CPU,要靠运算,cpu打得很高还是很慢。我们做的第一件事情,把压缩换掉。

第二,如果你只是本地机房里面是没有问题,跨机房的时候有问题,你把数据扔过来,开始收,不怀好意的人扔垃圾数据过来,要做加密。flume-ng本身支持加密格式,JKS加密格式,我们用了一下,发现跟它压缩一样的问题,压缩加密非常慢。

第三,把加密优化,我们用的还是flume-ng这套东西,但是我们已经换了核心组件,这就是基本上我们数据采集系统演进的东西。

enter image description here

关于数据清洗,其实是非常重要的,我从网上截了一张图,你输了一些数据本身就没有太大的价值,你研究出来的东西就没有太大的价值,所以数据清洗要干的事情,把一些没用的东西赶紧丢掉,所有错的东西丢掉,不要在这里影响。

enter image description here

一开始我们数据清洗是怎么样的?

左边那一张图,清洗之后干吗呢?

一开始的版本拿用python处理一下。当我们数据连续翻了两番这个东西搞不定,我们用了第二个版本,首先数据流过来之后,会扔到很多work上面去,我们把它通过一个SRC的东西确认一下,所有黑色的线是数据流,蓝色是信号流,你的数据全了,发来一个消息,OK,下一步可以干活,这边也会发消息,我干完什么什么。这边会有一个调度,这些所有消息应该怎么去搞。大家有没有觉得这个图丑了点,看起来那么不顺眼。

enter image description here

下一个版本, 消息流管控系统扔到MRs里面,大家看这个图是不是感觉比上一个简洁很多。

对比一下右边这个,如果大家没有听我讲,突然看到这个图,这是什么?再看这个,突然感觉世界清爽了很多。

enter image description here

到3.0的时候就变成什么样子?基本上上面两个流没有变,我们开始支持plugin,开始支持各种插件,为什么呢?

以前我们的数据清洗系统只是我们自己的部门来负责,后来有各种各样的数据接进来,各种各样的部门说,我这个数据进来应该这样清洗,这个数据进来应该这样清洗,搞着搞着我们就烦了,为什么有这么多数据,为什么这么多数据有各种方式的清洗,干脆不给你搞了,给你一个接口,这是插件,你给我,就可以清洗,我不关心你怎么清洗,你要让我写,我要问你,沟通成本很高,有了这个系统,告诉我数据怎么来,插件给我,给你配,自己解决自己的问题。

这是我们数据系统的进化的路径。

enter image description here

分析平台。

以前离线分析主要是MR on yarn,这是一开始用大数据都这样。但是现在一些从2015年、2016年开始用大数据平台的一些客户基本上都开始不搞MR,开始用Hive,用pig或者spark,感觉比MR高大上很多。接下来跑spark、pig、Hive,都扔上去。

大家有没有发现一个共同点?

on yarn,yarn作为计算资源管理平台,又要提到另一点,特别对于老板,年末和年中的时候老板问我们一个问题,今年有这么多服务器,这些钱都花在哪儿?都是哪个业务部门把资源给用了。老板开会的时候,要统计一下服务器每个部门大概用了多少,就很头疼。

后来我们把这些东西都做到yarn上面之后不头疼,要统计一下每个部门大概用了多少?给他一个链接,自己去看,很明显。这个东西都得益于我们把所有的东西都扔在yarn上。

在大数据概念里面各种开源软件,我们其实用了很多发现一个共同特点,能用非常容易,但是当你觉得这个东西很好,各种东西扔上去之后,他就开始给你整各种各样的问题,yarn里面会有什么样的问题?

给大家分享几个小例子。

首先,yarn是跑在CDH上面,有一次, 我们发现当天写上的文件会读取不了,提供的检查文件系统,一切都很好,你去读就是读不了。我们后来想尽各种方法怎么办?fsck告诉你文件在哪儿?这个机器出什么故障,不能提供服务,我们把这三台机器重启,NameNode终于认识到这个文件坏了。

那次发现当天某一个数据,原始日志都是存的,当天发现文件不可用马上恢复回来,当时把我们吓了一身冷汗,看看原码。当它发现文件坏掉的事情,做了一件事情,Datanode知道这个文件坏了, NameNode 不知道, 形成一种信息不对称,大家用5.1.2或之前的版本去看,它是有这个问题。

Yarn也有bug。所有计算都迁到yarn,不同的业务部门用你的队列,他用他的队列,大家互相共享。我们用的功能,你分一个队列就OK了。 在某一个部门里面要分子队列,这个部门太大了,分一个队列不够用,怎么办?再做一个子队列。

以前5.1.2这个东西跑得很好,升到5.5.1不工作了,都跑到另外的队列,怎么办?到底怎么回事?把这个东西一看,这个里边做了一件事情: 有个外国人的简写是XX.YY,这个人很不爽,你看你设计子队列, 用点做分隔符,我往里一提交一个人变成三个队列,这不是我想要的结果,所以怎么办?把队列里面用来分子队列的点给我换掉,让有点的人名可以加进去,我看完想抽它,社区居然同意了这种做法。他是怎么改的呢?

把里面所有的点都换成dot,这个里面就没有点,他做了一个自认为很好的事情,加了一个函数,把这个带点的名字放进来,结果这个函数只在建队列时候用到,你建队列的时候把名字换掉,调度的时候没有换,子队列没地方扔,就跑到其它地方去。

给大家讲这点小例子想说明什么呢?

开源是很好,但是不能赤膊上阵拿刀子对着干。

现在用的实时主要是两种,一个是storm/jStorm,一个是sparkstreaming。

关于storm,还有一个jStorm阿里开源的东西。Storm 是用 clojure 写的,你看见满屏的括号你就晕了,这是什么?阿里系这些人也感觉很不爽,你分明在Java上加了一层皮,阿里系用jave写的,叫jStorm,数据一致性方面做了很多改进,阿里系就用jStorm,在去年,阿里去Storm社区提议,你这个性能这么差,下一个版本直接用我们的jStorm,Storm社区同意了,从Storm2.0开始,将基于jStorm来做,不用以前那个架构。

其实我们内部也试用过,它有一个好处是什么呢?所有原来在Storm能跑的代码,在jStorm完全不用改。从稳定性上jStorm比Storm稳定很多。以前在Storm我们跑上十天左右,就挂,换上jStorm,直到去年迁机房,业务量变大,原来机房放不下, 被运维的同学问, 你们Storm集群怎么弄?才想起它来基本上是写完一扔就不用管了。

Spark streaming,代码很直观,基本上看一看大家就知道什么意思,写业务非常爽,不像java写,要构造什么类,构造什么函数,直接拿函数扔进去就好。

但它有一个致命的缺点,如果真正要做到很快,storm比它要快一些。

enter image description here

分析平台的演变我们做了几项。

pig和Hive的脚本,换了,换了用spark重写,性能提升在20%。

2.6fileoutputcommitter,当一个作业跑完要把善后东西处理掉,以前把日志汇总,后续查看,对作业没什么太大价值,想拿到结果只能等。换成2版本,可以提升30%。

Unhealthy handler提速10%。

pig on TEZ提升15%。

以上就是我今天的分享。谢谢大家。