OLAP MPP分散式關係型資料庫的雙活容災系統的設計

隨著《“十四五”大資料產業發展規劃》的釋出，大資料日趨成為重要的數字經濟支撐，對承載資料倉儲、負責高價值密度大資料儲存分析的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. 方案對比彙總