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