導讀：移動互聯(lián)時代，企業(yè)都面臨著海量數(shù)據(jù)帶來的挑戰(zhàn)，有一些企業(yè)馴服了海量數(shù)據(jù)，實現(xiàn)了“存的下、算的出”，但即使如此，這些企業(yè)很少跨過數(shù)據(jù)保護的門檻，因為傳統(tǒng)數(shù)據(jù)保護技術(shù)在面對PB級別數(shù)據(jù)量時，都或多或少的出現(xiàn)了問題，浪潮工程師開發(fā)了分級保護方案，很好的滿足了100PB級別的數(shù)據(jù)保護需求。
PB數(shù)據(jù)量挑戰(zhàn)傳統(tǒng)數(shù)據(jù)保護技術(shù)
提到數(shù)據(jù)保護和容災，很多人都會想到備份技術(shù)、存儲復制技術(shù)、數(shù)據(jù)卷復制技術(shù)、數(shù)據(jù)庫日志傳輸?shù)龋沁@些傳統(tǒng)技術(shù)沒法適應海量數(shù)據(jù)環(huán)境。數(shù)PB乃至數(shù)十PB規(guī)模的數(shù)據(jù)，是傳統(tǒng)數(shù)據(jù)保護技術(shù)和容災技術(shù)在設計和形成之初，所不能想象的。這些技術(shù)適用于百TB以下數(shù)據(jù)規(guī)模，大多數(shù)不能做到實時保護，容災數(shù)據(jù)日常處于離線或不可訪問狀態(tài)，難以滿足大數(shù)據(jù)的應用需求。
勉強部署這些技術(shù)在海量數(shù)據(jù)環(huán)境下，災難恢復、可用性、穩(wěn)定性等技術(shù)表現(xiàn)也會大打折扣。拿傳統(tǒng)備份技術(shù)來說，日常演練/驗證，數(shù)據(jù)需要重新加載，PB級數(shù)據(jù)環(huán)境下，加載時間往往是數(shù)天、甚至數(shù)周，若容災數(shù)據(jù)不能進行有效的日常驗證，整個容災架構(gòu)的可靠性和實用性會急劇下降，所以在很多場景中，傳統(tǒng)方案僅限于方案，不能實際部署。
數(shù)據(jù)分級解決大數(shù)據(jù)容災問題
OpenStack、Hadoop、Spark等目前主流的云和大數(shù)據(jù)平臺，數(shù)據(jù)可靠性主要通過存儲子系統(tǒng)的副本和糾刪碼等技術(shù)來保證，這些技術(shù)只能保證本地數(shù)據(jù)安全可靠，沒法應對人為破壞、物理/邏輯故障、站點故障等情況，需要增加歷史數(shù)據(jù)保護和遠距離容災保護。
大數(shù)據(jù)平臺80%左右都是原始數(shù)據(jù)，這些數(shù)據(jù)經(jīng)過數(shù)據(jù)清洗、治理形成平臺的標準資源庫數(shù)據(jù)，這個環(huán)節(jié)是一個海量數(shù)據(jù)結(jié)構(gòu)化的過程，隨后，根據(jù)上層業(yè)務應用需求，由標準資源庫快速派生出多個主題庫、專題庫等，這些數(shù)據(jù)庫就直接對接上層應用了。
海量數(shù)據(jù)保護需要在深入了解業(yè)務模型和數(shù)據(jù)屬性的技術(shù)上，對這些數(shù)據(jù)進行分級保護，根據(jù)重要程度等技術(shù)指標，執(zhí)行不同的保護策略，避免了成本高、技術(shù)難落地等實際問題。
數(shù)據(jù)分級保護
分級僅是海量數(shù)據(jù)保護的方案框架，具體方案需要針對客戶的具體應用場景進行設計，所以我們以剛剛成功上線的一個案例來詳細展開。
該用戶的數(shù)據(jù)量屬于超大規(guī)模級別，在全省有11個大數(shù)據(jù)分中心，1個大數(shù)據(jù)總中心，各個中心采集自己區(qū)域的原始數(shù)據(jù)，生成本地的標準資源庫，然后根據(jù)各自需求生成本地的主題庫、專題庫等，承接本地上層的應用；同時，各分中心傳輸本地的標準資源庫至總中心，匯聚為全省的標準資源庫，生成相關(guān)主題庫、專題庫，具備承接全省范圍內(nèi)業(yè)務需求的能力，12個中心數(shù)據(jù)總量接近50PB。
數(shù)據(jù)分析——50PB數(shù)據(jù)保護1PB即可
用戶希望建立有效的容災機制，防范物理、邏輯、站點等故障。根據(jù)上文所述的原則，需要先對客戶的數(shù)據(jù)進行分類，根據(jù)不同的重要程度采取不同的數(shù)據(jù)保護技術(shù)。
首先是原始數(shù)據(jù)，這些數(shù)據(jù)可再生，而且據(jù)經(jīng)過熱度訪問期后，便成為冷數(shù)據(jù)，價值低，規(guī)模大，不必采用額外的保護技術(shù)；其次是，標準資源庫數(shù)據(jù)，這些庫數(shù)據(jù)是大數(shù)據(jù)平臺的初次結(jié)果數(shù)據(jù)，含金量很高，是用戶大數(shù)據(jù)環(huán)境的核心數(shù)據(jù)，不易重建，有很強的數(shù)據(jù)保護和容災需求，然后是各類主題庫、專題庫等數(shù)據(jù)，這些庫數(shù)據(jù)由標準資源庫數(shù)據(jù)經(jīng)過二次加工派生出而出，并支持快速重建，發(fā)生問題可以在用戶要求的RTO（復原時間目標）內(nèi)完成重建，因而這類數(shù)據(jù)也不需要額外容災保護。最后則是各中心間冗余數(shù)據(jù)，顯然這些數(shù)據(jù)不需要容災保護
綜上，本項目僅需要為總中心的全量標準資源庫數(shù)據(jù)進行容災保護，數(shù)據(jù)量約1PB。
應用方案——3條傳輸通路冗余、計算存儲分離
浪潮為用戶設計了異地容災方案，將方案按照客戶要求部署在分數(shù)據(jù)中心10中。總中心的全量標準資源庫有1PB結(jié)構(gòu)化數(shù)據(jù)，每日數(shù)據(jù)變化量為30TB~50TB，所以，異地容災架構(gòu)中數(shù)據(jù)傳輸技術(shù)要支持高頻率周期性傳輸和實時傳輸模式，將增量數(shù)據(jù)復制過來，根據(jù)生產(chǎn)環(huán)境的壓力變化兩種傳輸技術(shù)可以靈活組合，美國服務器，保證異地容災大數(shù)據(jù)平臺為在線狀態(tài)，日常可以實時查詢數(shù)據(jù)、驗證數(shù)據(jù)。所以，容災數(shù)據(jù)傳輸采用ETL定制化工具，這種數(shù)據(jù)傳輸技術(shù)與大數(shù)據(jù)平臺有著天然的親和性，高速穩(wěn)定、成熟可靠，目前，容災方案可以保證RPO≤1小時，RTO≤2小時。
