平安科技資料庫總經理汪洋：開源資料庫在平安的應用實踐

汪洋 平安科技資料庫產品及儲存產品部總經理

很高興在DTCC十年的節點上，又回到北京，站在這個臺上跟大家分享，我一直對DTCC是有感情的，因為我本身是北京人，但是離開北京已經20多年了，每年藉著DTCC可以回家看看。

我叫汪洋，來自平安科技，在平安科技負責兩個團隊，儲存產品團隊和資料庫產品團隊，這兩個產品團隊全都跟資料有關。平安科技是平安集團的全資子公司，它有三個職能，一個集團的高科技核心，二是創新孵化器，這兩年也開始將技術和服務對外輸出。

我在平安科技做了8年，今天我講的是平安在開源資料庫方面的應用實踐，對於很多金融公司來講，受到一行兩會的監管，在採用開源資料庫的時候，基本保持觀望的態度；而任何一家組織架構的轉型，包括引入一些新的技術，都是有風險的，尤其是對於金融公司，大家都知道，平安集團就是一家綜合金融公司，它覆蓋了金融產品的方方面面。

那麼為什麼平安在這種情況下開始引入架構的轉型，開始引入一些開源資料庫，並且在內部推廣？希望我今天的分享能給金融同業或其他公司帶來一些借鑑。

一、平安為什麼要使用開源資料庫？

1.微服務架構的崛起

在2013-2014年的時候，很多像平安這樣的傳統公司都在探索怎麼樣進行網際網路轉型，那時Gartner提出雙模式發展，雙模式發展就是為了適應傳統企業向網際網路轉型的需要，一方面企業對於傳統的應用系統仍然需要三高，即高可用高可靠高效能；另一方面要快速響應，在自己的領域內能夠向網際網路轉型，這就要求敏捷開發，敏捷交付。這個時候過去的單體架構帶來很多問題：

• 開發週期很長，上線時間長，推向市場時間變很長

• 變更風險大，因為單體架構，牽一髮而動全身

• 很難進行擴容，特別是根據不同的元件進行擴容

而微服務架構的崛起，能夠把一個單體架構拆成各個模組，針對模組進行擴容，因為每個模組有不同的負載特性，模組之間是松偶合的，微服務架構的崛起就帶來它底層的持久化儲存的需要。

2.混合持久化解決不同資料儲存需求

微服務架構帶來了多型性的儲存。為什麼會有多型性，因為我們的資料不再向以前一樣：以前的我們追求高一致性，都是企業化資料；但是在很多網際網路場景下我們做秒殺時並不需要那麼高的一致性，它的資料格式也是不一樣的，因此也出現了不同的儲存引擎，隨著微服務的發展，可根據他自己的特性、資料格式、採取不同的資料庫。

3.One for all時代已經過去

現在不是One for all，而是Best fit

每個業務場景都有特定的資料庫。

所以我說技術沒有對錯，沒有最好，只有適合業務場景的技術。

4.傳統商業資料庫架構過於沉重

以Oracle為例，大約二十年前我學習的時候只有幾本書，現在的書可能一個房間都裝不下，安裝Oracle軟體也是，都很大，但是裝MySQL，都是輕量的，只有幾十或幾百兆，部署也相對簡單，這有利於快速試錯，快速把市場需求轉換為產品原型，快速推向市場。總之技術都是服務於業務。

還有我們是被開發人員倒逼，他們為了滿足業務需求使用開源資料庫，如果運維方面跟不上的話，運維會成為背鍋俠，因為最終生產出問題是落在了運維身上。

二、使用開源資料庫，需要投入哪些成本

從整體看，開源資料庫並不是免費的，使用開源資料庫是一個循序漸進過程，在使用開源資料庫時不能犧牲系統穩定性，因此需要許多其他方面的成本投入。

學習成本：學習成本是針對開發和運維人員的，因為資料庫對開發人員從來不是一個黑盒子，當資料庫體量變大時，肯定會遇到各種各樣的問題，所以開發和運維都存在一個學習週期。

遷移成本：雖然世面上很多遷移工具可以節省開發人員的投入，實際上這些工具沒有盡善盡美，特別是在程式碼遷移上，雖然轉換過來功能可行，但你會發現程式碼幾乎是不可讀的。

所以寧願把業務邏輯重構，重新看一遍，再用新資料庫語法重新寫一遍，在遷移過程中，資料遷移佔小，程式碼遷移才是大頭。

維護成本：需要對資料庫有很深的瞭解，才能在發生問題時快速定位，解決問題，事件響應機制、監控指標等都是維護成本。

時間成本：掌握開源技術也需要一個過程，充分應用現有開發和運維技術，比如我當初為什麼會選PostgreSQL，PostgreSQL對現有一直在Oracle系統上的運維和開發團隊來說，學習曲線是相對來說比較短，能夠快速進行遷移。

增加的運營成本及風險：增加運維成本的風險，人員招聘、人員培訓都有一個週期，資料庫團隊、產品、運維機制都需要在生產環境中不斷的錘鍊，才能變得不斷完善、成熟。

三、如何選擇合適的開源資料庫？

業務場景的需求：每個資料庫都是服務一個業務場景的需求，平安集團的好處是業務場景非常豐富：產險、壽險、養老險、壹錢包、健康網際網路、智慧城市等，我們可以在業務場景中充分的驗證這些開源資料庫，哪些資料庫適用於哪些業務場景，在場景中不斷的打磨運維和開發團隊。

有適合的替代方案：你在使用的資料庫有沒有合適的替代方案，比如我想從Oracle遷移出來，選擇什麼資料庫，在四五年前，我選擇的是PostgreSQL，現在證明當時的決定是對的，你可以看到AWS有很多RDS服務，所有遷移的方案，都是從Oracle遷移到PostgreSQL,也就是說PostgreSQL跟Oracle是相近的，他們間的遷移成本和學習成本都相對是較少的。

我們現有開發人員的技能：過往有過Oracle經驗的開發比較容易遷移到PostgreSQL。

現有資料庫的負載模式：根據每個系統負載型別可以選擇不同的開源資料庫。

開源社群活躍度：如果你選擇一個開源資料庫活躍度不高，你心裡沒底，你不知道它能不能發展下去，我們選擇開源資料庫希望儘可能的能用很長時間。

市場份額及行業知名度：資料庫處於出生期、成長期、成熟期、老年期的哪一個區域，需要了解它的生命週期，瞭解它在國外國內的一些應用情況來增加使用信心。

開發語言：資料庫本身的開發語言，能否匹配到現在團隊成員所具備的技能。運維需要快速定位問題發生在哪一步，研發人員需要對開源資料庫的程式碼進行改造，讓他更適配應用場景，所以開發語言也是考慮因素。

資料庫型別：我們在佈局整個資料庫組合時，要考慮在哪些資料庫型別上進行佈局，有很多資料庫型別，但不是每個資料庫型別都需要，所以需要選擇。

資料庫技術的發展趨勢：希望所選擇的資料庫是未來技術發展的趨勢。

不要使用太多的開源產品：如果資料庫種類太多也會增加運維成本，因為每一個資料庫都需要學習成本，在滿足業務場景的需求下選擇儘可能少的資料庫產品，儘量做到標準化。

四、引入和應用開源資料庫的策略是什麼？

現有的系統是已經執行生產的系統，它對執行的可用性有較高的要求，不能因為引入開源資料庫就對系統效能造成影響。應該按照重要性進行分類，平安根據資料庫按重要性分為3類。

不同業務線開放程度不一樣，平安一些傳統的大公司，如壽險、產險、銀行，他們相對來說比較謹慎；但是一些網際網路公司，如陸金所、壹錢包、健康網際網路，他們比較積極進取，願意進行新技術的嘗試，當然要確保不會對業務造成大的影響，完善後再推廣到傳統公司。

資料庫產品團隊有一百多人，不太現實讓每個人都去掌握多種資料庫，特別在剛開始的時候，我會讓一兩個人去負責某個資料庫產品，以點帶面去對其他開發人員進行培訓。其他的比如制定資料庫架構、運營和開發的指南手冊；對運營、開發以及DBA提供培訓。

另外，持續進行架構最佳化；積累開發和運營經驗；學習原始碼；建立自己的研發團隊；加入開源社群，這些都是在引入時需要有一定的計劃。

以下是平安各業務使用的不同型別開源資料庫的選型策略。

五、平安的開源資料庫架構如何？

六、三個開源資料庫在平安的應用案例

第一個案例是我們今年在1月8號 產險“財神節”活動使用TiDB，25個節點的叢集，有主從兩套架構，包括TiDB、TiKV，總共25個節點，主從之間透過BinLog做到非同步同步。

業務高峰期資料，如每秒10000+DML、平均每秒1000單、紅包秒殺TPS3000等。單從TPS來看，資料不是很大，但對於每個業務場景，要看相對值而不是絕對值，因為每一個Transaction的複雜度是不同的，對於產險，一個Transaction中有多達上百個SQL語句。

其實這個產品當時搭建了25個節點，我們的標準規格是NVMe，一時很難找到這麼多的NVMe機器，因此採用SSD，也是很好的滿足了產險秒殺活動的需要。

第二個案例是壽險客戶管理系統基於我們自研的DRDS。因為客戶資訊資料非常重要，所以我們是把寫的負載仍然放在Oracle，然後是實現讀寫分離，讀是用另外一個資料庫叢集、另外一個資源來實現，並且是在這個讀上面來使用單獨的架構，這是35個節點的叢集，15個節點是記錄客戶資訊的變化，20個節點是記錄保單資訊的。透過客戶服務和保單服務，來實現兩個DRDS的叢集，當客戶查詢的時候，就是去相應的叢集上訪問查詢。

InfluxDB是時序資料庫中的佼佼者，時序資料庫發展前景也是非常不錯的，特別是在IoT時代，不停有大量的資料產生，對這些資料儲存需要能支援高併發的寫入，它具有非常強的優勢；另外根據時間序列對資料進行分析聚合，在實際場景中也得到廣泛的應用。

我們自己的資料庫產品團隊，是將它用在了監控系統上，去採集很多資料，我們現在有更多的監控物件，如cpu、memory、nginx、I/O、各種資料庫等。InfluxDB的寫入效能每秒可達到35w，這在關係型資料庫裡面，單機的、在有index的情況下，很難想象能達到每秒35w。還有併發查詢與PostgreSQL相比的資料，時序資料庫還是有比較明顯的優勢。

七、發展路徑

引入眾多開源資料庫之後，我們在平安雲上，透過Cloud Database的方式，對外提供服務。一個方向是我們現在正在做雲資料庫容器化的部署，以期達到更高密度的部署、更強的自愈能力、更容易擴充套件的價值。

另一個方向是更多自研資料庫產品，基於這些資料庫產品開發出自主可控的資料庫，比如基於分散式KV資料庫開發出圖資料庫產品。

最後一個就是剛剛提到的Cloud Database，雲提供商是有天然的做AIOps的優勢，因為做AI最重要的就是資料，資料量要大，而且資料樣本要非常豐富，小的公司要做AIOps是不太可能的，所以我們可以基於平安雲來收集這些資料庫的運營資訊，結合人工智慧和機器學習，進行更精細的異常檢測、故障預測，能夠進行更精細化的資源管理，來不斷完善我們的產品。

以上，就是我今天關於平安在開源資料庫方面的應用實踐的一些分享，謝謝大家！