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

【WOT2015"互聯(lián)網＋"時代大數據技術峰會】特邀講師阿里無線事業(yè)部基礎架構線主管陳武分享手淘應對每天億萬級UV的數據采集手段。

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

以下是采訪實錄：

Q:手淘是如何進行數據收集的？

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

Q:移動大數據收集 VS PC大數據收集的有什么差異？

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

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

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

還有技術框架問題，整個移動端的框架要比Web框架要復雜很多。在Web端有一些標準的Html標簽，通過spm.webx框架很容易實現自動化埋點。但在手機端的框架內并沒有一個特別標準的語義,以及Reactive Native框架，webApp框架，Native和H5嵌套，C和OC，C和java的各種語言混編，雙十一的各種native到H5的降級方案靈活切換都給手淘的埋點增加了很多的復雜度。

總之，如何在數據量，數據質量，性能，成功率以及實時性上做權衡，是移動數據采集面臨的最難題。

Q:手淘是如何解決移動端數據采集的難點的？

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

Q:如何儲存收集上來的數據？

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

Q:如何處理處理異常數據？

陳武:異常數據我們會評估處理的成本，如果是低優(yōu)先級的數據，我們可能會直接丟棄，如果是高優(yōu)先級的數據（比如財報數據），我們會對這些數據做一些事后的清洗。

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

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

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

Q:如何保證SDK在性能與數據量上的平衡？

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

Q:雙十一，你最擔心的問題是什么？

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

Q:在災備方面手淘是如何做的？

陳武:容災這塊需要客戶端和服務端一起做，客戶端災備無外乎控制數據量和請求數，但這二者是相對矛盾的。如果把請求數降低，那么就意味著只能把用戶上傳log時間調大，這樣的好處就是服務器的qps降低了，然而客戶端堆積的日志就變大了，服務器解碼也變大了，下游產出時間變長了，所以需要按照顧下游服務器的計算能力合理的權衡上傳間隔和數據量。我們在雙十一的時候會對客戶端做多級的降級預案，會根據服務器的水位推送不同級別的配置，保證客戶端高級別的數據能夠全量上傳，低級別的數據能夠盡可能的上傳。

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

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

11月深圳WOT，我們聊大數據