大資料處理——Hadoop解析（一）

概述

這個時代被稱之為大資料時代，各行各業生產的資料量呈現爆發性增長，並且基於這些爆發性增長的資料做深層次的資料採礦、分析、處理。 因此，我們可以很容易的感覺到，在這樣一個大資料的時代，我們很多做事情的方法正在發生了改變。 例如，基於大資料分析可以做疾病預測控制;基於大資料分析可以做交通流量預測控制;基於大資料分析可以做大型系統故障診斷預測;基於大資料分析可以做客戶消費推薦。 可以說，大資料時代可以解決很多以前非常難以解決的問題。 可以這樣講，在這樣一個時代，大資料可以讓我們的生活變得更加美好。

突如其來的大資料時代，對技術界產生了巨大衝擊。 其最大的問題是如何存儲如此巨大的資料量?如何處理如此巨大的資料量。 針對這個問題，在Google的商業化系統之上，誕生了開源大資料處理系統Hadoop。

2003年Google發表了第一篇關於雲計算的核心技術文章GFS，當時，Apache的技術團隊意識到，GFS這種架構可以很好的解決網頁搜尋引擎建立過程中產生的海量檔的難題。 因此，參考了GFS的技術架構，完成了一套大資料檔案系統，並將之開源。 該檔案系統後來演變成Hadoop的核心專案HDFS。 2004年Google再次發表雲計算核心技術文章Mapreduce，解決了大型分散式運算中的程式設計模型問題。 隨後，Mapreduce的思想被應用於Hadoop的前身專案，並且開源。 2006年，雅虎將Hadoop專案從Nutch搜尋引擎專案中獨立，成為Apache的一個單獨子專案。 自此，Hadoop專案得以蓬勃發展。

截止到2013年10月，Hadoop 2.2.0版本已經成功發佈。 Facebook、阿裡巴巴、百度和騰訊都採用Hadoop部署了大資料處理平臺。 下面對Hadoop專案中的關鍵系統進行剖析。

分散式檔案系統

在大資料應用的背景下，檔存儲有以下幾個方面的特點：

1，海量資料存儲。 在大資料應用的環境裡，無論是檔的數量還是資料存儲規模都是十分巨大的。 因此，如果採用傳統存儲的模式，需要構建十分龐大的系統，並且需要傳統存儲支援十分靈活的可擴充性。 因為，在大資料時代，存儲的可擴充性顯得十分重要，資料量在不斷增加，存儲的規模也需要隨時跟進，因此，存儲的可擴充性是面向海量資料存儲的必然選擇。 傳統存儲基本都是面向單機高性能、單機高容量。 而大資料存儲需要面向低成本可擴擴充性，來應對不斷增加的海量存儲需求。 因此，傳統存儲在大資料環境中遇到了瓶頸，因為客戶的需求發生了變化。

2，大檔存儲。 在大資料應用環境中，存儲的檔基本以大檔為主。 這是一個十分重要的應用特徵。 面向Primary Storage領域的傳統存儲在設計的時候，主要考慮小檔的讀寫優化，因此，傳統存儲在大資料應用環境中，顯得很是浪費，主要專注的一面沒有很好的被應用，而使用者需求的一面沒有被重視。

3，讀多寫少的檔存儲。 在大資料應用環境中，讀請求比寫請求要多的多。 尤其在互聯網領域，寫請求不是很多，但是讀請求的數量十分巨大，因此，在讀多寫少的應用需求下，如何優化存儲設計是需要考慮的。

4，併發訪問。 在大資料應用環境下，應用用戶端的數量是十分巨大的，因此，如何避免檔案系統資料訪問瓶頸點，增強多客戶併發訪問的能力是分散式檔案系統設計需要考慮的重要問題。

為了滿足這種需求，Google提出了GFS的分散式檔案系統架構，Hadoop分散式檔案系統採用了該架構。 這種分散式檔案系統的結構如下所示：

從結構來講，這種分散式檔案系統是比較簡單的。 其主要分成兩大部分，第一部分是用來管理檔目錄結構以及檔中繼資料的控制器，這個控制器被稱之為 NameNode;第二部分是用來存儲資料的DataNode。 當用戶端需要訪問一個檔的時候，其首先需要訪問NameNode獲取檔資訊以及資料分佈特徵。 從NameNode獲取這些資訊之後，後期訪問檔的資料過程就不會經過NameNode，用戶端和DataNode進行直接通信。 這種分散式檔案系統的資料訪問屬於「帶外模式」，因此，可以具有很高的併發行，不同的用戶端可以訪問不同的DataNode。

這種分散式檔案系統的一個缺點在於處理小檔。 因為每次檔訪問操作都會訪問NameNode。 如果處理小檔，那麼NameNode將會被經常訪問，因此，NameNode將會成為整個系統的瓶頸。 幸運的是，在大資料應用環境下，主要的處理的是大檔，因此，這種分散式檔案系統架構可以滿足大資料應用需求。

這種分散式檔案系統具有很強的存儲可擴充性。 如果使用者想要擴展存儲容量，只需要增加一個DataNode就可以了，並且將這個DataNode加入到NameNode中進行管理。 DataNode的擴展對於用戶端而言是透明的。 DataNode的擴展一方面會擴展存儲容量，另一方面還可以擴展系統整體資料輸送量。 這種架構最大的問題在於擁有潛在瓶頸點NameNode，採用NameNode最大的好處是降低了設計實現的複雜度。

NameNode是整個系統的中繼資料伺服器，因此，性能和單點故障成為NameNode設計過程中需要考慮的首要問題。 為了提高性能，NameNode可以採用性能比較高的伺服器，並且可以採用集群的方式提高元資料處理的性能。 另外，為了避免單點故障，可以採用HA的方式增強NameNode的可靠性。 為此，很多廠商提出了各種HA的解決方案，保證NameNode可以在最短的時間內Failover，提高整個系統的服務品質和可靠性。 NameNode的設計優化是Hadoop分散式檔案系統得以應用的重點。

資料可靠性也是Hadoop分散式檔案系統需要考慮的問題。 為了降低整個系統的成本，DataNode可以採用成本低廉的伺服器搭建。 在這些伺服器中可以不採用傳統存儲中的RAID解決方案，這樣可以盡最大可能的降低單點存儲成本。 在這種沒有採用RAID的分散式檔存儲系統中如何保證資料可靠性呢? Hadoop的思路和GFS是相同的，採用多份複製的策略保證資料可靠性。 普通的檔採用3份複製的策略，重要的檔採用6份複製的策略。 在寫檔的時候，資料被寫入一個DataNode，然後這個DataNode再將複製資料寫入其他DataNode。 多份複製的好處是實現簡單，最為重要的是還可以將讀寫進行分離，並且可以併發讀請求。 多份複製的缺點也是顯而易見的，大量的資料複製導致存儲空間的利用率大為降低。 為了提高資料存儲空間利用率，在分散式存儲系統中引入Erasure Code。 Erasure Code可以實現類似傳統RAID演算法效果的資料冗余，但是，需要DataNode具有一定的資料計算能力，因此，該演算法的引入會對整個系統的寫性能造成一定影響。 另外，由於Erasurce Code將資料拆分，採用資料冗余編碼的方式達到增強資料可靠性的目的，因此，無法起到多份複製方法中讀寫分離、讀併發的目的，難免對讀性能也會造成一定影響。 存儲空間利用率和性能是互斥的，因此如何平衡這兩方面的需求是設計需要考慮的。 Facebook在Erasure Code方面做了很多工作，2013年發表了一篇針對Erasurce Code在大資料中應用的一篇文章《XORing Elephants: Novel Erasurce Codes for Big Data 》。

Hadoop分散式檔案系統是在大資料存儲系統中一種常用的結構，參照這種結構，淘寶開發了TFS用於存儲淘寶電商系統中的圖片、視頻檔，並且針對淘寶自身的特點進行了優化。 其最大的優化包括：

1)簡化NameNode檔目錄結構。 淘寶的存儲檔沒有必要採用複雜的目錄樹去管理，扁平的結構就可以滿足要求，每個檔可以使用一個64位的ID來描述即可。

2)淘寶中的圖片有大有小，對於這種小檔首先將其合併成一個大檔，最後進行大檔存儲。 這一個思路和Facebook的Haystack系統是類似的。

Hadoop分散式檔存儲系統在大資料處理中起到了一個基石的作用，後面的分散式資料處理和分散式資料庫都可以架構在Hadoop FS的基礎之上。

<待續>

本文出自 「存儲之道」 博客，請務必保留此出處HTTP://alanwu.blog.51cto.com/3652632/1416743