Google大資料論文GFS(Google File System)介紹

眾所周知，現在大資料技術的應用越來越成為一種趨勢，但是很多人只是聽過一個名詞，并不真正的了解大資料具體是在進行什么樣的作業，

根據百度百科上的定義：大資料（big data） 是指無法在一定時間范圍內用常規軟體工具進行捕捉、管理和處理的資料集合，是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率和多樣化的資訊資產，

我們說通俗一點就是：大資料是按照普通的手段，無法處理得到理想結果的海量的資料，因此我們需要用新的手段對這些海量的資料進行處理，

首先我們要來對 “ 海量資料 ” 這個概念進行理解，什么叫做海量資料呢，首先我們要對資料的數量級有一個認識，

資料最小的基本單位是bit，而1bit就相當于1個0/1，在計算機的底層，資料都是以0/1的形式存在的，也就是我們俗稱的 “機器碼” ，而資料按從小到大的順序給出所有單位：bit、Byte、KB、MB、GB、TB、PB、EB、ZB、YB、BB、NB、DB，他們之間的都是1024的進率，

對這幾個單位可能沒有什么很直觀的概念，這里我來給大家舉幾個例子：

• 人類歷史上說過的所有的話儲存在電腦里面，差不多只有1EB級別，
• 1PB的容量約等于小時候我們看的250000張DVD的容量，我們就算一天看一張DVD，大約要看680年才能看完，
• 1PB的資料按照百兆寬帶全速下載（100M/s），要下載兩年半才能下完

現在大家可能明白了PB的資料量是驚人的，然后再給大家猜一個問題，你知道谷歌每天要處理的資料量有多大嗎？
答案是：20PB！

因此大家可能對于我們今天的所強調的 海量資料 有了一個直觀的感受，

以前一臺單獨的普通計算機（或者服務器），處理資料的速度是以KB/s為單位的，但是我們現在明顯感受到，在大資料的領域，如果依然按照KB/s的處理能力來處理資料，那么只會使得系統陷入停滯或者癱瘓，

因此我們亟需設計一種擁有強大的資料采集、存盤、處理的系統，這也是我們大資料主要解決的問題，

大資料的起源來源于google的三篇論文：《Google File System》(GFS)、《MapReduce》、《BigTable》，為什么這三篇論文都是google發表的呢？因為創新來源于需求，作為世界上最龐大的資料體，google每天的搜索量達到了驚人的30億次，平均每秒鐘都有3.4萬個問題被搜索，因此google也最先遇到了需要設計一個龐大的系統來處理如此海量的資料，

《Google File System》(GFS) 這篇論文，就像是一篇設計檔案一樣，具體的描述了google如何去設計一個分布式的檔案管理系統，來對每天產生的海量資料進行管理、儲存、修改、訪問，

因為谷歌公布了其技術論文，更有國外類似如Hadoop的等開源框架的具體實作，國內的許多互聯網大廠才能在此基礎上設計自己的分布式檔案管理系統，例如淘寶的TFS（Taobao File System） 、**百度的BFS（Baidu File System）**等等，

作為大資料的 “開山鼻祖”，進來我們就來簡單了解一下google的 《Google File System》(下文簡稱GFS)，

設計預期

在GFS的開篇中就說到，這個系統在設計之初就是希望設計成一個分布式的檔案系統，其中整個系統由許多普通且廉價的服務器組成（大約幾百臺或者上千臺），系統設計完成必須要滿足這么幾個預期：

• 性能：這個系統要求對于資料的吞吐量必須要達到MB/s、GB\s甚至是TB/s的級別，這樣在一瞬間有海量的資料涌來的時候，才能對這些資料進行處理，

• 可伸縮性：因為組成系統的每臺服務器都是普通的服務器，因此每臺服務器隨時都有損壞、報廢的可能，因此必須使得系統能夠自動的檢測哪些服務器出現了問題，并且可以自動的對其進行處理，不需要使得整個系統斷電，就能動態的改變服務器的數量，這樣的性能非常的重要，不但體現在服務器損壞時可以自動的修復，更加體現在比如 **“雙十一”**時，這時候的資料量肯定比以往的資料量更加的龐大，因此需要的服務器的數量就更多，因為需要系統可以根據實時的需要，來決定使用的服務器的資源的多少，這樣的 可伸縮性 使得整個系統的更加的靈活，

• 可靠性：這里的可靠性就是指系統需要有很強的容錯能力，比如上文提到的，如果服務器突然損壞，怎么來保證資料不丟失，更有甚者，比如發生了自然災害，整個資料中心崩潰，怎么來恢復資料，保證系統能繼續進行正常的作業，還有在日常的一些對資料的訪問的程序中，如果系統發生了物理上的例外，比如發生了0/1的跳變，那如何來進行容錯，這些都是設計整個系統的可靠性時，需要進行考慮的東西，

• 可用性：可用性指用戶如何來對資料進行訪問、修改、追加、復制等操作，同時需要保證多個客戶端并行（同時）的訪問或者修改同一個資料時，怎么才能保證資料的一致性，是使得資料的修改不混亂，保證下一次讀取時，資料時可用的，不是混亂的資料，

系統架構（系統怎么作業的）

GFS中包含了數百臺服務器（普通的計算機），一個服務器就是一個節點，其中有一臺服務器最特殊，叫做 “Master節點”，他是所有服務器的老大，其余的服務器都叫做 “Chunk節點”，整個系統叫做一個集群，而海量的資料都是存盤在集群上的，同時資料的計算和處理也是基于集群作業的，

• Master節點：Master節點是儲存什么的呢?Master節點儲存的是 “元資料”，說通俗點，儲存的就是每一個Chunk資料的位置，以及每一個Chunk節點儲存了哪些資料， 注意：master節點不存盤具體的資料，具體的資料都存盤在chunk節點上，Master節點相當于一個目錄，你通過master節點就可以查到你想要的資料存盤在哪一個chunk節點上，以及這個chunk節點的具體位置在哪里，

• chunk節點： chunk節點用來存盤具體的資料，其中的資料是一塊一塊的劃分的，我們稱作塊資料，一塊的大小為大概128M，注意：為了保證容錯性，我們一般會使用3個chunk來存盤相同的資料，也就是說將一份資料備份3份，這樣當一個chunk出錯或者損壞時，可以通過另外兩份備份的資料，快速的將當前chunk的資料進行恢復，

下面舉一個例子來說明，當客戶端需要訪問或者修改時，系統的互動流程：

• 客戶端訪問master節點，master節點根據客戶端需要訪問的資料，查找自身存盤的索引資訊，找到對應的chunk節點的位置和索引范圍；

• master節點回傳chunk節點的位置，以及chunk節點中塊資料（block）的范圍，注意：因為相同的資訊一般會存盤在3個chunk節點當中，因此這里master節點會根據相應的演算法來尋找距離最近的chunk節點，作為主chunk

• 客戶端獲取到chunk的位置和資料區域以后，和主chunk進行連接，訪問主chunk內的資料，不再和master進行交流 注意：在沒有意外的情況下，客戶端一般是和主chunk進行互動，如果讀資料有修改，再由主chunk將資料同步到其他的chunk之中

• 客戶端訪問chunk完成后，chunk向master進行通信，更新master記憶體儲的資料區域的位置，保證客戶端下次讀取時資料的正確，
  
  這就是比較的簡單的一次客戶端訪問系統時產生的一些互動流程，在這里有一些補充的注意點：

• 盡量減少對Master的訪問：雖然我們使用的服務器都是普通且廉價的，但是master節點依然占有比較重要的位置，如果master節點損壞的話，會對整個系統產生比較嚴重的影響，因此我們應該盡量的減少對master節點的訪問，而且master節點的數量相比于chunk節點很少（一般1個集群1臺master節點），如果所有的客戶端訪問該系統都需要頻繁的和master節點進行互動的話，必然會嚴重降低系統的并行處理資料的性能，不符合我們整個系統大吞吐量的設計目標，因此，一般來說客戶端每次訪問系統只需要和master進行一次互動，在獲取了相應的chunk的位置和資料范圍后，以后的操作都直接和chunk進行互動就ok了，這樣就避免了頻繁的和master進行互動，

• 主chunk失效不需要重新訪問master： 這里還有一個細節，master在回傳chunk的位置和資料范圍時，并不是只回傳主chunk的位置和資料范圍，而是連帶著將其與兩個chunk的位置和范圍也一并回傳，這樣如果客戶端訪問主chunk失敗，可以直接訪問其他的兩個chunk，不需要再和master進行互動，

• “資料流”傳輸：chunk之間的資料傳遞是通過資料流的形式進行的，什么意思呢，比如，客戶端在向主chunk進行寫資料時，并不是說等全部寫完了以后，主chunk再把資料同步到另外兩個chunk，主chunk是一邊接收，一邊傳輸，收到多少資料，就把資料同步到另外兩個chunk，因此也叫 “管道傳輸”， 這樣做的目的也是為了提高系統的吞吐量性能，另外兩臺服務器不需要進行等待，可以進行作業，

• 主chunk“限時租約，超時識訓”： master指定一臺chunk節點作為主節點時，這個程序叫做 “租約”，租約一般是有時間限制的，當時間超出后，master會重新給客戶端分配主chunk，這叫做 “租約更改” ，這樣做的主要目的是為了防止主chunk內陷入死回圈或者損壞時，系統的作業無法繼續進行，

以上就是對GFS（Google File System）的內容簡單介紹和講解，大家如果希望對其了解更多的話，一定要去閱讀原論文，原論文寫的很通俗，完全可以讀懂，這里附上鏈接，
Google File System中文論文

這里也建議可以利用已經實作的開源的框架Hadoop去搭建自己的分布式集群，真正的去領略 “大資料” 的魅力，

以上屬于個人分享，歡迎留言、批評、交流，一起進步！