大數據之數據採集

大數據之數據採集

大數據體系通常分爲：數據採集、數據計算、數據服務、以及數據應用 幾大層次。

在數據採集層，主要分爲 日誌採集 和 數據源數據同步。

日誌採集

根據產品的類型 又有能夠分爲： 
- 瀏覽器頁面 的日誌採集 
- 客戶端 的日誌採集 

瀏覽器頁面採集： 
主要是收集頁面的 瀏覽日誌（PV/UV等） 和 交互操做日誌（操做事件）。

這些日誌的採集，通常是在頁面上植入標準的統計JS代碼來進執行。但這個植入代碼的過程，能夠在頁面功能開發階段由開發同窗手動寫入，也能夠在項目運行的時候，由服務器在相應頁面請求的時候動態的植入。

事實上，統計JS在採集到數據以後，能夠當即發送到數據中心，也能夠進行適當的匯聚以後，延遲發送到數據中心，這個策略取決於不一樣場景的需求來定。

頁面日誌在收集上來以後，須要在服務端進行必定的清晰和預處理。 
好比 清洗假流量數據、識別攻擊、數據的正常補全、無效數據的剔除、數據格式化、數據隔離等。

客戶端日誌採集： 
通常會開發專用統計SDK用於APP客戶端的數據採集。

客戶端數據的採集，由於具備高度的業務特徵，自定義要求比較高，所以除應用環境的一些基本數據之外，更多的是從 「按事件」的角度來採集數據，好比 點擊事件、登錄事件、業務操做事件 等等。

基礎數據可由SDK默認採集便可，其它事件由業務側來定義後，按照規範調用SDK接口。

由於如今愈來愈多APP採用Hybrid方案，即 H5 與 Native相結合的方式，所以對於日誌採集來講，既涉及到H5頁面的日誌，也涉及到Native客戶端上的日誌。在這種狀況下，能夠分開採集分開發送，也能夠將數據合併到一塊兒以後再發送。

常規狀況下是推薦將 H5上的數據往Native上合併，而後經過SDK統一的發送。這樣的好處是 既能夠保證採集到的用戶行爲數據在行爲鏈上是完整的，也能夠經過SDK採起一些壓縮處理方案來減小日誌量，提升效率。

APP上的數據採集，還有一點比較重要的就是惟一ID了，全部的數據都必須跟惟一ID相關聯，才能起到更好的分析做用，至於移動設備惟一ID我在上一篇文章中有詳細講到。 

日誌收集，還有很重要的一條原則就是 「標準化」、「規範化」，只有採集的方式標準化、規範化，才能最大限度的減小收集成本，提升日誌收集效率、更高效的實現接下來的統計計算。

數據源數據同步

根據同步的方式 能夠分爲： 
- 直接數據源同步 
- 生成數據文件同步 
- 數據庫日誌同步 

直接數據源同步： 
是指直接的鏈接業務數據庫，經過規範的接口（如JDBC）去讀取目標數據庫的數據。這種方式比較容易實現，可是若是業務量比較大的數據源，可能會對性能有所影響。

生成數據文件同步： 
是指從數據源系統現生成數據文件，而後經過文件系統同步到目標數據庫裏。 
這種方式適合數據源比較分散的場景，在數據文件傳輸先後必須作校驗，同時還須要適當進行文件的壓縮和加密，以提升效率、保障安全。

數據庫日誌同步： 
是指基於源數據庫的日誌文件進行同步。如今大多數數據庫都支持生成數據日誌文件，而且支持用數據日誌文件來恢復數據。所以可使用這個數據日誌文件來進行增量同步。 
這種方式對系統性能影響較小，同步效率也較高。 

數據採集自己不是目的，只有採集到的數據是可用、能用，且能服務於最終應用分析的數據採集纔是根本。

---

本文原創發佈於微信公衆號「 bzsikao 」，歡迎關注，交流更多的 互聯網認知、工做管理、大數據、Web、區塊鏈技術。