點(diǎn)擊上方 "大數(shù)據(jù)肌肉猿"關(guān)注,?星標(biāo)一起成長
點(diǎn)擊下方鏈接，進(jìn)入高質(zhì)量學(xué)習(xí)交流群
今日更新| 1052個轉(zhuǎn)型案例分享-大數(shù)據(jù)交流群
編?輯：彭文華
來 源：大數(shù)據(jù)架構(gòu)師（ID：bigdata_arch）
怎么預(yù)估大數(shù)據(jù)集群所需的內(nèi)存容量？這個問題是大數(shù)據(jù)架構(gòu)師的高頻面試題，但是更關(guān)鍵的是在項目中更是必備的技能。因為這會涉及到服務(wù)器的選擇和成本核算。
因此必須既能滿足現(xiàn)有的需求，又不能超過，還能保證持續(xù)、穩(wěn)定的使用。雖然現(xiàn)在有云服務(wù)器，隨時可以擴(kuò)容，但提需求的時候總得說一個依據(jù)，否則顯得非常不專業(yè)。
今天就給大家徹底解決這個問題。
雖然彭友問的是怎么估算內(nèi)存的資源，但是咱得擴(kuò)展一下。作為架構(gòu)師/項目經(jīng)理，面臨的問題是一個項目要啟動，我們需要申請多少資源才能滿足項目需求？
如果是要解決這個問題，那么最少要從網(wǎng)絡(luò)資源、存儲、內(nèi)存、CPU四個方面進(jìn)行預(yù)估。
服務(wù)器資源評估的交付物是一個類似的服務(wù)器需求單：
一般的時候我們評估資源有幾個方法：
1、經(jīng)驗預(yù)估：大佬專屬，看一眼需求就知道得分配多少資源；
2、參考預(yù)估：根據(jù)以前差不多項目的經(jīng)驗，對照參考預(yù)估；
3、技術(shù)預(yù)估：根據(jù)技術(shù)參數(shù)要求，進(jìn)行細(xì)致的計算后得出。
第1、2種方法在這就不講了，一個要牛人，一個要類似項目。這個也沒法跟彭友們說呀~~~
其實(shí)就是一些預(yù)估的原則，框定大致的范圍，這樣也比較科學(xué)。我簡單總結(jié)了幾個原則，供你參考：
1、最小可用原則：就是不要胡亂拍腦袋。很多人為了免責(zé)，參數(shù)就得往高了報，造成極大的資源浪費(fèi)；
2、高可靠高可用原則：訪問是有波峰波谷的，我們必須要確保集群在日常正常工作的同時，能抗住波峰的流量，一般來說，波峰波谷的時間占比大概都是28分布；應(yīng)用服務(wù)器也得考慮單節(jié)點(diǎn)故障問題；
3、可擴(kuò)展原則：需要考慮集群擴(kuò)展的場景，因此類似用途的服務(wù)器盡量要用相同規(guī)格；
4、便于運(yùn)維：需要結(jié)合團(tuán)隊的實(shí)力、技能等情況綜合考慮，更多的是人為的因素。
一般來說，我們需要綜合考慮需求項目的所有技術(shù)參數(shù)、技術(shù)選型，綜合進(jìn)行規(guī)劃。要畫出網(wǎng)絡(luò)拓?fù)鋱D，規(guī)劃每臺服務(wù)器的用途，根據(jù)用途、訪問需求、數(shù)據(jù)存量增量綜合預(yù)估。
但是網(wǎng)絡(luò)拓?fù)溥@個不在今天的討論范圍內(nèi)，所以就略過了；技術(shù)選型情況比較多，也無法一一遍歷，所以只能給一個普適性的評估方法。
彭友們在評估的時候，根據(jù)技術(shù)進(jìn)行調(diào)整就行了。比如離線和實(shí)時服務(wù)器所需的資源就不一樣了，離線偏重存儲，實(shí)時偏重計算。
網(wǎng)絡(luò)預(yù)估的指標(biāo)是TPS（Transactions Per Second 每秒處理事務(wù)數(shù)量）和QPS（Query Per Second 每秒查詢數(shù)量）。大家說的吞吐量就是通過這兩個指標(biāo)來衡量的。公式1：QPS =?設(shè)計并發(fā)數(shù)/平均響應(yīng)時間系統(tǒng)設(shè)定的同一時間并發(fā)用戶訪問的數(shù)量，以及系統(tǒng)的響應(yīng)效率，決定了QPS。
現(xiàn)在有些項目中直接就確定了QPS、并發(fā)數(shù)、平均響應(yīng)時間三個技術(shù)指標(biāo)，這時候就不用算了，直接照著這個做就行。但是也有其他情況，比如IoT的數(shù)據(jù)，這個非常規(guī)律，要么是24小時非常穩(wěn)定的，要么就是非常有節(jié)奏，工作時間穩(wěn)定，工作時間之外就停了；還有互聯(lián)網(wǎng)的情況，就比較亂了，分布的即為不均勻?；旧鲜窃纭⒅?、晚三個高峰，要么是上午、下午、晚上三個高峰。這跟網(wǎng)站、APP的性質(zhì)不一樣而各異。這時候我們設(shè)定一個估算方法就行了。比如按下面這個公式：公式2：波峰QPS=（全天數(shù)據(jù)查詢量*波峰數(shù)據(jù)量占比）/（每天3600秒*波峰時間）上面的參數(shù)可以自己調(diào)整，也可以再加幾個其他合理的參數(shù)就行了。大概的意思就是根據(jù)全天的數(shù)據(jù)接入需求，設(shè)定合理的假設(shè)，比如80%的數(shù)據(jù)都在20%波峰時間涌入，這樣就能算出波峰QPS了。1、高配：即抗住波峰*30%，留出余量；
2、中配：抗住波峰即可；
這時候會根據(jù)系統(tǒng)的需求進(jìn)行選擇，或者參考用來進(jìn)行工作量評估的三點(diǎn)估算法推算出一個最可能的值作為參考。即：最可能的值Te=（1份最差的結(jié)果（峰值最高）+4份波峰+1份小波峰）/6
當(dāng)然，上面只是參考而已，需要根據(jù)實(shí)際情況進(jìn)行調(diào)整。比如有些系統(tǒng)實(shí)時性不是特別高，選低配就行了，沒及時處理的，等波峰過了之后慢慢處理都行；有些用戶實(shí)時性要求高、敏感度高的，那就選中高配，確保波峰能過去。同時啟動熱點(diǎn)監(jiān)測，跟技術(shù)的朋友一起做一個彈性擴(kuò)容，確保波峰再大，都能實(shí)施擴(kuò)容，確保高可靠搞可用。1、根據(jù)設(shè)計的每天數(shù)據(jù)接入量，計算波峰QPS（公式1）;
2、根據(jù)歷史數(shù)據(jù)推算波峰QPS（把歷史QPS拉出來看看就知道了）；
3、根據(jù)并發(fā)數(shù)和平均響應(yīng)時間計算QPS（公式2）。
平均響應(yīng)時間可以用測試的方式得到，各種自動化測試工具都能搞定。非常簡單，輸入并發(fā)數(shù)，然后跑一下就能得到不同并發(fā)數(shù)下的平均響應(yīng)時間。
一般來說，現(xiàn)在的網(wǎng)卡帶寬都很大，費(fèi)用也不貴，基本上選個千兆、萬兆網(wǎng)卡就沒問題了，有些人就說計算QPS沒啥用。
但是老彭仍然建議算好QPS，因為這是后面存儲、計算的根據(jù)之一。
存量部分還是比較好算的，就是得統(tǒng)計一下各系統(tǒng)的數(shù)據(jù)量就行了，最多加一個接入計劃。
另外，存量數(shù)據(jù)也需要分成冷熱數(shù)據(jù)，有條件的話，熱數(shù)據(jù)放在SSD等高速存儲里；冷數(shù)據(jù)可以扔到OSS、SAS機(jī)械硬盤，或者壓縮一下，減少存儲成本。如果有數(shù)據(jù)退役的管理，那么可以根據(jù)退役流程進(jìn)行轉(zhuǎn)錄到磁帶機(jī)或者直接銷毀。2、增量部分，這個需要考慮幾個事情，第一個是應(yīng)用系統(tǒng)的接入，在統(tǒng)計存量數(shù)據(jù)的時候順便調(diào)研一下就好了；第二個是IoT、日志等數(shù)據(jù)源的接入。這時候就得根據(jù)QPS計算了。一般來說，每個QPS或者IoT的數(shù)據(jù)量是相對比較恒定的，為了方便計算，我們假定是每條數(shù)據(jù)10kb。
10KB*10000000條*3個備份=288GB
上面的幾個參數(shù)都可以進(jìn)行調(diào)整，比如每條數(shù)據(jù)的大小可能根本不用10kb，備份也不用3個，2個就行了等等。如果是流式數(shù)據(jù)，還要加一個保留數(shù)據(jù)的時間參數(shù)，比如保留最近3天的數(shù)據(jù)，就再*3就行了。這個時候就可以計算集群中每臺服務(wù)器的存儲要求了。比如我們計算出來存量10000G，日增量100G，集群中datanode一共10臺，那么每臺1T（1024G）就只能剛剛夠放存量的。
而每臺2T，則可以用（10臺*2048G-10000G）/100G=104天。我們按照需求進(jìn)行規(guī)劃、調(diào)整即可。如果是云服務(wù)器，可以整個半年的量，實(shí)時監(jiān)測，提前增量即可；如果是物理服務(wù)器，可以增設(shè)磁盤陣列，也可以滿足需求。
我們監(jiān)測的時候設(shè)一根報警線就行，一般來說，存儲的預(yù)警值是80%，預(yù)留20%空間，及時擴(kuò)容即可。
這個得完全根據(jù)技術(shù)方案來。離線和實(shí)時不一樣，增量和全量也不一樣，ETL、預(yù)計算、跑模型都不一樣。有些要把大量數(shù)據(jù)放內(nèi)存里，非常吃內(nèi)存，有些要開N個線程，瘋狂吃CPU。比如ClickHouse相對來說就比較吃CPU，對CPU的要求就要高一些。假設(shè)我們只有10個Topic，每個Topic有5個Partition，但是需要存3個副本，有3臺kafka服務(wù)器，常駐內(nèi)存只要最近的30%，那么：（10Topic*5Partition*3副本*1G文件*0.3內(nèi)存）/3臺服務(wù)器=15G。我們選擇16G很危險，建議選用32G內(nèi)存即可。
假設(shè)我們QPS1000次/秒，F(xiàn)link窗口設(shè)為5分鐘，每條數(shù)據(jù)10KB，那么可得出所需內(nèi)存為3GB。
假設(shè)我們有10T的全量數(shù)據(jù)，每天增100G，離線數(shù)據(jù)其實(shí)不會一次性把所有數(shù)據(jù)入內(nèi)存計算，所以比例會少很多。按這個計算，我們所需的內(nèi)存是：
（10T+100G）*0.02入內(nèi)存占比/6臺服務(wù)器，每臺服務(wù)器需要34GB的內(nèi)存，這個很尷尬，要么加幾臺服務(wù)器，要么選64G的內(nèi)存，要么降低我們?nèi)腭v內(nèi)存的比率，或者通過合理的流程削峰填谷。至于CPU的預(yù)估，一般按照CPU：內(nèi)存1:2、1:4（推薦）的比例直接算出來就行了。64G的內(nèi)存，選擇16core就夠了。除非是ClickHouse或者開N個線程的特別吃CPU的組件，可以放大一些，按1:2比例，選32core的。以上是單獨(dú)預(yù)估的。但是作為架構(gòu)師，需要全盤考慮。存儲的還得考慮NameNode和DataNode的區(qū)別，ZooKeeper等管理組件和其他組件共用服務(wù)器的情況，實(shí)時、離線任務(wù)一起跑的情況、熱點(diǎn)應(yīng)對等各類情況，這就不再細(xì)說了。
--end--
可私聊交流，也可進(jìn)資源豐富學(xué)習(xí)群
更文不易，點(diǎn)個“在看”支持一下??
