當我們想搭建一個時，碰到的第一個問題就是我們到底該如何選擇硬件。

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

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

1.計算和存儲

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.為CDH集群挑選硬件

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

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

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

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

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

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

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

• 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的內存
• 綁定的萬兆網

“記住，Hadoop生態系統的設計需考慮并行環境。”

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

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

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

• Light Processing Configuration，1U的機器，一般為測試，開發或者低要求的場景：2個hex-core CPUs，24-64GB內存，8個磁盤(1TB或者2TB)
• Balanced Compute Configuration，均衡或主流的配置，1U/2U的機器：2個hex-core CPUs，48-256GB的內存，12-16塊磁盤(1TB-4TB)，硬盤為直通掛載
• Storage Heavy Configuration，重存儲的配置，2U的機器：2個hex-core CPUs，48-128GB的內存，16-24塊磁盤(2TB-6TB)。這種配置一旦多個節點或者機架故障，將對網絡流量造成很大的壓力
• 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核

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

4.其他注意事項

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

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

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

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

5.Hadoop其他組件的考慮

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

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

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

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

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

6.總結

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