統計功能是一類極為常見的需求，比如下面這個場景：
簡單來說就是統計一天內，某個頁面的訪問用戶量，如果相同的用戶再次訪問，也只算記為一次訪問。
Redis與統計
聚合統計
要完成這個統計任務，最直觀的方式是使用一個SET保存頁面在某天的訪問用戶 ID，然后通過對集合求差SDIFF和求交SINTER完成統計：
# 2020-01-01 當日的 UV
SADD page:uv:20200101 "Alice" "Bob" "Tom" "Jerry"
# 2020-01-02 當日的 UV
SADD page:uv:20200102 "Alice" "Bob" "Jerry" "Nancy"
# 2020-01-02 新增用戶
SDIFFSTORE page:new:20200102 page:uv:20200102 page:uv:20200101
# 2020-01-02 新增用戶數量
SCARD page:new:20200102
# 2020-01-02 留存用戶
SINTERSTORE page:rem:20200102 page:uv:20200102 page:uv:20200101
# 2020-01-02 留存用戶數量
SCARD page:rem:20200102
優點：
- 操作直觀易理解，可以復用現有的數據集合
- 保留了用戶的訪問細節，可以做更細粒度的統計
缺點：
- 內存開銷大，假設每個用戶ID長度均小於 44 字節（使用 embstr 編碼），記錄 1 億用戶也至少需要 6G 的內存
SUNION、SINTER、SDIFF計算復雜度高，大數據量情況下會導致 Redis 實例阻塞，可選的優化方式有：- 從集群中選擇一個從庫專門負責聚合計算
- 把數據讀取到客戶端，在客戶端來完成聚合統計
二值統計
當用戶 ID 是連續的整數時，可以使用BITMAP實現二值統計：
# 2020-01-01 當日的 UV
SETBIT page:uv:20200101 0 1 # "Alice"
SETBIT page:uv:20200101 1 1 # "Bob"
SETBIT page:uv:20200101 2 1 # "Tom"
SETBIT page:uv:20200101 3 1 # "Jerry"
# 2020-01-02 當日的 UV
SETBIT page:uv:20200102 0 1 # "Alice"
SETBIT page:uv:20200102 1 1 # "Bob"
SETBIT page:uv:20200102 3 1 # "Jerry"
SETBIT page:uv:20200102 4 1 # "Nancy"
# 2020-01-02 新增用戶
BITOP NOT page:not:20200101 page:uv:20200101
BITOP AND page:new:20200102 page:uv:20200102 page:not:20200101
# 2020-01-02 新增用戶數量
BITCOUNT page:new:20200102
# 2020-01-02 留存用戶
BITOP AND page:rem:20200102 page:uv:20200102 page:uv:20200101
# 2020-01-02 留存用戶數量
BITCOUNT page:new:20200102
優點：
- 內存開銷低，記錄 1 億個用戶只需要 12MB 內存
- 統計速度快，計算機對比特位的異或運算十分高效
缺點：
- 對數據類型有要求，只能處理整數集合
基數統計
前面兩種方式都能提供准確的統計結果，但是也存在以下問題：
- 當統計集合變大時，所需的存儲內存也會線性增長
- 當集合變大時，判斷其是否包含新加入元素的成本變大
考慮下面這一場景：
只統計一個集合中 不重復的元素個數，而並不關心集合元素內容的統計方式，我們將其稱為 基數計數
cardinality counting
針對這一特定的統計場景，Redis 提供了HyperLogLog類型支持基數統計：
# 2020-01-01 當日的 UV
PFADD page:uv:20200101 "Alice" "Bob" "Tom" "Jerry"
PFCOUNT page:uv:20200101
# 2020-01-02 當日的 UV
PFADD page:uv:20200102 "Alice" "Bob" "Tom" "Jerry" "Nancy"
PFCOUNT page:uv:20200102
# 2020-01-01 與 2020-01-02 的 UV 總和
PFMERGE page:uv:union page:uv:20200101 page:uv:20200102
PFCOUNT page:uv:union
優點：
HyperLogLog計算基數所需的空間是固定的。只需要 12KB 內存就可以計算接近 \(2^{64}\) 個元素的基數。
缺點：
HyperLogLog的統計是基於概率完成的，其統計結果是有一定誤差。不適用於精確統計的場景。
HyperLogLog 解析
概率估計
HyperLogLog是一種基於概率的統計方式，該如何理解？
我們來做一個實驗：不停地拋一個均勻的雙面硬幣，直到結果是正面為止。
用 0 和 1 分別表示正面與反面，則實驗結果可以表示為如下二進制串：
+-+
第 1 次拋到正面 |1|
+-+
+--+
第 2 次拋到正面 |01|
+--+
+---+
第 3 次拋到正面 |001|
+---+
+---------+
第 k 次拋到正面 |000...001| (總共 k-1 個 0)
+---------+
進行 n 實驗后，將每次實驗拋硬幣的次數記為 \(k_1, k_3,\cdots,k_n\)，其中的最大值記為 \(k_{max}\)。
理想情況下有 \(k_{max} = log_2(n)\)，反過來也可以通過 \(k_{max}\) 來估計總的實驗次數 \(n = 2^{k_{max}}\)。
處理極端情況
實際進行實驗時，極端情況總會出現，比如在第 1 次實驗時就連續拋出了 10 次反面。
如果按照前面的公式進行估計，會認為已經進行了 1000 次實驗，這顯然與事實不符。
為了提高估計的准確性，可以同時使用 m 枚硬幣進行 分組實驗。
然后計算這 m 組實驗的平均值 \(\hat{k}_{max} = \frac{\sum_{i=0}^{m}{k_{max}}}{m}\)，此時能更准確的估計實際的實驗次數 \(\hat{n}=2^{\hat{k}_{max}}\)。
基數統計
通過前面的分析，我們可以總結出以下經驗：
可以通過二進制串中首個 1 出現的位置 \(k_{max}\) 來估計實際實驗發生的次數 \(n\)
HyperLogLog借鑒上述思想來統計集合中不重復元素的個數：
- 使用 hash 函數集合中的每個元素映射為定長二進制串
- 利用 分組統計 的方式提高准確性，將二進制串分到 \(m\) 個不同的桶
bucket中分別統計- 二進制串的前 \(log_2{m}\) 位用於計算該元素所屬的桶
- 剩余二進制位中，首個 1 出現的比特位記為 \(k\)，每個桶中的只保存最大值 \(k_{max}\)
- 當需要估計集合中包含的元素個數時，使用公式 \(\hat{n}=2^{\hat{k}_{max}}\) 計算即可
下面來看一個例子：
HyperLogLog實現，使用
8bit 輸出的 hash 函數並以
4 個桶進行分組統計
使用該 HLL 統計 Alice，Bob，Tom，Jerry，Nancy 這 5 個用戶訪問頁后的 UV
映射為二進制串 分組 計算k
| | |
V V V
+---------+
hash("Alice") => |01|101000| => bucket=1, k=1
+---------+ 分組統計 k_max
+---------+
hash("Bob") => |11|010010| => bucket=3, k=2 +----------+----------+----------+----------+
+---------+ | bucket_0 | bucket_1 | bucket_2 | bucket_3 |
+---------+ ==> +----------+----------+----------+----------+
hash("Tom") => |10|001000| => bucket=2, k=3 | k_max= 1 | k_max= 2 | k_max= 3 | k_max= 2 |
+---------+ +----------+----------+----------+----------+
+---------+
hash("Jerry") => |00|111010| => bucket=0, k=1
+---------+
+---------+
hash("Nancy") => |01|010001| => bucket=1, k=2
+---------+
分組計數完成后，用之前的公式估計集合基數為 \(2^{\hat{k}_{max}}= 2^{(\frac{1+2+3+2}{4})} = 4\)。
誤差分析
在 Redis 的實現中，對於一個輸入的字符串，首先得到 64 位的 hash 值：
- 前 14 位來定位桶的位置（共有16384個桶）
- 后 50 位用作元素對應的二進制串（用於更新首次出現 1 的比特位的最大值 \(k_{max}\)）
由於使用了 64 位輸出的 hash 函數，因此可以計數的集合的基數沒有實際限制。
HyperLogLog的標准誤差計算公式為 \(\frac{1.04}{\sqrt{m}}\)（\(m\) 為分組數量），據此計算 Redis 實現的標准誤差為 \(0.81\%\)。
下面這幅圖展示了統計誤差與基數大小的關系：
- 紅線和綠線分別代表兩個不同分布的數據集
- x 軸表示集合實際基數
- y 軸表示相對誤差（百分比）
分析該圖可以得出以下結論：
- 統計誤差與數據本身的分布特征無關
- 集合基數越小，誤差越小（小基數時精度高）
- 集合基數越大，誤差越大（大基數時省資源）