如何處理海量數據【轉】

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

1、數據量過大，數據中什麼狀況均可能存在。

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

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

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

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

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

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

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

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

2、編寫優良的程序代碼

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

3、對海量數據進行分區操做

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

4、創建普遍的索引

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

5、創建緩存機制

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

6、加大虛擬內存

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

7、分批處理

海量數據處理難由於數據量大，那麼解決海量數據處理難的問題其中一個技巧是減小數據量。能夠對海量數據分批處理，而後處 理後的數據再進行合併操做，這樣逐個擊破，有利於小數據量的處理，不至於面對大數據量帶來的問題，不過這種方法也要因時因勢進行，若是不容許拆分數據，還 須要另想辦法。不過通常的數據按天、按月、按等存儲的，均可以採用先分後合的方法，對數據進行分開處理。

八、使用臨時表和中間表

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

9、優化查詢SQL語句

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

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

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

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

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

12、創建視圖或者物化視圖

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

十3、避免使用32位機子（極端狀況）

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

十4、考慮操做系統問題

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

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

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

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

基於海量數據的數據挖掘正在逐步興起，面對着超海量的數據，通常的挖掘軟件或算法每每採用數據抽樣的方式進行處理，這樣 的偏差不會很高，大大提升了處理效率和處理的成功率。通常採樣時要注意數據的完整性和，防止過大的誤差。筆者曾經對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就是找到一種數據內容和數據存放地址之間的映射關係。 
  數組的特色是：尋址容易，插入和刪除困難；而鏈表的特色是：尋址困難，插入和刪除容易。那麼咱們能不能綜合二者的特性，作出一種尋址容易，插入刪除也容易 的數據結構？da案是確定的，這就是咱們要提起的哈希表，哈希表有多種不一樣的實現方法，我接下來解釋的是最經常使用的一種方法——拉鍊法，咱們能夠理解爲「鏈表 的數組」，如圖： 

 

左邊很明顯是個數組，數組的每一個成員包括一個指針，指向一個鏈表的頭，固然這個鏈表可能爲空，也可能元素不少。咱們根據元素的一些特徵把元素分配到不一樣的鏈表中去，也是根據這些特徵，找到正確的鏈表，再從鏈表中找出這個元素。 
元素特徵轉變爲數組下標的方法就是散列法。散列法固然不止一種，下面列出三種比較經常使用的。 
1，除法散列法 
最直觀的一種，上圖使用的就是這種散列法，公式： 
index = value % 16 
學過彙編的都知道，求模數實際上是經過一個除法運算獲得的，因此叫「除法散列法」。 
2，平方散列法 
求index是很是頻繁的操做，而乘法的運算要比除法來得省時（對如今的CPU來講，估計咱們感受不出來），因此咱們考慮把除法換成乘法和一個位移操做。公式： 
index = (value * value) >> 28 
若是數值分配比較均勻的話這種方法能獲得不錯的結果，但我上面畫的那個圖的各個元素的值算出來的index都是0——很是失敗。也許你還有個問 題，value若是很大，value * value不會溢出嗎？da案是會的，但咱們這個乘法不關心溢出，由於咱們根本不是爲了獲取相乘結果，而是爲了獲取index。 
3，斐波那契（Fibonacci）散列法 
平方散列法的缺點是顯而易見的，因此咱們能不能找出一個理想的乘數，而不是拿value自己看成乘數呢？da案是確定的。 
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彩piao中獎號碼列表，其中要包含20000箇中獎號碼。

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

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

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

數據庫索引

什麼是索引

　　數據庫索引比如是一本書前面的目錄，能加快數據庫的查詢速度。
　　例如這樣一個查詢：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的性能優化的一些經驗，可是隨着信息大爆炸，單機的數據庫服務器已經不能知足咱們的需求，因而，多多節點，分佈式數據庫網絡出現了，其通常的結構以下：

 

分佈式數據庫結構

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

 

 

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

引言：

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

VSM檢索模型

VSM全稱是Vector Space Model(向量空間模型)，是IR(Information Retrieval信息檢索)模型中的一種，因爲其簡單，直觀，高效，因此被普遍的應用到搜索引擎的架構中。98nian的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.左側的索引表如何創建?怎麼作才能最高效？

可能有人不假思索回da：左側的索引固然要採起hash結構啊，這樣能夠快速的定位到字典項。可是這樣問題又來了，hash函數如何選取呢？並且 hash是有碰撞的，可是倒排表彷佛又是不容許碰撞的存在的。事實上，雖然倒排表和hash異常的相思，可是二者仍是有很大區別的，其實在這裏咱們能夠採 用前面提到的Bitmap的思想，每一個Term(單詞)對應一個位置(固然了，這裏不是一個比特位)，並且是一一對應的。如何可以作到呢，通常在文字處理 中，有不少的編碼，漢字中的GBK編碼基本上就能夠包含全部用到的漢字，每一個漢字的GBK編碼是肯定的，所以一個Term的」ID」也就肯定了，從而能夠 作到快速定位。注：獲得一個漢字的GBK號是很是快的過程，能夠理解爲O(1)的時間複雜度。

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

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

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

固然了，一臺機器是存儲不下的，分佈式存儲是採起的。通常的備份保存3份就足夠了。

核心技術：Maven,Springmvc mybatis shiro, Druid, Restful, Dubbo, ZooKeeper,Redis,FastDFS,ActiveMQ,Nginx 
1.     項目核心代碼結構截圖

   項目模塊依賴

特別提醒：開發人員在開發的時候能夠將本身的業務REST服務化或者Dubbo服務化

2.    項目依賴介紹

   2.1 後臺管理系統、Rest服務系統、Scheculer定時調度系統依賴以下圖：

 

       2.2 Dubbo獨立服務項目依賴以下圖：

 

3.  項目功能部分截圖：

 

 

 

 

 

 

 

zookeeper、dubbo服務啓動 

 

 

dubbo管控臺 

 

 

 

 

 

 

 REST服務平臺