本文來自神策數(shù)據(jù)聯(lián)合創(chuàng)始人&首席架構(gòu)師付力力在 QCon 北京 2017 年全球軟件開發(fā)者大會(huì)上的精彩分享，主題是“基于 ImpalaS 構(gòu)建實(shí)時(shí)用戶行為分析引擎”。

---

付力力：大家好，今天的主題是“基于 ImpalaS 構(gòu)建實(shí)時(shí)用戶行為分析引擎”。

我今天的分享共有四部分，第一，簡單介紹一下什么是用戶行為分析。第二，講解用戶行為分析需求，涉及的整體的架構(gòu)以及這個(gè)架構(gòu)下的整體數(shù)據(jù)模型。第三，講解架構(gòu)關(guān)鍵點(diǎn)——如何實(shí)現(xiàn)實(shí)時(shí)導(dǎo)入。第四，講一些針對具體場景的查詢性能優(yōu)化點(diǎn)。

什么是用戶行為分析

用戶行為五大要素：4W1H

用戶行為是非常普遍常見的定義，無非是誰在什么時(shí)候干了什么事情。有很多很多的例子，無論是線上 APP 的操作、網(wǎng)頁瀏覽或者是線下購物，都包含了幾個(gè)要素。首先有參與者，誰是這個(gè)中心的主體，這是必須包含的；其次發(fā)生的時(shí)間、地點(diǎn)、行為的方式、具體做了什么事情，都會(huì)構(gòu)成用戶行為的幾大要素。

所以用戶行為是非常普遍的容易做抽象處理的數(shù)據(jù)，生產(chǎn)活動(dòng)會(huì)涉及到大量行為數(shù)據(jù)，這個(gè)數(shù)據(jù)可以被收集并產(chǎn)生很大的價(jià)值。從技術(shù)的角度講，它是一種特化的日志數(shù)據(jù)。

其實(shí)大家在不知不覺中已經(jīng)用到了用戶行為數(shù)據(jù)，可能是做用戶分析，產(chǎn)生一些 BI 報(bào)表，或者統(tǒng)計(jì) PV、UV。其次是 PM 做產(chǎn)品改進(jìn)，比如觀察產(chǎn)品的用戶黏性，或者新功能點(diǎn)給用戶帶來的影響、核心的交易流程或者注冊流程的轉(zhuǎn)化率符不符合預(yù)期，這些都與用戶行為直接相關(guān)，用戶行為分析也可以支持商務(wù)、市場、銷售部門進(jìn)行業(yè)務(wù)決策。

?

用戶行為需求：靈活性>及時(shí)性>時(shí)效性

首先主要總結(jié)一下應(yīng)用的需求特點(diǎn)：

時(shí)間軸、大量維度、維度取值分散；

分析靈活性要求高，查詢模式變化多；

要求實(shí)時(shí)響應(yīng)；

查詢頻率較低；

靈活性> 及時(shí)性 > 時(shí)效性。

需求特點(diǎn)非常顯著，首先，行為數(shù)據(jù)有一個(gè)最大的特點(diǎn)是時(shí)間軸：隨著時(shí)間不斷累計(jì)。且維度非常多，因?yàn)闃I(yè)務(wù)的范圍千差萬別。另一個(gè)特點(diǎn)是靈活性要求非常高，因?yàn)槭裁礃I(yè)務(wù)都可以基于用戶行為分析來做。另外是行為分析要求及時(shí)性。與傳統(tǒng)的 BI 報(bào)表相比，最大的區(qū)別在于用戶行為分析需要反復(fù)迭代和嘗試。最后，行為分析查詢頻率比較低，不需要它支撐頻率較高的業(yè)務(wù)。

在整體設(shè)計(jì)目標(biāo)上，系統(tǒng)的靈活性必須是第一位，其次是及時(shí)性，就是能夠?qū)崟r(shí)響應(yīng)分析的需求，讓分析人員能夠快速迭代，最后是時(shí)效性。

如何搭建整體架構(gòu)及數(shù)據(jù)模型簡介

如何選擇合適的查詢引擎

現(xiàn)在有非常多的查詢引擎，大家支持的特性和業(yè)務(wù)場景都差萬別，我們在選擇查詢引擎的時(shí)候，需要有兩個(gè)特點(diǎn)，一方面是足夠靈活。能夠比較完善地支持標(biāo)準(zhǔn)的SQL。另一方面是要足夠快。查詢引擎只是支持SQL很簡單，無非就是速度慢，但有一個(gè)很大的問題，不夠快的查詢引擎，不能實(shí)現(xiàn)交互查詢，不能滿足快速分析迭代的需求。

詳細(xì)解析 ImpalaS 架構(gòu)

我們選擇 ImpalaS，因?yàn)榻裉斓恼麄€(gè)架構(gòu)優(yōu)化是圍繞 Impala?來講的，所以簡單講一下 Impala?本身有什么特點(diǎn)：

大部分功能特性和 Hive 類似；

基于MPP 的查詢引擎；

較低的容錯(cuò)性；

較高的內(nèi)存需求；

較高的查詢效率。

首先，Impala?出現(xiàn)的時(shí)間不短，功能特性上和 Hive 比較像，但是它是基于 MPP 的查詢引擎，這是和 Hive 比較大的區(qū)別。Hive 的查詢執(zhí)行層完全基于如 MapReduce、Spark 的底層的執(zhí)行引擎，本身并不包含執(zhí)行層的東西，但是 Impala?是一個(gè)含有自己的 MPP 執(zhí)行層的查詢引擎，這是它能實(shí)現(xiàn)較快查詢的本質(zhì)原因。第三，容錯(cuò)性較差，Impala?不像MR或 SPARK，故障之后會(huì)有自動(dòng)重試機(jī)制。第四，內(nèi)存需求比較高，絕大部分中間的數(shù)據(jù)操作都會(huì)在內(nèi)存中完成。第五，查詢效率比較高，這是選擇它的最大原因。

很多客戶會(huì)問我們，為什么他們用 Impala?這么慢，這里有很重要的一點(diǎn)，Impala?官方推薦的是與數(shù)據(jù)節(jié)點(diǎn)要同機(jī)混部，實(shí)際上很多企業(yè)沒有做到這點(diǎn)?；?Impala?可以推導(dǎo)出一個(gè)非常簡單的系統(tǒng)架構(gòu)，最前端的頭像表示用戶使用交互界面，之后把前端用戶查詢的需求轉(zhuǎn)化成 SQL 發(fā)給 Impala，左側(cè)是數(shù)據(jù)采集，會(huì)實(shí)時(shí)寫入用戶行為表，右側(cè)是查詢緩存。

有兩個(gè)表非常重要：用戶行為表和用戶表。神策的架構(gòu)非常簡化，因?yàn)閿?shù)據(jù)模型簡單。我們的數(shù)據(jù)源多種多樣，例如客戶端操作、服務(wù)端日志、訂單數(shù)據(jù)、注冊數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)、商品的信息、書或漫畫的信息，客戶通過 SDK 和導(dǎo)入工具可以導(dǎo)入這些數(shù)據(jù)，最終構(gòu)建了用戶行為表和用戶表。概念雖然簡單，但是卻是架構(gòu)的核心。首先，簡單的模型有助于大大減少 ETL 計(jì)算成本和管理數(shù)據(jù)的成本。其次，在業(yè)務(wù)上兩張表的邏輯便于業(yè)務(wù)員了解，這點(diǎn)很重要，因?yàn)樽罱K的設(shè)計(jì)還是為業(yè)務(wù)服務(wù)的。

用戶行為表就是每一條數(shù)據(jù)代表一個(gè)用戶的行為，簡單抽象，整個(gè)表非常寬，設(shè)計(jì)物理存儲(chǔ)的時(shí)候需要考慮這個(gè)因素。

用戶表相對簡單一些，記錄了用戶當(dāng)前的狀態(tài)，可更新。

在物理存儲(chǔ)上，神策用 HDFS 存儲(chǔ)數(shù)據(jù)。目錄結(jié)構(gòu)按日期做分區(qū)，每個(gè)分區(qū)存 N 個(gè)文件，每個(gè)文件是 Parquet 的文件。結(jié)構(gòu)雖然簡單，但是做分區(qū)和文件切割時(shí)，保持合理大小，Parquet 的掃描性能才能達(dá)到預(yù)期效果。以及，我們還會(huì)在存儲(chǔ)時(shí)做一些局部排序。

用 Parquet 格式，是非常主流的做法，但是因?yàn)?Parquet 是一個(gè)支持批量寫入、無法追加的文件格式，所以無法實(shí)現(xiàn)實(shí)時(shí)的數(shù)據(jù)流。

Kudu 優(yōu)化查詢視圖

Kudu 作為新一代面向?qū)崟r(shí)分析的存儲(chǔ)引擎：

底層使用類似 Parquet 的存儲(chǔ)結(jié)構(gòu)；

支持實(shí)時(shí)寫入、實(shí)時(shí)更新及隨機(jī)查詢；

掃描性能比 Parquet 略差。

在引入 Kudu 后，架構(gòu)發(fā)生了變化，中間虛線框是用戶行為表下的一個(gè) HDFS 文件，上面是 Parquet 文件，實(shí)時(shí)寫入 Kudu 后，有一個(gè)第三方模塊定時(shí)把 Kudu 的數(shù)據(jù)轉(zhuǎn)化成 Parquet 的數(shù)據(jù)，存儲(chǔ)在 HDFS 上。頂層形式是兩張物理的表，一張?jiān)?Kudu 一張?jiān)?Parquet，在上層構(gòu)建一個(gè)查詢試圖，這個(gè)查詢視圖有兩個(gè)優(yōu)點(diǎn)，1. Kudu 實(shí)時(shí)的特性，能夠達(dá)到秒級的實(shí)時(shí)寫入，并發(fā)寫入量非?？捎^，很容易達(dá)到 3-5 萬的寫入量；2. 保留了 Parquet 高速掃描的能力。

雖然底層是兩張表，但是從上層應(yīng)用或者系統(tǒng)其他模塊看，頂層是一張表。這就是剛才講的，使用 UNION ALL，能夠讓數(shù)據(jù)拷貝零損耗，達(dá)到查詢上層和底層的視圖完全等效。

?

查詢性能優(yōu)化 Tips

基本查詢優(yōu)化

這個(gè)架構(gòu)為什么能夠滿足行為分析的查詢需求，很重要的是查詢優(yōu)化。

首先要有合理的硬件。我們給客戶做系統(tǒng)部署時(shí)，都會(huì)按照我們的要求做嚴(yán)格的基準(zhǔn)測試。CPU 以 16 核為主，正常 IO 的磁盤，不要用性能很差的磁盤或虛擬磁盤，至少要千兆網(wǎng)絡(luò)，內(nèi)存要 64G，不要用十臺 8G 的的機(jī)器充當(dāng)一臺 64G 的機(jī)器。

其次，就是寫好 SQL。很多查詢系統(tǒng)慢的重要原因是 SQL 寫的不好。 Impala 有一個(gè)缺陷，資源隔離做的不是特別好，寫的很爛的 SQL 會(huì)導(dǎo)致整個(gè)系統(tǒng)資源完全被占滿，無法進(jìn)行其他工作。

我們用三個(gè)標(biāo)準(zhǔn)節(jié)點(diǎn)做了一些基準(zhǔn)測試，在不做任何其它優(yōu)化的情況下，基本 10 秒內(nèi)可以完成 10 億內(nèi)行為數(shù)據(jù)的分組聚合。大家如果沒有達(dá)到這個(gè)效果，可能需要反思一下是不是硬件配置有問題，或者是 Parquet 文件大小不合適等前面提過的原因。

后面是一些特定場景下的優(yōu)化點(diǎn)供大家參考，不一定每人都能用到。

查詢抽樣

為什么要做抽樣：節(jié)約成本、提高效率。

查詢抽樣 vs 采集抽樣：

（1）存儲(chǔ)便宜，應(yīng)該盡量存儲(chǔ)最全的數(shù)據(jù)。

（2）抽樣分析的局限性，例如細(xì)分維度的分析。

有一些業(yè)務(wù)點(diǎn)只有少數(shù)用戶能觸發(fā)，采集抽樣可能會(huì)達(dá)不到抽樣的結(jié)果，偏差很大。

查詢抽樣的抽樣邏輯：首先按照用戶抽樣，不能隨機(jī)抽樣，必須保證用戶行為的完整性，

抽樣實(shí)現(xiàn)有非常多的方式。

根據(jù)用戶 ID 的 Hash 值得到抽樣編號。

Parquet / Kudu 數(shù)據(jù)按照抽樣編號排序。

Impala 進(jìn)行查詢掃描時(shí)根據(jù)需要只掃描需要部分的數(shù)據(jù)。

實(shí)現(xiàn)轉(zhuǎn)化漏斗

漏斗是非常常見的產(chǎn)品應(yīng)用，可以分析產(chǎn)品各個(gè)流程的轉(zhuǎn)化。神策分析可以實(shí)現(xiàn)任意定義轉(zhuǎn)化邏輯，任意選擇查詢時(shí)段，得到每個(gè)用戶精確的轉(zhuǎn)化信息。

計(jì)算邏輯

從用戶行為表抽取需要的事件數(shù)據(jù)。

事件數(shù)據(jù)按照用戶 ID 分組，每個(gè)分組內(nèi)按照時(shí)間排序，得到用戶序列。

進(jìn)行具體的轉(zhuǎn)化邏輯計(jì)算。

實(shí)現(xiàn)方式

實(shí)現(xiàn)自定義的分析函數(shù)（UDAnF），需要對 Impala 進(jìn)行改造

優(yōu)化最耗時(shí)的步驟：全局排序 -> 預(yù)排序 + 歸并排序

Join 優(yōu)化

優(yōu)化邏輯

使用每天的活躍用戶數(shù)據(jù)構(gòu)建 Bloom Filter；

Join 之前先用 Bloom Filter 對用戶表進(jìn)行過濾；

優(yōu)化效果：Join 右表的數(shù)據(jù)量從數(shù)億降到數(shù)千萬。

總結(jié)

綜上所述，架構(gòu)的數(shù)據(jù)模型非常簡化，用戶表加用戶行為表，這是大前提，基于這個(gè)數(shù)據(jù)模型選擇支持 SQL 的通用查詢引擎：ImpalaS 和 Kudu，針對應(yīng)用場景進(jìn)行針對性的性能優(yōu)化，最后完成實(shí)時(shí)用戶引擎的構(gòu)建。

?

?

?

?

總結(jié)

以上是生活随笔為你收集整理的付力力: 基于 ImpalaS 构建实时用户行为分析引擎的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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