「最全最新」農業銀行數據庫使用實踐和發展規劃

摘要：中國農業銀行（以下簡稱：農行）在信息化系統建設過程中，先是把關係型數據庫作為聯機交易型數據庫使用，後來為滿足分析型應用需要開始使用分析型數據庫，近幾年來隨著應用場景細分，對基於 Hadoop 的大數據生態和新興起來的 NoSQL、NewSQL 等數據庫也逐步開始了大量應用。在數據庫的整個使用過程中，關係型數據庫一直佔據著最為重要的位置，市場上主流關係型數據庫產品都有使用到，積累了較多的使用經驗。隨著這幾年兩地三中心工程建設，對關係型數據庫的使用提升到了一個新的層次。為了適應業務和技術市場的不斷進化，對分佈式數據庫、Spark SQL 等新興數據庫技術也有了深入的探索研究和實踐，對數據架構管控、數據生命週期管理和數據庫產品應用進行了整體規劃。

作者：蔡仕志

編輯：張曉藝

蔡仕志，農行研發中心高級專家。理學學士，高級工程師，先後就職於中國農業銀行福建省分行、總行軟件開發中心、信息技術管理部、數據中心，現任中國農業銀行研發中心高級專家。長期深耕系統技術領域，曾獲國家機關優秀青年創新獎，工作成果先後獲得人民銀行、銀監會各類獎項10餘次。

本文根據蔡仕志老師在DTCC數據庫大會分享內容整理而成，將介紹農行數據庫使用實踐和發展規劃，主要包括數據庫使用實踐、數據管理體系建設、數據管理典型案例、數據庫發展規劃等。

數據庫使用實踐

1.1農行省域及數據大集中

2000年左右，農行開始啟動省域數據集中，前後時間大約4年，之後進行數據大集中，時間也在4年左右。

省域集中即把各個地市的數據甚至包括手工網點的數據上收到省行，數據大集中是把所有數據上收到總行。在省域集中的過程中，由於各個省業務量有大有小，因此，採用的技術方案不同。業務量大的省會使用IBM的大型機，有些中等業務量省份會用IBM的中型機AS/400 ，有些中等業務量及小業務量省份會用開放平臺的Unix小型機（IBM和HP）。

農行數據大集中先是將數據集中到北京，後來遷移到上海。數據上收後，各個省仍然有開放平臺的數據庫。無論是在省域集中還是數據大集中階段，凡是用了IBM大型機和中型機的，都是使用IBM的DB2，凡是開放平臺UNIX下，都用的是Sybase ASE。

農行曾經大規模使用了Sybase，後來隨著數據體量的增加和Sybase自身的發展問題，Sybase逐漸無法滿足農行的需求，這個問題我們後面再聊。

1.2農行數據庫產品總覽

農行數據庫使用情況如下：

業務量較大、響應較高的系統最開始使用Sybase ASE，後來因為Sybase無法滿足高併發下的業務處理需求，就引入了Oracle；

少量業務處理應用系統因特殊原因，使用了：SQL Sever、MySQL、DB2 PureScale等；

分析型領域：最開始使用Sybase IQ，後來也是無法滿足大數據量下的處理效率，只好引入國產南大通用GBASE，結合Hadoop、HBASE等產品；

內存數據庫:Redis、MemCache、MongoDB等。

1.3 關係數據庫工具箱

除了數據庫產品本身以外，還有一些相應的工具箱。

PowerDesigner：數據庫建模工具。

DBArtisan：圖形化數據庫管理工具，能夠支持多個數據庫產品，能夠在相同的界面運行非常簡捷方便的數據庫管理操作。

ProActive DBA：用於數據庫性能分析優化的，在Sybase年代是最好用的，能看清楚很多服務器端運行的一些細節，對於排查問題，提升性能非常有幫助。

OEM: 在Oracle上基於Java型的綜合性系統管理平臺，目前應用範圍較廣。

OMEGA MON：在主機平臺能實現對DB2和Z/OS的監控。

此外，農行還引入了IBM的QREP、IBM-CDC、Oracle GoldenGate用於異構數據庫之間的實時複製數據，特別是在兩地三中心和主機以及開放平臺的一些數據同步上。

在商業工具之外，還有一些與應用結合相對緊密的需求，是商業監控和管理工具滿足不了的，所以農行也自主開發了一些工具，比如MyAME、OCMS等。

1.4 關係數據庫經驗談

除了工具之外，我們再來談一下這十幾年來農行使用關係型數據庫的一些心得體會。

在OLTP領域首先不得不提的就是讓大家既愛又恨的索引，索引對於查詢很有幫助的，但是對於數據庫維護其實是不利的。因為索引越多，運行的時候需要維護索引的開銷就越大，所以，索引創建量要結合應用的實際需求來考慮。

複合索引建太多會影響數據維護，也會間接影響性能。根據農行的經驗，一般複合索引的字段數不應該超過5個。

跟索引有關係的統計信息，對數據庫來說也非常重要。如果統計信息不準確的話，索引可能不會被正確使用，肯定嚴重影響性能。要想讓它準確的話，就需要進行定期的更新，如採用定時機制由系統級來更新。最好的是由應用人員結合具體應用設計好什麼時候該更新，因為應用更清楚數據變化規律。

使用分區功能的時候，要注意選擇合理的分區方式和分區分段。要注意對於分區的數據處理，有可能導致全局索引失效。農行在使用Oracle的時候，曾出現過類似問題。有些情況下，如果更新局部索引的話，可能需要同步更新全局索引，不然會導致性能問題。

此外還有一個常用技術叫分表，分表其實不算是數據庫的計術，算是應用的設計方面的。我們經常在應用設計上按週期分表。比如可能一個星期一天一個表，在寫日誌的時候用不同的表，這樣的話有很多的好處，比如能夠快速進行應用切換和數據清理更安全和方便。

數據庫還提供了並行功能，這也是跟剛才提到的索引一樣，屬於讓人是既愛又恨的功能。一般不太敢在聯機的時候啟用並行技術，因為並行技術雖然能夠把所有的計算資源同時利用起來，但如果聯機運行，可能某一個查詢一下就因為並行，把資源耗光了。那並行功能應該用到什麼地方呢？並行功能在做批量、數據備份、索引以及數據導入的時候使用是最合適的。

數據庫產品還提供很多的診斷工具，有一些是字符型的，有一些是圖形的，我們經常用這些工具來檢查服務器的查詢計劃、執行時間、物理和邏輯IO、網絡通訊，等待時間等等。

這些都是我覺得可以藉此機會跟大家分享的我們近一二十年來使用數據庫的一些經驗。

當然除了數據庫本身產品設計能力以外，我們覺得還是應用本身的數據結構和模型的設計，其實是對性能影響最大的。

此外，在SQL方面，通過合理地設計，控制事務顆粒度大小，這對於總體性能以及合理控制應用的資源消耗是非常重要的。如果適當地採用組合SQL，也能夠避免一些數據庫服務器和客戶端的反覆交互，對性能是有利的。

在運維方面，農行制定了一些針對不同數據庫產品的標準配製規範，來指導維持數據庫運行環境。因為不同的人運維會有不同習慣、誤操作等問題，這需要通過規範來解決。還可以適當的把一些小的數據庫進行適度整合到一個大的數據庫服務器，避免數據運維的複雜度和工作量。

在OLAP領域，前面提到農行最開始使用的是Sybase IQ，後來使用GBASE。使用GBASE的過程也是農行與它共同成長的過程。GBASE是使用列存儲的數據庫，列存儲天生佔存儲空間比較節省，相應地減少了IO，進而對性能有所幫助。另一個，它採用MPP架構，可以對多節點進行並行處理，自然能夠大大提高性能。最開始農行使用的GBASE是無Master架構，最多支持64個節點。當數據量越來越大、節點數據越來越多時，無法滿足需求了，就升級成了當前的聯邦架構，能支持最多300個節點。

農行使用OLAP的經驗有4個，首先是維度模型。在分析型數據領域，大多數都使用維度模型。通過合理的設計，雖然增加了數據冗餘，但是提升了性能，這實際上是一種以空間換時間的方法。

第2個是數據分佈，對於大的表，通過合理的哈希分佈，合理地選擇哈希列以便使得所有的數據在不同的節點上均勻分佈。這樣的話能夠讓同一個查詢在多個節點同時跑起來。對於小的表格、維度表的話，我們會建一些複製表，存在不同的節點上。目的是減少一些跨節點的查詢從而提高性能。

第3個是值得一提的GBASE索引。GBASE本身是粗粒度的智能索引，所以如果不必要的話，一般是不需要自建索引的。

第4就是，GBASE不支持分區，所以，前面提到的分表，其實也就變得很有使用的必要了。

數據管理體系建設

2.1 企業級數據模型

農行的企業級數據模型分兩部分，其一是數據模型管理，其二是數據模型設計的方法。數據模型管理分為企業型、應用級兩個層次。

企業型分成三個層次。A是業務概念等級，B是業務概念的細化分類，C是對這些細分的業務概念按照業務功能需要進行抽象為實體，然後提取所需的屬性，尋找實體間的關係，形成關係圖，也就是我們常說的ER圖。

應用級的數據模型分成C’和D兩個層次，C’是對企業級邏輯數據模型在具體應用系統裡面的細化和落地，D是應用系統實際用到數據庫中的物理數據模型。

數據模型的定義規範，這裡的主題域對應企業級數據模型的A級，就是對業務概念按照不同的模型進行分類。

實體特徵對應C級邏輯數據模型，是對實體的不同組成部分進行分類。

屬性分類是對實體的屬性進行分類抽象。

數據類型應用規範是對具體的屬性分類進行進一步的描述，限制該屬性的取值範圍和精度等。

2.2 數據管理制度和規範

數據管理制度和規範共有三階，包括戰略層、規章制度層和技術標準層。

通過一體化的制度設計來規範系統研發與運維流程中的數據生成與消費，然後再配以專業的數據管理團隊和流程化的改進機制，來落實系統研發運維和生命週期的架構管控。同時我們建立了兩種管控機制，包括數據架構管控和數據質量管控。接下來就數據質量保障機制詳加說明。

2.3 數據質量保證機制

農行的數據分佈於消費領域和生產領域，一般數據在使用過程當中，就可能會發現它存在問題。發現數據問題後，我們會把這些問題整理形成相應的問題清單。這些清單由業務部門牽頭進行分析原因。分析完以後會形成數據質量報告和數據問題報告，這些報告會按季度來提交到行裡面，通過專題會來進行研究。

同時也會生成相應定期發佈的全行監測報告。然後形成相應的系統建設需求或者系統控制需求。最後要對這些數據問題進行整改，整改的過程中，通常會採用高層協調聯合治理方式，包括把它納入到考核績效掛鉤等加強力度。

最後，會把整改結果反饋到消費領域，然後在消費領域再建立相應的監測規則，以便發現可能在這個運行中產生的新的數據問題。新的問題發現以後，會在這個閉環裡面進行循環往復的修正，這就是農行的數據質量保證機制，通過這個機制能夠實現數據標準管理和元數據管理的一個不斷地持續改進。

2.4 數據管理技術平臺

為了落實前面對應的各項制度和規範，農行還建立了一整套的數據管理技術平臺，實際對應了DOTA、元數據管理系統、接口管理系統等一些系統。這些系統把數據模型、質量、元數據等這些管理流程，實現了線上化、管理提供了可視化視圖以便於使用。

2.5 OLTP數據管理實踐

農行從2008年開始，花了幾年的時間研究，形成了自己的11步OLTP的建模方法和建模流程。之後在幾年的時間結合BoEing數據模型進行反覆實踐並把它落地。

2016年開始，農行進一步總結形成了DOTA數據管理框架。從2017年開始，農行又選取了典型OLTP項目進行進一步的再實踐。就是經過了研究、實踐、總結、再實踐的過程，實踐了整個OLTP數據管理。

2.6 OLAP數據管理實踐

與OLTP有所不同，農行的OLAP最開始是獨立建設的。能夠滿足部分業務領域的需求。基於不同的標準，逐步形成了系統孤島，系統間的數據共享程度相對較低。

為了更好地把數據組織起來，我們通過內部統一的數據交換平臺，把來自不同源系統的數據統一彙總到新構建的操作數據區，再進行初步的清洗加工。然後在數據整合加工區進行進一步的整合加工，再把結果放到數據集市區以進行使用，形成了一個重新設計的共享多層次的OLAP系統。這套主題化、共享可複用、多層次的OLAP系統，可以直接提供給OLTP的應用來使用。

OLAP數據管理實踐也有類似前面OLTP的四步走的過程。

數據管理典型案例

3.1 核心系統下移成效

我們的核心繫統是基於DB2。隨著這幾年國家自主可控的要求，所以農行應用就需要離開主機。怎麼離開主機呢？往開放平臺下移。最先下移的是查詢交易，把歷史明細交易先移到開放平臺的Hadoop上去，同時建立開放平臺的一個核心總控。

查詢交易下移之後，還有批量。我們先利用前面提到的QREP，把它從DB2同步到Oracle，建立起相應的批量執行平臺，實現批量的下移。

下移之後空間就節省了很多，近幾年都沒有擴容，而且隨著下移幅度進一步加大，雖然總業務量還是節節攀升，而且越來越快，但是主機的消耗並沒有增加，甚至相對來說還有所下降。

3.2 銀行卡受理中心繫統

銀行卡受理中心屬於典型的高併發，響應速度要求和可用性要求也很高的應用系統，靠數據庫本身來實現的話很困難。

所以農行採用數據分庫、數據分表、短事務以及多種切換方式，經過比較複雜的應用級的設計，最終來滿足高可用系統的要求。

3.3 分佈式緩存雲

在互聯網金融業的高併發、高可用的業務場景下，農行基於內存數據庫，建立了自己的磐雲緩存平臺，這個平臺現在已經支持電子商務、快捷支付等8個應用系統，運行效果也很好。

3.3 大數據實踐

農行的大數據實踐是基於GBASE和Hadoop，結合自己設計的各種各樣的數據處理平臺、數據清洗平臺等等，建了自主可控的大數據體系。該項目還在2018年人民銀行科技發展獎中得到了一等獎。

3.4 兩地三中心建設

關於主機平臺上的兩地三中心：早些年農行使用存儲層技術來實現異地複製，但最近幾年，存儲層技術只是用來保留數據備份。農行採用了DB2 Qrep異步複製技術，取得了很好的效果。

關於異地數據傳輸、切換：異地數據傳輸、切換的時候，Qrep本身會有5分鐘的數據丟失。為了應對這個問題，農行通過網絡級報文進行數據補償，以避免數據丟失。

關於開放平臺：在開放平臺方面，農行對於沒有數據依賴的應用能夠支持A-A模式，有數據依賴的應用只能用A-Q和A-S。開放平臺的兩地三中心我們正在逐步的建設過程中。

3.5 快捷支付系統

快捷支付系統是非常重要的一個應用系統。節日、促銷活動（如春節和雙十一）時，支付寶、微信紅包等等都在快捷支付系統上面運行，這是壓力非常大的一個應用系統。

為了滿足需求，我們設計了高達24個RAC的龐大集群。

為了減少數據庫訪問壓力，農行通過把靜態數據及變化頻率低的數據緩存到Redis中，對客戶限額也進行緩存，應用對於限額的訪問和回寫都只訪問Redis，縮短交易耗時。

為進一步提升系統高可用性，農行計劃新增Redis同步功能，日終將月限額寫回至數據庫，實現限額數據持久化。當Redis出現故障時，可以通過訪問數據庫實現限額控制。

數據庫產品本身的支撐能力有限，包括Oracle，雖然它已經是業界公認的成熟產品，但是業務場景的需求依然很龐大，導致我們需要對應用進行復雜的設計。這是我們需要考慮引入分佈式數據庫產品的一個動機。

數據庫發展規劃

4.1 數據庫產品戰略

主流數據庫DB2和Oracle，以及Sybase會持續使用。

在分佈式數據上有引入考慮。

農行預計在一些小規模的應用會使用MySQL，分析型數據庫、歷史交易查詢、歷史交易數據和內存數據庫方面還沿用現有產品。

值得一提的是，我們正在選擇圖數據庫和文檔數據庫，並對這方面有一定的瞭解。

數據庫產品的選擇其實只是第一步，如何把這些產品結合業務需要進行合理的使用規劃，是一個持續時間更長、影響更為廣泛的過程。

4.2 批量數據分佈架構

農行通常會結合數據架構的設計選擇數據庫產品，農行內部主要有兩套數據架構，一個是批量數據分佈架構，它是滿足T+1以及時間更長的數據使用，另外一套是實時的數據架構。

實時的數據架構業內稱為大數據架構，農行已經完成大部分的架構（綠色部分），黃色部分目前還正在建設過程中。為了更好地促進大數據平臺的數據能夠快速的提供給需求方，農行還大力建設全流程的數據開發平臺，以方便各個應用系統的使用方快速地進行開發數據與消費使用。

4.3 實時數據分佈架構

農行實時數據的分佈架構，是通過數據複製工具、網絡旁路工具、日誌採集工具等工具把不同的元數據彙總到實時數據交換層。實時數據交換層可以直接提供最上面的應用系統使用，也可以提供給實時計算層，進行進一步的加工。加工完以後提供給待消費的應用系統使用。

農行目前建設的實時數據總線，主要是數據傳遞的高速通道，當需要對數據進行加工處理的時候，就會交給大數據平臺的流計算平臺進行加工，然後再由實時數據總線交給對應的應用系統來使用。

以上就是我今天想跟大家分享的內容。數據庫是可靠和穩定性要求的典範，農業銀行為廣大用戶提供銀行金融服務，同樣也要求高可靠、高一致，我們相信，穩健才能行遠，我的分享就是這些，謝謝！