作者：处厚，目前主要负责支付宝数据分析组件开发和通过移动开发平台 mPaaS 对外输出工作。本专题主要围绕 mPaaS 移动分析服务 MAS 展开分享如何从 0 到 1 设计、构建移动分析架构。直播回顾地址（请复制到浏览器中打开）：http://t.cn/EoVbajX
0. 移动分析的过去与未来
移动分析，这个名字其实不够全面，本质上是“移动数据分析”。因此我们接下来讨论的具体业务问题虽然仍在数据统计分析的范畴，但由于移动端应用的蓬勃发展，因此我们将具体业务与 BI、数据仓库等技术深度结合，并逐步推演沉淀了移动分析架构设计的思考。
移动数据分析在发展初期和现阶段的情况已经是完全不同：
发展初期：从业务层面看，App 处于蓝海市场时获客容易，因此研发团队有条件更关注业务发展，专注开发好用的 App 来吸引客户；从技术层面看，BI/数据仓库技术曲高和寡，仍旧运行在大型企业中，如运营商、能源机构等。同时，开源数据平台还处在初级阶段。 现阶段：经过了多年的高速发展，移动数据分析已经进入了成熟期，App 厂商需要应对严厉的市场竞争才能存活。因此业务团队一方面需要更加熟悉 App 运营状况，精细化运营客户，另一方面，Hadoop 作为基础的大数据平台产品已经相对成熟，不仅方便于数据开发，对于自建大数据平台而言也非常适配。 而市面上众多提供数据分析服务的公司能够坚持到现在，也足以说明相关能力确实在解决移动开发者的相应痛点： 1、App 已经下发，那么 App 的运行情况实际如何？ 2、用户的数量及以后的增长趋势如何评估 3、App 中的哪些功能是实际上受用户喜爱和欢迎的？ 4、用户画像（用户所在区域、用户使用设备的价位、用户使用 App 的频次）这些问题，如果解决起来，和线上耦合性较小。但是直接使用线上的数据库来做则是非常困难，而且消耗很大，这就需要使用数据仓库技术，来处理移动数据，形成指标报表，从而深度支持业务方完成运营决策，更精准地展开用户运营；或者形成 AI 算法，提供新的用户服务。
那么，我们今天探讨一下，如何从 0 到 1 设计、构建一个移动分析平台。
1. 移动分析架构简析
大数据平台架构的层次划分没啥标准，主要是由于应用的分类横纵交错，因此基于大部分数据平台架构的共性基础上，我们总结归纳了一些思路，方便大家理解和应用到实际业务中。首先，我们将大数据平台架构划分为“四横一纵”：
四横：数据采集、数据处理/分析、数据访问 应用 一纵：管控体系开发管理，数据管理, 运维管理等等属于数据管理体系中非常重要的部分，目标是逐步完善四层架构体系，并将移动数据分析处理体系这样的来复枪变成机关枪，强大而快速。
2. 移动分析架构详解
【数据采集】
数据采集部分，我们可以将具体工作分为两块：
日志采集接口：接受移动端上报数据，并将接受的日志落盘。这个模块一般需要自己开发。 采集传输工具：监听日志文件，将落盘的问题读出，发送至需要的数据存储端，例如 HDFS, Kafka 等。这个模块一般可以采用开源或者商业的组件：Apache Flume, Elastic Logstash，Aliyun Logtail 等等。两者虽然可以合在一起，但是一般都是分开来，分开管理的好处是显而易见的：灵活，高并发，吞吐量兼顾。
除了采集 App 数据之外，针对数据库数据的采集，一般选用 Hadoop 大数据套件中专门用来采集关系型数据库的 Sqoop。对于关系型数据库的 mySQL，MariaDDB，Oracle，SQLServer 等都可以使用它来进行数据采集，快速健壮。当然除了 Sqoop 之外，Datax，kettle 甚至 Hive 都可以作为选型考虑。
基于 mPaaS 移动分析服务 MAS 产品本身日志类型较简单，同时产品使用需要兼顾速度以及灵活支持后端数据通道和存储，我们最终使用了 Apache Flume 以及 Hive 作为选型组合。
【数据处理、分析】
根据数据处理场景要求不同，可以划分为离线、实时流处理、即席查询等等。
在这个部分，可能也是要分两个部分：基础组件和业务流程。基础组件有较大共性，而业务流程因为不同的业务团队而差异较大，从而有不同的设计和实践方案，因此不能一概而论。接下来我们围绕 mPaaS 的数据计算流程进行简单解析：
离线部分离线是数据计算的基石，也是最早发展起来的。Hadoop/Hive/Spark 现在基本成为现在开源离线数据处理的标配。基于 Hive/Spark 构建分布式数据仓库，可以支持相对复杂的数据集分析场景，擅长海量的数据分析计算，但是运行时间来说相对较长。因此对计算时间不敏感的数据可以通过这种方式来进行处理，一般情况下的第二天凌晨开始计算，能够完成前一天业务数据的计算并导出。
基于 Hive/Spark，我们可以使用 SQL 非常灵活地开发 ETL 任务，对数据完成清洗，转换与加载。在做离线开发时，由于比较强调逻辑模型和分层设计，因此我们普遍用数仓的知识来指导开发。
一般而言，我们会使用纬度建模，也叫星型模型。为了分析方便，商业纬度往往会被分成不同层次，并融合到数据模型中。对应的，分层设计中我们主要分为接入层，汇总层和应用层。 
[图为页面访问接口数据处理过程]
以 mPaaS MAS 的离线为例，ETL 中接入事实表，从数据库同步的 10 张维度表为接入层，对数据汇总后，形成了庞大的中间层，最后形成了面向设备分析、留存分析、页面分析、漏斗分析等应用层。
实时流计算离线计算只能提供 N 个小时之前的数据计算结果，这对业务方而言，效率实在太低。在相当多的业务场景下，比如淘宝的双十一大促大盘，当前的计算结果需要被实时获取，从而时刻更新消费总额。因此，实时流计算便延伸出来，Spark Streaming、Storm(triden)/JStorm/Flink 是目前最常见的几种实时流计算技术，他们分别在吞吐量以及准确性上各善其场。
目前，mPaaS MAS 使用 JStorm/Kepler 技术，其中 JStorm 是一个分布式实时计算引擎，类似 Hadoop MapReduce。用户按照规定的编程规范实现一个任务，将任务提交到 JStorm 上，JStorm 即可将任务 7*24 小时调度起来。核心原理如下图：
JStorm 提交运行的程序称为 Topology。Topology 处理的最小的消息单位是一个Tuple，也就是一个任意对象的数组。Topology 由 Spout 和 Bolt 构成。Spout 是发出 Tuple 的结点。Bolt 可以随意订阅某个 Spout 或者Bolt 发出的 Tuple。Spout 和 Bolt 都统称为 Component。
即席查询对大量数据进行多维分析的情况下，传统的 SQL 数据库是远远不能满足需要的。ES/Druid 等提供了高效的索引，在分布式的情况下，支持亿级数据量以及秒级多维查询。目前在众多商业公司中得到的极广的应用与落地。
蚂蚁金服在 Druid 基础上，开发了 Explorer 从而更加完善地支持 SQL 与 mysql-jdbc-driver。Druid 列式设计可最大限度地减少 I/O 争用，后者是导致分析处理发生延迟的主要原因。列式设计还可提供极高的压缩率，那么可有效将其性能提高一倍。
Druid 协议层提供 MySQL 协议的接口，通过 mysql-jdbc-driver，可以向 Explorer 发起 insert,select 请求；而计算层基于 Drill，支持多种类型的存储，集群线性扩展，执行计划可定制；存储层则基于 Druid，拥有针对 OLAP 特有的存储格式和计算能力。Explorer 整体架构如下图：
对于 MAS 自定义分析中，因无法预先确定用户自定义聚合规则，以及属性维度，因此选择了 Explorer，并利用其强大的预聚合能力来支撑。在 Kepler/JStorm 实时计算拓扑中，仅需根据用户自定义的属性维度，切分后实时插入 Explorer 即可完成聚合。
数据访问
通过数据平台对于数据处理和分析之后，产出了大量的数据指标等内容，放在 HDFS 上，可以通过 Hive/Sqoop 等技术，将数据从 HDFS 中，回流到在线系统中，提供高速访问。
Hbase/OTS 等列式存储引擎提供了大容量，高性能，高可用的能力，查询速度在毫秒级，对于百亿级别的查询也是可以支持，同时具备了一定的高可用性。限制的部分仅仅需要通过 rowkey 或者 rowkey 的前缀进行范围查询。
MySQL 等数据库，针对数据量小的统计结果，可以存放到 SQL 数据库中，对于查询等操作同样非常方便。
在上一个小节，我们已经介绍过 ES/Druid 等即席查询数据库。它们对于多维分析可以提供极其有效的帮助。对于一些数据精细化分析的业务场景，通过数据漏斗等方式可以先删掉大量无效数据，结合自定义的多维分析，能够有效提升分析的效率和质量。
应用
指标
经过以上各个阶段，我们已经完成了业务数据的各项计算，得到了针对 App 的版本，渠道、iOS/Android 平台、业务纬度等聚合的计算结果，从而获取到针对“新增、累计用户、设备、渠道”等各项分类数据。
日志管理
围绕日志管理功能，我们需要再提到 ES 工具。基于 ES 的全文索引能力，其可以提供非常强大的日志查询回放能力。对于定位错误，辅助开发都有非常好的作用。
异常管理
移动端因为离开发者较远，因此无法像 server 端可以快速的看到错误。因此，针对移动端所面临的闪退、卡顿卡死等现象进行日志采集，有助于更好地优化产品体验，同时支持应用快速发版，也是现在敏捷开发的重要保证和支持。
管控体系
有了离线计算，实时流式计算以及应用积累的业务数据，管控平台的建设需要提上日程。它的作用就是催化上述分析能力以及相关数据，从而帮助业务方持续不断地优化分析方式来使用数据，将步枪升级为冲锋枪。
对于离线、实时计算的开发管理、数据管理、运维管理等模块，一般都是集成在数据平台这个层次上。开源系统也提供了 Hive Web Interface 等工具，但是功能还比较弱。 |调度系统|Oozie|azkaban|Zeus| |---|---|---|---| |离线 SQL 开发|Hue|Zepplin|| |元数据管理|Hive|实时需要自行开发||
mPaaS 移动分析服务 MAS
mPaaS，即mobile PaaS，简单来说它是源于支付宝技术的一个移动开发平台，包含了移动开发、测试、发布、分析、运营各个方面的云到端的一体化的解决方案。
移动分析服务 MAS 在 mPaaS 产品体系中，定位是支持移动端应用进行数据采集和分析，帮助业务方展开精细化、智能化运营，同时结合应用日志采集与分析等功能从而帮助开发团队更快、更精确地找到问题并快速修复。此外，移动分析能力在蚂蚁金服内部经历了双 11、双 12 等高并发大促业务的挑战和锤炼。
目前，mPaaS 移动分析服务 MAS 已经在支付宝香港版、印度 Paytm、印尼 Dana、上海地铁、华夏银行等多个项目中完成能力输出和落地应用。欢迎阅读 [移动分析服务 MAS](https://tech.antfin.com/docs/2/49561) 技术文档，进一步了解更多产品功能和优势介绍。 **| 活动推荐** - **蚂蚁金服 mPaaS 自办技术沙龙 CodeDay#2 将在 5/18（周六）登陆北京中关村创业大街，本次沙龙议题围绕支付宝如何将“自动化，智能化，自然语言，日志分析”等能力贴合实际业务场景做具体落地和演进，立即免费报名：http://t.cn/EoqXQNo**  > **往期阅读** > >[《开篇 | 蚂蚁金服 mPaaS 服务端核心组件体系概述》](https://juejin.im/post/5c088b8ce51d45721d7101fa) > >[《蚂蚁金服 mPaaS 服务端核心组件体系概述：移动 API 网关 MGS》](https://juejin.im/post/5c1088c7f265da61193bb12a) > >[《蚂蚁金服 mPaaS 服务端核心组件：亿级并发下的移动端到端网络接入架构解析》](https://juejin.im/post/5c25ddbce51d45690a253270) > >[《mPaaS 服务端核心组件：消息推送 MPS 架构及流程设计》](https://juejin.im/post/5c63ab376fb9a049f43bce85) > >[《mPaaS 服务端核心组件：移动分析服务 MAS 架构解析》](https://juejin.im/post/5c808afe6fb9a049c8503bb4) #### 关注我们公众号，获得第一手 mPaaS 技术实践干货 >  > 钉钉群：通过钉钉搜索群号“23124039” 期待你的加入～