做技術(shù)的朋友可能有過類似這樣的感覺——每天都會遇到新的問題，或者學(xué)到新的知識。然而一個人的時間和精力畢竟有限，不是所有的崗位都能做到總是親力親為，每人最擅長的領(lǐng)域也各不相同。為了使工程師自己踩過的坑、那些實用的心得體會也能給大家?guī)韼椭呀?jīng)驗記錄和分享出來就顯得尤為可貴，這就是我們開設(shè)《工程師筆記》專欄的目的。

 

最近有位朋友向我咨詢技術(shù)問題，他們的客戶提出一個大數(shù)據(jù)系統(tǒng)的服務(wù)器硬件需求，其中元數(shù)據(jù)有xxTB左右。并給出了以下初步建議：

節(jié)點類型1（元數(shù)據(jù)節(jié)點）

Xeon E5 14核CPU x2

256GB DDR4內(nèi)存

600GB SAS 15K硬盤x5

RAID卡

節(jié)點類型2（數(shù)據(jù)節(jié)點）

Xeon E5 14核CPU x2

128GB DDR4內(nèi)存

4TB 7.2K近線硬盤x4

RAID卡

 

軟件并非我擅長的方面，不過大數(shù)據(jù)概念炒了好幾年，從各方面還是多少了解到一些Hadoop/HDFS硬件架構(gòu)方面的東西。在與朋友討論的過程中，我覺得相關(guān)技術(shù)還需要補補，以跟上“應(yīng)用定義硬件”的形勢，于是就把之前收集到的一些資料翻看了下。

 

在分享我的學(xué)習(xí)心得之前，先列出以上案例中的幾個疑問，同時附上專家意見。

 

1.  Hadoop是否需要RAID？

根據(jù)我的了解，HDFS（Hadoop分布式文件系統(tǒng)）的數(shù)據(jù)盤應(yīng)該是不做RAID，靠跨節(jié)點的3副本來實現(xiàn)冗余高可用。那么是否還需要配SAS RAID卡？如果是RAID卡需要改成直通（HBA）模式嗎？

專家觀點

據(jù)了解開源版本的HDFS multiple master應(yīng)該還未ready，所以現(xiàn)在HDFS master是master-slave或者單點部署或者共享存儲。如果不是共享，那么master機器本身***不要down掉，RAID卡不僅提升性能，也能一定程度上避免單盤壞帶來的問題。網(wǎng)上有人說Master的內(nèi)存要盡可能大，要有更強的ECC功能，可以參考下。

 

2. 是否應(yīng)該添加額外的系統(tǒng)硬盤？元數(shù)據(jù)節(jié)點的SAS盤如果換成SSD效果更好？

按照傳統(tǒng)的觀點，在有條件的情況下服務(wù)器的系統(tǒng)盤和數(shù)據(jù)盤建議分開，無論從容量規(guī)劃還是性能角度考慮，特別是存儲密集型應(yīng)用。此外，用戶提出15K高轉(zhuǎn)速硬盤應(yīng)該是有IOPS需求，而SSD在這方面優(yōu)勢明顯。

專家觀點

如果需要高性能，SSD更好，價格也會持續(xù)下降，master采購SSD的話也浪費不了多少，一旦掛了，讀image恢復(fù)也快。單個磁盤容量應(yīng)該大于內(nèi)存，比如2倍，這樣內(nèi)存數(shù)據(jù)image才能落在磁盤上，甚至保留最近的幾個備份。

 

3. 這個建議中數(shù)據(jù)節(jié)點只配了4塊硬盤，能否滿足容量的需求？

4塊4TB硬盤裸容量按照16TB來計算不少了，但是HDFS默認是3副本，也就是3個節(jié)點的有效容量只相當(dāng)于單節(jié)點物理容量。而且處理過程中的數(shù)據(jù)集應(yīng)該會大于導(dǎo)入的元數(shù)據(jù)量，那么整個集群需要增加節(jié)點還是每節(jié)點的硬盤數(shù)？

專家觀點

只有4塊浪費了點，機器機架的公攤變多了，如果價格差別不大，10塊+更好，哪怕現(xiàn)在不插盤。不過這取決于應(yīng)用想干什么，以及當(dāng)前的業(yè)務(wù)規(guī)模。一般來說，數(shù)據(jù)量是X，那么容量需要是X*配置的replica/容量比。配置的replica一般是3，容量比80%，如果有大量的中間結(jié)果，容量比會比較低，比如60%。

 

4. CPU/內(nèi)存/硬盤配比有計算公式嗎？

由于這位朋友認識的一位大數(shù)據(jù)專家出差了，我被臨時找來抱佛腳：）聽?wèi)?yīng)用高手說，可以根據(jù)自己的情況來計算出需要的硬件配置。對于我們而言，這方面有沒有給用戶的建議呢？

專家觀點

跟業(yè)務(wù)類型緊密相關(guān)，比如跑人工智能類的迭代，那么CPU就要多，甚至配置GPU。如果是一般的數(shù)據(jù)處理，比如網(wǎng)站分析點擊日志，512GB空間，1個CPU，4-8GB內(nèi)存一般也差不多了。

 

這兩年，伴隨著OpenStack、Docker被人們追捧，云計算的話題依舊保持著一定熱度，或者說正在落地。而大數(shù)據(jù)泡沫在幾年前感覺有些被吹大了，以至于在Hadoop科普時我關(guān)注過一些，后來除了開源項目的發(fā)展之外，廠商們的推廣力度也沒有開始時那么大了，進入務(wù)實階段。

 下面引用一個當(dāng)年給我印象比較深的表格，來自Facebook關(guān)于非結(jié)構(gòu)化數(shù)據(jù)存儲硬件選型的分享資料。

 

我們知道Facebook每天都有海量上傳的照片和視頻，上表中Type V硬件類型對應(yīng)的就是這個，其特點為低CPU、內(nèi)存開銷，主要是溫數(shù)據(jù)和冷數(shù)據(jù)。

 而本文關(guān)注的Type IV針對Hadoop應(yīng)用，硬盤仍然按照12塊3TB大容量來配置，CPU和內(nèi)存的需求都是“中等”，從具體的Xeon X5650 CPU來看這份資料也比較早了。

 

 

上圖引用自《Dell  Cloudera Apache Hadoop Solution Reference Architecture》文檔，Cloudera是一家排名領(lǐng)先的Hadoop發(fā)行版廠商，我們借此來了解下今天Apache Hadoop方案中流行的組件。

底層有服務(wù)器和網(wǎng)絡(luò)硬件、操作系統(tǒng)、Java虛擬機（中間件）；往上包括了資源管理（YARN）、HDFS文件系統(tǒng)、HBase（開源的NoSQL分布式數(shù)據(jù)庫）；MapReduce數(shù)據(jù)處理框架和Hive數(shù)據(jù)倉庫在幾年前就已經(jīng)講的比較多，而Spark In Memory Processing等這兩年也比較火。

 既然最終目的是討論硬件配置，先看看不同的節(jié)點類型及其主要職能。

 

Admin Node即管理員節(jié)點，這里不過多討論；Edge Node（邊緣節(jié)點）被稱為Hadoop Clients，主要作用是集群數(shù)據(jù)與外界之間的導(dǎo)入導(dǎo)出；在數(shù)據(jù)節(jié)點和命名（Name）/HA節(jié)點之中，藍色部分屬于管理模塊，綠色則是存儲模塊，二者各有一套網(wǎng)絡(luò)連接到Edge Node。數(shù)據(jù)節(jié)點之間完全對等，下面介紹一下元數(shù)據(jù)服務(wù)的高可用實現(xiàn)。

 記得Hadoop在早期的1.0版本時，Name Node還曾經(jīng)有過單點故障問題，下面這段描述只代表部分商業(yè)版本的解決方案。

 首先不難理解，Active Name Node和Standby Name Node之間是主備關(guān)系，而第三個HA節(jié)點上也有Cloudera Manager和Zookeeper，其作用就是Name Node自動切換的仲裁。HA節(jié)點上不運行Name Node服務(wù)，但元數(shù)據(jù)的Journal會由主節(jié)點同時向3個節(jié)點寫入，多數(shù)返回才算成功。

 這個Journal，讓我想起了Oracle Data Guard中同步復(fù)制的Redo log。

專家觀點

Name Node HA這一塊現(xiàn)在并無統(tǒng)一的方案，我看到Hadoop網(wǎng)站上是建議使用NAS類的共享存儲，在不能基于類似paxos提供高可用情況下，我覺得共享存儲是個不錯的選擇，因為一致性能得到保證，主備就怕一致性問題。（參考鏈接：https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html）

 

上面是Hadoop節(jié)點間的網(wǎng)絡(luò)連接。目前主流的數(shù)據(jù)網(wǎng)絡(luò)是雙萬兆，iDRAC/管理網(wǎng)絡(luò)可以用千兆，作為與外界數(shù)據(jù)溝通的Edge Node還應(yīng)有2個萬兆連接至用戶的企業(yè)網(wǎng)絡(luò)。這個示例為角色完整的最小節(jié)點數(shù)集群，而實際上還有進一步精簡的配置方式。