摘要：本文主要是探討OLAP關系型數據庫框架的數據倉庫平台如何設計雙集群系統，即增強系統高可用的保障水准。
當前社會、企業運行當中，大數據分析、數據倉庫平台已逐漸成為生產、生活的重要地位，不再是一個附屬的可有可無的分析系統，外部監控要求、企業內部服務，涌現大批要求7*24小時在線的應用，逐步出現不同等級要求的雙集群系統。
數據倉庫主流數據庫平台均已存在多重高可靠保障措施設計，如硬盤冗余的raid設計、數據表冗余、節點備用冗余、機櫃備用數據交叉等，以及加上服務進程高可用冗余設計，其最大化程度滿足數據倉庫服務持續在線。
但現實場景，如數據庫軟件缺陷、定期加固補丁、產品迭代、硬件升級這些產品現實因素，以及來自機房、數據中心、地域、網絡的外部災難故障因素，均在降低數據倉庫可用性服務水平。
鑒於數據倉庫存在大量數據吞吐，針對不同數據庫、不同可用性要求，若需要設計雙集群冗余設計，可選技術手段分別有數據同步模式、雙ETL模式、雙活模式，具體探討如下：
1. 數據同步模式
a) 架構
由於數據庫IO能力有限、且兩個數據庫間帶寬有限，除了首次全量同步之后，后續通常考慮增量同步技術，即如何准確、高效獲取“變化數據”，一般存在日志同步技術、備份增量同步技術、邏輯數據同步；
b) 日志同步技術
日志同步技術，有業內最著名Oracle Golden Gate，大部分廠家也有自己的實現方式，像Teradata近年來推出Unity CDM（變化數據廣播）技術，而我司GaussDB for DWS可采用xlog及page進行變化數據同步。
優勢：直接同步變化數據增量，數據量少，要求帶寬低，但目前市面技術大都只適合數據每日變化量較少的數據倉庫環境；
劣勢：現實的技術門檻高，應對各類異常場景適應能力差，對主數據庫侵入性能要求高，一旦主庫繁忙，同步時效低；面對全刪全插等變化數據量大場景，同步吃力；
c) 備份增量同步技術
主要利用各數據庫平台備份恢復能力，進行數據增、全量備份、恢復；通常源庫備份數據壓縮之后，經網絡傳輸后，解壓恢復到目標庫；對應GaussDB for DWS可采用roach備份恢復工具實現；
優勢：利用同一技術實現增、全量數據同步，邏輯清晰，各場景容錯能力強；
劣勢：要求數據庫支持增備能力，且往往鎖等待嚴重；
d) 邏輯數據同步
該項主要涉及較高的業務侵入性，即充分獲取ETL調度數據流元數據，對應數據庫當日數據穩定之后，發起數據表導出-導入操作，針對數據表加工特性，選擇增全量同步規則，進行數據准實時同步。
優勢：較上述同步技術，可以實現多樣選擇性同步，同步過程由實施項目本身控制，做到表級數據同步，不需要全系統同步，即可實現部分業務雙集群；
劣勢：客戶化同步邏輯，操作前置依賴多，實施投入人力多，較難推廣；
2. 雙ETL模式
a) 架構
即采用兩套獨立調度平台進行數據加工，抽取同一個數據源（往往是落地穩定的數據交換平台），采用同一套ETL代碼依賴邏輯調度，各自生成目標數據，往往批量過程中，采取主庫對外持續服務，待主備庫數據准實時或批后校驗一致后，再開放備庫對外服務。
若雙集群數據發生不一致場景，主要以主庫數據為准，覆蓋備庫。該同步過程，需要使用到“數據同步模式”相關同步技術。
b) 參照落地架構
c) 加載源數據考慮
為保證兩套ETL調度加載數據源一致及數據復用，往往要求搭建一個數據交換平台。因為至少存在一個文件被兩套調度讀取，要求數據交換平台兩倍過往吞吐能力；且禁止加載的數據文件被二次覆蓋，導致兩套系統加載不一致；
d) 調度依賴順序考慮
由於ETL作業調度關系沒有配置完備，即存在A作業使用B作業的數據，但不配置依賴關系（絕大部分的情況是A作業可容忍B數據的時效，是否最新數據均可以使用，故為時效，業務上不配置依賴關系；當然也存在物理時間上，通常B遠遠早於A執行），導致兩套系統A作業生成數據不一致。
該場景下，在一套調度平台無法發現此問題，但存在兩套系統的校驗比對，即發現數據不一致；
該問題建議用戶補全依賴關系，確認執行順序一致性；
當然若希望靈活使用依賴關系，則需二次開發，控制兩套調度當日時序一致性；
e) ETL代碼服務器考慮
為了避免兩套ETL調度代碼維護不一致，需考慮統一維護渠道，包含不限於同一個代碼存儲源、版本服務器，以及代碼變更時機
f) 存在不確定值的SQL函數返回
ETL代碼中往往存在sample、random、row_number排序這種同一份數據產生不同結果集的函數，造成兩套系統數據不一致；
該問題建議用戶使用替代函數、明確取值、唯一排序，確保最終數據一致性；
同時，該設計邏輯正確情況下，哪份數據均可被業務采信，若該數據對下游影響少，可每日批后從主庫同步備庫，拉平數據；
g) 報錯修數邏輯考慮
其中一套系統的數據發生報錯、修數行為，會涉及到另一套系統的維護行為；
可選作法是保留操作邏輯，待另一套系統發生報錯時重復執行一次；
其它交給數據質量校驗（DQC）、數據校驗去復查；
h) 干預重跑修數邏輯考慮
若批后重跑，兩套系統重跑邏輯一致，涉及重復勞動（或支撐平台優化），相對簡單；
但涉及批量過程中發現部分數據需要重跑，由於兩套調度進度不一致，會導致
i) 數據校驗
i. 校驗時機
批后校驗，邏輯清晰，對調度依賴少，即根據整體調度進度，做到分層、分庫或整體數據校驗；
准實時校驗，即侵入調度環節，在每個作業完成時，均發起日志解析，提取每個SQL影響記錄數，若相應作業SQL存在影響記錄數不一致場景，即中止較晚完成的調度平台調度后續作業；
ii. 校驗手段
增全量校驗，即針對不同加工邏輯的數據表，區分增、全量數據值，以最小代價覆蓋所有業務表
iii. 校驗方法
通常作法有記錄數、匯總值、checksum校驗；
匯總值校驗，通過是數值型字段直接sum、字符型計算字符長度的sum、時間類型則轉換成數值相加的比對；
Checksum校驗，針對全表或部分字段，進行md5或hash運算，完成兩套系統一致性比對；
對於關系型數據庫，校驗開銷代價逐步遞增（記錄數 < 匯總值 < checksum校驗）；往往是結合增量校驗、結合重要指標，區分維度校驗，日常增量邏輯校驗，定期全量校驗，在校驗數據一致性和系統性能之間取得平衡點。
j) 優化考量
i. 校驗改進
即嵌入調度平台，提取ETL代碼運行日志，通過執行SQL影響的記錄值，實時進行兩套系統完成作業日志比對，發現記錄值影響，立即停止備庫調度，采用人工或自動方式修復數據，繼續后續批量。
該作法最大好處是，即時發現數據異常，避免問題放大，保障備庫更高可用性；
ii. 引入統一維護平台
即減少人為雙系統維護操作，代碼變更平台化，修數邏輯平台化，由平台分別下發兩套調度平台、兩套數據庫。
3. 雙活模式
以下基於Teradata Unity產品理念的延伸構想
a) 架構
b) 雙活功能點
i. 訪問路由能力
客戶端直接將中間件作為數據庫登陸，保持原來登陸邏輯不變；
中間件根據登陸用戶及附加參數實現拒絕登陸、雙系統登陸、或單系統登陸，實現寫登陸、讀登陸，實現受控方式登陸、或非受控方式登陸；即實現受控和非受控方式的系統讀寫；
同時兼顧考慮異常路由選擇或同步路由選擇，滿足最大化異常執行及少部分同步需求場景；
ii. SQL分發能力
經中間件發送的SQL指令，正常發送到相應數據庫，並接受數據庫響應信息；
iii. 批量導入、導出能力
針對數據大批量的導入，需要考慮采用更加高效的加載協議進行數據加載，並考慮經中間件復制數據塊，異步分發兩個數據庫；
數據導出，需要考慮高效數據導出協議，從其中一套數據庫正確導出數據；
iv. 更新類SQL校驗能力
Delete、Update、Insert、Merge等更新類DML SQL進行SQL影響記錄數校驗；
DDL/DCL執行返回碼驗證一致性能力；
v. 對象注冊功能
通過路由及創建對象的DDL語句，實現對象動態注冊；
通過命令行指令實現對象注冊；
適當增加對象索引、約束索引的注冊信息，用於擴展細粒度對象鎖能力，提高數據倉庫ETL SQL並發能力；
*數據倉庫環境下，只需要考慮到表級雙活的能力，不建議實施字段級、記錄級雙活；
vi. 對象鎖能力
根據SQL指令給相應對象動態加鎖、釋放鎖；
同時根據數據庫自帶的鎖特征，至少區分讀、寫鎖控制，以及部分數據庫的臟讀功能鎖；
vii. 對象狀態控制能力
進行管理的多套數據庫在線狀態控制；
進行對象狀態控制功能，包含不限於在線、離線、只讀、只寫、主動中斷緩存中、被動中斷緩存中、不可用等狀態；
viii. 緩存能力
進行SQL指令流緩存能力，以及緩存恢復執行的能力；
進行SQL與加載數據結合緩存、以及緩存恢復執行的能力；
ix. SQL異常控制能力
考慮用戶體驗，始終由返回響應正確的SQL指令返回客戶端；
兩個數據庫返回均成功，但返回的影響記錄數不一致，則響應慢的數據庫對應SQL及涉及對象被設置成不可用狀態；
若兩套數據庫其中一套執行成功，另一套執行失敗，則執行失敗的數據庫SQL和涉及對象被設置為被動中斷緩存中，同時緩存SQL，定時重試SQL；
若兩套數據庫返回均報錯，才通知客戶端報錯；
若SQL涉及對象已處理非在線狀態，則新提交的SQL被緩存，新提交SQL相應對象被設置為被動中斷緩存中。
針對中間件和數據庫之間，存在數據庫已執行完、但中間件未收到信號場景，需考慮閃環該場景（如增加事務鎖等）；
c) Teradata Unity參照落地架構
主要通過Unity實現多集群SQL、數據分發與管理；
Data Mover實現集群間數據同步；
Eocsystem Manager實現數據批后自動校驗及不一致重同步事件觸發；
Viewpoint實現系統平台透視圖展現與維護，並對接用戶告警平台；
d) 中間件高可用考慮
由於引入了中間件（前置）服務，即該服務的穩定、可靠對雙活模式至關重要。
數據庫單套系統本身已經具備極高的可用性，引入中間件后，由於所有數據庫訪問行為均通過該中間件，中間件任何異常均同時影響兩套數據庫訪問能力。
除了中間件本身所有相關服務需要滿足高可用之外，還需考慮極端場景下bypass能力，此項能力在於極端異常條件下，可以保障系統持續服務的能力。
高可用場景中，存在控制節點腦裂與自動升主場景，需借鑒仲裁機制減少腦殘裂發生；
e) 數據重同步考慮
即利用“數據同步模式”相關同步技術，實現兩套數據庫數據重同步能力；
f) 不確定值的SQL函數考慮
最佳方案，是采用“數據同步模式”的數據日志重同步技術，直接將第一套數據庫SQL執行結果的日志信息同步到第二套數據庫中，消除返回結果不一致；
部分簡單的系統時間函數，直接通過中間件改寫，保障SQL執行結果一致性；
另外，則通過SQL改寫，保證row_number函數進行主鍵或全字段排序，保證SQL執行結果一致性；
g) 異常會話重放能力
針對異常會話過程的SQL，可能需要從會話建立后，可視化選擇，倒回前幾個SQL重新執行，並指定過程SQL是否參與結果集校驗，以及SQL回放結束的確認動作，讓異常場景處理手段更加豐富。
4. 適用場景
a) “數據同步模式” – 日志同步技術
適用數據變化量小、數據傳輸壓力小的數據場景，通常只適用於小型數據倉庫平台；
對於規模小的平台，RPO、RTO可以接近0；
b) “數據同步模式” – 備份增量同步技術
適合大數據量同步場景，實現方式容易被用戶理解；
往往需要數據庫備份工具具備增量備份恢復能力；同時考驗備份工具消除相關硬件限制條件，讓該技術方案更加靈活；
雙集群的初始化同步往往采用全備全恢的邏輯實現，可以最大化、最快拉平存量數據；
對於規模大的平台，RPO往往需要小時級別，RTO最好水准也在分鍾、10分鍾以上；同時主集群需要保障一定資源量供數據同步使用，對主集群開銷大；
c) “數據同步模式” – 邏輯數據同步技術
適用靈活同步場景，往往數據同步量不會太大，或同步時間可容忍場景；
此場景往往適合於用戶對其數據倉庫ETL過程元數據信息清晰、完整，依賴客戶開發能力，相關同步數據存在清晰ETL算法，結合調度作業運行進度，動態發起相關數據表增、全量同步；
對於中等規模的平台，RPO可以做到分鍾、半小時，RTO可以維持在分鍾級；
d) “雙ETL模式”
需要兩套ETL調度環境，整體成本翻倍，但調度邏輯清晰、易於理解和維護；
較容易匹配不同規模的數據倉庫平台采納；
較難實現數據實時比對，以及數據發生不一致之后的控制邏輯（若需要實現，對於調度邏輯侵入性大）；
ETL調度批量中途，較難實現兩套調度鏈路協調重跑；
同時數據不一致，依賴於”數據同步模式”技術輔助實施；
由於主備調度進行不一致，無法做到主備統一視圖展現；
若雙集群硬件相當，RPO、RTO均可以維持在分鍾級別；
e) ”雙活模式“
需要獨立中間件、且嚴重依賴數據庫自身廠商，中間件實現難度大；
中間件的高可用（穩定性）成為它落地的最大障礙；
“雙ETL模式”的升級版，能適應各類數據倉庫雙集群場景；
絕大部分場景下，RPO、RTO均可以接近0，特別是雙活同時在線能力，不存在雙集群的主備切換，RTO可以做到0；同時存在統一視圖，不會因為其中一個集群故障，造成前后同一個查詢返回結果不一致場景；
5. 總結比對
