【數(shù)據(jù)倉庫】雙集群系統(tǒng)方案探討

本文主要是探討OLAP關(guān)系型數(shù)據(jù)庫框架的數(shù)據(jù)倉庫平臺如何設(shè)計雙集群系統(tǒng)，即增強系統(tǒng)高可用的保障水準。

當前社會、企業(yè)運行當中，大數(shù)據(jù)分析、數(shù)據(jù)倉庫平臺已逐漸成為生產(chǎn)、生活的重要地位，不再是一個附屬的可有可無的分析系統(tǒng)，外部監(jiān)控要求、企業(yè)內(nèi)部服務(wù)，涌現(xiàn)大批要求7*24小時在線的應(yīng)用，逐步出現(xiàn)不同等級要求的雙集群系統(tǒng)。

數(shù)據(jù)倉庫主流數(shù)據(jù)庫平臺均已存在多重高可靠保障措施設(shè)計，如硬盤冗余的raid設(shè)計、數(shù)據(jù)表冗余、節(jié)點備用冗余、機柜備用數(shù)據(jù)交叉等，以及加上服務(wù)進程高可用冗余設(shè)計，其最大化程度滿足數(shù)據(jù)倉庫服務(wù)持續(xù)在線。

但現(xiàn)實場景，如數(shù)據(jù)庫軟件缺陷、定期加固補丁、產(chǎn)品迭代、硬件升級這些產(chǎn)品現(xiàn)實因素，以及來自機房、數(shù)據(jù)中心、地域、網(wǎng)絡(luò)的外部災(zāi)難故障因素，均在降低數(shù)據(jù)倉庫可用性服務(wù)水平。

鑒于數(shù)據(jù)倉庫存在大量數(shù)據(jù)吞吐，針對不同數(shù)據(jù)庫、不同可用性要求，若需要設(shè)計雙集群冗余設(shè)計，可選技術(shù)手段分別有數(shù)據(jù)同步模式、雙ETL模式、雙活模式，具體探討如下：

1.?????? 數(shù)據(jù)同步模式

a)???????? 架構(gòu)

由于數(shù)據(jù)庫IO能力有限、且兩個數(shù)據(jù)庫間帶寬有限，除了首次全量同步之后，后續(xù)通?？紤]增量同步技術(shù)，即如何準確、高效獲取“變化數(shù)據(jù)”，一般存在日志同步技術(shù)、備份增量同步技術(shù)、邏輯數(shù)據(jù)同步；

b)??????? 日志同步技術(shù)

日志同步技術(shù)，有業(yè)內(nèi)最著名Oracle Golden Gate，大部分廠家也有自己的實現(xiàn)方式，像Teradata近年來推出Unity CDM（變化數(shù)據(jù)廣播）技術(shù)，而我司GaussDB for DWS可采用xlog及page進行變化數(shù)據(jù)同步。

優(yōu)勢：直接同步變化數(shù)據(jù)增量，數(shù)據(jù)量少，要求帶寬低，但目前市面技術(shù)大都只適合數(shù)據(jù)每日變化量較少的數(shù)據(jù)倉庫環(huán)境；

劣勢：現(xiàn)實的技術(shù)門檻高，應(yīng)對各類異常場景適應(yīng)能力差，對主數(shù)據(jù)庫侵入性能要求高，一旦主庫繁忙，同步時效低；面對全刪全插等變化數(shù)據(jù)量大場景，同步吃力；

c)???????? 備份增量同步技術(shù)

主要利用各數(shù)據(jù)庫平臺備份恢復(fù)能力，進行數(shù)據(jù)增、全量備份、恢復(fù)；通常源庫備份數(shù)據(jù)壓縮之后，經(jīng)網(wǎng)絡(luò)傳輸后，解壓恢復(fù)到目標庫；對應(yīng)GaussDB for DWS可采用roach備份恢復(fù)工具實現(xiàn)；

優(yōu)勢：利用同一技術(shù)實現(xiàn)增、全量數(shù)據(jù)同步，邏輯清晰，各場景容錯能力強；

劣勢：要求數(shù)據(jù)庫支持增備能力，且往往鎖等待嚴重；

d)??????? 邏輯數(shù)據(jù)同步

該項主要涉及較高的業(yè)務(wù)侵入性，即充分獲取ETL調(diào)度數(shù)據(jù)流元數(shù)據(jù)，對應(yīng)數(shù)據(jù)庫當日數(shù)據(jù)穩(wěn)定之后，發(fā)起數(shù)據(jù)表導(dǎo)出-導(dǎo)入操作，針對數(shù)據(jù)表加工特性，選擇增全量同步規(guī)則，進行數(shù)據(jù)準實時同步。

優(yōu)勢：較上述同步技術(shù)，可以實現(xiàn)多樣選擇性同步，同步過程由實施項目本身控制，做到表級數(shù)據(jù)同步，不需要全系統(tǒng)同步，即可實現(xiàn)部分業(yè)務(wù)雙集群；

劣勢：客戶化同步邏輯，操作前置依賴多，實施投入人力多，較難推廣；

2.?????? 雙ETL模式

a)???????? 架構(gòu)

即采用兩套獨立調(diào)度平臺進行數(shù)據(jù)加工，抽取同一個數(shù)據(jù)源（往往是落地穩(wěn)定的數(shù)據(jù)交換平臺），采用同一套ETL代碼依賴邏輯調(diào)度，各自生成目標數(shù)據(jù)，往往批量過程中，采取主庫對外持續(xù)服務(wù)，待主備庫數(shù)據(jù)準實時或批后校驗一致后，再開放備庫對外服務(wù)。

若雙集群數(shù)據(jù)發(fā)生不一致場景，主要以主庫數(shù)據(jù)為準，覆蓋備庫。該同步過程，需要使用到“數(shù)據(jù)同步模式”相關(guān)同步技術(shù)。

b)???????? 參照落地架構(gòu)

c)???????? 加載源數(shù)據(jù)考慮

為保證兩套ETL調(diào)度加載數(shù)據(jù)源一致及數(shù)據(jù)復(fù)用，往往要求搭建一個數(shù)據(jù)交換平臺。因為至少存在一個文件被兩套調(diào)度讀取，要求數(shù)據(jù)交換平臺兩倍過往吞吐能力；且禁止加載的數(shù)據(jù)文件被二次覆蓋，導(dǎo)致兩套系統(tǒng)加載不一致；

d)???????? 調(diào)度依賴順序考慮

由于ETL作業(yè)調(diào)度關(guān)系沒有配置完備，即存在A作業(yè)使用B作業(yè)的數(shù)據(jù)，但不配置依賴關(guān)系（絕大部分的情況是A作業(yè)可容忍B數(shù)據(jù)的時效，是否最新數(shù)據(jù)均可以使用，故為時效，業(yè)務(wù)上不配置依賴關(guān)系；當然也存在物理時間上，通常B遠遠早于A執(zhí)行），導(dǎo)致兩套系統(tǒng)A作業(yè)生成數(shù)據(jù)不一致。

該場景下，在一套調(diào)度平臺無法發(fā)現(xiàn)此問題，但存在兩套系統(tǒng)的校驗比對，即發(fā)現(xiàn)數(shù)據(jù)不一致；

該問題建議用戶補全依賴關(guān)系，確認執(zhí)行順序一致性；

當然若希望靈活使用依賴關(guān)系，則需二次開發(fā)，控制兩套調(diào)度當日時序一致性；

e)???????? ETL代碼服務(wù)器考慮

為了避免兩套ETL調(diào)度代碼維護不一致，需考慮統(tǒng)一維護渠道，包含不限于同一個代碼存儲源、版本服務(wù)器，以及代碼變更時機

f)????????? 存在不確定值的SQL函數(shù)返回

ETL代碼中往往存在sample、random、row_number排序這種同一份數(shù)據(jù)產(chǎn)生不同結(jié)果集的函數(shù)，造成兩套系統(tǒng)數(shù)據(jù)不一致；

該問題建議用戶使用替代函數(shù)、明確取值、唯一排序，確保最終數(shù)據(jù)一致性；

同時，該設(shè)計邏輯正確情況下，哪份數(shù)據(jù)均可被業(yè)務(wù)采信，若該數(shù)據(jù)對下游影響少，可每日批后從主庫同步備庫，拉平數(shù)據(jù)；

g)???????? 報錯修數(shù)邏輯考慮

其中一套系統(tǒng)的數(shù)據(jù)發(fā)生報錯、修數(shù)行為，會涉及到另一套系統(tǒng)的維護行為；

可選作法是保留操作邏輯，待另一套系統(tǒng)發(fā)生報錯時重復(fù)執(zhí)行一次；

其它交給數(shù)據(jù)質(zhì)量校驗（DQC）、數(shù)據(jù)校驗去復(fù)查；

h)???????? 干預(yù)重跑修數(shù)邏輯考慮

若批后重跑，兩套系統(tǒng)重跑邏輯一致，涉及重復(fù)勞動（或支撐平臺優(yōu)化），相對簡單；

但涉及批量過程中發(fā)現(xiàn)部分數(shù)據(jù)需要重跑，由于兩套調(diào)度進度不一致，會導(dǎo)致

i)?????????? 數(shù)據(jù)校驗

i.????????????? 校驗時機

批后校驗，邏輯清晰，對調(diào)度依賴少，即根據(jù)整體調(diào)度進度，做到分層、分庫或整體數(shù)據(jù)校驗；

準實時校驗，即侵入調(diào)度環(huán)節(jié)，在每個作業(yè)完成時，均發(fā)起日志解析，提取每個SQL影響記錄數(shù)，若相應(yīng)作業(yè)SQL存在影響記錄數(shù)不一致場景，即中止較晚完成的調(diào)度平臺調(diào)度后續(xù)作業(yè)；

ii.????????????? 校驗手段

增全量校驗，即針對不同加工邏輯的數(shù)據(jù)表，區(qū)分增、全量數(shù)據(jù)值，以最小代價覆蓋所有業(yè)務(wù)表

iii.????????????? 校驗方法

通常作法有記錄數(shù)、匯總值、checksum校驗；

匯總值校驗，通過是數(shù)值型字段直接sum、字符型計算字符長度的sum、時間類型則轉(zhuǎn)換成數(shù)值相加的比對；

Checksum校驗，針對全表或部分字段，進行md5或hash運算，完成兩套系統(tǒng)一致性比對；

對于關(guān)系型數(shù)據(jù)庫，校驗開銷代價逐步遞增（記錄數(shù) < 匯總值 < checksum校驗）；往往是結(jié)合增量校驗、結(jié)合重要指標，區(qū)分維度校驗，日常增量邏輯校驗，定期全量校驗，在校驗數(shù)據(jù)一致性和系統(tǒng)性能之間取得平衡點。

j)?????????? 優(yōu)化考量

i.????????????? 校驗改進

即嵌入調(diào)度平臺，提取ETL代碼運行日志，通過執(zhí)行SQL影響的記錄值，實時進行兩套系統(tǒng)完成作業(yè)日志比對，發(fā)現(xiàn)記錄值影響，立即停止備庫調(diào)度，采用人工或自動方式修復(fù)數(shù)據(jù)，繼續(xù)后續(xù)批量。

該作法最大好處是，即時發(fā)現(xiàn)數(shù)據(jù)異常，避免問題放大，保障備庫更高可用性；

ii.????????????? 引入統(tǒng)一維護平臺

即減少人為雙系統(tǒng)維護操作，代碼變更平臺化，修數(shù)邏輯平臺化，由平臺分別下發(fā)兩套調(diào)度平臺、兩套數(shù)據(jù)庫。

3.?????? 雙活模式

以下基于Teradata Unity產(chǎn)品理念的延伸構(gòu)想

a)???????? 架構(gòu)

b)???????? 雙活功能點

i.????????????? 訪問路由能力

客戶端直接將中間件作為數(shù)據(jù)庫登陸，保持原來登陸邏輯不變；

中間件根據(jù)登陸用戶及附加參數(shù)實現(xiàn)拒絕登陸、雙系統(tǒng)登陸、或單系統(tǒng)登陸，實現(xiàn)寫登陸、讀登陸，實現(xiàn)受控方式登陸、或非受控方式登陸；即實現(xiàn)受控和非受控方式的系統(tǒng)讀寫；

同時兼顧考慮異常路由選擇或同步路由選擇，滿足最大化異常執(zhí)行及少部分同步需求場景；

ii.????????????? SQL分發(fā)能力

經(jīng)中間件發(fā)送的SQL指令，正常發(fā)送到相應(yīng)數(shù)據(jù)庫，并接受數(shù)據(jù)庫響應(yīng)信息；

iii.????????????? 批量導(dǎo)入、導(dǎo)出能力

針對數(shù)據(jù)大批量的導(dǎo)入，需要考慮采用更加高效的加載協(xié)議進行數(shù)據(jù)加載，并考慮經(jīng)中間件復(fù)制數(shù)據(jù)塊，異步分發(fā)兩個數(shù)據(jù)庫；

數(shù)據(jù)導(dǎo)出，需要考慮高效數(shù)據(jù)導(dǎo)出協(xié)議，從其中一套數(shù)據(jù)庫正確導(dǎo)出數(shù)據(jù)；

iv.????????????? 更新類SQL校驗?zāi)芰?/p>

Delete、Update、Insert、Merge等更新類DML SQL進行SQL影響記錄數(shù)校驗；

DDL/DCL執(zhí)行返回碼驗證一致性能力；

v.????????????? 對象注冊功能

通過路由及創(chuàng)建對象的DDL語句，實現(xiàn)對象動態(tài)注冊；

通過命令行指令實現(xiàn)對象注冊；

適當增加對象索引、約束索引的注冊信息，用于擴展細粒度對象鎖能力，提高數(shù)據(jù)倉庫ETL SQL并發(fā)能力；

*數(shù)據(jù)倉庫環(huán)境下，只需要考慮到表級雙活的能力，不建議實施字段級、記錄級雙活；

vi.????????????? 對象鎖能力

根據(jù)SQL指令給相應(yīng)對象動態(tài)加鎖、釋放鎖；

同時根據(jù)數(shù)據(jù)庫自帶的鎖特征，至少區(qū)分讀、寫鎖控制，以及部分數(shù)據(jù)庫的臟讀功能鎖；

vii.????????????? 對象狀態(tài)控制能力

進行管理的多套數(shù)據(jù)庫在線狀態(tài)控制；

進行對象狀態(tài)控制功能，包含不限于在線、離線、只讀、只寫、主動中斷緩存中、被動中斷緩存中、不可用等狀態(tài)；

viii.????????????? 緩存能力

進行SQL指令流緩存能力，以及緩存恢復(fù)執(zhí)行的能力；

進行SQL與加載數(shù)據(jù)結(jié)合緩存、以及緩存恢復(fù)執(zhí)行的能力；

ix.????????????? SQL異?？刂颇芰?/p>

考慮用戶體驗，始終由返回響應(yīng)正確的SQL指令返回客戶端；

兩個數(shù)據(jù)庫返回均成功，但返回的影響記錄數(shù)不一致，則響應(yīng)慢的數(shù)據(jù)庫對應(yīng)SQL及涉及對象被設(shè)置成不可用狀態(tài)；

若兩套數(shù)據(jù)庫其中一套執(zhí)行成功，另一套執(zhí)行失敗，則執(zhí)行失敗的數(shù)據(jù)庫SQL和涉及對象被設(shè)置為被動中斷緩存中，同時緩存SQL，定時重試SQL；

若兩套數(shù)據(jù)庫返回均報錯，才通知客戶端報錯；

若SQL涉及對象已處理非在線狀態(tài)，則新提交的SQL被緩存，新提交SQL相應(yīng)對象被設(shè)置為被動中斷緩存中。

針對中間件和數(shù)據(jù)庫之間，存在數(shù)據(jù)庫已執(zhí)行完、但中間件未收到信號場景，需考慮閃環(huán)該場景（如增加事務(wù)鎖等）；

c)???????? Teradata Unity參照落地架構(gòu)

ü? 主要通過Unity實現(xiàn)多集群SQL、數(shù)據(jù)分發(fā)與管理；

ü? Data Mover實現(xiàn)集群間數(shù)據(jù)同步；

ü? Eocsystem Manager實現(xiàn)數(shù)據(jù)批后自動校驗及不一致重同步事件觸發(fā)；

ü? Viewpoint實現(xiàn)系統(tǒng)平臺透視圖展現(xiàn)與維護，并對接用戶告警平臺；

d)???????? 中間件高可用考慮

由于引入了中間件（前置）服務(wù)，即該服務(wù)的穩(wěn)定、可靠對雙活模式至關(guān)重要。

數(shù)據(jù)庫單套系統(tǒng)本身已經(jīng)具備極高的可用性，引入中間件后，由于所有數(shù)據(jù)庫訪問行為均通過該中間件，中間件任何異常均同時影響兩套數(shù)據(jù)庫訪問能力。

除了中間件本身所有相關(guān)服務(wù)需要滿足高可用之外，還需考慮極端場景下bypass能力，此項能力在于極端異常條件下，可以保障系統(tǒng)持續(xù)服務(wù)的能力。

高可用場景中，存在控制節(jié)點腦裂與自動升主場景，需借鑒仲裁機制減少腦殘裂發(fā)生；

e)???????? 數(shù)據(jù)重同步考慮

即利用“數(shù)據(jù)同步模式”相關(guān)同步技術(shù)，實現(xiàn)兩套數(shù)據(jù)庫數(shù)據(jù)重同步能力；

f)????????? 不確定值的SQL函數(shù)考慮

最佳方案，是采用“數(shù)據(jù)同步模式”的數(shù)據(jù)日志重同步技術(shù)，直接將第一套數(shù)據(jù)庫SQL執(zhí)行結(jié)果的日志信息同步到第二套數(shù)據(jù)庫中，消除返回結(jié)果不一致；

部分簡單的系統(tǒng)時間函數(shù)，直接通過中間件改寫，保障SQL執(zhí)行結(jié)果一致性；

另外，則通過SQL改寫，保證row_number函數(shù)進行主鍵或全字段排序，保證SQL執(zhí)行結(jié)果一致性；

g)???????? 異常會話重放能力

針對異常會話過程的SQL，可能需要從會話建立后，可視化選擇，倒回前幾個SQL重新執(zhí)行，并指定過程SQL是否參與結(jié)果集校驗，以及SQL回放結(jié)束的確認動作，讓異常場景處理手段更加豐富。

4.?????? 適用場景

a)???????? “數(shù)據(jù)同步模式” – 日志同步技術(shù)

適用數(shù)據(jù)變化量小、數(shù)據(jù)傳輸壓力小的數(shù)據(jù)場景，通常只適用于小型數(shù)據(jù)倉庫平臺；

對于規(guī)模小的平臺，RPO、RTO可以接近0；

b)???????? “數(shù)據(jù)同步模式” – 備份增量同步技術(shù)

適合大數(shù)據(jù)量同步場景，實現(xiàn)方式容易被用戶理解；

往往需要數(shù)據(jù)庫備份工具具備增量備份恢復(fù)能力；同時考驗備份工具消除相關(guān)硬件限制條件，讓該技術(shù)方案更加靈活；

雙集群的初始化同步往往采用全備全恢的邏輯實現(xiàn)，可以最大化、最快拉平存量數(shù)據(jù)；

對于規(guī)模大的平臺，RPO往往需要小時級別，RTO最好水準也在分鐘、10分鐘以上；同時主集群需要保障一定資源量供數(shù)據(jù)同步使用，對主集群開銷大；

c)???????? “數(shù)據(jù)同步模式” – 邏輯數(shù)據(jù)同步技術(shù)

適用靈活同步場景，往往數(shù)據(jù)同步量不會太大，或同步時間可容忍場景；

此場景往往適合于用戶對其數(shù)據(jù)倉庫ETL過程元數(shù)據(jù)信息清晰、完整，依賴客戶開發(fā)能力，相關(guān)同步數(shù)據(jù)存在清晰ETL算法，結(jié)合調(diào)度作業(yè)運行進度，動態(tài)發(fā)起相關(guān)數(shù)據(jù)表增、全量同步；

對于中等規(guī)模的平臺，RPO可以做到分鐘、半小時，RTO可以維持在分鐘級；

d)???????? “雙ETL模式”

需要兩套ETL調(diào)度環(huán)境，整體成本翻倍，但調(diào)度邏輯清晰、易于理解和維護；

較容易匹配不同規(guī)模的數(shù)據(jù)倉庫平臺采納；

較難實現(xiàn)數(shù)據(jù)實時比對，以及數(shù)據(jù)發(fā)生不一致之后的控制邏輯（若需要實現(xiàn)，對于調(diào)度邏輯侵入性大）；

ETL調(diào)度批量中途，較難實現(xiàn)兩套調(diào)度鏈路協(xié)調(diào)重跑；

同時數(shù)據(jù)不一致，依賴于”數(shù)據(jù)同步模式”技術(shù)輔助實施；

由于主備調(diào)度進行不一致，無法做到主備統(tǒng)一視圖展現(xiàn)；

若雙集群硬件相當，RPO、RTO均可以維持在分鐘級別；

e)???????? ”雙活模式“

需要獨立中間件、且嚴重依賴數(shù)據(jù)庫自身廠商，中間件實現(xiàn)難度大；

中間件的高可用（穩(wěn)定性）成為它落地的最大障礙；

“雙ETL模式”的升級版，能適應(yīng)各類數(shù)據(jù)倉庫雙集群場景；

絕大部分場景下，RPO、RTO均可以接近0，特別是雙活同時在線能力，不存在雙集群的主備切換，RTO可以做到0；同時存在統(tǒng)一視圖，不會因為其中一個集群故障，造成前后同一個查詢返回結(jié)果不一致場景；

5.?????? 總結(jié)比對

數(shù)據(jù)倉庫服務(wù) GaussDB(DWS)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。