一、常見的數(shù)據(jù)分析場景

常見的數(shù)據(jù)分析就是對業(yè)務(wù)數(shù)據(jù)或者行為數(shù)據(jù)進(jìn)行分析和管理。

(資料圖片僅供參考)

業(yè)務(wù)數(shù)據(jù)主要是指用戶行為發(fā)生之后，實際產(chǎn)生的結(jié)果，我們使用數(shù)倉建模來給業(yè)務(wù)提供指標(biāo)，從而指導(dǎo)業(yè)務(wù)進(jìn)行一些正向的操作或者修改之前的一些操作。行為數(shù)據(jù)主要是指用戶使用產(chǎn)品上的各種行為，我們可以對面向行為分析的數(shù)據(jù)進(jìn)行加工和分析，從用戶的行為中推導(dǎo)出來到底是哪些環(huán)節(jié)沒有做好，從而調(diào)整和優(yōu)化這些環(huán)節(jié)。

二、數(shù)倉建模方法

在引入行為分析方法之前，先介紹一下數(shù)倉建模的方法。

數(shù)倉建模方法主要流程如下：

用戶空間：以音樂播放為例，用戶在APP上的操作會產(chǎn)生行為日志，比如廣告請求、曝光、點擊，APP打開、用戶注冊和播放、下載歌曲等操作日志。數(shù)倉建模：我們將用戶的行為日志采集過來，形成ODS、DWD層的表，再往后是各個主題表。不同業(yè)務(wù)團(tuán)隊會創(chuàng)建自己的業(yè)務(wù)寬表，從用戶空間中抽取感興趣的事件放到各自的主題業(yè)務(wù)寬表中。主題應(yīng)用：再往下是這些主題寬表所支撐的業(yè)務(wù)，比如報表建設(shè)、特征挖掘、機(jī)器學(xué)習(xí)、OneID系統(tǒng)建設(shè)等等，最終為增長團(tuán)隊、經(jīng)營團(tuán)隊和產(chǎn)品團(tuán)隊等提供支持。三、數(shù)倉建模方法的優(yōu)劣勢1、優(yōu)勢方法論成熟 : 已經(jīng)在無數(shù)的公司中被驗證過，更有像《阿里巴巴大數(shù)據(jù)實踐》《Building The Data Warehouse》 等優(yōu)秀的指導(dǎo)書籍。技術(shù)棧成熟:無論是從消息中間件、數(shù)據(jù)ETL管路，數(shù)據(jù)湖、數(shù)據(jù)倉庫、數(shù)據(jù)集市的各種選型等，工業(yè)界已經(jīng)誕生了無數(shù)優(yōu)秀的框架和數(shù)據(jù)庫。l技術(shù)供應(yīng)商支持完善：Google，Amazon，Microsoft，阿里云，騰訊云等供應(yīng)都提供幾乎一站式的服務(wù)。技術(shù)人才供給: 各個互聯(lián)網(wǎng)公司都有數(shù)據(jù)倉庫建模的需求，人才供應(yīng)充分，培養(yǎng)體系完備。公司推動阻力小: 數(shù)倉的重要性經(jīng)歷了充分的市場教育，推動起來會比較順暢，投入產(chǎn)出比也比較好闡述。應(yīng)用場景:適合指標(biāo)類的多維分析數(shù)據(jù)運(yùn)算。2、劣勢建設(shè)鏈條長: 數(shù)據(jù)采集->ODS->DWD->DWT->數(shù)據(jù)報表和應(yīng)用。數(shù)據(jù)一致性保證有挑戰(zhàn):不同數(shù)據(jù)主題之間會有指標(biāo)和字段的重合，在工程和業(yè)務(wù)之間，不同的工程團(tuán)隊之間都可能造成理解的偏差。擴(kuò)展字段流程復(fù)雜:表結(jié)構(gòu)需要預(yù)先定義, 擴(kuò)展新字段往往需要較長的開發(fā)周期和回溯數(shù)據(jù)周期。工程實現(xiàn)很難統(tǒng)一: 架構(gòu)評估往往取決于承接的工程團(tuán)隊的過往經(jīng)驗和喜好，同樣需求的實現(xiàn)差異較大。不適合時序行為數(shù)據(jù)分析:因為需要按照用戶維度shuffle和開窗，用戶行為分析往往比較耗資源。預(yù)聚合不夠靈活:當(dāng)維度不能命中預(yù)聚合的維度時，查詢會退化成全表聚合。四、面向行為分析的分析方法-概念

基于以上數(shù)倉建模的優(yōu)缺點，我們需要對行為數(shù)據(jù)進(jìn)行一些不一樣的抽象，用一些不一樣的查詢方式來解決面向用戶行為數(shù)據(jù)的問題。首先來介紹一些概念：

用戶空間：和數(shù)倉建模一樣，這部分不變。用戶事件序列：和數(shù)倉建模方式不同，我們這里不將用戶的行為日志抽象到ODS、DWD層，在這里將行為日志數(shù)據(jù)抽象成用戶事件序列，比如對于播放歌曲事件會包含用戶屬性和事件屬性，用戶屬性回答誰在什么樣的設(shè)備上這個問題，事件屬性回答這個人主要做了什么事， 這個事我怎么去描述它。對于所有事件，我們都可以用這兩種類型的元數(shù)據(jù)來描述這個事件,在一個時間軸上串起來，就可以知道這件事是誰做的，以及做了這件事后發(fā)生了什么。事件抽象：有了用戶序列的抽象，我們可以聚焦一下，看某個人在某個具體事件序列上的抽象。比如圖中會員升級的例子。用戶群計算：有了事件抽象之后，最重要的就是我們怎么使用這些數(shù)據(jù)，我們可以利用這些數(shù)據(jù)來獲取新增用戶群、活躍用戶群以及滿足X條件的用戶群等等。

如上圖所示，以7日Android用戶的留存率為例，左邊是傳統(tǒng)數(shù)倉的解決方案，右邊是行為分析的解決方案。

傳統(tǒng)數(shù)倉的解決方案：主要是寫一個SQL來看7天前的新增用戶在今天的活躍用戶中是否有，如果有的話，7天的新增用戶作為分母，今天的活躍用戶作為分子，除出來一個比例計算留存率。但是可能在數(shù)倉里面，一條記錄并不是用用戶的ID來劃分的，所以最終想要計算出用戶ID的結(jié)果會有一個shuffle、關(guān)聯(lián)、數(shù)據(jù)傾斜的過程，這都是在傳統(tǒng)輸出解決方案當(dāng)中我們需要去考慮的一些點。行為分析的解決方案：這是另外一種簡化的計算用戶留存的方式，本質(zhì)上是在圖中的三個圈圈選的用戶中做計算，三個圈的交集就是7天前的新增用戶在今日活躍用戶中的比例。我們將復(fù)雜留存SQL轉(zhuǎn)成了三個用戶群之間并集和交集的計算。

所以我們現(xiàn)在已經(jīng)有了兩層抽象，對于數(shù)據(jù)的抽象，是用時間線排進(jìn)來的一個個的事件，對于計算的抽象，是把一個查詢拆解成一個個用戶群的計算，再根據(jù)計算的結(jié)果回答我們一個個關(guān)于用戶群相關(guān)的問題。

五、面向行為分析的分析方法-整體架構(gòu)

下面是面向行為數(shù)據(jù)分析的整體架構(gòu)（該架構(gòu)可供參考，但并非唯一解）。

從下往上看，最下面是數(shù)據(jù)的存儲，采用列式存儲，并在其中應(yīng)用一些對用戶群更友好的技術(shù)，從而減少數(shù)據(jù)的加載量和分發(fā)量。往上是文件元數(shù)據(jù)/列元數(shù)據(jù)。再上面是用戶數(shù)據(jù)訪問層，本質(zhì)上就是計算層。IDMapping層主要解決不同ID對應(yīng)同一用戶的問題。查詢緩存層、查詢結(jié)果聚合層，以及最上面的查詢接入層，都是為了提高查詢效率。

下圖是對于7日的Android用戶留存率，在面向行為數(shù)據(jù)分析的架構(gòu)中的實現(xiàn)過程抽象：

接下來是對于面向行為數(shù)據(jù)分析架構(gòu)中關(guān)鍵節(jié)點的介紹。

1、列存儲

首先介紹我們自定義的列存儲。我們沒有使用ORC、Parquet這些列存儲格式，主要是因為ORC、Parquet格式不會對用戶存儲做一些自定義的優(yōu)化，市面上的Druid、HBase也是為了加速數(shù)據(jù)訪問引用了很多的組件。對于特定的場景，我們可以把更多的組件應(yīng)用過來，比如說BloomFilter（布隆過濾器），目的是快速判斷一個用戶是否在當(dāng)前文件中，因為我們所有的查詢其實都是面向用戶ID的。還有Delta encoding（差分編碼），用來對時間格式進(jìn)行存儲，減少時間戳的存儲體積。

2、元數(shù)據(jù)

列存儲再往上一層就是元數(shù)據(jù)。首先是文件元數(shù)據(jù)。文件的第一級索引是按時間的，而時間是動態(tài)的，因為用戶的活躍時間可能是在晚上或者中午的休息時間，凌晨可能用戶并不活躍。這就導(dǎo)致我們文件中存儲的用戶數(shù)據(jù)在時間上不是平均分配的，比如想要查詢凌晨1點到早上9點的數(shù)據(jù)，有可能需要訪問多個文件。這個時候我們需要知道應(yīng)該在動態(tài)時間切片文件中訪問哪些文件。因此我們就需要一個元數(shù)據(jù)的管理，基于查詢的起止時間，找出存儲的位置，這樣可以確保每個文件存儲的大小是相近的，盡可能減少數(shù)據(jù)計算過程中的數(shù)據(jù)偏移。

其次是列元數(shù)據(jù)。我們查詢的時候并不是要把所有的列都加載進(jìn)來，計算的時候只加載文件中對應(yīng)偏移量的列數(shù)據(jù)，這樣可以減少網(wǎng)絡(luò)傳輸?shù)拈_銷、磁盤IO和內(nèi)存使用量。

3、OneID

OneID的建設(shè)在每家公司是不一樣的，但本質(zhì)上都是用來追蹤用戶的設(shè)備變化，還原用戶事件的最真實狀態(tài)，進(jìn)而提供IDMapping、ID Encoding的能力。

4、緩存層

緩存層主要是對以前訪問數(shù)據(jù)的緩存，加速訪問。緩存key中有時間的版本號，數(shù)據(jù)可能會因為回填等原因引入新數(shù)據(jù)，通過時間版本號的方式可以自動刷新緩存。

5、用戶數(shù)據(jù)訪問層

用戶數(shù)據(jù)訪問層包括數(shù)據(jù)的聚合層、用戶群算子層以及元數(shù)據(jù)管理和底層時序數(shù)據(jù)的加載。首先，用戶請求會包含時間范圍、過濾條件、用戶群聚合條件等；第二步，根據(jù)用戶請求，請求元數(shù)據(jù)，確定要訪問的文件和列在哪里；第三步，知道了數(shù)據(jù)在哪后，加載數(shù)據(jù)到計算節(jié)點，并緩存到本地；第四步，用戶分區(qū)計算，最大化并行查詢效果；最后，進(jìn)行聚合計算。

通過以上架構(gòu)，我們希望在查詢時，只去加載最低密度的數(shù)據(jù)，在不同節(jié)點之間通訊時只去通訊最必要的用戶群的bit數(shù)組，最終也是通過bit運(yùn)算的方式返回，再通過OneID將bit數(shù)組還原成所關(guān)心的用戶群的一個詳細(xì)的描述。

六、面向行為分析的分析方法-分析舉例

下面是行為分析的幾個例子。

首先是用戶留存分析。

上圖中包含了7月29日至8月8日（第5天到第10天）之間的留存率。對于行，只需要計算7月29日至8月8日之間每天的新增用戶。對于列，只需要計算行時間+偏移量的活躍用戶數(shù)。而整個表格的計算就是對兩個用戶群進(jìn)行邏輯與。這樣就把表格的計算拆成了一個個單元格的獨立的計算，每一個獨立的計算都可以通過預(yù)計算保存在緩存中，還可以通過一些好的用戶交互方式，實現(xiàn)自助的留存率分析。

第二個常用的分析是漏斗分析。比如分析做了播放的用戶中，有多少進(jìn)行了收藏，收藏的用戶又有多少進(jìn)行了購買，購買的用戶中有多少下載了歌曲。漏斗分析又有時序嚴(yán)格和非嚴(yán)格之分。時序嚴(yán)格的轉(zhuǎn)化漏斗，必須是發(fā)生在時序嚴(yán)格遞增的場景下，同一個session內(nèi)，一定是先播放，再收藏，再購買，最后下載。非時序嚴(yán)格的轉(zhuǎn)化漏斗常用來進(jìn)行趨勢分析，有可能先購買再播放。對于非時序嚴(yán)格的轉(zhuǎn)化漏斗，采用垂直切，我們只需要去分別計算每一個事件的用戶群，再做與關(guān)系。時序嚴(yán)格的轉(zhuǎn)化漏斗，要采用水平切，計算一個session內(nèi)既播放，又收藏，購買并且下載了的用戶群，再用搭積木的方式計算出來。

第三個分析的例子是路徑分析。常用于某個業(yè)務(wù)指標(biāo)轉(zhuǎn)化不好時進(jìn)行分析。首先定義事件的入度和出度，也就是一個事件的前一個和后一個事件。計算采用深度遍歷的方式。

關(guān)鍵詞：