以下是現場速記。

 

OceanBase解決方案部泛互行業總經理 弓子介

 

弓子介：在座的各位嘉賓，我叫弓子介，是2015年加入阿里，OceanBase是一款技術產品數據庫，今天又來了很多CIO，聊了很多數字化轉型，我是2015年加入以后正好趕上阿里系內部的移動互聯網Timing，所以今天想跟大家分享阿里系內部從原先的IOE單體架構，面臨“雙十一”在線高并發場景的思考。

 

大家一直都在談數字化，坦白講，技術都是為業務服務的。最近二十年，隨著互聯網的發展，剛才波士登的CIO也提到很多商業模式從線下的門店零售變成在線化。整個業務是不確定性的，很難預測明年或者下一個季度需要多少IT支撐才能滿足業務，整個技術架構都是業務驅動的。最近十幾年大家都在做企業IT數字化轉型，整個IaaS層也是從原先采購硬件的主機到后來采用虛擬化的方式提升整個IT運營成本，現在大家的業務也分為穩態業務和敏態業務，一般敏態業務可以預測，上云投入產出比是最高的。最近五年的發展也是經過單體架構變成微服務化架構，再到最近的容器化，整個技術架構、中間數據架構一直沒有一個很好的方法論。

 

今天結合OceanBase在螞蟻的實踐給大家做一個分享。

 

數據架構伴隨應用架構和基礎設施架構的演進，主要面臨幾個方面的問題：業務的不確定性，很難快速預估未來通過抖音投放和渠道投放需要多少硬件，這些對數據要有快速彈性的需求。現在已經不光是交易數據，尤其是很多創新業務，去做IoT、RFID，采集車端這些非結構化或者半結構化的數據，這些數據已經很難通過傳統的商業數據庫，包括Oracle、MySQL存儲，衍生出來類似Mongo這些內存數據庫，所以對企業來說數據庫的種類會越來越多，管理成本也會變大。OceanBase認為，數據庫回到本質就是幫助企業業務系統存儲數據，只要有一款數據庫既能滿足聯機交易，又能滿足企業決策的報表查詢，包括交易數據、IoT半結構化數據，都是可以放在一個數據庫里面，那么對大家來說整個架構可以統一，其實也是2015年在螞蟻內部希望能夠統一技術棧的思考。

 

數據庫的發展也是伴隨業務的發展，Oracle到今天為止也有四十年了，但到2000年左右已經沒有新的單機數據庫或者集中式數據庫品類的更新，因為2000年以后移動互聯網和PC時代來臨，面臨數據的爆發式增長，單機數據庫已經很難支撐海量存儲，7×24小時聯機交易場景，所以基礎設施并沒有趕上業務的商業模式創新，怎么辦呢?只能去想一些妥協的、中間的解決方案，大家都聽過分庫分表，為什么要分?因為單機性能、容量很難滿足聯機改易和線上運營，不得不分而治之，所以架構在OceanBase看來只是中間態，原先IT存留人員還是之前傳統數據庫的年代，數據庫的實力有了幾何級的增長，所以對大家來說應該也都聽說過，X86硬件故障率都有年化百分比，就是6%。

 

OceanBase數據庫可以在應用程序微服務改造完成以后，把運維復雜度降為原來的集中式數據庫，既支持聯機交易，又支持現在新興的車聯網IoT數據，整個企業統一技術棧，這是我們以前在螞蟻內部的思考方向。

 

剛才講過，OceanBase數據庫相比市場上其它大家聽過的數據庫，最大的區別在于，這款數據庫是在阿里2010年立項，先解決自身阿里系內部數字化轉型遇到的問題。OceanBase剛開始在阿里之前用的也是Oracle、IBM、EMC的存儲，但在2009年首屆“雙十一”，這套架構就已經扛不住了。為什么?因為天生不是為了在互聯網場景設計出來的，我們2010年立項以后在電商場景打磨數據庫的彈性和高并發能力，2015年OceanBase在阿里系內部來到電商下游支付場景。

 

跟大家分享一個故事：2015年，支付寶出過一次比較大的輿情故障，就是杭州蕭山光纜2015年5月27日被挖斷了，那個時候還是有很大的社會輿情風險。因為當時的故障非常典型，就是傳統數據庫Oracle主備架構情況下網絡出現中斷，如果大家是支付寶的用戶應該也知道，支付寶剛開始去付錢是要跳到網商銀行，不去做帳務相關的處理，到了2014年有了余額寶，其實涉及到資金的交易，我們并不敢去做強行的切換，導致當時故障花了8個小時，等到網絡恢復以后才恢復。其實這件事情也是加速OceanBase在螞蟻集團的快速落地，在這之后，2015年到2019年，我們花了四年的時間把阿里包括螞蟻內部的所有應用全部切換到OceanBase，包括借唄、花唄、余額寶都是跑在上面。

 

2020年以后，我們的數據庫產品也是被業務倒逼往前走，前十年都是在阿里系內部面對互聯網場景，但隨著國內的信創走進各行各業，包括金融、政府。我們在做傳統客戶的時候發現，這些架構還是停留在原先的Oracle和MySQL，以前大家去跑業務的時候并不會像互聯網一樣嚴格區分聯機交易還是分析查詢，包括報表查詢的服務，會在一個實例上去跑，但在互聯網場景打磨的數據庫走向傳統企業會發現一開始水土不服，云廠商提供的數據庫只能做聯機交易，稍微復雜的查詢就跑不出來了，可能會推薦去用一款數據庫，中間通過數據的傳輸解決原來可能Oracle一個數據庫就能解決的問題。

 

我們2020年發布OceanBase3.0版本，主要面向國內各行各業的企業客戶，數據庫引擎既可以滿足互聯網場景的高并發、點查點讀，也可以支撐原先可能在Oracle X Data運行的復雜查詢。去年我們發布4.0版本，其實也是被業務倒逼的，因為我們走出阿里以后發現很多CIO對分布式數據庫的認知，覺得我們的體量還沒到，現在我們用MySQL和Oracle也還好，并沒有急著去換分布式數據庫。4.0版本更多的是希望降低我們數據庫的使用門檻和起步成本，可以做一些創新業務的時候能夠直接體驗OceanBase。隨著業務越來越大，伴隨著業務一起成長，不是分布式數據庫只有到一個超大體量才能去用。

 

這些就是整個OceanBase四個版本解決的主要痛點，今天參會的很多CIO企業已經在使用。就像剛才主持人介紹的，我們在金融行業主要是以信創國產化作為切入點，但在當前OceanBase走出螞蟻、走向社會也是從金融行業走向各行各業，現在OceanBase服務的非金融行業已經超過金融行業客戶的數量。

 

OceanBase相比其它友商提供的數據庫最大的區別就是剛才提到的，當前國內的數據庫OceanBase是唯一一款由自研、自用到外部客戶輸出的數據庫，不會像其它廠商可能會基于開源直接在云上提供對外服務，可能有這種踩坑的過程，需要企業一起進行。OceanBase從第一天起就是在螞蟻嚴苛的Mission-critical去做全場景打磨。

 

OceanBase之所以叫做分布式數據庫，主要就是解決互聯網場景穩態業務和敏態業務的沖突。因為我們開發一個新的業務上線投產，并不會知道這個業務未來發展的天花板有多高，一開始去做整個IT評估，可能評估多了，也有可能評估少了，這個時候可能就會面臨運營側流量激增，一下子IT基礎設施沒有扛住。我們的數據庫可以通過Scale Out的方式，以前用云主機和MySQL性能上線就是這臺PC機能夠提供的計算能力，單機上限就是整個系統的吞吐量上限。OceanBase可以通過追加機器橫向地往一個集群堆疊更多的機器，理論上性能是可以快速伴隨業務的突變隨時調整。

 

因為OceanBase本身就是在螞蟻內部解決集中式數據庫這種主備架構腦裂的問題，之前應該也有一些報道，云廠商去年年底在某些Region出過大的故障，一個機房掛了整個Region八個小時都沒有辦法服務，當時只有OceanBase對外提供服務，其它機房都有出現故障。雖然是小概率事件，但在金融場景和對連續性要求很高的業務場景都是必選項。

 

OceanBase4.0發布的新特性就是單機分布式一體化，伴隨業務從小到大。因為我們每年都會做一些創新的業務嘗試，新的業務不可能起步就使用特別大的規格去做業務創新，所以針對敏態創新型的業務，4.0可以在單機使用，如果業務未來有爆發式的增長也可以快速通過追加機器實現3臺機器、6臺機器的線性增長，并不需要起步很高的配置、很高的規格才能使用分布式數據庫。

 

HTAP這個名詞比較偏技術術語，因為我們走進傳統企業，發現一個業務系統無法嚴格區分是在線聯機交易還是復雜查詢，一般都是混合Workload，無論是國產信創還是成本經濟效益考慮，很難遷移到一款數據庫，如果是其它云廠商的話。OceanBase希望把簡單留給客戶，把復雜留給自己，想要去做一個分布式Oracle，解決原先的應用，包括DB2、Oracle遷移到OB，或者一個產品替換到另一個產品，不是為了做數字化轉型，一款產品需要八款產品才能解決原先一個數據庫解決的場景問題，整個成本只要一份數據就能夠滿足業務需求。

 

剛才提到的就是OceanBase的優勢，站在CIO的角度去做整個數據庫的替換決策成本還是挺高的，因為換數據庫無異于給非常換發動機引擎，業務不能停，過程還需要盡量低成本。OceanBase在數據庫內核層面兼容Ocacle11.2以上的版本以及MySQL8.0，相比其它廠商最大的區別是什么?因為現在很多廠商也說兼容Oracle，可能基于PostGre，OceanBase是原生層面兼容Oracle，就像大家了解Java和C的區別，Java需要解釋虛擬機的翻譯，因為內核是開源PostGre，上面封裝的性能遠遠不如底層數據庫內核層面實現兼容。為了盡量減少整個異構數據遷移的決策成本，我們把螞蟻內部去O的最佳實踐沉淀了一款遷移工具，叫做OMS，可以端到端地幫助大家在整個異構數據遷移過程中，所有的風險都是可以通過這款工具一鍵完成。

 

OceanBase在阿里系內部就是面對這種規模化的運維，螞蟻內部有上萬個OceanBase實例，規模化場景中成本也是公司考量IT部門和整個數據庫部門的一個重要的指標，我們從原來的MySQL、Oracle遷移過來，公司希望能夠以更低的成本完成這件事情。我們在OceanBase內部自研編碼以及高壓縮比，原先Oracle應用、MySQL應用遷移過來，存儲至少比原先節省70%。

 

剛才提到微服務化改造以后，服務進行了拆分，底層數據實例會有一個指數級的膨脹，導致運維的復雜度上升，整體資源密度的下降。OceanBase內部做了微服務化改造以后，MySQL實例上漲10倍，遷移到OceanBase以后，我們通過多租戶概念，可以在一個大集群把原來零散的MySQL、Oracle整合到一套OceanBase集群，整體計算密度大約有50%的上升，可以降低整體運維復雜度。

 

前面介紹的都是OceanBase的內核能力，除了內核以外，數據庫本身使用對象包含開發和運維，針對不同的使用群體，我們也有配套一些管理工具以及開發工具，可以像原先使用MySQL、Oracle一樣使用OceanBase，并不會增加太多的學習成本。

 

OceanBase的公有云也是對外正式發布，因為發現隨著疫情的變化，很多企業也開始走出國門，開始走向海外，所以OceanBase能夠提供線下部署，也能夠提供公有云部署，未來企業如果有跨境出海的需求也可以直接使用OceanBase，我們現在是在AWS和GCB均已經開服。

 

前面講的都是OceanBase的產品特性，后面跟大家分享一些案例。

 

因為我們是源于螞蟻，螞蟻之所以使用OceanBase看重的也是OceanBase的底層核心能力。我們提出的理念就是統一技術棧，現在螞蟻的應用數據都是跑在OceanBase上面。

 

隨著信創的推進，運營商需要去做原先技術棧的架構轉型。OceanBase幫助山東移動把原來的CRM系統從傳統的IOE架構平遷到OceanBase上來，不光是原來技術棧的升級，也包括未來主機、芯片的全棧國產化。

 

海底撈是去年因為疫情，整個國內門店需要降本增效，OceannBase高壓縮比以及多租戶整合，幫助整個海底撈原先的IT的TCO投入降低大概35%左右。

 

理想汽車不光是供應鏈端的系統，包括車聯網端的整個IoT數據，現在是全面跑在OceanBase上來，看重的是金融級的高可用。車間智能制造，如果系統宕機，可能直接影響到出貨量，其實是OceanBase給理想汽車帶來的價值。

 

攜程也是如此，因為很難預測分布式業務未來的增長，很多業務都有自己的周期性，攜程就是最典型的例子。春運購買火車票，日常業務是跑在自己的機房，可以用自己的IDC內部的基礎設施承載，但春運這種突增的業務高發流量，單機房是很難承載的，采用OceanBase以后可以快速地在春運前購買云主機，通過OceanBase的彈性能力彈到云上，等到春運搶火車票結束以后再縮回自己的IDC。

 

總結一下，這些是我們在國內的頭部咖啡品牌，因為原先的技術站是基于虛擬化的VMWare架構，需要整體數字化轉型，包括應用側的微服務化，其實面臨整體數據庫實例的膨脹，包括原來的PostGre、MySQL、Oracle可以通過OceanBase整合到一個技術棧，這是我們當時做這個項目帶來的最大價值。

 

OceanBase是從螞蟻孵化帶有天生的互聯網高并發和海量數據的解決方案，我們走出螞蟻，走向各行各業，也會被業務場景打磨，現在可以支持頭部客戶，也可以支持Startup和創新場景。未來大家如果有些創新業務場景，可以考慮先使用OceanBase，隨著業務變大，OceanBase也可以從容地、慢慢地通過擴縮容的方式伴隨業務一起成長。

 

我們既可以支持線下IDC，又可以支持各種云，包括國內的云廠商以及海外主流的云廠商。客戶那里如果有多云戰略，OceanBase可能是你的首選，包括理想和一些客戶，底層云的Vendor是多家，可以通過OceanBase屏蔽不同云廠商的產品差異，PaaS層提供統一的管理和監控。