本文根據(jù)黃東旭在 PingCAP D 輪融資線上發(fā)布會的演講實錄進行整理。

TiDB 的現(xiàn)在和未來

大家好，我是黃東旭，是 PingCAP 的聯(lián)合創(chuàng)始人和 CTO，這是 PingCAP 成立以來的第一次發(fā)布會，我想跟大家簡單聊聊 TiDB 在產(chǎn)品和技術上的更新。考慮到線上的很多觀眾不一定是有很強的技術背景，我將盡我所能將技術的部分說得讓大家都能夠理解。

在講正題之前有一個小故事，我們做基礎軟件的產(chǎn)品經(jīng)理去跟客戶聊需求的時候，客戶經(jīng)常都會說：對于數(shù)據(jù)庫，我的要求特別簡單、特別基礎、非常樸素，我不要求很多功能，安全穩(wěn)定是必須的，最好能高可用，性能一定要好，如果數(shù)據(jù)量大了，能實現(xiàn)彈性伸縮就更好了；另外，最好別讓我學太多新東西，用起來跟過去使用的產(chǎn)品差不多，這就是一款完美的數(shù)據(jù)庫產(chǎn)品。

就像大家在家里用自來水一樣，我們對自來水的需求就是擰開水龍頭水就能出來，但是背后自來水廠是怎么處理的大家不用知道，我們只需要根據(jù)實際情況使用冷水或者熱水就好。但是從技術的角度來說，剛才類似冷熱水這個非常樸素的基礎需求，類比一下放到數(shù)據(jù)庫的世界這就是一個圖靈獎級別的基礎需求，稍微解釋一下圖靈獎是計算機行業(yè)學術界最頂級的，相當于計算機界的諾貝爾獎。

這里有兩位行業(yè)泰斗級的人物，左邊 Leslie Lamport 在 2013 年研究相關問題拿了圖靈獎，右邊這位跟我們挺有緣的，發(fā)型跟（我們的 CEO）劉奇同學挺像，他是 UC 伯克利分校的一名教授，也是著名 CAP 定理的提出者，PingCAP 中的 CAP 就是來源于此。雖然看上去這個需求是一個很樸素的需求，但是這是一個值得去花很長時間研究，在技術領域很有挑戰(zhàn)，也是一個很前沿的研究領域。

在聊數(shù)據(jù)庫之前，我想帶大家回顧一下十年前的電子產(chǎn)品，回顧一下我們當年的生活，大家回想一下十年前我們手上的數(shù)碼產(chǎn)品有哪些，比如我們打電話有諾基亞，拍照有數(shù)碼相機，也有用來做導航的獨立設備 GPS，聽歌用的 MP3 等等，種類繁多。

我們再來回顧一下這十年，這些東西好像在我們的生活中漸漸消失掉了，一臺智能手機把很多這些碎片化的東西統(tǒng)一了起來，我覺得這背后一個很重要的點就是我們對于統(tǒng)一用戶體驗的追求驅(qū)動了整個科技界產(chǎn)品發(fā)生翻天覆地的變革，現(xiàn)在一臺智能手機基本解決了我們生活中百分之七八十的數(shù)字化生活場景的需求。

TiDB 是一個 HTAP 系統(tǒng)

接下來進入正題，PingCAP 是做數(shù)據(jù)庫的廠商，如果我們拉一條數(shù)軸來看，左邊的業(yè)務是更偏實時在線的業(yè)務，如果這條數(shù)軸的右邊是離線業(yè)務的話，按照這個數(shù)軸來看，數(shù)據(jù)庫這個產(chǎn)品大家可能印象中是在左邊的，一些典型場景，比如像 Hadoop 或者一些數(shù)據(jù)倉庫、報表是在右邊。

再看一個具體的業(yè)務場景，假設是一個公司要打造電商平臺的 IT 系統(tǒng)，梳理一下現(xiàn)在電商平臺內(nèi)部有各種各樣的應用和場景，我們按照這些場景放到這個數(shù)軸上，左邊是在線，右邊是離線，我們看到比如交易、訂單管理、明細查詢，這可能是偏在線的業(yè)務，用戶用手機隨時可以打開看；右邊離線業(yè)務更像是內(nèi)部運營人員，比如老板查看去年賺了多少錢，這種報表可能是一個更偏離線的業(yè)務。

大家有沒有發(fā)現(xiàn)中間有一些實時的報表，實時的促銷調(diào)價，熱銷產(chǎn)品的推薦，你放在左邊不合適，放在右邊好像也不太對，所以中間部分是一個比較模糊的狀態(tài)，這是一個業(yè)務的語言，比如我們把這個業(yè)務放到這條軸上去看，比如說我是電商平臺的技術人員，業(yè)務人員告訴我，我們上面這些需求，這些需求翻譯成技術的語言會變成什么樣子呢？

就變成了各種各樣的 OLTP 數(shù)據(jù)庫和 OLAP 數(shù)據(jù)庫和數(shù)據(jù)倉庫，比如像 ClickHouse、Greenplum，像離線的數(shù)據(jù)倉庫 Hadoop、HIVE，有很多同學不了解這些名詞沒關系，我只是想展現(xiàn)一下，業(yè)務需求翻譯成技術語言，通常需要一系列復雜的數(shù)據(jù)技術棧來支撐。

可能有很多觀眾學過計算機技術，我記得我在上大學的時候，我們有一門課是叫數(shù)據(jù)庫系統(tǒng)，老師上課的時候教我數(shù)據(jù)庫就是增刪改查，就是存數(shù)據(jù)、取數(shù)據(jù)的一個系統(tǒng)、一個軟件，幾個關鍵的命令 INSERT\SELECT\UPDATE\DELETE，我回憶了一下好象也沒有教哪些場景是 OLTP 的場景，哪些是 OLAP 的系統(tǒng)，并沒有這么復雜。

數(shù)據(jù)庫應該就是存數(shù)據(jù)、取數(shù)據(jù)天經(jīng)地義，就像水龍頭一樣一擰開就出水，我還特地查了一下 database 的定義，在維基百科上面的定義其實并沒有說 OLTP 的 database 或者 OLAP 的 database。

我知道這可能是一個細分的領域，但是從數(shù)據(jù)庫這個詞的本源來看，本質(zhì)上像一個容器一樣，存儲數(shù)據(jù)和取數(shù)據(jù)的一個系統(tǒng)，好像也沒什么復雜。

為什么今天很多工程師，很多用戶就覺得這個數(shù)據(jù)庫或者這個場景一定是個 OLTP，或者是個 OLAP ，要有一個涇渭分明的分類。就像剛才電商的例子，其實有大量中間的場景很難說到底是一個 OLTP 還是 OLAP 。但是現(xiàn)在的現(xiàn)實是對于很多 IT 系統(tǒng)、業(yè)務系統(tǒng)來說，對于實時性的要求越來越高，為了解決這個問題，我們構建了各種各樣的數(shù)據(jù)孤島，構建了各種各樣的煙囪式系統(tǒng)。

所以過去這種涇渭分明式的分類方式到底適不適用現(xiàn)在有越來越多實時性要求的時代呢？

回過頭來思考這個分類是不是有問題的時候，作為一個理工男或者作為一個學理科出身的工程師，我們特別喜歡尋找一個定義或者尋找一個分類。我們找遍了各種各樣的定義，從學術界、工業(yè)界、到各類咨詢機構，發(fā)現(xiàn) HTAP 是一個更加符合或者說更加適合現(xiàn)在 TiDB 應用場景的一個定義。

TiDB 的定位是一個 Real-Time 的 HTAP 系統(tǒng)，有很多朋友后來問我，TiDB 是一個 HTAP 系統(tǒng)，是不是就意味著你不是一個 OLTP 系統(tǒng)，或者說你到底是一個 OLTP 還是 OLAP？

我們回到智能手機的那個例子，首先智能手機一定是一個 100% 的手機，肯定能打電話，在打電話的基礎上再加上很多其他的常用功能，比如相機、GPS、MP3等在一個系統(tǒng)里面搞定。我想強調(diào)的是 TiDB 的定位就是 Real-Time HTAP 系統(tǒng)，首先是一個 100% 的 OLTP 系統(tǒng)，同時還能支持一些 Real-Time OLAP Query。

講到 TiDB，我其實很感慨，我一直看著這個產(chǎn)品一步步成長起來，最近這一年成長速度尤其快，現(xiàn)在我很高興地看到 TiDB 4.0 已經(jīng)成為社區(qū)的一個主流版本。

在 4.0 發(fā)布的時候，我當時很熱情洋溢的發(fā)表了一段話，說這是一個非常具有里程碑意義的一個版本，事實上 TiDB 4.0 的表現(xiàn)我覺得是不負眾望的，現(xiàn)在大家都非常喜歡，成為了主流。

展望 TiDB 5.0

我想跟大家展望一下 TiDB 5.0，在講 5.0 之前我想稍微強調(diào)一下 TiDB 做產(chǎn)品的思路。我們都是工程師出身，也比較接地氣，不說什么高大上的，用大白話來說就四點：穩(wěn)、快、好用和用著放心。前面提到過用戶對于一個數(shù)據(jù)庫產(chǎn)品的樸素需求，我們也是希望按照這種方式來做產(chǎn)品。

但在 TiDB 5.0 里面我們真正把一個具體的目標放到了產(chǎn)品規(guī)劃的方向里面，那就是 TiDB 要走向各行各業(yè)的核心場景。之前，TiDB 從 2.0 到 3.0 和 4.0，已經(jīng)開始慢慢地走向了各行各業(yè)，慢慢地滲透到一些對穩(wěn)定性、對性能要求非常極致的場景，包括金融、銀行的一些核心業(yè)務系統(tǒng)。

在 TiDB 5.0 這個版本，我們第一次明確地提出，至少在產(chǎn)品層面上要達到各行業(yè)核心場景對于數(shù)據(jù)庫性能和穩(wěn)定性的要求。

接下來具體談談 TiDB 5.0 在這幾個方面的進展。

首先第一點穩(wěn)定性，我經(jīng)常說一句話：把一個東西做對其實是很難的，把一個數(shù)據(jù)庫做出來不難，做對卻很難，所以我們構建了各種各樣的正確性的測試系統(tǒng)。現(xiàn)在 TiDB 已經(jīng)做出來了，下一個階段是更穩(wěn)，但是要使得 TiDB 更加穩(wěn)定還有很多的工作要做，這方面沒有捷徑，道理誰都懂，魔鬼在細節(jié)，只有做得越來越深，越來越細，我很高興的看到，在 TiDB 5.0 中我們和用戶一起把 TiDB 的穩(wěn)定性又往前推進了一個級別。

下圖是 5.0 在某個券商機構的測試結果，在 48 小時高壓力的測試場景里面 TiDB 5.0 的系統(tǒng)抖動一直小于 5%，同時在性能上跟 4.0 相比有明顯的提升。我想強調(diào)的是在做穩(wěn)定性這件事情上，已經(jīng)開始進入改革深水區(qū)，低垂的果實已經(jīng)摘的差不多了，剩下就是一些場景和技術上比較硬的難題等著我們?nèi)スタ?，我們很高興地看到 5.0 對于 4.0 在穩(wěn)定性上有比較出色的表現(xiàn)。

第二，性能快。天下武功，唯快不破，尤其是對于數(shù)據(jù)庫這樣的基礎軟件來說，特別是在一些核心應用場景，比如像銀行的一些核心交易系統(tǒng)，一個毫秒的額外延遲可能就會對整體的系統(tǒng)和用戶體驗造成影響。

在 TiDB 5.0 里面我們很高興地看到，對比 4.0 延遲幾乎成倍地下降。這讓我想到跟開發(fā)團隊經(jīng)常開的玩笑，說 TiDB 每個版本有點像摩爾定律，每一個版本比上一個版本性能提升一倍、延遲下降一倍、成本不變，未來成本還會持續(xù)下降。我很高興看到 5.0 還是保持著這個規(guī)律，所以，性能快與延遲降低在 5.0 里面會是一個很重要的標簽。

快的另外一個方面，首先熟悉 TiFlash 的同學看到標題肯定會心一笑，我們之前有提到 TiDB 是一個 Real-Time HTAP 架構，AP 這部分是由 TiFlash 分析加速引擎來提供服務的。在 5.0 里面 TiFlash 將支持分布式的聚合和分布式的計算（MPP），能讓整個 TiDB 的 OLAP 能力真正延伸到更多的應用場景，應對更多更復雜的 JOIN 場景。

好用，這個方面我想強調(diào)的有兩點。

首先，大家看到跨數(shù)據(jù)中心、跨地域一個部署，很多做分布式系統(tǒng)的同學會覺得很興奮，TiDB 終于可以支持做 Geo-Partition（多地多活跨地域數(shù)據(jù)分布） 。我稍微解釋一下，TiDB 是一個分布式數(shù)據(jù)庫，所以有很多用戶、很多開發(fā)者希望 TiDB 可以實現(xiàn)真正的跨長距離或者跨多個數(shù)據(jù)中心的部署，可以在全國或者全球都組成一個大的網(wǎng)絡。

其次，打通多個流行數(shù)據(jù)處理棧生態(tài)和提供全鏈路追蹤系統(tǒng)，也將使得 TiDB 5.0 變得更加好用。

提到 Geo-Partion，實際上，有很多客戶有這樣的場景需求，特別是對于一些海外客戶，比如一家歐洲公司的業(yè)務遍布全球，這時候如果有一個數(shù)據(jù)庫系統(tǒng)，能夠支持全球跨長距離的區(qū)域部署，能夠在不同的國家、不同的位置隨時提供服務，運維方面也省去了部署多套技術棧和數(shù)據(jù)庫系統(tǒng)的成本，這對于客戶來說就是一個理想之選。

舉個例子，我們剛才提到多地部署，怎么降低本地的延遲，如果是一個歐洲公司，大家知道歐洲有很嚴格的 GDPR，企業(yè)的數(shù)據(jù)不能出境，這種場景下 Geo-Partition 就是一個非常實用的特性。

如果是現(xiàn)在的 TiDB 去做這件事情，比如說在歐洲、中國、美國同時提供服務，在一些場景下的數(shù)據(jù)庫性能和延遲可能會不太理想，因為需要到一個中央的服務器上去處理，去拿時間戳，然后才能提供服務。

在 TiDB 5.0 里面，我們將中央的授時服務改成了一個分布式授時的服務，能夠讓這個系統(tǒng)在本地或者在多數(shù)據(jù)中心場景里面的性能表現(xiàn)更佳。

第二個方面是 TiDB 的“朋友”越來越多，作為一個基礎軟件，雖然 TiDB 的目標是盡可能的把很多場景統(tǒng)一，但我覺得 TiDB 跟業(yè)界其他生態(tài)技術棧的互聯(lián)互通也是一個非常重要的方面。

現(xiàn)在對于 TiDB 來說，已經(jīng)能夠與 Flink、Kafka、Spark，包括 Hadoop、AWS S3 以及 MySQL、Oracle 這些傳統(tǒng)的數(shù)據(jù)庫進行互聯(lián)互通。

舉一個具體用戶的例子，這是一個在線的實時數(shù)倉業(yè)務，線上的業(yè)務持續(xù)在做交易，在做寫入，同時這些數(shù)據(jù)通過 TiDB TiCDC 增量訂閱模塊輸出到 Kafka，同步到 Flink 流式計算引擎去做歸納、聚合與分析，然后再重新寫回到 TiDB。寫入到 TiDB 的這些數(shù)據(jù)再去對在線業(yè)務進行補充，TiDB 結合 Kafka、Flink 組成了一個簡單易用的實時數(shù)倉架構。

說到安全，對于數(shù)據(jù)庫來說，安全其實是非常重要的，在我們的產(chǎn)品規(guī)劃里面，安全是放在很高優(yōu)先級的特性。

我想強調(diào)，在 4.0 里面 TiKV 存儲層已經(jīng)支持全鏈路的數(shù)據(jù)透明加密。在 DBaaS 平臺里面，我們正在引入 RBAC，就是基于用戶身份的鑒權系統(tǒng)，同時我們會跟 AWS 的身份認證系統(tǒng)進行打通，給用戶提供更加安全、更加可靠的產(chǎn)品與服務保障。

在安全合規(guī)方面，隨著 TiDB 越來越多地應用在國內(nèi)、國外一些關鍵的業(yè)務場景，不同的國家，不同的應用場景對于合規(guī)的要求呈現(xiàn)多樣化特點， TiDB 已經(jīng)通過了 SOC2Type1 認證，這是在美國金融行業(yè)里面非常認可的合規(guī)標準，未來我們將在合規(guī)上面投入更多的精力。

未來的數(shù)據(jù)庫是什么樣子？

前面是對于 TiDB 5.0 在現(xiàn)在這個時間點的進展同步。但是未來在哪里？

我們每一個分享最后的部分會講講到底未來應該是什么樣子的，我覺得在比較近的未來，TiDB 一個重要的方向是更加云化。為什么云如此重要？數(shù)據(jù)庫云化的背后我覺得可以展開幾點：

• 一個是 Severless；

• 二是智能的調(diào)度能力；

• 第三是利用云的基礎設施降低成本。

為什么說云如此重要？大家可以看到右邊這張圖，橫軸是數(shù)據(jù)量和業(yè)務需求，縱軸是企業(yè)在 IT 上投入的成本，在云誕生之前我們在去做面向不確定性的業(yè)務，面向暴漲的數(shù)據(jù)量，如果采用傳統(tǒng)的 IDC 部署方式，成本和投入的曲線跟實際的需求不能完全吻合，其實存在很多資源的浪費。

首先，只有云真正把整個基礎軟件的商業(yè)模式變成了 pay as you go，盡可能地貼合業(yè)務的增長曲線，對于數(shù)據(jù)庫這樣很重要的基礎軟件來說，在云上利用云的彈性能夠去更合理地滿足業(yè)務的實際需求。

第二，云很好地屏蔽了底層基礎架構實現(xiàn)的復雜性，對于做基礎軟件的人來說，這具有劃時代的意義。比如說利用云的彈性調(diào)度能力以及一些 AI 新技術，使得這個系統(tǒng)更好地理解業(yè)務的需求，更加智能地規(guī)劃該把數(shù)據(jù)放置在什么地方，該建立什么樣的索引。

第三，云是很好的基礎設施，面向云時代的基礎設施如何去設計下一代的基礎軟件，我覺得是一個很重要的課題。最近關注技術圈的朋友，Snowflake 的消息令大家非常振奮，Snowflake 在技術上的選擇也帶給我很多啟發(fā)，怎么通過云的基礎設施來打造新一代的基礎軟件。

以上是我對近期未來的一些展望和看法。最后我想強調(diào)的是，回歸初心我們想做的事情就是讓數(shù)據(jù)庫真正回歸原本的樣子，把復雜性隱藏在背后，為用戶提供一個使用門檻很低，解放大家生產(chǎn)力的好產(chǎn)品，謝謝大家！