在處理海量數據的過程中，關係型數據庫的侷限性會較為突出，因為其二維表的存儲結構有時並不適用於行與列的搜索和計算。在Hadoop體系下，人們可以用HBase，而MapReduce作為其底層的計算工具，這是常見的大數據處理模式。後來，Google對其進行了改進，放棄MapReduce，隨之用Bigtable加以取代。相比於MapReduce而言，Bigtable對其計算性能和安全性能進行了改進，在吸收關係型數據庫的基礎上，Bigtable採用採用分佈式存儲技術、併發數據處理，動態伸縮性也大為加強，加強了用戶對數據分佈和格式的動態控制。
如果說Bigtable在海量數據計算方面較為突出，那麼用於存儲這些海量數據的就是GFS。GFS也是Google開發的大型分佈式數據存儲架構，其優點一個是數據量大，一個是可以在成本低廉的硬件上加以實施。其存儲架構分為一個主服務器和多個分服務器。主服務器可用於記錄存儲位置、對文件系統進行運行和維護、回收其他服務器上的垃圾等。下面再詳細說明一下GFS與MapReduce的關係。
通常GFS用於存儲海量數據，文件系統將數據在各個節點冗餘複製。在某種程度上MapReduce可以對GFS進行補充，以便充分利用GFS中廉價的服務器所提供的CPU。和GFS一起構成了處理海量數據的核心力量，構建類似於Google的搜索索引也是一樣的。但是這兩個系統都缺乏實時隨機存取數據的能力，在web應用處理方面還有所欠缺。
GFS的不足之處除了上述以外，在這一系統中並不適合存儲非常大的文件，而不適合存儲成千數萬的小文件，例如社交平臺上的圖片，因為文件的眾多數據信息最終要存儲在主節點的內存中，文件數量龐大會導致服務器運行緩慢。
針對上述存在的問題則需要一個能夠驅動交互應用的解決方案，而且能同時利用以上兩種基礎架構和依靠GFS 存儲的數據冗餘和數據可用性較強的特點。可以將存儲的數據進行拆分從而轉換成較小的條目，然後由系統將這些小記錄聚合到非常大的文件中，同時提供索引排序，使用戶可以查找最少的磁盤就能夠獲得所需要的數據。尚學堂陳老師指出，做好這些工作的目的是要讓它能夠及時存儲爬蟲的結果，與MapReduce協作生成搜索索引。由於摒棄了一些關係型數據庫的特性，所以可採用簡單的API來進行增刪改查操作，同時加一個掃描函數，以在較大的鍵範圍或全表上迭代掃描，最終形成一個管理結構化數據的分佈式存儲系統BigTable。
以上介紹了Bigtable的形成過程，從而引出其與MapReduce和GFS之間的關係，這也是在瞭解Bigtable的過程中所必須掌握的常識。
閱讀更多 淨水如你眼 的文章
