從頭到尾徹底解析Hash表演算法

轉自：http://blog.csdn.net/fly542/article/details/6696446

              十一、從頭到尾徹底解析Hash 表演算法

作者：July、wuliming、pkuoliver  
出處：http://blog.csdn.net/v_JULY_v。  
說明：本文分為三部分內容，
    第一部分為一道百度面試題Top K演算法的詳解；第二部分為關於Hash表演算法的詳細闡述；第三部分為打造一個最快的Hash表演算法。
------------------------------------

 

第一部分：Top K 演算法詳解
問題描述
百度面試題：
    搜尋引擎會通過日誌檔案把使用者每次檢索使用的所有檢索串都記錄下來，每個查詢串的長度為1-255位元組。
    假設目前有一千萬個記錄（這些查詢串的重複度比較高，雖然總數是1千萬，但如果除去重複後，不超過3百萬個。一個查詢串的重複度越高，說明查詢它的使用者越多，也就是越熱門。），請你統計最熱門的10個查詢串，要求使用的記憶體不能超過1G。

必備知識：
    什麼是雜湊表？
    雜湊表（Hash table，也叫雜湊表），是根據關鍵碼值(Key value)而直接進行訪問的資料結構。也就是說，它通過把關鍵碼值對映到表中一個位置來訪問記錄，以加快查詢的速度。這個對映函式叫做雜湊函式，存放記錄的陣列叫做雜湊表。

    雜湊表的做法其實很簡單，就是把Key通過一個固定的演算法函式既所謂的雜湊函式轉換成一個整型數字，然後就將該數字對陣列長度進行取餘，取餘結果就當作陣列的下標，將value儲存在以該數字為下標的陣列空間裡。
    而當使用雜湊表進行查詢的時候，就是再次使用雜湊函式將key轉換為對應的陣列下標，並定位到該空間獲取value，如此一來，就可以充分利用到陣列的定位效能進行資料定位（文章第二、三部分，會針對Hash表詳細闡述）。

問題解析：
    要統計最熱門查詢，首先就是要統計每個Query出現的次數，然後根據統計結果，找出Top 10。所以我們可以基於這個思路分兩步來設計該演算法。
    即，此問題的解決分為以下倆個步驟：

第一步：Query統計
    Query統計有以下倆個方法，可供選擇：
    1、直接排序法
    首先我們最先想到的的演算法就是排序了，首先對這個日誌裡面的所有Query都進行排序，然後再遍歷排好序的Query，統計每個Query出現的次數了。

    但是題目中有明確要求，那就是記憶體不能超過1G，一千萬條記錄，每條記錄是255Byte，很顯然要佔據2.375G記憶體，這個條件就不滿足要求了。

    讓我們回憶一下資料結構課程上的內容，當資料量比較大而且記憶體無法裝下的時候，我們可以採用外排序的方法來進行排序，這裡我們可以採用歸併排序，因為歸併排序有一個比較好的時間複雜度O(NlgN)。

    排完序之後我們再對已經有序的Query檔案進行遍歷，統計每個Query出現的次數，再次寫入檔案中。

    綜合分析一下，排序的時間複雜度是O(NlgN)，而遍歷的時間複雜度是O(N)，因此該演算法的總體時間複雜度就是O(N+NlgN)=O（NlgN）。

    2、Hash Table法
    在第1個方法中，我們採用了排序的辦法來統計每個Query出現的次數，時間複雜度是NlgN，那麼能不能有更好的方法來儲存，而時間複雜度更低呢？

    題目中說明了，雖然有一千萬個Query，但是由於重複度比較高，因此事實上只有300萬的Query，每個Query255Byte，因此我們可以考慮把他們都放進記憶體中去，而現在只是需要一個合適的資料結構，在這裡，Hash Table絕對是我們優先的選擇，因為Hash Table的查詢速度非常的快，幾乎是O(1)的時間複雜度。

    那麼，我們的演算法就有了：維護一個Key為Query字串，Value為該Query出現次數的HashTable，每次讀取一個Query，如果該字串不在Table中，那麼加入該字串，並且將Value值設為1；如果該字串在Table中，那麼將該字串的計數加一即可。最終我們在O(N)的時間複雜度內完成了對該海量資料的處理。

    本方法相比演算法1：在時間複雜度上提高了一個數量級，為O（N），但不僅僅是時間複雜度上的優化，該方法只需要IO資料檔案一次，而演算法1的IO次數較多的，因此該演算法2比演算法1在工程上有更好的可操作性。

第二步：找出Top 10
    演算法一：普通排序
    我想對於排序演算法大家都已經不陌生了，這裡不在贅述，我們要注意的是排序演算法的時間複雜度是NlgN，在本題目中，三百萬條記錄，用1G記憶體是可以存下的。

    演算法二：部分排序
    題目要求是求出Top 10，因此我們沒有必要對所有的Query都進行排序，我們只需要維護一個10個大小的陣列，初始化放入10個Query，按照每個Query的統計次數由大到小排序，然後遍歷這300萬條記錄，每讀一條記錄就和陣列最後一個Query對比，如果小於這個Query，那麼繼續遍歷，否則，將陣列中最後一條資料淘汰，加入當前的Query。最後當所有的資料都遍歷完畢之後，那麼這個陣列中的10個Query便是我們要找的Top10了。

    不難分析出，這樣，演算法的最壞時間複雜度是N*K， 其中K是指top多少。

    演算法三：堆
    在演算法二中，我們已經將時間複雜度由NlogN優化到NK，不得不說這是一個比較大的改進了，可是有沒有更好的辦法呢？

    分析一下，在演算法二中，每次比較完成之後，需要的操作複雜度都是K，因為要把元素插入到一個線性表之中，而且採用的是順序比較。這裡我們注意一下，該陣列是有序的，一次我們每次查詢的時候可以採用二分的方法查詢，這樣操作的複雜度就降到了logK，可是，隨之而來的問題就是資料移動，因為移動資料次數增多了。不過，這個演算法還是比演算法二有了改進。

    基於以上的分析，我們想想，有沒有一種既能快速查詢，又能快速移動元素的資料結構呢？回答是肯定的，那就是堆。
    藉助堆結構，我們可以在log量級的時間內查詢和調整/移動。因此到這裡，我們的演算法可以改進為這樣，維護一個K(該題目中是10)大小的小根堆，然後遍歷300萬的Query，分別和根元素進行對比。

    思想與上述演算法二一致，只是演算法在演算法三，我們採用了最小堆這種資料結構代替陣列，把查詢目標元素的時間複雜度有O（K）降到了O（logK）。
    那麼這樣，採用堆資料結構，演算法三，最終的時間複雜度就降到了N‘logK，和演算法二相比，又有了比較大的改進。

總結：
    至此，演算法就完全結束了，經過上述第一步、先用Hash表統計每個Query出現的次數，O（N）；然後第二步、採用堆資料結構找出Top 10，N*O（logK）。所以，我們最終的時間複雜度是：O（N） + N'*O（logK）。（N為1000萬，N’為300萬）。如果各位有什麼更好的演算法，歡迎留言評論。第一部分，完。

 

第二部分、Hash表 演算法的詳細解析

什麼是Hash
     Hash，一般翻譯做“雜湊”，也有直接音譯為“雜湊”的，就是把任意長度的輸入（又叫做預對映， pre-image），通過雜湊演算法，變換成固定長度的輸出，該輸出就是雜湊值。這種轉換是一種壓縮對映，也就是，雜湊值的空間通常遠小於輸入的空間，不同的輸入可能會雜湊成相同的輸出，而不可能從雜湊值來唯一的確定輸入值。簡單的說就是一種將任意長度的訊息壓縮到某一固定長度的訊息摘要的函式。

    HASH主要用於資訊保安領域中加密演算法，它把一些不同長度的資訊轉化成雜亂的128位的編碼,這些編碼值叫做HASH值. 也可以說，hash就是找到一種資料內容和資料存放地址之間的對映關係。

    陣列的特點是：定址容易，插入和刪除困難；而連結串列的特點是：定址困難，插入和刪除容易。那麼我們能不能綜合兩者的特性，做出一種定址容易，插入刪除也容易的資料結構？答案是肯定的，這就是我們要提起的雜湊表，雜湊表有多種不同的實現方法，我接下來解釋的是最常用的一種方法——拉鍊法，我們可以理解為“連結串列的陣列”，如圖：

    左邊很明顯是個陣列，陣列的每個成員包括一個指標，指向一個連結串列的頭，當然這個連結串列可能為空，也可能元素很多。我們根據元素的一些特徵把元素分配到不同的連結串列中去，也是根據這些特徵，找到正確的連結串列，再從連結串列中找出這個元素。

    元素特徵轉變為陣列下標的方法就是雜湊法。雜湊法當然不止一種，下面列出三種比較常用的：

1，除法雜湊法 
最直觀的一種，上圖使用的就是這種雜湊法，公式： 
      index = value % 16 
學過彙編的都知道，求模數其實是通過一個除法運算得到的，所以叫“除法雜湊法”。

2，平方雜湊法 
求index是非常頻繁的操作，而乘法的運算要比除法來得省時（對現在的CPU來說，估計我們感覺不出來），所以我們考慮把除法換成乘法和一個位移操作。公式： 
      index = (value * value) >> 28   （右移，除以2^28。記法：左移變大，是乘。右移變小，是除。）
如果數值分配比較均勻的話這種方法能得到不錯的結果，但我上面畫的那個圖的各個元素的值算出來的index都是0——非常失敗。也許你還有個問題，value如果很大，value * value不會溢位嗎？答案是會的，但我們這個乘法不關心溢位，因為我們根本不是為了獲取相乘結果，而是為了獲取index。

3，斐波那契（Fibonacci）雜湊法

平方雜湊法的缺點是顯而易見的，所以我們能不能找出一個理想的乘數，而不是拿value本身當作乘數呢？答案是肯定的。

1，對於16位整數而言，這個乘數是40503 
2，對於32位整數而言，這個乘數是2654435769 
3，對於64位整數而言，這個乘數是11400714819323198485

    這幾個“理想乘數”是如何得出來的呢？這跟一個法則有關，叫黃金分割法則，而描述黃金分割法則的最經典表示式無疑就是著名的斐波那契數列，即如此形式的序列：0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144,233, 377, 610， 987, 1597, 2584, 4181, 6765, 10946，…。另外，斐波那契數列的值和太陽系八大行星的軌道半徑的比例出奇吻合。

    對我們常見的32位整數而言，公式： 
            index = (value * 2654435769) >> 28

    如果用這種斐波那契雜湊法的話，那上面的圖就變成這樣了：

很明顯，用斐波那契雜湊法調整之後要比原來的取摸雜湊法好很多。 

適用範圍
    快速查詢，刪除的基本資料結構，通常需要總資料量可以放入記憶體。

基本原理及要點
    hash函式選擇，針對字串，整數，排列，具體相應的hash方法。 
碰撞處理，一種是open hashing，也稱為拉鍊法；另一種就是closed hashing，也稱開地址法，opened addressing。

擴充套件 
    d-left hashing中的d是多個的意思，我們先簡化這個問題，看一看2-left hashing。2-left hashing指的是將一個雜湊表分成長度相等的兩半，分別叫做T1和T2，給T1和T2分別配備一個雜湊函式，h1和h2。在儲存一個新的key時，同 時用兩個雜湊函式進行計算，得出兩個地址h1[key]和h2[key]。這時需要檢查T1中的h1[key]位置和T2中的h2[key]位置，哪一個 位置已經儲存的（有碰撞的）key比較多，然後將新key儲存在負載少的位置。如果兩邊一樣多，比如兩個位置都為空或者都儲存了一個key，就把新key 儲存在左邊的T1子表中，2-left也由此而來。在查詢一個key時，必須進行兩次hash，同時查詢兩個位置。

問題例項（海量資料處理） 
    我們知道hash 表在海量資料處理中有著廣泛的應用，下面，請看另一道百度面試題：
題目：海量日誌資料，提取出某日訪問百度次數最多的那個IP。
方案：IP的數目還是有限的，最多2^32個，所以可以考慮使用hash將ip直接存入記憶體，然後進行統計。

 

第三部分、最快的Hash表演算法

    接下來，我們們來具體分析一下一個最快的Hasb表演算法。
    我們由一個簡單的問題逐步入手：有一個龐大的字串陣列，然後給你一個單獨的字串，讓你從這個陣列中查詢是否有這個字串並找到它，你會怎麼做？有一個方法最簡單，老老實實從頭查到尾，一個一個比較，直到找到為止，我想只要學過程式設計的人都能把這樣一個程式作出來，但要是有程式設計師把這樣的程式交給使用者，我只能用無語來評價，或許它真的能工作，但...也只能如此了。

    最合適的演算法自然是使用HashTable（雜湊表），先介紹介紹其中的基本知識，所謂Hash，一般是一個整數，通過某種演算法，可以把一個字串"壓縮" 成一個整數。當然，無論如何，一個32位整數是無法對應回一個字串的，但在程式中，兩個字串計算出的Hash值相等的可能非常小，下面看看在MPQ中的Hash演算法：

函式一、以下的函式生成一個長度為0x500（合10進位制數：1280）的cryptTable[0x500]

void prepareCryptTable()
{ 
    unsigned long seed = 0x00100001, index1 = 0, index2 = 0, i;
 
    for( index1 = 0; index1 < 0x100; index1++ )
    { 
        for( index2 = index1, i = 0; i < 5; i++, index2 += 0x100 )
        { 
            unsigned long temp1, temp2;
 
            seed = (seed * 125 + 3) % 0x2AAAAB;
            temp1 = (seed & 0xFFFF) << 0x10;
 
            seed = (seed * 125 + 3) % 0x2AAAAB;
            temp2 = (seed & 0xFFFF);
 
            cryptTable[index2] = ( temp1 | temp2 ); 
       } 
   } 
} 

函式二、以下函式計算lpszFileName 字串的hash值，其中dwHashType 為hash的型別，在下面的函式三、GetHashTablePos函式中呼叫此函式二，其可以取的值為0、1、2；該函式返回lpszFileName 字串的hash值： 

unsigned long HashString( char *lpszFileName, unsigned long dwHashType )
{ 
    unsigned char *key  = (unsigned char *)lpszFileName;
unsigned long seed1 = 0x7FED7FED;
unsigned long seed2 = 0xEEEEEEEE;
    int ch;
 
    while( *key != 0 )
    { 
        ch = toupper(*key++);
 
        seed1 = cryptTable[(dwHashType << 8) + ch] ^ (seed1 + seed2);
        seed2 = ch + seed1 + seed2 + (seed2 << 5) + 3; 
    }
    return seed1; 
}

    Blizzard的這個演算法是非常高效的，被稱為"One-Way Hash"( A one-way hash is a an algorithm that is constructed in such a way that deriving the original string (set of strings, actually) is virtually impossible)。舉個例子，字串"unitneutralacritter.grp"通過這個演算法得到的結果是0xA26067F3。

　　是不是把第一個演算法改進一下，改成逐個比較字串的Hash值就可以了呢，答案是，遠遠不夠，要想得到最快的演算法，就不能進行逐個的比較，通常是構造一個雜湊表(Hash Table)來解決問題，雜湊表是一個大陣列，這個陣列的容量根據程式的要求來定義，例如1024，每一個Hash值通過取模運算 (mod) 對應到陣列中的一個位置，這樣，只要比較這個字串的雜湊值對應的位置有沒有被佔用，就可以得到最後的結果了，想想這是什麼速度？是的，是最快的O(1)，現在仔細看看這個演算法吧：

typedef struct
{
    int nHashA;
    int nHashB;
    char bExists;
   ......
} SOMESTRUCTRUE;
一種可能的結構體定義？

函式三、下述函式為在Hash表中查詢是否存在目標字串，有則返回要查詢字串的Hash值，無則，return -1.

int GetHashTablePos( har *lpszString, SOMESTRUCTURE *lpTable ) 
//lpszString要在Hash表中查詢的字串，lpTable為儲存字串Hash值的Hash表。
{ 
    int nHash = HashString(lpszString);  //呼叫上述函式二，返回要查詢字串lpszString的Hash值。
    int nHashPos = nHash % nTableSize;
 
    if ( lpTable[nHashPos].bExists  &&  !strcmp( lpTable[nHashPos].pString, lpszString ) ) 
    {  //如果找到的Hash值在表中存在，且要查詢的字串與表中對應位置的字串相同，
        return nHashPos;    //則返回上述呼叫函式二後，找到的Hash值
    } 
    else
    {
        return -1;  
    } 
}

 
    看到此，我想大家都在想一個很嚴重的問題：“如果兩個字串在雜湊表中對應的位置相同怎麼辦？”,畢竟一個陣列容量是有限的，這種可能性很大。解決該問題的方法很多，我首先想到的就是用“連結串列”,感謝大學裡學的資料結構教會了這個百試百靈的法寶，我遇到的很多演算法都可以轉化成連結串列來解決，只要在雜湊表的每個入口掛一個連結串列，儲存所有對應的字串就OK了。事情到此似乎有了完美的結局，如果是把問題獨自交給我解決，此時我可能就要開始定義資料結構然後寫程式碼了。

    然而Blizzard的程式設計師使用的方法則是更精妙的方法。基本原理就是：他們在雜湊表中不是用一個雜湊值而是用三個雜湊值來校驗字串。

 

    MPQ使用檔名雜湊表來跟蹤內部的所有檔案。但是這個表的格式與正常的雜湊表有一些不同。首先，它沒有使用雜湊作為下標，把實際的檔名儲存在表中用於驗證，實際上它根本就沒有儲存檔名。而是使用了3種不同的雜湊：一個用於雜湊表的下標，兩個用於驗證。這兩個驗證雜湊替代了實際檔名。
    當然了，這樣仍然會出現2個不同的檔名雜湊到3個同樣的雜湊。但是這種情況發生的概率平均是：1:18889465931478580854784，這個概率對於任何人來說應該都是足夠小的。現在再回到資料結構上，Blizzard使用的雜湊表沒有使用連結串列，而採用"順延"的方式來解決問題，看看這個演算法：

函式四、lpszString 為要在hash表中查詢的字串；lpTable 為儲存字串hash值的hash表；nTableSize 為hash表的長度： 

int GetHashTablePos( char *lpszString, MPQHASHTABLE *lpTable, int nTableSize )
{
    const int  HASH_OFFSET = 0, HASH_A = 1, HASH_B = 2;
 
    int  nHash = HashString( lpszString, HASH_OFFSET );
    int  nHashA = HashString( lpszString, HASH_A );
    int  nHashB = HashString( lpszString, HASH_B );
    int  nHashStart = nHash % nTableSize;
    int  nHashPos = nHashStart;
 
    while ( lpTable[nHashPos].bExists )
   {
     /*如果僅僅是判斷在該表中時候存在這個字串，就比較這兩個hash值就可以了，不用對
     *結構體中的字串進行比較。這樣會加快執行的速度？減少hash表佔用的空間？這種
      *方法一般應用在什麼場合？*/
        if ( 　 lpTable[nHashPos].nHashA == nHashA
        &&  lpTable[nHashPos].nHashB == nHashB )
       {
            return nHashPos;
       }
       else
       {
            nHashPos = (nHashPos + 1) % nTableSize;
       }
 
        if (nHashPos == nHashStart)
              break;
    }
     return -1;
}

上述程式解釋：

1.計算出字串的三個雜湊值（一個用來確定位置，另外兩個用來校驗)
2. 察看雜湊表中的這個位置
3. 雜湊表中這個位置為空嗎？如果為空，則肯定該字串不存在，返回-1。
4. 如果存在，則檢查其他兩個雜湊值是否也匹配，如果匹配，則表示找到了該字串，返回其Hash值。
5. 移到下一個位置，如果已經移到了表的末尾，則反繞到表的開始位置起繼續查詢　
6. 看看是不是又回到了原來的位置，如果是，則返回沒找到
7. 回到3

ok，這就是本文中所說的最快的Hash表演算法。什麼?不夠快?:D。歡迎，各位批評指正。

--------------------------------------------
補充1、一個簡單的hash函式：

/*key為一個字串，nTableLength為雜湊表的長度
*該函式得到的hash值分佈比較均勻*/
unsigned long getHashIndex( const char *key, int nTableLength )
{
    unsigned long nHash = 0;
   
    while (*key)
    {
        nHash = (nHash<<5) + nHash + *key++;
    }
        
    return ( nHash % nTableLength );
}

 

補充2、一個完整測試程式：  
    雜湊表的陣列是定長的，如果太大，則浪費，如果太小，體現不出效率。合適的陣列大小是雜湊表的效能的關鍵。雜湊表的尺寸最好是一個質數。當然，根據不同的資料量，會有不同的雜湊表的大小。對於資料量時多時少的應用，最好的設計是使用動態可變尺寸的雜湊表，那麼如果你發現雜湊表尺寸太小了，比如其中的元素是雜湊表尺寸的2倍時，我們就需要擴大雜湊表尺寸，一般是擴大一倍。

    下面是雜湊表尺寸大小的可能取值：

     17,            37,          79,        163,          331,  
    673,           1361,        2729,       5471,         10949,        
   21911,          43853,      87719,      175447,      350899,
  701819,         1403641,    2807303,     5614657,     11229331,   
 22458671,       44917381,    89834777,    179669557,   359339171,  
718678369,      1437356741,  2147483647

 

以下為該程式的完整原始碼，已在linux下測試通過：

致謝：
1、http://blog.redfox66.com/。
2、http://blog.csdn.net/wuliming_sc/。完。