數(shù)據(jù)倉庫是一個(gè)面向主題的、集成的、隨時(shí)間變化但信息本身相對(duì)穩(wěn)定的數(shù)據(jù)集合，用于支持管理決策過程。其本質(zhì)就是完成從面向業(yè)務(wù)過程數(shù)據(jù)的組織管理到面向業(yè)務(wù)分析數(shù)據(jù)的組織和管理的轉(zhuǎn)變過程，也是商業(yè)智能BI中數(shù)據(jù)倉庫的主要作用。

數(shù)據(jù)倉庫就像企業(yè)的總的大倉庫，能夠存儲(chǔ)不同來源、不同格式的數(shù)據(jù)，并且可以通過ETL和數(shù)據(jù)模型，對(duì)數(shù)據(jù)進(jìn)行高質(zhì)量的篩選，分級(jí)分類進(jìn)行存儲(chǔ)。具有很強(qiáng)的穩(wěn)定性，不會(huì)頻繁的進(jìn)行增刪改等操作，能夠反映歷史變化。

今天我們從數(shù)據(jù)的源頭開始說起，數(shù)據(jù)的源頭是數(shù)據(jù)采集和上報(bào)。

（一）數(shù)據(jù)采集

采集內(nèi)容

數(shù)據(jù)采集一般需要涵蓋4W（When、Where、Who、What）四大要素，像作文一樣分別從時(shí)間、地點(diǎn)、人物、事件對(duì)用戶的行為予以描述。
When
操作時(shí)間。有些數(shù)據(jù)上報(bào)并不是在采集后馬上進(jìn)行的，而是累計(jì)采集N條后打包上報(bào)；有些參數(shù)的獲取需要前后臺(tái)彼此交互，所以時(shí)間的采集可以細(xì)分為動(dòng)作發(fā)生的時(shí)間、采集時(shí)間、前后臺(tái)交互完成時(shí)間、上報(bào)時(shí)間等，根據(jù)各業(yè)務(wù)需求和復(fù)雜程度決定采集的類型和范圍。

?

Where

操作地點(diǎn)。一般可以通過IP地址或經(jīng)緯度確定。
Who
身份標(biāo)識(shí)。這里主要介紹2種身份標(biāo)識(shí)：用戶賬號(hào)和設(shè)備號(hào)。
用戶賬號(hào)是各個(gè)應(yīng)用按照自己的規(guī)則賦予用戶的內(nèi)部身份標(biāo)識(shí)。其中有些應(yīng)用根據(jù)流量域?qū)傩?、?nèi)容生產(chǎn)和消費(fèi)屬性等設(shè)計(jì)了多級(jí)賬號(hào)體系；有些應(yīng)用則使用單賬號(hào)體系；有些使用大生態(tài)下的開放賬號(hào)體系。

設(shè)備號(hào)是硬件設(shè)備的身份標(biāo)識(shí)，包括但不限于手機(jī)、電腦、電視、智能可穿戴設(shè)備等。設(shè)備號(hào)的作用是識(shí)別一臺(tái)具體設(shè)備，例如IMEI、IDFA、OAID等，生成設(shè)備ID的相關(guān)的算法也在不斷優(yōu)化升級(jí)以達(dá)到更準(zhǔn)確的識(shí)別和標(biāo)記。
在硬件推送（PUSH）場景下，用戶賬號(hào)要先轉(zhuǎn)化為設(shè)備號(hào)才能進(jìn)行正常推送。除此之外，設(shè)備號(hào)在黑產(chǎn)打擊方面也有大規(guī)模的應(yīng)用。

What

操作內(nèi)容。諸如頁面、曝光、點(diǎn)擊等操作和相關(guān)的業(yè)務(wù)參數(shù)在此進(jìn)行采集。在前端框架技術(shù)上支持的情況下，用戶操作的來源和去向也可以根據(jù)統(tǒng)計(jì)需要進(jìn)行采集。

數(shù)據(jù)采集和上報(bào)是為了優(yōu)化服務(wù)的，不能過度影響到應(yīng)用的正常功能，所以需要在一定程度上進(jìn)行權(quán)衡與精簡。而操作內(nèi)容的采集場景，存在大量的前后端數(shù)據(jù)交互，若請(qǐng)求數(shù)據(jù)結(jié)構(gòu)過大，則可能影響傳輸性能進(jìn)而影響使用體驗(yàn)。

采集方式

埋點(diǎn)采集
前后端應(yīng)用開發(fā)人員在特定場景下的特定時(shí)機(jī)，根據(jù)需要采集特定的參數(shù)。早期和中小型應(yīng)用多使用該采集方式。其優(yōu)點(diǎn)是開發(fā)成本低，修改靈活；但缺點(diǎn)是容易造成全局采集邏輯不一致的情況，后續(xù)維護(hù)成本和數(shù)據(jù)加工成本高。

?

SDK采集

SDK通過內(nèi)部集成采集和緩存能力，統(tǒng)一采集時(shí)機(jī)和采集策略，標(biāo)準(zhǔn)化采集事件來進(jìn)行全局參數(shù)采集，是從數(shù)據(jù)源頭改善數(shù)據(jù)質(zhì)量的重要方式，已經(jīng)被越來越多的大型業(yè)務(wù)所使用。其優(yōu)點(diǎn)是標(biāo)準(zhǔn)化程度高，降低前后端開發(fā)人員的開發(fā)量；缺點(diǎn)是開發(fā)這一套工具需要較大的前期投入。

采集時(shí)機(jī)和采集策略的統(tǒng)一是SDK采集相較于埋點(diǎn)采集的重大改進(jìn)。用曝光場景舉個(gè)例子，若使用埋點(diǎn)上報(bào)，有些開發(fā)人員在目標(biāo)露出屏幕100個(gè)像素時(shí)采集，另一些開發(fā)人員可能在目標(biāo)露出5%時(shí)進(jìn)行采集；不同的開發(fā)人員在采集同一個(gè)參數(shù)時(shí)，使用的代碼和采集路徑也不一定完全相同。在大型應(yīng)用中，數(shù)據(jù)的采集不是一次就能完成的，而是一個(gè)分階段進(jìn)行的過程，采集的參數(shù)個(gè)數(shù)也可能不是幾個(gè)，而是幾十上百個(gè)，所以不同的采集時(shí)機(jī)和采集策略就意味著能采集到參數(shù)的個(gè)數(shù)和質(zhì)量也不盡相同。

BINLOG采集
BINLOG可以獲取數(shù)據(jù)庫的每一條變更記錄，由此完成DB數(shù)據(jù)的采集。目前已經(jīng)有比較成熟的開源組件可以直接使用。其優(yōu)點(diǎn)是無需前后端開發(fā)人員的額外工作，但缺點(diǎn)是后續(xù)的數(shù)據(jù)加工會(huì)變得非常復(fù)雜，需要頻繁的去重和取最新數(shù)據(jù)的操作，這在實(shí)時(shí)數(shù)據(jù)處理場景下幾乎是致命的。
數(shù)據(jù)采集的質(zhì)量決定了數(shù)倉質(zhì)量的上限，數(shù)據(jù)開發(fā)的工程量是數(shù)據(jù)源質(zhì)量和數(shù)倉設(shè)計(jì)與實(shí)施質(zhì)量共同決定的。一個(gè)團(tuán)隊(duì)多做一點(diǎn)，另一個(gè)團(tuán)隊(duì)就少做一點(diǎn)，但在一些關(guān)鍵節(jié)點(diǎn)上，一個(gè)團(tuán)隊(duì)修補(bǔ)另一個(gè)團(tuán)隊(duì)的開發(fā)空缺可能是幾倍甚至幾十倍的工作量。在預(yù)期提供相同質(zhì)量數(shù)倉的前提下，決策者需要合理平衡數(shù)據(jù)源開發(fā)和數(shù)倉開發(fā)的工作配比，才能更大程度地發(fā)揮數(shù)據(jù)價(jià)值。

（二）數(shù)據(jù)上報(bào)

拿到采集的數(shù)據(jù)以后，需要進(jìn)行數(shù)據(jù)的上報(bào)，才能被后續(xù)的鏈路所使用。

客戶端（前端）上報(bào)

客戶端在采集到的數(shù)據(jù)后，直接或在緩存N條以后，批量將數(shù)據(jù)通過網(wǎng)絡(luò)發(fā)送到日志服務(wù)器。這個(gè)過程可能由于網(wǎng)絡(luò)波動(dòng)或者用戶直接殺掉進(jìn)程導(dǎo)致部分?jǐn)?shù)據(jù)上報(bào)缺失；有些應(yīng)用為應(yīng)對(duì)網(wǎng)絡(luò)問題會(huì)內(nèi)置上報(bào)重試邏輯，一定程度上解決上報(bào)缺失的同時(shí)也引入了重復(fù)上報(bào)的可能性。

?

無論是上報(bào)缺失或者上報(bào)重復(fù)，都是小概率事件，并且一般通過客戶端上報(bào)的數(shù)據(jù)都是頁面、曝光、點(diǎn)擊這類的描述性數(shù)據(jù)，故在統(tǒng)計(jì)容忍的范圍內(nèi)仍可接受。

后臺(tái)上報(bào)

后臺(tái)服務(wù)在用戶觸發(fā)較為關(guān)鍵性的操作時(shí)（例如訪問、下單、關(guān)注等）或者后臺(tái)主動(dòng)操作時(shí)（例如發(fā)券、回收權(quán)限等）進(jìn)行相關(guān)參數(shù)的采集和上報(bào)，也是通過網(wǎng)絡(luò)發(fā)送到日志服務(wù)器上。但因?yàn)楹笈_(tái)服務(wù)一般處于比較穩(wěn)定的內(nèi)部生產(chǎn)環(huán)境，所以上報(bào)的成功率會(huì)比客戶端更高，一些對(duì)準(zhǔn)確性要求較高的統(tǒng)計(jì)數(shù)據(jù)可以使用后臺(tái)上報(bào)的方式。

BINLOG上報(bào)

數(shù)據(jù)庫BINLOG的采集和上報(bào)一般是集成在一起的，可以在采集后立即發(fā)送到消息隊(duì)列（多為Kafka隊(duì)列）完成數(shù)據(jù)上報(bào)。

（三）數(shù)據(jù)源選擇

數(shù)倉里的數(shù)據(jù)不是業(yè)務(wù)DB里的數(shù)據(jù)，中間經(jīng)過了采集和加工過程。

數(shù)據(jù)在加工鏈路上不可避免地會(huì)產(chǎn)生一定程度的丟失和延遲，所以在要求高準(zhǔn)確性和低延遲的簡單統(tǒng)計(jì)場景下，在不會(huì)影響到應(yīng)用基本功能的前提下更推薦在DB內(nèi)直接統(tǒng)計(jì)數(shù)據(jù)；在同樣要求高準(zhǔn)確和低延遲的較復(fù)雜場景時(shí)，也可以通過提高數(shù)倉建設(shè)標(biāo)準(zhǔn)和一定程度的定制開發(fā)，使用經(jīng)數(shù)倉加工后的數(shù)據(jù)。

?

數(shù)據(jù)源的選擇同樣面臨投入產(chǎn)出比的衡量，業(yè)務(wù)DB由于范式概念的設(shè)計(jì)，較難實(shí)現(xiàn)復(fù)雜的統(tǒng)計(jì)需求，但具有準(zhǔn)確和快速的優(yōu)點(diǎn)，數(shù)倉可以進(jìn)行大規(guī)模復(fù)雜計(jì)算，但面對(duì)極低延遲和極強(qiáng)準(zhǔn)確性的需求時(shí)也會(huì)提高其建設(shè)成本。

?