一、常見的數據分析場景

常見的數據分析就是對業務數據或者行為數據進行分析和管理。

業務數據主要是指用戶行為發生之后，實際產生的結果，我們使用數倉建模來給業務提供指標，從而指導業務進行一些正向的操作或者修改之前的一些操作。行為數據主要是指用戶使用產品上的各種行為，我們可以對面向行為分析的數據進行加工和分析，從用戶的行為中推導出來到底是哪些環節沒有做好，從而調整和優化這些環節。

二、數倉建模方法

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

數倉建模方法主要流程如下：

• 用戶空間：以音樂播放為例，用戶在APP上的操作會產生行為日志，比如廣告請求、曝光、點擊，APP打開、用戶注冊和播放、下載歌曲等操作日志。
• 數倉建模：我們將用戶的行為日志采集過來，形成ODS、DWD層的表，再往后是各個主題表。不同業務團隊會創建自己的業務寬表，從用戶空間中抽取感興趣的事件放到各自的主題業務寬表中。
• 主題應用：再往下是這些主題寬表所支撐的業務，比如報表建設、特征挖掘、機器學習、OneID系統建設等等，最終為增長團隊、經營團隊和產品團隊等提供支持。

三、數倉建模方法的優劣勢

1、優勢

• 方法論成熟 : 已經在無數的公司中被驗證過，更有像《阿里巴巴大數據實踐》《Building The Data Warehouse》 等優秀的指導書籍。
• 技術棧成熟: 無論是從消息中間件、數據ETL管路，數據湖、數據倉庫、數據集市的各種選型等，工業界已經誕生了無數優秀的框架和數據庫。
• l技術供應商支持完善：Google，Amazon，Microsoft，阿里云，騰訊云等供應都提供幾乎一站式的服務。
• 技術人才供給: 各個互聯網公司都有數據倉庫建模的需求，人才供應充分，培養體系完備。
• 公司推動阻力小: 數倉的重要性經歷了充分的市場教育，推動起來會比較順暢，投入產出比也比較好闡述。
• 應用場景:適合指標類的多維分析數據運算。

2、劣勢

• 建設鏈條長: 數據采集->ODS->DWD->DWT->數據報表和應用。
• 數據一致性保證有挑戰:不同數據主題之間會有指標和字段的重合，在工程和業務之間，不同的工程團隊之間都可能造成理解的偏差。
• 擴展字段流程復雜:表結構需要預先定義, 擴展新字段往往需要較長的開發周期和回溯數據周期。
• 工程實現很難統一: 架構評估往往取決于承接的工程團隊的過往經驗和喜好，同樣需求的實現差異較大。
• 不適合時序行為數據分析:因為需要按照用戶維度shuffle和開窗，用戶行為分析往往比較耗資源。
• 預聚合不夠靈活:當維度不能命中預聚合的維度時，查詢會退化成全表聚合。

四、面向行為分析的分析方法-概念

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

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

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

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

所以我們現在已經有了兩層抽象，對于數據的抽象，是用時間線排進來的一個個的事件，對于計算的抽象，是把一個查詢拆解成一個個用戶群的計算，再根據計算的結果回答我們一個個關于用戶群相關的問題。

五、面向行為分析的分析方法-整體架構

下面是面向行為數據分析的整體架構（該架構可供參考，但并非唯一解）。

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

下圖是對于7日的Android用戶留存率，在面向行為數據分析的架構中的實現過程抽象：

接下來是對于面向行為數據分析架構中關鍵節點的介紹。

1、列存儲

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

2、元數據

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

其次是列元數據。我們查詢的時候并不是要把所有的列都加載進來，計算的時候只加載文件中對應偏移量的列數據，這樣可以減少網絡傳輸的開銷、磁盤IO和內存使用量。

3、OneID

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

4、緩存層

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

5、用戶數據訪問層

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

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

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

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

首先是用戶留存分析。

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

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

第三個分析的例子是路徑分析。常用于某個業務指標轉化不好時進行分析。首先定義事件的入度和出度，也就是一個事件的前一個和后一個事件。計算采用深度遍歷的方式。