APP是進入移動互聯網的重要載體，故得到越來越多開發者的關注。打造APP，無論是開發、產品、運營、推廣等任意一個環節都離不開海量數據的支持。這樣一來，怎樣采集，存儲，整理，分析，挖掘海量數據成為開發者們面臨的重大挑戰。友盟從2010年成立至今，在這方面有獨特技術和寶貴經驗，51CTO對友盟數據平臺負責人吳磊進行專訪，就移動大數據平臺的底層架構演進、實踐經驗與數據增值等內容進行了交流。

【受訪人簡介】

[[158417]]

 吳磊·友盟公司數據平臺負責人

吳磊，友盟公司數據平臺負責人。目前主要負責Umeng移動數據分析平臺的軟件研發和系統架構。擁有10多年的軟件開發經驗，先后在大型通訊系統，通用搜索引擎以及海量數據分析等領域工作。在基礎平臺架構和海量數據處理方向有多年的深厚積累，對Hadoop等大數據領域相關技術在具體工作中的落地有深刻的實踐和體會。

 移動大數據分析平臺的架構思想及演進

當問及加入友盟之后和之前工作有何不同時，吳磊這樣回答，“之前工作主要是做數據搜索，大數據的源頭和搜索引擎有分不開的聯系，可以說，大數據是從搜索開始的，加入友盟之后，工作和之前有很多相似之處，只是最終的目標不一樣。友盟架構很多方面和搜索引擎架構是有很多共通性的，但友盟有更多自己的特點，因為其更注重于數據分析。” 

Lambda混合架構思想

友盟數據平臺整體架構

友盟的架構思想是借鑒了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二級索引的缺失。

#p#

友盟移動大數據平臺在數據采集、清洗、計算方面踩過的坑

1）數據采集

數據采集面臨以下三大挑戰：

• 大流量。友盟服務大量開發者，接受數以億計的設備發來日志，每天要處理80億次對話，數據量非常大。
• 高并發。如用戶在早上上班路上，中午吃飯后以及晚上睡覺前，是使用的高峰期，這些時候會造成出非常高的并發請求。
• 擴展性。因為移動互聯網是在高速發展的，最開始一臺機器發展可能需要10臺，20臺，如果系統沒有橫向擴展能力將會是很痛苦的事情。

為了快速上線，友盟在2010年的數據平臺是基于RoR開發，在后臺通過Resque進行一些離線的處理。這個架構很快就跟不上移動互聯網的發展速度，面臨巨大的數據壓力，不調整是不行的。之后就切換到基于Finagle Server的日志服務器，Finagle Server是Twitter開源出來的一個異步服務器框架，很適合移動互聯網訪問特點：高并發，小數據量。切換到Finagle Server之后，單臺服務器的處理能力得到了極大的提升。同時日志收集服務的無狀態特性可以支持橫向擴展，即使面臨非常高壓力時也可簡單的通過增加臨時服務器來應對。

友盟主要采集數據以下三方面：

• 設備的基本情況。如說其CPU、型號、內存大小等基本數據。
• 啟動數據。如APP在何時何地啟動，啟動次數等。
• 事件數據。事件需要根據每個APP不同來自己定義，以APP開發者自身需求為依據。如需知某些事件發生的次數或時間等，根據要求按需發送。

2）數據清洗

友盟通過三個方面對數據清洗，分別是：唯一標識、數據標準化、數據格式。

唯一標識。移動統計分析可以使用設備ID來作為標識符。但也會遇到問題，吳磊在采訪中以Android設備為例，對這部分進行了詳細分享：安卓設備通常可以拿來作為設備標識的是 IMEI， MAC， 和Android ID，可安卓設備的碎片化和開放性，導致得到數據變得不是那么容易。由于Android的開放性，各種刷機rom橫行， 會出現一些設備MAC地址完全一樣的情況，還有部分山寨機則會出現公用IMEI的問題。同樣還有一些安卓設備是沒有IMEI的，如平板和盒子。針對這一問題，友盟采用統一計算和機器學習來應對，統一計算就是綜合以上提到的三種設備ID，按一定的算法來計算出唯一的ID，對于重復的IMEI，MAC地址，Andriod ID等數據加入計算黑名單，在計算時不予采用。機器學習就是通過基于圖的分析方法，來將計算設備標識。

數據標準化。型號、地域識別、時間識別三角度來考慮

1. 型號。采訪中，吳磊表示，友盟設備指數，是一個在移動行業關注度非常高的指數，有當前活躍設備的排名，故能否精確識別手機機型就很重要。可并不是獲取一個Model字段都很容易，如小米3是當前活躍量很大的一款機型，但其Model字段有多達xxx個型號，那就必須把這些型號都對應到小米3這一款機型上。關于多機同型的問題，吳磊給舉了一個有趣的案例，m1這個Modle，在2014年年末計算時，突然發現m1設備在3年之后又一次開始突增了，經過仔細發現原來是另一款m開頭的對手廠家一個爆款手機Model字段也是叫m1。類似這樣的事情現在有，將來也會發生，這是大數據處理中繞不開的坑。
2. 地域識別。通常是依靠IP地址來實現的，國內的IP地址管理并不規范，會出現真實地址有偏移的情況。對此會記錄一天內出現最多次出現的地域來判定其所屬地。
3. 時間問題。如使用的是客戶時間，但因客戶機器時間設置不一致等情況及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當前是處于生命周期哪個階段，是屬于快速增長階段、平穩發展階段，還是屬于衰減階段。這樣就能更好了解自己的產品目前的健康狀況。同時也能了解自身產品，如用戶群體里有多少是垃圾設備，有多少是有價值設備。