移動(dòng)互聯(lián)網(wǎng)的接入使得傳統(tǒng)PC端的數(shù)據(jù)收集已經(jīng)不能滿足目前業(yè)務(wù)的需求，移動(dòng)大數(shù)據(jù)的收集處理分析也成為所有企業(yè)不可回避的問題。相比于終端較為統(tǒng)一的PC年代，移動(dòng)終端的多樣性、流量、網(wǎng)絡(luò)、功能等諸多因素都限制著移動(dòng)大數(shù)據(jù)的收集。如何在不影響用戶體驗(yàn)的情況下做到準(zhǔn)確、快速的收集？51CTO

【W(wǎng)OT2015"互聯(lián)網(wǎng)＋"時(shí)代大數(shù)據(jù)技術(shù)峰會(huì)】特邀講師阿里無線事業(yè)部基礎(chǔ)架構(gòu)線主管陳武分享手淘應(yīng)對(duì)每天億萬級(jí)UV的數(shù)據(jù)采集手段。

陳武：花名 蒼井，阿里巴巴集團(tuán)無線事業(yè)部無線事業(yè)部基礎(chǔ)架構(gòu)線技術(shù)主管。曾就職于91無線，騰訊。13年加入阿里一直從事業(yè)務(wù)開發(fā)，深知業(yè)務(wù)線對(duì)埋點(diǎn)的痛點(diǎn)之后帶團(tuán)隊(duì)參試手淘埋點(diǎn)監(jiān)控體系建設(shè)。

以下是采訪實(shí)錄：

Q:手淘是如何進(jìn)行數(shù)據(jù)收集的？

陳武:目前手淘通過客戶端埋點(diǎn)的方式采集數(shù)據(jù)。埋點(diǎn)方案常見的有兩種：一種是頁面埋點(diǎn)，這種一般是在架構(gòu)層理已經(jīng)做好了。另外一種是一些控件點(diǎn)擊和自定事件的埋點(diǎn)這種通常是開發(fā)手工埋的。

Q:移動(dòng)大數(shù)據(jù)收集 VS PC大數(shù)據(jù)收集的有什么差異？

陳武：首先從設(shè)備維度看，中國有7億的手機(jī)網(wǎng)民，而且一直保持著高速增長，手淘的日志量也基本是每年翻一翻，在DT時(shí)代的進(jìn)程中，移動(dòng)設(shè)備漸漸成為了主流的數(shù)據(jù)的生產(chǎn)者，移動(dòng)互聯(lián)網(wǎng)巨大的流量給的服務(wù)器的連接能力和計(jì)算能力提出了極大的挑戰(zhàn)。另外，移動(dòng)設(shè)備跟貼近用戶，移動(dòng)數(shù)據(jù)呈現(xiàn)出更多的用戶屬性：比如用戶的位置信息，用戶的性別，用戶的語音信息，用戶的健康情況，甚至是用戶的喜怒哀樂在移動(dòng)端都能被數(shù)據(jù)化，可見移動(dòng)數(shù)據(jù)的私密性比PC數(shù)據(jù)要高很多，用戶對(duì)數(shù)據(jù)安全的考慮要求我們?cè)谝苿?dòng)數(shù)據(jù)安全上比PC更加嚴(yán)格。移動(dòng)設(shè)備比PC更具有多樣性，中國的手機(jī)從幾百元到幾千元機(jī)型性參差不齊，再加上中國特色的山寨機(jī)市場，在方案設(shè)計(jì)上就需要考慮到不同機(jī)型，耗電，內(nèi)存，cpu占用等性能指標(biāo)。

 其次是移動(dòng)互聯(lián)網(wǎng)的網(wǎng)絡(luò)特性，PC的數(shù)據(jù)采集流量基本是不需要考慮的，而在手機(jī)端流量成本會(huì)直接影響到用戶成本，也是需要重點(diǎn)考慮的。PC的網(wǎng)絡(luò)相對(duì)穩(wěn)定，而移動(dòng)互聯(lián)網(wǎng)要應(yīng)對(duì)頻繁的強(qiáng)弱網(wǎng)絡(luò)切換的場景，弱網(wǎng)如何保障傳輸也是我們要考慮的點(diǎn)。

再次是交互層級(jí)，移動(dòng)端的交互邏輯比PC端要復(fù)雜的多。手機(jī)的屏幕本身比較小，導(dǎo)致它的層級(jí)很深。而手淘非常重視整個(gè)交易的鏈路的，鏈路上下文參數(shù)的透傳上也是比PC端復(fù)雜很多，比如手淘的詳情頁面我們需要記錄這些頁面的流量地圖，在埋點(diǎn)的時(shí)候就必須track這些流量的來源作為不同業(yè)務(wù)方的結(jié)算依據(jù)。

還有技術(shù)框架問題，整個(gè)移動(dòng)端的框架要比Web框架要復(fù)雜很多。在Web端有一些標(biāo)準(zhǔn)的Html標(biāo)簽，通過spm.webx框架很容易實(shí)現(xiàn)自動(dòng)化埋點(diǎn)。但在手機(jī)端的框架內(nèi)并沒有一個(gè)特別標(biāo)準(zhǔn)的語義,以及Reactive Native框架，webApp框架，Native和H5嵌套，C和OC，C和java的各種語言混編，雙十一的各種native到H5的降級(jí)方案靈活切換都給手淘的埋點(diǎn)增加了很多的復(fù)雜度。

總之，如何在數(shù)據(jù)量，數(shù)據(jù)質(zhì)量，性能，成功率以及實(shí)時(shí)性上做權(quán)衡，是移動(dòng)數(shù)據(jù)采集面臨的最難題。

Q:手淘是如何解決移動(dòng)端數(shù)據(jù)采集的難點(diǎn)的？

陳武:首先，性能問題我們的埋點(diǎn)sdk會(huì)有自身監(jiān)控，這些監(jiān)控會(huì)記錄關(guān)鍵代碼的性能指標(biāo)和到達(dá)率指標(biāo)，在服務(wù)端我們按版本建立監(jiān)控的基線來保證我們的sdk自身的性能是不斷優(yōu)化的。具體到優(yōu)化的方法也是很多的：比如我們?cè)诠?jié)約流量提升下行到達(dá)率方面做了配置增量更新方案，通過聚合埋點(diǎn)來提升計(jì)算性能，按照事件的優(yōu)先級(jí)做了不同的上傳策略來保證實(shí)時(shí)性，通過動(dòng)態(tài)窗口調(diào)整的算法，保證***的帶寬利用。其次，在交易鏈路方面問題我們會(huì)通過阿里的SPM（super position model）和TPK(transparent key)標(biāo)志在框架層做透傳。***，混合編程問題，我們?cè)趕dk提供了C層，JS層的埋點(diǎn)bridge確保下游業(yè)務(wù)方可以方便的調(diào)用我們的埋點(diǎn)代碼。

Q:如何儲(chǔ)存收集上來的數(shù)據(jù)？

陳武:這里就涉及到了后端架構(gòu)，我們?cè)?**層是adash服務(wù)器，它負(fù)責(zé)數(shù)據(jù)流的接收和解碼工作，解碼之后按消費(fèi)的業(yè)務(wù)場景拆分到不同的數(shù)據(jù)流。第二層是阿里的TT流，TT流負(fù)責(zé)消費(fèi)adash的數(shù)據(jù)。TT的另外一端連接我們的實(shí)時(shí)計(jì)算galaxy系統(tǒng)和離線存儲(chǔ)的ODPS云梯系統(tǒng)，最終將數(shù)據(jù)落地到我們的云服務(wù)器上。負(fù)責(zé)數(shù)據(jù)產(chǎn)品的業(yè)務(wù)系統(tǒng)可以分別從galaxy上產(chǎn)出實(shí)時(shí)監(jiān)控報(bào)表，以及從ODPS上產(chǎn)出離線監(jiān)控報(bào)表。

Q:如何處理處理異常數(shù)據(jù)？

陳武:異常數(shù)據(jù)我們會(huì)評(píng)估處理的成本，如果是低優(yōu)先級(jí)的數(shù)據(jù)，我們可能會(huì)直接丟棄，如果是高優(yōu)先級(jí)的數(shù)據(jù)（比如財(cái)報(bào)數(shù)據(jù)），我們會(huì)對(duì)這些數(shù)據(jù)做一些事后的清洗。

 從以往的case看，通常遇到的是重復(fù)數(shù)據(jù)和臟數(shù)據(jù)兩種情況，比如重復(fù)數(shù)據(jù)的清洗，簡單來說我們會(huì)認(rèn)為一臺(tái)手機(jī)不會(huì)在同一毫秒產(chǎn)生2條相同的日志，所以就按照這個(gè)算法對(duì)ODPS中有問題的小時(shí)表，按照設(shè)備ID和時(shí)間做投影對(duì)數(shù)據(jù)庫做一輪去重。這種清洗通常是需要耗費(fèi)很大的計(jì)算成本。

  還有一種是在客戶端的清洗，舉個(gè)例子詳情業(yè)務(wù)存在一個(gè)自定義打點(diǎn)，后來版本升級(jí)改動(dòng)將頁面名稱從shop變成了sp，那么在統(tǒng)計(jì)PV上就會(huì)出錯(cuò)，這時(shí)候我們可以通過下發(fā)配置在埋點(diǎn)sdk里面對(duì)數(shù)據(jù)做訂正，在源頭上糾正錯(cuò)誤日志。這種情況節(jié)約了很多服務(wù)端的計(jì)算成本，但是要考慮配置到達(dá)率和時(shí)效性的問題。

日常工作中我們也會(huì)通過建立一些中間表來累積清理規(guī)則，對(duì)于符合這些表里的數(shù)據(jù)，我們可以選擇清理或者是保留。

Q:如何保證SDK在性能與數(shù)據(jù)量上的平衡？

陳武:首先是數(shù)據(jù)【分級(jí)】，我們會(huì)把淘寶的數(shù)據(jù)按照業(yè)務(wù)劃分，性能數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)，接著對(duì)這些數(shù)據(jù)設(shè)定優(yōu)先級(jí)，像UV、GMV以及實(shí)時(shí)計(jì)算數(shù)據(jù)這些都享有非常高的優(yōu)先級(jí)，我們會(huì)按優(yōu)先級(jí)來傳數(shù)據(jù)，優(yōu)先級(jí)低的數(shù)據(jù)我們可以用更低級(jí)別的線程來處理。另外就是【采樣】，我們的網(wǎng)絡(luò)性能埋點(diǎn)一天有上百億的點(diǎn)，這些點(diǎn)不涉及業(yè)務(wù)結(jié)算，只是用來監(jiān)控網(wǎng)絡(luò)成功率的，我們可以通過配置控制的采樣率，對(duì)樣本抽樣做監(jiān)控即可。***可以通過【聚合】來提升性能，以計(jì)數(shù)的點(diǎn)為例，我們只要把一段時(shí)間內(nèi)的相同點(diǎn)的值做累加，最終把一段時(shí)間內(nèi)的多個(gè)點(diǎn)聚合成一個(gè)點(diǎn)上報(bào)，可以很好的控制了日志的埋點(diǎn)頻率。聚合的方式提升了性能，但是如果在聚合的過程中異常退出了，就可能損失一部分?jǐn)?shù)據(jù)，所以我們只是針對(duì)低優(yōu)先級(jí)的點(diǎn)位做了聚合處理。

Q:雙十一，你最擔(dān)心的問題是什么？

陳武:在雙十一期間流量會(huì)暴漲，今年還有大型晚會(huì)，可以預(yù)見今年一定會(huì)出現(xiàn)流量極端暴漲的情況。因此在容災(zāi)方面我比較擔(dān)心，流量上去了會(huì)不會(huì)把服務(wù)器打爆，會(huì)不會(huì)把網(wǎng)卡打爆？數(shù)據(jù)量暴增的時(shí)候下游的數(shù)據(jù)產(chǎn)出是否會(huì)延時(shí)？我們平時(shí)會(huì)模擬大流量的情況，做全鏈路壓測，梳理各個(gè)節(jié)點(diǎn)性能瓶頸，為雙十一保駕護(hù)航。

Q:在災(zāi)備方面手淘是如何做的？

陳武:容災(zāi)這塊需要客戶端和服務(wù)端一起做，客戶端災(zāi)備無外乎控制數(shù)據(jù)量和請(qǐng)求數(shù)，但這二者是相對(duì)矛盾的。如果把請(qǐng)求數(shù)降低，那么就意味著只能把用戶上傳log時(shí)間調(diào)大，這樣的好處就是服務(wù)器的qps降低了，然而客戶端堆積的日志就變大了，服務(wù)器解碼也變大了，下游產(chǎn)出時(shí)間變長了，所以需要按照顧下游服務(wù)器的計(jì)算能力合理的權(quán)衡上傳間隔和數(shù)據(jù)量。我們?cè)陔p十一的時(shí)候會(huì)對(duì)客戶端做多級(jí)的降級(jí)預(yù)案，會(huì)根據(jù)服務(wù)器的水位推送不同級(jí)別的配置，保證客戶端高級(jí)別的數(shù)據(jù)能夠全量上傳，低級(jí)別的數(shù)據(jù)能夠盡可能的上傳。

另外在服務(wù)器端容災(zāi)，我們核心業(yè)務(wù)都是異地多活， 在故障時(shí)可以快速遷引流量，保證服務(wù)的持續(xù)可用。在業(yè)務(wù)層按業(yè)務(wù)做集群隔離，像手淘、天貓、聚劃算雙十一相關(guān)的業(yè)務(wù)系統(tǒng)單獨(dú)集群，其它業(yè)務(wù)會(huì)被放到另外集群。重要的數(shù)據(jù)會(huì)存多份，采集服務(wù)器如果丟失數(shù)據(jù)，可以根據(jù)一些日志流水進(jìn)行部分?jǐn)?shù)據(jù)恢復(fù)。

***還有系統(tǒng)的測壓保障，我們已經(jīng)在雙十一之前做過多次全鏈路的流量放大壓測，除此之外還會(huì)有各種下游業(yè)務(wù)的降級(jí)預(yù)案。

11月深圳WOT，我們聊大數(shù)據(jù)