數據庫

河北十一选五前三组最大遗漏:「完整版」農業銀行數據庫使用實踐和發展規劃!

廣告
廣告

微信掃一掃,分享到朋友圈

「完整版」農業銀行數據庫使用實踐和發展規劃!
0 0

摘要:中國農業銀行(以下簡稱:農行)在信息化系統建設過程中,先是把關系型數據庫作為聯機交易型數據庫使用,后來為滿足分析型應用需要開始使用分析型數據庫,近幾年來隨著應用場景細分,對基于 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 實時數據分布架構

農行實時數據的分布架構,是通過數據復制工具、網絡旁路工具、日志采集工具等工具把不同的元數據匯總到實時數據交換層。實時數據交換層可以直接提供最上面的應用系統使用,也可以提供給實時計算層,進行進一步的加工。加工完以后提供給待消費的應用系統使用。

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

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

老魚,企業級老編一枚,你若有故事,歡迎聯系!

IEEE態度轉變:解除對華為評審限制

上一篇

IBM 思想之夜:?場關于 AI 辯論,?名“AI 辯?”

下一篇

你也可能喜歡

「完整版」農業銀行數據庫使用實踐和發展規劃!

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃