從0到1構建大數據平臺，如何規劃集群硬件與軟件
?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);?
