集群規(guī)模計算
集群規(guī)模取決于用戶數(shù)據(jù)及應(yīng)用需求，最終規(guī)劃值為以下各種計算方式得出的最小集群規(guī)模的最大值
? 容量需求
– 估算相對容易且準確
– 大多數(shù)案例可以通過容量來決定集群規(guī)模
? 計算需求
– 準確的估算計算資源只能通過小規(guī)模測試并合理估算
? 其他資源限制
– 如用戶MapReduce應(yīng)用可能對內(nèi)存等資源有特殊要求，且單節(jié)點可配置資源相對有限，則集群最小規(guī)模需滿足用戶此類資源要求

創(chuàng)新互聯(lián)公司成立十年來，這條路我們正越走越好，積累了技術(shù)與客戶資源，形成了良好的口碑。為客戶提供成都做網(wǎng)站、網(wǎng)站制作、網(wǎng)站策劃、網(wǎng)頁設(shè)計、主機域名、網(wǎng)絡(luò)營銷、VI設(shè)計、網(wǎng)站改版、漏洞修補等服務(wù)。網(wǎng)站是否美觀、功能強大、用戶體驗好、性價比高、打開快等等，這些對于網(wǎng)站建設(shè)都非常重要，創(chuàng)新互聯(lián)公司通過對建站技術(shù)性的掌握、對創(chuàng)意設(shè)計的研究為客戶提供一站式互聯(lián)網(wǎng)解決方案，攜手廣大客戶，共同發(fā)展進步。

網(wǎng)絡(luò)建議
? 建議使用萬兆網(wǎng)絡(luò)或更高速度網(wǎng)絡(luò)
– 如要充分利用磁盤并行操作帶寬，至少需要萬兆網(wǎng)絡(luò)
– 即使帶寬足夠，使用高帶寬網(wǎng)絡(luò)也能帶來性能提升
? 對網(wǎng)絡(luò)帶寬敏感的場景：
– ETL類型或其他高輸入輸出數(shù)據(jù)量的MapReduce任務(wù)
– 對于空間或者電力資源有限的環(huán)境中，可使用大容量節(jié)點并配合高速度網(wǎng)絡(luò)
– HBase等時延敏感類應(yīng)用也對網(wǎng)絡(luò)傳輸速度有要求

傳統(tǒng)樹狀網(wǎng)絡(luò)
? 網(wǎng)絡(luò)超額(Oversubscription)
– 通過增加層次擴充網(wǎng)絡(luò)，但會有如下問題
– 節(jié)點間網(wǎng)絡(luò)距離增加
– 網(wǎng)絡(luò)超額問題惡化
? 因此盡量采用超多端×××換機或擴充交換機背板擴充端口容量
– 小型或中型網(wǎng)絡(luò)可以使用雙層樹形架構(gòu)
– 僅通過頂層交換機上行端口和外部系統(tǒng)進行交互
– 避免Hadoop的網(wǎng)絡(luò)傳輸風暴污染外部網(wǎng)絡(luò)

組件架構(gòu)
? 管理節(jié)點(Head/Master Node)：如NameNode, Yarn及Master等
– 提供關(guān)鍵的、集中的、無替代的集群管理服務(wù)
– 若該管理服務(wù)停止，則對應(yīng)集群Hadoop服務(wù)停止
– 需要可靠性高的硬件設(shè)備
? 數(shù)據(jù)節(jié)點(Data/Worker/Slave Node)
– 處理實際任務(wù)，如數(shù)據(jù)存儲，子任務(wù)執(zhí)行等
– 同節(jié)點運行多個服務(wù)，為保證局部性
– 若該服務(wù)停止，則由其他節(jié)點自動代替服務(wù)
– 硬件各部件皆可能損壞，但能方便的替換
? 邊緣節(jié)點(Edge Node)
– 對外提供Hadoop服務(wù)代理以及包裝
– 作為客戶端訪問實際Hadoop服務(wù)
– 需要可靠性高的硬件設(shè)備

管理節(jié)點硬件要求
? 管理節(jié)點角色主要包括NameNode，Secondary NameNode，Yarn RM
– Hive Meta Server以及Hive Server通常部署在管理節(jié)點服務(wù)器上
– Zookeeper Server以及Hmaster可以選取數(shù)據(jù)節(jié)點服務(wù)器，由于一般負載有限，對節(jié)點無太大特殊要求
– 所有HA候選服務(wù)器(Active以及Standby)使用相同配置
– 通常對內(nèi)存要求高但對存儲要求低
? 建議使用高端PC服務(wù)器甚至小型機服務(wù)器，以提高性能和可靠性
– 雙電源、冗余風扇、網(wǎng)卡聚合、RAID…
– 系統(tǒng)盤使用RAID1
– 由于管理節(jié)點數(shù)目很少且重要性高，高配置一般不是問題

數(shù)據(jù)節(jié)點配置策略建議
? 數(shù)量少但單點性能高的集群 vs. 數(shù)量多但單點性能低的集群
– 一般而言，使用更多的機器而不是升級服務(wù)器配置
– 采購主流的最”合算”配置的服務(wù)器，可以降低整體成本
– 數(shù)據(jù)多分布可獲得更好的scale-out并行性能以及可靠性
– 需要考慮物理空間、網(wǎng)絡(luò)規(guī)模以及其他配套設(shè)備等綜合因素來
? 考慮集群服務(wù)器數(shù)目
– 計算密集型應(yīng)用考慮使用更好的CPU以及更多的內(nèi)存

內(nèi)存需求計算
? 需要大內(nèi)存的主節(jié)點角色：
– NameNode, Secondary NameNode,YARN AM, Hbase Regionserver
? 節(jié)點內(nèi)存算法：
– 大內(nèi)存角色內(nèi)存相加
– 計算類應(yīng)用需要大內(nèi)存，如Spark/Impala建議至少256GB內(nèi)存

硬盤容量選擇
? 通常建議使用更多數(shù)目的硬盤
– 獲得更好的并行能力
– 不同的任務(wù)可以訪問不同的磁盤
– 8個1.5TB的硬盤性能好于6個2TB的硬盤
– 除去數(shù)據(jù)永久存儲需求外，一般建議預(yù)留20%至30%的空間用于存儲臨時數(shù)據(jù)
? MapReduce任務(wù)中間數(shù)據(jù)
? 實際部署中每服務(wù)器配備12個硬盤非常常見
– 單節(jié)點存儲容量最大值不超過48TB

存儲服務(wù)需求

數(shù)據(jù)源	Hadoop方式物理存儲容量	數(shù)據(jù)節(jié)點數(shù)量
原始文件、數(shù)據(jù)量 625T	625TB3(復(fù)制份數(shù))0.3(壓縮比)/80%(硬盤利用率)=703TB(只存放明細數(shù)據(jù)，無表，無MR）	按30T每節(jié)點703TB/30*1.05(冗余度)=25 臺
Hbase 和 Cassandra	數(shù)據(jù)服務(wù)：假設(shè)歷史數(shù)據(jù)量為2.6T，每日增量為55G，數(shù)據(jù)保留365天，3副本使用壓縮時：( 2.6 + 0.055365 ) 1.3*1.2（key開銷）/70%(硬盤利用率)=51T	按30T每節(jié)點51T/30*1.3(冗余度)=3臺打開WAL時需增加：region server wal大小(通常小於RS內(nèi)存的一半)

服務(wù)器配置建議

	管理服務(wù)器	數(shù)據(jù)服務(wù)器	邊緣服務(wù)器
CPU	2*E5-2620v4	2*E5-2620v4	2*E5-2620v4
硬盤	SAS 600GB*4；RAID0+1	SAS 600GB2；SATA? 2T15	SAS 600GB2；SATA? 2T15
內(nèi)存	256G ECC	256G ECC	256G ECC
網(wǎng)絡(luò)	雙萬兆網(wǎng)卡	雙萬兆網(wǎng)卡	雙萬兆網(wǎng)卡
數(shù)量	3	30	3

網(wǎng)站欄目：CDH初期集群構(gòu)建方案建議
轉(zhuǎn)載來于：http://www.rwnh.cn/article14/jdgpge.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供動態(tài)網(wǎng)站、、Google、企業(yè)網(wǎng)站制作、關(guān)鍵詞優(yōu)化、面包屑導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)