摘要：随着資料湖技術從離線向實時的發展，資料湖在業務已逐漸從輔助決策向實時決策，實時幹預甚至提前預防的方向發展，同時，随着國家把資料作為第五種生産要素，資料據價值在逐漸提升，這樣對海量資料湖的可靠性提出了新的要求。
本文分享自華為雲社群《華為雲FusionInsight MRS容災：大資料兩地三中心的容災也可以如此省心》，作者： Sailing27 。
随着資料湖技術從離線向實時的發展，資料湖在業務已逐漸從輔助決策向實時決策，實時幹預甚至提前預防的方向發展，同時，随着國家把資料作為第五種生産要素，資料據價值在逐漸提升，這樣對海量資料湖的可靠性提出了新的要求。
首先，資料湖作為企業全量資料存儲的地方，對資料的安全性有着至關重要的作用，如何保證湖内的資料在任何情況下，都不要出現丢失的情況，是越來越多的企業在思考的問題，同時，随着資料湖逐漸補齊互動式查詢，實時分析等能力，大量的分析師正逐漸将日常的資料分析工作轉移到資料湖中，在這種背景下，一旦出現資料湖無法對外提供服務或者是資料丢失，将會對企業産生重大影響。但另一方面，資料中心級的故障在全球不斷出現，火災、水災等各種新聞不斷湧現。同時，日常運維過程中的誤操作，也是時時刻刻懸在頭上的一把利劍，這種情況可能比機房起火更常見，但對資料的影響卻也是緻命的。
每一次有新聞報道這方面的事故時，相信很多大資料平台的運維人員都是心頭一緊，如何確定資料湖系統的絕對可靠，成為越來越多企業關心的問題。
對于一個資料湖平台，常見的故障包括：
資料湖一般作為大規模分布式系統，對以小範圍硬體故障類一般都已在系統架構中有比較完善的考慮，本文不做較長的描述。下面主要介紹的是重大災難以及誤操作場景下，MRS的高可用方案。
華為雲MRS作為全球領先的資料湖平台，在可靠性方面已有比較完整的規劃，為應用不同的故障場景，提供了以下三種方案：
資料備份：采用OBS或者備MRS叢集來作為備份存儲，将關鍵資料備份到OBS/HDFS中。
單叢集跨AZ：采用多AZ方式建設單叢集，通過副本放置政策（BPP）和YARN的任務排程機制的優化，確定單AZ故障時資料不丢失，關鍵業務不中斷。
異地主備容災：分别建設主、備兩個MRS叢集，配置主備容災關系，主叢集資料周期/實時自動同步到備叢集上。主叢集故障時，将業務倒換到備叢集上，確定業務快速恢複。
下面将對以上三種方案進行較長的描述：
備份方案，作為一種最基礎的資料保護方案，具有成本低，方案簡單的特點，特别是相比其它方案，在資料誤删保護方面，具有獨特的優勢。但是，大資料業務的備份，也是十分有挑戰的一項工作，主要展現在：
由于大資料平台的元件多，各類元件的備份方案也不統一，實施起來較為複雜，特别是有些場景，還要考慮元件間的資料一緻性問題；
資料體量巨大，全量備份成本高，正因如此，很多大資料項目都沒有采用備份方案。
華為雲原生資料湖MRS，作為企業級的資料湖平台，具有簡單易用的備份管理功能，支援對接多種備份存儲方案。整體備份能力如下：
在元件上，支援了Manger、DBService、HDFS、YARN、HBase、Hive、ES、Redist、ClickHouse、IotDB等所有涉及資料的元件。同時MRS支援圖形化的備份配置界面，使用者隻需要按需選擇所需要備份的資料，設定好備份周期，系統将會自動周期進行備份，且會保證元件間資料關聯的一緻性，同時也支援手工一次性備份。
備份存儲，MRS支援将資料備份到備MRS叢集或OBS上，對于有條件采用OBS備份的場景，可優先采用OBS備份，對于無OBS的場景，可以采用備MRS叢集進行備份，在此場景下，考慮到成本，備叢集HDFS可以采用兩副本。
以下是備份任務的主要管理界面：
建立備份任務時的政策選擇：
備份任務管理：
總結：備份方案，由于其在應對資料丢失方面的優勢，一般會作為基礎的資料保護能力，特别是其全量資料的儲存能力，可以應對資料誤删除的場景。
備份方案雖然可以解決資料可靠性的問題，但無法解決業務可靠性的問題，如果發生機房機的故障，雖然資料可以從備份系統中恢複，但這時的恢複周期會非常長，針對機房級的故障，如何同時解決業務和資料的可靠性，MRS提供了單叢集跨AZ的方案，此方案的核心是利用大資料的分布式能力，将一個MRS叢集部署到多個AZ中，對于存儲層的HDFS，自動識别多AZ，并将多副本分布在多AZ中，確定任一AZ故障，都不會導緻資料丢失。對于計算層，支援同一個隊列跨AZ部署，并在一個AZ故障時，自動将任務在另一個AZ中重試，實作應用層無感覺的AZ遷移。
MRS單叢集跨AZ的部署架構如下：
如上圖所示，同一個MRS叢集會同時部署到3AZ中，對于存儲層，通過塊放置政策（BPP)對AZ的感覺，将同一資料的3個副本，分别放置到3個AZ中，確定任一AZ故障，不會造成資料丢失，對于計算，通過将租戶隊列配置到多個AZ中，實作租戶的應用，在一個AZ故障以後，仍然可以在另外一個AZ中執行。
在跨AZ的的場景下，還有一個比較大的挑戰是AZ間的帶寬，AZ間的帶寬一般會比較有限，如何降低跨AZ部署的時候，對AZ間帶寬的要求是一個不可忽視的問題，MRS的跨AZ方案中，為了降低對跨AZ帶寬的訴求，MRS從以下三個方面，對跨AZ的流量進行了優化：
應用内的Shuffle流量：基于自研的Superior排程器，實作了正常場景下，計算任務不跨AZ，這樣，将作務運作過程中的Shuffle流量全部控制在一個AZ内，減少了跨AZ的流量消耗。
業務資料讀取流量：對于業務資料的讀請求，通過基于資料本地化的排程，實作了資料從本AZ讀取，将跨AZ的讀流量降到接近于零。
業務資料寫流量：HDFS上的寫流量，會有大量的臨時檔案、日志類的寫入流量，MRS實作了按目錄配置是否需要跨AZ，實作了隻針對真正的業務資料按跨AZ的政策進行副本放置。消減掉了臨時檔案、日志類的無用的跨AZ流量。
如下圖所示，App1運作于跨AZ隊列Queue1上，雖然此隊列關聯了AZ1和AZ2的計算資源，但MRS自研的Superior排程器通過AZ感覺排程，不會将App1的計算任務同時分發到兩個AZ上同時執行，而是僅在其中一個AZ上執行，
而當AZ1故障時，Superior會自動将此應用在AZ2上重跑，此時應用看到的任務狀态并不會中斷，也不需要進行失敗重試的改造，實作了對應用的完全透明。
同時可以看出，無論App運作在哪個AZ上，對存儲層的通路，都可以實作在本AZ内的閉環，并不需要跨AZ通路，保證性能的同時，也降低了對AZ間帶寬的要求。
考慮到某些場景，沒有足夠的3AZ資源可用，MRS也支援2+1的部署模式，即：兩個主AZ加一個仲裁AZ，仲裁AZ不用于實際的資料存儲和業務計算，隻需要幾個工部署需要3AZ仲裁的元件，主要包括Zookeeper、HDFS JournalNode。
針對某此AZ間資源不均的場景，MRS也提供了靈活的配置能力，可以按需配置需要保護的業務（租戶）和資料（表/目錄），隻要最小的AZ中的資源，滿足需要跨AZ保護的業務和資料的資耗的訴求即可。不需要強制所有AZ的的資源完全一樣。
MRS提供了簡單易用的跨AZ部署配置界面：
叢集開啟跨AZ能力：
選擇每個AZ的節點：
總結：通過在計算、存儲、叢集管理方面的設計，業務可以友善靈活地部署出跨AZ的MRS叢集，在業務看來，跨AZ的叢集仍然是一個單叢集，且在平台内部實作了AZ故障時的應用重試，應用層也不用進行失敗重試類的改造，真正實作了對應用的完全透明的高可用能力。
雖然跨AZ的方案，可以解決機房級的故障，但由于單叢集跨AZ方案對網絡時延的要求，AZ間的距離一般隻能在一個城市之内。為了應對城市級的故障場景，需要采用MRS主備容災的方案，實作真正的高可用，這裡需要說明的是，主備容災方案，是一個端到端的方案，不是一個大資料平台層單方面能實作的，是以很多時候需要結合資料源、應用層的架構進行完整的設計，本文主要介紹大資料平台層的主備容災方案。大資料平台層的主備複制方案如下圖：
針對主備容災場景下，涉及元件多，同步管理複雜的問題，MRS提供了統一的容災管理能力，業務隻需要将主備叢集的容災關系配置好，即可完成對所有元件的容災保護。
考慮到容災服務，很多時候隻會針對核心資料和業務進行保護，MRS提供了保護組的概念，一對主備叢集，可以配置多個保護組，用于不同業務和資料的主備保護。
一個保護組内，可以配置HDFS目錄、Hive表等各種緯度的保護内容。
配置好保護組以後，系統會提供保護組的同步狀态、曆史記錄等管理功能。
總結：通過MRS的主備容災能力，業務可以很容易地實作大資料平台的異地主備容災能力，滿足應對城市級災難的能力，配置業務側的主備容災方案，真正實作業務的絕對高可用。
通過上面介紹的三種方案，MRS可以實作從簡單的資料備份到跨AZ高可用，到異地容災的完整場景覆寫，支撐業務應對各種異常場景，三種方案的對比如下：
業務可以根據自身業務特點以及需要應對的故障場景，靈活選擇适合自己的方案。如在華北某城市中，通過跨AZ的方式建設主叢集，在華南某城市建設一個備叢集。這樣既能防護AZ級的火災、電力故障，也能防範城市級的水災等重大災難場景。
點選關注，第一時間了解華為雲新鮮技術~