3種雙叢集系統方案設計模式詳解

摘要：本文主要是探討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. 總結比對