上一篇文章介紹的Linear Counting算法相較于直接映射bitmap的方法能大大節省內存（大約只需后者1/10的內存），但畢竟只是一個常系數級的降低，空間復雜度仍然為O(Nmax)O(Nmax)。而本文要介紹的LogLog Counting卻只有O(log2(log2(Nmax)))O(log2(log2(Nmax)))。例如，假設基數的上限為1億，原始bitmap方法需要12.5M內存，而LogLog Counting只需不到1K內存（640字節）就可以在標準誤差不超過4%的精度下對基數進行估計，效果可謂十分驚人。

本文將介紹LogLog Counting。

---

簡介

LogLog Counting（以下簡稱LLC）出自論文“Loglog Counting of Large Cardinalities”。LLC的空間復雜度僅有O(log2(log2(Nmax)))O(log2(log2(Nmax)))，使得通過KB級內存估計數億級別的基數成為可能，因此目前在處理大數據的基數計算問題時，所采用算法基本為LLC或其幾個變種。下面來具體看一下這個算法。

基本算法

均勻隨機化

與LC一樣，在使用LLC之前需要選取一個哈希函數H應用于所有元素，然后對哈希值進行基數估計。H必須滿足如下條件（定性的）：

1、H的結果具有很好的均勻性，也就是說無論原始集合元素的值分布如何，其哈希結果的值幾乎服從均勻分布（完全服從均勻分布是不可能的，D. Knuth已經證明不可能通過一個哈希函數將一組不服從均勻分布的數據映射為絕對均勻分布，但是很多哈希函數可以生成幾乎服從均勻分布的結果，這里我們忽略這種理論上的差異，認為哈希結果就是服從均勻分布）。

2、H的碰撞幾乎可以忽略不計。也就是說我們認為對于不同的原始值，其哈希結果相同的概率非常小以至于可以忽略不計。

3、H的哈希結果是固定長度的。

以上對哈希函數的要求是隨機化和后續概率分析的基礎。后面的分析均認為是針對哈希后的均勻分布數據進行。

思想來源

下面非正式的從直觀角度描述LLC算法的思想來源。

設a為待估集合（哈希后）中的一個元素，由上面對H的定義可知，a可以看做一個長度固定的比特串（也就是a的二進制表示），設H哈希后的結果長度為L比特，我們將這L個比特位從左到右分別編號為1、2、…、L：

又因為a是從服從均與分布的樣本空間中隨機抽取的一個樣本，因此a每個比特位服從如下分布且相互獨立。

下面解釋為什么可以這樣估計。注意如下事實：

由于比特串每個比特都獨立且服從0-1分布，因此從左到右掃描上述某個比特串尋找第一個“1”的過程從統計學角度看是一個伯努利過程，例如，可以等價看作不斷投擲一個硬幣（每次投擲正反面概率皆為0.5），直到得到一個正面的過程。在一次這樣的過程中，投擲一次就得到正面的概率為

分桶平均

上述分析給出了LLC的基本思想，不過如果直接使用上面的單一估計量進行基數估計會由于偶然性而存在較大誤差。因此，LLC采用了分桶平均的思想來消減誤差。具體來說，就是將哈希空間平均分成m份，每份稱之為一個桶（bucket）。對于每一個元素，其哈希值的前k比特作為桶編號，

偏差修正

上述經過分桶平均后的估計量看似已經很不錯了，不過通過數學分析可以知道這并不是基數n的無偏估計。因此需要修正成無偏估計。這部分的具體數學分析在“Loglog Counting of Large Cardinalities”中，過程過于艱澀這里不再具體詳述，有興趣的朋友可以參考原論文。這里只簡要提一下分析框架：

首先上文已經得出：

誤差分析

不加證明給出如下結論：

算法應用

誤差控制

在應用LLC時，主要需要考慮的是分桶數m，而這個m主要取決于誤差。根據上面的誤差分析，如果要將誤差控制在?之內，則：

內存使用分析

合并

與LC不同，LLC的合并是以桶為單位而不是bit為單位，由于LLC只需記錄桶的ρmax，因此合并時取相同桶編號數值最大者為合并后此桶的數值即可。

小結

本文主要介紹了LogLog Counting算法，相比LC其最大的優勢就是內存使用極少。不過LLC也有自己的問題，就是當n不是特別大時，其估計誤差過大，因此目前實際使用的基數估計算法都是基于LLC改進的算法，這些改進算法通過一定手段抑制原始LLC在n較小時偏差過大的問題。后面要介紹的HyperLogLog Counting和Adaptive Counting就是這類改進算法。

總結

以上是生活随笔為你收集整理的解读Cardinality Estimation算法（第三部分：LogLog Counting）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。