雲資料庫UDB的三重境界

03-04

0.前言

公有雲服務本質上是用戶和 IT 基礎設施的連接器，通過打碎傳統 IT 繁重的流程、低效的工作方式、不透明的價格以及糟糕的用戶體驗，重構出雲主機、雲資料庫、雲對象存儲等產品，讓用戶更便捷地獲取計算和存儲能力，並保持使用習慣不變。

經過近十年的發展，一個越來越明顯的趨勢是公有雲服務正從基於傳統 IT 基礎設施的包裝和組合式創新，演進為圍繞公有雲場景、計算和存儲能力的重新進化和升級。諸如容器雲和 Serverless 架構、AWS Aurora 雲資料庫、UCloud 安全屋等，便是這一趨勢的典型代表。

由此，我們可以對公有雲的發展進程做一個兩階段的概括。雲計算 1.0 的關鍵詞是連接，通過互聯網和公有雲來連接用戶和計算存儲能力；而雲計算 2.0 的關鍵詞是進化，圍繞公有雲場景，重新看待全社會使用計算和存儲資源的問題，對現有 IT 基礎設施、模式做進一步的升級和進化。

站在雲計算 1.0 向 2.0 進化和升級的檔口， UCloud 雲資料庫團隊希望通過這篇文章梳理過去、剖析當下、想像未來，以此來全面展現 UCloud 雲資料庫服務（ UCloud DataBase Service，簡稱 UDB ）能力，分享我們過去的經驗和對未來的思考。

1. 基因

考察一個雲計算服務的發展猶如觀察一顆種子落地後的生長。傳統 IT 設施向雲端變遷的趨勢是雲服務生長所需的陽光和雨露，但一顆種子能否長成參天大樹，除了足夠的陽光雨露，

還要考察這顆種子的基因和成色。

在 UCloud 公司的四大價值觀里，「客戶為先」是放在首位的價值觀。這體現了 UClouders 一以貫之的理念：只有為客戶創造出真正的價值，企業才能夠生存和發展。

創造真正的用戶價值是 UCloud 所有產品的基因，也是 UDB 產品和雲資料庫團隊的基因。對於 UDB 產品而言，創造真正的用戶價值體現在兩個方面：

需求驅動的產品研發和運營

需求驅動產品設計，技術評估實現可行性，必要時非標快速定製，定製逐漸沉澱為標準產品，整個過程循序漸進。小步快走，是互聯網研發和運營的要領，也是公有雲服務的要領。

以 UDB 跨地域跨可用區容災為例，從單機版 UDB 開始，不斷有用戶因跨可用區容災場景提出建跨機房從庫的需求，中大型互聯網客戶尤為強烈。起初，以一種非標形式來提供能力的支持。後期因 VPC 2.0 上線，技術也愈加成熟，現已將這種非標能力轉化為標準能力，即多可用區高可用 UDB 產品，同時也將 UDB 由可用區級提升為地域級，產品形態得到一次質的提升，傳統模式下需要付出極高成本才能構建的異地容災方案，通過 UDB 產品可以輕鬆獲得，用戶價值進一步被創造。

一切以客戶價值為歸依，匠心鑄造真正價值

雲計算產品是 IT 基礎設施類產品，技術人員在雲服務的研發中起主導作用。但技術並不直接等同於用戶價值。即使再先進的技術，離真正的用戶價值還是會有一段距離。這段距離則需要用做產品的匠心來來彌補。所謂的產品匠心，非常重要的兩點是對需求的洞察和對技術的取捨。技術人員常見的一個毛病是先入為主，將自己覺得酷的、牛的技術點等同於用戶價值。但事實往往證明不一定。真正的用戶價值創造，要打破技術人員思維的藩籬，洞察到用戶需求的本質，從需求角度出發做技術選型，必要時敢於放下自己的喜好甚至利益，成就真正的用戶價值。

以UDB 產品的硬體架構選型為例。2013年UDB立項之初，並沒有選擇雲主機方案，而是選擇了物理機+ Docker 的方案。如果基於雲主機來構建UDB，能夠充分復用雲主機成熟的能力，UDB團隊只需要關心硬體層面之上的問題，同時降低研發成本，快速推出產品。但在2013年我們判斷，當時的雲主機對IO的優化還存在不足。具體體現為IO路徑過長，管理層次太多，這些都將影響IO 性能和IO穩定性。而IO性能和穩定性，恰好又是雲資料庫最重要的兩個技術指標。因此， UDB 從一開始就選擇了物理機+ CGroup的架構，在2014年全面轉向Docker。事實證明，這是一個明智的選擇。5年以來，在各公有雲廠商的雲資料庫產品性能對比上，UDB 每次都是完勝。

2. 三重境界

王國維在《人間詞話》二六節寫到：古今之成大事業、大學問者，必經過三種之境界。「昨夜西風凋碧樹，獨上高樓，望盡天涯路」，此第一境也。「衣帶漸寬終不悔，為伊消得人憔悴」，此第二境也。「眾里尋他千百度，回頭驀見，那人正在燈火闌珊處」，此第三境也。此等語皆非大詞人不能道。然遽以此意解釋諸詞，恐晏、歐諸公所不許也。

UDB 的成長之路，也經歷三個階段，細分為三重境界。這三個階段互相獨立，又存在一個內在的邏輯，將它們牢靠地連接在一起。

這個內在邏輯就是 UDB 的基因：創造真正用戶價值。 UDB 在每一個階段的萌芽、發展、躍遷，無一不是這個基因和理念在發揮作用。

a.做透一個點：取代自建資料庫

UDB 產品第一階段要比拼的是能否比用戶自建資料庫（基於雲主機或者自建 IDC ），具備更大的用戶價值。只有創造出更大價值，形成更高的價值勢能，才能吸引用戶將業務遷移到雲資料庫。所以 UDB 的第一個目標就是把「取代自建資料庫」這一個點給做透。

b.構建功能網：全方位覆蓋用戶需求

過去幾十年來，圍繞 DBMS 出現了從容災、遷移、安全到讀寫分離、數據拆分等解決方案和軟體，對應用戶業務的各種需求。這些解決方案和軟體同樣需要雲化，並且需要利用公有雲的優勢產生比自建更大的價值。如此，才能不斷強化雲資料庫的價值勢能，服務好已有用戶並吸引更多用戶向公有雲轉化。

因此， UDB 產品第二階段要做的是構建一張雲資料庫功能網。在第一階段的基礎上，繼續將用戶需要的各個功能點做透。眾多功能點以及功能點的組合，最終構成一張大網，全方位地覆蓋用戶的各種需求。

c.三位一體融合平台：雲計算 2.0 下的內生進化

第一階段和第二階段，對新價值的創造都是基於成熟的軟體或解決方案，利用公有雲來實現功能的隨手可得、快速部署和彈性擴展。這種模式清晰明確，但並不意味著雲資料庫價值創造的終點。

雲計算 2.0 時代，公有雲開始擺脫傳統 IT 基礎設施和軟體的藩籬。在產品和技術上，圍繞自身業務場景開啟獨立進化。其中，如何解決全社會大規模用雲時的成本、效率和智能問題，是這場進化的核心。而 UCloud 雲資料庫團隊也需要進一步去思考，是否能提供更加廉價優質、高效智能的雲資料庫產品。帶著問題和思考， UCloud 雲資料庫團隊內部做了多次探討，最終達成這樣一個認知：雲計算 2.0 下的雲資料庫服務，會是資料庫PAAS化，運維智能化，以及結構化數據處理生態體系這樣三位一體的組合。

下文我們將對做透一個點、構建功能網、三位一體融合平台展開詳細介紹，用具體的例子來勾勒 UDB 發展的三重境界。

3. 做透一個點：取代自建資料庫

取代自建資料庫，看來似乎簡單，但逐一羅列並剖析需要考慮的五個價值點：

a.可靠性

b.穩定性

c.高性能

d.零維護

e.性價比

你會發現要做好絕非易事。 UDB 產品經過幾年的努力，完美地實現了 做透一個點：取代自建資料庫 這一目標。

可靠性

雲資料庫的可靠性強調數據安全性包括兩方面：一是DB數據；二是備份數據。DB數據落盤的持久性通常要求99.9999％及以上，表明數據保持存儲狀態不丟失的概率。此類數據主要是指用戶存儲在資料庫中的數據，不包括緩存和臨時存儲。DB數據本地盤採用 RAID10或者 RAID50 做好冗餘，若是高可用機型，則再有實例級冗餘。備份數據要求異地存儲，多副本存儲。

穩定性

這裡強調的是單機穩定性。我們可以看下如何自建一套資料庫，在數據中心的電力、物理網路、機架、物理伺服器等基礎設施之上，部署操作系統和補丁，安裝資料庫軟體和補丁，運行資料庫軟體，啟用資料庫服務。如果是採用虛擬化部署，則額外涉及計算、網路、存儲虛擬化。這是一套龐大的系統，各個環節都存在不可預知的故障風險。 UDB 經過多年的運營積累了諸多經驗，在多方面多層次保障其足夠穩定。

高性能

如何通過軟硬體結合使單機資料庫的性能發揮到極致？高性能 UDB 機型底層採用 PCI-E/NVMe SSD 存儲硬體，定製化宿主機 Linux 內核專門適配最新型硬體。採用自研 IO 調度演算法，可良好保障實例級的 IO 隔離。資料庫層面通過參數調優、內核定製優化，使資料庫發揮出最優性能。通常情況下，資料庫的性能瓶頸會出現在磁碟 IO 。採用虛擬機自建存在諸多弊端，例如 IO 路徑過長、 IO 穩定性較差、 IO 競爭等。 UDB 採用高性能物理機+ Docker 架構 + 自研 IO 調度演算法，打造出強勁的 IO 性能，持續保障穩定性和隔離性。

零維護

通常情況下，資料庫是後台服務框架里最為核心的組件，重要性不言而喻，日常運維工作慎之又慎。在第一個階段， UDB 提供的是資料庫的全託管運維能力，包括一鍵部署、保活、容災、備份、恢復、遷移、配置、漏洞修復、升級、監控與告警、巡檢等等一系列的後台運維類操作，解放了客戶的 DBA 人力/精力。本身在 UDB 產品上集成了上述多數的控制台操作，使客戶對資料庫基本可控。

性價比

客戶對雲資料庫買不買賬，性價比成為非常重要的因素。可靠、穩定、高性能、高可用、零維護等基礎能力作為 UDB 的價值基礎，在 UDB 產品上更是提供豐富的配置組合，自定義存儲（普通盤 or SSD 盤）、內存大小、 VPC 網路、可用區等，靈活多配，按需付費，一鍵交付。按業務增長，彈性擴容。客戶完全省去自建資料庫的一切環節，規劃 IDC ，規劃資源、採購、上架、交付部署以及後期一切運維工作。對於一些商業資料庫（如SQL Server ）尤其划算，省去自購官方 License 費用。

4. 構建功能網：全方位覆蓋用戶需求

雲資料庫發展第一階段的目標是把「取代自建資料庫」這個價值點做透，創造出區別於傳統方式的全新價值。在第二階段則需緊扣用戶使用資料庫的痛點，有針對性地推出公有雲解決方案，構成一張功能網，全方位覆蓋用戶需求。我們把第二階段用戶的痛點需求歸結為三類：

高可用和容災

資料庫的高可用是大型

IT 系統的必備機制，但不少系統在建設時，受限於自身基礎設施和能力，無法實現優質可靠、高等級的資料庫高可用。

而這一點恰好是公有雲的優勢。首先是完善的基礎設施。公有雲廠商擁有大量的數據中心，數據中心之間通過跨可用區，乃至跨地域的光纖專線進行連通，構成一張覆蓋全國乃至全球的高性能網路；第二，公有雲的規模效應將帶來成本優勢，能夠顯著降低基礎設施的建設成本；最後，規模效應也讓技術團隊被超大力度地錘鍊，技術能力和運營水平不斷提升。基於以上三點原因，公有雲是實施資料庫高可用的優良環境。

容量和性能

大數據時代，全社會數據量在高速增長。原因之一是生產和生活日益互聯網化，產生大量數據；原因之二是數據的價值越發得到重視，企業普遍希望能夠沉澱並分析數據、從數據中挖掘出價值。

而傳統的單機資料庫系統，必然隨著大數據時代的到來，在容量和性能上遭遇挑戰。如何應對這兩大挑戰，且總體保持 IT 成本可控，是令客戶越來越頭痛的問題。

運維和安全

運維和安全是雲資料庫研發和運營永遠的課題。需要圍繞用戶需求構建運維閉環，從數據導入導出、資料庫運行期管理/問題排查，到性能分析、資料庫優化，讓用戶不使用任何第三方運維工具，即可將雲資料庫運維工作全部搞定。在安全上，除了 DBMS 自身的用戶訪問控制機制之外，還應該圍繞審計、加密、防惡意攻擊等方面為用戶提供優質的產品或功能，構建資料庫安全運營閉環。

下面將列出 UDB 圍繞高可用和容災、容量和性能、運維和安全三個方面，構建的眾多功能點。這些功能點和功能點的組合構造出一張大網，全方位覆蓋用戶需求。

4.1高可用和容災

4.2容量和性能

4.3運維和安全

5.UDB產品全景圖

經過一、二階段的發展，UDB產品已經成長為基礎紮實、品類完善、功能全面的一個雲資料庫產品體系。UDB產品的全景圖如下：

6. 三位一體融合平台：雲計算 2.0 下的內生進化

UDB 產品在第一、二階段的成長和發展是基於公有雲場景，圍繞成熟的資料庫軟體和解決方案來為用戶創造使用價值。這種模式清晰明確，但也存在不少短板。

1.最大的問題在於傳統的資料庫軟體的架構和代碼已不適應公有雲發展的需要。傳統資料庫在容量和性能提升、容災、最新硬體的利用上都存在不足。

2.用戶對雲資料庫提出的新需求，傳統資料庫已不能滿足。比如按需付費、大數據量的高速備份、更短的災難恢復時間、OLTP

和 OLAP 融合、異構資料庫等問題，傳統資料庫沒有很好的解決方案。

3.資料庫運維的方法仍然傳統。當資料庫實例和客戶量達到一定的規模後，傳統的人工運維的方法已變得不切實際。

我們不可能用產生問題的方式去解決問題。上述問題來源於傳統的資料庫架構和運維方式，因此不再可能用傳統的方式去解決。唯一解決之道在於依託雲計算 2.0 ，實現雲資料庫的內生進化。擺脫傳統模式的窠臼，開創雲資料庫的新境界。

在雲計算從 1.0 向 2.0 躍遷的關鍵時間節點上， UDB 團隊提出未來發展的三位一體戰略來刻畫未來雲資料庫的技術和產品形態，滿足未來客戶的普遍需求：

a. 資料庫PAAS化

b. 運維智能化

c. 結構化數據處理生態體系

上述三個支點構成一個雲資料庫2.0體系，有力支撐 UDB 未來的發展。

6.1 資料庫PAAS化

從用戶使用的角度，IAAS和PAAS的區別在於，IAAS需要用戶為租用的資源實例付費（即使資源沒有被100%使用），而PAAS只需要為資源實際使用量付費。PAAS在IAAS的基礎上，進一步降低了全社會IT使用成本，符合公有雲發展的終極理想：讓IT像水和電一樣被人類社會使用。

像使用水和電一樣使用資料庫，這個理想看上去很美好，但很難實現。要做到像水和電一樣使用資料庫，必須解決兩個關鍵問題：

1. 容量和性能根據業務需求彈性擴展

2. 存儲和計算能力按實際使用量計費

第一個問題既目前熱門的分散式資料庫問題，而第二個問題長期以來只是一個模糊的目標，可望而不可及。但近幾年來，計算和存儲分離的架構理念，結合新型硬體或創新的資料庫IO優化方法，為解決這兩個問題帶來希望。

計算和存儲分離，就是將數據存儲下放到分散式存儲系統，資料庫實例只保留SQL執行和事務處理等計算類操作，計算層和存儲層通過網路交互徹底解耦。歷史上，計算和存儲分離架構的產品有存在（如騰訊雲CDB第二代產品），但並未成為主流，其原因在於將計算和存儲分離後，資料庫的性能上不去，導致實際價值不大。但近幾年來，業內分別從兩個不同角度，突破了這一瓶頸：

1. AWS Aurora創造性地裁剪資料庫內核，只落地RedoLog而不落地Page，從而減少了持久化數據的寫入量，IO開銷大為減少。

2. 阿里PolarDB利用高速網路和新型硬體，優化了資料庫內核的IO路徑，實現了通過網路的分散式IO，和本地IO同樣的延遲時間和更高的吞吐量。

由此，雲資料庫正式進入2.0時代，既計算和存儲分離時代，向PAAS化開啟大步演進。以AWS 2017年11月份推出的Aurora Serverless為例，目前已經做到了根據業務壓力實現動態伸縮調配系統資源，存儲能力和讀寫性能得以動態擴展；做到了根據業務實際數據量和讀寫QPS進行計費，從而實現像使用水和電一樣使用資料庫。

而UDB從2017年下半年開始，已經啟動計算和存儲分離架構的新一代資料庫的開發，邁出構建UDB 2.0的關鍵一步，後續產品敬請期待。

6.2 運維智能化

一般企業的 DBA 只需要為本公司資料庫系統服務，而公有雲 DBA 需要為上萬家企業服務，工作量不言而喻。隨著客戶和資料庫實例的增多，必須要通過自動化、智能化的方式來幫助 DBA 進行在線實例的維護，讓 DBA 從繁重瑣碎的日維護工作中脫離出來，把精力放在更高階、更重要的事情上。

DBA 工作智能化的過程總的來說分為三個階段： 1. 原始手工運維；2.重複性工作自動化；3.結合機器學習的運維智能化。

在手工運維階段， DBA憑藉自己的經驗藉助一些半自動化的工具，完成雲端資料庫實例的日常運維、故障分析和解決、性能調優工作；

在重複性工作自動化階段，雲資料庫團隊將建設體系化和自動化的 DBA 運維繫統，收集資料庫實例各層面的系統狀態和性能數據，構建數據分析平台進行數據分析，判斷或預判有問題或有潛在問題的資料庫實例，以及通過預設規則進行資料庫故障的處理、防範或告警。

在 DBA 工作智能化階段，將利用大數據分析和機器學習的一些技術去進一步增加 DBA 自動化運維繫統。比如，細時間粒度的資料庫實例異常預警、資料庫故障自動診斷和處理等。

6.3 結構化數據處理生態體系

資料庫PAAS化+運維智能化，這兩個目標的實現，可以說實現了公有雲資料庫從業者一直以來追求的聖杯：一個根據業務壓力自動彈性伸縮、按需付費且運維自治，僅需少數人工干預的雲端結構化數據存儲和處理平台，讓用戶真正得以向水和電一樣使用資料庫。但這還不夠。

事實上，用戶對結構化數據的存儲和處理時複雜的，有時候還是非常個性化的。回顧對象存儲PAAS平台的發展歷程，一開始是解決文件的存取問題，隨後開始提供對文件的加工處理能力（比如轉碼、壓縮、鑒黃等），最後基於該平台結合其他技術（比如AI），進一步延伸諸如機器視覺、圖像知識提取等功能，不斷滿足用戶的需求。

因此，對於一個結構化數據處理PAAS平台而言，必然也需要隨用戶需求而動，不斷向上生長，添加更多能力。更有必要的是打造一個開放的、共贏的結構化數據處理生態體系，引入全行業和全社會的力量，來建設一個擁有涵蓋各行業用戶需求，有著勃勃生機同時穩定可靠的結構化數據存儲和計算生態系統，進一步解放全社會的生產力。

7.結語

通過公有云為用戶創造比傳統IT更大的價值，這是 UCloud 雲資料庫團隊開展工作的出發點。雲計算和公有雲的高速發展最根本的原因不在於有多前沿的技術、多便宜的價格，而是在於通過一個個產品和功能的創新和創造，不斷產生新的用戶價值，在真實用戶需求的助推下發展壯大。UDB推出5年以來，UCloud雲資料庫團隊一直秉持這一理念，伴隨雲計算髮展大潮經歷三重境界，任憑歲月更迭而初心不改。