摘要：隨着數據湖技術從離線向實時的發展，數據湖在業務已逐漸從輔助決策向實時決策，實時干預甚至提前預防的方向發展，同時，隨着國家把數據作為第五種生產要素，數據據價值在逐步提升，這樣對海量數據湖的可靠性提出了新的要求。
本文分享自華為雲社區《華為雲FusionInsight MRS容災：大數據兩地三中心的容災也可以如此省心》，作者： Sailing27 。
背景介紹
隨着數據湖技術從離線向實時的發展，數據湖在業務已逐漸從輔助決策向實時決策，實時干預甚至提前預防的方向發展，同時，隨着國家把數據作為第五種生產要素，數據據價值在逐步提升，這樣對海量數據湖的可靠性提出了新的要求。
首先，數據湖作為企業全量數據存儲的地方，對數據的安全性有着至關重要的作用，如何保證湖內的數據在任何情況下，都不要出現丟失的情況，是越來越多的企業在思考的問題，同時，隨着數據湖逐步補齊交互式查詢，實時分析等能力，大量的分析師正逐步將日常的數據分析工作轉移到數據湖中，在這種背景下，一旦出現數據湖無法對外提供服務或者是數據丟失，將會對企業產生重大影響。但另一方面，數據中心級的故障在全球不斷出現，火災、水災等各種新聞不斷涌現。同時，日常運維過程中的誤操作，也是時時刻刻懸在頭上的一把利劍，這種情況可能比機房起火更常見，但對數據的影響卻也是致命的。
每一次有新聞報道這方面的事故時，相信很多大數據平台的運維人員都是心頭一緊，如何確保數據湖系統的絕對可靠，成為越來越多企業關心的問題。
對於一個數據湖平台，常見的故障包括：
數據湖一般作為大規模分布式系統，對以小范圍硬件故障類一般都已在系統架構中有比較完善的考慮，本文不做詳細描述。下面主要介紹的是重大災難以及誤操作場景下，MRS的高可用方案。
MRS災備方案介紹
華為雲MRS作為全球領先的數據湖平台，在可靠性方面已有比較完整的規划，為應用不同的故障場景，提供了以下三種方案：
- 數據備份：采用OBS或者備MRS集群來作為備份存儲，將關鍵數據備份到OBS/HDFS中。
- 單集群跨AZ：采用多AZ方式建設單集群，通過副本放置策略（BPP）和YARN的任務調度機制的優化，確保單AZ故障時數據不丟失，關鍵業務不中斷。
- 異地主備容災：分別建設主、備兩個MRS集群，配置主備容災關系，主集群數據周期/實時自動同步到備集群上。主集群故障時，將業務倒換到備集群上，確保業務快速恢復。
下面將對以上三種方案進行詳細描述：
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的方案，此方案的核心是利用大數據的分布式能力，將一個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故障時的應用重試，應用層也不用進行失敗重試類的改造，真正實現了對應用的完全透明的高可用能力。
MRS主備容災方案介紹
雖然跨AZ的方案，可以解決機房級的故障，但由於單集群跨AZ方案對網絡時延的要求，AZ間的距離一般只能在一個城市之內。為了應對城市級的故障場景，需要采用MRS主備容災的方案，實現真正的高可用，這里需要說明的是，主備容災方案，是一個端到端的方案，不是一個大數據平台層單方面能實現的，因此很多時候需要結合數據源、應用層的架構進行完整的設計，本文主要介紹大數據平台層的主備容災方案。大數據平台層的主備復制方案如下圖：
針對主備容災場景下，涉及組件多，同步管理復雜的問題，MRS提供了統一的容災管理能力，業務只需要將主備集群的容災關系配置好，即可完成對所有組件的容災保護。
考慮到容災服務，很多時候只會針對核心數據和業務進行保護，MRS提供了保護組的概念，一對主備集群，可以配置多個保護組，用於不同業務和數據的主備保護。
一個保護組內，可以配置HDFS目錄、Hive表等各種緯度的保護內容。
配置好保護組以后，系統會提供保護組的同步狀態、歷史記錄等管理功能。
總結：通過MRS的主備容災能力，業務可以很容易地實現大數據平台的異地主備容災能力，滿足應對城市級災難的能力，配置業務側的主備容災方案，真正實現業務的絕對高可用。
總結：
通過上面介紹的三種方案，MRS可以實現從簡單的數據備份到跨AZ高可用，到異地容災的完整場景覆蓋，支撐業務應對各種異常場景，三種方案的對比如下：
業務可以根據自身業務特點以及需要應對的故障場景，靈活選擇適合自己的方案。如在華北某城市中，通過跨AZ的方式建設主集群，在華南某城市建設一個備集群。這樣既能防護AZ級的火災、電力故障，也能防范城市級的水災等重大災難場景。