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

admin

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

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

Admaster是做什么的呢？

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

我们的挑战有哪些？

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

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

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

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

什么样的架构是好的？

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

架构怎么来的？

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

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

这个架构谁来主导？

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

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

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

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

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

数据收集系统，为什么讲这个东西？

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

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

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

第三，快快快。

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

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

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

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

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

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

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

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

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

具体讲讲这里面做了什么事情。（结合上面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这套东西，但是我们已经换了核心组件，这就是基本上我们数据采集系统演进的东西。

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

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

左边那一张图，清洗之后干吗呢？

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

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

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

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

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

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

分析平台。

以前离线分析主要是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比它要快一些。

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

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

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

Unhealthy handler提速10%。

pig on TEZ提升15%。

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

原文地址：
http://gitbook.cn/books/57107c89 ... /1461912820571.html