Hadoop教程：如何為Hadoop集群選擇合適的硬件

---

隨著Apache Hadoop的起步，云客戶的增多面臨的首要問題就是如何為他們新的的Hadoop集群選擇合適的硬件。

盡管Hadoop被設(shè)計(jì)為運(yùn)行在行業(yè)標(biāo)準(zhǔn)的硬件上，提出一個(gè)理想的集群配置不想提供硬件規(guī)格列表那么簡單。 選擇硬件，為給定的負(fù)載在性能和經(jīng)濟(jì)性提供最佳平衡是需要測試和驗(yàn)證其有效性。（比如，IO密集型工作負(fù)載的用戶將會為每個(gè)核心主軸投資更多）。

在這個(gè)博客帖子中，你將會學(xué)到一些工作負(fù)載評估的原則和它在硬件選擇中起著至關(guān)重要的作用。在這個(gè)過程中，你也將學(xué)到Hadoop管理員應(yīng)該考慮到各種因素。

結(jié)合存儲和計(jì)算

過去的十年，IT組織已經(jīng)標(biāo)準(zhǔn)化了刀片服務(wù)器和存儲區(qū)域網(wǎng)(SAN)來滿足聯(lián)網(wǎng)和處理密集型的工作負(fù)載。盡管這個(gè)模型對于一些方面的標(biāo)準(zhǔn)程序是有相當(dāng)意義 的，比如網(wǎng)站服務(wù)器，程序服務(wù)器，小型結(jié)構(gòu)化數(shù)據(jù)庫，數(shù)據(jù)移動等，但隨著數(shù)據(jù)數(shù)量和用戶數(shù)的增長，對于基礎(chǔ)設(shè)施的要求也已經(jīng)改變。網(wǎng)站服務(wù)器現(xiàn)在有了緩存 層；數(shù)據(jù)庫需要本地硬盤支持大規(guī)模地并行；數(shù)據(jù)遷移量也超過了本地可處理的數(shù)量。

大部分的團(tuán)隊(duì)還沒有弄清楚實(shí)際工作負(fù)載需求就開始搭建他們的Hadoop集群。

硬件提供商已經(jīng)生產(chǎn)了創(chuàng)新性的產(chǎn)品系統(tǒng)來應(yīng)對這些需求，包括存儲刀片服務(wù)器，串行SCSI交換機(jī)，外部SATA磁盤陣列和大容量的機(jī)架單元。然 而，Hadoop是基于新的實(shí)現(xiàn)方法，來存儲和處理復(fù)雜數(shù)據(jù)，并伴隨著數(shù)據(jù)遷移的減少。 相對于依賴SAN來滿足大容量存儲和可靠性，Hadoop在軟件層次處理大數(shù)據(jù)和可靠性。

Hadoop在一簇平衡的節(jié)點(diǎn)間分派數(shù)據(jù)并使用同步復(fù)制來保證數(shù)據(jù)可用性和容錯(cuò)性。因?yàn)閿?shù)據(jù)被分發(fā)到有計(jì)算能力的節(jié)點(diǎn)，數(shù)據(jù)的處理可以被直接發(fā)送到存儲有數(shù)據(jù)的節(jié)點(diǎn)。由于Hadoop集群中的每一臺節(jié)點(diǎn)都存儲并處理數(shù)據(jù)，這些節(jié)點(diǎn)都需要配置來滿足數(shù)據(jù)存儲和運(yùn)算的要求。

工作負(fù)載很重要嗎？

在幾乎所有情形下，MapReduce要么會在從硬盤或者網(wǎng)絡(luò)讀取數(shù)據(jù)時(shí)遇到瓶頸（稱為IO受限的應(yīng)用），要么在處理數(shù)據(jù)時(shí)遇到瓶頸（CPU受限）。排序是 一個(gè)IO受限的例子，它需要很少的CPU處理（僅僅是簡單的比較操作），但是需要大量的從硬盤讀寫數(shù)據(jù)。模式分類是一個(gè)CPU受限的例子，它對數(shù)據(jù)進(jìn)行復(fù) 雜的處理，用來判定本體。

下面是更多IO受限的工作負(fù)載的例子：

• 索引

• 分組

• 數(shù)據(jù)導(dǎo)入導(dǎo)出

• 數(shù)據(jù)移動和轉(zhuǎn)換

下面是更多CPU受限的工作負(fù)載的例子：

• 聚類/分類

• 復(fù)雜文本挖掘

• 自然語言處理

• 特征提取

Cloudera 的客戶需要完全理解他們的工作負(fù)載，這樣才能選擇最優(yōu)的Hadoop硬件，而這好像是一個(gè)雞生蛋蛋生雞的問題。大多數(shù)工作組在沒有徹底剖 析他們的工作負(fù)載時(shí)，就已經(jīng)搭建好了Hadoop集群，通常Hadoop運(yùn)行的工作負(fù)載隨著他們的精通程度的提高而完全不同。而且，某些工作負(fù)載可能會被 一些未預(yù)料的原因受限。例如，某些理論上是IO受限的工作負(fù)載卻最終成為了CPU受限，這是可能是因?yàn)橛脩暨x擇了不同的壓縮算法，或者算法的不同實(shí)現(xiàn)改變 了MapReduce任務(wù)的約束方式。基于這些原因，當(dāng)工作組還不熟悉要運(yùn)行任務(wù)的類型時(shí)，深入剖析它才是構(gòu)建平衡的Hadoop集群之前需要做的最合理 的工作。

接 下來需要在集群上運(yùn)行MapReduce基準(zhǔn)測試任務(wù)，分析它們是如何受限的。完成這個(gè)目標(biāo)最直接的方法是在運(yùn)行中的工作負(fù)載中的適當(dāng)位置添加監(jiān)視器來 檢測瓶頸。我們推薦在Hadoop集群上安裝Cloudera Manager，它可以提供CPU，硬盤和網(wǎng)絡(luò)負(fù)載的實(shí)時(shí)統(tǒng)計(jì)信息。（Cloudera Manager是Cloudera 標(biāo)準(zhǔn)版和企業(yè)版的一個(gè)組件，其中企業(yè)版還支持滾動升級）Cloudera Manager安裝之后，Hadoop管理員就可以運(yùn)行MapReduce任務(wù)并且查看Cloudera Manager的儀表盤，用來監(jiān)測每臺機(jī)器的工作情況。

第一步是弄清楚你的作業(yè)組已經(jīng)擁有了哪些硬件

在 為你的工作負(fù)載構(gòu)建合適的集群之外，我們建議客戶和它們的硬件提供商合作確定電力和冷卻方面的預(yù)算。由于Hadoop會運(yùn)行在數(shù)十臺，數(shù)百臺到數(shù)千臺節(jié) 點(diǎn)上。通過使用高性能功耗比的硬件，作業(yè)組可以節(jié)省一大筆資金。硬件提供商通常都會提供監(jiān)測功耗和冷卻方面的工具和建議。

為你的CDH(Cloudera distribution for Hadoop) Cluster選擇硬件

選 擇機(jī)器配置類型的第一步就是理解你的運(yùn)維團(tuán)隊(duì)已經(jīng)在管理的硬件類型。在購買新的硬件設(shè)備時(shí)，運(yùn)維團(tuán)隊(duì)經(jīng)常根據(jù)一定的觀點(diǎn)或者強(qiáng)制需求來選擇，并且他們傾 向于工作在自己業(yè)已熟悉的平臺類型上。Hadoop不是唯一的從規(guī)模效率上獲益的系統(tǒng)。再一次強(qiáng)調(diào)，作為更通用的建議，如果集群是新建立的或者你并不能準(zhǔn) 確的預(yù)估你的極限工作負(fù)載，我們建議你選擇均衡的硬件類型。

Hadoop集群有四種基本任務(wù)角色:名稱節(jié)點(diǎn)（包括備用名稱節(jié)點(diǎn)），工作追蹤節(jié)點(diǎn)，任務(wù)執(zhí)行節(jié)點(diǎn)，和數(shù)據(jù)節(jié)點(diǎn)。節(jié)點(diǎn)是執(zhí)行某一特定功能的工作站。大部分你的集群內(nèi)的節(jié)點(diǎn)需要執(zhí)行兩個(gè)角色的任務(wù)，作為數(shù)據(jù)節(jié)點(diǎn)（數(shù)據(jù)存儲）和任務(wù)執(zhí)行節(jié)點(diǎn)（數(shù)據(jù)處理）。

這是在一個(gè)平衡Hadoop集群中，為數(shù)據(jù)節(jié)點(diǎn)/任務(wù)追蹤器提供的推薦規(guī)格：

• 在一個(gè)磁盤陣列中要有12到24個(gè)1~4TB硬盤

• 2個(gè)頻率為2~2.5GHz的四核、六核或八核CPU

• 64~512GB的內(nèi)存

• 有保障的千兆或萬兆以太網(wǎng)（存儲密度越大，需要的網(wǎng)絡(luò)吞吐量越高）

名字節(jié)點(diǎn)角色負(fù)責(zé)協(xié)調(diào)集群上的數(shù)據(jù)存儲，作業(yè)追蹤器協(xié)調(diào)數(shù)據(jù)處理（備用的名字節(jié)點(diǎn)不應(yīng)與集群中的名字節(jié)點(diǎn)共存，并且運(yùn)行在與之相同的硬件環(huán)境上。）。 Cloudera推薦客戶購買在RAID1或10配置上有足夠功率和企業(yè)級磁盤數(shù)的商用機(jī)器來運(yùn)行名字節(jié)點(diǎn)和作業(yè)追蹤器。

NameNode也會直接需要與群集中的數(shù)據(jù)塊的數(shù)量成比列的RAM。一個(gè)好的但不精確的規(guī)則是對于存儲在分布式文件系統(tǒng)里面的每一個(gè)1百萬的數(shù)據(jù)塊，分 配1GB的NameNode內(nèi)存。于在一個(gè)群集里面的100個(gè)DataNodes而言，NameNode上的64GB的RAM提供了足夠的空間來保證群集 的增長。我們也推薦把HA同時(shí)配置在NameNode和JobTracker上，

這里就是為NameNode／JobTracker／Standby NameNode節(jié)點(diǎn)群推薦的技術(shù)細(xì)節(jié)。驅(qū)動器的數(shù)量或多或少，將取決于冗余數(shù)量的需要。

• 4–6 1TB 硬盤驅(qū)動器 采用 一個(gè) JBOD 配置 (1個(gè)用于OS, 2個(gè)用于文件系統(tǒng)映像[RAID 1], 1個(gè)用于Apache ZooKeeper, 1個(gè)用于Journal節(jié)點(diǎn))

• 2 4-/16-/8-核心 CPUs, 至少運(yùn)行于 2-2.5GHz

• 64-128GB 隨機(jī)存儲器

• Bonded Gigabit 以太網(wǎng)卡 or 10Gigabit 以太網(wǎng)卡

記住, 在思想上，Hadoop 體系設(shè)計(jì)為用于一種并行環(huán)境。

如果你希望Hadoop集群擴(kuò)展到20臺機(jī)器以上，那么我們推薦最初配置的集群應(yīng)分布在兩個(gè)機(jī)架，而且每個(gè)機(jī)架都有一個(gè)位于機(jī)架頂部的10G的以太網(wǎng)交 換。當(dāng)這個(gè)集群跨越多個(gè)機(jī)架的時(shí)候，你將需要添加核心交換機(jī)使用40G的以太網(wǎng)來連接位于機(jī)架頂部的交換機(jī)。兩個(gè)邏輯上分離的機(jī)架可以讓維護(hù)團(tuán)隊(duì)更好地理 解機(jī)架內(nèi)部和機(jī)架間通信對網(wǎng)絡(luò)需求。

Hadoop 集群安裝好后，維護(hù)團(tuán)隊(duì)就可以開始確定工作負(fù)載，并準(zhǔn)備對這些工作負(fù)載進(jìn)行基準(zhǔn)測試以確定硬件瓶頸。經(jīng)過一段時(shí)間的基準(zhǔn)測試和監(jiān)視，維護(hù)團(tuán)隊(duì) 將會明白如何配置添加的機(jī)器。異構(gòu)的Hadoop集群是很常見的，尤其是在集群中用戶機(jī)器的容量和數(shù)量不斷增長的時(shí)候更常見-因此為你的工作負(fù)載所配置的 “不理想”開始時(shí)的那組機(jī)器不是在浪費(fèi)時(shí)間。Cloudera管理器提供了允許分組管理不同硬件配置的模板，通過這些模板你就可以簡單地管理異構(gòu)集群了。

下面是針對不同的工作負(fù)載所采用對應(yīng)的各種硬件配置的列表，包括我們最初推薦的“負(fù)載均衡”的配置：

• 輕量處理方式的配置(1U的機(jī)器）:兩個(gè)16核的CPU，24-64GB的內(nèi)存以及8張硬盤（每張1TB或者2TB)。

• 負(fù)載均衡方式的配置(1U的機(jī)器）:兩個(gè)16核的CPU，48-128GB的內(nèi)存以及由主板控制器直接連接的12-16張硬盤（每張1TB或者2TB)。通常在一個(gè)2U的柜子里使用2個(gè)主板和24張硬盤實(shí)現(xiàn)相互備份。

• 超大存儲方式的配置(2U的機(jī)器）:兩個(gè)16核的CPU，48-96GB的內(nèi)存以及16-26張硬盤（每張2TB-4TB)。這種配置在多個(gè)節(jié)點(diǎn)/機(jī)架失效時(shí)會產(chǎn)生大量的網(wǎng)絡(luò)流量。

• 強(qiáng)力運(yùn)算方式的配置(2U的機(jī)器）:兩個(gè)16核的CPU，64-512GB的內(nèi)存以及4-8張硬盤（每張1TB或者2TB)。

（注意Cloudera期望你配置它可以使用的2×8,2×10和2×12核心CPU的配置。)

下圖向你展示了如何根據(jù)工作負(fù)載來配置一臺機(jī)器：

其他要考慮的

記 住Hadoop生態(tài)系統(tǒng)的設(shè)計(jì)是考慮了并行環(huán)境這點(diǎn)非常重要。當(dāng)購買處理器時(shí)，我們不建議購買最高頻率(GHZ)的芯片，這些芯片都有很高的功耗 （130瓦以上）。這么做會產(chǎn)生兩個(gè)問題：電量消耗會更高和熱量散發(fā)會更大。處在中間型號的CPU在頻率、價(jià)格和核心數(shù)方面性價(jià)比是最好的。

當(dāng)我們碰到生成大量中間數(shù)據(jù)的應(yīng)用時(shí)-也就是說輸出數(shù)據(jù)的量和讀入數(shù)據(jù)的量相等的情況-我們推薦在單個(gè)以太網(wǎng)接口卡上啟用兩個(gè)端口，或者捆綁兩個(gè)以太網(wǎng) 卡，讓每臺機(jī)器提供2Gbps的傳輸速率。綁定2Gbps的節(jié)點(diǎn)最多可容納的數(shù)據(jù)量是12TB。一旦你傳輸?shù)臄?shù)據(jù)超過12TB，你將需要使用傳輸速率為捆 綁方式實(shí)現(xiàn)的4Gbps(4x1Gbps)。另外，對哪些已經(jīng)使用10Gb帶寬的以太網(wǎng)或者無線網(wǎng)絡(luò)用戶來說，這樣的方案可以用來按照網(wǎng)絡(luò)帶寬實(shí)現(xiàn)工作負(fù) 載的分配。如果你正在考慮切換到10GB的以太網(wǎng)絡(luò)上，那么請確認(rèn)操作系統(tǒng)和BIOS是否兼容這樣的功能。

當(dāng)計(jì)算需要多少內(nèi)存的時(shí)候，記住Java本身要使用高達(dá)10%的內(nèi)存來管理虛擬機(jī)。我們建議把Hadoop配置為只使用堆，這樣就可以避免內(nèi)存與磁盤之間 的切換。切換大大地降低MapReduce任務(wù)的性能，并且可以通過給機(jī)器配置更多的內(nèi)存以及給大多數(shù)Linux發(fā)布版以適當(dāng)?shù)膬?nèi)核設(shè)置就可以避免這種切 換。

優(yōu)化內(nèi)存的通道寬度也是非常重要的。例如，當(dāng)我們使用雙通道內(nèi)存時(shí)，每臺機(jī)器就應(yīng)當(dāng)配置成對內(nèi)存模塊（DIMM）。當(dāng)我們使用三通道的內(nèi)存時(shí)，每臺機(jī)器都應(yīng)當(dāng)使用三的倍數(shù)個(gè)內(nèi)存模塊（DIMM）。類似地，四通道的內(nèi)存模塊（DIMM)就應(yīng)當(dāng)按四來分組使用內(nèi)存。

超越MapReduce

Hadoop 不僅僅是HDFS和MapReduce；它是一個(gè)無所不包的數(shù)據(jù)平臺。因此CDH包含許多不同的生態(tài)系統(tǒng)產(chǎn)品（實(shí)際上很少僅僅做為 MapReduce使用）。當(dāng)你在為集群選型的時(shí)候，需要考慮的附加軟件組件包括Apache HBase、Cloudera Impala和Cloudera Search。它們應(yīng)該都運(yùn)行在DataNode中來維護(hù)數(shù)據(jù)局部性。

HBase 是一個(gè)可靠的列數(shù)據(jù)存儲系統(tǒng)，它提供一致性、低延遲和隨機(jī)讀寫。Cloudera Search解決了CDH中存儲內(nèi)容的全文本搜索的需求，為新類型用戶簡化了訪問，但是也為Hadoop中新類型數(shù)據(jù)存儲提供了機(jī)會。Cloudera Search基于Apache Lucene/Solr Cloud和Apache Tika，并且為與CDH廣泛集成的搜索擴(kuò)展了有價(jià)值的功能和靈活性。基于Apache協(xié)議的Impala項(xiàng)目為Hadoop帶來了可擴(kuò)展的并行數(shù)據(jù)庫技 術(shù)，使得用戶可以向HDFS和HBase中存儲的數(shù)據(jù)發(fā)起低延遲的SQL查詢，而且不需要數(shù)據(jù)移動或轉(zhuǎn)換。

由于垃圾回收器（GC）的超時(shí)，HBase 的用戶應(yīng)該留意堆的大小的限制。別的JVM列存儲也面臨這個(gè)問題。因此，我們推薦每一個(gè)區(qū)域服務(wù)器的堆最大不超過16GB。HBase不需要太多別的資源 而運(yùn)行于Hadoop之上，但是維護(hù)一個(gè)實(shí)時(shí)的SLAs，你應(yīng)該使用多個(gè)調(diào)度器，比如使用fair and capacity 調(diào)度器，并協(xié)同Linux Cgroups使用。

 Impala 使用內(nèi)存以完成其大多數(shù)的功能，在默認(rèn)的配置下，將最多使用80％的可用RAM資源，所以我們推薦，最少每一個(gè)節(jié)點(diǎn)使用96GB的RAM。與 MapReduce一起使用Impala的用戶，可以參考我們的建議 － “Configuring Impala and MapReduce for Multi-tenant Performance.” 也可以為Impala指定特定進(jìn)程所需的內(nèi)存或者特定查詢所需的內(nèi)存。

搜 索是最有趣的訂制大小的組件。推薦的訂制大小的實(shí)踐操作是購買一個(gè)節(jié)點(diǎn)，安裝Solr和Lucene，然后載入你的文檔群。一旦文檔群被以期望的方式來 索引和搜索，可伸縮性將開始作用。持續(xù)不斷的載入文檔群，直到索引和查詢的延遲，對于項(xiàng)目而言超出了必要的數(shù)值 － 此時(shí)，這讓你得到了在可用的資源上每一個(gè)節(jié)點(diǎn)所能處理的最大文檔數(shù)目的基數(shù)，以及不包括欲期的集群復(fù)制此因素的節(jié)點(diǎn)的數(shù)量總計(jì)基數(shù)。

結(jié)論

購 買合適的硬件，對于一個(gè)Hapdoop群集而言，需要性能測試和細(xì)心的計(jì)劃，從而全面理解工作負(fù)荷。然而，Hadoop群集通常是一個(gè)形態(tài)變化的系統(tǒng)， 而Cloudera建議，在開始的時(shí)候，使用負(fù)載均衡的技術(shù)文檔來部署啟動的硬件。重要的是，記住，當(dāng)使用多種體系組件的時(shí)候，資源的使用將會是多樣的， 而專注與資源管理將會是你成功的關(guān)鍵。

來源：馬哥linux運(yùn)維