[[173570]]

1. 概念

1.1 UV 與 PV

對于互聯(lián)網(wǎng)產(chǎn)品來說，UV 與 PV 是兩個(gè)非常常見的指標(biāo)，并且通常都是分析的最基礎(chǔ)指標(biāo)。UV 一般來講，是指使用產(chǎn)品(或產(chǎn)品某個(gè)功能)的獨(dú)立用戶數(shù)。PV 則來源于網(wǎng)站時(shí)代，一般指網(wǎng)站(或網(wǎng)站某個(gè)頁面)的頁面瀏覽量，在移動(dòng)互聯(lián)網(wǎng)時(shí)代，則一般會(huì)引申表示使用產(chǎn)品(或產(chǎn)品某個(gè)功能)的用戶行為或者用戶操作數(shù)量。

PV 和 UV 一般而言是互相影響，一起變化的，對于 PV 和 UV 的變化與數(shù)字的解讀，也是一門很深的學(xué)問。由于本文主要是介紹在多維分析中 UV 和 PV 的計(jì)算規(guī)則，所以，對于 PV 和 UV 的具體解讀與分析，不做展開論述。

1.2 多維分析

多維分析是在 BI(Business Intelligence)領(lǐng)域廣泛使用的一種分析技術(shù)和分析方法，能夠從不同的角度，靈活動(dòng)態(tài)地進(jìn)行分析。

多維分析中有“指標(biāo)”和“維度”兩個(gè)基本概念，在這里，我們用一個(gè)實(shí)際的例子來進(jìn)行描述。

一個(gè)典型的網(wǎng)站，它可能需要從地域、終端、App 版本這三個(gè)角度，來考察自己的 PV 和 UV 的情況。那么，在這個(gè)場景下，維度有三個(gè)，分別是地域、終端和 App 版本;指標(biāo)則是兩個(gè)，分別是 PV 和 UV。所謂的多維分析，就是可以在維度的任意組合情況下，來看對應(yīng)的指標(biāo)的數(shù)值：可以看北京的，iOS端的，7.1 版 App 的 PV 和 UV;也可以看湖北的安卓端的 PV 和 UV;也可以看 7.2 版 App 的 PV 和 UV。具體設(shè)置查詢條件的時(shí)候，維度可以是三個(gè)，可以是兩個(gè)，也可以是一個(gè)。從這個(gè)例子可以看出，多維分析是非常靈活的，具有很強(qiáng)的分析能力，可以充分滿足分析人員對于產(chǎn)品的各種細(xì)粒度的分析需求。

而為了能夠讓多維分析發(fā)揮出更大的價(jià)值，一般情況下，都是希望多維分析的查詢結(jié)果能夠在一分鐘能就得到，從而可以讓使用者不停地調(diào)整查詢條件，快速地驗(yàn)證自己的猜想。

2. “可加”與“不可加”

正如上面提到的，多維分析對于查詢速度非常敏感，業(yè)內(nèi)也有很多專門的存儲(chǔ)和查詢方案。

而在具體的實(shí)現(xiàn)中，有一種最為常見的實(shí)現(xiàn)手段，就是把各個(gè)維度的所有取值組合下的指標(biāo)全部預(yù)先計(jì)算并且存儲(chǔ)好，這種一般可以稱作事實(shí)表。然后在具體進(jìn)行多維查詢的時(shí)候，再根據(jù)維度的選擇，掃描相對應(yīng)的數(shù)據(jù)，并聚合得到最終的查詢條件。

此時(shí)，會(huì)發(fā)現(xiàn)一個(gè)比較有意思的問題，就是 PV 這類指標(biāo)，是“可加”的，而 UV 這類指標(biāo)，則是“不可加”的。例如，我們把昨天三個(gè)維度的可能組合下的所有的 PV 和 UV 都計(jì)算并且存儲(chǔ)好，如下表所示：

那么，對于 PV 這種指標(biāo)，是可以通過掃描對應(yīng)的記錄，然后累加得到最終的結(jié)果。例如，我們想分析整個(gè)湖北的 PV，則可以把湖北相關(guān)的四條記錄中的 PV，累加起來就是整個(gè)湖北的 PV 值。

但是，對于 UV 這類指標(biāo)，卻不能簡單的累加，因?yàn)?，這個(gè)指標(biāo)并不是在每一個(gè)維度上都是正交的。例如，同一個(gè)用戶可能先后使用了不同的 App 版本，甚至于有一定幾率使用了不同的終端，所以，UV 并不能簡單地累加，通常情況下，真實(shí)的 UV 是比加起來的值更小的。

因而，對于 UV 這類不可累加的指標(biāo)，需要使用其它的計(jì)算方案。

3. UV 計(jì)算的常見方案

UV 類型的指標(biāo)，有三種常見的計(jì)算方案，我們在這里分別進(jìn)行介紹。

3.1 估算方案

所謂的估算方案，就是在上面的表格的基礎(chǔ)上，不再額外記錄更多細(xì)節(jié)，而是通過估算的方式來給出一個(gè)接近真實(shí)值的 UV 結(jié)果，常見的算法有很多，例如 HyperLogLog 等。

由于畢竟是估算，最終估算的結(jié)果有可能與真實(shí)值有較大差異，因此只有一些統(tǒng)計(jì)平臺(tái)可能會(huì)采用，而如我們 Sensors Analytics 之類的以精細(xì)化分析為核心的分析系統(tǒng)并不會(huì)采用，因此在這里不做更多描述。

3.2 擴(kuò)充事實(shí)表，以存代算

所謂以存代算，就是在預(yù)先計(jì)算事實(shí)表的時(shí)候，將所有需要聚合的結(jié)果，都算好。

依然以上面的例子來說明，如果我們想以存代算，預(yù)先做完聚合，類似于 Hive 所提供的group by with cube操作。在擴(kuò)充完畢后，之前那個(gè)表的結(jié)果就應(yīng)該是：

從這個(gè)表我們可以看出，假設(shè)一共三個(gè)維度，每個(gè)維度有兩個(gè)取值，則之前的事實(shí)表一共是 2*2*2=8 條記錄，而現(xiàn)在，則擴(kuò)充到了 3*3*3-1=26 條記錄，整個(gè)規(guī)模擴(kuò)充了很多，會(huì)帶來更多的存儲(chǔ)和預(yù)計(jì)算的代價(jià)。

3.3 從最細(xì)粒度數(shù)據(jù)上掃描

之前提出的擴(kuò)充事實(shí)表的方式，的確可以解決多維分析中指標(biāo)聚合的問題，除此之外，還有一種方案，則是在事實(shí)表上，將用戶ID也做為一個(gè)維度，來進(jìn)行保存，此時(shí)就不需要保存 UV 了，如下表所示：

甚至更進(jìn)一步，我們將 PV 數(shù)值也進(jìn)一步展開，對于用戶的每一個(gè)行為，都保留一條數(shù)據(jù)，如下表：

雖然這樣一來，需要保存的數(shù)據(jù)規(guī)模有了數(shù)量級(jí)上的擴(kuò)充，并且所有的聚合計(jì)算都需要在多維分析查詢的時(shí)候再掃描數(shù)據(jù)并進(jìn)行聚合，存儲(chǔ)和計(jì)算代價(jià)都提高了很多，看似是一種很無所謂的舉措。

但是，相比較之前的方案，它卻有一個(gè)***的好處，也即是因?yàn)橛辛俗罴?xì)粒度的用戶行為數(shù)據(jù)，才有可能計(jì)算事件級(jí)別的漏斗、留存、回訪等，才有可能在這些數(shù)據(jù)的基礎(chǔ)之上，進(jìn)一步做用戶畫像、個(gè)性化推薦等等。而這也正是目前 Sensors Analytics 所采用的數(shù)據(jù)存儲(chǔ)方案，也正因?yàn)椴捎昧诉@種存儲(chǔ)方案，我們才能夠?qū)⒆约撼蔀榫?xì)化用戶行為分析系統(tǒng)，才能夠滿足使用者的最細(xì)粒度數(shù)據(jù)分析和獲取的需求。

在這樣一個(gè)數(shù)據(jù)存儲(chǔ)方案的基礎(chǔ)上，為了提高數(shù)據(jù)查詢的效能，一般的優(yōu)化思路有采用列存儲(chǔ)加壓縮的方式減少從磁盤中掃描的數(shù)據(jù)量，采用分布式的方案提高并發(fā)掃描的性能，采用應(yīng)用層緩存來減少不同查詢的公共掃描數(shù)據(jù)的量等等，這方面的內(nèi)容我們會(huì)在后面的文章里面做進(jìn)一步的探討，盡請期待