背景：

在大數據分析平臺背景下，針對用戶行為分析、用戶畫像、個性化推薦等場景，

本文介紹首先需要做的數據采集與傳輸。

采集這類數據一般通過“埋點”的方法，記錄用戶提交了訂單、后臺庫存的變化，

從而為后續大數據分析提供基礎。

一、前端埋點方案

1、代碼埋點

事件發生時，顯示調用代碼發送記錄

國外：Google Analytics、Mixpanel

國內：百度統計、友盟、TalkingData、諸葛IO、Sensors?Analytics 等

優點：控制精準；可以設置自定義屬性，采集能力最強；（有的產品不一定能達到）

缺點：埋點代價大；發布代價大

2、可視化埋點

界面上點選控件，來指定觸發事件以及發送數據的條件

國外：Mixpanel 等

國內：TalkingData、諸葛IO、Sensors Analytics 等

優點：部署直觀、發布迅速、迭代快捷

缺點：能夠覆蓋的控件有限；UI變更會導致埋點失效；自定義屬性和時間的設置能力有限；

3、全埋點/無埋點

預先收集所有控件操作，然后在后端程序或網頁篩選要分析和統計的對象

國外：Heap

國內：百度、豌豆莢、GrowingIO

優點：數據可以向前“回溯”；可以自動獲取一些啟發性信息；

缺點：可視化埋點缺點；傳輸的數據量太大，浪費資源；

數據采集粒度對比，自上至下更獲取數據更詳細

全埋點/無埋點：某時某人點擊了一個按鈕

?可視化埋點?：某時某人提交了一個訂單

代碼埋點?：訂單金額、商品名稱、用戶級別

后端接入數據：商品庫存、商品成本、用戶風險級別

數據回收一般是先收集，等待用戶網絡好時，壓縮加密傳輸。

二、后端日志的傳輸方案

前端埋點通病：

傳輸時效性問題；數據可靠性問題；能夠獲取的數據信息有限；

因此，前后端都能獲取數據時，優先在后端接入。

后端日志傳輸方案

application -> 日志文件?-> flume_agent?-> flume_collector??-> ?HDFS ? ?& ? ?Kafka（用于實時場景）

_______客戶機___________________|__中心服務器___|____存儲服務器? ? ??

優點：內網傳輸，時效性、安全性、可靠性問題迎刃而解；服務端模塊打日志，發版、更新更簡單；

缺點：部分前端行為采集不到；改動后與業務服務耦合，影響業務穩定性；日志打印是技術難題；日志流管理有門檻；

百度在flume_agent把日志格式化為protobuffer，節省帶寬，兼容性好。格式化工作盡早做。

日志如果直接打kafka，缺點是耦合性太強，對現有業務改造大。

日志是追加寫的，所以適合flume+kafka，不停的append。

三、數據庫數據的傳輸方案

數據分析不僅是針對用戶，有時需要針對訂單、商戶、商品分析，所以不可避免要采集數據庫數據。

經常變動的信息，應該添加埋點、或日志。

不常變動的信息，可以導入分析。

兩個導入方案：

（1）固定周期導入整張表做snapshot，體現為Hive同一張表的不同partition；

（2）snapshot + delta 內容太大時，使用此方案，類似于增量備份

sqoop：關系型數據庫與HIVE之間互相傳輸的工具；

導入到HIVE后，可以利用HQL轉化存儲格式為orcfile parkquet，提升存儲和查詢效率；

日志存儲格式建議用 google protobuffer，但是不能直接vim打開。但是比json節省空間，前后兼容性好，

數據倉庫的建立方案：

olap為了讀取優化 ?列存儲，基于htfs很適合 orcfile parkquet ?,上層 spark sql 、hive、impla的都通用

oltp

總結

以上是生活随笔為你收集整理的数据采集与传输的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。