如何處理海量數據

在實際的工作環境下，許多人會遇到海量數據這個複雜而艱鉅的問題，它的主要難點有以下幾個方面：

一、數據量過大，數據中什麼情況都可能存在。

如果說有10條數據，那麼大不了每條去逐一檢查，人爲處理，如果有上百條數據，也可以考慮，如果數據上到千萬級別，甚至過億，那不是手工能解決的了，必須通過工具或者程序進行處理，尤其海量的數據中，什麼情況都可能存在，例如，數據中某處格式出了問題，尤其在程序處理時，前面還能正常處理，突然到了某個地方問題出現了，程序終止了。

二、軟硬件要求高，系統資源佔用率高。

對海量的數據進行處理，除了好的方法，最重要的就是合理使用工具，合理分配系統資源。一般情況，如果處理的數據過TB級，小型機是要考慮的，普通的機子如果有好的方法可以考慮，不過也必須加大CPU和內存，就象面對着千軍萬馬，光有勇氣沒有一兵一卒是很難取勝的。

三、要求很高的處理方法和技巧。

這也是本文的寫作目的所在，好的處理方法是一位工程師長期工作經驗的積累，也是個人的經驗的總結。沒有通用的處理方法，但有通用的原理和規則。

下面我們來詳細介紹一下處理海量數據的經驗和技巧：

一、選用優秀的數據庫工具

現在的數據庫工具廠家比較多，對海量數據的處理對所使用的數據庫工具要求比較高，一般使用Oracle或者DB2，微軟公司最近發佈的SQL Server 2005性能也不錯。另外在BI領域：數據庫，數據倉庫，多維數據庫，數據挖掘等相關工具也要進行選擇，象好的ETL工具和好的OLAP工具都十分必要，例如Informatic，Eassbase等。筆者在實際數據分析項目中，對每天6000萬條的日誌數據進行處理，使用SQL Server 2000需要花費6小時，而使用SQL Server 2005則只需要花費3小時。

二、編寫優良的程序代碼

處理數據離不開優秀的程序代碼，尤其在進行復雜數據處理時，必須使用程序。好的程序代碼對數據的處理至關重要，這不僅僅是數據處理準確度的問題，更是數據處理效率的問題。良好的程序代碼應該包含好的算法，包含好的處理流程，包含好的效率，包含好的異常處理機制等。

三、對海量數據進行分區操作

對海量數據進行分區操作十分必要，例如針對按年份存取的數據，我們可以按年進行分區，不同的數據庫有不同的分區方式，不過處理機制大體相同。例如SQL Server的數據庫分區是將不同的數據存於不同的文件組下，而不同的文件組存於不同的磁盤分區下，這樣將數據分散開，減小磁盤I/O，減小了系統負荷，而且還可以將日誌，索引等放於不同的分區下。

四、建立廣泛的索引

對海量的數據處理，對大表建立索引是必行的，建立索引要考慮到具體情況，例如針對大表的分組、排序等字段，都要建立相應索引，一般還可以建立複合索引，對經常插入的表則建立索引時要小心，筆者在處理數據時，曾經在一個ETL流程中，當插入表時，首先刪除索引，然後插入完畢，建立索引，並實施聚合操作，聚合完成後，再次插入前還是刪除索引，所以索引要用到好的時機，索引的填充因子和聚集、非聚集索引都要考慮。

五、建立緩存機制

當數據量增加時，一般的處理工具都要考慮到緩存問題。緩存大小設置的好差也關係到數據處理的成敗，例如，筆者在處理2億條數據聚合操作時，緩存設置爲100000條/Buffer，這對於這個級別的數據量是可行的。

六、加大虛擬內存

如果系統資源有限，內存提示不足，則可以靠增加虛擬內存來解決。筆者在實際項目中曾經遇到針對18億條的數據進行處理，內存爲1GB，1個P42.4G的CPU，對這麼大的數據量進行聚合操作是有問題的，提示內存不足，那麼採用了加大虛擬內存的方法來解決，在6塊磁盤分區上分別建立了6個4096M的磁盤分區，用於虛擬內存，這樣虛擬的內存則增加爲 4096*6 + 1024 =25600 M，解決了數據處理中的內存不足問題。

七、分批處理

海量數據處理難因爲數據量大，那麼解決海量數據處理難的問題其中一個技巧是減少數據量。可以對海量數據分批處理，然後處理後的數據再進行合併操作，這樣逐個擊破，有利於小數據量的處理，不至於面對大數據量帶來的問題，不過這種方法也要因時因勢進行，如果不允許拆分數據，還需要另想辦法。不過一般的數據按天、按月、按年等存儲的，都可以採用先分後合的方法，對數據進行分開處理。

八、使用臨時表和中間表

數據量增加時，處理中要考慮提前彙總。這樣做的目的是化整爲零，大表變小表，分塊處理完成後，再利用一定的規則進行合併，處理過程中的臨時表的使用和中間結果的保存都非常重要，如果對於超海量的數據，大表處理不了，只能拆分爲多個小表。如果處理過程中需要多步彙總操作，可按彙總步驟一步步來，不要一條語句完成，一口氣吃掉一個胖子。

九、優化查詢SQL語句

在對海量數據進行查詢處理過程中，查詢的SQL語句的性能對查詢效率的影響是非常大的，編寫高效優良的SQL腳本和存儲過程是數據庫工作人員的職責，也是檢驗數據庫工作人員水平的一個標準，在對SQL語句的編寫過程中，例如減少關聯，少用或不用遊標，設計好高效的數據庫表結構等都十分必要。筆者在工作中試着對1億行的數據使用遊標，運行3個小時沒有出結果，這是一定要改用程序處理了。

十、使用文本格式進行處理

對一般的數據處理可以使用數據庫，如果對複雜的數據處理，必須藉助程序，那麼在程序操作數據庫和程序操作文本之間選擇，是一定要選擇程序操作文本的，原因爲：程序操作文本速度快；對文本進行處理不容易出錯；文本的存儲不受限制等。例如一般的海量的網絡日誌都是文本格式或者csv格式（文本格式），對它進行處理牽扯到數據清洗，是要利用程序進行處理的，而不建議導入數據庫再做清洗。

十一、定製強大的清洗規則和出錯處理機制

海量數據中存在着不一致性，極有可能出現某處的瑕疵。例如，同樣的數據中的時間字段，有的可能爲非標準的時間，出現的原因可能爲應用程序的錯誤，系統的錯誤等，這是在進行數據處理時，必須制定強大的數據清洗規則和出錯處理機制。

十二、建立視圖或者物化視圖

視圖中的數據來源於基表，對海量數據的處理，可以將數據按一定的規則分散到各個基表中，查詢或處理過程中可以基於視圖進行，這樣分散了磁盤I/O，正如10根繩子吊着一根柱子和一根吊着一根柱子的區別。

十三、避免使用32位機子（極端情況）

目前的計算機很多都是32位的，那麼編寫的程序對內存的需要便受限制，而很多的海量數據處理是必須大量消耗內存的，這便要求更好性能的機子，其中對位數的限制也十分重要。

十四、考慮操作系統問題

海量數據處理過程中，除了對數據庫，處理程序等要求比較高以外，對操作系統的要求也放到了重要的位置，一般是必須使用服務器的，而且對系統的安全性和穩定性等要求也比較高。尤其對操作系統自身的緩存機制，臨時空間的處理等問題都需要綜合考慮。

十五、使用數據倉庫和多維數據庫存儲

數據量加大是一定要考慮OLAP的，傳統的報表可能5、6個小時出來結果，而基於Cube的查詢可能只需要幾分鐘，因此處理海量數據的利器是OLAP多維分析，即建立數據倉庫，建立多維數據集，基於多維數據集進行報表展現和數據挖掘等。

十六、使用採樣數據，進行數據挖掘

基於海量數據的數據挖掘正在逐步興起，面對着超海量的數據，一般的挖掘軟件或算法往往採用數據抽樣的方式進行處理，這樣的誤差不會很高，大大提高了處理效率和處理的成功率。一般採樣時要注意數據的完整性和，防止過大的偏差。筆者曾經對1億2千萬行的表數據進行採樣，抽取出400萬行，經測試軟件測試處理的誤差爲千分之五，客戶可以接受。

還有一些方法，需要在不同的情況和場合下運用，例如使用代理鍵等操作，這樣的好處是加快了聚合時間，因爲對數值型的聚合比對字符型的聚合快得多。類似的情況需要針對不同的需求進行處理。

海量數據是發展趨勢，對數據分析和挖掘也越來越重要，從海量數據中提取有用信息重要而緊迫，這便要求處理要準確，精度要高，而且處理時間要短，得到有價值信息要快，所以，對海量數據的研究很有前途，也很值得進行廣泛深入的研究。

海量數據處理專題（一）——開篇

　　大數據量的問題是很多面試筆試中經常出現的問題，比如baidu google 騰訊 這樣的一些涉及到海量數據的公司經常會問到。

　　下面的方法是我對海量數據的處理方法進行了一個一般性的總結，當然這些方法可能並不能完全覆蓋所有的問題，但是這樣的一些方法也基本可以處理絕大多數遇到的問題。下面的一些問題基本直接來源於公司的面試筆試題目，方法不一定最優，如果你有更好的處理方法，歡迎與我討論。

　　本貼從解決這類問題的方法入手，開闢一系列專題來解決海量數據問題。擬包含 以下幾個方面。

1. Bloom Filter
2. Hash
3. Bit-Map
4. 堆(Heap)
5. 雙層桶劃分
6. 數據庫索引
7. 倒排索引（Inverted Index）
8. 外排序
9. Trie樹
10. MapReduce

　　在這些解決方案之上，再借助一定的例子來剖析海量數據處理問題的解決方案。

海量數據處理專題（二）——Bloom Filter

【什麼是Bloom Filter】 
Bloom Filter是一種空間效率很高的隨機數據結構，它利用位數組很簡潔地表示一個集合，並能判斷一個元素是否屬於這個集合。Bloom Filter的這種高效是有一定代價的：在判斷一個元素是否屬於某個集合時，有可能會把不屬於這個集合的元素誤認爲屬於這個集合（false positive）。因此，Bloom Filter不適合那些“零錯誤”的應用場合。而在能容忍低錯誤率的應用場合下，Bloom Filter通過極少的錯誤換取了存儲空間的極大節省。 這裏有一篇關於Bloom Filter的詳細介紹，不太懂的博友可以看看。 
【適用範圍】 
可以用來實現數據字典，進行數據的判重，或者集合求交集 
【基本原理及要點】 
對於原理來說很簡單，位數組+k個獨立hash函數。將hash函數對應的值的位數組置1，查找時如果發現所有hash函數對應位都是1說明存在，很明顯這 個過程並不保證查找的結果是100%正確的。同時也不支持刪除一個已經插入的關鍵字，因爲該關鍵字對應的位會牽動到其他的關鍵字。所以一個簡單的改進就是 counting Bloom filter，用一個counter數組代替位數組，就可以支持刪除了。 

還有一個比較重要的問題，如 何根據輸入元素個數n，確定位數組m的大小及hash函數個數。當hash函數個數k=(ln2)*(m/n)時錯誤率最小。在錯誤率不大於E的情況 下，m至少要等於n*lg(1/E)才能表示任意n個元素的集合。但m還應該更大些，因爲還要保證bit數組裏至少一半爲0，則m應 該>=nlg(1/E)*lge 大概就是nlg(1/E)1.44倍(lg表示以2爲底的對數)。 

舉個例子我們假設錯誤率爲0.01，則此時m應大概是n的13倍。這樣k大概是8個。 

注意這裏m與n的單位不同，m是bit爲單位，而n則是以元素個數爲單位(準確的說是不同元素的個數)。通常單個元素的長度都是有很多bit的。所以使用bloom filter內存上通常都是節省的。 

【擴展】 
Bloom filter將集合中的元素映射到位數組中，用k（k爲哈希函數個數）個映射位是否全1表示元素在不在這個集合中。Counting bloom filter（CBF）將位數組中的每一位擴展爲一個counter，從而支持了元素的刪除操作。Spectral Bloom Filter（SBF）將其與集合元素的出現次數關聯。SBF採用counter中的最小值來近似表示元素的出現頻率。 

【問題實例】 
給你A,B兩個文件，各存放50億條URL，每條URL佔用64字節，內存限制是4G，讓你找出A,B文件共同的URL。如果是三個乃至n個文件呢？ 

根據這個問題我們來計算下內存的佔用，4G=2^32大概是40億*8大概是340億bit，n=50億，如果按出錯率0.01算需要的大概是650億個bit。 現在可用的是340億，相差並不多，這樣可能會使出錯率上升些。另外如果這些urlip是一一對應的，就可以轉換成ip，則大大簡單了。

 

海量數據處理專題（三）——Hash

【什麼是Hash】 
  Hash，一般翻譯做“散列”，也有直接音譯爲“哈希”的，就是把任意長度的輸入（又叫做預映射， pre-image），通過散列算法，變換成固定長度的輸出，該輸出就是散列值。這種轉換是一種壓縮映射，也就是，散列值的空間通常遠小於輸入的空間，不同的輸入可能會散列成相同的輸出，而不可能從散列值來唯一的確定輸入值。簡單的說就是一種將任意長度的消息壓縮到某一固定長度的消息摘要的函數。 
HASH主要用於信息安全領域中加密算法，它把一些不同長度的信息轉化成雜亂的128位的編碼,這些編碼值叫做HASH值. 也可以說，hash就是找到一種數據內容和數據存放地址之間的映射關係。 
  數組的特點是：尋址容易，插入和刪除困難；而鏈表的特點是：尋址困難，插入和刪除容易。那麼我們能不能綜合兩者的特性，做出一種尋址容易，插入刪除也容易的數據結構？答案是肯定的，這就是我們要提起的哈希表，哈希表有多種不同的實現方法，我接下來解釋的是最常用的一種方法——拉鍊法，我們可以理解爲“鏈表的數組”，如圖： 

 
左邊很明顯是個數組，數組的每個成員包括一個指針，指向一個鏈表的頭，當然這個鏈表可能爲空，也可能元素很多。我們根據元素的一些特徵把元素分配到不同的鏈表中去，也是根據這些特徵，找到正確的鏈表，再從鏈表中找出這個元素。 
元素特徵轉變爲數組下標的方法就是散列法。散列法當然不止一種，下面列出三種比較常用的。 
1，除法散列法 
最直觀的一種，上圖使用的就是這種散列法，公式： 
index = value % 16 
學過彙編的都知道，求模數其實是通過一個除法運算得到的，所以叫“除法散列法”。 
2，平方散列法 
求index是非常頻繁的操作，而乘法的運算要比除法來得省時（對現在的CPU來說，估計我們感覺不出來），所以我們考慮把除法換成乘法和一個位移操作。公式： 
index = (value * value) >> 28 
如果數值分配比較均勻的話這種方法能得到不錯的結果，但我上面畫的那個圖的各個元素的值算出來的index都是0——非常失敗。也許你還有個問題，value如果很大，value * value不會溢出嗎？答案是會的，但我們這個乘法不關心溢出，因爲我們根本不是爲了獲取相乘結果，而是爲了獲取index。 
3，斐波那契（Fibonacci）散列法 
平方散列法的缺點是顯而易見的，所以我們能不能找出一個理想的乘數，而不是拿value本身當作乘數呢？答案是肯定的。 
1，對於16位整數而言，這個乘數是40503 
2，對於32位整數而言，這個乘數是2654435769 
3，對於64位整數而言，這個乘數是11400714819323198485 
這幾個“理想乘數”是如何得出來的呢？這跟一個法則有關，叫黃金分割法則，而描述黃金分割法則的最經典表達式無疑就是著名的斐波那契數列，如果你還有興趣，就到網上查找一下“斐波那契數列”等關鍵字，我數學水平有限，不知道怎麼描述清楚爲什麼，另外斐波那契數列的值居然和太陽系八大行星的軌道半徑的比例出奇吻合，很神奇，對麼？
對我們常見的32位整數而言，公式： 
i ndex = (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，同時查找兩個位置。 
【問題實例】 
1).海量日誌數據，提取出某日訪問百度次數最多的那個IP。 
IP的數目還是有限的，最多2^32個，所以可以考慮使用hash將ip直接存入內存，然後進行統計。

 

海量數據處理專題（四）——Bit-map

【什麼是Bit-map】 
所謂的Bit-map就是用一個bit位來標記某個元素對應的Value， 而Key即是該元素。由於採用了Bit爲單位來存儲數據，因此在存儲空間方面，可以大大節省。 
如果說了這麼多還沒明白什麼是Bit-map，那麼我們來看一個具體的例子，假設我們要對0-7內的5個元素(4,7,2,5,3)排序（這裏假設這些元素沒有重複）。那麼我們就可以採用Bit-map的方法來達到排序的目的。要表示8個數，我們就只需要8個Bit（1Bytes），首先我們開闢1Byte的空間，將這些空間的所有Bit位都置爲0(如下圖：) 

 
然後遍歷這5個元素，首先第一個元素是4，那麼就把4對應的位置爲1（可以這樣操作 p+(i/8)|(0x01<<(i%8)) 當然了這裏的操作涉及到Big-ending和Little-ending的情況，這裏默認爲Big-ending）,因爲是從零開始的，所以要把第五位置爲一（如下圖）： 

 

然後再處理第二個元素7，將第八位置爲1,，接着再處理第三個元素，一直到最後處理完所有的元素，將相應的位置爲1，這時候的內存的Bit位的狀態如下： 

 

然後我們現在遍歷一遍Bit區域，將該位是一的位的編號輸出（2，3，4，5，7），這樣就達到了排序的目的。下面的代碼給出了一個BitMap的用法：排序。 

C代碼  

    //定義每個Byte中有8個Bit位  
    #include ＜memory.h＞  
    #define BYTESIZE 8  
    void SetBit(char *p, int posi)  
    {  
        for(int i=0; i ＜ (posi/BYTESIZE); i++)  
        {  
            p++;  
        }  
       
        *p = *p|(0x01＜＜(posi%BYTESIZE));//將該Bit位賦值1  
        return;  
    }  
       
    void BitMapSortDemo()  
    {  
        //爲了簡單起見，我們不考慮負數  
        int num[] = {3,5,2,10,6,12,8,14,9};  
       
        //BufferLen這個值是根據待排序的數據中最大值確定的  
//待排序中的最大值是14，因此只需要2個Bytes(16個Bit)  
//就可以了。  
        const int BufferLen = 2;  
        char *pBuffer = new char[BufferLen];  
       
        //要將所有的Bit位置爲0，否則結果不可預知。  
        memset(pBuffer,0,BufferLen);  
        for(int i=0;i＜9;i++)  
        {  
            //首先將相應Bit位上置爲1  
            SetBit(pBuffer,num[i]);  
        }  
       
        //輸出排序結果  
        for(int i=0;i＜BufferLen;i++)//每次處理一個字節(Byte)  
        {  
            for(int j=0;j＜BYTESIZE;j++)//處理該字節中的每個Bit位  
            {  
                //判斷該位上是否是1，進行輸出，這裏的判斷比較笨。  
//首先得到該第j位的掩碼（0x01＜＜j），將內存區中的  
//位和此掩碼作與操作。最後判斷掩碼是否和處理後的  
//結果相同  
                if((*pBuffer&(0x01＜＜j)) == (0x01＜＜j))  
                {  
                    printf("%d ",i*BYTESIZE + j);  
                }  
            }  
            pBuffer++;  
        }  
    }  
       
    int _tmain(int argc, _TCHAR* argv[])  
    {  
        BitMapSortDemo();  
        return 0;  
    }  

【適用範圍】 

可進行數據的快速查找，判重，刪除，一般來說數據範圍是int的10倍以下 

【基本原理及要點】 

使用bit數組來表示某些元素是否存在，比如8位電話號碼 

【擴展】 

Bloom filter可以看做是對bit-map的擴展 

【問題實例】 

1)已知某個文件內包含一些電話號碼，每個號碼爲8位數字，統計不同號碼的個數。 

8位最多99 999 999，大概需要99m個bit，大概10幾m字節的內存即可。 （可以理解爲從0-99 999 999的數字，每個數字對應一個Bit位，所以只需要99M個Bit==1.2MBytes，這樣，就用了小小的1.2M左右的內存表示了所有的8位數的電話） 

2)2.5億個整數中找出不重複的整數的個數，內存空間不足以容納這2.5億個整數。 

將bit-map擴展一下，用2bit表示一個數即可，0表示未出現，1表示出現一次，2表示出現2次及以上，在遍歷這些數的時候，如果對應位置的值是0，則將其置爲1；如果是1，將其置爲2；如果是2，則保持不變。或者我們不用2bit來進行表示，我們用兩個bit-map即可模擬實現這個2bit-map，都是一樣的道理。 

 

海量數據處理專題（五）——堆

【什麼是堆】
概念：堆是一種特殊的二叉樹，具備以下兩種性質
1）每個節點的值都大於（或者都小於，稱爲最小堆）其子節點的值
2）樹是完全平衡的，並且最後一層的樹葉都在最左邊
這樣就定義了一個最大堆。如下圖用一個數組來表示堆：

 

那麼下面介紹二叉堆：二叉堆是一種完全二叉樹，其任意子樹的左右節點（如果有的話）的鍵值一定比根節點大，上圖其實就是一個二叉堆。

你一定發覺了，最小的一個元素就是數組第一個元素，那麼二叉堆這種有序隊列如何入隊呢？看圖：

 

假設要在這個二叉堆裏入隊一個單元，鍵值爲2，那隻需在數組末尾加入這個元素，然後儘可能把這個元素往上挪，直到挪不動，經過了這種複雜度爲Ο(logn)的操作，二叉堆還是二叉堆。

那如何出隊呢？也不難，看圖：

出隊一定是出數組的第一個元素，這麼來第一個元素以前的位置就成了空位，我們需要把這個空位挪至葉子節點，然後把數組最後一個元素插入這個空位，把這個“空位”儘量往上挪。這種操作的複雜度也是Ο(logn)。

【適用範圍】
海量數據前n大，並且n比較小，堆可以放入內存

【基本原理及要點】
最大堆求前n小，最小堆求前n大。方法，比如求前n小，我們比較當前元素與最大堆裏的最大元素，如果它小於最大元素，則應該替換那個最大元 素。這樣最後得到的n個元素就是最小的n個。適合大數據量，求前n小，n的大小比較小的情況，這樣可以掃描一遍即可得到所有的前n元素，效率很高。

【擴展】
雙堆，一個最大堆與一個最小堆結合，可以用來維護中位數。

【問題實例】
1)100w個數中找最大的前100個數。
用一個100個元素大小的最小堆即可。

 

海量數據處理專題（六）

【什麼是雙層桶】  
事實上，與其說雙層桶劃分是一種數據結構，不如說它是一種算法設計思想。面對一堆大量的數據我們無法處理的時候，我們可以將其分成一個個小的單元，然後根據一定的策略來處理這些小單元，從而達到目的。

【適用範圍】 
第k大，中位數，不重複或重複的數字

【基本原理及要點】 
因爲元素範圍很大，不能利用直接尋址表，所以通過多次劃分，逐步確定範圍，然後最後在一個可以接受的範圍內進行。可以通過多次縮小，雙層只是一個例子，分治纔是其根本（只是“只分不治”）。

【擴展】 
當有時候需要用一個小範圍的數據來構造一個大數據，也是可以利用這種思想，相比之下不同的，只是其中的逆過程。

【問題實例】 
1).2.5億個整數中找出不重複的整數的個數，內存空間不足以容納這2.5億個整數。

有 點像鴿巢原理，整數個數爲2^32,也就是，我們可以將這2^32個數，劃分爲2^8個區域(比如用單個文件代表一個區域)，然後將數據分離到不同的區 域，然後不同的區域在利用bitmap就可以直接解決了。也就是說只要有足夠的磁盤空間，就可以很方便的解決。 當然這個題也可以用我們前面講過的BitMap方法解決，正所謂條條大道通羅馬~~~

2).5億個int找它們的中位數。

這個例子比上面那個更明顯。首先我們將int劃分爲2^16個區域，然後讀取數據統計落到各個區域裏的數的個數，之後我們根據統計結果就可以判斷中位數落到那個區域，同時知道這個區域中的第幾大數剛好是中位數。然後第二次掃描我們只統計落在這個區域中的那些數就可以了。

實 際上，如果不是int是int64，我們可以經過3次這樣的劃分即可降低到可以接受的程度。即可以先將int64分成2^24個區域，然後確定區域的第幾 大數，在將該區域分成2^20個子區域，然後確定是子區域的第幾大數，然後子區域裏的數的個數只有2^20，就可以直接利用direct addr table進行統計了。

3).現在有一個0-30000的隨機數生成器。請根據這個隨機數生成器，設計一個抽獎範圍是0-350000彩票中獎號碼列表，其中要包含20000箇中獎號碼。

這個題剛好和上面兩個思想相反，一個0到3萬的隨機數生成器要生成一個0到35萬的隨機數。那麼我們完全可以將0-35萬的區間分成35/3=12個區 間，然後每個區間的長度都小於等於3萬，這樣我們就可以用題目給的隨機數生成器來生成了，然後再加上該區間的基數。那麼要每個區間生成多少個隨機數呢？計 算公式就是：區間長度*隨機數密度，在本題目中就是30000*（20000/350000）。最後要注意一點，該題目是有隱含條件的：彩票，這意味着你 生成的隨機數裏面不能有重複，這也是我爲什麼用雙層桶劃分思想的另外一個原因。

海量數據處理專題（七）——數據庫索引及優化

索引是對數據庫表中一列或多列的值進行排序的一種結構，使用索引可快速訪問數據庫表中的特定信息。

數據庫索引

什麼是索引

　　數據庫索引好比是一本書前面的目錄，能加快數據庫的查詢速度。
　　例如這樣一個查詢：select * from table1 where id=44。如果沒有索引，必須遍歷整個表，直到ID等於44的這一行被找到爲止；有了索引之後(必須是在ID這一列上建立的索引)，直接在索引裏面找44（也就是在ID這一列找），就可以得知這一行的位置，也就是找到了這一行。可見，索引是用來定位的。
　　索引分爲聚簇索引和非聚簇索引兩種，聚簇索引 是按照數據存放的物理位置爲順序的，而非聚簇索引就不一樣了；聚簇索引能提高多行檢索的速度，而非聚簇索引對於單行的檢索很快。

概述

　　建立索引的目的是加快對錶中記錄的查找或排序。
　　爲表設置索引要付出代價的：一是增加了數據庫的存儲空間，二是在插入和修改數據時要花費較多的時間(因爲索引也要隨之變動)。

 

 

B樹索引-Sql Server索引方式

爲什麼要創建索引

　　創建索引可以大大提高系統的性能。
　　　　第一，通過創建唯一性索引，可以保證數據庫表中每一行數據的唯一性。
　　　　第二，可以大大加快數據的檢索速度，這也是創建索引的最主要的原因。
　　　　第三，可以加速表和表之間的連接，特別是在實現數據的參考完整性方面特別有意義。
　　　　第四，在使用分組和排序子句進行數據檢索時，同樣可以顯著減少查詢中分組和排序的時間。
　　　　第五，通過使用索引，可以在查詢的過程中，使用優化隱藏器，提高系統的性能。
　　也許會有人要問：增加索引有如此多的優點，爲什麼不對錶中的每一個列創建一個索引呢？因爲，增加索引也有許多不利的方面。
　　　　第一，創建索引和維護索引要耗費時間，這種時間隨着數據量的增加而增加。
　　　　第二，索引需要佔物理空間，除了數據表佔數據空間之外，每一個索引還要佔一定的物理空間，如果要建立聚簇索引，那麼需要的空間就會更大。
　　　　第三，當對錶中的數據進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了數據的維護速度。

在哪建索引

　　索引是建立在數據庫表中的某些列的上面。在創建索引的時候，應該考慮在哪些列上可以創建索引，在哪些列上不能創建索引。一般來說，應該在這些列上創建索引：
　　在經常需要搜索的列上，可以加快搜索的速度；
　　在作爲主鍵的列上，強制該列的唯一性和組織表中數據的排列結構；
　　在經常用在連接的列上，這些列主要是一些外鍵，可以加快連接的速度；在經常需要根據範圍進行搜索的列上創建索引，因爲索引已經排序，其指定的範圍是連續的；
　　在經常需要排序的列上創建索引，因爲索引已經排序，這樣查詢可以利用索引的排序，加快排序查詢時間；
　　在經常使用在WHERE子句中的列上面創建索引，加快條件的判斷速度。
　　同樣，對於有些列不應該創建索引。一般來說，不應該創建索引的的這些列具有下列特點：
　　第一，對於那些在查詢中很少使用或者參考的列不應該創建索引。這是因爲，既然這些列很少使用到，因此有索引或者無索引，並不能提高查詢速度。相反，由於增加了索引，反而降低了系統的維護速度和增大了空間需求。
　　第二，對於那些只有很少數據值的列也不應該增加索引。這是因爲，由於這些列的取值很少，例如人事表的性別列，在查詢的結果中，結果集的數據行佔了表中數據行的很大比例，即需要在表中搜索的數據行的比例很大。增加索引，並不能明顯加快檢索速度。
　　第三，對於那些定義爲text, image和bit數據類型的列不應該增加索引。這是因爲，這些列的數據量要麼相當大，要麼取值很少,不利於使用索引。
　　第四，當修改性能遠遠大於檢索性能時，不應該創建索引。這是因爲，修改性能和檢索性能是互相矛盾的。當增加索引時，會提高檢索性能，但是會降低修改性能。當減少索引時，會提高修改性能，降低檢索性能。因此，當修改操作遠遠多於檢索操作時，不應該創建索引。

數據庫優化

　　此外，除了數據庫索引之外，在LAMP結果如此流行的今天，數據庫（尤其是MySQL）性能優化也是海量數據處理的一個熱點。下面就結合自己的經驗，聊一聊MySQL數據庫優化的幾個方面。
　　首先，在數據庫設計的時候，要能夠充分的利用索引帶來的性能提升，至於如何建立索引，建立什麼樣的索引，在哪些字段上建立索引，上面已經講的很清楚了，這裏不在贅述。另外就是設計數據庫的原則就是儘可能少的進行數據庫寫操作（插入，更新，刪除等），查詢越簡單越好。如下：

 

數據庫設計

　　其次，配置緩存是必不可少的，配置緩存可以有效的降低數據庫查詢讀取次數，從而緩解數據庫服務器壓力，達到優化的目的，一定程度上來講，這算是一個“圍魏救趙”的辦法。可配置的緩存包括索引緩存(key_buffer)，排序緩存(sort_buffer)，查詢緩存(query_buffer)，表描述符緩存(table_cache)，如下圖：

 

配置緩存

　　第三，切表，切表也是一種比較流行的數據庫優化法。分表包括兩種方式：橫向分表和縱向分表，其中，橫向分表比較有使用意義，故名思議，橫向切表就是指把記錄分到不同的表中，而每條記錄仍舊是完整的（縱向切表後每條記錄是不完整的），例如原始表中有100條記錄，我要切成2個表，那麼最簡單也是最常用的方法就是ID取摸切表法，本例中，就把ID爲1,3,5,7。。。的記錄存在一個表中，ID爲2,4,6,8,。。。的記錄存在另一張表中。雖然橫向切表可以減少查詢強度，但是它也破壞了原始表的完整性，如果該表的統計操作比較多，那麼就不適合橫向切表。橫向切表有個非常典型的用法，就是用戶數據：每個用戶的用戶數據一般都比較龐大，但是每個用戶數據之間的關係不大，因此這裏很適合橫向切表。最後，要記住一句話就是：分表會造成查詢的負擔，因此在數據庫設計之初，要想好是否真的適合切表的優化：

 

分表

第四，日誌分析，在數據庫運行了較長一段時間以後，會積累大量的LOG日誌，其實這裏面的蘊涵的有用的信息量還是很大的。通過分析日誌，可以找到系統性能的瓶頸，從而進一步尋找優化方案。

 

性能分析

以上講的都是單機MySQL的性能優化的一些經驗，但是隨着信息大爆炸，單機的數據庫服務器已經不能滿足我們的需求，於是，多多節點，分佈式數據庫網絡出現了，其一般的結構如下：

 

分佈式數據庫結構

這種分佈式集羣的技術關鍵就是“同步複製”。。。

 

 

海量數據處理專題（八）——倒排索引(搜索引擎之基石)

引言：

在信息大爆炸的今天，有了搜索引擎的幫助，使得我們能夠快速，便捷的找到所求。提到搜索引擎，就不得不說VSM模型，說到VSM，就不得不聊倒排索引。可以毫不誇張的講，倒排索引是搜索引擎的基石。

VSM檢索模型

VSM全稱是Vector Space Model(向量空間模型)，是IR(Information Retrieval信息檢索)模型中的一種，由於其簡單，直觀，高效，所以被廣泛的應用到搜索引擎的架構中。98年的Google就是憑藉這樣的一個模型，開始了它的瘋狂擴張之路。廢話不多說，讓我們來看看到底VSM是一個什麼東東。

在開始之前，我默認大家對線性代數裏面的向量(Vector)有一定了解的。向量是既有大小又有方向的量，通常用有向線段表示，向量有：加、減、倍數、內積、距離、模、夾角的運算。

文檔(Document)：一個完整的信息單元，對應的搜索引擎系統裏，就是指一個個的網頁。

標引項(Term)：文檔的基本構成單位，例如在英文中可以看做是一個單詞，在中文中可以看作一個詞語。

查詢(Query)：一個用戶的輸入，一般由多個Term構成。

那麼用一句話概況搜索引擎所做的事情就是：對於用戶輸入的Query，找到最相似的Document返回給用戶。而這正是IR模型所解決的問題：

信息檢索模型是指如何對查詢和文檔進行表示，然後對它們進行相似度計算的框架和方法。

舉個簡單的例子：

現在有兩篇文章(Document)分別是 “春風來了，春天的腳步近了” 和 “春風不度玉門關”。然後輸入的Query是“春風”，從直觀上感覺，前者和輸入的查詢更相關一些，因爲它包含有2個春，但這只是我們的直觀感覺，如何量化呢，要知道計算機是門嚴謹的學科^_^。這個時候，我們前面講的Term和VSM模型就派上用場了。

首先我們要確定向量的維數，這時候就需要一個字典庫，字典庫的大小，即是向量的維數。在該例中，字典爲{春風,來了,春天, 的,腳步,近了,不度,玉門關} ，文檔向量，查詢向量如下圖：

 

VSM模型示例

PS:爲了簡單起見，這裏分詞的粒度很大。

將Query和Document都量化爲向量以後，那麼就可以計算用戶的查詢和哪個文檔相似性更大了。簡單的計算結果是D1和D2同Query的內積都是1，囧。當然了，如果分詞粒度再細一些，查詢的結果就是另外一個樣子了，因此分詞的粒度也是會對查詢結果（主要是召回率和準確率）造成影響的。

上述的例子是用一個很簡單的例子來說明VSM模型的，計算文檔相似度的時候也是採用最原始的內積的方法，並且只考慮了詞頻(TF)影響因子，而沒有考慮反詞頻(IDF)，而現在比較常用的是cos夾角法，影響因子也非常多，據傳Google的影響因子有100+之多。
大名鼎鼎的Lucene項目就是採用VSM模型構建的，VSM的核心公式如下（由cos夾角法演變，此處省去推導過程）

 

VSM模型公式

從上面的例子不難看出，如果向量的維度(對漢語來將，這個值一般在30w-45w)變大，而且文檔數量(通常都是海量的)變多，那麼計算一次相關性，開銷是非常大的，如何解決這個問題呢？不要忘記了我們這節的主題就是 倒排索引，主角終於粉墨登場了！！！

倒排索引

倒排索引非常類似我們前面提到的Hash結構。以下內容來自維基百科：

倒排索引（英語：Inverted index），也常被稱爲反向索引、置入檔案或反向檔案，是一種索引方法，被用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射。它是文檔檢索系統中最常用的數據結構。

有兩種不同的反向索引形式：

• 一條記錄的水平反向索引（或者反向檔案索引）包含每個引用單詞的文檔的列表。
• 一個單詞的水平反向索引（或者完全反向索引）又包含每個單詞在一個文檔中的位置。

後者的形式提供了更多的兼容性（比如短語搜索），但是需要更多的時間和空間來創建。

由上面的定義可以知道，一個倒排索引包含一個字典的索引和所有詞的列表。其中字典索引中包含了所有的Term(通俗理解爲文檔中的詞)，索引後面跟的列表則保存該詞的信息(出現的文檔號，甚至包含在每個文檔中的位置信息)。下面我們還採用上面的方法舉一個簡單的例子來說明倒排索引。

例如現在我們要對三篇文檔建立索引(實際應用中，文檔的數量是海量的)：

文檔1(D1)：中國移動互聯網發展迅速

文檔2(D2)：移動互聯網未來的潛力巨大

文檔3(D3)：中華民族是個勤勞的民族

那麼文檔中的詞典集合爲：{中國，移動，互聯網，發展，迅速，未來，的，潛力，巨大，中華，民族，是，個，勤勞}

建好的索引如下圖：

 

倒排索引

在上面的索引中，存儲了兩個信息，文檔號和出現的次數。建立好索引以後，我們就可以開始查詢了。例如現在有一個Query是”中國移動”。首先分詞得到Term集合{中國，移動}，查倒排索引，分別計算query和d1,d2,d3的距離。有沒有發現，倒排表建立好以後，就不需要在檢索整個文檔庫，而是直接從字典集合中找到“中國”和“移動”，然後遍歷後面的列表直接計算。

對倒排索引結構我們已經有了初步的瞭解，但在實際應用中還有些需要解決的問題(主要是由海量數據引起的)。筆者列舉一些問題，並給出相應的解決方案，拋磚以引玉，希望大家可以展開討論：

1.左側的索引表如何建立?怎麼做才能最高效？

可能有人不假思索回答：左側的索引當然要採取hash結構啊，這樣可以快速的定位到字典項。但是這樣問題又來了，hash函數如何選取呢？而且hash是有碰撞的，但是倒排表似乎又是不允許碰撞的存在的。事實上，雖然倒排表和hash異常的相思，但是兩者還是有很大區別的，其實在這裏我們可以採用前面提到的Bitmap的思想，每個Term(單詞)對應一個位置(當然了，這裏不是一個比特位)，而且是一一對應的。如何能夠做到呢，一般在文字處理中，有很多的編碼，漢字中的GBK編碼基本上就可以包含所有用到的漢字，每個漢字的GBK編碼是確定的，因此一個Term的”ID”也就確定了，從而可以做到快速定位。注：得到一個漢字的GBK號是非常快的過程，可以理解爲O(1)的時間複雜度。

2.如何快速的添加刪除更新索引？

有經驗的碼農都知道，一般在系統的“做加法”的代價比“做減法”的代價要低很多，在搜索引擎中中也不例外。因此，在倒排表中，遇到要刪除一個文檔，其實不是真正的刪除，而是將其標記刪除。這樣一個減法操作的代價就比較小了。

3.那麼多的海量文檔，如果存儲呢？有麼有什麼備份策略呢？

當然了，一臺機器是存儲不下的，分佈式存儲是採取的。一般的備份保存3份就足夠了。

好了，倒排索引終於完工了，不足的地方請指正。謝謝