背景：

在大數(shù)據(jù)分析平臺(tái)背景下，針對(duì)用戶行為分析、用戶畫像、個(gè)性化推薦等場(chǎng)景，

本文介紹首先需要做的數(shù)據(jù)采集與傳輸。

采集這類數(shù)據(jù)一般通過“埋點(diǎn)”的方法，記錄用戶提交了訂單、后臺(tái)庫(kù)存的變化，

從而為后續(xù)大數(shù)據(jù)分析提供基礎(chǔ)。

一、前端埋點(diǎn)方案

1、代碼埋點(diǎn)

事件發(fā)生時(shí)，顯示調(diào)用代碼發(fā)送記錄

國(guó)外：Google Analytics、Mixpanel

國(guó)內(nèi)：百度統(tǒng)計(jì)、友盟、TalkingData、諸葛IO、Sensors?Analytics 等

優(yōu)點(diǎn)：控制精準(zhǔn)；可以設(shè)置自定義屬性，采集能力最強(qiáng)；（有的產(chǎn)品不一定能達(dá)到）

缺點(diǎn)：埋點(diǎn)代價(jià)大；發(fā)布代價(jià)大

2、可視化埋點(diǎn)

界面上點(diǎn)選控件，來指定觸發(fā)事件以及發(fā)送數(shù)據(jù)的條件

國(guó)外：Mixpanel 等

國(guó)內(nèi)：TalkingData、諸葛IO、Sensors Analytics 等

優(yōu)點(diǎn)：部署直觀、發(fā)布迅速、迭代快捷

缺點(diǎn)：能夠覆蓋的控件有限；UI變更會(huì)導(dǎo)致埋點(diǎn)失效；自定義屬性和時(shí)間的設(shè)置能力有限；

3、全埋點(diǎn)/無埋點(diǎn)

預(yù)先收集所有控件操作，然后在后端程序或網(wǎng)頁(yè)篩選要分析和統(tǒng)計(jì)的對(duì)象

國(guó)外：Heap

國(guó)內(nèi)：百度、豌豆莢、GrowingIO

優(yōu)點(diǎn)：數(shù)據(jù)可以向前“回溯”；可以自動(dòng)獲取一些啟發(fā)性信息；

缺點(diǎn)：可視化埋點(diǎn)缺點(diǎn)；傳輸?shù)臄?shù)據(jù)量太大，浪費(fèi)資源；

數(shù)據(jù)采集粒度對(duì)比，自上至下更獲取數(shù)據(jù)更詳細(xì)

全埋點(diǎn)/無埋點(diǎn)：某時(shí)某人點(diǎn)擊了一個(gè)按鈕

?可視化埋點(diǎn)?：某時(shí)某人提交了一個(gè)訂單

代碼埋點(diǎn)?：訂單金額、商品名稱、用戶級(jí)別

后端接入數(shù)據(jù)：商品庫(kù)存、商品成本、用戶風(fēng)險(xiǎn)級(jí)別

數(shù)據(jù)回收一般是先收集，等待用戶網(wǎng)絡(luò)好時(shí)，壓縮加密傳輸。

二、后端日志的傳輸方案

前端埋點(diǎn)通病：

傳輸時(shí)效性問題；數(shù)據(jù)可靠性問題；能夠獲取的數(shù)據(jù)信息有限；

因此，前后端都能獲取數(shù)據(jù)時(shí)，優(yōu)先在后端接入。

后端日志傳輸方案

application -> 日志文件?-> flume_agent?-> flume_collector??-> ?HDFS ? ?& ? ?Kafka（用于實(shí)時(shí)場(chǎng)景）

_______客戶機(jī)___________________|__中心服務(wù)器___|____存儲(chǔ)服務(wù)器? ? ??

優(yōu)點(diǎn)：內(nèi)網(wǎng)傳輸，時(shí)效性、安全性、可靠性問題迎刃而解；服務(wù)端模塊打日志，發(fā)版、更新更簡(jiǎn)單；

缺點(diǎn)：部分前端行為采集不到；改動(dòng)后與業(yè)務(wù)服務(wù)耦合，影響業(yè)務(wù)穩(wěn)定性；日志打印是技術(shù)難題；日志流管理有門檻；

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

日志如果直接打kafka，缺點(diǎn)是耦合性太強(qiáng)，對(duì)現(xiàn)有業(yè)務(wù)改造大。

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

三、數(shù)據(jù)庫(kù)數(shù)據(jù)的傳輸方案

數(shù)據(jù)分析不僅是針對(duì)用戶，有時(shí)需要針對(duì)訂單、商戶、商品分析，所以不可避免要采集數(shù)據(jù)庫(kù)數(shù)據(jù)。

經(jīng)常變動(dòng)的信息，應(yīng)該添加埋點(diǎn)、或日志。

不常變動(dòng)的信息，可以導(dǎo)入分析。

兩個(gè)導(dǎo)入方案：

（1）固定周期導(dǎo)入整張表做snapshot，體現(xiàn)為Hive同一張表的不同partition；

（2）snapshot + delta 內(nèi)容太大時(shí)，使用此方案，類似于增量備份

sqoop：關(guān)系型數(shù)據(jù)庫(kù)與HIVE之間互相傳輸?shù)墓ぞ?#xff1b;

導(dǎo)入到HIVE后，可以利用HQL轉(zhuǎn)化存儲(chǔ)格式為orcfile parkquet，提升存儲(chǔ)和查詢效率；

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

數(shù)據(jù)倉(cāng)庫(kù)的建立方案：

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

oltp

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。