作者：處厚，目前主要負責支付寶資料分析元件開發和通過移動開發平臺 mPaaS 對外輸出工作。本專題主要圍繞 mPaaS 移動分析服務 MAS 展開分享如何從 0 到 1 設計、構建移動分析架構。
直播回顧地址（請複製到瀏覽器中開啟）：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 技術文件，進一步瞭解更多產品功能和優勢介紹。
| 活動推薦
- 螞蟻金服 mPaaS 自辦技術沙龍 CodeDay#2 將在 5/18（週六）登陸北京中關村創業大街，本次沙龍議題圍繞支付寶如何將“自動化，智慧化，自然語言，日誌分析”等能力貼合實際業務場景做具體落地和演進，立即免費報名：t.cn/EoqXQNo
往期閱讀
《螞蟻金服 mPaaS 服務端核心元件體系概述：移動 API 閘道器 MGS》
《螞蟻金服 mPaaS 服務端核心元件：億級併發下的移動端到端網路接入架構解析》
《mPaaS 服務端核心元件：訊息推送 MPS 架構及流程設計》
關注我們公眾號，獲得第一手 mPaaS 技術實踐乾貨
釘釘群：通過釘釘搜尋群號“23124039”
期待你的加入～