在數(shù)據(jù)倉庫建模中，未經(jīng)任何加工處理的原始業(yè)務(wù)層數(shù)據(jù)，稱之為 ODS（Operational Data Store）數(shù)據(jù)。作為 DBA 來說，關(guān)心的肯定是如何把關(guān)系型數(shù)據(jù)庫的業(yè)務(wù)數(shù)據(jù)同步到數(shù)據(jù)倉庫中去…

一、領(lǐng)導(dǎo)的需求

我從一份領(lǐng)導(dǎo)的需求開始：

1. 實現(xiàn)業(yè)務(wù)系統(tǒng) 7*24 小時不間斷運行。

2. 保證業(yè)務(wù)系統(tǒng)數(shù)據(jù)安全性。

3. 降低生產(chǎn)系統(tǒng)壓力，將部分查詢和報表分析業(yè)務(wù)負載分離出去。

看似簡單的幾行字，實際上并不簡單，對我們公司而言，至少走過了幾年，痛苦的幾年…

二、系統(tǒng)架構(gòu)

我先介紹一下公司某業(yè)務(wù)數(shù)據(jù)庫選型和架構(gòu)，業(yè)務(wù)庫采用了 Oracle 11G RAC+DataGuard (3+2)，數(shù)據(jù)倉庫是 2 套單實例的 ORACLE 12C。

1. 主備節(jié)點之間采用光纖直連。

2. 正常情況下，主節(jié)點的數(shù)據(jù)（REDO）傳遞到備節(jié)點 APPLY。

3. 切換至備庫節(jié)點步驟：

• 當(dāng)生產(chǎn)數(shù)據(jù)庫發(fā)生災(zāi)難時，備庫角色從 standby 變?yōu)?primary，可以進行業(yè)務(wù)負載。

• 將 DNS 中主庫域名解析地址由主庫 scan ip 切換至備庫 scan ip。

• 應(yīng)用配置無需更改，最大限度的提高業(yè)務(wù)恢復(fù)速度。

DataGuard 有 switch over、fail over 兩種切換方式。

1. switch over 功能，在容災(zāi)演練、生產(chǎn)環(huán)境服務(wù)器或存儲硬件升級、服務(wù)器非存儲類硬件故障或其它計劃內(nèi)的切換動作時，可以采用 switch over 方式進行切換。switch over 切換過程是可逆的，即主備數(shù)據(jù)庫可以反復(fù)相互切換。*

2. fail over 功能，當(dāng)生產(chǎn)環(huán)境服務(wù)器發(fā)生存儲類故障且無法修復(fù)，可以采用 failover 方式強制切換。failover 切換過程是不可逆的，備數(shù)據(jù)庫變?yōu)橹鲾?shù)據(jù)庫后，是不能再回切回來的，即使原來的主數(shù)據(jù)庫修好后，需要重建 DataGuard，才能保持容災(zāi)同步關(guān)系。

2016 年的某一個晚上，我們拉研發(fā)、測試人員等十幾號人，埋頭奮戰(zhàn)了一夜，通過 SWITCH OVER 切換演練，做到了大部分應(yīng)用程序無縫接管，保證了核心業(yè)務(wù)連續(xù)性。當(dāng)然，也發(fā)現(xiàn)了一些問題，也及時進行經(jīng)驗總結(jié)。

1. 在業(yè)務(wù)應(yīng)用服務(wù)梳理中，遺漏了少部分外圍的系統(tǒng)，事后才發(fā)現(xiàn)。

2. 在 DNS 進行域名切換時，少部分服務(wù)出現(xiàn)訪問異常，由于長事務(wù)等原因，后手動重啟服務(wù)才解決的。

在我們引進 ORACLE RAC+DataGuard 架構(gòu)后，帶來的效果是明顯的，解決我們數(shù)據(jù)庫的單點故障，備庫承擔(dān)了大部分讀的角色，同時也釋放了主庫的一部分讀寫壓力。加上每天 RMAN LEVEL0-LEVEL2 的備份機制，保證了核心業(yè)務(wù)系統(tǒng)數(shù)據(jù)安全性，也朝著實現(xiàn)核心業(yè)務(wù)系統(tǒng)7*24 小時不間斷運行邁進了很重要的一步。

故事還沒結(jié)束，才剛剛開始，呵呵！我的中心思想是業(yè)務(wù)報表數(shù)據(jù)同步，如何實現(xiàn)數(shù)據(jù)同步？如何給數(shù)據(jù)中心那邊提供一個單純，而又干凈的數(shù)據(jù)倉庫呢？

看到這，大部分讀者首先想到是 DBLINK 最方便，在備庫上用 DBLINK 同步。作為 DBA 來言，不能否認用 DBLINK 在某些方面確實能帶來方便，如臨時遷移數(shù)據(jù)、少部分基礎(chǔ)表的數(shù)據(jù)同步等，但作為數(shù)據(jù)倉庫建模，做大數(shù)據(jù)分析、報表，可想而知，數(shù)據(jù)量的規(guī)模，DBLINK 太小家子氣了，而且用 DBLINK 存在隱患。

1. 不支持?jǐn)帱c續(xù)傳功能，如果源端數(shù)據(jù)庫出問題（UNDO 不足、TEMP 不足等）、網(wǎng)絡(luò)問題，需要重新同步數(shù)據(jù)，牽扯到效率問題。

2. 不支持 DDL，如果通過大量的自定義觸發(fā)器來實現(xiàn)，在效率和準(zhǔn)確性方面需要長時間驗證，得不償失。

3. 幾年前爆發(fā)的 dblink 導(dǎo)致 SCN Headroom 過低問題，有血的教訓(xùn)。

具體可以參考：
System Change Number (SCN), Headroom, Security and Patch Information (文檔 ID 1376995.1)

Installing, Executing and Interpreting output from the “scnhealthcheck.sql” script (文檔 ID 1393363.1)

三、利劍之一 Kettle+Azkaban

我們首先想到了 ETL 工具，想到了 Kettle，也想到了 Azkaban。

• ETL 是 EXTRACT（抽?。?、TRANSFORM（轉(zhuǎn)換）、LOAD（加載）的簡稱，實現(xiàn)數(shù)據(jù)從多個異構(gòu)數(shù)據(jù)源加載到數(shù)據(jù)庫或其他目標(biāo)地址，是數(shù)據(jù)倉庫建設(shè)和維護中的重要一環(huán)，也是工作量較大的一塊。

• Azkaban 是一個任務(wù)調(diào)度系統(tǒng)，用于負責(zé)任務(wù)的調(diào)度運行（如數(shù)據(jù)倉庫調(diào)度），用以替代 linux 中的 crontab。

Kettle 是一款國外開源的 ETL 工具，JAVA 開發(fā)的，數(shù)據(jù)抽取高效穩(wěn)定。Kettle 中文名稱叫水壺，該項目的主程序員 MATT 希望把各種數(shù)據(jù)放到一個壺里，然后以一種指定的格式流出。

Azkaban 是一個 Linkedin 開源的，JAVA 開發(fā)的，批量工作流任務(wù)調(diào)度器， 用于在一個工作流內(nèi)以一個特定的順序運行一組工作和流程，定義了一種 KV 文件格式來建立任務(wù)之間的依賴關(guān)系，友好 WEB 界面，便于維護和跟蹤工作流。

kettle 和 Azkaban 的引入，也驗證了一句話，“好東西永遠不愁賣，何況還不要錢”。

關(guān)鍵工作流程：

????如圖所示，首先在 Spoon 上編排數(shù)據(jù)抽取任務(wù)（任務(wù)中包含多個轉(zhuǎn)換，多任務(wù)并行執(zhí)行），其次將源表的數(shù)據(jù)經(jīng)過處理輸出到目標(biāo)端數(shù)據(jù)庫中，更新原有記錄，再次在 Spoon 上完成任務(wù)編排，通過組件 kitchen 來調(diào)用編排好任務(wù)，最后將調(diào)用的內(nèi)容編寫成 shell 腳本，由 azkaban 進行任務(wù)調(diào)度。

Azkaban 友好的 WEB 界面，運維人員能方便的查看任務(wù)執(zhí)行情況，以及任務(wù)執(zhí)行日志。

目前公司業(yè)務(wù)報表情況統(tǒng)計如下：

四、利劍之二 GOLDENGATE

隨著公司業(yè)務(wù)數(shù)據(jù)的不斷增長，業(yè)務(wù)數(shù)據(jù)種類越來越多，領(lǐng)導(dǎo)對各類數(shù)據(jù)整合的要求也越來越高，數(shù)據(jù)中心能否及時對實時數(shù)據(jù)深層次的挖掘、分析？已成為重要一環(huán)，目前面臨的刺手問題是數(shù)據(jù)的實時性。

基于數(shù)據(jù)的可靠性、實時性等要求，我們開始嘗試 Oracle 下 GoldenGate 產(chǎn)品，先簡單介紹 GoldenGate 產(chǎn)品。

• 2009 年被 Oracle 收購，成為 Oracle 在實時數(shù)據(jù)集成，數(shù)據(jù)復(fù)制和數(shù)據(jù)高可用性領(lǐng)域的戰(zhàn)略性產(chǎn)品。

• 跨異構(gòu)環(huán)境，對系統(tǒng)負載影響很低，對交易型數(shù)據(jù)做實時抓取、路由、轉(zhuǎn)換和傳遞。

• 和其他產(chǎn)品關(guān)鍵差異點 ：
  性能：非侵入式、低影響和亞秒級的延遲
  彈性、可擴展：開放和模塊化的架構(gòu)，支持異構(gòu)數(shù)據(jù)源和目標(biāo)
  可靠：保持交易事務(wù)的完整性 ，對中斷和失敗容忍度高

從官方找了二張 goldengate 的工作流程圖：

作為 ORACLE 鐵粉的我，我相信它的實力。

曾經(jīng)有過這么一段故事，有點久了，希望不會影響您的判斷，有一丁點參考價值，我都開心。在 2014 年 5 月左右，跟 ORACLE 工程師 James 經(jīng)過 2 周的時間，共同完成了對 oracle goldengate 同步工具（產(chǎn)品）的測試工作，文檔《江蘇某支撐平臺 oracle goldengate 同步工具測試用例 _v1.3》。

在測過過程中發(fā)現(xiàn)一些性能瓶頸，如下：

1. Analyz 操作分析表不能同步，需要在目標(biāo)端手動執(zhí)行。

2. 沒有主鍵和唯一索引的大表的 update、delete 操作，目標(biāo)端執(zhí)行時間較長，對某業(yè)務(wù)表（表大小 53G）進行 130 萬條記錄刪除，目標(biāo)端執(zhí)行 8 小時以上（速度相差近 300 倍）。

3. 在數(shù)據(jù)校驗測試中，有主鍵和唯一建的表與無主鍵和唯一建的表，在數(shù)據(jù)量基本相同情況下，速度相差 6 倍以上。

4. 業(yè)務(wù)高峰期 OGG 軟件后臺進程消耗 CPU 資源情況如下：
   一個復(fù)制進程要消耗 4%CPU；一個抽取進程要消耗 3%CPU；
   目標(biāo)端開啟 8 個復(fù)制進程時，cpu 消耗 36% 左右，開啟 4 個復(fù)制進程時，cpu 消耗 20% 左右。

廢話少說，開始我們的介紹，首先了解一下數(shù)據(jù)庫基礎(chǔ)環(huán)境。

主要的實施步驟

1. 源端 /OGG 為共享文件目錄。

2. 源端在 dataguard 中備庫某一節(jié)點上部署 Manager、Extract、DataPump 進程。

3. 在目標(biāo)端節(jié)點上部署 Manager、Replicat 進程。

說明：源端使用 ASM 存放數(shù)據(jù)文件或日志文件，必須使用 SYS 用戶登錄 ASM 實例，在源端 extract 參數(shù)文件中要配置：

TRANLOGOPTIONS ASMUSER SYS@<ASM_instance>, ASMPASSWORD <password>

經(jīng)過 1~2 個月的反復(fù)測試和驗證過程中，在 DDL/DML 同步、斷點續(xù)傳、實時性、數(shù)據(jù)安全性等取得了很好的效果，尤其是在備庫節(jié)點承擔(dān)了 OGG 抽取進程的所有消耗，對主庫基本無影響下進行的，也滿足了數(shù)據(jù)中心對數(shù)據(jù)的實時性的要求。花了將近半年的時間，在數(shù)據(jù)中心的大力協(xié)助下，我們成功的把 Kettle 上 300 多張核心業(yè)務(wù)的表遷移到 OGG 上，豐富了多維度的報表開發(fā)，實時報表也上線了，管理后臺的財務(wù)報表也計劃從業(yè)務(wù)庫遷移至數(shù)據(jù)倉庫。這下，大家都開心了，是不是可以“假裝友好的”擁抱一下，開個玩笑，哈哈！

如下圖所示，分別部署了 6 個抽取進程、投遞進程和復(fù)制進程。

對于百萬級以下新增表同步，基本做到在線實施。當(dāng)然，期間 replicat 進程會出現(xiàn)大量 Error ORA-01403: no data found 的錯誤，導(dǎo)致 replicat 進程 ABENDING，一般選擇業(yè)務(wù)低峰期，通過 skiptransaction 后，手動補齊差異數(shù)據(jù)來實現(xiàn)。

不知不覺中，dataguard 已經(jīng)上線了 1 年多，一直高效、穩(wěn)定的執(zhí)行他的職責(zé)。因此，我們還上了異構(gòu)平臺的數(shù)據(jù)同步（Oracle->mysql），如天眼系統(tǒng)數(shù)據(jù)同步、對賬系統(tǒng)數(shù)據(jù)同步、火車票項目數(shù)據(jù)同步等。

五、小插曲

當(dāng)然也出現(xiàn)過小插曲，2019 年 6 月左右上線的新增城市站點項目，給我們帶來了不少困惑，項目上線后，replicat 出現(xiàn)數(shù)據(jù)延時，從 1 小時積壓到 10 多小時，突然感覺 replicat 進程 HANG 了，而且是所有的 replicat 進程都不工作了。 通過目標(biāo)端 info repyw2、send repyw2,status，源端 send extyw2, showtrans 等命令，發(fā)現(xiàn) RBA 刷新非常慢， 存在長事務(wù)。于是組織相關(guān)的研發(fā)人員討論，戰(zhàn)火開始了，您懂得。

通過對代碼的排查，發(fā)現(xiàn)新增站點處理流程中加入事務(wù)管理，而且在調(diào)度中通過 city_id 字段采用并發(fā)機制，反復(fù)對某城市站點表中 SYNC_FLAG 字段更新（業(yè)務(wù)邏輯有點復(fù)雜，此處省略了），導(dǎo)致了處理未提交事務(wù)。我們內(nèi)部初步認為是長事務(wù)導(dǎo)致 replicat 進程 HANG ，造成數(shù)據(jù)延時。通過 mos 找到蛛絲馬跡，Goldengate 12.1.2 Integrated Replicat Appears To Hang when Applying a transaction against an 11.2.0.4 database (Doc ID 1609690.1)。

經(jīng)過多次跟研發(fā)溝通，研發(fā)同意在新增站點處理流程取消事務(wù)管理，引進了中間表進行改造，等業(yè)務(wù)邏輯測通后，且降低和控制并發(fā)（從 300 降到 50,30,10）的情況下，再次上線，發(fā)現(xiàn)問題依舊，但是數(shù)據(jù)延時由 10 多小時降到 1 小時 30 分鐘左右，期間加入提升 replicat 進程性能的批處理進程模式 BATCHSQL。期間通過業(yè)務(wù)日志系統(tǒng)發(fā)現(xiàn)部分城市站點出現(xiàn)了 ORA-08103 對象不存在錯誤。

BATCHSQL BATCHESPERQUEUE 1000,BATCHTRANSOPS 2000 ,OPSPERBATCH 6000 , OPSPERQUEUE 6000

此時，我多想在 ORACLE support 上開個 SR，尋求 ORACLE 的幫助?。o奈，只能打消這念想，繼續(xù)前行…

關(guān)鍵的一步, 分兩種思路走

第一，繼續(xù)優(yōu)化業(yè)務(wù)邏輯，結(jié)合 ORA-8103 觸發(fā)場景，我們暫且用 DELETE 代替了 TRUNCATE，優(yōu)先避免錯誤發(fā)生，先不考慮 DELETE 效率低下，以及帶來高水位問題。

cause: This ORA-08103 occurs on the next block read after the truncate command.
Possible solutions are:
- Use DELETE instead of TRUNCATE  
- Use SELECT FOR UPDATE as this will try to lock the table

第二，我們對新增站點處理流程進行存儲過程的改寫，采用事務(wù)類型的臨時表來代替中間表。此處，應(yīng)該有掌聲，這是同事張春蕾的杰作，當(dāng)然，也少不了研發(fā)同事的大力協(xié)作。有興趣的可以提供該過程的代碼。

等再次上線后，成功的解決了 replicat 進程 HANG，數(shù)據(jù)延時等問題，不想再贅述枯燥地細節(jié)，當(dāng)然有興趣者，我們可以一起探討，謝謝！

六、總結(jié)

結(jié)束了嗎？

結(jié)束了，我反問，是不是快了點（尷尬了）…

嚴(yán)肅一點，再來一次，真的結(jié)束了嗎？

沒有。從理論上說，文章結(jié)束了，但從實踐上說，還沒有，我們才剛開始…

這不是廢話嘛!
…
…
…

好了，言歸正傳，我來總結(jié)和展望一下吧。

• 公司數(shù)據(jù)平臺基于 Kettle+Azkaban 和 GOLDENGATE 兩大利器，基本覆蓋了公司內(nèi)部各個業(yè)務(wù)線，目前能夠滿足絕大部分業(yè)務(wù)的數(shù)據(jù)同步需求，實現(xiàn)業(yè)務(wù) DB 數(shù)據(jù)準(zhǔn)確、高效地入倉。

• 而對業(yè)務(wù)服務(wù)類的日志數(shù)據(jù)（Log）入倉的部分又是另一個課題，賣個關(guān)子，公司有一套穩(wěn)定的 HADOOP 集群平臺，通過 flume、kafka、spark 等技術(shù)解決了公司大部分用戶行為的分析需求， 但是，重點來了，對于兩者的數(shù)據(jù)整合、后續(xù)構(gòu)建高可用容災(zāi)等，我們不得不又面臨的重要難題，也許分布式架構(gòu)的 NEWSQL（TIDB，小強 DB 等）是我們下一站，加油！我們才真正的開始…