友盟吳磊： 移動大數據平臺的架構、實踐與數據增值

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當前是處于生命周期哪個階段，是屬于快速增長階段、平穩發展階段，還是 屬于衰減階段。這樣就能更好了解自己的產品目前的健康狀況。同時也能了解自身產品，用戶群體里面有多少是垃圾設備，有多少是有價值的設備。