Hadoop 和云似乎是***搭檔。它們都包含靈活和分布式的處理與存儲，而且都帶有一個靈活的實例系統。它們還使您能夠根據數據和處理需求來擴大和收縮 Hadoop 集群。但這會引發各種管理與調度問題。本文將了解所有這些問題，并描述基于云的 Hadoop 部署的挑戰與優勢。

了解云部署的范圍

Hadoop 系統是一個用起來頗有挑戰性的環境，但由于云環境所具有的限制（與自由），云部署會引入額外的復雜性。

例如，借助云中的 Hadoop，如何處理可變的集群規模與信息的有效分布？如何有效地擴大和收縮云環境，以便應付您期望處理的 Hadoop 負載？如何計劃和控制任務與處理，以便在云實例可用時***限度地利用它們？

根據具體云服務的不同，云部署的優勢與劣勢會對這些環境中 Hadoop 的使用產生相應的影響。請記住，與公有云相比，私有云服務的約束與限制存在巨大差異。如果使用自己的 VM 環境或諸如 OpenStack 這樣的解決方案時，那么您將擁有極大的靈活性來定制服務與功能。

為了讓云中的 Hadoop 發揮***功效，您首先需要了解已經存在的云部署解決方案，以及它們對于 Hadoop 環境有哪些影響。

基于服務的云部署

某些云解決方案完全基于某個特定服務，該服務將會加載并處理數據。例如，借助 IBM Bluemix®，您可以基于 IBM InfoSphere® BigInsights™ 配置一個 MapReduce 服務，該服務可以處理高達 20GB 的信息。但 Hadoop 服務的大小、配置與復雜性是不可配置的。其他基于服務的解決方案也提供同樣類別的復雜性。

您必須根據自己的需要來選擇或配置服務解決方案的大小，因為您可能無法控制磁盤、I/O、CPU 或 RAM 的可用性。

確定需求的惟一途徑就是通過測試。在計算結果上再增加 25% 或更高，以便為使用率***和最復雜的情況留出余地。

基于（虛擬）機器的云部署

盡管云環境完全基于機器或虛擬機風格的部署，Hadoop 在虛擬環境中的安裝方式與在物理機器上極為相似。您可以對可配置參數的范圍進行配置，而這些參數會改變您針對集群部署的選擇。

每個節點的配置尤其需要認真考慮，包括 CPU、RAM、磁盤容量和磁盤 I/O 速度。盡管優秀的 Hadoop 集群部署可以隱藏節點之間的鏡像差異，但在需要標準支持和提高速度與運算能力時，了解配置可以幫助您調整部署的規模。

和所有基于云的系統或安裝部署一樣，配置取決于以下因素：

CPU

精確的 CPU 計算或任意單元。除非部署的是基于 YARN 的解決方案，否則應考慮為集群內所有的數據與處理節點部署完全相同的配置。這種方法讓計算所需的集群規模與容量變得更輕松。針對基于 YARN 的部署，可以將集群內不同節點配置為支持和處理不同級別的 CPU 容量。例如，這種方法可以使用指定項目的特定高性能 CPU 節點組來擴展現有集群。

RAM

所有節點都至少應該擁有 4GB 空間，但此空間的大小可能會受到實際可用空間的限制。此外還要記住，一定要留出一些空間用于文件緩存，這樣可以提高性能。有些解決方案（如 HBase）可以使用額外的內存。

存儲器容量

確保對操作系統和 Hadoop 存儲使用了單獨的卷，這種實踐可以提高性能并讓擴展 HDFS 存儲變得更簡單。在縮放集群大小之前，應估計要使用的存儲容量，并標準化指定的大小。這種方法可確保在整個集群上實現***程度的平均分布。

磁盤 I/O

HDFS 環境應該限制磁盤 I/O 的暴露，因為所有工作都分布在集群上。然而在沒有必要的情況下，不要將磁盤 I/O 限制到節點無法有效訪問和處理數據的程度。在眾多云環境中，基準或***的磁盤 I/O 配置可能過低，甚至降低了總體性能。更糟糕的是，如果無法確保磁盤 I/O 速率位于某個特定水平上，那么在處理任務的過程中，可能會遭遇性能下降。

網絡 I/O

Hadoop 需要進行大量的網絡 I/O 才能完成操作；除了原始寫入之外，每個文件都至少被復制兩次，而且 MapReduce 操作期間使用的數據都必須采用類似的方式通過網絡進行傳輸。在眾多云環境中，網絡性能是受限的，這可能成為部署中的一個限制因素。

混合型云部署

在一些混合型云部署中，有些元素是固定的，而其他元素是可變的。在這種情況下，您可以在某些限制下定義特定的機器容量，同時控制節點的總體數量。在這些 Hadoop 云部署中，選擇正確的 RAM 與 CPU 組合，然后調整集群，使之滿足這種配置。

#p#

擴展與收縮 Hadoop 集群

云環境最吸引人的方面之一就是能夠擴展和收縮 Hadoop 集群的規模，使之滿足將要提交的任務對于負載與存儲的要求。在以基于服務架構為基礎的云環境中，擴展與收縮通常是通過云服務的控制部分進行管理的。

擴展集群通常很容易，因為通過給現有配置增加更多節點，就可以更加輕松地使用額外的資源。收縮集群困難一些，有可能會導致性能受損和任務中斷。

根據您選擇的云環境，用于增加或減少 Hadoop 集群規模的具體方法也會有所不同。基于服務的云環境有一些內置的伸縮功能。基于虛擬機的單元需要在集群內進行部署、安裝軟件和授權。

使用有彈性的 Hadoop 集群

真正有彈性的 Hadoop 集群需要大量的工作與管理。即便是啟動云服務，大量增加節點，稍后再刪除它們，實際的數據增加與管理工作也會很復雜。

大問題在于，對于要以***效率處理問題的集群而言，真正需要做的是將數據與工作負載分布到集群上。

此外，還要考慮這些處理所花費的時間。甚至在最理想的情況下，啟動每個節點并讓它們開始處理工作的過程需要花費 5 到 10 分鐘。

收縮規模一直是更為復雜的問題，因為必須避免可能保存同一數據塊的所有副本的節點停止運行。為了縮小集群的規模，必須首先執行再次平衡，確定數據被正確存儲，而且數據副本分布在余下的節點上，如果需要再次縮小規模，只需重復以上過程即可。

擴展 Hadoop 集群

使用新節點擴展集群是一種常見的需求，過程也很簡單。通常，在云環境中增加節點時，新節點的大小與容量與現有節點相同。這種方法有助于未來的容量規劃。這條通用規則不適用于以下情形：

在您計劃使用更多空間、CPU 或 RAM 容量升級節點時。

在集群到達 80% 容量之前擴展集群時。僅在當前容量達到 80% 時才增加節點數量。被動等待擴展集群可能會導致容量不夠用。

決定增加更多節點后，實際的過程則十分簡單：

• 向云環境添加新節點。
• 在每個新節點上安裝 Hadoop。（從鏡像獲取一個預先安裝好的節點是最容易的方式。）
• 在主節點上的 conf/slaves 文件中添加新節點的信息。
• 啟動如 清單 1 中所示的 Hadoop 流程。

清單 1. 啟動 Hadoop 流程

$ hadoop-daemon.sh start datanode 
$ hadoop-daemon.sh start tasktracker 

 不同的 Hadoop 變體可能有不同的步驟，但這些屬于基本步驟。您可能還想確保主節點通過檢查 dfs.hosts 配置能夠正確識別它們。為了檢查它們是否被正確識別，可以運行 清單 2 中的代碼。

清單 2. 確保 Hadoop 變體被正確識別

$ hadoop mradmin -refreshNodes 
$ hadoop dfsadmin -refreshNodes 

這段代碼針對 MapReduce 任務處理來設置節點，但沒有移動任何現有數據。下一步驟是確保移動文件塊。

重新分布已存儲的數據塊

可以在集群內移動已存儲的數據塊，以便更好地使用增加的節點，移動的方法有如下幾種：

將文件復制到不同的目錄。這項操作將自動重新分布數據塊，因為文件被有效重寫到 HDFS 中。這個步驟需要額外的工作，但它可以與工作流同時執行。
臨時增加復制容量。默認值為 3。將這個值提高到 4 將向集群添加新的數據塊副本。將這個值減少為 3 將從某些機器上移除數據塊。
顯式啟動一次調整操作：

$ start-balancer.sh 

 請記住，啟動任意類型的調整操作都需要大量的 I/O 與網絡傳輸，直到調整完成為止。

收縮 Hadoop 集群

收縮 Hadoop 集群時要考慮以下因素：

• 是否能安全地縮小集群規模？ 如果有任務正在運行，在每個節點上運行一次停止運行過程（decommission process）。此過程將刪除節點并以可重新開始的方式停止所有正在運行的任務（使用狀態 KILLED_UNCLEAN），這樣當下次檢查隊列并且 JobTracker 重新分配任務時，就可以在可用節點上重新安排任務執行。
• 是否能夠在其他節點上釋放空間？請記住，縮小集群規模就是減少用于復制數據的計算機數量，并提高剩余節點上的磁盤使用。

注意： 一次停止運行的節點絕不能超過一個。

云環境的魅力在于，可以在 100 個節點的集群中啟動 20 個新節點來應對高峰，稍后便可移除它們。這種方法使得集群面臨較少的風險，甚至可能完全移除已存儲數據的風險。停止運行過程會自動在余下節點中重新分布數據副本。盡管可以減少大的數據塊，但這樣做會給系統帶來很大的負載。但會減少多個數據塊中的節點。

停止運行的最安全方法是分階段完成停止運行過程。例如，如果要移除 20 個節點，每次停止運行 3 到 5 個節點：

將要移除的節點從集群添加到 dfs.hosts.exclude 設置。

運行 dfs 刷新來更新節點列表：

$ hadoop dfsadmin -refreshNodes 

 刷新 MapReduce 配置：

$ hadoop mradmin -refreshNodes 

 節點現在被標記為已停止運行。在節點最終停止運行并安全移除機器之前，要將數據副本復制到其他集群中的其他主機。

現在，對每個額外的數據塊重復這些步驟。通常，此過程花費的時間要長于擴展過程，但它消除了數據丟失的風險。

升級節點配置

云環境的主要優勢之一是可以靈活地修改單獨節點配置，甚至可以根據需要完全更新和替換節點。您可以分階段地完成這些修改，將前面描述的擴展和收縮過程合二為一。您甚至可以將這個過程作為針對特定任務的計劃擴展與收縮過程的一個組成部分。

例如，要將 20 個數據節點從 4 CPU 系統變為 8 CPU 系統，可以執行以下步驟：

• 添加 4 個具有新配置的新節點。
• 將它們添加到配置。
• 啟動服務。
• 執行調整。
• 從舊配置停止運行 4 個數據節點
• 重復這些步驟。

結果是獲得了一個首先通過添加新配置節點進行擴展，然后通過移除舊配置節點進行收縮的集群。

#p#

任務調度與分布

根據任務調度需要確定擴展與收縮集群的時間，以及處理該過程所需的容量大小。

借助云模型，您有時可以使用多個單獨的集群代替一個大型集群，從中獲得一些優勢。您可以根據數據復雜性和集群規模來調度工作。例如，一個較大的處理任務可能需要更多的節點，但需要的存儲較少，而其他任務可能需要更多的存儲，但需要的處理節點較少。

在云中進行處理時，嘗試在***化集群配置的同時不擴展或增加集群規模。很多工具都能做到這一點，包括基本的任務調度和使用復雜的工作流，比如 IBM InfoSphere BigInsights 中的應用程序管理器和 Oozie。我們的目標是在不增加成本的情況下讓集群獲得***性能，并確保不會讓集群過載到無法輕松擴展或恢復的程度。

應對存儲與負載高峰

最復雜的過程很可能是了解如何應對突如其來的存儲與負載高峰。根據部署環境，可用的選擇可能有很大差異。對于您可以改變的一些因素，當您意識到集群已經超出容量時，您會怎樣做？

顯著的觀點是從一開始就嘗試避免這個特定問題。您可能希望時刻關注容量，并確保留出 20% 到 30% 的容量來處理工作。運行容量超過 80% 時會帶來一些麻煩。

確定需求

首先確定是否需要增加磁盤或 MapReduce 容量。這二者具有不同的屬性。二者的做法均是為了添加更多的節點，添加更多的節點通常可以解決問題，但其代價可能是不必要的。

如果問題是在存儲上，那么可以考慮給現有節點增加更多的存儲設備。有些云環境能夠在不重新引導或修改系統的情況下提供這個選項。在這種情況下，可以將 dfs.datanode.data.dir 配置更新為包含新掛載的目錄。這個選項始終比使用新節點擴展集群要快得多，也容易得多。

如果屬于長期問題，則應該考慮 增加節點和使用擁有更大容量的節點替換一些現有的節點。從長遠角度看，這是一項值得的投資，因為這樣做可以防止在未來面臨高峰時出現更多的問題。

如果需要 CPU 能力，但是只愿意等待存儲需求而不愿意進行調整，那么可以添加新的節點，安裝 Hadoop，然后啟動數據節點與任務跟蹤器過程，但不執行任何調整。

確定是否能通過足夠快地擴展（和收縮）來達到效果

如果與任務的計劃長度相比，高峰期較短，那么可能不值得添加節點，因為創建新主機所花費的時間比處理任務還要長。

盡管不存在通用規則，但要牢記，云部署或許能夠將節點容量提高 10%，甚至是 100%，但以完全線性的方式來看它可能不會提高性能，特別是在云環境中。

如果任務的預計運行時間是 6 小時，而您可以在不到一小時內將集群的規模有效提高 50%，那么擴展集群是值得的。

當高峰結束時是否也能夠及時收縮？

考慮高峰結束時收縮規模所需的時間長短。收縮需要花費額外的時間來完成停止運行過程，并將數據塊重新分布到集群的余下節點上。圖 1 顯示了同一任務在 10 個節點上運行，然后在更多節點上運行的大約時間，其中包括向集群添加節點和讓節點停止運行的時間，所有時間的測量單位均為小時。

從這張圖中可以看出，增加 5 個節點很快，將集群規模擴展三倍很簡單，但在節點停止運行時額外花費了 2.5 小時的時間。此過程最終僅節省了一個小時，但成本卻變為原來的三倍。

結束語

在云中部署 Hadoop 需要了解云環境的限制，并能夠根據需要動態地擴展和收縮集群規模的優點。但靈活的特性不代表沒有缺陷。因此，有效的 Hadoop 部署需要您了解運行任務，以及擴展和收縮過程所需的時間長短，從而將云中任務執行的時間縮至最短。

原文鏈接：http://www.ibm.com/developerworks/cn/data/library/ba/ba-hadoop-in-cloud/index.html