Hadoop运维记录系列(十四)
周末去了趟外地，受托給某省移動公司(經確認更正，是中國移動位置基地，不是省公司)做了一下Hadoop集群故障分析和性能調優，把一些問題點記錄下來。
該系統用于運營商的信令數據，大約每天1T多數據量，20臺Hadoop服務器，贊嘆一下運營商乃真土豪，256G內存，32核CPU，卻掛了6塊2T硬盤。還有10臺左右的服務器是64G內存，32核CPU，4~6塊硬盤，據用戶反饋，跑數據很慢，而且會有失敗，重跑一下就好了。
軟件環境是RedHat 6.2，CDH Hadoop 4.2.1。
總容量260多TB，已使用200多T。
首先，這硬件配置屬于倒掛，內存CPU和硬盤不匹配，因為作為Hadoop來說，注重的是磁盤的高吞吐量，而并發讀寫磁盤個數決定了吞吐量的大小。對于Hadoop來說，硬盤數量多比單盤容量大更具有優勢。舉例說明，假設一塊硬盤的讀寫速度是210MB每秒，一塊硬盤3TB，那么全部掃描一遍大概需要4小時左右。而1TB的硬盤掃描一遍大概只需要一個多小時。Hadoop最好的硬盤掛載方式是JBOD，也就是直接插主板不做raid。那么如果同時10塊硬盤讀寫，得到的吞吐量是2.1G左右。20塊就是4G左右。所以，對于Hadoop來說，30塊1TB硬盤的性能要絕對優于10塊3TB的硬盤。但是目前來說，性價比最高的還是2TB的硬盤。
還好只有20臺服務器，可以挨個手工上去查一下，如果是200臺，挨個查我就死在移動了。除了硬件配置不合理外，還查出幾個比較重要的問題。
一、20臺機器沒有做機架感知，而且復制份數是2，因為受集群總存儲能力限制，目前只能復制兩備份，這個沒轍了，以后擴服務器再說吧。
二、配置不合理，且沒有為異構硬件搭配不同的Hadoop配置項
????1. 因為采用CDH 4，所以實際是在YARN上跑MRv1，256G內存的服務器配置的map槽位數是150個，reduce槽位數是130個，其實是很大程度上超出了32核CPU的計算能力，絕大部分的CPU時間消耗在了MR Java進程之間的切換上。大量的Java進程用strace跟蹤看都是在互斥鎖上等待(FUTEX_WAIT)。所以，跑任務的時候服務器的System CPU很高，真正用于MR的User CPU很少。
????2. 256G跟64G內存的服務器，Hadoop配置文件一樣，64G也是150 map slots, 130 reduce slots，mapred.map(reduce).child.java.opt內存也沒改，沒發生OOM真是奇跡...MR槽位數不是越大越好，要跟CPU和內存數量搭配著算才好，至于2.0，更簡單一些，只要配置vcore數量就行了，但是也不是vcore配的越大就越好。而且，據說搭建集群之前有公司給他們培訓過Hadoop，居然告訴他們map,reduce槽位數的配置項沒用，不用管，這培訓也太坑人了吧。
????3. 沒有做磁盤保留空間，我到了現場以后沒多久一臺NodeManager就掛了，我以為是我神威所致，服務器害怕了，上去一看是硬盤100%了...
三、Linux系統層面沒有做優化。
????1. 沒有開啟TCP回收和TCP復用
????2. 沒有設置文件打開句柄數
????3. 還有三臺服務器沒有關閉SELinux
? ? 4. 沒有自動化運維，20臺Hadoop服務器都是tar包解壓縮手工裝的。
????5. 沒有監控，據說是我去之前幾天才裝的Ganglia...監控數據采集了MR和HBASE，沒有HDFS
????6. 沒有做數據壓縮。
????7. 小文件太多，塊數量380萬，文件數量360萬。分塊大小設定128M，上去看很多文件都達不到，基本都是40~80兆左右。
四、業務層面太過復雜。
????1. 數據清洗依賴Hive進行，而沒有采用編寫MR的方式，Hive開發速度快，但是執行效率是真低啊。
????2. 單個查詢Join太多，并開啟了Hive的并行查詢，引發大量的Stage任務，占用太多MR槽位。
????3. 同時并發計算太多，沒有做Job分解和規劃調度。
????4. 清洗后的數據使用snappy壓縮，這玩意計算讀取的時候不分塊的，只能1map讀取。
總的來說，基本還是由于硬件配置不合理和對Hadoop底層不熟悉導致的性能較低，這個不是我這個層面能解決的問題了。
當然，這不是我見過的配置最不合理的硬件，記得去年年初中軟國際賣某部委的Hadoop服務器，找我給配置，128G內存，64核CPU，4塊2T盤。當時我看著這服務器是真不知道該怎么配才合適。當時說給錢，到現在也沒給，賴賬了這幫孫子...
其實搞hadoop，不僅僅只是搭起來能跑那么簡單，傳統運營商基本還是拿傳統的思維觀念在看待這些新生的開源事物，認為單個機器CPU足夠多，內存足夠大，就不需要很多臺機器了。如果只是這樣簡單的話，就不需要開發Hadoop了，谷歌只要弄個牛逼配置的大型機，繼續用Oracle就好了。Hadoop也好，Spark也好，更多的是螞蟻啃大象的思路，雖然單個機器爛，但是只要足夠多，也可以解決大問題。
云服務也好，大數據也罷，真正注重的是運維的能力，運維強則數據強
轉載于:https://blog.51cto.com/slaytanic/1636197
總結
以上是生活随笔為你收集整理的Hadoop运维记录系列(十四)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： maya 专家模式
- 下一篇： GOOD MEETINGS CREATE