友盟吴磊： 移动大数据平台的架构、实践与数据增值

APP做为进入移动互联网的重要载体得到越来越多开发者的关注，做APP，开发、产品、运营、推广等每个环节都离不开海量数据的支持。这样一来， 如何采集，存储，整理，分析，挖掘海量数据成为开发者们面临的紧要问题。友盟从2010年成立至今，在这方面有独特技术和宝贵经验，51CTO对友盟数据 平台负责人吴磊进行专访，就移动大数据平台的底层架构演进、实践经验与数据增值等内容进行了分享。

【受访人简介】

吴磊，友盟公司数据平台负责人。目前主要负责Umeng移动数据分析平台的软件研发和系统架构。拥有10多年的软件开发经验，先后在大型通讯系 统，通用搜索引擎以及海量数据分析等领域工作。在基础平台架构和海量数据处理方向有多年的深厚积累，对Hadoop等大数据领域相关技术在具体工作中的落 地有深刻的实践和体会。

移动大数据分析平台的架构思想及演进

当问及加入友盟之后和之前工作有何不同时，吴磊这样回答，“之前工作主要是做数据搜索，大数据的源头和搜索引擎有分不开的联系，可以说，大数据是 从搜索开始的，加入友盟之后，工作和之前有很多相似之处，只是最终的目标不一样。友盟架构很多方面和搜索引擎架构是有很多共通性的，但友盟有更多自己的特 点，因为其更注重于数据分析。”

数据平台整体架构

友盟的架构思想是借鉴了lambda的混合架构体系，其核心思想是既能兼顾低延迟的计算需求，同时也能具有处理需要处理全量数据的能力，最后通过 将两部分的视图聚合起来提供外部服务。Lambda架构是由批处理层，快速处理层，和服务层三部分组成，整个体系也比较简单，通过视图层的聚合就能将两部 分计算结果合并起来提供一个完整的视图。系统维护的代价也比较低。

数据流水线

结合友盟的业务架构和Lambda架构思想，最终的系统如上图，友盟为APP集成提供手机、平板、盒子的SDK，APP通过SDK将日志返回到平 台的Nginx，负载均衡之后送到基于Finagle框架的日志接收器，之后流入数据接入层。使用两个 Kafka 集群来承担数据接入功能。上面Kafka集群被实时计算消费。下面kafka用于离线数据消费，两个集群之间通过Kafka的Mirror功能进行同步。 主要目的是IO负载的分离，避免离线部分过大的IO请求影响到实时计算部分；以及实时离线部分的业务解耦，方便两部分业务独立发展。接下来是数据计算层， 分别由离线计算层和实时计算层组成。

离线部分，主要是基于Hadoop Mapreduce框架开发了一系列的MR任务。同时使用Hive建立数据仓库，使用pig进行数据挖掘，现在也在逐步使用Spark来承担数据挖掘相关的工作。实时部分是通过storm来进行流式计算。

实时部分，最终计算结果会存储到 MongoDB，离线部分的数据存储在 HDFS 。离线分析的结果存储在 HBase 。因为 HBase 缺少二级索引的相关功能，所以引入了 Elastic Search 来为 HBase 相关表提供索引查询功能。最后通过统一的 REST Service 来对外提供数据服务。

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

友盟移动大数据平台在数据采集、清洗、计算方面踩过的坑

1）数据采集

数据采集面临一下三大挑战：

• 大流量。 友盟服务大量开发者，接受数以亿计的设备发来日志，每天要处理80亿次对话，数据量非常大。
• 高并发。 如用户在早上上班路上，中午吃饭后以及晚上睡觉前，是使用的高峰期，这些时候会造成出非常高的并发请求。
• 扩展性。 因为移动互联网是在高速发展的，最开始一台机器发展可能需要10台，20台，如果系统没有横向扩展能力将会是很痛苦的事情。

为了快速上线，友盟在2010年的数据平台是基于RoR开发，在后台通过Resque进行一些离线的处理。这个架构很快就跟不上移动互联网的发展速度，面临巨大的数据压力，不调整是不性的。

之后就切换到基于Finagle Server的日志服务器，Finagle Server是推ter开源出来的一个异步服务器框架，很适合移动互联网访问特点：高并发，小数据量。切换到Finagle Server之后，单台服务器的处理能力得到了极大的提升。同时日志收集服务的无状态特性可以支持横向扩展，即使面临非常高压力时也可简单的通过增加临时 服务器来应对。

友盟主要采集数据以下三方面：

• 设备的基本情况。 如说它的CPU，它的型号，它的内存的大小啊这些基本数据。
• 启动数据。 如APP在什么时候具体哪个点启动，启动了多少次，这种是启动数据。
• 事件数据。 事件需要是根据每个APP不同来自己定义 ，要以APP的开发者自身需求为依据。如说需要知道某些事件发生的次数或时间等，根据要求按需发送。

2）数据清洗

友盟通过三个方面对数据清洗，分别是：唯一标识、数据标准化、数据格式。

唯一标识。移动统计分析可以使用设备ID来作为标识符。 但也会遇到问题，吴磊在采访中以Android设备为例，对这部分进行了详细分享：

安卓设备通常可以拿来作为设备标识的是 IMEI， MAC， 和Android ID，可安卓设备的碎片化和开放性，导致得到数据变得不是那么容易。由于Android的开放性，各种刷机rom横行， 会出现一些设备MAC地址完全一样的情况，还有部分山寨机则会出现公用IMEI的问题。同样还有一些安卓设备是没有IMEI的，如平板和盒子。

针对这一问题，友盟采用统一计算和机器学习来应对，统一计算就是综合以上提到的三种设备ID，按一定的算法来计算出唯一的ID，对于重复的 IMEI，MAC地址，Andriod ID等数据加入计算黑名单，在计算时不予采用。机器学习就是通过基于图的分析方法，来讲计算设备标识。

数据标准化。型号、地域识别、时间识别等角度考虑。

• 型号：采访中，吴磊表示，友盟设备指数，是一个在移动行业关注度非常高的指数，有当前活跃设备的排名。所以是否能够精确识别手机机型就很重 要。 但并不是获取一个Model字段都很容易，如小米3是当前活跃量很大的一款机型，但其Model字段有多达xxx个型号，那就必须把这些型号都对应到小米 3这一款机型上。关于多机同型的问题，吴磊给举了一个有趣的案例，m1这个Modle，在2014年年末计算时，突然发现m1设备在3年之后又一次开始突 增了，经过仔细发现原来是另一款m开头的对手厂家一个爆款手机mModel字段也是叫m1。类似这样的事情现在有，将来也会发生，这是大数据处理中绕不开 的坑。
• 地域识别：通常是依靠IP地址来实现的，国内的IP地址管理并不规范，会出现真实地址有偏移的情况。对此会记录一天内出现最多次出现的地域来判定其所属地。
• 时间问题：最开始使用的是客户时间，但因客户机器时间设置不一致等情况及SDK的发送策略问题，经常导致和服务器时间不一致，会带来很多问题，例如是否需要向前补算等。

数据格式。Json、Thrift、Protobuf等。

3)数据计算

吴磊在采访中表示，数据计算会占用数据平台工程师大部分的时间，数据计算分为实时计算、离线计算、准实时计算三部分，以下是这三部分计算面临的挑战：

实时计算：时效性问题是实时计算首要面对的，从实时上考虑，就不能放一些太复杂的计算。突发流量冲击大多会发生在晚上10：00开始到12：00结束，就 是睡前刷一刷。会产生一些延迟，如果延迟特别严重会临时扩容，Lambda的架构很灵活，保证了有能力很方便进行扩容。误差，lambda的计算架构，实 时和离线部分是两套代码，产生差异是必然的。为了不会让实时部分偏差太大，一般最长也是天级任务。到凌晨就清理了。这样数据会在离线计算时得到纠正。

离线计算：数据倾斜是贯穿离线计算始终的问题，因为数据倾斜几乎是天然存在的，如大App数据量是小App几万倍，如不及时处理，会不断放大，最后会对效 果产生严重影响，不同的数据倾斜会有不同的方法，通常对最常见的倾斜问题，会通过进一步细分然后再汇总的办法来解决。还有因为离线计算数据量大，就得处处 压缩，通过时间换取空间，那么资源调度的问题就来了，任务是有优先级的，通过改造Hadoo的公平调度算法来保证大任务能得到充分的计算资源在可接受的范 围内计算完毕。

准实时计算：对于延迟有一定敏感但又不适合放置在离线任务中运算的，称为准实时计算。如下载服务，消息推送中的圈人服务等，最早是通过mini batch的方式，不断提交mr任务完成，最近通过实验验证使用spark streaming 来作这事比较适合。

3）数据存储与数据安全

数据存储分为，在线存储、在线存储数据缓存三部分：

在线存储。读写均衡（主要分清读写的请求哪个更多，来进行优化，例如实时部分，读和写是比较均衡的，采用了MongoDB，但是离线计算写远远大于读，需要对HBase进行优化）

离线存储。数据压缩，数据生命周期

数据缓存。横向扩展，预加载 TWME搭建 redis 集群

吴磊表示， 数据安全做大数据的人会关注，也是所有做数据的人都非常关注的问题。事实上安全是有很多个维度的，有从技术方面，有产品策略方面，还有有政策方面安全等等。

友盟在数据安全方面首先有自己的商业底线，就是绝对不采集用户的敏感数据，如个人用户识别数据、手机号码、，地理位置信息等。其次，友盟数据计算 结果，需要完全认证才能访问，就是说每个用户只能访问自己的数据，永远不可能访问其他人的数据。最后，进行数据处理时，团队与团队之间的信息是隔离的，如 离线处理这部分的工程师，看到都是一些经过脱敏的数据，是不可能知道这些数据属于哪个APP。

友盟移动大数据平台在数据增值方面采取哪些方法

谈到数据增值，吴磊先给记者分析了当前移动互联网的发展行情，现在移动互联网的红利已经接近尾声，就说是说靠移动互联网本身的迅猛发展给开发者用 户增长的可能性已经很渺茫。所以提高自身产品的吸引力或其他营销手段增加用户活跃度，才能使得开发者的产品得到更好的发展。友盟大数据平台可以助开发者们 一臂之力，这是现在乃至未来友盟给客户提供的主要服务。

采访最后，吴磊表示为了能够更好的服务于客户，友盟能做的就是让现有的这些庞大数据增值起来。那如何能够让数据增值呢？

其一：内部数据打通，友盟不光是做统计分析，还有即时通讯、社会化分享、工具推荐等业务。 把这些业务的数据尽可能的进行横向打通，这样一来，就可以用户自身的自定义事件，进行一些有针对性的推送。

其二，用户画像。友盟还和其他的数据方合作，给用户进行画像，这样就可以进行更加精准的推送。用户画像可以根据现有的数据更精准的自己用户属性和兴趣、行为等方面。

其三：设备评级。对于APP开发者来说，更解渠道的推广效果，如哪些渠道进行推广更有价值用户，哪些渠道推广的用户价值小，或哪些渠道有作弊行为，推广全是一些虚假的用户。

其四，APP健康度评估。通过APP健康度能使开发者了解自己这一款APP当前是处于生命周期哪个阶段，是属于快速增长阶段、平稳发展阶段，还是 属于衰减阶段。这样就能更好了解自己的产品目前的健康状况。同时也能了解自身产品，用户群体里面有多少是垃圾设备，有多少是有价值的设备。