講師介紹

汪洋，平安科技資料庫技術部總監，從事Oracle相關開發運維工作20年。加入平安後，負責資料庫技術引入，資料庫產品選型，資料庫架構設計，資料庫規範制定，開發、測試、生產環境運維等工作。近年，對開源資料庫技術以及DBaaS產生濃厚興趣，一直致力於相關的研究和引入工作。

大家好，我是來自平安科技的汪洋，2011年加入平安科技之後開始從事雲端計算，還有一些開源資料庫的研究和推廣。我這個部門是資料庫部門，有120人，其中80人是DBA，在國內公司這個DBA團隊是非常具有規模的，但我們人手還是不夠，因為我們服務的是整個平安科技，總共8000人的開發團隊。

今天的主題為資料資產峰會，而平安集團整個從1988年13人增加到現在的150萬人的一個公司，其中保險代理人有110萬，積累了大量的資料，而且都是高質量的資料。我們說平安集團所擁有的這些資料是非常高質量的，那怎麼把這些資料轉化為價值？現在經常聽到的一個詞都是賦能，怎麼樣能夠讓資料賦能這個企業，馬雲提出了一切資料業務化，一切業務資料化，因此怎樣讓這些資料促進業務的發展，這是我們要解決的問題。

資料是企業的重要資產，是企業的生命線，是企業能夠可持續發展生存下去一個重要的元素。資料庫作為重要的組成部分，如何讓資料進行安全、高效的儲存，並且能夠高效地訪問、高效地分析，資料是死的，怎麼快速產生出價值，這也是我們要解決的問題，所以今天我就來談一談平安資料庫運維的一些道法術。

我從2011年進入平安科技，在這之前運維的資料庫是比較單一的，都是Oracle資料庫，從2013年開始引入一些開源資料庫，到現在差不多運營的資料庫種類有八九種，包括剛才提到了平安的各種業務場景，我總有一個組合可以適用你，可以讓你在這些場景基於各種資料庫進行一些開發工作。

那麼為什麼是從2013年開始改變的？一方面是由於外面的大環境，大家都知道2013年開始了去IOE運動，很多的企業都在考慮或者討論怎麼樣去IBM、去EMC或者去Oracle，另外一方面銀監會也發了文，要求企業一定要有一定的自主可控的能力。

還有內因，在這之前我們確實沒有太多的選擇，只有一些商業的資料庫，Oracle就自然而然成為預設的一個數據庫產品選擇。但從2013年隨著開源軟體、網際網路電商的發展，引出了一些新的資料庫引擎，另外我們自己也感受到一些壓力，整個集團的業務種類非常多，而且我們要積極地向網際網路轉型，再加上出現了很多新的需求，而這些需求如果都用Oracle在某些場景下是不太適合的，有的時候因為互動太慢了，有的時候是因為太過於重，造成它的成本過高，基於這兩方面的原因我們開始引入了一些資料庫。

一、道——何謂運維

1、從開發設計的角度

我們為什麼要引入這些資料庫，第一個就是快速的響應速度，在移動網際網路快速發展下，天下武功唯快不破，一切是看到這個市場的機會，看到有這個需求，我們一定要在短時間之內快速地實現它。但如果用傳統的方式，申請資源分配資源進行分析，一整套下來的流程是非常長的。

從開發人員的角度，希望他們能從業務部門提出的需求去快速地進行開發，並且推出市場，能夠搶佔市場先機，快速的市場反應速度是必要的。傳統的Oracle有時很難滿足，從我們過去的經驗來看，那時候也沒有云計算。剛才我說的整個Oracle要分配資源，除了資料庫部門，還要向基礎架構部門去申請主機的資源、儲存的資源，只是Oracle的環境要搭兩個星期，還要再申請一些其他環境，例如開發、測試，再等到生產上線，可能時效非常慢，無法滿足快速上線的需求，所以開發同事會抱怨我們的交付太慢。

第二個是便捷的元件交付，無論是Oracle也好，還是其它資料庫也好，我們都希望能夠自動化，儘量地減少流程中的冗餘，儘量減少溝通的成本，能夠做到快捷的元件交付。

第三個是靈活的微服務模式發展，它是能快速地將市場需求轉化為價值的一個過程，原來的敏捷開發只是縮短一個系統開發過程中的效率，但並沒有提升運維方面的效率。不知道大家了不瞭解微服務，服務之間把大的應用程式分開很多服務，獨立在不同的程序裡面，並且可以進行獨立的部署。一個大的應用程式不用再像以前的單體架構進行詳細的測試，而且關聯的元件和部門人員非常多，模組之間依賴關係也錯綜複雜。在微服務模式搭出來一個應用，當市場需求變化的時候我可以去重構，可以把這些積木拆下來再滿足別的需求。可以獨立的部署，微服務對改變可以有效進行故障隔離，對一個服務的改變不會影響其它的服務，不像單體結構牽一髮而動全身，要進行大量的測試和風險分析才能上線，這就導致了對市場的反應速度下降。所以微服務的興起也促進我們要去選擇不同的技術，它的邊界是非常清晰的。

所謂的物理邊界就是現在容器技術，相對於資料庫來說每一個微服務都可以有它自己的資料庫，而且有它自己的資料庫產品。一個微服務的團隊如果開發人員技術棧是它所熟悉的資料庫產品，就可以快速使用並且交付產品。反之，如果我的一個企業只有單一的一個技術架構，像以前傳統的Oracle，那這樣對於開發人員的學習成本也是非常高的，這也造就了對市場響應速度的下降。上述所有的一切都是為了更快的能夠將需求轉化為最大值，並且是推向市場。

第四，低廉的試錯成本，這也是我們引入開源資料庫的原因，Oracle的試錯成本比較高，你的學習成本非常高，對於一個從來沒有接觸過資料庫的人員來說，Oracle資料庫的學習成本確實非常高。

資料庫從來都不是一個黑匣子，這在很多開發人員腦子裡有一個誤解，把資料庫當成一個黑匣子，寫任何的SQL都可以執行在任何的資料庫上。如果大家做過Oracle的話，或者是做過效能優化的話，你便知道，雖然大家都能達到同樣的功能效果，但針對哪那種資料庫應該怎麼寫，你一定要了解資料庫內容的一些機制，才能夠發揮極致的效能。

為什麼說試錯成本，因為很多情況下市場需求有，我要開發滿足這個需求的產品，但是不確定這個產品真正的能在市場上有多大的需求量，或者我的產品在推出市場能不能成功，騰訊也是快速地試錯。或者對於需求不是很明確的情況，就有很多系統剛上線不久之後就會涉及到下線的問題，說明這個產品推向市場是沒有太大的盈利能力，是沒有很好的商業模式，必須要快速地斬斷，快速作出一個決策。Oracle的下線成本是非常高的，風險也比較高，大家知道Oracle用的都是一些共享的主機和儲存，你下線要變更，因為都是共享的，你會影響到其它正在執行的一些系統。新建環境風險相對較低，但是下線系統的時候涉及到人為的誤操作風險是非常大的，還包括需要進行IO多鏈路掃描，下線之前分配的Oracle資料庫的那些磁碟，這個也是有一定風險的。Oracle在很多情況下是不滿足這種快速試錯的。

第五，多元的資料儲存管理，一個數據庫可以支援多種資料格式。在提出這個Multimodel之前，Oracle只能支援一些關係型的資料，但是隨著大資料的發展，隨著物聯網的推出，其實有很多資料是不太適合放在Oracle裡面的，而且成本也太高，為什麼這麼說呢？

很多資料並不在乎非常強的一致性，可以說在金融行業裡面也有很多資料其實並不要求那麼強的一致性，但是在關係型資料庫裡面就要求你要滿足一些要求，最初的設計是要滿足這種要求，而且你去加一個欄位或者減一個欄位都會帶來一些成本以及生產變更，都會比較麻煩，像現在NoSQL沒有一個限定模式的概念，你在設計的時候是可以允許你不用一次到位，可以隨著需求變化而變化。但基本上你在設計的時候還是要思考一下你的Data Model是如何去設計的，還要去仔細考慮，只不過不像關係型資料庫這種強制性要求你這麼做。那麼針對這種多元的資料管理，以及像對地理位置資訊的查詢，使用Oracle有時候是比較難以實現的。

這是從開發的角度來說明為什麼要使用多種資料庫產品。

2、從運營管理的角度

那麼，從運維管理角度，在引入這些開源資料庫或者多種資料庫的情況下會有哪些問題，又會帶來什麼好處呢？

第一個是標準的元件交付，對於運維來說，開發人員越靈活，風險則越高，這也就是說DevOps推出的一個原因，運維人員希望一個變更都不要做，你不做變更系統就不會出問題，只要有變化，無論是人為還是系統的效能，那可能是出現問題的一些先兆。所以從運維的角度來說，我們希望是標準化、規範化和和統一化，我們以前運維Oracle這一個領域時，因為這個規範是比較統一的，管理起來要比現在簡單很多。

第二，規範的程式碼設計，資料庫不能被當成一個黑匣子，每個資料庫都應有自己的命名規範、架構規範、架構規範、資訊保安規範，當你有多個數據庫的時候，你的程式碼設計肯定是多種多樣的，這也帶來了一些運維方面的困難。如果我引入了多個數據庫，對於每種資料庫解決思路或者解決方法肯定是不一樣的。如何規範程式碼設計，制定一個開發規範也是不一樣的。如果是不一樣的話，當出現問題的時候就需要有多種技能才能夠去解決。

第三，統一的管控流程，從運維的角度來說希望能夠引入多種資料庫的情況下也能夠有統一的管控流程，只有達到了剛才說的標準化、歸範化，才能保證系統的穩定性。

第四，持續的服務可用，金融行業對這個要求非常高。我不知道大家有沒有銀行的朋友，如果系統15分鐘不可用，要報當地的銀監局，如果再超過要報銀監會，銀行行業對系統的可用性要求是非常高的，我們是希望引入多種資料庫的同時，不能犧牲系統的效能，不能犧牲系統的可用性。

第五，合理的成本投入，大家往往認為一個開源資料庫的成本是免費的，而認為Oracle是很昂貴的，因為它是商業化的資料庫。但是從我來看，不能簡單地看這個問題，一個合理的成本投入，不光要考慮一個數據庫的License成本。開源資料庫軟體並不是免費的軟體。評估整體成本，它不光包括了License成本，在你用它時是不是零成本投入也需要考慮到。你需要去學習它，任何一個數據庫你去用的時候，市場上有沒有這樣技能的開發人員，有沒有具備這些運維技能的人員，你都要考慮。在你自身已有的團隊情況下，你還要考慮大家多年運維Oracle的情況下，轉移到運維別的資料庫，這個轉移的成本有多高，這些都是一個成本的投入，所以這個投入都是整體的，是TCO（Total Cost of Ownership），包括人員的學習成本。

其實開發和運維之間，什麼叫運維？就是在剛才我說的靈活和穩定、對立和統一之間找到一個平衡點，我希望能夠引入一些開源資料庫，能夠支援業務的快速發展，能夠將產品更快的推出市場，但是同時我希望不能犧牲系統的可用性和效能，在這之間找到一個平衡點。

我們摸索了這麼多年，現在打的是組合拳，在這個組合拳裡面我實現了一個相對統一、平衡，基本上涵蓋所有這些業務的一些業務需求，能夠滿足開發人員需求，也能夠滿足剛才我提到的運維方面對於穩定性和效能還有可靠性的需求。

二、法——何為運維

既然決定了這個方向，我要引入多種資料庫，要引入開源資料庫，要去提升我們互動速度，加快產品的上市時間，那麼應該怎麼搶佔市場先機？

第一個是需求場景，要看這麼多業務有哪些方面的需求，這些需求到底適合用什麼資料庫來實現。其實在我去引入之前有些開發人員已經在使用某個資料庫產品了（例如MongoDB開發）。

有兩方面因素，第一他們覺得MongoDB沒有一個固定的模式，相對來說比較簡單。第二個它比較輕量，也符合微服務模式。這就變成運維部門很被動，如果我主動出擊，有一系列的組合，你有這樣的需求馬上提供給你這樣的產品，那麼這樣的產品也能夠滿足我的運維要求。

而如果讓開發來迫使我們，這相對來說比較被動，開發人員經常考慮功能性的需求，而很少考慮非功能性的需求，像可靠性、可用性，這樣變得比較被動。所以後面我主動去看有哪樣的一些需求，比如說分庫分表的需求，高效能的需求，而基於磁碟的資料庫又很難在極大的併發負載下滿足系統的多方面需求。這樣通過一步步的挖掘需求去看到底需要什麼樣種類的一些資料庫。

還有就是資料庫的SLA，它的服務承諾是怎麼樣的，我們根據SLA進行一些資料庫產品的選型。另外還要市場的成熟度，社群活躍程度，迭代快不快，如果一個開源軟體兩年都不迭代，這個活躍度很低。生態圈成不成熟，是否有很多的外掛，有很大的開發者生態，也有很多人在使用，這些都是要考慮的，包括它的排名，到底有多少人在談論，在網站上被引用的頻度，在某種程度上表示大家對它的關注度和熱度。還有人員的技能，市場上到底有多少開發人員和運維人員具備這個技能，如果我去轉容不容易，成本投入要多大，這些都是要考慮的，而最終我們決定引入PostgreSQL資料庫作為Oracle資料庫的一個替代品。

上面我列出來一些平安科技主要使用的資料庫，我們稱之為七劍下天山。對於資料庫來說，不能從一個點評價效能好不好，而是要從整體來評價，它的功能的豐富度，它的可靠性、可用性，包括髮生問題時候效能資料的完整性，可診斷性，備份和恢復、高可用等等整體上來考慮，直到現在我都認為Oracle現在仍然是最好的資料庫。我們也把很多Oracle中的理念移植到開源資料庫上。但是並不是所有的場景都適合用Oracle，所以現在有一個概念叫用最合適的資料庫適用最合適的場景。現在不是Best of Breed的時代，而是Best fit的時代。但最後歸結為一點，就是如何以最快速度將市場需求轉化為價值，並且交付價值。

PostgreSQL、MySQL、SQL Server、Timesten、Redis，我們都劃分了一下，在什麼場景下用什麼資料庫。傳統型的，特別涉及到資金交易的核心繫統我們還是用Oracle，不光是因為它穩定，效能好，可用性，還因為它出了問題之後我可以快速地獲取詳細的診斷資料，快速地分析、定位、解決問題，滿足監控要求的時效性。

非關係型資料庫每類裡面都有，文件型資料使用MongoDB，圖資料庫現在隨著物聯網、萬物互聯的發展都需要用到這些關係，我們現在開始調研一些圖資料庫。現在對監控資料、對物聯網資料的時間粒度要求越來越細，所以有很多時序資料需要去處理，而且資料量也非常大，如何能夠做到實時的處理、實時的響應、實時的展現，我們也在考慮時序資料庫的使用。

有了道和法，最後就是怎麼去實現的問題。

三、術——運維為何

我們從2012年開始做標準的流程，早期是手工的交付，就是先把這個流程跑通，那時是兩個星期搭建一個Oracle資料庫的時代。2013年時把這個運維變成了自動化，2015年進行私有云的搭建，不光實現了自動化，還實現了資源的自動分配、自動管理，使用者可以自助申請各種資料庫。今年開始對外提供平安金融雲，公有云服務，裡面也包含了資料庫雲DBPaaS。

這是我們金融雲的一個架構，也是基於我們從2015年至今約兩年建設運維私有云經驗發展出來的DBPaaS公有云。私有云和公有云具體實施是不一樣的，這裡只是一個技術架構的概念圖，基本上是一樣的。

這是我們PostgreSQL的架構圖，最初使用的是本地磁碟，本地磁碟會帶來一些問題。在現實中，主機和儲存故障來看，大部分是主機故障，後來我們改成了共享磁碟，解決了很多問題，包括產品的定價問題、資源使用率的問題，我不再擔心儲存的使用率跟主機匹配不一樣的情況。這個共享儲存有時候大家會把共享儲存跟傳統的儲存混為一談，其實共享儲存也可以是分散式是儲存，也可以是SDS軟體定義儲存，只要能夠滿足資料庫的效能要求就好。在使用共享儲存的架構之後，主機發生問題時，我可以把DB切換到備機，資料是零丟失的，滿足金融的監管要求。

Redis我們有兩種架構，單一例項和分庫分表。分庫分表我們使用Redis Cluster，是Redis 3.0以後才有的這個特性，在平安科技，主要適用於記憶體訪問資料量非常大的場景。

還有MongoDB架構圖，它本身的架構設計內建了分庫分表。在應用場景上，MongoDB很方便地用於處理一些地理位置資訊。

就資料庫管理規模來看，我們的Redis有3500個，MySQL有800個，PG有1093，MongoDB 789個，而且還在快速增長，也是得益於平安集團業務的高速發展。

我們無論是私有云還有金融雲上面，都希望把這麼多年在金融資料庫上面的經驗進行輸出，分享給大家。對於PostgreSQL資料庫，在去年大規模推廣和使用的基礎上，今年我們更進一步，對於原始碼進行了修改，做到了問題SQL語句事前的預防，可以在提交到PG執行對生產造成危害之前，就進行警告或者攔截。我們在PG裡面可以對它進行稽核，比如如果發現WHERE條件是1等於1，或者乾脆沒有WHERE條件的話我們可以進行攔截，或者是傳送警告。這也是我們一直在踐行的，我們希望能夠對開源資料庫進行貢獻，能夠反饋給社群，能夠促進整個開源社群共同發展。

還有一些其他的經驗，去年我參加廣州的全球敏捷運維峰會的時候，講到平安科技資料庫升級的流程是非常完善的。我們前年完成了全球最大的，100多TB的Oracle 9i OLTP核心資料庫的升級。這麼多年的運維經驗希望能夠把它輸出出來。還包括資訊保安基線、健康檢查、包括業務舉行活動時候去做的一些容量的規劃，種種這些都是我們這麼多年積累的一些經驗，希望能夠把它進行輸出。

資料庫的運維，這是一條無止境的路，隨著儲存技術的發展，計算技術的發展，各方面技術都在飛速的發展。企業的資料庫組合並不是一成不變的，也在根據市場的變化不斷地進行調整，包括也看一些圖資料庫，儘量地能夠在飛速發展的市場環境當中能夠快速滿足集團各個專業子公司發展需要，能夠做到金融場景的全覆蓋。包括在金融雲上面，我們也會根據客戶的需求結合現在的發展趨勢不斷調整我們的技術組合，讓這個技術組合具有不斷持續的生命力。

這就是我今天的演講，謝謝大家。

文章來自微信公眾號：DBAplus社群