Google揭開了內部工作方式的神秘面紗。
Google這個搜索巨人很少暴露其數據中心，但在上周，Google研究員Jeff Dean在Google I/O會議上揭秘了它的部分運行情況。
一方面，Google使用了一些常規伺服器，另外一方面，Google將1800台伺服器組成了集群，這些集群伺服器負責Google日常的搜索處理任務，這部分伺服器的數量大約是700到1000台。
Google並未透露擁有多少台伺服器，但我們估計的數量有成千上萬。Dean透露，Google將40台伺服器編為一個集群，而在全球範圍， Google擁有36個數據中心。每個數據中心有150個伺服器集群，這意味著Google擁有的伺服器數量超過20萬台，不過Google伺服器的數量應該遠遠超過這一數字，而且每天都在增長。
無論有多少台伺服器，Google取得的成就都引人矚目。像紐約證券交易所和航空公司訂票系統都使用大量的主幹機伺服器與軟體，而Google主要使用自己的技術。
可以肯定，許多伺服器廠商對此會感到酸溜溜的，但Google明顯認為，將自己的技術命運掌握在自己手中最安全。Google搜索產品與用戶體驗部門副總裁Marissa Mayer說，創始人Larry Page鼓勵在公司中形成一種「健康的，對不可能說不」的氣氛。
為了應對Google這樣的搜索規模，需要讓每台機器的性能發揮到極致。雖然伺服器廠商們對其高端機型中的容錯性能津津樂道，但Google更樂意將錢投到容錯軟體上。
Dean說：「我們的觀點是，不可靠的硬體數量最好是可靠機型的兩倍。你需要將可靠性放在軟體層面。假如你運行1萬台機器，那麼每天都有一些當機。」
Dean 說，在每個伺服器集群運行的頭一年，一般有1千台機器會發生故障；數千塊硬碟會出問題；一個「電源分配單元」（PDU）將壞掉，令500到1000台機器當機6小時；20個伺服器機架將出現故障，造成40到80台機器從網絡上掉線；5個伺服器機架將變得不穩定，這使得機架上的伺服器處理的一半信息包失去響應；一個伺服器集群需要重新連接，這將影響5%的機器，影響的時間跨度一般為2天。伺服器集群有50%的過熱可能性，過熱會讓絕大多數伺服器在5分鐘內當機，並且耗時1到2天來重新恢復。
雖然Google使用了一般的硬體設備，但在軟體上卻沒有使用尋常的軟體。Google要求英特爾提供專門定製的電路板。Dean還透露，Google目前為每40個伺服器組成的機架配備一個機箱，而不是象一般情況那樣為每個伺服器配備一個機箱。
對於伺服器本身，Google喜歡多核晶片配置。儘管許多軟體公司正在努力適應多核晶片時代的來臨，但Google對這種晶片使用起來得心應手。Google不得不讓自己的技術適應有限的硬體資源架構，因此，他們已經進入了並行處理時代。
Dean說：「我們確實喜歡多核機器。對我們來說，多核機器用少量的機器實現了良好的連接性能。對我們而言，它們更容易使用。」
儘管Google需要對搜索以及其它服務進行快速響應，並行處理能夠完成這一任務需要，雖然有可能單個線程的速度並不快。
Dean說：「單個線程的性能對我們來說確實沒有多大關係。我們將重點主要放在並行處理問題上。」
Google如何讓這些普通的硬體發揮作用？用軟體。
Dean 闡述了Google軟體的三大核心元素：Google文件系統（GFS）；Google大表(BigTable：是Google一種對於半結構化數據進行分布存儲與訪問的接口或服務)；MapReduce算法（它是Google開發的C++編程工具，用於大於1TB數據的大規模數據集並行運算）。儘管 Google依靠許多開源項目實現了企業的騰飛，但Google對這三套核心元素秘而不宣。
Google 文件系統處於這三個元素的最底層，它負責許多伺服器，機器的數據存儲工作。很多Google文件系統的體積都異常龐大，有好幾個petabyte規模（1 petabyte相當於1百萬gigabytes）。有200多個伺服器集群運行有Google文件系統，其中很多集群包含了上千台機器。
Google文件系統至少在三台名為「塊伺服器」（chunkservers）上存儲大體積數據（一般為64MB）；如果一台塊伺服器發生故障，那麼主伺服器會負責將數據恢復到新的區域。Dean說：「至少在存儲層面，機器故障的處理由Google文件系統來完成。」
為了給全部這些數據提供一些結構，Google使用了大表。象甲骨文和IBM公司的商業資料庫在這裡發揮不了作用，因為這些產品無法滿足Google的需要，Dean說，如果要使用商業資料庫的話，價格將非常的昂貴。
Google 從2004年開始設計大表，現在已經在Google 70多個項目中使用，包括Google地圖，Google地球，Blogger，Google Print和核心的搜索目錄。Dean說，大表管理的最大一個數據表格有6 petabytes大小，覆蓋上千台機器。
2003 年，Google編寫了MapReduce的第一個版本，這種算法給了Google公司一條讓自己數據發揮作用的途徑來。例如，MapReduce能夠找出一個詞語在Google搜索目錄中出現的次數；一系列網頁中特定詞語出現的頻率；連結到某個特定網站的所有網站數量等。
有了MapReduce，Google可以編寫出一個索引目錄，迅速顯示出與特定詞語相關的網頁出來。Dean說：「為了在可以接受的時間內完成這一工作，你需要在上千台機器上進行處理。」
Google 對MapReduce軟體的使用正在增多。2004年，MapReduce運行了2.9萬個工作任務，到2007年，已有220萬個工作由 MapReduce來完成。同期，MapReduce對於一個工作的平均運行響應時間從634秒下降到了395秒，MapReduce任務的數據產出量從 193 terabytes上升到了14018 terabytes。
Dean說，在任何一天，Google運行有大約10萬個MapReduce工作任務；每項任務大約會占用4百台伺服器，時間大約是5到10分鐘。
這是一個有趣的數學計算。假設伺服器只完成MapReduce工作，每台伺服器一次只完成一項任務，那麼大約要耗時24小時，如果這些工作任務每個耗時5分鐘，這意味著MapReduce任務要占用大約13.9萬台伺服器。如果耗時7.5分鐘，那麼需要的伺服器數量增加到20.8萬台；如果需要 10分鐘，伺服器的數量增加至27.8萬台。
和Google文件系統一樣，MapReduce的設計也要考慮伺服器的當機問題。
Dean說：「當一台機器當機，主伺服器會了解分配給這台機器的任務是什麼，然後直接指定其它機器來完成這一任務。」
MapReduce的可靠性曾經在一個由1800台伺服器組成的集群進行維護時經受住了嚴格考驗。工作人員將其中80台機器拔掉，其它1720台機器承擔起了80台機器的處理任務。Dean說：「它運行有一些慢，但全部完成了任務。」
在2004年，Dean表示，曾經有一個1800台機器組成集群，其中1600台當機了，但整個系統經受住了考驗。
儘管Google的數據中心取得了很大的成功，但公司並不滿足，他們有很長遠的改進發展計劃。
對於一般的企業來說，他們只需要考慮將工作任務從一台伺服器轉移到另外一台，但Google面臨的工作量級不同，他們希望能夠將工作任務由一個數據中心自動轉移到另外一個中心。
Dean說：「我們希望自己的下一代架構是一種能夠超越單個機器的系統。」
考慮到Google的業務數量級，這無疑是一個艱巨的挑戰。毫無疑問，很多小公司正在羨慕的看著他們。
