當我們想搭建一個Hadoop大數(shù)據(jù)平臺時，碰到的第一個問題就是我們到底該如何選擇硬件。

雖然Hadoop被設計為可以運行在標準的X86硬件上，但在選擇具體服務器配置的時候其實沒那么簡單。為已知的工作負載或者應用場景選擇硬件時，往往都要綜合考慮性能因素和性價比，才能選擇合適的硬件。比如，對于IO密集型的工作負載，用戶往往需要為每個CPU core匹配更多的存儲或更高的吞吐(more spindles per core)。

通過本文，您將學習到如何根據(jù)工作負載來選擇硬件，包括一些其他您需要考慮的因素。

[[209201]]

1.計算和存儲

過去的十年，業(yè)界基本已經(jīng)形成了刀片和SANs(Storage Area Networks)的標準，從而滿足網(wǎng)格和處理密集型的工作負載。這種模式對于許多標準應用(比如Web服務器，應用服務器，較小的結構化數(shù)據(jù)和數(shù)據(jù)搬運)還都是適用的，但是隨著數(shù)據(jù)量和用戶數(shù)據(jù)的增長，基礎設施的需求也發(fā)生了變化。Web服務器現(xiàn)在已經(jīng)有了緩存層，數(shù)據(jù)庫借助本地磁盤開始支持海量并發(fā)，數(shù)據(jù)搬運的壓力迫使我們需要更多的在本地處理數(shù)據(jù)。

“很多人在搭建Hadoop集群時都沒有去真正了解過工作負載”

硬件供應商更新了對應的產(chǎn)品來滿足相應的需求，包括存儲刀片，SAS(Serial Attached SCSI)交換機，外掛的SATA陣列和容量更大的機架。然而，Hadoop是基于一個全新的存儲和處理數(shù)據(jù)的方式，盡量避免數(shù)據(jù)傳輸。Hadoop通過軟件層來實現(xiàn)大數(shù)據(jù)的處理以及可靠性，而不像一個SAN存儲所有數(shù)據(jù)，如果計算則傳輸?shù)揭幌盗械镀M行計算。

Hadoop將數(shù)據(jù)分布式存儲在各臺服務器上，使用文件副本來保證數(shù)據(jù)不丟以及容錯。這樣一個計算請求可以直接分發(fā)到存儲數(shù)據(jù)的相應服務器并開始進行本地計算。由于Hadoop集群的每臺節(jié)點都會存儲和處理數(shù)據(jù)，所以你就需要考慮怎樣為集群里的這些服務器選擇合適的配置。

2.為什么跟工作負載有關系

在很多情況下，MapReduce/Spark都會遭遇瓶頸，比如從磁盤或者網(wǎng)絡讀取數(shù)據(jù)(IO-bound的作業(yè))，或者在CPU處理大量數(shù)據(jù)時(CPU-bound的作業(yè))。IO-bound的作業(yè)的一個例子是排序，一般需要很少的處理(簡單的比較)卻需要大量的讀寫磁盤。CPU-bound的作業(yè)的一個例子是分類(classification)，一些數(shù)據(jù)往往需要很復雜的處理。

典型的IO-bound的工作負載如下：

• 索引(Indexing)
• 分組(Grouping)
• 數(shù)據(jù)導入導出
• 數(shù)據(jù)傳輸和轉換

典型的CPU-bound工作負載如下：

• 聚類和分類(Clustering/Classification)
• 復雜的文本挖掘
• 自然語言處理
• 特征提取

我們需要完全了解工作負載，才能夠正確的選擇合適的Hadoop硬件。很多人因為從來沒有研究過工作負載，往往會導致Hadoop運行的作業(yè)是基于不合適的硬件。此外，一些工作負載往往會受到一些其他的限制。比如因為選擇了壓縮，本應該是IO-bound的工作負載實際卻是CPU-bound的，或者因為算法選擇不同而使MapReduce或者Spark作業(yè)受限。由于這些原因，當您不熟悉未來將要運行的工作負載時，可以選擇一些較為均衡的硬件配置來搭建Hadoop集群。

接下來我們就可以在集群中運行一些MapReduce/Spark作業(yè)進行基準測試，來分析它們的bound方式?？梢酝ㄟ^一些監(jiān)控工具來確定工作負載的瓶頸。當然Cloudera Manager提供了這個功能，包括CPU，磁盤和網(wǎng)絡負載的實時統(tǒng)計信息。通過Cloudera Manager，當集群在運行作業(yè)時，系統(tǒng)管理員可以通過dashboard很直觀的查看每臺機器的性能表現(xiàn)。

“第一步是了解運維部門管理的硬件。”

除了根據(jù)工作負載來選擇硬件外，還可以與硬件廠商一起了解耗電和散熱以節(jié)省額外的開支。由于Hadoop是運行在數(shù)十，數(shù)百甚至數(shù)千個節(jié)點上，盡可能多的考慮方方面面都可以節(jié)省成本。每個硬件廠商都提供了專門的工具來監(jiān)控耗電和散熱，以及如何改良的最佳實踐。

3.為CDH集群挑選硬件

在挑選硬件的時候，第一步是了解您的運維部門所管理的硬件類型。運維部門往往傾向于選擇他們熟悉的硬件。但是，如果您是在搭建一個新的集群，并且無法準確的預測集群未來的工作負載，我們建議您還是選擇適合Hadoop較為均衡的硬件。

一個Hadoop集群通常有4個角色：NameNode(和Standby NameNode)，ResourceManager，NodeManager和DataNode。集群中的絕大多數(shù)機器同時是NodeManager和DataNode，既用于數(shù)據(jù)存儲，又用于數(shù)據(jù)處理。

以下是較為通用和主流的NodeManager/DataNode配置：

• 12-24塊1-6TB硬盤， JBOD (Just a Bunch Of Disks)
• 2 路8核，2路10核，2路12核的CPU, 主頻至少2-2.5GHz
• 64-512GB內(nèi)存
• 綁定的萬兆網(wǎng) (存儲越多，網(wǎng)絡吞吐就要求越高)

NameNode負責協(xié)調集群上的數(shù)據(jù)存儲，ResourceManager則是負責協(xié)調數(shù)據(jù)處理。Standby NameNode不應該與NameNode在同一臺機器，但應該選擇與NameNode配置相同的機器。我們建議您為NameNode和ResourceManager選擇企業(yè)級的服務器，具有冗余電源，以及企業(yè)級的RAID1或RAID10磁盤配置。

NameNode需要的內(nèi)存與集群中存儲的數(shù)據(jù)塊成正比。我們常用的計算公式是集群中100萬個塊(HDFS blocks)對應NameNode的1GB內(nèi)存。常見的10-50臺機器規(guī)模的集群，NameNode服務器的內(nèi)存配置一般選擇128GB，NameNode的堆棧一般配置為32GB或更高。另外建議務必配置NameNode和ResourceManager的HA。

以下是NameNode/ResourceManager及其Standby節(jié)點的推薦配置。磁盤的數(shù)量取決于你想冗余備份元數(shù)據(jù)的份數(shù)。

• 4–6個1TB的硬盤，JBOD(1個是OS, 2個是NameNode的FS image [RAID 1], 1個配置給Apache ZooKeeper, 還一個是配置給Journal node)
• 2路6核，2路8核的CPU, 主頻至少2-2.5GHz
• 64-256GB的內(nèi)存
• 綁定的萬兆網(wǎng)

“記住，Hadoop生態(tài)系統(tǒng)的設計需考慮并行環(huán)境。”

如果預期你的Hadoop集群未來會超過20臺機器，建議集群初始規(guī)劃就跨兩個機架，每個機柜都配置柜頂(TOR,top-of-rack)的10GigE交換機。隨著集群規(guī)模的擴大，跨越多個機架時，我們在機架之上還要配置冗余的核心交換機，帶寬一般為40GigE，用來連接所有機柜的柜頂(TOR)交換機。擁有兩個機架，可以讓運維團隊更好的了解機架內(nèi)以及跨機架的網(wǎng)絡通信需求。Hadoop網(wǎng)絡要求可以參考Fayson之前的文章CDH網(wǎng)絡要求(Lenovo參考架構)。

當搭建好Hadoop集群后，我們就可以開始識別和整理運行在集群之上的工作負載，并且為這些工作負載準備基準測試，以定位硬件的瓶頸在哪里。經(jīng)過一段時間的基準測試和監(jiān)控，我們就可以了解需要如何增加什么樣配置的新機器。異構的Hadoop集群是比較常見的，特別是隨著數(shù)據(jù)量和用例數(shù)量的增加，集群需要擴容時。所以如果因為前期并不熟悉工作負載，選擇了一些較為通用的服務器，也并不是不能接受。Cloudera Manager支持服務器分組，從而使異構集群配置變的很簡單。

以下是不同的工作負載的常見機器配置：

• Light Processing Configuration，1U的機器，一般為測試，開發(fā)或者低要求的場景：2個hex-core CPUs，24-64GB內(nèi)存，8個磁盤(1TB或者2TB)
• Balanced Compute Configuration，均衡或主流的配置，1U/2U的機器：2個hex-core CPUs，48-256GB的內(nèi)存，12-16塊磁盤(1TB-4TB)，硬盤為直通掛載
• Storage Heavy Configuration，重存儲的配置，2U的機器：2個hex-core CPUs，48-128GB的內(nèi)存，16-24塊磁盤(2TB-6TB)。這種配置一旦多個節(jié)點或者機架故障，將對網(wǎng)絡流量造成很大的壓力
• Compute Intensive Configuration，計算密集型的配置，2U的機器：2個hex-core CPUs，64-512GB memory,4-8塊磁盤(1TB-4TB)

注意：以上2路6核為最低的CPU配置，推薦的CPU選擇一般為2路8核，2路10核，2路12核

下圖顯示如何根據(jù)工作負載來選擇你的機器：

4.其他注意事項

Hadoop生態(tài)系統(tǒng)是一個并行環(huán)境的系統(tǒng)。在選擇購買處理器時，我們不建議選擇主頻(GHz)最高的芯片，這樣一般都代表了更高電源瓦數(shù)(130W+)。因為這會產(chǎn)生兩個問題：更高的功率消耗和需要更多的散熱。較為均衡的選擇是在主頻，價格和核數(shù)之間做一個平衡。

當存在產(chǎn)生大量中間結果的應用程序 – 輸出結果數(shù)據(jù)與輸入數(shù)據(jù)相當，或者需要較多的網(wǎng)絡交換數(shù)據(jù)時，建議使用綁定的萬兆網(wǎng)，而不是單個萬兆網(wǎng)口。

當計算對內(nèi)存要求比較高的場景，請記住，Java最多使用10%的內(nèi)存來管理虛擬機。建議嚴格配置Hadoop使用的堆大小的限制，從而避免內(nèi)存交換到磁盤，因為交換會大大影響計算引擎如MapReduce/Spark的性能。

優(yōu)化內(nèi)存通道寬度也同樣重要。比如，當使用雙通道內(nèi)存時，每臺機器都應配置一對DIMM。使用三通道內(nèi)存時，每個機器都應該具有三倍的DIMM。同樣，四通道DIMM應該被分為四組。

5.Hadoop其他組件的考慮

Hadoop遠遠不止HDFS和MapReduce/Spark，它是一個全面的數(shù)據(jù)平臺。CDH平臺包含了很多Hadoop生態(tài)圈的其他組件。我們在做群集規(guī)劃的時候往往還需要考慮HBase，Impala和Solr等。它們都會運行在DataNode上運行，從而保證數(shù)據(jù)的本地性。

HBase是一個可靠的，列存儲數(shù)據(jù)庫，提供一致的，低延遲的隨機讀/寫訪問。Cloudera Search通過Solr實現(xiàn)全文檢索，Solr是基于Lucene，CDH很好的集成了Solr Cloud和Apache Tika，從而提供更多的搜索功能。Apache Impala則可以直接運行在HDFS和HBase之上，提供交互式的低延遲SQL查詢，避免了數(shù)據(jù)的移動和轉換。

由于GC超時的問題，建議的HBase RegionServer的heap size大小一般為16GB，而不是簡單的越大越好。為了保證HBase實時查詢的SLA，可以通過Cgroups的的方式給HBase分配專門的靜態(tài)資源。

Impala是內(nèi)存計算引擎，有時可以用到集群80%以上的內(nèi)存資源，因此如果要使用Impala，建議每個節(jié)點至少有128GB的內(nèi)存。當然也可以通過Impala的動態(tài)資源池來對查詢的內(nèi)存或用戶進行限制。

Cloudera Search在做節(jié)點規(guī)劃時比較有趣，你可以先在一個節(jié)點安裝Solr，然后裝載一些文檔，建立索引，并以你期望的方式進行查詢。然后繼續(xù)裝載，直到索引建立以及查詢響應超過了你的預期，這個時候你就需要考慮擴展了。單個節(jié)點Solr的這些數(shù)據(jù)可以給你提供一些規(guī)劃時的參考，但不包括復制因子因素。

6.總結

選擇并采購Hadoop硬件時需要一些基準測試，應用場景測試或者Poc，以充分了解你所在企業(yè)的工作負載情況。但Hadoop集群也支持異構的硬件配置，所以如果在不了解工作負載的情況下，建議選擇較為均衡的硬件配置。還需要注意一點，Hadoop平臺往往都會使用多種組件，資源的使用情況往往都會不一樣，專注于多租戶的設計包括安全管理，資源隔離和分配，將會是你成功的關鍵。