從Facebook看大數據存儲怎么選
做技術的朋友可能有過類似這樣的感覺——每天都會遇到新的問題，或者學到新的知識。然而一個人的時間和精力畢竟有限，不是所有的崗位都能做到總是親力親為，每人最擅長的領域也各不相同。為了使工程師自己踩過的坑、那些實用的心得體會也能給大家帶來幫助，把經驗記錄和分享出來就顯得尤為可貴，這就是我們開設《工程師筆記》專欄的目的。
最近有位朋友向我咨詢技術問題，他們的客戶提出一個大數據系統的服務器硬件需求，其中元數據有xxTB左右。并給出了以下初步建議：
節點類型1（元數據節點）
Xeon E5 14核CPU x2
256GB DDR4內存
600GB SAS 15K硬盤x5
RAID卡
節點類型2（數據節點）
Xeon E5 14核CPU x2
128GB DDR4內存
4TB 7.2K近線硬盤x4
RAID卡
軟件并非我擅長的方面，不過大數據概念炒了好幾年，從各方面還是多少了解到一些Hadoop/HDFS硬件架構方面的東西。在與朋友討論的過程中，我覺得相關技術還需要補補，以跟上“應用定義硬件”的形勢，于是就把之前收集到的一些資料翻看了下。
在分享我的學習心得之前，先列出以上案例中的幾個疑問，同時附上專家意見。
1. Hadoop是否需要RAID？
根據我的了解，HDFS（Hadoop分布式文件系統）的數據盤應該是不做RAID，靠跨節點的3副本來實現冗余高可用。那么是否還需要配SAS RAID卡？如果是RAID卡需要改成直通（HBA）模式嗎？
專家觀點
據了解開源版本的HDFS multiple master應該還未ready，所以現在HDFS master是master-slave或者單點部署或者共享存儲。如果不是共享，那么master機器本身***不要down掉，RAID卡不僅提升性能，也能一定程度上避免單盤壞帶來的問題。網上有人說Master的內存要盡可能大，要有更強的ECC功能，可以參考下。
2. 是否應該添加額外的系統硬盤？元數據節點的SAS盤如果換成SSD效果更好？
按照傳統的觀點，在有條件的情況下服務器的系統盤和數據盤建議分開，無論從容量規劃還是性能角度考慮，特別是存儲密集型應用。此外，用戶提出15K高轉速硬盤應該是有IOPS需求，而SSD在這方面優勢明顯。
專家觀點
如果需要高性能，SSD更好，價格也會持續下降，master采購SSD的話也浪費不了多少，一旦掛了，讀image恢復也快。單個磁盤容量應該大于內存，比如2倍，這樣內存數據image才能落在磁盤上，甚至保留最近的幾個備份。
3. 這個建議中數據節點只配了4塊硬盤，能否滿足容量的需求？
4塊4TB硬盤裸容量按照16TB來計算不少了，但是HDFS默認是3副本，也就是3個節點的有效容量只相當于單節點物理容量。而且處理過程中的數據集應該會大于導入的元數據量，那么整個集群需要增加節點還是每節點的硬盤數？
專家觀點
只有4塊浪費了點，機器機架的公攤變多了，如果價格差別不大，10塊+更好，哪怕現在不插盤。不過這取決于應用想干什么，以及當前的業務規模。一般來說，數據量是X，那么容量需要是X*配置的replica/容量比。配置的replica一般是3，容量比80%，如果有大量的中間結果，容量比會比較低，比如60%。
4. CPU/內存/硬盤配比有計算公式嗎？
由于這位朋友認識的一位大數據專家出差了，我被臨時找來抱佛腳：）聽應用高手說，可以根據自己的情況來計算出需要的硬件配置。對于我們而言，這方面有沒有給用戶的建議呢？
專家觀點
跟業務類型緊密相關，比如跑人工智能類的迭代，那么CPU就要多，甚至配置GPU。如果是一般的數據處理，比如網站分析點擊日志，512GB空間，1個CPU，4-8GB內存一般也差不多了。
這兩年，伴隨著OpenStack、Docker被人們追捧，云計算的話題依舊保持著一定熱度，或者說正在落地。而大數據泡沫在幾年前感覺有些被吹大了，以至于在Hadoop科普時我關注過一些，后來除了開源項目的發展之外，廠商們的推廣力度也沒有開始時那么大了，進入務實階段。
下面引用一個當年給我印象比較深的表格，來自Facebook關于非結構化數據存儲硬件選型的分享資料。
我們知道Facebook每天都有海量上傳的照片和視頻，上表中Type V硬件類型對應的就是這個，其特點為低CPU、內存開銷，主要是溫數據和冷數據。
而本文關注的Type IV針對Hadoop應用，硬盤仍然按照12塊3TB大容量來配置，CPU和內存的需求都是“中等”，從具體的Xeon X5650 CPU來看這份資料也比較早了。
上圖引用自《Dell Cloudera Apache Hadoop Solution Reference Architecture》文檔，Cloudera是一家排名領先的Hadoop發行版廠商，我們借此來了解下今天Apache Hadoop方案中流行的組件。
底層有服務器和網絡硬件、操作系統、Java虛擬機（中間件）；往上包括了資源管理（YARN）、HDFS文件系統、HBase（開源的NoSQL分布式數據庫）；MapReduce數據處理框架和Hive數據倉庫在幾年前就已經講的比較多，而Spark In Memory Processing等這兩年也比較火。
既然最終目的是討論硬件配置，先看看不同的節點類型及其主要職能。
Admin Node即管理員節點，這里不過多討論；Edge Node（邊緣節點）被稱為Hadoop Clients，主要作用是集群數據與外界之間的導入導出；在數據節點和命名（Name）/HA節點之中，藍色部分屬于管理模塊，綠色則是存儲模塊，二者各有一套網絡連接到Edge Node。數據節點之間完全對等，下面介紹一下元數據服務的高可用實現。
記得Hadoop在早期的1.0版本時，Name Node還曾經有過單點故障問題，下面這段描述只代表部分商業版本的解決方案。
首先不難理解，Active Name Node和Standby Name Node之間是主備關系，而第三個HA節點上也有Cloudera Manager和Zookeeper，其作用就是Name Node自動切換的仲裁。HA節點上不運行Name Node服務，但元數據的Journal會由主節點同時向3個節點寫入，多數返回才算成功。
這個Journal，讓我想起了Oracle Data Guard中同步復制的Redo log。
專家觀點
Name Node HA這一塊現在并無統一的方案，我看到Hadoop網站上是建議使用NAS類的共享存儲，在不能基于類似paxos提供高可用情況下，我覺得共享存儲是個不錯的選擇，因為一致性能得到保證，主備就怕一致性問題。（參考鏈接：https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithNFS.html）
上面是Hadoop節點間的網絡連接。目前主流的數據網絡是雙萬兆，iDRAC/管理網絡可以用千兆，作為與外界數據溝通的Edge Node還應有2個萬兆連接至用戶的企業網絡。這個示例為角色完整的最小節點數集群，而實際上還有進一步精簡的配置方式。
所謂“QuickStart”應該就是最小起步規模。上圖中2個R730xd Infrastructure Node估計包含了元數據和Edge節點的功能，這里減掉了第3個HA節點是不是意味著故障切換的機制有變化？
專家補充
Master Namenode HA并無標準，開源以及一些基于開源的商業公司都想做自己的。
本文開頭提到過每個數據節點的硬盤數。除了容量之外，這還會影響到存儲性能，上面的圖表顯示了執行時間與硬盤數之間的對應關系。
從這個來看，8塊硬盤相比4塊速度提升了一倍，同時容量翻番。盡管12塊盤的性能更好，但在今天硬盤容量不斷增長（傳輸率也有些提升）的情況下，有些場景數據節點用8塊盤應該也是一種不錯的選擇，特別是對性能和容量不太敏感的應用。
關于合理的硬件資源配比，我從一份資料里引用整理出上面的圖表供參考。其中有3種不同應用側重的Hadoop計算（存儲）節點，我們先按照一般規律假設磁盤主軸數為12。對于數據密集型和存檔型應用其CPU核心配置12個（2顆6核入門級）即可；計算密集型應用可以配置24核——2顆12核。內存容量方面，對于存檔節點24GB即夠用，數據密集型可以配置48GB，而計算密集型在這里的建議是96GB。
當然，上表也有一定的時間局限性，比如磁盤是按照主軸而不是容量來統計。這樣從存儲性能角度看比較合理，但硬盤容量畢竟在慢慢提高，比如3、4年前的主流3TB今天上升到4TB或者更大；與此同時內存價格在不斷下降，CPU集成核心數越來越多，為了更好地適應更大的數據集規模，主流應用的配比也應該隨著時間發展而適當調整。
下面我們來看一些更具體的建議。
該表格引用自《Dell Reference Configuration for Hortonworks Data Platform 2.4》，列出了Name Node和HA見證節點的磁盤配置建議。Hortonworks是另外一個主要的Hadoop發行版。
可見OS、HDFS元數據和數據庫有可靠性和可用性的要求；Zookeeper和NameNode Journal應該只有在故障時才會用到，并且在多個節點上有副本，所以不用RAID保護。對于日志這類順序寫入負載，SSD可以提供更高的吞吐量。
上面是具體的Name Node和HA見證節點配置。在這個PowerEdge R730xd服務器平臺上，CPU為2顆Xeon E5-2650 v4 12核、128GB內存，網絡子卡（Daughter Card）選擇雙萬兆+雙千兆；硬盤方面，2塊600GB SAS盤RAID 1用于OS（安裝在服務器后端的Flexbay中），另外8塊1TB數據盤的用途參見上面。
作為一款12Gb SAS RAID卡，PERC 9 H730支持設置為HBA直通模式。上圖為Dell服務器標配H730 mini RAID子卡，通過專用連接器插在主板上，不占用標準PCIe擴展槽。這種子卡的成本比標準尺寸的RAID卡要低（網絡子卡的情況類似），即使當做SAS HBA來使用也不會造成多少浪費。
對比本文開頭用戶提出的元數據節點配置，內存容量比這個還大，而硬盤上沒有寫這么細致，總的來說還算合理吧。畢竟配置建議與實際應用情況相關，可以跟用戶做進一步的溝通。
上圖是我幾年前在PowerEdge 12G發布活動上，拍攝的R720xd后側Flexbay——2個2.5英寸熱插拔盤位。
通用數據節點的CPU和內存與前面的Name Node等相同，算是主流配置吧。HDFS數據存儲方面，配置了12塊4TB 7.2K NL-SAS硬盤（企業級近線SATA用在服務器上差不多），非RAID或者RAID 0模式。
由于數據節點的多副本容錯模式，對單機可用性要求大為降低，因此多數情況下操作系統盤的RAID 1也可以不用。上表中應該屬于一種比較豪華的配置方式。
高性能節點建議配置2顆Xeon E5-2690 14核CPU、512GB內存，除了板載網絡子卡之外，額外增加一塊Intel雙端口萬兆配置LACP聚合以提高帶寬。
磁盤配置也相應的比較豪華。服務器平臺調整為24個2.5英寸盤位的R730xd，包括20x 1.2TB SAS + 3x 800GB SSD的HDFS分層存儲；另有一塊800GB Intel S3710應該是用于Spark數據持久化——這就可以理解為什么內存要配這么大，因為它就是針對“內存計算”的。
***是高容量節點，它的配置在通用數據節點基礎上做了增強——采用一款特定版本的R730xd機箱（12+2+4，帶有Flexbay和Mid-bay）。如下圖，在2U機箱的中部增加了4個3.5英寸硬盤位，因此4TB HDFS數據盤的數量增加到16塊。
這4塊盤也能夠支持熱插拔，不過需要先打開服務器上蓋。Dell這種設計屬于在標準服務器基礎上的改良，其他品牌可能也有自己提高存儲密度的方式。
架構驗證——云帶來真正的便利
有個方法是可以檢驗一下選型的，就是在云服務廠商那里先按照自己的配置租一些服務器，根據業務調整云服務器的配置，這個很方便（硬件買了就很難調整了），最終也能得出比較合理的配置。
本文到此先告一段落，開頭提出的幾個問題應該都有答案了。筆者不是大數據方面的專家，希望這些學習心得加上專家觀點對大家有所幫助。如有錯誤和不足歡迎批評指正，歡迎您在下面留言交流！
