OB君：螞蟻金服資深技術專家虞舜將在本文為大家分享螞蟻金服數據庫所面對的業務挑戰，解讀OceanBase的自治數據庫體系，解密OceanBase在天貓雙11大促期間的穩定性解決方案，探索OceanBase在螞蟻金服的智能運維實踐之路。本文整理自OceanBase TechTalk技術沙龍杭州站上虞舜的演講視頻以及PPT。

前言

OceanBase是一款通用的分布式關系數據庫，有很多獨特的特點。比如數據庫的多租戶、高可用、極致彈性伸縮能力。如果把OceanBase當作單庫使用，就沒有辦法把OceanBase的分布式能力發揮到極致。

近幾年來，傳統數據庫的基礎領域方面突破越來越少，而在人工智能和機器學習所驅動的自治數據庫方面卻屢屢獲得重大進展。在今年的數據庫頂級峰會SIGMOD中，有多篇優秀論文都與自治數據庫領域關系密切，我們能越來越清晰地感受到，人工智能與數據庫的結合已經成為了大勢所趨。其實，不僅學術界如此，越來越多的商業數據庫巨頭也已經將重心轉移到了自治化數據庫之上。

關于OceanBase

OceanBase為何被稱為金融級數據庫呢？在螞蟻，OceanBase部署在非常廉價并且經常發生故障的服務器上，而正是在這些不可靠的服務器上，建立了支撐支付寶、網商銀行以及整個螞蟻金服如此巨大業務量的OceanBase數據庫，在出現機器宕機時能夠在極短時間內恢復。2017年的天貓雙11當天，螞蟻每秒鐘需要處理大約25.6萬筆交易支付以及4200萬次SQL請求。

OceanBase Milestone

那么首先我們一起來回顧一下OceanBase這幾年的重要里程碑事件：2010年6月，OceanBase正式立項；2011年，淘寶收藏夾上線；2014年，支付寶交易系統上線；2016年，支付寶賬務系統上線；2017年，OceanBase開始商業銀行推廣，至今已在多家商業銀行上線運行。

OceanBase至今已成功應用于支付寶全部核心業務：交易、支付、會員和賬務等系統，網商銀行和印度Paytm以及阿里巴巴淘寶收藏夾、P4P廣告報表等業務。從2017年開始，OceanBase開始服務外部客戶，包括南京銀行、浙商銀行、人保健康險平臺等。

目前，OceanBase技術團隊正在如上圖所示的幾個方向上開展研究工作，包括HTAP、全局快照、兼容性等等。本文分享的主題則是其中一個重要的研究方向——智能化數據庫。

螞蟻數據庫的挑戰和應對之道

對于螞蟻金服而言，數據庫方面的挑戰可以主要分為5個方面：高并發交易、低成本交易、精細化高可用、國際化以及高效的研發運維支撐。

智能驅動的Self-Driving Database

為了應對上述數據庫方面的挑戰，螞蟻需要更加智能的自治數據庫來提升整體的效率和穩定性。在螞蟻我們做了幾個方面的實踐，比如數據庫配置的自調優（Self/Auto Tuning），遇到故障時候的自愈（Self/Auto Healing）以及面對容量、利用率以及成本問題的自伸縮（Self/Auto Scaling）。其實，智能驅動的自治數據庫就像是自動駕駛汽車一樣，目標是希望讓大部分的事情都由數據庫自己完成，讓DBA、SRE、業務研發能夠更加專注地做好業務。

SIGMOD以及業界趨勢

自治數據庫近年來無論是在學術界還是工業界都是比較火的，學術界的SIGMOD 2018里的兩篇論文：“Query-based Workload Forecasting for Self-Driving Database Management Systems”和“P-Store: An Elastic Database System with Predictive Provisioning”和螞蟻目前正在做的工作比較接近。此外，在工業界， Oracle將Autonomous Database作為一個重要的方向，提升Oracle在數據庫市場上的競爭力。

智能化數據庫系統的架構

如上圖，這是螞蟻定義的智能化數據庫系統的架構，包括感知、決策、執行等模塊，其實，簡單而言它是一個典型的控制系統。站在數據庫的角度來看，整個系統的目標就是讓Response Time最小、吞吐量最高、RT時間最小。

智能化數據庫系統的輸入可能是負載模型或者系統事件，這兩者就構成了系統所需要感知的元素。舉例而言，比如OceanBase系統感知到了一次SSD磁盤IO抖動，因為螞蟻數據庫系統中有海量的SSD，這樣的抖動每天都會發生，有些抖動只發生一次就會恢復，而另外一些抖動可能因為SSD固件Bug、物理故障等因素無法自動恢復，可能會Hung死系統。智能化的數據庫系統首先將會通過數據和算法感知到IO問題，然后將信息同步給決策系統——數據庫大腦，數據庫大腦會決策這樣的問題出現之后應該如何解決。例如，在螞蟻，當系統感知到業務異常時，大腦會快速的根據數據和算法判斷異常的根因以及可行的方案，當識別到SSD有問題時就會做出剔除SSD或者OceanBase Server的決策，實現Response Time的快速恢復。

在上圖所示的智能化數據庫系統架構設計中，系統層面使用了很多的機器學習算法，OceanBase層面也做了大量的能力擴展和防護措施，比如上面談到的SSD或Server的剔除能力，OceanBase在執行操作之前會進行leader切換以及副本完整性檢測，避免影響業務。智能數據庫系統的優化策略與人的決策過程非常相似，比如DBA優化SQL時會先判斷哪里存在問題，這就完成了第一步“感知”，之后再進行第二步“決策”，根據經驗判斷應該執行的操作，第三步，是執行這個操作從而達到優化系統或者恢復故障的目的。

智能化數據庫系統的三大組件

智能化基石

要建立上述的智能數據庫系統，需要堅實、靈活的基礎能力支撐，包括一下幾個方面：

第一點是靈活可擴展、可定制的OceanBase，例如，開放數據庫內核的能力，使得平臺或者工具可以任意干預SQL的計劃和執行策略，任意切換主節點并修改資源配置，通過精心設計和實現這些內核能力，避免決策錯誤時對系統產生不良的影響。

第二點是自動化、穩定并且具備強大數據處理能力的平臺。舉例而言，如果數據庫通過對歷史數據的分析和計算，確定在未來三天內或三個月內將會出現容量不足的情況，那么就可以決策自動進行容量，而這一點建立在資源“池”化的基礎上比如容器，如果數據庫建立在物理機上，這就使得擴容變得異常困難。

在螞蟻，數據庫建立在容器之上，需要時調用API直接擴容容器即可，不需要時調用API歸還容器即可，OceanBase自動對數據進行遷移和均衡，整個過程業務系統無感知，這樣的容量伸縮方式也已經經歷了多次雙11的實戰檢驗。此外，螞蟻的數據庫平臺能夠處理2017雙11每秒4200萬的SQL采集和計算，而每條SQL都會被記錄到系統中，之后通過機器學習算法可以識別出SQL執行情況的變化。

最后就是數據庫專家的經驗，無論國內外，阿里和螞蟻的數據庫工程師的經驗和能力都是很強的，不斷將這些經驗轉化成為自治數據庫需要的規則和算法，來提升整體系統的能力，讓螞蟻OceanBase的數據庫體系逐步提升，逼近一個經驗豐富的數據庫工程師。

感知

具備了智能化基石之后，我們再來深入討論構建智能化數據庫系統的三個組件。首先，是感知系統，對于感知系統而言，它目標是理解數據庫上運行了什么樣的業務，并對上面的工作負載（Workload）進行建模，負載建模常用的一些算法，比如隨機過程、回歸以及RNN等在上述的論文中有所介紹，完成負載建模后，可以通過模型預測未來工作負載的變化，比如是否存在流量的突增（導致的容量不足）等，讓數據庫系統提前作出反應，比如建立索引、增加資源等。

另外一點就是“統一事件”，這一點較為抽象，“統一事件”用來建模數據庫系統里面真實發生的事情、所處的狀態，比如有沒有Server宕機、有沒有Partition發生遷移，或者某些關鍵指標的是否發生了變化等，為了感知這些事件，智能數據庫系統中使用Anomaly Detection相關的算法（例如LSTM、ARIMA、HoltWinters以及Ensemble等算法）來識別這些變化并生成相應的事件。

決策

在智能數據庫系統中，決策是使用AI或機器學習的一個非常重要的場景。決策的本質是給定一個輸入，比如系統里面發生的事件、Metric Data以及Workload等，輸出就是Action Plan，而優化的目標就是使得RT時間最小、TPS時間最大和成功率最高，這一點無論是在銀行還是在螞蟻金服內部都是一樣的。

螞蟻數據庫目前所采用的策略主要有兩種，一種是基于經驗的決策，依靠螞蟻DBA專家的經驗建立一顆決策樹，在判斷當前的情況符合決策樹中的分支時，決策執行提前設定好的預案。另外一種是基于學習的決策，這部分可以使用聚類或者控制理論算法來實現，在螞蟻我們使用了最樸素的策略。這方面最大的挑戰就是如何積累學習所需要的數據，因為機器學習的很多算法需要大量數據進行訓練，螞蟻為了積累這些數據開發了DB風險回歸平臺，其能夠以95%的程度仿真線上系統的工作負載，通過自動的在這些工作負載上注入的異常和優化策略，達到積累數據的目的。

執行器

除了執行決策產生的Action Operator，執行器模塊還有兩個目標，就是實現冪等以及最小化系統影響。螞蟻金服技術團隊對于執行器做了抽象，將其抽象為Operator模型，這個模型中具有可免疫和可回滾的特點，也就是說在Operator或Action執行的時候就能夠知道預期產生的結果，并且保證產生預期的結果，其背后就是基于數據或者規則進行的分析判斷。

智能化的最佳實踐案例

智能化大促

接下來結合螞蟻金服的兩個具體場景為大家分享智能化的具體實踐。第一個場景是智能化大促，如下圖所示的是螞蟻金服的簡化架構圖。可以看出整個鏈路非常復雜，支付的核心鏈路需要經過很多的系統，之前都是通過人工方式判斷大促場景有幾個核心鏈路，并人工計算每個系統大約需要處理多少SQL以及需要多少機器，這樣非常容易出現計算錯誤或者遺漏。

此外，還有一些系統可能并不重要，但是還是占用了很多機器，這其實是不合理的。因此在618大促過程中，螞蟻金服實現了通過智能方式計算出到底哪些系統和鏈路是與大促相關的，在計算出精細化的容量之后就能夠實現機器的自動擴容，之后系統就可以自動實現重新負載均衡。

智能化大促的第二點工作就是持續優化。每年在螞蟻內部都會上線很多新系統，對于大促相關的業務系統，需要驅動其持續進行優化，而由于業務迭代太快，所以這一點無法靠人工完成，需要能夠自動識別整個系統的瓶頸和問題，并提供優化建議。

第三點就是用戶無感知壓測，螞蟻的線上系統在運行真實業務流量的同時，也會運行用于檢測系統容量的測試流量。由于雙11的流量壓力非常大，因此在進行線上壓測的時候很容易造成故障，故障隨著RPC的傳導可能會造成整條鏈路出現問題，進而影響用戶體驗。針對這個問題，通過對歷史數據的學習和建模，計算下一次再增加壓力是否會造成失敗，從而避免壓測影響到用戶。

第四點是資源利用率的提升，螞蟻將數據庫放到容器里面之后也就形成了一個非常大的分布式系統。該系統的部分業務和雙11相關，另外一些則沒有關系，與雙11有關系的業務系統的CPU會非常忙綠，而沒有關系的業務系統的CPU將會非常空閑，想要將系統的資源利用率提升上去就需要rebalance等智能化方法。

螞蟻金服針對于復雜的鏈路實現了容量預測模型，與此同時還會對于業務類型進行刻畫，判斷鏈路是否與雙11相關，以及其屬于IO密集型還是CPU密集型。當將這些業務模型刻畫好之后，就能夠清楚地了解業務情況，進而可以實現很多事情，比如從全局的角度將與雙11相關與不相關的業務合并部署到同一臺機器上，更合理的利用資源，而且這些都是系統自動化實現的，無需人工參與。

另外一點就是持續進行優化，這包括資源優化和計劃狀態，螞蟻的數據庫系統采集了線上運行的所有SQL以及SQL的運行數據，對每條SQL都進行了參數化以及分庫分表歸一化建模，從而了解每條SQL大概會訪問多少數據，訪問了哪條索引，最優策略應該是什么樣的。其效果就是對于線上運行的所有核心業務的每一條SQL，都可以判斷哪條SQL不是最優的，或者數據庫訪問資源過多需要修改，并通過釘釘“@”具體相關人員進行改進。

穩定性

第二個具體場景就是穩定性，這里列舉了支付寶經常使用的三個場景：移動支付、乘公交地鐵以及購買理財產品，而在這些場景對實效性、成功率等要求時非常高，在螞蟻金服這樣的體量下，任何一點點異常都會影響非常多的用戶，促使螞蟻對穩定性的要求越來越高，既要具備城市級容災能力，也要具備精細化的異常恢復能力。

螞蟻金服OceanBase的容災機制

下圖來自于Google，其大概列舉了系統中經常會出現的異常類別。在過去的幾年里，螞蟻金服投入了大量的資源，進行架構改造升級，實現機房、網絡等基礎設施層面故障的快速恢復能力。螞蟻金服也正在設計系統來發現非通斷式異常，并快速、自動的將這些異常修復。

Zone/Region級別容災

如下圖所示的是螞蟻金服的數據架構，在業務和數據庫中間件的數據架構層能夠保證當某一個機房掛掉可以立即切換到另外一個機房。左側的圖則是OceanBase的“三地五中心”的設計，即使某個城市故障都不會影響服務使用，這樣的架構現在依舊在不斷進行優化和打磨。

Self-Healing-精細化異常恢復

精細化異常恢復的主要目的是自動化解決數據庫系統的異常。這里列舉了幾個例子，比如下圖列舉了三個非通斷異常：Bad SQL、IO Hung以及Software Bug。目前，螞蟻內部的目標就是在5分鐘之內恢復這些異常，這顯然無法通過人工完成，而需要自動化手段，比如基于專家經驗的決策樹和機器學習決策。Self-healing會引入一個問題，那就是如何防止自動化決策錯誤導致問題惡化，而目前螞蟻能夠做到了切主不殺事務、冪等控制和柔性強切以及其他系統防護的工作。

下一步計劃

對于未來的計劃而言，首先要讓螞蟻的所有業務域都運行在自治的數據庫中，不再需要DBA進行日常維護，希望能夠通過智能數據庫解決90%以上的問題，而讓DBA和架構師更加專注于架構發展和平臺設計。此外，螞蟻還希望將經過內部驗證的功能和服務來賦能螞蟻金融云和更多銀行等金融機構。

?

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的OceanBase在蚂蚁金服的智能运维实践之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。