海量數據下的用戶訪問行爲分析一直是一大難題，滿幫集團作爲全國最大的車貨匹配信息平臺，每天會產生近十億的流量數據，半年即達千億級數據規模，如何做到快速地響應業務方的多維查詢、自定義漏斗分析、留存分析、用戶畫像等流量分析需求，讓我們一起來看看陳雅婕對滿幫集團爲此自研的自助流量分析平臺 APPDATA 的分享。
作爲大數據團隊，需要給公司的各條業務線提供數據服務。爲了更好地洞察用戶行爲，支撐各大事業羣的產品和運營同學給用戶提供更好、更深層次的服務，我們自研了流量分析平臺 APPDATA，代替了分散在各個事業羣和業務線的商業化流量分析工具，完成了流量分析的全集團統一。
本文介紹 APPDATA 的演進過程，主要包括：
1）滿幫流量分析的業務背景，以及 APPDATA 的產品定位；
2）立項之初的技術架構和實現及遭遇到的問題；
3）將 Kylin 作爲 APPDATA 的核心多維分析引擎所帶來的巨大改變；
4）對 Kylin 的一些調優操作，以及爲了更好的滿足業務需求，對 Kylin 做出的一點改造。
APPDATA 是什麼？
滿幫流量分析的場景特點
第一，滿幫流量數據規模盤大。滿幫集團作爲全國最大的車貨匹配信息平臺，連接着上千萬的司機和貨主用戶，這些用戶每天都會訪問平臺各種各樣的產品來進行發貨、找貨，以及使用一些如加油、ETC充值、借貸等服務，從而每天會產生近十億的流量數據，近半年的數據累計達千億級。
第二，業務重度依賴流量分析。海量的流量數據記錄着非常豐富的用戶行爲。無論哪條業務線，無論是管理者、數據分析師、產品經理，還是運營人員，都非常希望深入分析流量數據，以此來洞察用戶，爲各項業務的展開提供決策支持。業務線對流量分析的訴求十分強烈，數據團隊每週會收到幾十個流量數據相關的需求。
第三，人工提數方式處理需求。在數據團隊成立的初期，我們以人工提數的方式處理需求。業務人員每週會把需求提交給數據分析師，數據分析師進行排期、寫 SQL 提數，最後把數據反饋給需求方。這種方式非常的原始低效，一方面，業務人員要等較長的時間才能拿到結果；另一方面，人工處理需求的成本非常高，當時我們有兩個數據分析師全人力投入支持。
APPDATA 產品定位
針對上述流量分析場景的特點，我們希望能有一款自助流量分析的數據產品，提供給業務人員，快速高效地響應流量分析的需求。同時，也可以將那兩個 all in 在流量數據提取工作上的數據分析師解救出來，讓他們能專注到更需要「人智」的數據處理工作上。
這款自助流量分析產品就是 APPDATA。我們盤點了之前收到所有流量分析相關的提數需求，梳理出了 APPDATA 的 Feature List：
-
多維查詢：提供在不同維度組合下，頁面/自定義事件的PV、UV、停留時長等指標查詢；
-
自定義漏斗分析：支持用戶自定義漏斗轉化路徑，由系統計算出漏斗每步驟的人數、轉化率；
-
留存分析：提供留存分析，幫助產品做黏性分析；
-
用戶畫像：實現流量數據和用戶畫像標籤數據的聯動，提供用戶畫像信息查詢。
我們希望通過這四個功能覆蓋 80% 的流量分析需求，通過產品滿足數據分析，讓大數據在驅動業務中工具化，自動化。
早期方案和挑戰
明確產品規劃之後，我們開始推進產品落地。
早期方案
立項之初，出於效率優先的考慮，採用的方案如下圖所示：
用戶訪問客戶端產生埋點數據，上報到數據團隊的集羣，落到 Hive 中，數據分析師根據業務人員的查詢需求，提前編寫相應的 SQL 邏輯，在 Hive 中進行計算，通過流程引擎每天將數據結果導入到 MySQL 中，前臺再根據相應的篩選條件，進行數據查詢以及結果呈現。早期方案能實現以下功能：
T+1 的單維度下，頁面/自定義事件的 PV、UV、停留時長指標查詢；
自定義漏斗分析，但漏斗模型配置後第二天才會生效輸出數據；
有限的留存數據查詢，僅支持每個埋點的次日留存人數。
可以看到早期方案實現的效果遠未達到最初產品規劃的效果，僅能覆蓋最基礎的流量數據查詢需求。然而，隨着業務的發展和業務人員數據意識的增強，對流量數據的查詢越來越精細化，用戶希望得到更豐富的維度、更及時的數據。
早期方案面臨的挑戰
早期方案存在怎樣的問題，導致 APPDATA 無法滿足精細化的流量數據查詢？總結有以下四個原因：
-
僅支持單維度條件查詢，UV 無法實現二次聚合。UV 的計算不是單純的相加，需要依據 UID 做去重計算。早期方案需要數據分析師根據用戶的查詢需求，提前編寫 SQL 計算邏輯，而多維度下的 UV 查詢需要根據用戶的查詢條件實時做去重計算，很顯然，早期方案無法做到。
-
用戶自定義的數據，如漏斗分析，配置需要 T+1 才能生效。用戶在系統上新建漏斗，需要第二天才能看到結果。這個延遲是非常影響業務，因爲新加的漏斗，往往會包含新上線的埋點，那麼新上線的埋點需要 T+1 出數據，漏斗配置又需要 T+1 纔有數據，無法在最好的時機支持運營策略和產品設計上的調整。
-
人工編寫 SQL 計算邏輯，維護起來很困難，開發週期長。APPDATA 上流量指標的計算較爲複雜，由數據分析師編寫 SQL 邏輯，維護起來很麻煩，當有調整時，需要一定的開發週期，無法快速響應業務上的訴求。
-
埋點數據量龐大，導致 MySQL 查效率低。系統時常出現查不出來數據的情況，使得用戶對系統的可靠性產生懷疑。
基於 Kylin 的解決方案
針對上述存在的諸多問題，研發團隊提出引入 Apache Kylin 作爲系統的核心計算引擎加以解決。
爲什麼選擇 Kylin？
回答這個問題，主要還是從實際面臨的問題出發思考。下圖的左邊是上文提到的早期方案存在的四個問題，右邊是 Kylin 的一些特性，可以看到 Kylin 特性能較好的解決問題。
-
Kylin 是一個 OLAP 引擎，可以非常快速地響應海量數據的多維查詢場景。對於 UV 二次聚合，可以將 UV 存儲成 Bitmap，這樣就可以實現根據用戶查詢條件的二次聚合；
-
Kylin 有靈活的框架，支持函數功能擴展，可以利用它提供的交集函數解決自定義數據 T+1 生效的問題；
-
Kylin 提供了一個可視化管理界面，只需在前期對數據做簡單的處理和轉化，後續的數據處理工作都可以在界面上完成，包括定義 Cube 模型、處理數據、到最後的查詢，不用寫一行代碼，可以大大地提高效率；
-
Kylin 使用 HBase 來存儲數據，不會有 MySQL 那樣存太多導致查詢效率低的問題。
除此之外，還有兩個原因：
-
成本問題，Kylin 支持標準 SQL，可使用 JDBC 連接，早期方案也使用 JDBC 連接，新舊方案切換成本比較可控；
-
Kylin 支持 T+0 Cube構建，可以讓 APPDATA 提供 T+0 流量數據查詢，我們認爲實時數據的查詢也是非常有必要的。
基於上述的這些原因，我們選擇引入 Kylin 作爲 APPDATA 的核心計算引擎。
Kylin 和 APPDATA 結合的技術架構
APPDATA 和 Kylin 結合的技術架構圖如下所示：
從左往右，客戶端產生埋點數據，上報到大數據，這些數據首先通過 Kafka 接進來。對於 T+1 的數據，數據寫入 Hive，每天的凌晨根據事先寫好的 SQL 邏輯對數據做簡單的處理和轉化，最終形成一張寬表， 然後根據配置好的 Cube 模型，每天構建一次，然後將結果數據導入到 HBase；對於 T+0 的數據處理，數據進來後會落到 Kafka，在兩個 Kafka 之間我們用程序做了數據轉化的工作，最終的效果也是形成一張寬表，這裏和離線數據不同的是，Cube 構建是每十分鐘構建一次，同樣的，結果數據也會導入到 HBase。數據都準備好之後，剩下的就是響應用戶的查詢了。
新方案能做到哪些早期方案做不到的功能：
-
多維查詢：系統有十多個維度可以相互交叉，並且和任意日期關聯。在新的方案中，對於這種多維的查詢，不再需要像以前一樣，提前梳理用戶可能查詢的指標，對數據建模，然後再進行復雜的數據處理，只需要對數據進行簡單的處理和轉化，配置好 Cube 的模型，然後構建 Cube，APPDATA 根據查詢條件生成相應 SQL 請求 Kylin，就可以得到結果，整個過程非常的優雅；
-
虛擬埋點：虛擬埋點就是若干個埋點組合成的埋點，在很多場景下，只查詢單個埋點的數據是不夠的，需要拉通全域流量數據來看。而虛擬埋點涉及到 UV 聚合去重，早期方案是做不到的，而在新的方案中，只要用戶把這個虛擬埋點具體包含哪些埋點告訴系統，系統生成 SQL 去查詢 Kylin 就可以；
-
自定義漏斗 2.0：在新方案中，我們利用 Kylin 提供的交集函數，實現了漏斗配置後即刻返回結果數據的效果；
-
T+0 流量數據：新的方案實現了 T+0 的流量數據查詢，端到端的延遲大概是15分鐘左右。
顯然，新的實現方式能夠更近一步支持精細化的流量分析，提供豐富的維度、T+0 的數據、即時靈活的自定義數據，讓系統的功能得到了非常強大擴展。
數據情況和運行效率
- 硬件配置
Kylin 集羣總共有三臺服務器，一臺用於構建 Cube，兩臺用於查詢；HBase 服務器一共八臺，每臺機器內存 256GB，CPU 24 核，硬盤 8TB；計算集羣服務器 60 臺，內存 192GB，CPU 24 核，硬盤 144TB。
- 數據量
目前 APPDADA 生產線上有 5 個 Cube，每天有八九億的數據增量，提供近半年數據查詢，共累計了 10+T 的數據。接入了 8 個客戶端，覆蓋公司所有業務線的流量數據。
- 併發量
APPDATA 以 Web 服務和 API 兩種形式服務於公司內部業務人員和業務系統，業務人員的數量在 150 個人左右，對接廣告系統、活動運營平臺兩個業務系統。
- 查詢效率
查詢的效率依賴於查詢條件的複雜程度，經過簡單的測試，目前我們 85% 的查詢是小於 800 毫秒，95% 的查詢小於 3 秒，99% 的查詢小於 7 秒。
調優和改造
在文章的最後，介紹在使用 Kylin 的過程中，做的一些調優操作，以及爲了實現業務上的需求，對 Kylin 做的一點改進。
性能調優
首先，我們對維度做了優化。Kylin 核心的工作就是構建 N 個維度的 Cube，實現聚合的預計算。理論上，構建 N 個維度的 Cube 會生成 2 的 N 次方個 Cuboid。隨着維度的增加，Cuboid 的數量會爆炸式地增長，給 Cube 的構建帶來巨大的壓力。而在實際數據查詢中一些維度之間的組合是不必要的。這樣就可以通過修剪無查詢需求的 Cuboid，來緩解 Cube 構建的壓力。
第二個是 Rowkey 的順序優化。一般而言，Kylin 以 HBase 作爲存儲引擎，而 HBase 是以 Rowkey 順序存儲行的，設計良好的 Rowkey 將更有效地完成數據的查詢過濾和定位，減少 IO 次數，提高查詢速度。這意味着我們可以把查詢中被用作過濾條件的維度放在非過濾條件維度的前面，基數較高的維度，放在基數較低維度的前面，這樣就可以跳過一些不必要的掃描，快速的定位到查詢場景。通過種方式，可以將絕大部分的查詢效率穩定在亞秒級。
上述的這兩個調優操作都能在 Kylin 提供的可視化界面的「高級配置」設置完成。
在應用層面的一點改進
爲了幫助提升產品關鍵路徑的轉化，我們支持產品同學到 APPDATA 上構建漏斗，上文中提到我們用 Kylin 提供的交集函數來計算漏斗數據。假設一個兩步的漏斗，計算時，先分別獨立計算訪問過兩個步驟的用戶數，得到的第一步的用戶數作爲第一步的人數，然後求兩羣人的交集，得到的人數作爲第二步的人數。這裏的求交集就是用到交集函數。
爲了滿足業務上的需要，在配置漏斗時，每一個步驟可以是單個的埋點，也可以是由多個埋點組合成的虛擬埋點。而單個埋點和虛擬埋點是有差異的，前者是物理上的概念，後者是邏輯上的。Kylin 原本提供的交集函數只能支持物理概念上的單個埋點，而不支持多個埋點組合成虛擬埋點，也就是說，不可以先對單個埋點求並集，然後再求交集。在這裏，我們所做的改造就是擴展交集函數支持邏輯上的虛擬埋點。可以看到擴展後，我們可以先讓單個埋點做或者運算，再求交集。
我們用擴展後的交集函數計算漏斗和留存數據。對於漏斗，用戶先創建虛擬埋點，綁定若干個埋點，再創建漏斗，後臺調用交集函數，給出結果。對於留存數據，用戶也是先創建虛擬埋點，系統調用交集函數，計算每個虛擬埋點的日留存、周留存、月留存數據。
最後，要感謝 APPDATA 開發團隊的成員華強、鍾亞雄同學，以及建議 APPDATA 引入 Kylin 的 王賢彬同學，正是因爲大家的努力才使得基於 Kylin 的解決方案成爲可能。
作者介紹：
陳雅婕（WeChat ID：chenyajie1992），前滿幫集團大數據產品經理，曾就職於百度大數據部，多年數據產品工作經驗，先後負責多款大數據產品的搭建，幫助數據團隊從提數階段向數據產品階段轉變。