The Future of Database2022 | 黃東旭新番_風聞

12 月 1 日，以"去發現，去挑戰"為主題的 PingCAP DevCon 2022 主論壇上，PingCAP 聯合創始人兼 CTO 黃東旭，在大會上分享了“The Future of Database”的主題演講。

2022年底的預測，黃東旭給出的關鍵詞是：Frictionless Developer Experience，“技術無感化”。

“過去我們其實一直在把數據庫與開發者分開來看。數據庫關注性能、穩定性，各種各樣特別硬核的跑分，但是未來將是從開發者的角度考慮如何去使用數據庫，讓這個數據庫幫助開發者更快、更流暢地構建應用。”他在接受媒體採訪時表達。

得出這一預測的前提是：過去一年中，**TiDB的發版節奏和模型發生了變化。這也是基於去年的判斷——雲的意義在於加速軟件的迭代速度，**大半年時間 TiDB Cloud 已經進行了超過 34 次迭代，增加了上百個功能特性和改進。這個迭代速度比 TiDB 內核本身的迭代速度更快。

以下是為你梳理了黃東旭分享中的要點，以及在隨後媒體羣訪中的觀點：

1、廣義上的開發者包括架構師、開發者、DBA，但數據庫軟件的真正用户是應用開發者。

2、2023年，雲上數據庫可能會超過傳統數據庫，未來數據庫產品中，雲一定會變成數據庫服務的承載平台。

3、基礎設施維護（買服務器、部署服務器、運維）時間仍然佔據一個程序員新開發應用過程中40%以上的時間。真正開發應用的時間只有10%～20%。以及數據架構組件之間的連接非常複雜，需要更多時間保證系統穩定運行。

如果用傳統的思路去構建系統，你就會發現要用一大堆不同的技術棧串聯在一起才能實現，並且每一個技術棧還有着自身複雜的運維成本。過去 20 年我們發明了太多的技術，太多不同的 Database，每一種 Database 都有着自己複雜的概念與運維。作為一個開發者，要想把它用好，就需要把這些東西都學習一遍。複雜的概念現在都沒有被隱藏起來，反而全都透傳給了開發者。公有云廠商會有好多機型推薦給你，如 i3.xlarge、i3.2xlarge、i3.4xlarge 等，這些機型代號背後到底意味着什麼？這都是系統架構的複雜性。如果你在雲上選錯了機型或者選錯了服務，就會發現最後的賬單和你選了正確的機型或者服務有着天壤之別。

**Vercel，**是一個非常偏向於開發者開發流程和體驗的平台，在它的首頁有三個英文單詞：Develop（開發）、Preview（預覽）和 Ship（上線），這其實就是一個開發者的視角。用過的同學就會知道，在 Vercel 這個平台上，一個應用開發者只需要關注網站怎麼做，只需要去寫 code。其他的事情，包括髮布、部署、CDN、流量全都由 Vercel 幫忙封裝好了，開發者只需要將 100% 的時間都放在業務邏輯開發上就可以了。這是一個很好的方向，這意味着應用的開發門檻在降低。未來，應用開發者對數據庫的關注點會從數據庫變成 API，甚至在更長遠的的未來只需要關注 web 前端開發

Abstraction（抽象）程度提高，架構的複雜性會變得越來越低。雲不再讓開發者考慮硬件、網絡、磁盤、存儲、數據中心的租賃，開發者的心智負擔降低。

4、計算能力的抽象方面，公有云的概念出現了，把剛才那些複雜的硬件、部署、網絡等數據中心的複雜性抽象掉了。你拿到就是一台機器，它到底是不是真實的機器你不用關心。這時，你要再開發一個應用，只需要在公有云上開個賬號，把應用部署上去，按月給錢就行了。這比起自己去折騰數據中心來説，迭代速度又快了一步。

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

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

你想要提供服務，就要從用户使用服務的全生命週期去考慮。比如他剛進來註冊的環節、綁定信用卡的環節、數據導入的環節、使用、調優、備份的環節，同步到其他數據源的環節，每一個環節都要去考慮，這裏面考慮的點就是用户體驗，用户體驗是指引這個產品做得更好用的方向。

**7、“抽象”再往前一步是什麼？我們給出的答案是“Serverless”。**對於數據庫來説 Serverless HTAP 是一個更高級別的“抽象”，它意味着更高的開發效率。Serverless 跟雲有什麼區別？我覺得二者當然都是 Pay-as-you-go，但是能不能以一個更細的粒度去提供 Pay-as-you-go 的能力？過去我們其實還是按照服務器、虛擬機這樣的資源來去看待一個月多少錢，這個服務能不能粒度更細一些，只收業務流量的錢？尤其是對於偏分析的場景來説，有很多時候我們做大數據分析，比如每天半夜要去跑個報表，可能需要一千個虛擬機算，20 秒鐘算完，然後再縮回來。每天可能就凌晨需要這麼多 OLAP 的服務器，但是我不可能白天也買這麼多服務器，就為了晚上算那一下，**能不能更細粒度的 Pay-as-you-go，只算 20 秒的錢非常重要。**對於Serverless數據庫來説，很重要的一個課題是從用户角度看，它應該融入到每天的、現代的開發體驗中。

8、TiDB Serverless Tier， 11 月 1 號上線公測，我自己寫了一個小程序，在一個全新的環境下，通過代碼啓動一個 TiDB 的 Serverless Tier 實例。在這個過程裏，我只是告訴這個程序，要啓動一個集羣，這個集羣叫什麼名字，然後把密碼一輸，20 秒之後可以直接拿一個 MySQL 客户端連上去了，這個時間未來會進一步縮短。其中我們有一個原則，就是怎麼利用好雲提供的不同的服務，比如SpotInstances、S3、EBS、彈性的LoadBalancer。TiDB的ServerlessTier背後對於雲上所有的彈性資源都進行了很好的整合，以及巧妙的調度。當 TiDB Serverless Tier 上線以後，我們發現它一上線就把整個 **TiDB 在雲上的 cost 降低了。拿最小集羣來説，現在對比今年年初，成本降低到 1/5。**而且在可見的未來，這個成本會變得更低；第二就是啓動的時間，在今年 3 月份的時候，在雲上啓動一個新的 TiDB 集羣需要 15 分鐘，如果自己部署時間可能更長。現在只要 20 秒鐘，不遠的未來這個時間會縮短到更短。

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

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

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

**Serverless 其實是雲上 Database Service 更進一步產品形態的體現。**現在我可能還需要去關注買多少個數據庫節點，買多少個集羣，但是在未來，真正從開發者的角度來説，他所關心的應該只有數據操作的 API ，這一層才是離業務更近的東西。

同時，附上記者採訪過程中的QA摘要：

Q：什麼是“技術無感化”？

**黃東旭：**雲原生的下一步是Serverless，這背後的一個核心的邏輯在於阻礙數字化轉型進一步深入的很重要的原因是開發效率，所以我們提出了一個概念，叫技術無感化。

技術無感化對於技術軟件來説，核心的就是如何能夠去通過更高層次的抽象，去把數據庫本身這種軟件的複雜性一步一步地降低，使得未來的開發者對具體的技術幾乎都不需要感知，然後就能夠去把這個東西用起來。

在用户體驗上，越來越簡單。

一方面不特別強調數據庫的硬核性能、跑分，這些極端場景一般用不到。另一方面，雲提供的基礎能力可以讓很多東西變成可能，雲原生架構枷鎖了更多能力（Data Sharing）。

Q：Serverless如何改變TiDB的使用場景？

**黃東旭：**Serverless它是一個產品的形態，但是它並不改變數據庫本身的feature。

第一，首先TiDB 本身還是一個 HTAP 的database。HTAP 意味着什麼呢？

你是一個電商，你做個電商的網站，肯定要有庫存、有訂單、有支付是吧，就這些系統其實都是對在線交易要求很高，數據不能丟，數據不能錯，7x24小時不能停機。這種叫OLTP 的scale 的場景不會因為它是或者不是 Serverless 就有什麼區別。

另外一種場景可能是HTAP。假設我是這個電商公司的老闆。我就想看今天到現在為止我這一天賣了多少錢。你知道就這麼簡單的一個需求，在過去你可能要搭無數的系統，才能完成這個東西，而且一旦你的這個老闆想看的報表是實時的，這個報表實時有些什麼變化，HTAP場景其實就是説，你不需要推倒再來，你直接可以在一個系統繼續做在線的支付交易，同時能夠讓你直接在上面去做實時的分析。電商只是個例子，其他各行各業吧，都有類似的這種場景，比如説像區塊鏈的數據分析。

疊加在這兩種場景之上，如果有了Serverless， 你完全不用關心底下基礎設施。雙11的峯值來了，自動就幫你把他系統擴上去，讓你支撐這個業務。然後雙11過了，它自動就縮回來。它只收你雙11那天的錢。

關於實時分析，比如説你一天就分析三秒鐘，Serverless不會改變本身數據庫的應用場景，而是去改變數據庫在價值交付裏面的粒度。同時降低使用門檻。

Q：Serverless的技術難點究竟是在哪裏？

**黃東旭：**很多數據庫在走向Serverless或者走向雲原生這一步犯了第一個，或者説最致命的錯誤，**雲上的數據庫不能夠直接把雲下的架構搬到雲上，這是完全錯的，**這樣你沒有辦法去利用雲上面提供的一些很好的能力。

所以這裏面第一個難點就是你怎麼能夠充分地去利用雲給你提供的service。比如説你在雲上你不應該去自己做存儲引擎。

核心的一個理念就是你多充分的去利用雲給你提供的服務。

第二個難點就是在雲下的時候，原來我們是一個數據庫的提供商，我們只要關心技術，數據庫軟件做好了就好了，但現在**雲上第二個難點就是，我們既是數據庫服務的開發者同時又是運營者。**這兩塊的技術的要求其實很不一樣的。你做出來不難，但是你怎麼把它運營好？

第三個難點是雲上的賬單如何設計好。

歸根結底我覺得核心的難挑戰就在於你要基於雲作為最底層的基礎，假設去開發個全新的東西。你過去學習到的所有的雲下去開發數據庫的幾乎所有經驗技巧全都要扔掉，你在雲上其實在做一個新的東西。

Q：關於私有云、公有云和Serverless的關係。

**黃東旭：**不管公有云還是私有云的環境下，Serverless解決的是能夠多細的粒度去利用硬件的基礎設施的這個問題，如果你就只有三台機器，那什麼雲原生不原生就無所謂。但當你有3000台機器的時候，升至300台機器的時候。你會看到提升個10%的利用率，對於企業來説都是很大的一個進步，這個跟公有云私有云無關。

Q：目前我們已經從11月份開始就公測了。現在我們的客户畫像大概是一個什麼樣的？什麼樣的人會用我們？

黃東旭:我覺得這個問題很有意思，我自己也在觀察。我發現現在的這個Serverless的這種用户，他基本上都不是數據庫的專家。都是我要在上面做個應用啊，我要快速搭一個電商，其實這才是我們真正覺得未來應該去使用Serverless數據庫的用户，而不是那些企業的DBA或者企業的基礎架構工程師。

Q：開源與對於數據庫未來趨勢預測之間的關係是什麼？

黃東旭: 開源其實是用户選擇你的一個基礎。但再往前走，如果這個用户或者説未來的這個開發者，他就是土生土長長在雲上的一個用户，那開源對於他的重要性，我覺得沒有一些真正的大的企業對開源這麼重要。其實開源這個價值對於不同的客户羣體來，有些部分是不一樣的，有些是一樣的，比如説剛才説的簡單易用、便宜，這個是一樣的，我今天的預測是選擇一些更普實的產品價值去講。

Q：DBA羣體的發展趨勢可能是怎樣的？

**黃東旭：**DBA 可能短期還不會消失吧，但是從大的方向上來説，以後編程這件事情會變得越來越簡單。就是我們這代人在學習的東西，或者説我們的同行在學的東西，可能在未來，全世界也就這些人知道了，就咱們這一小波人知道了。再過十年、再過20年，下一代的開發者，他可能看待編程的方式跟我們現在是完全不一樣的。就比如説你現在回頭去看30年前寫程序的人，他們當時為什麼要要用彙編語言？要用機器碼來寫程序？為什麼要打孔啊？所以我覺得第一點就是編程會變得越來越簡單，我們怎麼給未來的這些程序員去設計系統？未來的程序員不會了解數據庫的，我覺得因為這個東西太複雜了，我認為的趨勢是這樣的。

Q：如何理解API會成為未來兵家必爭之地？

**黃東旭：**我覺得數據庫廠商是肯定會在上面去佈局的。因為你想數據再往上一層，用户怎麼去用它？現在其實都是數據庫的語言，SQL其實嚴格來説是數據庫的語言。但是你從來沒有見過一個應用開發他會直接把 SQL直接寫在它的應用的code裏，你還是要中間經過一層這個離應用更近的建模的方式。

但是呢，第一，現在沒有統一的行業或者事實標準，當然有一些 particle。比如説你現在做一個後端開發，你天天在做的是什麼事情呢？我底下搞個數據庫，把數據存進去，用 SQL 把這個數據撈出來，封裝成個 API給應用層，程序員天天都在幹這個事情。所以這個背後的邏輯很簡單，就是我怎麼去把這些開發者每天的日常重複的勞動和重複的工作隱藏掉。數據庫擴容縮容部署這些東西，已經被Serverless 隱藏掉了。那下一步大家花的時間一定是在業務上。業務經常在乾的一些無意義的事情會被隱藏掉，但這個隱藏掉是數據庫廠商去提供呢？還是其他什麼公司去提供的，這不好説，但是我覺得下一步這方面會有一些進展。

Q：如何理解您所説的“抽象”？

**黃東旭:**這裏的抽象指的是能夠把數據庫底層的跟業務不相關的概念也隱藏掉。我覺得第一個抽象就是把服務器這個節點的概念抽象掉。抽象成什麼呢？抽象成 QPS 、TPS 流量這些業務指標；第二層的抽象，對於用户來説，比如像賬單計費在過去其實是一套很複雜的系統，包括容量規劃或者計費規則。我能不能簡單到就像打出租車一樣？我坐多長時間就給多少錢，這也是一種層次的抽象。其實對於用户來説，這個抽象層數是最高的，但是底下供應鏈的細節你不應該暴露給客户吧？

**所以我覺得我剛才指的這個抽象的意思就是用户在做業務的過程中不要考慮的就把它隱藏起來。換成另外一個概念，或者把更好理解的概念暴露給用户，這種叫抽象。**比如説一個節點掛了，你還要告訴用户説，你要手動去把這個服務器的數據導到另外一台機器上再啓動起來，這個就不叫抽象了。這個節點掛了，你無感，後面都處理完了，用户沒有感知，這個叫抽象。