存儲能力詳細方案-參考

Hadoop存儲能力詳細方案Hadoop采用HDFS作為其底層文件存儲方式。HDFS是分布式文件系統(tǒng)，適合于存儲大數(shù)據(jù)文件，通過將大數(shù)據(jù)文件切分成多個小數(shù)據(jù)文件，并且分散存放在多臺DataNode服務(wù)器，同時提供數(shù)據(jù)冗余機制保證數(shù)據(jù)安全。本次Hadoop存儲節(jié)點為：300臺DataNode服務(wù)節(jié)點。存儲數(shù)據(jù)安全及分配機制：采用3備份機制保證數(shù)據(jù)安全，同時為系統(tǒng)保留10%的臨時數(shù)據(jù)交換空間，當數(shù)據(jù)量超過集群總?cè)萘康?0%時，建議增加節(jié)點。存儲總?cè)萘浚?00臺數(shù)據(jù)節(jié)點，每個節(jié)點36T的磁盤容量，除去10%的臨時數(shù)據(jù)交換空間，同時HDFS中一份數(shù)據(jù)存放著3份備份；最終存儲容量公式如下可用存儲容量=節(jié)點數(shù)*單節(jié)點磁盤容量*（1-臨時數(shù)據(jù)交換空間比例）÷HDFS文件備份數(shù)量；即：可用存儲容量=300×36×（1-10%）÷3=3240T；目錄規(guī)劃：針對不同的數(shù)據(jù)用途和支撐方式進行存儲容量劃分，存放在HDFS中的數(shù)據(jù)分為接口層，處理層，共享層。接口層主要為原始數(shù)據(jù)，處理層為存放在HDFS中數(shù)據(jù)經(jīng)Hive映射之后數(shù)據(jù)，共享層為經(jīng)數(shù)據(jù)深度沉淀之后存放在HBase中。接口層：總?cè)萘?50%處理層：總?cè)萘?30%共享層：總?cè)萘?20%Storm存儲能力詳細方案Storm流數(shù)據(jù)處理采用linux文件系統(tǒng)作為其存儲，數(shù)據(jù)盤采用raid5保證數(shù)據(jù)安全。存儲總?cè)萘繛椋?0臺服務(wù)器，每臺36T，采用Raid5磁盤陣列之后，數(shù)據(jù)容量為原來的75%，并建議預(yù)留10%的空間；最終可用存儲計算公式如下：可用存儲容量=節(jié)點數(shù)*單節(jié)點磁盤容量*Raid5后的磁盤容量比例*（1-臨時數(shù)據(jù)交換空間比例）；即：可用存儲容量=30×36×75%×（1-10%）=729T；Redis存儲能力詳細方案Redis包含平臺Redis內(nèi)存數(shù)據(jù)庫和前置Redis內(nèi)存數(shù)據(jù)庫，平臺Redis內(nèi)存數(shù)據(jù)庫集群用于存放Storm處理后數(shù)據(jù)，對外提供低延遲數(shù)據(jù)服務(wù)；前置Redis內(nèi)存數(shù)據(jù)庫存放應(yīng)用級數(shù)據(jù)對外提供服務(wù)。平臺Redis內(nèi)存數(shù)據(jù)庫集群：集群通過一臺路由服務(wù)器根據(jù)一套算法將表的Key值打算后分散存放到7個RedisMaster服務(wù)器中，同時每一個Master節(jié)點對應(yīng)一個Slave節(jié)點保證數(shù)據(jù)安全，通過路由服務(wù)器實現(xiàn)高可用。存儲容量為：14臺數(shù)據(jù)服務(wù)器，7個Master節(jié)點，對應(yīng)7個Slave節(jié)點，每一節(jié)點內(nèi)存為512G，為保證KV查詢的高效性，建議預(yù)留30%的空間；最終可用存儲計算公式如下：可用存儲容量=節(jié)點數(shù)÷熱備*單節(jié)點內(nèi)存容量*（1-預(yù)留空間比例）；即：可用存儲容量=14÷2×512×（1-30%）=2508.8G；前置Redis內(nèi)存數(shù)據(jù)庫：前置Redis內(nèi)存數(shù)據(jù)庫中，數(shù)據(jù)表分別分別存放在不同的節(jié)點，同時內(nèi)存中數(shù)據(jù)定期備份到本地和遠程磁盤，通過該方式在保證了數(shù)據(jù)安全的同時針對多租戶的場景實現(xiàn)了資源隔離。存儲容量為：前置數(shù)據(jù)服務(wù)器，每一節(jié)點內(nèi)存為512G，為保證KV查詢的高效性，建議預(yù)留30%的空間，最終可用存儲計算公式如下：可用存儲容量=節(jié)點數(shù)÷熱備*單節(jié)點內(nèi)存容量*（1-預(yù)留空間比例）；即：可用存儲容量=4×512×（1-30%）=1433.6；Mysql存儲能力詳細方案Mysql關(guān)系型數(shù)據(jù)庫存儲放深度匯總模型數(shù)據(jù)，支撐能力封裝組件，為上層應(yīng)用提供數(shù)據(jù)服務(wù)器；其中支撐業(yè)務(wù)數(shù)據(jù)節(jié)點數(shù)為8臺，管控數(shù)據(jù)節(jié)點數(shù)為2臺。業(yè)務(wù)數(shù)據(jù)MySql數(shù)據(jù)庫：Mysql服務(wù)器的數(shù)據(jù)存儲將采用Raid5磁盤陣列劃分，以滿足數(shù)據(jù)安全及高可用性。服務(wù)器存儲容量：8臺MySql服務(wù)器，每臺24T，采用Raid5磁盤陣列，存來源于多個系統(tǒng)的同構(gòu)、異構(gòu)多種數(shù)據(jù)，數(shù)據(jù)的導(dǎo)入、轉(zhuǎn)換、加載完全可視化，實現(xiàn)快速開發(fā)部署能力，有效降低操作門檻，提升工作效率。分布式ETL對于能力平臺的構(gòu)建提供了如下的能力支撐：支撐能力平臺的分布式運行和多類計算任務(wù)的統(tǒng)一管控分布式ETL對平臺所構(gòu)建的分布式環(huán)境是必不可缺的支撐基礎(chǔ)，對于各個集群上的分布式處理任務(wù)提供統(tǒng)一的管理，并對計算運行過程進行實時監(jiān)控和異常預(yù)警，實現(xiàn)平臺計算任務(wù)的統(tǒng)一工作臺管理支撐。提供底層數(shù)據(jù)處理技術(shù)的統(tǒng)一封裝與能力支撐分布式ETL提供了一套可視化的通用的數(shù)據(jù)處理組件，通過流程化的運算邏輯定義、封裝和調(diào)度管理，為開發(fā)實現(xiàn)提供了一套高效易用的數(shù)據(jù)處理支撐框架，降低了技術(shù)人員對于底層技術(shù)的掌握門檻，便于支撐面向業(yè)務(wù)應(yīng)用的快速服務(wù)與響應(yīng)。數(shù)據(jù)容量估算本期工程各類數(shù)據(jù)規(guī)模如下表所示，總計原始用戶數(shù)據(jù)容量約為6588TB。數(shù)據(jù)分類數(shù)據(jù)類型數(shù)據(jù)內(nèi)容要求數(shù)據(jù)容量（單周期原始數(shù)據(jù)量，TB）數(shù)據(jù)容量（15年底系統(tǒng)保存數(shù)據(jù)需求，TB）備注當前15年底接口/整合層模型應(yīng)用層小計網(wǎng)絡(luò)數(shù)據(jù)移動DPI、移動AAA數(shù)據(jù)內(nèi)容詳見《中國電信移動分組域數(shù)據(jù)信息采集設(shè)備技術(shù)要求（發(fā)布版本)》294614264141840移動DPI清單率設(shè)為50%設(shè)備配置推算Hadoop分布式集群建議采用本地存儲方式（數(shù)據(jù)存儲在各PC服務(wù)器本地磁盤上），對照可參考案例，對于常規(guī)數(shù)據(jù)分析，Hadoop平臺數(shù)據(jù)處理平臺節(jié)點需求數(shù)主要由數(shù)據(jù)處理量需要的存儲節(jié)點數(shù)量，同時考慮計算節(jié)點能力需求。詳細計算過程如下表所示：存儲能力測算系統(tǒng)數(shù)據(jù)容量6558TB壓縮比0.5備份數(shù)3空間冗余1.20所需存儲容量=系統(tǒng)數(shù)據(jù)容量*壓縮比*備份數(shù)*空間冗余11858.42TB存儲節(jié)點需求單節(jié)點掛載存儲量36TB所需存儲節(jié)點數(shù)=所需存儲容量/單節(jié)點掛載存儲量330臺計算能力測算日增量（G）14992