隨著《“十四五”大數據產業發展規劃》的發布，大數據日趨成為重要的數字經濟支撐，對承載數據倉庫、負責高價值密度大數據存儲分析的OLAP MPP集群進行全面的容災以及雙活系統的建設變的格外重要。

OLAP MPP集群容災系統能滿足對T+1，T+0.X等非實時的批處理的數倉場景的容災需求，但是RPO，RTO會較大，往往達到小時級；隨著數倉業務對連續性要求的不斷提高，尤其是實時數倉的場景，需要建設實時的雙活系統來滿足對業務的連續性要求；當主庫出現故障時，要求備庫立即進行接管，對于實時數倉，要建立RPO，RTO達到分鐘級或者秒級甚至到0的準實時或者實時雙活系統才能保障主備庫數據不丟失以及數據的一致性，從而保障業務的連續性。

OLAP MPP分析型集群的容災以及雙活在技術實現上、災備級別要求上都與在線生產系統的OLTP事務數據庫有較大差異。如事務數據庫具有完備的WAL（write ahead logging）事務日志，災備可以通過事務日志實現數據庫的備份、雙活復制、異地容災等；OLAP MPP分析型數據庫為追求大吞吐性能，無法完全按照事務數據庫基于事務日志的容災以及雙活設計方案，目前業界采用的主流容災和雙活方案主要有：數據同步模式、ETL模式、雙活模式，具體說明如下：

1. 數據同步方式

主備集群間的數據同步是雙活容災系統建設的基礎，高效、穩定、一致性的同步是雙活容災系統穩定運行的關鍵；本節列舉下市面上常見的數據同步方式，以及各自的優缺點；

1.1.基于事務日志、數據塊的數據同步

優勢：直接同步變化的數據增量，只適合數據變化量較少的數據倉庫。

劣勢：對主數據庫有侵入性，一旦主庫繁忙，同步時效低；面對變化數據量大的場景，不適合。

1.2.基于備份恢復的數據同步

利用備份恢復工具進行數據的全量備份和增量備份，存放到某個存儲介質上，然后恢復到備庫上。

優勢：采用產品已有的備份恢復工具來實現。

劣勢：要求數據庫支持增備能力，且往往鎖等待嚴重；備庫對外只能提供讀；對備庫進行恢復時不能馬上提供服務，備份恢復無法達到與流式同步方式的RPO， 做不到RPO=0的程度,  RTO時間較長，而且需要較大空間保存備份的數據。

1.3.基于導入導出的數據同步

基于上層應用對主庫導出，備庫導入，業務需要設計對增量數據的識別，對業務的設計和調度有較高的侵入性。以作業為單位，需要應用記住該作業產生的相關表，等作業完成后，主庫發起對這些表的導出操作，備庫進行導入操作。

優勢：可以基于表級進行數據同步，基于導入導出，導出的是文本文件，因此主庫和備庫可以是異構的，例如主庫是產品A，備份是產品B。

劣勢：對主庫的應用調度和數據庫設計侵入性高，實施困難。

2. 雙活容災模式

本節介紹雙活容災的一些實現方案，有些是產品能力，有些是應用解決方案，供大家參考；

2.1.基于ETL雙加工雙活模式

采用兩套獨立的調度系統進行作業的加工，由上層應用進行控制。

優勢：不依賴于數據庫產品自生的容災能力，有應用自己進行控制，不依賴產品。一般采取主庫對外提供持續服務，待主備庫數據準實時或批后校驗一致后，再開放備庫對外服務。

劣勢：因為主備庫同時跑ETL作業，需要同時消耗主備庫的CPU，內存和IO資源；另外對存在不確定值的SQL函數導致主備集群數據不一致，例如now、random、row_number排序這種同一份數據產生不同結果集的函數。建議用戶修改SQL語句，明確唯一取值、唯一排序，確保主備數據的一致性。若主備集群數據發生不一致場景，主要以主庫數據為準，覆蓋備庫，該同步過程可以采用“基于事務日志以及數據塊的數據同步”技術。

2.2.基于產品提供的中間件進行調度的雙活模式

產品級調度中間件是由OLAP產品提供一個組件，對外提供產品統一接口，實現主備集群SQL的調度、校驗和同步（同步采用數據庫自生的基于事務日志以及數據塊的數據同步的底層技術）；客戶業務只需在產品級中間件下發任務；產品級中間件會自動調度任務：加載語句可以同時發送給主備庫，實現雙加載；DML語句可以靈活配置，可以主備庫同時執行后進行校驗，也可以主庫執行完成后把增量數據同步到備庫；只有主備庫的數據校驗成功后，本次任務才算執行成功。

另外，考慮到不確定值的SQL函數導致主備集群數據不一致（例如now、random、row_number排序這種同一份數據產生不同結果集的函數），如果采用主備集群雙加工的調度方式，則建議用戶修改SQL語句，明確唯一取值、唯一排序，確保主備庫執行SQL結果的一致性，部分簡單的系統時間函數，可以通過中間件改寫，保障SQL執行結果的一致性；

建議采用的最佳方案是采用“基于事務日志以及數據塊的數據同步”的同步技術，直接將主數據庫SQL執行結果的日志以及變化的數據塊同步到備庫中。

優勢：產品級提供，對應用完全透明。

劣勢：引入了中間件作為接入服務，由于所有數據庫訪問行為均通過該中間件，中間件任何異常均影響整個雙活系統的高可用，需要考慮中間件本身的高可用。

2.3.基于應用提供的中間件進行調度的雙活模式

用戶的應用加工作業連接主庫完成寫操作，支持兩種調度方式：

方式一：作業級實時一致性方案，是在作業的最后一步將本作業影響的目標表增量數據同步至備庫中，同步不成功則認為該作業加工失敗。

方式二：作業級異步一致性方案，作業的最后一步將本作業信息記錄至同步隊列中，同步隊列處理將已完成作業信息獲取到，并獲取作業目標表將其增量數據同步，何時同步及同步哪些表由“同步隊列處理”應用保證。當主備庫同步完成后進行數據的校驗。

優勢：應用控制加工邏輯，實現作業級的實時一致性和準實時的一致性，可靈活進行控制。主集群數據可寫，承擔數據統計分析等數據加工業務，完成數據加工后將結果數據同步到備份集群，備集群可以分擔主集群對外業務查詢服務，降低主集群讀寫對系統資源的爭搶壓力。

劣勢：對應用邏輯有侵入性，增加了應用邏輯的復雜性。

2.4.基于強一致的實時同步的雙活模式

通過統一的調度集群作為入口，采用虛擬集群技術，主備集群作為邏輯子集群納入調度集群的統一管理，在虛擬集群中將兩個同樣規模和數據分布策略的子集群之間建立鏡像關系，就稱為鏡像集群。顧名思義，兩個鏡像集群中的表和數據是一致的。主備計算集群通過建立鏡像集群關系實現了強一致的實時雙活，可以支持同城的實時雙活場景。

(1)  在主備計算集群間建立鏡像關系，鏡像關系可以按表進行創建，也可以按照數據庫進行創建；

(2)  虛擬集群中互為鏡像的兩個子集群可以部署在同機房內，也可以部署在同城的不同機房內，對兩個子集群之間的網絡質量和網絡帶寬有一定要求；當兩個子集群位于不同機房時，就形成了同城異地的災備；在同城異地部署中，可以在備份機房中部署1個coordinator節點，實現管理集群的數據災備；

(3)  業務直接連接其中的一個子集群進行操作，下發DDL、DML、DQL等SQL語句，對于DDL，將同時下發到互為鏡像的兩個集群中執行；對于DML、DQL操作則直接下發到當前應用的默認子集群中執行，DML的執行結果采用鏈式轉發方式傳輸到另一個子集群中；鏡像集群中的數據修改操作，需要在兩個子集群中統一提交后才返回執行結果給用戶；

(4)  如果主備任何一個計算集群發生故障，應用無需做任何改變，調度集群對應用透明的完成了對業務的切換，如上圖中的VC1集群和VC2集群為鏡像集群關系，業務默認直接在VC1上執行，當VC1發生整體故障后，調度集群自動切換業務連接到VC2上來執行；

(5)  如果管理集群在主機房中的所有節點發送故障，需要人工修改集群管理節點的配置為備份機房中的管理節點為管理集群的唯一節點后，業務就可通過備份機房中的管理節點下發SQL任務。

優勢：通過統一的調度集群對外提供服務，主備計算集群通過鏡像關系實現了產品級的強一致的實時雙活。主備計算集群的任何一個出現整體故障時，調度集群會把任務自動下發給沒有故障的主備計算集群，對應用完全透明，應用不需要做任何切換。

劣勢：主備計算集群的事務是強一致的，要求主備計算集群間為萬兆網，不適用于跨廣域網的異地實時雙活。

3. 方案對比匯總