12 月 1 日，以"去發現，去挑戰"為主題的 PingCAP DevCon 2022 主論壇線上上成功舉辦，為數萬觀眾帶來一場技術盛宴。PingCAP 聯合創始人兼 CTO 黃東旭，在大會上分享了“The Future of Database”的主題演講，分享了他對雲原生、開發者生產力的理解，介紹了 Serverless HTAP 的意義以及未來的”技術無感化“發展方向。以下為演講實錄，全文約 7000 字。

首先感謝所有使用者，使用者的使用是支撐 PingCAP 一直進步的最重要動力，每年看到 TiDB 越來越普及，使用者越來越多，就感覺肩上的擔子又重了。

![1.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/1_93f0db213c.png)

在過去一年中，TiDB 有一個最重要的變化——發版節奏和模型發生了變化。今年，TiDB 第一次引入了 LTS 版本，以及形成了以兩個月為週期的迭代發版節奏。此外，特別值得一提的是，今年 5 月 TiDB Cloud 正式 GA，去年我提到雲的意義在於加速軟體的迭代速度，短短大半年時間 **TiDB Cloud 已經進行了超過 34 次迭代，增加了上百個功能特性和改進**。這個迭代速度比 TiDB 核心本身的迭代速度更快，這也印證了之前我對於雲的判斷。

## 資料庫的“第一性原理”

埃隆·馬斯克有一個很有名的“第一性原理”，這些年我一直也在思考這個問題，對於一個資料庫廠商或者資料庫產品經理來說，資料庫軟體的第一性原理是什麼？**對於資料庫來說，一個很本質的問題是 developer 到底需要什麼樣的資料庫**。這裡說的 developer 並不是指資料庫開發者，而是那些真正開發應用的開發者。為什麼這麼說呢？其實數字化轉型也好，各種應用創新也好，其背後的驅動力到最後都是一行一行程式碼，而這些程式碼都是開發者寫的。對於資料庫軟體來說，真正的使用者其實就是開發者。

![2.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/2_81894f8cfc.png)

上圖是一項關於“在你的組織內部到底是誰在選擇 Database”的調查，可以看到排名第一的是架構師、第二是開發者、第三是 DBA，三者加起來達到了超過 80% 的佔比。這些人都是廣義上的開發者，對於資料庫軟體來說真正的使用者其實就是這些人。

![3.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/3_7b2415a552.png)

資料庫裡另外一個大的趨勢是 Cloud。我覺得今年已經不用再強調 Cloud is the future，從 Gartner 的報告可以看出，今年全球企業在 Cloud 上的投入已經超過了私有化資料中心的投入，並且每年的增速都非常快。

![4.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/4_4c3a3da5dc.png)

在資料庫領域中也有著同樣的趨勢，上圖是雲資料庫和私有化部署的資料庫軟體的佔比趨勢。大家可以看到，2019年時，雲上的資料庫服務（Database as a Service）還不到傳統資料庫的一半，但今年幾乎接近一樣，可以預見明年一定會超過。所以，雲是毋庸置疑的趨勢，**在未來的資料庫產品中，Cloud 一定會變成資料庫服務的承載平臺**。

## 如何解放開發者的生產力？

這次分享的主題依然是“The Future of Database”，要講的是資料庫的未來會是什麼產品形態。談到這個話題，我的思考習慣是先關注現在資料庫到底有哪些痛點，開發者到底在為什麼煩惱。

![5.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/5_f5295269ca.png)

從這張圖可以看出，開發者、程式設計師、DBA 日常的時間都花在了什麼地方。你會發現他們 39% 的時間在做業務創新、在 Coding，41% 的時間在做基礎設施維護，如買伺服器、部署伺服器、運維等等。這其實非常符合一個開發者的日常體感。有時候作為一個程式設計師，我想要雄心勃勃地做一個新的東西、新的應用時，會發現真正開發那個應用的時間可能只佔整個時間的 10%-20% 左右，**大量時間都花費在買伺服器、部署資料庫、資料的備份恢復、CI/CD 搭建上，而不是在開發應用上面**。

![6.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/6_0bed9de7a1.png)

這張圖來自 a16z（美國一個特別著名的投資機構）在 2020 年底出的一份報告，他們提出了一套包治百病的資料架構“Unified Data Infrastructure”。當時看到這個架構的時候，我覺得它確實包含了我們遇到的各種各樣的問題，這個架構確實能解決問題。**但另一方面，圖中每個框其實都是一套非常複雜的軟體**，這個架構的問題是框特別多、特別複雜，而且這些框之間互相的連線會把事情變得更加複雜。想象一下剛才提到的小例子，我在開發一個應用時要花很多時間去處理這些基礎設施的問題，在這張圖裡，剛才這些不爽的體驗要再乘十或二十倍，因為這些元件之間的連線會帶來更多的複雜性。所以這個架構看起來很美，但實際上我們會花更多的時間去保障系統穩定執行。

綜上所述，**當今把開發者拖慢的最核心原因是開發者的生產力**，如果開發者的生產力提高了，業務創新、應用創新的速度就會變得更快。

![7.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/7_c761db6eb7.png)

OSS Insight 是 PingCAP 自己開發的一個很好玩的 GitHub 資料分析工具，它抓取了 GitHub 上所有的資訊和實時的資料，提供一些資料的洞察服務。這樣一個看起來很簡單、很有意思的小應用，**如果用傳統的思路去構建系統，你就會發現要用一大堆不同的技術棧串聯在一起才能實現，並且每一個技術棧還有著自身複雜的運維成本**。

過去 20 年我們發明了太多的技術，太多不同的 Database，每一種 Database 都有著自己複雜的概念與運維。作為一個開發者，要想把它用好，就需要把這些東西都學習一遍。業界有一句特別真實的笑話：別釋出了，別做新的東西了，我真的學不動了……**這些複雜的概念現在都沒有被隱藏起來，反而全都透傳給了開發者**。舉一個簡單的例子，如果你想在雲上選擇機型，就會發現不同的公有云廠商會有好多機型推薦給你，如 i3.xlarge、i3.2xlarge、i3.4xlarge 等等，這些機型代號背後到底意味著什麼？這都是系統架構的複雜性。

更不要說背後的成本，**如果你在雲上選錯了機型或者選錯了服務，就會發現最後的賬單和你選了正確的機型或者服務有著天壤之別**。最近很火的 FinOps，說白了就是如何科學地利用雲去省錢。這意味著什麼呢？意味著就連計費方式以及篩選的策略對於使用者來說都是非常複雜的事情，複雜到需要用另外一套工具來去做最佳化，以幫助使用者作出正確的決策。

![8.jpg](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/8_923cb0c9a2.jpg)

**我們再往前看一下，今天的開發者到底是怎麼去思考開發應用的？**這裡我想分享一個最近特別喜歡的公司——Vercel，是一個非常偏向於開發者開發流程和體驗的平臺，在它的首頁有三個英文單詞：Develop（開發）、Preview（預覽）和 Ship（上線），這其實就是一個開發者的視角。用過的同學就會知道，在 Vercel 這個平臺上，一個應用開發者只需要關注網站怎麼做，只需要去寫 code。其他的事情，包括髮布、部署、CDN、流量全都由 Vercel 幫忙封裝好了，開發者只需要將 100% 的時間都放在業務邏輯開發上就可以了。這是一個很好的方向，這意味著應用的開發門檻在降低。**未來，應用開發者對資料庫的關注點會從資料庫變成 API，甚至在更長遠的的未來只需要關注 web 前端開發就好了**。

## 用“抽象”解決複雜性

綜上所述，從開發者的角度，或者新一代開發框架的角度來說，開發門檻正在變得越來越低，應用開發者變得越來越多，那資料庫、資料技術、資料處理技術棧，怎麼解決複雜性帶來的矛盾呢？

我覺得解決這個問題的思路可以用一個詞來描述——**Abstraction（抽象）**。為什麼抽象如此重要？抽象怎麼幫我們解決問題？

對於基礎軟體或者軟體開發來說，概念的抽象程度提高，會帶來什麼樣的結果？**第一，架構的複雜性會變得越來越低**。我們想象一下雲，原來沒有云的情況下你可能還要去考慮一下硬體、網路、磁碟、儲存、資料中心的租賃，但有云了之後架構本身的複雜性是降低的，你不需要了解這麼多東西，因為雲底下的東西已經被隱藏掉了。這意味著作為一個開發者來說，他的心智負擔在降低。就像用 Vercel 開發應用的時候你不需要關注 CDN，Vercel 已經解決了 CDN 的問題。心智負擔降低意味著開發者能更快地開發出應用，能花更多的時間專注於業務創新，這就是商業的迭代速度。所以為了解決剛才說的矛盾，我們在資料技術上應該進一步去做抽象。

![9.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/9_f8a1a72329.png)

在聊資料庫的 Abstraction 前，我們可以看另外一個例子——**計算能力的抽象**。上面這個二維圖示中，豎軸是技術的抽象程度，橫軸是商業創新的迭代速度（Go-to-Market Speed），我們用它來看一下剛剛這個理論是不是成立。

圖中左下角是 On-Prem，意味著 20 年前要做一個網站，還要關心買伺服器、租機房、網路租用等，抽象程度很低，**開發者要花大量時間在這些與業務無關的事情上，這也就意味著迭代速度是慢的**。

後來人們是怎麼解決的？**公有云的概念出現了，把剛才那些複雜的硬體、部署、網路等資料中心的複雜性抽象掉了**。你拿到就是一臺機器，它到底是不是真實的機器你不用關心。這時，你要再開發一個應用，只需要在公有云上開個賬號，把應用部署上去，按月給錢就行了。這比起自己去折騰資料中心來說，迭代速度又快了一步。

**再往上看，雲原生的概念出現了**。雲原生的核心計算單元是 Container，Container 是更高層次的抽象。在虛擬機器時代，你依然要去考慮 VM 掛了怎麼辦，但是在 Container 世界裡，Container 以及底下雲的排程器都不用你管，意味著迭代速度更快。

![10.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/10_8a00437db7.png)

在資料庫的世界裡“抽象”是如何去體現的？**抽象程度最低的是雲本身的基礎設施**，比如你要在雲上私有化部署一個資料庫，你需要自己去維護 MySQL 或者 VM。這時候你看到的是雲的基礎設施，它的抽象程度很低。**再往上一層，比如 PingCAP 幾年前要基於雲提供的基礎設施如虛擬機器、S3、容器，去開發出一個叫 TiDB 的資料庫**。TiDB 提供了 SQL 能力，Scalability 能力，以及低延遲、高可用、分散式事務、HTAP、Geo-partition 等等一大堆資料庫核心層面的能力。在這個階段已經有很多使用者說，“哇，TiDB 挺好用的”。

**過去一年中，PingCAP 一直在把這個資料庫技術變成一個資料庫的雲服務，也就是我們在做的 TiDB Cloud**。技術和服務的區別是什麼呢？TiDB 技術本身就像一輛車裡的發動機，或者一個火箭裡的引擎。但是一個發動機跟一輛車肯定不一樣，尤其在雲上。對於一個在雲上想要使用資料庫服務的使用者來說，他需要資料的匯入、資料的匯出、備份、智慧診斷、多租戶各種各樣周邊的東西，**把它們拼裝在一起才是一個服務，而不是給使用者一個發動機讓你自己拼出一輛車**。

這張圖裡有一條虛線，虛線之下作為一個資料庫開發者或者一個資料庫廠商來說，關注點其實是能力或者 feature ，就好比說發動機是不是穩定、是不是快、是不是省油，這些是能力驅動為主的一個抓手，但是在這條虛線之上整個驅動力會變成怎麼去提升使用者體驗。你想要提供服務，就要從使用者使用服務的全生命週期去考慮。比如他剛進來註冊的環節、繫結信用卡的環節、資料匯入的環節、使用、調優、備份的環節，同步到其他資料來源的環節，每一個環節都要去考慮，這裡面考慮的點就是使用者體驗，**使用者體驗是指引這個產品做得更好用的方向**。

## 下一級別的“抽象”是什麼？

**“抽象”再往前一步是什麼？我們給出的答案是“Serverless”**。一個月前 PingCAP 已經發布了 TiDB 的 Serverless 雲服務。如果剛才那個理論是 OK 的，“抽象程度越高，開發的效率越高”，**Serverless 就會變成在雲原生之後新的“抽象”**。對於資料庫來說 Serverless HTAP 是一個更高階別的“抽象”，它意味著更高的開發效率。

可能大家第一次聽到  Serverless HTAP ，這到底是什麼東西？意味著什麼？

![11.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/11_cc3ffe56c2.png)

第一，想象一下如果有這麼一個資料庫，它的**啟動或者建立，你不需要關心任何部署細節**，也不用管有幾個節點，而且它是召之即來，揮之即去的，幾十秒之內就能準備好，一鍵就能建立出來；

第二，這個系統雖然看不見底下的基礎設施，但是它會**跟著業務的負載變化而自動匹配**。比如說你的吞吐大到一定程度，不用再停下來加伺服器，系統會自動進行擴充套件。當你的業務峰值降下來了，比如說雙十一過後業務流量下來了，這個系統還能夠自動地縮回來，甚至縮到 0。能縮到 0 其實很重要，在沒有業務負載的情況下，系統能變成 0 意味著系統不再收錢，而且當有業務流量再過來的時候它也能在很短的時間內又恢復提供服務；

第三，**HTAP Database**。提供了一棧式的 SQL 能力，這是 HTAP 本身的能力；

第四，**Pay-as-you-go**。有的人可能會說公有云不是也是 Pay-as-you-go 嗎？Serverless 跟雲有什麼區別？我覺得二者當然都是 Pay-as-you-go，但是能不能以一個更細的粒度去提供 Pay-as-you-go 的能力？過去我們其實還是按照伺服器、虛擬機器這樣的資源來去看待一個月多少錢，這個服務能不能粒度更細一些，只收業務流量的錢？尤其是對於偏分析的場景來說，有很多時候我們做大資料分析，比如每天半夜要去跑個報表，可能需要一千個虛擬機器算，20 秒鐘算完，然後再縮回來。每天可能就凌晨需要這麼多 OLAP 的伺服器，但是我不可能白天也買這麼多伺服器，就為了晚上算那一下，能不能更細粒度的 Pay-as-you-go，只算 20 秒的錢非常重要。

第五，也是長期以來被各種硬核資料庫開發商忽略的一點，但未來會越來越重要，**一個 Serverless 的 HTAP Database 一定要跟現代的開發者開發應用的過程體驗深度整合**。舉個例子，比如我們在筆記本上開發應用，現在如果有一個召之即來、揮之即去的資料庫，我的開發體驗其實是貫穿於整個開發流程裡的。所以，過去我們其實一直在把資料庫與開發者分開來看。資料庫關注效能、穩定性，各種各樣特別硬核的跑分，但是未來將是從開發者的角度考慮如何去使用資料庫，讓這個資料庫幫助開發者更快、更流暢地構建應用。我覺得對於 Serverless 資料庫來說，很重要的一個課題是從使用者角度看，它應該融入到每天的、現代的開發體驗中。

## TiDB Serverless Tier

![12.jpg](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/12_28a125c2bd.jpg)

聽起來很美好，Does it even possible？**經過大半年的時間，我們終於把這個東西的第一個原型做出來了，並在 11 月 1 號上線公測，這就是剛才說的 [TiDB Serverless Tier](https://tidbcloud.com/free-trial)**。

我自己寫了一個小程式，在一個全新的環境下，透過程式碼啟動一個 TiDB 的 Serverless Tier 例項。在這個過程裡，我只是告訴這個程式，要啟動一個叢集，這個叢集叫什麼名字，然後把密碼一輸，20 秒之後可以直接拿一個 MySQL 客戶端連上去了，這個時間未來會進一步縮短。想象一下，如果縮短到三五秒鐘，這會極大地改變開發應用的使用流程和體驗。而且你不用關心它的擴充套件性，即使上線以後，業務流量變得巨大無比的時候，它也能夠很好地擴容上去，沒有流量的時候，它還能縮回來。

![13.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/13_d375c3dd69.png)

當然它背後其實有很多很多的技術細節，本文我們就不一一細說了。其中我們有一個原則，就是怎麼利用好雲提供的不同的服務，比如 Spot Instances、S3、EBS、彈性的 Load Balancer。TiDB 的 Serverless Tier 背後對於雲上所有的彈性資源都進行了很好的整合，以及巧妙的排程，提供了一個極致彈性的使用者體驗。這個使用者體驗比原來的雲原生資料庫更往前跨越了一步，細節更少，抽象程度更高。

![14.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/14_9c843d72cd.png)

這是系統的設計圖，就不展開太多了，給大家展示一下這個東西還是挺厲害的。

![15.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/15_c8ed753a77.png)

所以，**TL;DR 是存在的，也是有可能被做出來的**。當 TiDB Serverless Tier 上線以後，我們發現它一上線就把整個 TiDB 在雲上的 cost 降低了。拿最小叢集來說，現在對比今年年初，成本降低到 1/5。而且在可見的未來，這個成本會變得更低；第二就是啟動的時間，在今年 3 月份的時候，在雲上啟動一個新的 TiDB 叢集需要 15 分鐘，如果自己部署時間可能更長。現在只要 20 秒鐘，不遠的未來這個時間會縮短到更短。

## 雲端 Serverless HTAP 資料庫服務，意味著什麼？

![16.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/16_a008ec4dc8.png)

第一，**我們一開始花了很長時間去構建了一個穩定的資料庫核心**，可以彈性擴充套件、自動 Failover、ACID Transaction 等非常硬核的基礎能力。但這些都是基礎能力，這些東西應該隱藏在發動機裡。作為一個開車的人，不用關心變速箱裡有哪些特性；

第二，**HTAP 能夠提供實時的一棧式資料服務**。使用者不需要關心什麼是 OLAP，什麼是 OLTP。一套系統可以支撐所有負載，也不用擔心 OLAP 負載影響 OLTP 的正常服務；

第三，基礎設施層面，**Serverless 部署的成本變得極低，極致的 Serverless 不用關心任何運維的細節**。你可以透過程式碼和 open API 控制這些叢集的起停。在擁有更大規模的基礎設施時，這點是非常重要的。Serverless 在處理更復雜或更大系統的時候，能顯著減低複雜性；

第四，**真正的按需計費**。Serverless 能夠真正按照資源的消耗量來去計費。對於開發者來說，想用資料庫的時候，只要招手它就來，不用的時候，也不用給錢，任何時候去訪問它，資料都在那兒，也能對外提供服務。

![17.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/17_63cfa346cc.png)

**在這樣的 Serverless 架構下，我們其實還能解鎖更多的能力、更多的可能性**。

舉個例子，S3 是 TiDB Serverless Tier 底下重度依賴的雲物件儲存服務。用過 S3 的肯定都知道它便宜，可用性很高。更重要的一點是資料共享，比如大家都在用 AWS，A 使用者用 S3，B 使用者部分資料也在 S3 上，比如說我想把我的資料共享給另外一個使用者的時候，既然都在 S3 上，那共享就變得很簡單。以前在私有環境下，你還需要把資料下載出來拷給他，再上傳進去，然後才能做分析。如果是在資料量比較大的情況下，這幾乎是不可想象的。這種新架構的**一種可能性就是真正能夠做到 Data Sharing**，當然這裡面肯定還涉及到包括隱私計算，各種各樣的安全性問題。但從技術底層來說，這種產品形態並非不可能了。

另一種場景，比如說我想做一個區塊鏈的資料分析應用，但做這樣的應用，第一步你得把資料準備好。區塊鏈的資料其實也不小，經常是大幾百 GB 或幾個 TB 的資料。但如果在 S3 上有一個公共的資料集已經準備好了，那**在雲上 Serverless 使用者只需要在啟動的時候，載入這部分資料就好了**。這些能力在雲下是根本不可能完成的任務。

![18.png](https://www-website-strapi.oss-cn-shanghai.aliyuncs.com/prod/18_dbfc30531d.png)

這些能力具備後，資料庫的商業模式會變成什麼樣子？在去年的 DevCon 上，我提出了一個猜想，“資料庫作為一個軟體形態本身會消亡，而資料庫的平臺化、微服務化會取代原來的資料庫軟體形式”。這個理論正在變成現實，今天，我們可以看到幾乎所有的資料庫廠商，都在雲上提供服務。

## 更進一步

未來再往前一步，會發展成什麼樣子？

**Serverless 其實是雲上 Database Service 更進一步產品形態的體現**。現在我可能還需要去關注買多少個資料庫節點，買多少個叢集，但是在未來，真正從開發者的角度來說，他所關心的應該只有資料操作的 API ，這一層才是離業務更近的東西。另一方面，**當 Serverless 在雲上被提供後，資料共享、交換就變成了一個很自然或者很簡單的事情，那時候我覺得會出現一個叫做 Data market 的新商業模式**。

記得我在上大學學資料庫課程的時候，我的老師告訴我，這個東西很簡單，你只要會寫 SQL 就 OK 了。但我工作以後，發現還有 OLTP、OLAP、時序資料庫、圖資料庫，以及各種各樣稀奇古怪的資料庫，你得學習一大堆東西，這些東西里面有無數的細節。

**我們想把它做得很簡單，把開發者的體驗帶回從前**。資料庫本來就應該是很簡單的東西，我們應該花更多的時間關注於業務的創新、關注於真正重要的事情，這些複雜的東西，就讓它簡單起來好了。

未來真正重要的東西是什麼？**是流暢的開發體驗。這就是我們終極的前進方向**，也是作為一個基礎軟體提供商的擔當。雖然前面說了這麼多很技術的東西，但其實 Serverless 很簡單，現在它已經變得觸手可及，大家可以透過 TiDB Cloud 就可以立刻體驗它。

黃東旭：開發者的技術無感化時代從 Serverless HTAP 資料庫開始

相關文章