成天看用戶埋點數據，知道數據是咋來的嗎?

咱們平時看到的報表複雜而多樣，可以經過多種緯度的數據評估用戶的使用習慣和對應功能的價值。然而這些報表是如何產生的呢?今天我們就看看上報數據一步一步變成報表的大體流程。

全部上報的數據都是爲了記錄一次事件的發生或者描述一個狀態，具體的上報數據能夠設計爲KEY-VALUE的形式或者數據組合的形式。KEY- VALUE的形式主要用來統計簡單的計數類上報，如按鈕點擊的次數，某個選項的值等，KEY用來區分不一樣的事件，VALUE表明事件發生的次數、狀態值等;數據組合的主要用來描述一個事件或者狀態須要多種屬性描述的場景，好比下載成功事件，描述這個事件的數據組合可能包括對應的下載地址、下載渠道來源、下載耗時等信息。

當上報數據設計好後，後續的工做才能正常開展。下面一步一步說。

一、埋點

所謂「埋點」，就是在正常的功能邏輯中添加統計邏輯。拿統計微信右上角「+」的點擊次數爲例，上報的數據能夠採用KEY-VALUE形式，咱們定義 KEY爲「CLICK_ADD_BTN」，VALUE的值爲點擊的次數。當用戶點擊「+」時，展現菜單的代碼會經過按鈕的「回調」(詳見《聊聊同步、異步和回調》)來觸發執行，程序猿在業務代碼執行完後，又加上了統計代碼，把「CLICK_ADD_BTN」對應的VALUE加1，「+」被統計到了一次使用。

二、上報

並非每統計到一次事件或者狀態就會發起數據上報，客戶端統計到的數據會先暫時存儲在內存或者磁盤上，當用戶啓動、退出應用程序的時候，或者在其餘更合適的時機，將當前週期統計到的事件批量上報到服務器，這樣作的目的主要是考慮到與服務器屢次創建鏈接的性能損耗(詳見《不得不知的TCP和UDP》) 和流量問題(相同大小的數據分屢次發送比一次發送要消耗更多流量)，另外客戶端在上報具體的統計事件以外，還會將標識用戶的ID一併上報，後續用於計算用戶相關的數據如日使用用戶和留存率等。

三、後臺記錄日誌

數據上報到服務器後，服務器會將客戶端上報的原始數據存儲到服務器的磁盤中。通常來講，非強實時性的數據上報到服務器後，並不會當即參與計算，得到最終的統計結果，好比一個功能的日使用次數，日用戶數，日留存等數據，而是等到服務器負載較低的時間段利用預先配置的計劃任務進行離線處理。這樣處理的目的是爲了節約服務器資源(錢)，由於你們確定不想由於計算統計數據而影響實時業務的處理效率。

四、計算&入庫

報表中展現的數據，並非客戶端上報的原始數據，好比「+」的使用次數、使用用戶數、日留存率這三組數據，都是經過對客戶端上報的「CLICK_ADD_BTN」對應VALUE值的累加並結合上報用戶ID二次計算得出的。

若是咱們的產品達到微信這種日登錄數五六億，那麼天天上報的統計數據將是海量的，爲了從這種海量的數據中計算出「+」的使用次數、使用用戶數等信息，就須要用到「數據倉庫工具」，好比當下流行的Hive處理工具，它基於Hadoop分佈式系統基礎框架，利用計算機集羣的能力進行分佈式計算。當「數據倉庫工具」計算出最終的結果後，計劃任務會將結果(「+」的日使用次數、日使用用戶數等數據)保存到數據庫中，也就是「入庫」過程。「入庫」後的數據才能與前端對接，組成報表展現系統。

通常狀況下，原始數據通過數據倉庫工具處理後，對應的日誌文件還會在服務器上保留一段時間(通常3~7天)，以便追溯統計問題，因此，若是發現統計數據有問題問題，必定要及時反饋給負責的程序猿，不然就會「死」無對證咯。

五、展現

 

當數據「入庫」後，報表的展現就水到渠成了。報表系統經過前端頁面用戶的輸入獲取查詢條件，而後經過後臺數據庫查詢得到結果，在前端展現出來。

這裏只是簡述了埋點數據上報、統計的大體流程，每一個過程當中還有不少細節要解決，如後臺日誌亂碼問題、客戶端異常致使數據丟失等。一旦數據出現問題，常常須要聯繫各方人員定位緣由。在此呼籲廣大的產品大蝦必定要關心、愛護爲你作統計需求的程序猿，他們上輩子都是偷了蟠桃的孫悟空。

對咯，今天別忘了看報表哦。