通向高可扩展性之路（谷歌篇）
原文鏈接：http://highscalability.com/google-architecture
原文寫于2008年11月22日，以下是譯文：
?
平臺：
1. Linux
2. 很多種語言： Python， Java， C++
?
平臺上有什么？
一些數據：
1. 2006年時大約有450,000 臺廉價商用服務器
2. 2005年的時候谷歌已經索引了80億網頁。現在大概沒人知道他們已經索引了多少網頁了。
3. 現在谷歌有超過200個GFS集群。一個集群可以有1000甚至5000臺機器。成千上萬臺的機器從這些可以裝得下5PB存儲的GFS集群中讀取數據。一個集群的總的讀寫吞吐量可以高達每秒40GB。
4. 目前谷歌已有6000個MapReduce的程序，還正在已每個月數百的速度增加。
5. BigTable可以擴展到存儲數以十億計得URL，數以百TB計的衛星圖片，以及數以億計的用戶偏好。
?
技術堆棧：
谷歌把他們的基礎設施視為一個三層的堆棧：
1. 產品：搜索，廣告，郵件，地圖，視頻，聊天，博客
2. 分布式系統基礎設施： GFS，MapReduce, 和BigTable
3. 計算平臺： 在各個不同數據中心運行著的那些機器
4. 確保公司員工可以以較低的成本方便地部署應用
5. 關注每一個應用的性價比。花更多的錢在硬件上來確保不丟失日志數據，但是在其他類型的數據上花更少的錢。雖然這么說，但是谷歌不丟失數據。
?
基于GFS（Google File System）的可靠存儲機制：
1. 可靠地可擴展存儲是任何應用的一個核心需求。GFS是谷歌的核心存儲平臺。
2. 谷歌文件系統 - 大規模分布式日志結構的文件系統，用來存儲了很多很多數據
3. 為什么要自己開發這套系統而不是拿個已經存在的系統來用用？因為他們可以控制所有的細節，并且正是這套系統把谷歌和其他人區分了開來。他們需要：
- 多個數據中心之間的高可靠性
- 可擴展到數千個網絡節點
- 巨大的讀寫帶寬要求
- 支持大塊的GB級的數據
- 有效地將多個操作分散到不同節點來減少瓶頸
4. 系統有主服務器和塊服務器
- 主服務器用來存儲各種數據文件的元數據。真正的數據在文件系統中存為多個64MB大小的塊文件。客戶從主服務器獲取元數據并由此找到包含他們想要的文件的塊服務器。
- 塊服務器在硬盤上存著那些真正的數據。每一個塊都被復制到三個不同的塊服務器上來提供冗余，以防有的服務器會出故障。一旦客戶從主服務器上獲取了路徑信息，客戶的應用就會從塊服務器上直接下載文件。
5. 一個新的應用上線既可以使用已有的GFS集群，也可以建立一個新的集群。理解谷歌在他們的數據中心中使用什么樣的配置過程會是一件非常有趣的事情。
6. 關鍵是要有足夠的基礎設施來確保人們在上線他們的應用時有選擇的余地。GFS可以被適當地調整來適應不同應用的需求。
?
用MapReduce來處理數據：
1. 現在你有了一個很好的存儲系統，那么這么多數據能用來干嘛呢？我們假設你在1000臺機器上有好幾TB的數據。數據庫通常不能支持這么大的數據，就算支持，這樣的數據庫也會非常昂貴。這時MapReduce就體現出了作用。
2. MapReduce是一個編程模型，也包含一個與之關聯的處理和產生大數據集的具體實現。用戶聲明一個映射（map）函數來把一個鍵值對（key value pair）轉化成多個作為中間變量的鍵值對，以及一個歸納（reduce）函數來合并所有中間變量中具有相同鍵（key）的值（value）。很多現實中的任務可以用這個模型來表達。用這種功能性風格寫出來的代碼可以自動在大集群的商用服務器上并行執行。有一個實時系統會來管理輸入數據的分割，在多臺機器上調度程序的運行，處理機器故障，以及機器間溝通的問題。這可以使沒有在并行分布式系統下編程經驗的程序員們方便的利用一個大型分布式系統的資源。
3. 為什么使用MapReduce？
- 這是一個很好的在多臺機器間分攤任務的方法
- 處理機器故障
- 支持多種不同類型的應用，如搜索和廣告。幾乎每個應用都有MapReduce的操作。你可以預算有用的數據，找到單詞計數，為TB級的數據排序等等。
- 計算可以自動的離IO源更近
4. MapReduce系統有三種不同的服務器。
- 主服務器將用戶任務分配到映射服務器和歸納服務器上。它也跟蹤任務狀態。
- 映射服務器接受用戶輸入的數據，并對之執行映射操作。結果會被寫到中間文件中去。
- 歸納服務器對中間文件執行歸納操作。
5. 例如你想數數所有網頁中一共有多少個詞。你可以把所有GFS上的網頁輸入MapReduce。這將會導致數以千計的機器同時開工，而這一切的協調，任務調度，處理失敗，以及數據調送都會被自動執行。
- 具體步驟如下：GFS -> 映射 -> 洗牌 -> 歸納 -> 把結果存回GFS
- 在MapReduce中一個映射函數將數據從一種形式映射到另一種形式，并產生一個鍵值對。在我們的這個例子中，鍵就是單詞，值就是計數。
- 洗牌過程匯總了鍵的類型。
- 歸納函數把所有鍵值對做了匯總并產生了最終結果。
6. 谷歌索引流水線有大約20種不同的MapReduce。一個MapReduce匯總數據中的各種記錄的鍵，第二個mapReduce再利用這個結果做些別的事，然后又傳遞給下面的MapReduce，以此類推。
7. 程序可以很小，甚至20到50行的代碼都有。
8. 不過拖后腿的任務會是一個問題。拖后腿的任務指的是那些比其他任務執行的慢的任務。它會影響整個任務的進度。它可能是由于比較慢的I/O（比如一個差的控制器）或是一個暫時的CPU利用率陡升。解決方案就是同時執行多個一樣的任務，一旦有一個完成了就終止其它的。
9. 映射服務器和歸納服務器之間的數據傳輸是壓縮過的。基本想法是因為服務器并不受限于CPU，所以花點CPU時間在壓縮和解壓數據上來節省帶寬和I/O是值得的。
?
?在BigTable中存儲結構化數據：
1. BigTable是一個大規模容錯的自管理系統，包括TB級的內存和PB級的存儲。它可以支持每秒百萬的讀寫。
2. BigTable有一個基于GFS的分布式哈希機制。它不是關系型數據庫，不支持聯合或者SQL式的查詢。
3. 它支持基于關鍵字的查詢來獲得結構化的數據。GFS存儲不透明數據，許多應用需求也含有結構化的數據。
4. 商業數據庫通常不能擴展到如此規模，也不能運行在上千臺機器上。
5. 通過控制他們自己的下層存儲系統，谷歌可以獲得更多的控制力和杠桿來優化他們的系統。比如說，如果他們想要使跨數據中心的操作更簡單一些，他們可以把這個功能直接寫入他們的系統中。
6. 機器可以隨時加入或者離開這個系統，而這個系統還是可以工作。
7. 每一個數據項都被存在一個單元中，可以通過行健，列鍵或者時間標簽來獲取。
8.每一行都被存在一個或多個表單中。一個表單就是一系列64KB大小的，數據結構被稱為SSTable的塊。
9. BigTable有三種不同的服務器：
- 主服務器把表單分配到表單服務器上。它們跟蹤表單們在哪里，并且在需要時會重新分配任務。
- 表單服務器處理表單的讀寫請求。當表單的大小超過限制（通常100-200MB）時，它們會把表單拆分。當一臺表單服務器出故障時，它的表單會被分配到其他100臺服務器上，這樣系統就可以不受影響。
- 鎖服務器提供分布式鎖服務。一些類似向表單中寫入數據， 主服務器仲裁，以及訪問控制等操作需要互斥。
10. 一個地域性小組可以用來物理地集中存儲相關數據，以提高地域性偏好。
11. 表單盡可能的被存在RAM中。
?
硬件：
1. 當你有很多機器的時候，你會怎樣制造他們使得他們更加省錢省電？
2. 使用超級便宜的商用硬件，然后在其上設置軟件來處理它們的故障。
3. 如果你使用一個偵察故障的基礎設施，而不是確保每個部件都高度可靠，一千倍的用電量的增加可能可以只會增加33倍的支出。你必須在不可靠之上構建可靠來使這一套方法行之有效。
4. Linux，自己的服務器架設計，PC級的母板，低端存儲
5. 用每瓦特的成本來衡量的性價比并沒有提高，因為存在很大的電能和冷卻的問題。
6. 混合使用自己獨立的數據中心和與他人共享的數據中心。
?
其他：
1. 快速推出改動，而不是等待QA。
2. 代碼庫是創建程序的主要途徑。
3. 一些應用被當成服務提供給別人，例如爬蟲。
4. 有一個控制應用版本的基礎設施，所以不用擔心新發布一個版本會破壞什么東西。
?
谷歌的未來之路：
1. 支持含地理信息的分布式集群。
2. 給所有數據創建一個單一的全局命名域。現在數據被分散在各個集群中。
3. 更多更好的自動數據和計算遷徙。
4. 解決廣域復制和網絡分割引起的一致性問題（例如，即使一個集群因為做維護或者其他原因停運而下線，仍能保持服務可訪問）
?
學到的經驗教訓：
1. 基礎設施可以是一個競爭優勢。 這對于谷歌來說是很明顯的。他們可以更快更便宜的推出新的互聯網服務，規模之大很少有人可以媲美。很多公司走上了一條完全不同的路。他們把基礎設施認為是負擔。每一個組使用完全不同的技術，也沒有通用的計劃來構建這些系統。谷歌認為自己是一家系統工程公司，這是一個非常新穎的看待軟件開發的角度。
2. 拓展到多個數據中心仍然是一個未解決的難題。大多數網頁存在于一個或最多兩個數據中心之中。如何把一個網頁分布到多個數據中心上去是一個可以說非常需要技巧的事情。
3. 看看Hadoop如果你自己沒有時間從頭重新構建這整個一套基礎設施。Hadoop是一個開源的實現了很多跟這里說的類似的想法的系統。
4. 一個被低估了的平臺化開發的優勢就是年輕的開發員可以更快更有自信地在這個平臺上創造靠譜的應用。如果每一個項目都需要創建一樣的分布式基礎架構的話，你就有麻煩了，因為知道怎么做這些事情的人相當少見。
5. 協同并不是總是一件壞事。讓一個系統的所有部件協同工作的話，某一個部件改進就可以惠及其它所有的部件。優化文件系統，那每個人都可以立即不費任何功夫地受益。如果每一個項目都是用一個不同的文件系統，那就不可能對整個技術堆棧有一個持續的遞增的優化。
6. 創建不需要關閉系統的自管理系統。這樣可以使你更加容易地在服務器之間均衡資源，動態地增加容量，淘汰機器，以及自然地處理升級。
7. 創建一個達爾文式的基礎設施。并行處理多個相同的耗時操作，并只等最快的那個結束。
8. 不要忽視學術界。學術界有很多好的想法沒有被引入產業界。很多谷歌做的事情都有先例，只是沒有大規模部署。
9. 考慮壓縮。當你有很多CPU可以浪費，而I/O受限時，壓縮是一個很好地選擇。
轉載于:https://www.cnblogs.com/zhutianshi/p/4340925.html
總結
以上是生活随笔為你收集整理的通向高可扩展性之路（谷歌篇）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java调用Oracle存储Packag
- 下一篇： 微软Azure已开始支持hadoop--