分享架构实践，搞移动互联网数据分析不得不看！

在日前的 nfoQ ArchSummit（全球架构师峰会）上，友盟高级技术总监叶谦分享了一些友盟数据平台的整体架构实践经验，很多伙伴要演讲速记。刚巧，友盟君发现【chinastor】阿明同学已经梳理了一份详文，借花献佛了。

友盟早在 2010 年就专注移动开发者平台，在叶谦看来，数据是移动互联网的主旋律。从友盟 24 小时采样数据绘成的全球移动互联网用户活跃度的图像中，可以看出，中国居于全球最为突出的区域。

作为开发者服务平台的先入者，友盟覆盖的终端设备已经遍布世界各地。四年多以来，围绕数据，友盟都做了什么呢？

来看友盟统计分析产品包括的多个系统：

友盟数据平台已经累积了超过 5PB 的移动互联网历史数据，并且这些数据正以每天 5TB 的速度快速增长。伴随着数据量增长而来的，是来自 SDK 、服务系统等等方面的经验和教训。

• SDK 方面的教训——控制再控制，首先要控制好 SDK 大小，SDK
  模块化设计，不同功能可以自行组合，针对游戏、云用户、移动用户等提供模块化和社会化分享服务，开发者可以自行选择控制数据包大小，这是移动互联网比较普世的经验，也是友盟的实践之道。

• 其次，控制数据包大小，使用二进制数据包格式 thrift 方式传输。

• 再控制方面，控制与服务端交互策略。采用多种发送模式，来满足实际业务需求；此外，对数据包去重，进行多重校验；其次，SDK端按规则调整的同时加上了服务端动态控制。

国外某大数据专家 Nathan Marz and James Warren 的书里，提到的大数据架构包括了：批量处理层、服务层、速度实施层三层架构的精髓。批量处理层是运行在一段时间真正的循环，从头开始不断重新计算批量视图 ；服务层是一个可扩展的数据库，对于用户来说，查询是两个方面同时查；速度层只处理新的数据，因为任何老数据都被服务层所占有，被批量处理层所吸引住。

但有一个问题，对于移动互联网的用户来说，如何快速迭代？快速迭代往往意味着取舍选择！有几个核心问题：

快速网络接入，对于 BGP 8线 或者 BGP双线如何选择？

快速系统搭建，对于传统 SQL 数据库或者新兴 NoSQL 数据库如何选择？友盟使用了 Twitter 系的开源软件。

快速 Scale up,对于软件架构升级还是硬件升级如何选择？友盟采用了 SSD 存储技术解决了问题。

其实，需求驱动是最合适的演进方向。

存储空间不够怎么办？友盟统计平台每天数据增长很快，由此友盟对压缩算法做了改进，LZO to LZMA。

容量大且能支持小量在线访问的数据库？采用容量大并且能支持小量在线访问的数据库 HBASE+KVProxy，目前友盟有 20 万的开发者，但在线不高，因此采用了这样的系统，将大量数据放在 HBASE 里面，最大一个表有几十 TB 的规模。

如何支持自定义的任务调度需求？友盟自行研发了任务调度系统。从任务调度的需求来看，依赖比较复杂，有常规周期时间点调度，a 任务依赖 b 任务，有了 b 任务才能进行的调度等等，友盟调度系统可以提供适合的方式。

对于需求驱动来看，如何更有效率地按 App 组织数据？友盟自定义索引格式 App index，根据 LZO 方式做了该格式，逻辑方式和 LZO 相似。

对于需求驱动更有意思的方面，如何才能得到更准确的设备标识？实际上，设备标识问题多，如安卓山寨多，各种 ROM，各种安卓系统的设备泛滥；苹果系统封闭，可用的设备标识一直在变。

对于这些实际情况，友盟改进设备标识方案，两个思路基于较为简单的规则，兼容老的标识体系；基于图的分析方法，不兼容老的标识体系。

现在，友盟的应用统计分析、游戏统计分析、社会化分享组件、消息推送四大类产品线早已推出，目前广泛服务于移动开发者。

感兴趣可以登录友盟官网 www.umeng.com 进行了解，了解本文更多详细内容，请点击查看！