問題導讀
1.如何判斷數據增量？
2.QPS如何計算？
3.存儲空間需要考慮哪些因素？
4.內存估算和哪些因素有關？
我們在實際工作，或者面試中，經常會遇到這麼一個問題，集羣該如何規劃，一臺機器多少磁盤，多少內存，多少core等。
關於公司集羣規模，有的幾臺，有的幾百或有的則幾千臺，那麼這幾百幾千臺機器他們的配置是怎麼樣的？
這裏先說下大概，對於大多數公司來說，集羣有的10來臺，而對於電信行業，一個地方的可能有幾百臺，對於一線互聯網集羣規模就比較大一些，上千臺是比較常見的。
那麼如果我們要搭建大數據平臺，集羣該如何規劃？這是我們初步搭建集羣的時候，首次遇到的問題。
對於需要多少臺機器，其實這個問題，不能一刀切的回答，具體情況具體分析。雖然一開始我們不知道多少臺機器，但是我們可以知道影響的關鍵因素？
那就是數據的增量是多少？
數據的增量，這裏我們來說下數據增量：
其實數據的增量不同的公司，也是不一樣的，有的公司數據增量也就是幾個G，而有的公司數據增量1T以上，比如物聯網大數據。除了數據增量，還有其它影響因素，比如使用的計算組件，使用MapReduce和Spark,Flink在內存的使用上，肯定是有區別的。再比如QPS也影響着系統的資源分配。
除了影響因素，那麼我們預估集羣包含哪些步驟？
1.判斷計算數據增量大小
如何計算數據量得大小，這個其實很多企業已有相關得系統，只不過數據得處理更換爲大數據。所以數據增量已經非常明確。如果我們不知道增量是多少，那麼我們就需要計算下。
如每天1億的請求，每個大概2KB，則增量爲190G。
計算過程：
2KB轉換爲G=2/1024/1024
（2/1024/1024）*100000000約等於190G
2.QPS計算與評測
QPS這裏我們首先需要計算大概是多少，同時我們需要評測一臺物理機大概能支撐多少QPS。
QPS或許我們有些成員比較陌生，可以參考
記一次性能優化，單臺4核8G機器支撐5萬QPS
https://www.aboutyun.com/blog-61-4365.html
我們或許聽說過，如果新浪微博明星發微博，比如結婚，離婚等事件，那麼新浪就要頂不住了，就需要臨時增加服務器，所以導致新浪程序員假期加班。其中原因之一就是QPS過多，導致服務器壓力增大。
假如集羣1億的請求，對於一些網站而言，比如About雲社區，電商社區等，一般0點到上午8點請求量很小。一般高峯期爲上午10點，下午4，5點請求量比較大，當然每個社區或者電商時間點，有所區別。
也就是80%的數據( 0.8億)會在其餘16個小時（8點-24點）湧入，20%時間( 3小時內)湧入:
QPS= 80 000 000/ (10800)約等於7407條。
即預估結果集羣需要在業務最高峯期抗住 7407/s的QPS。
上面是我們評估在高峯期QPS。如果資源充足，讓高峯期QPS控制在集羣能承載的總QPS的30%左右是比較安全的策略，即應設計集羣承載QPS上限爲2萬~3萬/s 纔是安全的。
對於物理機，我們可以進行測試，一般來說一臺物理機可穩定支持4萬QPS。關於QPS測試方法很多種，比如WRK
QPS性能測試工具WRK的簡明教程
https://www.aboutyun.com/blog-61-4366.html
更多我們可以自己搜索。
3.存儲預估
存儲的預估，這裏其實還是涉及到我們是如何對待這些數據的，比如有些數據有效期是一年，有的則是長期存儲等。這裏我們就以長期存儲保留。對於時間上來說，一般是三年內不需要增加磁盤。
我們就以數據增量爲190G來計算，對於大數據存儲，比如hdfs存儲副本默認爲3，那麼190G*3=570G，也就是說一天大概存儲570G。
570G*3*365=624150G大概爲609T。也就是就存儲來說大概需要609T的磁盤。但是一般集羣存儲不超過80%，609T/0.8大概需要760T。
如果一臺機器是20T，那麼我們需要38臺機器。
4.內存估算
內存估算，內存的估算其實這個是沒有絕對標準，有的公司使用Flink處理物聯網數據，只用了幾臺不到10G的機器就可以處理。所以內存的估算其實不同的組件，執行多少任務，多少實時任務，離線任務、算法模型等，區別比較大。
一般實時任務佔用的資源都是固定的，可以根據業務個數估算。離線任務可以根據ETL任務數和任務資源配置情況估算，計算資源離線和實時同時啓用的時候不能超過資源90%。實時任務資源佔用需要小於50%，如果數據增量爲190G，實時任務7407/s的QPS，一分鐘窗口444420*（2/1024/1024）=0.85G,有的設置5分鐘窗口，那麼大概是4.25G。如果離線任務，可以把1/4的數據放到內存，那就就需要47.5G的內存。如果二者同時運行，按照不超過90%來計算，需要57.5G。
上面只是單純的從實時和離線單任務來計算，可以選擇64G內存。
5.CPU估算
CPU和內存比例，一般爲1：2或者1：4，當然具體需要看有多少線程。
我們以Kafka爲例：
Kafka進程裏面大概有多少線程：
1個Accept線程
默認的3個Process線程（一般會設置爲9個）
默認的8個RequestHandler工作線程（可以設置爲32個）
清理日誌的線程
感知Controller狀態的線程
副本同步的線程
估算下來Kafka內部有100多個線程
實際計算
4個cpu core，一般來說幾十個線程，在高峯期CPU幾乎都快打滿了。
8個cpu core，也就能夠比較寬裕的支撐幾十個線程繁忙的工作。所以Kafka的服務器一般是建議16核，基本上可以hold住一兩百線程的工作。當然如果可以給到32 cpu core那就最好不過了！【參考】
總結
上面其實結果並不重要，重要的是我們是如何計算的，大家可以根據自己的環境和需求來估算大概需要的配置和機器數目。
校稿：凌霄子、鳥叔