基數計數（cardinality counting）是實際應用中一種常見的計算場景，在數據分析、網絡監控及數據庫優化等領域都有相關需求。精確的基數計數算法由于種種原因，在面對大數據場景時往往力不從心，因此如何在誤差可控的情況下對基數進行估計就顯得十分重要。目前常見的基數估計算法有Linear Counting、LogLog Counting、HyperLogLog Counting及Adaptive Counting等。這幾種算法都是基于概率統計理論所設計的概率算法，它們克服了精確基數計數算法的諸多弊端（如內存需求過大或難以合并等），同時可以通過一定手段將誤差控制在所要求的范圍內。

作為“解讀Cardinality Estimation算法”系列文章的第一部分，本文將首先介紹基數的概念，然后通過一個電商數據分析的例子說明基數如何在具體業務場景中發揮作用以及為什么在大數據面前基數的計算是困難的，在這一部分也同時會詳述傳統基數計數的解決方案及遇到的難題。

后面在第二部分-第四部分會分別詳細介紹Linear Counting、LogLog Counting、HyperLogLog Counting及Adaptive Counting四個算法，會涉及算法的基本思路、概率分析及論文關鍵部分的解讀。

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

基數的定義

簡單來說，基數（cardinality，也譯作勢），是指一個集合（這里的集合允許存在重復元素，與集合論對集合嚴格的定義略有不同，如不做特殊說明，本文中提到的集合均允許存在重復元素）中不同元素的個數。例如看下面的集合：

{1,2,3,4,5,2,3,9,7}{1,2,3,4,5,2,3,9,7}

這個集合有9個元素，但是2和3各出現了兩次，因此不重復的元素為1,2,3,4,5,9,7，所以這個集合的基數是7。

如果兩個集合具有相同的基數，我們說這兩個集合等勢。基數和等勢的概念在有限集范疇內比較直觀，但是如果擴展到無限集則會比較復雜，一個無限集可能會與其真子集等勢（例如整數集和偶數集是等勢的）。不過在這個系列文章中，我們僅討論有限集的情況，關于無限集合基數的討論，有興趣的同學可以參考實變分析相關內容。

容易證明，如果一個集合是有限集，則其基數是一個自然數。

基數的應用實例

下面通過一個實例說明基數在電商數據分析中的應用。

假設一個淘寶網店在其店鋪首頁放置了10個寶貝鏈接，分別從Item01到Item10為這十個鏈接編號。店主希望可以在一天中隨時查看從今天零點開始到目前這十個寶貝鏈接分別被多少個獨立訪客點擊過。所謂獨立訪客（Unique Visitor，簡稱UV）是指有多少個自然人，例如，即使我今天點了五次Item01，我對Item01的UV貢獻也是1，而不是5。

用術語說這實際是一個實時數據流統計分析問題。

要實現這個統計需求。需要做到如下三點：

1、對獨立訪客做標識

2、在訪客點擊鏈接時記錄下鏈接編號及訪客標記

3、對每一個要統計的鏈接維護一個數據結構和一個當前UV值，當某個鏈接發生一次點擊時，能迅速定位此用戶在今天是否已經點過此鏈接，如果沒有則此鏈接的UV增加1

下面分別介紹三個步驟的實現方案

對獨立訪客做標識

客觀來說，目前還沒有能在互聯網上準確對一個自然人進行標識的方法，通常采用的是近似方案。例如通過登錄用戶+cookie跟蹤的方式：當某個用戶已經登錄，則采用會員ID標識；對于未登錄用戶，則采用跟蹤cookie的方式進行標識。為了簡單起見，我們假設完全采用跟蹤cookie的方式對獨立訪客進行標識。

記錄鏈接編號及訪客標記

這一步可以通過javascript埋點及記錄accesslog完成，具體原理和實現方案可以參考我之前的一篇文章：網站統計中的數據收集原理及實現。

實時UV計算

可以看到，如果將每個鏈接被點擊的日志中訪客標識字段看成一個集合，那么此鏈接當前的UV也就是這個集合的基數，因此UV計算本質上就是一個基數計數問題。

在實時計算流中，我們可以認為任何一次鏈接點擊均觸發如下邏輯（偽代碼描述）：

cand_counting(item_no, user_id){

if(user_idisnotin the item_no visitorset){

add user_id to item_no visitor set;

cand[item_no]++;

}

}

邏輯非常簡單，每當有一個點擊事件發生，就去相應的鏈接被訪集合中尋找此訪客是否已經在里面，如果沒有則將此用戶標識加入集合，并將此鏈接的UV加1。

雖然邏輯非常簡單，但是在實際實現中尤其面臨大數據場景時還是會遇到諸多困難，下面一節我會介紹兩種目前被業界普遍使用的精確算法實現方案，并通過分析說明當數據量增大時它們面臨的問題。

傳統的基數計數實現

接著上面的例子，我們看一下目前常用的基數計數的實現方法。

基于B樹的基數計數

對上面的偽代碼做一個簡單分析，會發現關鍵操作有兩個：查找-迅速定位當前訪客是否已經在集合中，插入-將新的訪客標識插入到訪客集合中。因此，需要為每一個需要統計UV的點（此處就是十個寶貝鏈接）維護一個查找效率較高的數據結構，又因為實時數據流的關系，這個數據結構需要盡量在內存中維護，因此這個數據結構在空間復雜度上也要比較適中。綜合考慮一種傳統的做法是在實時計算引擎采用了B樹來組織這個集合。下圖是一個示意圖：

之所以選用B樹是因為B樹的查找和插入相關高效，同時空間復雜度也可以接受（關于B樹具體的性能分析請參考這里）。

這種實現方案為一個基數計數器維護一棵B樹，由于B樹在查找效率、插入效率和內存使用之間非常平衡，所以算是一種可以接受的解決方案。但是當數據量特別巨大時，例如要同時統計幾萬個鏈接的UV，如果要將幾萬個鏈接一天的訪問記錄全部維護在內存中，這個內存使用量也是相當可觀的（假設每個B樹占用1M內存，10萬個B樹就是100G！）。一種方案是在某個時間點將內存數據結構寫入磁盤（雙十一和雙十二大促時一淘數據部的效果平臺是每分鐘將數據寫入HBase）然后將內存中的計數器和數據結構清零，但是B樹并不能高效的進行合并，這就使得內存數據落地成了非常大的難題。

另一個需要數據結構合并的場景是查看并集的基數，例如在上面的例子中，如果我想查看Item1和Item2的總UV，是沒有辦法通過這種B樹的結構快速得到的。當然可以為每一種可能的組合維護一棵B樹。不過通過簡單的分析就可以知道這個方案基本不可行。N個元素集合的非空冪集數量為2N?12N?1，因此要為10個鏈接維護1023棵B樹，而隨著鏈接的增加這個數量會以冪指級別增長。

基于bitmap的基數計數

為了克服B樹不能高效合并的問題，一種替代方案是使用bitmap表示集合。也就是使用一個很長的bit數組表示集合，將bit位順序編號，bit為1表示此編號在集合中，為0表示不在集合中。例如“00100110”表示集合 {2，5，6}。bitmap中1的數量就是這個集合的基數。

顯然，與B樹不同bitmap可以高效的進行合并，只需進行按位或（or）運算就可以，而位運算在計算機中的運算效率是很高的。但是bitmap方式也有自己的問題，就是內存使用問題。

很容易發現，bitmap的長度與集合中元素個數無關，而是與基數的上限有關。例如在上面的例子中，假如要計算上限為1億的基數，則需要12.5M字節的bitmap，十個鏈接就需要125M。關鍵在于，這個內存使用與集合元素數量無關，即使一個鏈接僅僅有一個1UV，也要為其分配12.5M字節。

由此可見，雖然bitmap方式易于合并，卻由于內存使用問題而無法廣泛用于大數據場景。

小結

本文重點在于通過電商數據分析中UV計算的例子，說明基數的應用、傳統的基數計數算法及這些算法在大數據面前遇到的問題。實際上目前還沒有發現更好的在大數據場景中準確計算基數的高效算法，因此在不追求絕對準確的情況下，使用概率算法算是一個不錯的解決方案。在后續文章中，我將逐一解讀常用的基數估計概率算法。

請尊重原創，原文鏈接地址：http://blog.codinglabs.org/articles/algorithms-for-cardinality-estimation-part-i.html

總結

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

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