資源描述:
《google論文1-google集群架構(gòu).doc》由會(huì)員上傳分享,免費(fèi)在線閱讀,更多相關(guān)內(nèi)容在學(xué)術(shù)論文-天天文庫(kù)。
1、【google論文一】面向星球的網(wǎng)絡(luò)搜索:google集群架構(gòu)??2010-10-0110:30:21
2、??分類:搜索與分布式
3、??標(biāo)簽:集群??服務(wù)器??索引??查詢??google??
4、字號(hào)大中小?訂閱?轉(zhuǎn)載請(qǐng)注明:http://duanple.blog.163.com/blog/static/70971767201091102339246/?作者phylips@bmy為了能夠支持可擴(kuò)展的并行化,google的網(wǎng)絡(luò)搜索應(yīng)用讓不同的查詢由不同的處理器處理,同時(shí)通過(guò)劃分全局索引,使得單個(gè)查詢可以利用多個(gè)處理器處理。針對(duì)所要
5、處理的工作負(fù)載類型,google的集群架構(gòu)由15000個(gè)普通pc機(jī)和容錯(cuò)軟件組成。這種架構(gòu)達(dá)到了很高的性能,同時(shí)由于采用了普通pc機(jī),也節(jié)省了采用昂貴的高端服務(wù)器的大部分花費(fèi)。?很少有網(wǎng)絡(luò)服務(wù)的單個(gè)請(qǐng)求像搜索引擎占用那樣多的計(jì)算資源。平均來(lái)看,在google上的每次查詢需要讀取數(shù)百m的數(shù)據(jù)耗費(fèi)數(shù)10億的cpu指令循環(huán)。為了能夠支持峰值在每秒數(shù)千次請(qǐng)求流,需要與世界上最大的超級(jí)計(jì)算機(jī)規(guī)模相當(dāng)?shù)挠布O(shè)施。通過(guò)容錯(cuò)性軟件將15000個(gè)普通pc機(jī)聯(lián)合起來(lái),提供了一種比使用高端服務(wù)器更廉價(jià)的解決方案。?本文我們將介紹google的集
6、群架構(gòu),討論那些影響到設(shè)計(jì)方案的最重要的因素:能效和性價(jià)比。在我們的實(shí)際操作中,能效實(shí)際上是一個(gè)關(guān)鍵的度量標(biāo)準(zhǔn),因?yàn)閿?shù)據(jù)中心的電力是有限的,因此電力耗費(fèi)和制冷成為運(yùn)作中的關(guān)鍵。?我們的應(yīng)用本身可以很容易進(jìn)行并行化:不同的查詢可以運(yùn)行在不同的處理器上,同時(shí)全局索引也劃分的使得單個(gè)查詢可以使用多個(gè)處理器。因此,處理器的性價(jià)比比峰值性能變得更重要。同時(shí),google的應(yīng)用是面向吞吐率的,可以更有效的利用處理器提供的并行化,比如并行多線程(SMT),或者多核處理器(CMP)。??Google架構(gòu)概覽??Google的軟件架構(gòu)來(lái)源于
7、兩個(gè)基本的觀點(diǎn)。首先我們需要在軟件層面提供可靠性,而不是通過(guò)硬件,這樣我們就可以使用普通的pc構(gòu)建廉價(jià)的高端集群。其次,我們不斷的裁剪設(shè)計(jì)是為了達(dá)到最好的總體請(qǐng)求吞吐率,不是為了提高服務(wù)器的峰值響應(yīng)時(shí)間,因?yàn)槲覀兛梢酝ㄟ^(guò)并行化獨(dú)立的請(qǐng)求來(lái)控制響應(yīng)時(shí)間。?我們相信使用不可靠的廉價(jià)pc來(lái)構(gòu)建可靠的計(jì)算設(shè)施可以達(dá)到最好的性價(jià)比。通過(guò)在不同的機(jī)器上備份服務(wù),以及自動(dòng)化的故障檢測(cè)和錯(cuò)誤處理,為我們的環(huán)境提供軟件級(jí)的可靠性。這種軟件級(jí)的可靠性在我們的系統(tǒng)設(shè)計(jì)中幾乎隨處可見(jiàn)。檢查一下一次查詢處理的控制流程,有助于理解這種高級(jí)的查詢服務(wù)系
8、統(tǒng),同時(shí)也有助于對(duì)于可靠性考慮的理解。?Google的一次查詢?當(dāng)用戶在google中輸入一次查詢,用戶瀏覽器首先通過(guò)DNS進(jìn)行域名解析,將www.google.com轉(zhuǎn)換為ip地址。為了對(duì)查詢可以進(jìn)行更有效的處理,我們的服務(wù)由分布在世界各地的多個(gè)集群組成。每個(gè)集群大概有數(shù)千個(gè)機(jī)器,這種地理上的分布可以有效的應(yīng)付災(zāi)難性的數(shù)據(jù)中心失敗比如地震,大規(guī)模的停電。基于DNS的負(fù)載平衡系統(tǒng),會(huì)計(jì)算用戶的與每一個(gè)物理集群地理上的距離來(lái)選擇一個(gè)合適的物理集群。負(fù)載平衡系統(tǒng),需要最小化請(qǐng)求往返時(shí)間,同時(shí)要考慮各個(gè)集群的可用容量。?用戶瀏覽
9、器然后給這些集群中的一個(gè)發(fā)送一個(gè)http請(qǐng)求,之后,對(duì)于該集群來(lái)說(shuō),所有的處理都變成了本地化的。在每個(gè)集群中有一個(gè)基于硬件的負(fù)載平衡器監(jiān)控當(dāng)前可用的googlewebservers(GWS)集合,并在這個(gè)集合上將本地的請(qǐng)求處理進(jìn)行負(fù)載平衡。收到一個(gè)請(qǐng)求之后,GWS協(xié)調(diào)這個(gè)查詢的執(zhí)行,并將結(jié)果格式化為html語(yǔ)言。圖1表示了這個(gè)過(guò)程。??查詢執(zhí)行由兩個(gè)主要階段組成,第一個(gè)階段,索引服務(wù)器查閱倒排索引(將每個(gè)查詢?cè)~映射到匹配的文檔列表)。索引服務(wù)器然后決定相關(guān)的文檔集合,通過(guò)對(duì)每個(gè)查詢?cè)~匹配的文檔列表求交集,為每個(gè)文檔計(jì)算出一
10、個(gè)相關(guān)性的分值,這個(gè)分值決定了在輸出結(jié)果中的排序。?搜索的過(guò)程非常具有挑戰(zhàn)性,因?yàn)樾枰幚砗A繑?shù)據(jù):原始網(wǎng)頁(yè)文檔通常具有數(shù)十T的未壓縮數(shù)據(jù),從原始數(shù)據(jù)中導(dǎo)出的倒排索引本身也有好幾T的數(shù)據(jù)。幸運(yùn)的是,通過(guò)將索引劃分到不同的片段,可以將搜索高度并行化,每個(gè)片段具有從全布索引中隨機(jī)選擇的一個(gè)文檔子集。一組機(jī)器負(fù)責(zé)處理對(duì)于一個(gè)索引片段的請(qǐng)求,在整個(gè)集群中每個(gè)片段都會(huì)有這樣的一組機(jī)器與之對(duì)應(yīng)。每個(gè)請(qǐng)求通過(guò)中間負(fù)載平衡器選擇組內(nèi)機(jī)器中的一個(gè),換句話說(shuō)每個(gè)查詢將會(huì)訪問(wèn)分配到每個(gè)片段的一臺(tái)機(jī)器(或者是一組機(jī)器的子集)。如果一個(gè)片段的備份壞
11、了,負(fù)載平衡器將會(huì)避免在查詢時(shí)使用它,我們的集群管理系統(tǒng)的其他組件將會(huì)嘗試修復(fù)它,實(shí)在不行就用另一臺(tái)機(jī)器來(lái)取代它。停工期間,系統(tǒng)的容量需要減去那臺(tái)壞掉的機(jī)器所代表的容量。然而,服務(wù)仍然是未中斷的的,索引仍然是可用的。?第一階段的查詢執(zhí)行最終輸出一個(gè)排過(guò)序的文檔標(biāo)識(shí)符列表。第二階段則通過(guò)獲取這個(gè)文檔列表,