專4-5-360云盤底層Cassandra+Storm介紹－郭東東,倪傳雷

360云盤底層Cassandra+Storm介紹郭東東、倪傳雷?Cassandra+Storm整體架構(gòu)及現(xiàn)狀?Cassandra系統(tǒng)改進(jìn)及實踐?Storm系統(tǒng)改進(jìn)及實踐Cassandra+Storm集群現(xiàn)狀?集群規(guī)模主機(jī)規(guī)模備份規(guī)模數(shù)據(jù)規(guī)模單日新增13000臺8000臺400PB500TB單集群規(guī)模集群容量150臺(24/3T)9P300臺(24/3T)P600臺(36/4T)79PIDC3Cassandratorm聯(lián)通Cassandra+Storm集群現(xiàn)狀I(lǐng)DC3Cassandratorm聯(lián)通IDC1業(yè)務(wù)接入層CassandratormIDC2業(yè)務(wù)接入層Cassandratorm業(yè)務(wù)接業(yè)務(wù)接入層IDC21業(yè)務(wù)接入層CassandratormIDC22業(yè)務(wù)接入層CassandratormIDC23業(yè)務(wù)接入層CassandratormCassandra系統(tǒng)改進(jìn)-數(shù)據(jù)可靠性?主要問題：–扇區(qū)、磁盤故障、主機(jī)故障導(dǎo)致副本缺失–新寫入數(shù)據(jù)副本可能不足(ONE/QUORUM)–系統(tǒng)自帶機(jī)制不能保證副本及時修復(fù)：Cassandra系統(tǒng)改進(jìn)-數(shù)據(jù)可靠性?文件/磁盤自動摘除?去腐生肌?消除影響–基于統(tǒng)計?文件異常訪問次數(shù)?摘除文件比例Cassandra系統(tǒng)改進(jìn)-數(shù)據(jù)可靠性?數(shù)據(jù)節(jié)點定期掃描修復(fù)?磁盤/文件故障摘除即啟動修復(fù)?盡快恢復(fù)全副本的狀態(tài)?確定故障所屬Range?RowScan+Diff?KeyScan+Read(ALL)Cassandra系統(tǒng)改進(jìn)-數(shù)據(jù)可靠性?增量數(shù)據(jù)的檢查修復(fù)?保證新寫入數(shù)據(jù)副本數(shù)足夠?解決hinthandoff缺點?副本不足記入輔助表–數(shù)據(jù)節(jié)點寫失?。撼瑫r/拒絕–數(shù)據(jù)節(jié)點停機(jī)?讀修復(fù)Cassandra系統(tǒng)改進(jìn)-數(shù)據(jù)分配策略?主要問題：–基于集群的數(shù)據(jù)Partition策略，不靈活–不同Keyspace根據(jù)數(shù)據(jù)類型及訪問需求，需要不同的Partition策略–部分KeySpace有范圍Scan的需求Cassandra系統(tǒng)改進(jìn)-數(shù)據(jù)分配策略?基于KeySpace的Partition策略：–支持RandomPartitioner和ByteOrderedPartitioner–修改表的Meta信息存儲，增加Partition策略–增加不同Partition的Token對應(yīng)關(guān)系–修改訪問接口內(nèi)部實現(xiàn)，實現(xiàn)不同Partition的兼容性Cassandra系統(tǒng)改進(jìn)-EraserCode?主要問題：–數(shù)據(jù)規(guī)模原來越大，儲存成本越來越高–SimpleStrategy,NetworkTpStrategy存儲3副本成本太高Cassandra系統(tǒng)改進(jìn)-EraserCode?基于Stripe的EC存儲策略：–數(shù)據(jù)切分成N段子數(shù)據(jù)–N段子數(shù)據(jù)計算出P個校驗值–N+P段數(shù)據(jù)依序存儲在環(huán)上Cassandra系統(tǒng)改進(jìn)-EraserCode?EC存儲數(shù)據(jù)切分及存儲原理：–數(shù)據(jù)內(nèi)容按照大小切分成N個字段–子段的Key，有前綴+Value的Md5–原始Key只存儲子Key列表Storm系統(tǒng)改進(jìn)-大文件緩存?主要問題：–部分Stormtopology依賴數(shù)據(jù)量較大，如機(jī)器學(xué)習(xí)模型–規(guī)模達(dá)數(shù)百兆，導(dǎo)致topology啟動時間過長–數(shù)據(jù)變化不大Storm系統(tǒng)改進(jìn)-大文件緩存?大文件緩存：–大文件采用類似Jar管理方式，由supervisor管理–topology下線之后并不立即刪除，長時間不用才釋放Storm系統(tǒng)改進(jìn)-應(yīng)用Jar包P2P分發(fā)?主要問題：–topology的jar包比較大–worker數(shù)量在上千臺服務(wù)器上–topology啟動耗時比