Hadoop平臺架構

dongpo 8年前發布 | 21K 次閱讀分布式/云計算/大數據

來自： http://www.itweet.cn/2016/01/25/Hadoop-Disk-Planning/

文章目錄

1. 簡介
2. 走向分布式
3. 存儲規劃
4. HDFS目錄規劃
1. 4.1. linux os目錄規劃
2. 4.2. linux主機名規劃
3. 4.3. hdfs目錄規劃
4. 4.4. 計算框架臨時目錄
5. 4.5. 存儲格式選擇和效率如何權衡？
5. 結束語

剛剛開始使用Hadoop集群的時候,目錄沒有有個規范,大家都根據自己的喜好
創建各種不同的目錄,權限控制也沒有開啟,隨著應用越來越多，使用的人員也
多了起來，導致目錄混亂,終于在新規劃集群的時候,對目錄做了規范和權限控制.
下面簡單介紹一下我們HDFS目錄規范和HDFS存儲規劃,希望對初建Hadoop集群的
同學能有一些幫助。

簡介

Hadoop的目的是基于一種新的方法來存儲和處理復雜的數據。通過把數據均衡分布
到集群上,通過復制副本以確保數據的可靠性和容錯。存儲和計算都分布到多個機器,
充分體現數據的本地性,現在的很多數據庫也都支持數據分片技術，通過把傳統的個
人英雄主義轉變為集團作戰，英雄難覓，普通人確很容易尋找。
就如超強一體機和普通PC Server對比，一個價格高昂甚至需要定制,價格高到連
淘寶這樣的土豪公司都難以承受,提出去IOE的口號,Oracle一體機確實比較貴,而小型的Pc Server容易購買。由于是量產機型,成本低。而Hadoop就是可以運行在低配置的Pc Server服務器上面的分布式集群技術,通過把海量數據分布式存儲后,通過分布式計算模型
來進行海量數據分析。通俗易懂點說，就是把一臺超級服務器跑10天完成的任務,交給20臺
小型機構建的集群20分鐘完成！而且20小型Pc機是一臺超級服務器價格的20%！相比較之下
優勢明顯：

- 效率提高 - 彈性擴容 - 價格優勢 - 彈性計算

這就是分布式存儲和計算的巨大好處！

走向分布式

一個系統走向分布式，一定有其不得不為的理由。
可擴展性是最常見的理由之一。
我先簡單的將“可伸縮”的需求分成兩種：

? Data Scalability: 單臺機器的容量不足以 (經濟的) 承載所有資料，所以需要
           分散。如：NoSQL
? Computing Scalability: 單臺機器的運算能力不足以 (經濟的) 及時完成運算所      
             以需要分散。如：科學運算。不管是哪一種需求，在決定采用分布式架構時，
             就幾乎注定要接受一些犧牲：

1.犧牲效率：網路延遲與節點間的協調，都會降低執行效率。
2.犧牲 AP 彈性：有些在單機上能執行的運算，無法輕易在分布式環境中完成。
3.犧牲維護維運能力：分散式架構的問題常常很難重現，也很難追蹤.另外，跟單機系統一樣，也有一些系統設計上的 tradeoffs(權衡)
4.CPU 使用效率優化或是 IO 效率優化
5.讀取優化或是寫入優化
6.吞吐率優化或是網絡延遲優化
7.資料一致性或是資料可得性,選擇了不同的 tradeoff，就會有不同的系統架構。

存儲規劃

Hadoop資源包含：存儲和計算。前期你對計算資源其實很難評估，建議初期可以忽略計算資源的評估，單純從存儲這個指標來規劃。那么我們的存儲應該怎么選擇？這個需要根據平臺數據增長率來計算，也因為Hadoop集群后期可以水平擴展。一般的公司很難遇到瓶頸。

一個真實的案例,我們平臺新規劃一個集群,某種數據來源,每天增長的數據為4T,我們3被冗余,以不同存儲周期規劃如下：

數據源	數據格式	數據大小/天	數據3倍鏡像冗余/天	數據條數/天	文件個數/天	存儲周期(1個月)	存儲周期(2個月)	存儲周期(3個月)	硬件評估
XX-HTTP-Data	gz	4T	4T*3=12T	2302859808	43429	360T	720T	1080T	集群硬件規劃

評估硬件存儲：

總存儲	HDFS總存儲	數據存儲	數據類型	存儲周期	30%計算空間(預留來自HDFS)	linux os	存儲評估
864 T	720 T	464T	XX-HTTP-Data+應用分析結果數據	1個月	216 T	40T	存儲評估

我們的業務是IO密集型+CPU密集型都有的業務,一個系統中既有離線任務(mr,hive),
也有基于內存計算(hbase,impala,spark),流計算(storm,sparkstreaming)等多種類型
的作業,長ETL任務,短SQL-on-Hadoop任務,SQL-on-Hbase的實時入庫查詢！對內存,
網絡,CPU,磁盤IO都會在不同的時間段有瓶頸！目前我們計算資源是統一由Yarn來,
并且在同一個集群擁有不同的機器配置(最初我們只有mr,hive任務，隨著內存技術
發展和成熟，引進了impala,spark等技術，剛開始20個節點,32G內存,32T磁盤,
引入內存技術后,新購10臺服務器是128G內存,113T磁盤,主機資源不一致,
資源分配就遇到一個大問題？),剛開始我們是使用對集群角色分組,
比如Datanode分為3組,不同組機器配置不同,但是慢慢我們發現集群資源利用
率并不高,某些機器資源利用率很低,后期慢慢的引入了Yarn的資源池,Label
based scheduling基于標簽的調度機制，并且升級了Hadoop版本,它可以跟其他調度
策略混合使用！基于標簽的調度策略是hadoop yarn新引入的feature，它能讓
YARN更好地運行在異構集群中，進而更好地管理和調度混合類型的應用程序。

1、Linux系統所在磁盤制作Raid1,需要損失一塊盤，比如：一臺主機12塊盤，2塊盤做raid1安裝linux os，則hdfs使用9塊盤！
2、Namenode配置,比如做了HA,就需要2臺cpu,mem強大的機器,磁盤存儲小的服務器！
比如：XeonE7-4880v2(2.5GHz/15c)/8.0GT/37.5ML3 * 4 Member: 512G or 256G
3、Datanode配置,XeonE5-2660v3(2.6GHz/10c)/9.6GT/25ML3 * 2 Member：128G
4、根據存儲周期劃分,一臺主機123T磁盤,Namenode不計入存儲,Datanode節點linux os 使用2塊3T盤raid1,103T=30T做為HDFS存儲！
5、比如存儲周期是1個月,hdfs存儲=4T303=360T,考慮分析結果數據預估存儲20%=72T,內存計算,磁盤計算需要計算空間=HDFS總存儲30%,考慮零時空間,測試數據等！HDFS總存儲5%
6、綜合上面幾點,HDFS總存儲=720T,Datanode數n=(720T+n3T2)/123=24臺,2臺Namenode,1臺客戶機,總共24+2+1=27臺！
公式,N主機數：N=(720T+N3T2)/123T

注意：這里的值都是預估值,剛開始可以這樣規劃,由于Hadoop可以彈性擴容,后期可以
可以增加主機,這里Datanode 主機采用CentOS-6.6_X86-64系統,并且系統做了radi1,
其實如果不甘心損失那么多存儲,Datanode主機可以不用做raid,HDFS存儲全都做成
JBOD安裝，無RAID。我們自然有我們的考量,如果你有覺得不妥的歡迎指正.詳細選型
主機配置請參考：《Hadoop平臺架構—硬件篇》

HDFS目錄規劃

底層數據存儲規劃，這個模塊比較重要，由于前期建設規劃不合理，導致數據存儲目錄規劃混亂，導致很多數據存儲目錄很深，在清理hdfs存儲空間的時候，造成了不小的麻煩，所以重新規劃了目錄分布！底層操作系統默認raid5.戴爾服務器.后修改為系統盤raid1(兩塊盤做radi1),總共11塊盤一臺機器。其余盤做JBOD！

linux os目錄規劃

目錄	大小	Linux版本
/boot	1024M	CentOS 6.6
/boot	1024M	CentOS 6.6
/swap	內存大小*{1~2}	CentOS 6.6
/	60G	CentOS 6.6
/var	針對兩個主節點100G,其余節點50G	CentOS 6.6
/data{1..10}	Hdfs數據	CentOS 6.6
/tmp	40G	CentOS 6.6
/home	80G	CentOS 6.6

Linux系統分區方案說明：
在很多業務服務器數量多且復雜的運維場景，會有專門的系統安裝工程師，由于這些基礎系統安裝工程師無法確定服務器的業務需求，因此，會根據公司的要求只分出：
    /boot   200M
    Swap    內存*2
    /   （列如： 100G）
然后剩余的分區保留不分，fdisk(不適合大于2t的分區)，parted(適合大于2T的分區)
這樣后續使用的服務器的不同業務產品的運維部門就可以根據具體的業務在規劃后面的分區，這樣的方法也是值得推薦的分區思路！

上面的/data{1..10}目錄，表示，如果有10塊硬盤，掛載點為10個目錄，取名/data1, /data2, /data3, / data..這些目錄都用來存儲hdfs數據的數據目錄！
有關根目錄/ ，主要是存儲/var，/home，/tmp，/opt等！

linux主機名規劃

目錄	Linux版本
bigdata-server{01…100}	CentOS 6.6

hdfs目錄規劃

目錄	含義	Linux版本
/data/external	外部抽取數據源存儲路徑	CentOS 6.6
/data/external/db	表示oracle-數據	CentOS 6.6
/data/external/ftp	表示從ftp獲取的數據	CentOS 6.6
/user/hive/warehouse	各種內部表庫地址	CentOS 6.6
/tmp	用來存儲一些臨時數據文件，每周清理一遍	CentOS 6.6
/xxx	一些默認自動生成的目錄	CentOS 6.6
/apps	App運行所需jar包	CentOS 6.6
/scripts	各種腳本備份路徑	CentOS 6.6
/user	用戶空間，存儲用戶私有數據，僅用戶自己可以訪問.	CentOS 6.6
/hbase	Hbase HDFS數據目錄	CentOS 6.6

計算框架臨時目錄

由于數據量越來越大，檢索數據太大，導致無法所有數據放入內存，很多中間結果數據會寫到磁盤，目前規劃總存儲的20%做為計算磁盤空間！如果低于20%，計算的時候會導致磁盤空間不足的情況，或者很多任務出現警告和運行緩慢等情況！

存儲格式選擇和效率如何權衡？

  組件      格式     數據量     壓縮大小   原始大小

  Imapla    Parquet  ?           30.1 G     98.6 G
  Sparksql  Parquet  ?           69.4 G     98.6 G
  Hive      Rcfile   ?           93.4 G     98.6 G
  Presto    Orcfile  ?           16.2 G     98.6 G

  Hbase     Snappy   ?           0.35T      2.3T    # 每天入hbase數據量

  注意：考慮生成壓縮文件的效率,時間換空間的操作！

>>>>>>>>Txt格式
      組件                  耗時
      Hive                  342.235s
      Presto                73.4s
      Impala                20.57s
      Sparksql              169.465s
      Sparksql[chache]      95.9s

>>>>>>>>Parquet格式
       組件                  耗時
       Hive                  322.201s
       Presto                37.91s
       Impala                17.57s
       Sparksql              124.9s
       Sparksql[chache]      108s

>>>>>>>>Orc格式
       組件                  耗時
       Hive                  276.179s
       Presto                101.4s
       Impala                0s  #不支持此格式
       Sparksql              46s
       Sparksql[chache]      35s

>>>>>>>>RcFile格式
       組件                  耗時
       Hive                  306.264s
       Presto                36s
       Impala                18.14s
       Sparksql              177.799s
       Sparksql[chache]      176.5s

>>>>>>>>>>>>>2組join FcFile文件格式
       組件             耗時         其它問題記錄
       Hive             1600s 
       Presto           700s 
       Impala           1175.29s   
       Sparksql         689.047s
       Sparksql[chache]              效率提升不明顯,未測試

       組件              耗時        其它問題記錄
       Hive              300s  
       Presto            60s 
       Impala            2.67s
       Sparksql          40 s
       Sparksql[chache]              效率提升不明顯,未測試

>>>>>>>>>>>>>>>>>大大表兩兩關聯（億級+百萬級）測試
==>TextFile
       組件         耗時       其它問題記錄
       Hive         641.937s     第一次執行

       Impala       267.526s     第一次執行
       Impala       262.727s     第二次執行
       Spark-sql    300.355s     第一次執行
       Spark-sql    294.922s     第二次執行

==>Parquet
       組件        耗時        其它問題記錄
       Hive        57.702s      第一次執行

       Impala      1.359s       第一次執行
       Impala      1.232s       第二次執行
       Spark-sql   2.977s       第一次執行
       Spark-sql   2.857s       第二次執行

Hadoop壓縮算法選擇：
  ?mapreduce.map.output.compress.codec 
  ?mapreduce.output.fileoutputformat.compress.codec 
  ?mapreduce.output.fileoutputformat.compress.type 
    – org.apache.hadoop.io.compress.DefaultCodec 
    – org.apache.hadoop.io.compress.SnappyCodec [最佳選擇]
    – org.apache.hadoop.io.compress.BZip2Codec /GzipCodec【GzipCodec壓縮最高，但是時間上比較耗時】

結束語

這是我對于Hadoop存儲硬件規劃的一個小小總結，如有不妥之處歡迎指正,如果想了解非常詳細的硬件參數,歡迎參考《Hadoop平臺架構—硬件篇》

參考：http://www.itweet.cn

原創文章，轉載請注明：轉載自whoami的博客
本博客的文章集合: http://www.itweet.cn/archives/

本文由用戶 dongpo 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1453897409995.html

分布式/云計算/大數據