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取得的成就都引人矚目。像紐約證券交易所和航空公司訂票系統都使用大量的Unix服務器與軟件，而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的業務數量級，這無疑是一個艱巨的挑戰。毫無疑問，很多小公司正在羨慕的看著他們。