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

【受訪人簡介】

[[158417]]

 吳磊·友盟公司數(shù)據(jù)平臺負(fù)責(zé)人

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

 移動大數(shù)據(jù)分析平臺的架構(gòu)思想及演進(jìn)

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

Lambda混合架構(gòu)思想

友盟數(shù)據(jù)平臺整體架構(gòu)

友盟的架構(gòu)思想是借鑒了Lambda的混合架構(gòu)體系，其核心思想是既能兼顧低延遲的計算需求，同時也能具有處理需要處理全量數(shù)據(jù)的能力，最后通過將兩部分的視圖聚合起來提供外部服務(wù)。Lambda架構(gòu)是由批處理層，快速處理層，和服務(wù)層三部分組成，整個體系也比較簡單，通過視圖層的聚合就能將兩部分計算結(jié)果合并起來提供一個完整的視圖。系統(tǒng)維護(hù)的代價也比較低。

友盟數(shù)據(jù)流水線

結(jié)合友盟的業(yè)務(wù)架構(gòu)和Lambda架構(gòu)思想，最終的系統(tǒng)如上圖，友盟為APP集成提供手機、平板、盒子的SDK，APP通過SDK將日志返回到平臺的Nginx，負(fù)載均衡之后送到基于Finagle框架的日志接收器，之后流入數(shù)據(jù)接入層。使用兩個 Kafka 集群來承擔(dān)數(shù)據(jù)接入功能，上面Kafka集群被實時計算消費，下面kafka用于離線數(shù)據(jù)消費，兩個集群之間通過Kafka的Mirror功能進(jìn)行同步。主要目的是IO負(fù)載的分離，避免離線部分過大的IO請求影響到實時計算部分及實時離線部分的業(yè)務(wù)解耦，方便兩部分業(yè)務(wù)獨立發(fā)展。接下來是數(shù)據(jù)計算層，分別由離線計算層和實時計算層組成。

離線部分，主要是基于Hadoop Mapreduce框架開發(fā)了一系列的MR任務(wù)。同時使用Hive建立數(shù)據(jù)倉庫，使用pig進(jìn)行數(shù)據(jù)挖掘，現(xiàn)在也在逐步使用Spark來承擔(dān)數(shù)據(jù)挖掘相關(guān)的工作。實時部分是通過storm來進(jìn)行流式計算。實時部分，最終計算結(jié)果會存儲到 MongoDB，離線部分的數(shù)據(jù)存儲在 HDFS 。離線分析的結(jié)果存儲在 HBase 。因為 HBase 缺少二級索引的相關(guān)功能，所以引入了 Elastic Search 來為 HBase 相關(guān)表提供索引查詢功能。最后通過統(tǒng)一的 REST Service 來對外提供數(shù)據(jù)服務(wù)。

數(shù)據(jù)接入層讓Kalfka集群承擔(dān)，后面由Storm消費，存儲在MongoDB里面，通過Kafka自帶的Mirror功能同步，兩個Kafka集群，可以分離負(fù)載。計算有離線和實時兩部分，實時是Storm，離線是Hadoop，數(shù)據(jù)挖掘用Hive，分析任務(wù)，正在從Pig遷移到Spark平臺，大量的數(shù)據(jù)通過計算之后，存儲在HFDS上，最后存儲在HBase里面，通過ES來提供多級索引，以彌補HBase二級索引的缺失。

#p#

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

1）數(shù)據(jù)采集

數(shù)據(jù)采集面臨以下三大挑戰(zhàn)：

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

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

友盟主要采集數(shù)據(jù)以下三方面：

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

2）數(shù)據(jù)清洗

友盟通過三個方面對數(shù)據(jù)清洗，分別是：唯一標(biāo)識、數(shù)據(jù)標(biāo)準(zhǔn)化、數(shù)據(jù)格式。

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

數(shù)據(jù)標(biāo)準(zhǔn)化。型號、地域識別、時間識別三角度來考慮

1. 型號。采訪中，吳磊表示，友盟設(shè)備指數(shù)，是一個在移動行業(yè)關(guān)注度非常高的指數(shù)，有當(dāng)前活躍設(shè)備的排名，故能否精確識別手機機型就很重要?？刹⒉皇谦@取一個Model字段都很容易，如小米3是當(dāng)前活躍量很大的一款機型，但其Model字段有多達(dá)xxx個型號，那就必須把這些型號都對應(yīng)到小米3這一款機型上。關(guān)于多機同型的問題，吳磊給舉了一個有趣的案例，m1這個Modle，在2014年年末計算時，突然發(fā)現(xiàn)m1設(shè)備在3年之后又一次開始突增了，經(jīng)過仔細(xì)發(fā)現(xiàn)原來是另一款m開頭的對手廠家一個爆款手機Model字段也是叫m1。類似這樣的事情現(xiàn)在有，將來也會發(fā)生，這是大數(shù)據(jù)處理中繞不開的坑。
2. 地域識別。通常是依靠IP地址來實現(xiàn)的，國內(nèi)的IP地址管理并不規(guī)范，會出現(xiàn)真實地址有偏移的情況。對此會記錄一天內(nèi)出現(xiàn)最多次出現(xiàn)的地域來判定其所屬地。
3. 時間問題。如使用的是客戶時間，但因客戶機器時間設(shè)置不一致等情況及SDK的發(fā)送策略問題，經(jīng)常導(dǎo)致和服務(wù)器時間不一致，會帶來很多問題，如是否需要向前補算等。

數(shù)據(jù)格式。Json、Thrift、Protobuf等。

3)數(shù)據(jù)計算

吳磊在采訪中表示，數(shù)據(jù)計算會占用數(shù)據(jù)平臺工程師大部分的時間，數(shù)據(jù)計算分為實時計算、離線計算、準(zhǔn)實時計算三部分，以下是這三部分計算各自需要面臨的挑戰(zhàn)：

實時計算：時效性問題是實時計算首要面對的，從實時上考慮，就不能放一些太復(fù)雜的計算。突發(fā)流量沖擊大多會發(fā)生在晚上10：00到12：00之間，就是睡前刷一刷。這樣一來，就會產(chǎn)生一些延遲，如果延遲特別嚴(yán)重，就得臨時擴容來應(yīng)對，好在Lambda的架構(gòu)很靈活，能夠保證有能力很方便的進(jìn)行擴容。因Lambda計算架構(gòu)有實時和離線部分是兩套代碼，產(chǎn)生誤差是必然。為了不會讓實時部分偏差太大，一般最長也是天級任務(wù)，到凌晨就會清理，而且數(shù)據(jù)會在離線計算時得到糾正。

離線計算：數(shù)據(jù)傾斜是貫穿離線計算始終的問題，因數(shù)據(jù)傾斜幾乎是天然存在的，如大App數(shù)據(jù)量是小App幾萬倍，如不及時處理就會不斷放大，最后會對效果產(chǎn)生嚴(yán)重影響，不同數(shù)據(jù)傾斜會有不同應(yīng)對方法，通常對最常見傾斜問題，會通過進(jìn)一步細(xì)分再匯總的辦法來解決。還有因離線計算數(shù)據(jù)量大，就需處處壓縮，通過時間換取空間，那資源調(diào)度的問題就接踵而來。好在任務(wù)有優(yōu)先級，通過改造Hadoo的公平調(diào)度算法來保證大任務(wù)能得到充分的計算資源在可接受的范圍內(nèi)計算完畢。

準(zhǔn)實時計算：對于延遲有一定敏感但又不適合放置在離線任務(wù)中運算的，稱為準(zhǔn)實時計算。如下載服務(wù)，消息推送中的圈人服務(wù)等，最早是通過mini batch的方式，不斷提交mr任務(wù)完成，最近通過實驗驗證使用Spark Streaming 來作這事比較適合。

3）數(shù)據(jù)存儲與數(shù)據(jù)安全

數(shù)據(jù)存儲分為，在線存儲、在線存儲數(shù)據(jù)緩存三部分：

• 在線存儲。讀寫均衡（主要分清讀寫的請求哪個更多，來進(jìn)行優(yōu)化，例如實時部分，讀和寫是比較均衡的，采用了MongoDB，但是離線計算寫遠(yuǎn)遠(yuǎn)大于讀，需要對HBase進(jìn)行優(yōu)化）
• 離線存儲。數(shù)據(jù)壓縮，數(shù)據(jù)生命周期
• 數(shù)據(jù)緩存。橫向擴展，預(yù)加載 TWME搭建 redis 集群

吳磊表示， 數(shù)據(jù)安全做大數(shù)據(jù)的人會關(guān)注，也是所有做數(shù)據(jù)的人都非常關(guān)注的問題。事實上安全是有很多個維度的，有從技術(shù)方面，有產(chǎn)品策略方面，還有有政策方面安全等等。

友盟在數(shù)據(jù)安全方面首先有自己的商業(yè)底線，就是絕對不采集用戶的敏感數(shù)據(jù)，如個人用戶識別數(shù)據(jù)、手機號碼、，地理位置信息等。其次，友盟數(shù)據(jù)計算結(jié)果，需要完全認(rèn)證才能訪問，就是說每個用戶只能訪問自己的數(shù)據(jù)，永遠(yuǎn)不可能訪問其他人的數(shù)據(jù)。最后，進(jìn)行數(shù)據(jù)處理時，團(tuán)隊與團(tuán)隊之間的信息是隔離的，如離線處理這部分的工程師，看到都是一些經(jīng)過脫敏的數(shù)據(jù)，是不可能知道這些數(shù)據(jù)屬于哪個APP。

 友盟移動大數(shù)據(jù)平臺在數(shù)據(jù)增值方面采取哪些方法

談到數(shù)據(jù)增值，吳磊先給記者分析了當(dāng)前移動互聯(lián)網(wǎng)的發(fā)展行情，現(xiàn)在移動互聯(lián)網(wǎng)的紅利已經(jīng)接近尾聲，就說是說靠移動互聯(lián)網(wǎng)本身的迅猛發(fā)展給開發(fā)者用戶增長的可能性已經(jīng)很渺茫。所以提高自身產(chǎn)品的吸引力或其他營銷手段增加用戶活躍度，才能使得開發(fā)者的產(chǎn)品得到更好的發(fā)展。友盟大數(shù)據(jù)平臺可以助開發(fā)者們一臂之力，這是現(xiàn)在乃至未來友盟給客戶提供的主要服務(wù)。

采訪最后，吳磊表示為了能夠更好的服務(wù)于客戶，友盟能做的就是讓現(xiàn)有的這些龐大數(shù)據(jù)增值起來。那如何能夠讓數(shù)據(jù)增值呢？

其一：內(nèi)部數(shù)據(jù)打通，友盟不光是做統(tǒng)計分析，還有即時通訊、社會化分享、工具推薦等業(yè)務(wù)。 把這些業(yè)務(wù)的數(shù)據(jù)盡可能的進(jìn)行橫向打通，這樣一來，就可以用戶自身的自定義事件，進(jìn)行一些有針對性的推送。

其二，用戶畫像。友盟還和其他的數(shù)據(jù)方合作，給用戶進(jìn)行畫像，這樣就可以進(jìn)行更加精準(zhǔn)的推送。用戶畫像可以根據(jù)現(xiàn)有的數(shù)據(jù)更精準(zhǔn)的自己用戶屬性和興趣、行為等方面。

其三：設(shè)備評級。對于APP開發(fā)者來說，更解渠道的推廣效果，如哪些渠道進(jìn)行推廣更有價值用戶，哪些渠道推廣的用戶價值小，或哪些渠道有作弊行為，推廣全是一些虛假的用戶。

其四，APP健康度評估。通過APP健康度能使開發(fā)者了解自己這一款A(yù)PP當(dāng)前是處于生命周期哪個階段，是屬于快速增長階段、平穩(wěn)發(fā)展階段，還是屬于衰減階段。這樣就能更好了解自己的產(chǎn)品目前的健康狀況。同時也能了解自身產(chǎn)品，如用戶群體里有多少是垃圾設(shè)備，有多少是有價值設(shè)備。