google在Big Data 應用上的技術與論文介紹

最新推荐文章于 2024-07-29 22:43:52 发布

chrysanthemumcao

最新推荐文章于 2024-07-29 22:43:52 发布

阅读量1k

点赞数

转载自:http://techorange.com/2013/05/14/big-data-beyond-mapreduce/

目前 Big Data 的相關應用有不少都是從 MapReduce 衍生而出的，但，若把焦點移到即時資料（Real-Time Data）的需求上時就會發現它的不足之處。

因此，本篇文章將與各位讀者分享，從 Google 發佈 GFS、Big Data 與 MapReduce 這些技術開始，到這些技術發展的現況與其所遭遇到的瓶頸，以及 Google 為了解決這些問題提出了哪些因應的技術。

MapReduce，GFS 與 Bigtable，帶動了 Big Data 應用技術的發展

Google 在 2003 年發表了第一篇論文〈The Google File System〉。文中敘述，GFS（Google File System）是一個分散式檔案系統，由數百個叢集（Cluster）所組成。簡單來說，儲存在 GFS 的檔案會被切割成 64 MB 左右的資料塊（Chunk），其利用重複的方式（Redundant Fashion）儲存在叢集中。

2004 年，Google 發表了 MapReduce 論文〈MapReduce: Simplified Data Processing on Large Clusters〉，如今，MapReuce 可以說幾乎已經跟 Big Data 劃上等號了。

Google 利用 MapReuce 演算法來計算查詢索引（Search Index），讓使用者能在最短的時間內從 Internet 上找到自己所需要/查詢的資料。

2006 年，Google 發表了 Bigtable 論文〈Bigtable: A Distributed Storage System for Structured Data〉，而 Bigtable 帶領了許多 NoSQL 資料庫的技術應用發展，像是 Cassandra、HBase 等等。

其中，Cassandra 的架構就整合了 Bigtable（資料模型、SSTables 及 Write-Through-Logs）與 Amazon 的 Dynamo 資料庫（Peer-to-Peer Clustering Model）。

Percolator，能夠解決 MapReduce 無法處理個別更新的問題

隨著 Internet 的網頁呈現指數增加，MapReduce 每次都要全面地重新計算查詢索引是非常不切實際的。因此，Google 為了提升系統的效能，開發了一個更有價值的分散式計算系統：Percolator。

Google 在 2010 年發表了相關的論文〈 Large-scale Incremental Processing Using Distributed Transactions and Notifications〉，文中敘述 Google 如何在網路搜尋索引（Web Search Index）的技術持續地維持精進。例如，MapReduce 做計算時無法處理局部的更新，因此，在效能的改善部份是很有限的，而 Percolator 則彌補了這個弱點。

但是，各位讀者千萬不要誤以為 Percolator 是用來取代 MapReduce 的。

Percolator 是建立於 Bigtable 之上的應用，它加入了對表（Table）與紀錄（Row）的交易（Transaction）與鎖定（Lock）機制，也就是當 GFS 做表的掃描時，一旦發現有更新過的紀錄，就會透過觸發程序（Trigger）告知這個改變，再依據讀取（Read）或寫入（Write）的請求，在不同階段的工作過程中，針對資料表或記錄做鎖定或釋放的管理機制。透過這樣子的方式，來完成局部個體的更新。

Pregel：用來處理網絡社交關係的圖型結構計算

Google 為了做網路社交關係的圖型結構分析，開始針對圖型結構探勘做相關的研究與發展，並在 2010 年發表了相關的論文〈Pregel: A System for Large-Scale Graph Processing〉。

由於針對大型的圖型結構做處理是非常複雜也具有挑戰性的，尤其是網路的分散式處理讓難度又提高了許多，因此，Pregel 的計算要比MapReduce 的計算要複雜許多，其主要是利用BSP（Bluk Synchronous Parallell）、PageRank、Bipartite Matching 等演算法來做計算的實踐。而在論文中你也可以看到上述這些方法的實踐。