?01大數據集群節點規劃

1.HDFS集群節點規劃

假如業務系統數據量每天增量 50T，保留周期為 30 天，那么 HDFS 存儲 容量為 50T * 30 天 * 3 副本 * 2 倍（數據源+清晰加工） = 9000T = 8.79P 。假如每個機器的磁盤是 4T * 10 = 40T, 每臺機器的可用存儲容量為 40T * 0.75 = 30T， 節點預估數量= 9000T / 30 = 300 節點，所以 datanode 的節 點最小數量為 300 個。

2.YARN集群節點規劃

根據任務量和性能評估 YARN 的節點數是很難的，難以評估，所以 NodeManager節點數可以和datanode節點數保持一致，如果算力負載過高， 根據實際情況再擴容即可。

3.HBase集群節點規劃

HBase 節點規劃：一般開始搭建是根據 HDFS 存儲公式計算即可，如果從增加并發的考慮，一般一個 RegionSever 并發為 5000 ~2 萬（優化后并發更高）， 可以根據業務實際并發估計節點數量。

4.Kafka集群節點規劃

Kafka 節點規劃：一般開始搭建是根據類似 HDFS 存儲公式計算，一般1個 broker 并發為 5 萬（優化后并發更高），可以根據業務實際并發估計節點數量。

5.Zookeeper集群節點規劃

Zookeeper 節點規劃：集群開始搭建時3節點就夠用了，如果發現 zookeeper 負載過高或有超時現象時可以考慮擴展到 5 節點。

6.大數據集群廠商選擇

集群中的每個組件要做高可用，一般國企會用 CDH，互聯網公司會用開源社區版演化自己平臺。

02大數據集群硬件規劃

1.磁盤陣列概念

RAID：磁盤陣列（Redundant Arrays of Independent Disks，RAID），有"數塊獨立磁盤構成具有冗余能力的陣列”之意。

RAID0 是把多個(最少2個)硬盤合并成1個邏輯盤使用，數據讀寫時對各硬盤同時操作，不同硬盤寫入不同數據，速度快。

RAID1是通過磁盤數據鏡像實現數據冗余，在成對的獨立磁盤上產生互為備份的數據。當原始數據繁忙時，可直接從鏡像拷貝中讀取數據，因此RAID 1可以提高讀取性能。RAID 1是磁盤陣列中單位成本最高的，但提供了很高的數據安全性和可用性。當一個磁盤失效時，系統可以自動切換到鏡像磁盤上讀寫，而不需要重組失效的數據。

Raid5是把硬盤設備的數據奇偶校驗信息保存到其他硬盤設備中，“parity”部分存放的就是數據的奇偶校驗信息，換句話說，Raid5技術實際上沒有備份磁盤中的真實數據，而是當硬盤設備出現問題后，通過奇偶校驗技術來嘗試重建損壞的數據。Raid5這樣的技術特性 “妥協”的兼顧了硬盤設備的讀寫速度、數據安全性與存儲成本問題。

Raid10是Raid1和Raid0的組合體，Raid10技術至少需要4塊硬盤來組建，其中先分別兩兩制成Raid1磁盤陣列，以保證數據的安全性。然后再對兩個Raid1磁盤按陣列實施Raid0技術，進一步提高硬盤設備的讀寫速度。

2.HDFS集群硬件規劃

內存：NameNode 內存一般 100 萬個 block 對應 1G 的堆內存，比如我們最大的一個集群的 block 達到了 9000 萬，會占內容 90G，NameNode 的內存不止存放 block，我們產線環境配置的是 200G+。

磁盤：主節點NameNode主要 CPU/內存配置高些，系統盤做 RAID1，hdfs要安裝在系統盤上，如果有其他的數據盤，可以做 RAID5，容量所需不大，500G~ 1T 即可。

從節點 datanode 內存/CPU/磁盤都有要求，我們產線存儲每服務器 4T*10=40T 臺

備注：DataNode對磁盤要求比較高。

3.YARN集群硬件配置

主節點 ResourceManager 主要 CPU/內存配置高些，系統盤做 RAID1，yarn要安裝在系統盤上，如果有其他的數據盤，可以做 RAID5，容量所需不大， 500G~1T 即可。

備注：因為ResourceManager要做調度，所以CPU可以分配多一點，內存不用太大。

從節點 NodeManager 對 CPU 和內存都有要求。

備注：NodeManager一般與DataNode共用節點，對內存要求不是很高，主要是計算。

4.HBase集群硬件配置

主節點 Master CPU 內存中配就行。

從節點 RegionServer 內存可以大些。

備注：RegionServer對內存要求較高，blockcache和Memstore都需要占用內存。

5.Kafka集群硬件配置

03大數據集群目錄規劃

1.管理節點的系統盤與數據盤

OS磁盤建議RAID1，建議200G以上，并且做LVM（邏輯卷），這樣可以動 態調整OS空間大小，安裝包需要安裝在OS盤，namenode的fsimage/editlog、jouralnode的/editlog、zookeeper的數據日志都放在OS盤（RAID1）。 

管理節點的數據盤做RAID5，管理節點的數據盤如下所示： 

2.數據節點的數據盤

數據節點的數據盤做RAID0（一塊盤做RAID0，硬件RAID）作為數據盤，文件格式為xfs，并配置noatime，不做LVM，最好是同構。數據節點的數據盤： 

備注：數據盤大小建議一致，避免數據不均衡；磁盤不能做LVM，避免影響存儲性能。

04Kafka Topic分區規劃

1.Kafka磁盤規劃

• 步驟1：評估數據量：要求研發提前評估所有topic 一個周期全量的數據大小。 
• 步驟2：計算磁盤總存儲：如一塊盤 825g，一個節點 20 塊盤，10 個節點。那 

么磁盤總存儲就是 165000g。 

• 步驟3：預估實際數據存儲占比：Topic:一個周期全量數據大小占磁盤總存儲的百分比，超過百分之六十，即要求研發減少存儲周期。 
• 步驟4：計算磁盤總塊數：一個節點 20 塊盤，10 個節點，總磁盤塊數 200 個。

2.Kafka Topic分區方式1

合理預分區：所有分區數量為磁盤總數的整數倍。如所有的 topic 總數據量為 50000g，磁盤個數為 200，那么就可以設置總分區數為 200/400/600.具體多少分區數視業務決定。若分區數為 400，那么一個分區的大小約 125g。

案例1：

某一個 topic：cbss001 的預估數據量是 210g，那么通過計算（每個分區：125g）可以將其分成兩個分區。這樣根據 kafka 副本落盤策略，各個主機磁盤就能保證最大限度的存儲均衡。 

案例2：?

如果我們建立了一個非常大的 topic（100個分區），那么此 topic 的分區數量應該是磁盤數的整數倍；如果說我們還有建立一個小的 topic（如10個分區），那么此 topic 的每個分區大小應該跟之前的大的 topic 分區的大小保持一致。

3.Kafka Topic分區方式2

確定分區數量的方法：

（1）創建一個只有1個分區的topic

（2）測試這個topic的producer吞吐量和consumer吞吐量。

（3）假設他們的值分別是Tp和Tc,單位可以是MB/s.

（4）然后假設總的目標吞吐量是Tt,那么分區數=Tt/min（Tp,Tc）

kafka性能基準測試：

（1）Kafka Producer壓力測試

bin/kafka-producer-perf-test.sh  --topic test --record-size 100 --num-records 100000 --throughput -1 --producer-props bootstrap.servers=hadoop1:9092,hadoop2:9092,hadoop3:9092

說明：

record-size是一條信息有多大，單位是字節。

num-records是總共發送多少條信息。

throughput 是每秒多少條信息，設成-1，表示不限流，可測出生產者最大吞吐量。

（2）Kafka Consumer壓力測試

bin/kafka-consumer-perf-test.sh --broker-list hadoop1:9092,hadoop2:9092,hadoop3:9092 --topic test --fetch-size 10000 --messages 10000000 --threads 1

參數說明：

--zookeeper 指定zookeeper的鏈接信息

--topic 指定topic的名稱

--fetch-size 指定每次fetch的數據的大小

--messages 總共要消費的消息個數

05HBase 表Region規劃

1.業務場景

每天寫入5億+條數據

每天寫入176G+數據量

region分裂大小為10G

TTL為20天

rowkey為手機號

2.預建分區個數

預建分區的個數=最終保有的數據量/每個regin配置的大小

（1）Region最大值推薦10-20Gb, 最優值推薦5-10Gb。

（2）數據總量=176*20=3520G

3.預分區實現

方法一：

admin.createTable(tabledesc,startkey,endkey,numRegion)

方法二：

admin.createTable(tableDesc ,splitKeys);?