基于異構數據庫的歷史數據中心建設

文/李璋琪

1 引言

傳統行業的核心數據庫普遍采用商業數據庫軟件，例如本文中所涉及的某省級電信運營商的計費、CRM等系統均使用Oracle數據庫。一般情況下，歷史數據中心采用與生產系統相同的數據庫軟件，優點是與生產系統完全兼容，應用程序的開發、移植均相對容易。但也存在不足，例如：隨著數據量增大，查詢統計耗時越來越長；計算能力擴充受到限制，較難滿足日益增多的大數據分析類需求等。

為解決現有歷史數據中心效率與應用等方面的瓶頸，研究并采用分布式開源數據庫，從評估選型、數據遷移、應用改造、管理模式等多方面進行了實踐與探索，實現了與生產數據庫異構的歷史數據中心系統。通過多種場景下的生產實踐驗證了該方法的可行性與優勢，并為后續類似系統的建設或改造提供思路、建議與參考。

2 基于異構數據庫的歷史數據中心建設研究

2.1 總體設計思路

經過需求、研發、運管等部門共同分析，決定采用與生產系統異構的分布式開源數據庫作為歷史數據中心底層數據平臺，將原有的集中式數據存儲改為分布式存儲。同時，不影響原有業務用戶的使用，不改變原有業務流程，例如：基于歷史數據的分析工作，數據歸檔/清理策略等。如圖1所示。

2.2 歷史數據中心數據庫選型與分析

表1：MySQL與PostgreSQL對比

表2：PostgreSQL內核數據庫對比

圖1：總體架構示意圖

2.2.1 數據庫選型

考慮到的因素包括：歷史數據相關應用的業務特點，新舊系統切換難易程度與成本，語法、函數、數據庫對象與數據類型的兼容性，應用系統改造的范圍及難易程度等。此外，要求備選的數據庫必須是技術成熟的主流開源數據庫，可進行分布式部署，具有良好的技術支持，無需對數據庫本身進行二次開發，能夠直接應用于系統建設。

經過初步篩選，PostgreSQL、MySQL或者基于上述兩者內核的數據庫符合要求，進一步對比發現PostgreSQL與現有Oracle數據庫的兼容性更好，尤其在數據查詢與統計分析方面更加吻合歷史數據中心的業務特性，對比結果如表1所示。

進一步，通過對比三種基于PostgreSQL內核的分布式架構產品發現，Greenplum在適用性、兼容性、技術支持等方面均有優勢，而且針對并行數據加載、資源管理、查詢優化、存儲等方面進行了增強，更加符合歷史數據中心的應用特點。此外，在公司內部已有基于Greenplum的應用成功案例，因此確定采用Greenplum作為后臺數據庫。結果如表2所示。

表3：對象類型兼容性分析

表4：對象類型兼容性分析

表5：內置函數兼容性分析

2.2.2 兼容性分析

首先，分析當前數據庫與目標數據庫之間命名規范的兼容情況，結論如下：

（1）現有的生產與歷史數據庫表名、字段名均采用英文命名，與目標數據庫要求相兼容，無需變更。

（2）現有的生產與歷史數據庫表名最大長度為30字節，最大的字段名、視圖名、數據庫用戶名長度均為30字節。目標數據庫所支持的最大長度為63字節，能夠兼容，無需變更。

其次，梳理對象類型的兼容性情況，并評估替換后的影響。基于歷史數據中心的業務特點，目標數據庫并不需要使用原有數據庫的所有對象類型，且對于少部分不支持的特性可使用其他方式進行規避。結果如表3所示。

再次，經過數據類型比對，僅有ROWID類型不被支持。經檢查，原有數據庫中涉及使用rowid類型的對象并非實體表，無需在歷史數據中心使用。分析內容與結論如表4所示。

最后，梳理數據庫內置函數的兼容情況。根據開發部門提供的SQL語句進行分析，共涉及ORACLE數據庫內置函數14個，其中3個函數需要進行重寫（START WITH CONNECT BY PRIOR，connect by prior start with，DECODE）。部分函數的替換方式如表5所示。

2.2.3 應用程序代碼改造

需要對應用程序代碼進行排查與改造，將原有基于oracle數據庫編寫的代碼改造為標準SQL語句或與目標數據庫兼容，本次實施中涉及的改造范圍和要點如下：

（1）部分函數需要調整為目標數據庫兼容的函數，參見表5；

（2）常量需要調整，目標數據庫要求顯性強制轉換；

（3）變量引用需要調整為目標數據庫兼容的方式；

（4）去除SQL語句中的強制索引（HINT）；

（5）左右連接（+）連接需要轉換為標準的SQL；

（6）遞歸引用需要轉換為目標數據庫支持的遞歸方式；

表6：原有歷史數據中心硬件信息

表7：數據節點設備硬件信息

圖2：數據導出耗時與進程數量之間的關系

圖3：導出文件大小與進程數量之間的關系

（7）行號、分頁處理，需要調整為目標數據庫支持的方式。

注：數據類型轉換在目標數據庫搭建期間處理。

2.2.4 設備選型與評估

原有歷史數據中心主機和存儲容量信息如表6所示。

評估預期的資源規模，需要x86架構主機總數58臺，其中管理節點2個，數據節點56個。數據節點單臺x86設備配置信息如表7所示：

2.3 原有歷史數據中心存量數據遷移

根據規劃完成硬件平臺建設后，需將原有數據庫中的所有數據遷移到新建的歷史數據中心。可選的遷移方案有：OracleFDW、ETL工具ora2pg、sqluldr2工具導出+Gpcopy導入、基于數據庫觸發器或者事務日志的同步方式，或者開發專用的數據遷移工具（例如：可基于JAVA開發應用程序，同時連接兩端數據庫，讀取源數據庫中的數據，寫入目標數據庫中）。

該階段工作的難點在于，當原有數據庫中存有clob、blob等大對象字段類型時，不能采用常規的數據遷移方式。經過實踐，在有少量clob或blob時，采用開源工具ora2pg實現比較方便，但在數據量較大時效率不高，建議開發輕量級的java應用以提高遷移效率。

2.4 生產系統增量數據遷移方式評估、選擇與注意事項

根據生產系統的數據生命周期管理策略，需要定期將非活躍數據遷移至歷史數據中心。由于增量數據的遷移涉及到生產系統的變更，因此需要評估并控制數據導出、導入等環節的時長。此外，需要嚴格評估數據在異構數據庫之間遷移之后的完整性、一致性和可用性。

異構數據庫之間一般采用文本形式進行數據交換，但Oracle沒有提供此類文本導出工具。因此，選用基于OCI接口編寫的第三方文本導出工具sqluldr2，并使用目標數據庫工具gpcopy導入文本。為避免導出數據分行或者特殊字符影響數據導入，數據導出階段選擇CSV格式。

2.4.1 數據導出評估

評估環境如表8所示。

數據導出評估結果表9所示。

進一步分析所得結果之間的關系如圖2與圖3所示。

由上述分析可知，sqluldr2加大進程數量可以明顯降低數據導出時間，但導出的數據文件大小會有所增加。以此為參照，可以根據系統負載情況，采用合適的進程數量導出數據。

2.4.2 數據導入評估

評估環境如表10所示。

數據導入評估結果如表11所示。

由上述分析可知，加大進程數量可以降低數據導入時間，以此為參照，可以根據系統負載情況，采用合適的進程數量導入數據。

2.4.3 數據加載問題與解決方法

經過多種場景下的數據導出與導入驗證，發現在如下三種情況會導致數據導入出錯或不完整，問題與解決方法如表12所示。

表8：數據導出環境

圖4：數據清理流程對比

工具sqluldr2支持以csv格式導出數據，能夠同時解決分隔符與xml數據分行兩類問題。此外，上述問題均可以通過使用ora2pg作為備選解決方案，在滿足ora2pg的環境下可以使用。

2.5 生產系統增量數據遷移

切換到開源數據庫之后，并不需要改變原有的數據生命周期管理策略，生產數據庫的定期數據遷移與數據清理流程也與之前保持一致，僅在數據導出、導入方法方面存在差異，如圖4所示。

3 初步實踐與應用效果分析

（1）原有歷史數據中心使用集中式高端存儲，數據的存儲周期為1年，超期數據需要轉為離線存儲。改用分布式開源數據庫之后，搭配較為廉價的存儲，獲得了更大的容量，數據存儲周期延長到5年，有助于提高業務故障處理效率，減少客戶投訴。

以用戶歷史業務辦理情況查詢為例，在查詢2年以上的歷史套餐辦理情況場景下，原有環境中受制于數據存儲周期，需要繁瑣的流程及多個部門協作，一般處理時長在5天左右。新歷史數據中心數據存儲周期更長，可以直接查詢到此類數據，絕大多數歷史數據的查詢工單均可在0.5天內完結，大幅度提高了業務故障處理效率，如圖5所示。

（2）新歷史數據中心在處理復雜統計分析類應用的場景時具有明顯的性能優勢，以省內某項業務季度報、年報的生成速度進行比對可知，效率提升分別在6倍與10倍左右（如圖6所示）。同樣，得益于分布式數據庫在統計分析類業務處理速度的提高，后續可以繼續挖掘新的業務類型，使歷史數據中心能夠發揮更大的作用。

4 結束語

本文在研究主流開源數據庫的功能，以及開源與原有商用數據庫之間的兼容性分析的基礎上，通過分析業務場景和歷史數據的應用需求，實現了一種與生產系統數據庫相異構的，以分布式開源數據庫為底層數據平臺的歷史數據中心系統，并成功應用于歷史數據相關的生產實踐中。

在大型生產系統中的實際應用效果表明，本方法在數據統計分析應用方面具有明顯的性能優勢，能夠提升應用的性能與效率，使歷史數據為分析決策提供更多支持，使數據發揮更大的價值。

表9：數據導出結果對比

表10：數據導入環境

表11：數據導入結果對比

表12：數據加載問題與解決方法

圖5：業務故障處理時長對比

圖6：報表生成時間對比