【MDCC 2015】友盟数据平台负责人吴磊：移动大数据平台的架构与实践

转自： http://www.csdn.net/article/2015-10-20/2825962

 

【MDCC 2015】友盟数据平台负责人吴磊：移动大数据平台的架构与实践

 

【CSDN现场报道】10月14日-16日，“ 2015移动开发者大会 · 中国” （Mobile Developer Conference China 2015，简称MDCC 2015）在北京新云南皇冠假日酒店隆重举行。本次大会由全球最大中文IT社区CSDN和中国最具关注度的全方位创业平台创新工场联合主办，以“万物互 联，移动为先”为主题，邀请国内外业界领袖与技术专家共论移动开发的热点，在实践中剖析技术方案与趋势。

友盟数据平台负责人 吴磊

移 动互联网的无处不在催熟了大数据平台，而中国互联网正在面临从IT时代到DT时代的变革，移动互联网与大数据几乎是一种相生相伴的关系。回归到App研 发，到后期尤为须要数据与运营。友盟从2010年开始就专一于移动大数据，5年来不只积累了大量的数据，并且拥有着丰富的技术与经验，那么，友盟大数据平 台有着怎样的架构与实践？今天在这里与你们分享一下。

1、架构

架构思想

友盟架构主要参考了Twitter提出的Lambda架构思想。如上图所示，最下面是快速处理层，新增数据在快速处理层计算，这部分数据比较小，能够快速完成，生成实时视图。同时，新增数据会并入全量数据集，进行批处理，生成批处理视图。这样，系统同时具备了低延迟实时处理能力，也具备离线大数据处理能力。以后经过数据服务层，把两个视图合并起来，对外提供服务。

数据平台总体架构

根 据友盟的业务特色，数据平台由下向上分红这几个部分：最基础的是日志收集，接下来进入离线计算和实时分析，计算后的结果，会进行数据挖掘，有价值的数据进 入数据仓库。接下来会提供一个基于REST Service的数据服务，在此服务之上作各类数据应用，例如：报表、数据分析报告、数据下载等。两边的部分提供辅助的功能，包括任务调度和监控管理。

数据流水线

结 合友盟的业务架构和Lambda架构思想，最终的系统以下图所示：最左边是数据采集层，友盟提供手机、平板、盒子的SDK给App集成，App经过SDK 发送日志到友盟平台；首先进入到Nginx，负载均衡以后传给基于finagle框架的日志接收器，接着来到数据接入层。

数 据接入层让Kalfka集群承担，后面由Storm消费，存储在MongoDB里面，经过Kafka自带的Mirror功能同步，两个Kafka集群，可 以分离负载；计算有离线和实时两部分，实时是Storm，离线是Hadoop，数据挖掘用Hive，分析任务，正在从Pig迁移到Spark平台，大量的 数据经过计算以后，存储在HFDS上，最后存储在HBase里面，经过ES来提供多级索引，以弥补HBase二级索引的缺失。

2、实践

通 过以上的介绍，你们可能对整个大数据平台的结构和概念有了初步的了解。正如Linux之父Linus Torvalds的名言——“Talk is cheap, show me the code!”同样，其实知道是相对容易的，难的是如何去实现。因此接下来，我给你们分享一些友盟在实践中获得的一些经验。

数据采集

首先是从数据采集来讲起，数据采集部分面临了很大的挑战，首当其冲即是大流量、高并发和扩展性。友盟的数据平台经历了一个发展的过程。在2010年刚开始的时候，由于快速上线的要求，咱们是基于RoR开发的，在后台经过Resque进行一些离线的处理。这个架构，随着互联网的爆发，面临巨大的数据压力，很快就不能适用了。

接 下来，咱们就切换到基于Finagle Server的日志服务器。这个Finagle Server是Twitter开源出来的一个异步服务器框架，很适合移动互联网的访问特色：高并发、小数据量。切换到Finagle Server以后，单台服务器的处理能力获得了极大的提高。同时日志收集服务的无状态特性能够支持横向扩展，因此当面临很是高压力的时候能够简单地经过增 加临时服务器来解决。

数据清洗

大数据的特色之一是数据多样化，若是不进行清洗会对后面的计算产生困扰。在数据清洗方面，咱们花了不少精力，并踩了不少的坑。

• 惟一标识

作数据分析，第一件事情就是要拿到“惟一标识”。Android系统里做为惟一标识的，经常使用的是IMEI、MAC、Android ID。首先，由于Android碎片化问题，经过API在采集这些数据的时候，经常会有采集不到的状况。

还 有其余一些异常的状况，好比有不少山寨机没有合法的IMEI，因此会不少机器共用一个IMEI，致使IMEI重复；有些ROM刷机后会更改MAC地址，导 致MAC重复；大部分电视盒子自己就没有IMEI。这种状况下咱们单纯用IMEI或者MAC，或者Android ID ，来进行标识的话，就会出现问题。

对此，咱们采用的办法是由单独的服务来统一计算。后台会有离线任务来进行计算，发现重复率很高的标识符，加入到黑名单里。在计算的时候，直接跳过黑名单里的标识，换用另外一种算法进行计算。

• 数据标准化

咱们在“数据标准化”方面也遭遇过不少坑，好比：“设备型号”，并非直接采集model个字段就能够解决的。拿小米3举例，这个手机会有不少版本，不一样的批次model字段不同。对于这种状况，若是不进行统一标准化，算出来的结果确定有问题。

此外，还会出现多机一型的状况，例如m1，在2011发布的三年后活跃设备数量发生突增。调查发现，原来是其对手厂家在2014年末生产了一款畅销的产品，model字段也叫m1。所以，咱们就须要把设备型号，经过专门手段来和产品名称对应上，统一标准化。

在数据标准化过程当中，还会遇到“地域识别”的问题。地域识别是用IP地址来识别的。由于中国IP地址管理并非很是规范，因此常常会出现，上一秒钟你们还在北京，下一秒就到深圳的状况。对于解决这样的问题，咱们是选用设备一天中最常出现的IP地址做为当天的地域标识。

还 有“时间识别”，也是很大的问题。最开始咱们采用的都是客户端时间。可是客户时间有很大的随意性，用户的一个错误设置，就会致使时间不一致；另一些山寨 机会有Bug，机器重启以后，时间直接就变成1970年1月1号了；还有一种可能，产生数据的时候没有网络链接，在从新联网时日志才会汇报到平台，这样的 话数据就会产生延迟。

为了解决这些时间不一致的问题，咱们统一使用服务器端时间。可是这样又带来了新的问题：统计时间和真实时间的差别，可是这个差别值是从小时间窗口（例如一个小时，或一天）观察出来的，从大的时间窗口来看是正确的。

• 数据格式的归一化

友盟SDK通过不少版的进化，上报上来的日志会有多种格式。早期时采用JSON格式，后期则使用Thrift的格式。在数据平台处理的时候，两种格式切换很麻烦，所以在处理以前，咱们把它统一成 Protobuf ，来进行后期计算。

数据计算

在数据计算的时候，根据不一样业务对于时延的容忍程度的高低，分为实时计算，离线计算和准实时计算。

实 时计算，面临的挑战之一是时效性。由于实时计算是对延时很是敏感的，毫秒级的水平。若是说你把不合适的计算，好比一些很耗CPU的计算放进来，会直接致使 实时计算的延迟。因此在架构时，须要考量把哪些放到实时部分合适，哪些不适合。另外，实时计算每每会在写数据库时产生IO延迟，须要对实时数据库进行专门 优化。对此，咱们在实时计算部分选用了MongoDB存储数据，同时不断优化MongoDB的写请求来解决这个问题。

另一个挑战是突发流量。用户使用App的频率并不均匀，早中晚会有很高的使用率，尤为是晚上10:00-12:00这个时间段会对咱们系统带来很是大的压力，得益于以前的架构设计，在达到必定的阈值以后，会触发报警，运维的同窗会进行临时扩容来应对这些突发流量。

因 为实时计算一般是增量计算，会产生偏差积累的问题。Lambda架构决定了实时和离线是两套独立的计算系统，因此必然会出现偏差。若是长时间使用实时计算 的结果，这个偏差会愈来愈大。如今解决的办法是在实时处理时，不要给太大的时间窗口，好比说最多不要超过一天，超过一天以后，就要开始清理，离线部分的计 算天天计算一次，保证在这个时候离线部分的数据计算完成，这样就能够用离线的数据来覆盖实时数据，从而消除这个数据偏差。

离线计算，也会面临一些问题。最常遇到的麻烦是数据倾斜问题。数据倾斜这个事情，几乎是自然存在的，好比说一些大App的数据量，和小App的数据量存在着巨大的差距，经常会在离线计算的时候产生长尾现象，并行的MR做业中老是有一两个任务拖后腿，甚至超出单机计算能力。

产 生数据倾斜的缘由有不少种，针对不一样的缘由，有不一样的解决办法。最多见的缘由是由于粒度划分太粗致使的，好比说咱们计算的时候，若是以App ID来进行分区，很容易致使数据倾斜。针对这种状况，友盟的解决办法的是进行更细一步的划分，好比经过App ID加设备ID进行分区，而后再将结果聚合起来，这样就能够减小数据倾斜的发生。

第二个问题是数据压缩的问题。离线计算的时候，每每输入输出都会很大，所以咱们要注意时时刻刻进行压缩，用消耗CPU时间来换取存储空间的节省。这样作可以节省数据传输中的IO延迟，反而可以下降整个任务的完成时间。

接下来会面临资源调度的困难，由于各类任务优先级是不同的，好比一些关键的指标，要在特定时间算出来，有些任务则是早几个小时均可以。Hadoop自带的调度器不管是公平调度仍是能力调度器都不能实现咱们的需求，咱们是经过修改Hadoop的度器代码来实现的。

另 外还有一类任务对时延比较敏感，可是又不适合放到实时计算中的。这类任务咱们称之为准实时任务。例如报表的下载服务，由于是IO密集型任务，放入实时不太 合适，可是它又对时间比较敏感，可能用户等三五分钟仍是能够接受的，可是等一两个小时就很难接受了。对于这些准实时任务咱们以前采用的是经过预留必定资源 来运行MR来实现的。如今用Spark Streaming专门来作这些事情。

在进行准实时计算时，里面也有一个资源占用的问题，在预留的过程当中，会致使你的资源占用率太低，如何平衡是个问题；第二点不少实时计算的任务，每每也采用了增量计算模式，须要解决增量计算的偏差累计问题，咱们经过必定时间的全量计算来弥补这个缺陷。

数据存储

数 据存储，根据咱们以前的计算模式，也分为在线存储和离线存储两部分。在实时部分的计算结果主要存在MongoDB里面，必须对写IO进行优化。离线数据计 算结果通常存储在HBase里。可是HBase缺乏二级索引。咱们引入了Elastic Search，来帮助HBase进行索引相关的工做。

在 作数据服务的时候经过数据缓存可以解决数据冷热的问题。友盟数据缓存用的是Redis，同时使用了TwemProxy来做负载均衡。友盟在数据缓存这方面 的经验就是须要预加数据，好比：天天凌晨计算完数据以后，在用户真正访问以前，须要把部分计算结果预先加载上去，这样等到用户访问的时候，就已经在内存里 了。

数据增值

整个大数据的系统，价值最大的部分，就在于数据增值，友盟目前数据增值主要分两个大的方向。首先是内部数据打通，基于用户事件，结合用户画像、以及和阿里百川合做提供更多的维度信息，来为开发者提供更精准的推送。好比，对一个汽车电商类App，能够圈定一部分有车的用户来推送汽车配件相关信息，而后圈定一部分无车用户来推送售车相关信息。

此外，在数据挖掘方面也作了不少工做。针对现有的设备，进行用户画像相关计算，经过用户画像可以了解用户的属性和兴趣，方便后续的数据横向打通。同时，还针对一些做弊行为设计提供了设备评级产品。

经过数据平台的统计算法和机器学习算法，把现有的全部设备进行评级，哪些是垃圾设备，哪些是真实设备，可以很好的识别出来。这样一来，若是开发者有相关需求，咱们能够提供设备评级相关指标，来帮助开发者测评这些推广渠道，到底哪些可信，哪些不可信。

更多精彩内容，请关注新浪微博：@CSDN移动，图文直播专题：2015移动开发者大会。