導讀：移動互聯(lián)時代，企業(yè)都面臨著海量數(shù)據(jù)帶來的挑戰(zhàn)，有一些企業(yè)馴服了海量數(shù)據(jù)，實現(xiàn)了“存的下、算的出”，但即使如此，這些企業(yè)很少跨過數(shù)據(jù)保護的門檻，因為傳統(tǒng)數(shù)據(jù)保護技術在面對PB級別數(shù)據(jù)量時，都或多或少的出現(xiàn)了問題，浪潮工程師開發(fā)了分級保護方案，很好的滿足了100PB級別的數(shù)據(jù)保護需求。

PB數(shù)據(jù)量挑戰(zhàn)傳統(tǒng)數(shù)據(jù)保護技術

提到數(shù)據(jù)保護和容災，很多人都會想到備份技術、存儲復制技術、數(shù)據(jù)卷復制技術、數(shù)據(jù)庫日志傳輸?shù)龋沁@些傳統(tǒng)技術沒法適應海量數(shù)據(jù)環(huán)境。數(shù)PB乃至數(shù)十PB規(guī)模的數(shù)據(jù)，是傳統(tǒng)數(shù)據(jù)保護技術和容災技術在設計和形成之初，所不能想象的。這些技術適用于百TB以下數(shù)據(jù)規(guī)模，大多數(shù)不能做到實時保護，容災數(shù)據(jù)日常處于離線或不可訪問狀態(tài)，難以滿足大數(shù)據(jù)的應用需求。

勉強部署這些技術在海量數(shù)據(jù)環(huán)境下，災難恢復、可用性、穩(wěn)定性等技術表現(xiàn)也會大打折扣。拿傳統(tǒng)備份技術來說，日常演練/驗證，數(shù)據(jù)需要重新加載，PB級數(shù)據(jù)環(huán)境下，加載時間往往是數(shù)天、甚至數(shù)周，若容災數(shù)據(jù)不能進行有效的日常驗證，整個容災架構的可靠性和實用性會急劇下降，所以在很多場景中，傳統(tǒng)方案僅限于方案，不能實際部署。

數(shù)據(jù)分級解決大數(shù)據(jù)容災問題

OpenStack、Hadoop、Spark等目前主流的云和大數(shù)據(jù)平臺，數(shù)據(jù)可靠性主要通過存儲子系統(tǒng)的副本和糾刪碼等技術來保證，這些技術只能保證本地數(shù)據(jù)安全可靠，沒法應對人為破壞、物理/邏輯故障、站點故障等情況，需要增加歷史數(shù)據(jù)保護和遠距離容災保護。

大數(shù)據(jù)平臺80%左右都是原始數(shù)據(jù)，這些數(shù)據(jù)經過數(shù)據(jù)清洗、治理形成平臺的標準資源庫數(shù)據(jù)，這個環(huán)節(jié)是一個海量數(shù)據(jù)結構化的過程，隨后，根據(jù)上層業(yè)務應用需求，由標準資源庫快速派生出多個主題庫、專題庫等，這些數(shù)據(jù)庫就直接對接上層應用了。

海量數(shù)據(jù)保護需要在深入了解業(yè)務模型和數(shù)據(jù)屬性的技術上，對這些數(shù)據(jù)進行分級保護，根據(jù)重要程度等技術指標，執(zhí)行不同的保護策略，避免了成本高、技術難落地等實際問題。

　　數(shù)據(jù)分級保護

一個案例——50PB數(shù)據(jù)的保護

分級僅是海量數(shù)據(jù)保護的方案框架，具體方案需要針對客戶的具體應用場景進行設計，所以我們以剛剛成功上線的一個案例來詳細展開。

該用戶的數(shù)據(jù)量屬于超大規(guī)模級別，在全省有11個大數(shù)據(jù)分中心，1個大數(shù)據(jù)總中心，各個中心采集自己區(qū)域的原始數(shù)據(jù)，生成本地的標準資源庫，然后根據(jù)各自需求生成本地的主題庫、專題庫等，承接本地上層的應用;同時，各分中心傳輸本地的標準資源庫至總中心，匯聚為全省的標準資源庫，生成相關主題庫、專題庫，具備承接全省范圍內業(yè)務需求的能力，12個中心數(shù)據(jù)總量接近50PB。

數(shù)據(jù)分析——50PB數(shù)據(jù)保護1PB即可

用戶希望建立有效的容災機制，防范物理、邏輯、站點等故障。根據(jù)上文所述的原則，需要先對客戶的數(shù)據(jù)進行分類，根據(jù)不同的重要程度采取不同的數(shù)據(jù)保護技術。

首先是原始數(shù)據(jù)，這些數(shù)據(jù)可再生，而且據(jù)經過熱度訪問期后，便成為冷數(shù)據(jù)，價值低，規(guī)模大，不必采用額外的保護技術;其次是，標準資源庫數(shù)據(jù)，這些庫數(shù)據(jù)是大數(shù)據(jù)平臺的初次結果數(shù)據(jù)，含金量很高，是用戶大數(shù)據(jù)環(huán)境的核心數(shù)據(jù)，不易重建，有很強的數(shù)據(jù)保護和容災需求，然后是各類主題庫、專題庫等數(shù)據(jù)，這些庫數(shù)據(jù)由標準資源庫數(shù)據(jù)經過二次加工派生出而出，并支持快速重建，發(fā)生問題可以在用戶要求的RTO(復原時間目標)內完成重建，因而這類數(shù)據(jù)也不需要額外容災保護。最后則是各中心間冗余數(shù)據(jù)，顯然這些數(shù)據(jù)不需要容災保護

綜上，本項目僅需要為總中心的全量標準資源庫數(shù)據(jù)進行容災保護，數(shù)據(jù)量約1PB。

應用方案——3條傳輸通路冗余、計算存儲分離

浪潮為用戶設計了異地容災方案，將方案按照客戶要求部署在分數(shù)據(jù)中心10中?？傊行牡娜繕藴寿Y源庫有1PB結構化數(shù)據(jù)，每日數(shù)據(jù)變化量為30TB~50TB，所以，異地容災架構中數(shù)據(jù)傳輸技術要支持高頻率周期性傳輸和實時傳輸模式，將增量數(shù)據(jù)復制過來，根據(jù)生產環(huán)境的壓力變化兩種傳輸技術可以靈活組合，保證異地容災大數(shù)據(jù)平臺為在線狀態(tài)，日?？梢詫崟r查詢數(shù)據(jù)、驗證數(shù)據(jù)。所以，容災數(shù)據(jù)傳輸采用ETL定制化工具，這種數(shù)據(jù)傳輸技術與大數(shù)據(jù)平臺有著天然的親和性，高速穩(wěn)定、成熟可靠，目前，容災方案可以保證RPO≤1小時，RTO≤2小時。

最后，容災中心大數(shù)據(jù)平臺，采用計算和存儲分離的部署模式，容災存儲采用企業(yè)級分布式存儲，并和上層大數(shù)據(jù)平臺對接，使方案具備很強的數(shù)據(jù)湖特性：容災數(shù)據(jù)可以靈活的分配給非大數(shù)據(jù)平臺環(huán)境，支持容災數(shù)據(jù)在不同類型的業(yè)務系統(tǒng)間共享，避免數(shù)據(jù)再次復制過程，最大化數(shù)據(jù)價值。

以下為容災方案技術架構圖：

　　容災方案技術架構圖

本項目在總中心部署3臺ETL服務器(后續(xù)計劃在容災中心也部署3臺，實現(xiàn)ETL服務器的站點互備架構)，形成三條邏輯冗余的數(shù)據(jù)傳輸通道，從總中心大數(shù)據(jù)平臺抽取標準資源庫全量數(shù)據(jù)至容災中心，之后進行差量數(shù)據(jù)復制，容災中心數(shù)據(jù)和生產中心數(shù)據(jù)保持一定的時間差異，可以提升防范邏輯數(shù)據(jù)故障的能力。

容災中心，日常主要工作為接收總中心標準資源庫數(shù)據(jù)，并提供數(shù)據(jù)查詢、驗證服務、低頻運行臨時分配的作業(yè)任務，根據(jù)建設目標，此平臺配置和生產中心標準資源庫同量存儲資源，但不需配置同等的計算資源，所以，本方案采用30臺服務器(約為總中心大數(shù)據(jù)平臺計算力的10%)、40臺高密存儲節(jié)點(配置海量數(shù)據(jù)存儲池，提供4PB可用容量，實現(xiàn)未來三年的容量預留)搭建大數(shù)據(jù)容災平臺。30臺服務器包括1臺管理節(jié)點、2臺主服務節(jié)點以及27臺數(shù)據(jù)節(jié)點，平臺服務組件采用高可靠主備模式，防止單節(jié)點故障問題。海量存儲池采用糾刪數(shù)據(jù)冗余機制，保證可靠性和空間利用率，海量存儲池，被上層大數(shù)據(jù)平臺管理，隨著容災數(shù)據(jù)的快速增長，可以實現(xiàn)在不擴容平臺計算資源的條件下，在線擴展其容量至數(shù)百PB，滿足用戶后期數(shù)據(jù)的快速增長需求。

　　Hadoop容災平臺

結語，海量數(shù)據(jù)將是企業(yè)新常態(tài)

目前全球數(shù)據(jù)量約為44ZB，到2025年會上升至163ZB，也就是說，數(shù)據(jù)的高速增長將成為越來越多的企業(yè)面臨的常態(tài)化問題，而不是新挑戰(zhàn)。在可見的時間內，網(wǎng)絡等方面的技術條件都不足以使得企業(yè)進行全面不加取舍的數(shù)據(jù)保護，分級保護將成為越來越多用戶的選擇，希望這個案例能夠給更多的企業(yè)用戶提供良好的借鑒范例。

生成海報

免責聲明：本網(wǎng)站內容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內容可能涉嫌侵犯其知識產權或存在不實內容時，應及時向本網(wǎng)站提出書面權利通知或不實情況說明，并提供身份證明、權屬證明及詳細侵權或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關文章源頭核實，溝通刪除相關內容或斷開相關鏈接。