我還清楚記得，五年前的這個時候，當時還在豌豆莢，午後與劉奇和崔秋的閒聊關於未來數據庫的想象，就像一粒種子一樣，到了今天看起來也竟枝繁葉茂鬱鬱蔥蔥，有點感慨。按照慣例，五年是一個重要的節點，沒有十年那麼冗長，也沒有一兩年的短暫，是一個很好的回顧節點，就在此認真的回顧一下過去，展望一下未來。
五年前創業的出發點其實很樸素：做一個更好的分佈式數據庫。從學術的角度上看起來，並不是提出了什麼驚天地泣鬼神的神奇算法，我們選擇的 Shared-nothing 的架構其實在當時的業界也不是什麼新鮮的事情了，但真正令我激動的是：我們要造的是一個真正能作爲整個系統的 Single Source of Truth 的基礎軟件。這句話怎麼理解呢？我在後邊會好好聊聊。
數據是架構的中心
作爲一個互聯網行業的架構師，幾乎是天天都在和各種類型的數據打交道，這麼多年的經驗，不同行業不同系統，從技術層面來說，抽象到最高，總結成一句話就是：
數據是架構的中心。
仔細想想，我們其實做的一切工作，都是圍繞着數據。數據的產生，數據的存儲，數據的消費，數據的流動……只不過是根據不同的需求，變化數據的形態和服務方式。計算機系的同學可能還記得老師說過的一句話：程序 = 算法 + 數據結構，我這裏斗膽模仿一下這個句式：系統 = 業務邏輯 x 數據。可以說很多架構問題都是出在數據層，例如常見的「煙囪式系統」帶來的種種問題，特別是數據孤島問題，其實本質上的原因就出在沒有將數據層打通，如果不從數據架構去思考，就可能「頭疼醫頭、腳疼醫腳」，費了半天勁還是很彆扭，反過來如果將數據層治理好，就像打通「任督二脈」一樣，起到四兩撥千斤的效果。
但是理想通常很豐滿，現實卻很骨感。至少在我們五年前出來創業那會兒，我們覺得並沒有一個系統能夠很好的解決數據的問題。可能好奇的讀者就要問了：不是有 Hadoop？還有 NoSQL？再不濟關係型數據庫也能分庫分表啊？其實列出的這幾個幾乎就是當年處理存儲問題的全部候選，這幾個方案的共同特點就是：不完美。
具體一點來說，這幾個解決方案對於數據應用的場景覆蓋其實都不大，對於複雜一點的業務，可能需要同時使用 n 多個方案才能覆蓋完整。這就是爲什麼隨着近幾年互聯網業務越來越複雜，類似 Kafka 這樣的數據 Pipeline 越來越流行，從數據治理的角度其實很好理解：各種數據平臺各負責各的，爲了做到場景的全覆蓋，必然需要在各個「島」之間修路呀。
我們當年就在想，能不能有一個系統以一個統一的接口儘可能大的覆蓋到更多場景。
我們需要一個 Single Source of Truth。數據應該是貫穿在應用邏輯各個角落，我理想中的系統中對於任意數據的存取都應該是可以不加限制的（先不考慮權限和安全，這是另一個問題），這裏的“不加限制”是更廣義的，例如：沒有容量上限，只要有足夠的物理資源，系統可以無限的擴展；沒有訪問模型限制，我們可以自由的關聯、聚合數據；沒有一致性上的限制；運維幾乎不需要人工干預……
以分佈式數據庫爲統一中心的架構
我當年特別着迷於一個美劇：Person of Interest （疑犯追蹤），這個電視劇裏面有一個神一樣的人工智能 The Machine，收集一切數據加以分析，從而預測或是干預未來人們的行動。雖然這部美劇還是比較正統的行俠仗義之類的主題，但是更讓我着迷的是，是否我們能設計一個 The Machine？雖然直到目前我還不是一個 AI 專家，但是給 The Machine 設計一個數據庫似乎是可行的。這幾年創業過程中，我們發現更令人興奮的點在於：
以分佈式數據庫爲統一中心的架構是可能的。
這個怎麼理解呢？舉個例子，就像在上面提到的分裂帶來的問題，數據層的割裂必然意味着業務層需要更高的複雜度去彌補，其實很多工程師其實偏向於用線性的思維去思考維護系統的成本。但是實際的經驗告訴我們，事情並不是這樣的。一個系統只有一個數據庫和有十個數據庫的複雜程度其實並不是的簡單的 10x，考慮到數據的流動，維護成本只可能是更多，這裏還沒有考慮到異構帶來的其他問題。
以分佈式數據庫爲中心的架構是什麼樣子的呢？很好理解，整個架構的中心是一個場景覆蓋度足夠廣，且具有無限的水平伸縮能力的存儲系統。大部分數據的流動被限制在這個數據庫內部，這樣應用層就可以幾乎做到無狀態，因爲這個中心的數據庫負責了絕大部分狀態，每個應用可以通過自己的緩存來進行加速。
這裏我想提醒的是，爲什麼我在上面強調水平擴展能力，是因爲受限的擴展能力也是導致分裂的一個重要的原因。我們從來都沒有辦法準確的預測未來，我們很難想象甚至是一年後業務的變化（想想這次疫情），有句老話說的很好：唯一不變的就是變化。
另外一個經常被問到的問題，爲什麼要強調緩存層需要離業務層更近，或者說，爲什麼位於中心的這個巨型數據庫不應該承擔緩存的責任？我的理解是，只有業務更懂業務，知道應該以什麼樣的策略緩存什麼樣的數據，而且出於性能（低延遲）考慮，緩存離業務更近也是有道理的。
[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-48xJXblE-1586332219569)(https://download.pingcap.com/images/blog-cn/talk-about-the-future-of-databese-on-5th-anniversary-of-pingcap/2-distributed-database.png)]
對應上面那句話「唯一不變的就是變化」，這個架構帶來最大的好處正是「以不變應萬變」，或者更簡單的一個詞：簡潔。Google 其實在很早就想清楚了這個問題，因爲他們很早就明白什麼是真正的複雜。
另一個例子是 HTAP，如果關注的數據庫的發展的話，最近一定對 HTAP 這個詞很熟悉，其實在我看來的 HTAP 的本質在於上面提到的覆蓋度，下面是一個典型的架構：
傳統的數據架構通常將 OLTP、OLAP、離線數倉分離，各個系統各司其職，中間通過獨立的 Pipeline 進行同步（有時候還會加上 ETL）。
下面是一個 HTAP 的系統的樣子：
雖然從表面上看，只是簡單的將接口層進行整合，但是這個意義其實是深遠的，首先數據同步的細節被隱藏了一起來，這意味着數據庫層面可以自己決定通過何種方式同步數據，另外由於 OLTP 引擎和 OLAP 引擎在同一個系統內部，使得很多細節信息不會在同步的過程中丟失，比如：事務信息，這就意味着在內部的分析引擎能夠做到傳統的 OLAP 沒辦法做的事情。另外對於業務層的使用來說，少一個系統意味着更統一的體驗和更小的學習和改造成本，不要低估統一帶來的力量。
未來在哪裏？
上面這些是過去五年發生的事情，也幾乎按照我們創業時候的設想一步步的變爲現實，那麼接下來的五年會發什麼？隨着對於行業和技術的理解的加深，至少有一點我深信不疑的是：
彈性調度會是未來的數據庫的核心能力
誰都不會否認，最近十年在 IT 技術上，最大的變革是由雲帶來的，這場革命還在進行時。雲的核心能力是什麼？我認爲是彈性。計算資源分配的粒度變得越來越細，就像從只能買房變成可以租房，甚至可以像住酒店一樣靈活。這意味着什麼？本質在於我們可以不用爲「想象中」的業務峯值提前支付成本。
過去我們的採購服務器也好，租賃機櫃也好，都是需要設定一個提前量的，當業務峯值沒有到來之前，其實這些成本是已經提前支付的了。雲的出現將彈性變成了基礎設施的一個基礎能力，我預計數據庫也會發生同樣的事情。
可能有很多朋友會有疑問，現在難道不是幾乎所有數據庫都號稱能夠支持透明水平擴展嘛？其實這裏希望大家不要將**「彈性調度」狹隘的理解爲擴展性，而且這個詞的重點在「調度」**上，我舉幾個例子以方便大家理解：
-
數據庫能不能夠自動識別 workload，根據 workload 進行自動伸縮？例如：預感到峯值即將來臨，自動的採購機器，對熱數據創建更多副本並重分佈數據，提前擴容。在業務高峯過去後，自動回收機器進行縮容。
-
數據庫能不能感知業務特點，根據訪問特點決定分佈？例如：如果數據帶有明顯的地理特徵（比如，中國的用戶大概率在中國訪問，美國用戶在美國），系統將自動的將數據的地理特徵在不同的數據中心放置。
-
數據庫能不能感知查詢的類型和訪問頻度，從而自動決定不同類型數據的存儲介質？例如：冷數據自動轉移到 S3 之類比較便宜的存儲，熱數據放在高配的閃存上，而且冷熱數據的交換完全是對業務方透明的。
這裏提到的一切背後都依賴的是「彈性調度」能力。未來我相信物理資源的成本會持續的降低，計算資源的單價持續下降帶來的結果是：當存儲成本和計算資源變得不是問題的時候，問題就變成**「如何高效的分配資源」**。如果將高效分配作爲目標的話，「能調度」就是顯而易見的基礎。
當然就像一切事物發展的客觀規律一樣，學會跑步之前，先要學會走路，我相信在接下來的一段時間內，我們會看到第一批初步擁有這樣能力的新型數據庫，讓我們拭目以待。
下一個階段是智能
對於更遠的未來是怎麼樣子的？我不知道，但是就像 The Machine 一樣，只有足夠數據才能誕生出智能，我相信就像我們不瞭解宇宙和海洋一樣，我們現在對於數據的認識一定是膚淺的，甚至大量的數據我們都還沒記錄下來，一定有更大奧祕隱藏在這海量的數據中，從數據中能獲取什麼樣的洞察，能夠怎麼樣更好的改變我們的生活，我並不知道，但是做這件事情的主角我猜不會是人類。雖然在這個小節我們討論的東西可能就有點像科幻小說了，不過我願意相信這樣的未來，從數據的海洋中誕生出新的智能體。
尾聲
創業這五年的時間，回頭看看那個最樸素的出發點：寫一個更好的數據庫徹底解決煩人的 MySQL 分庫分表問題。似乎也算沒有偏離初心，但是在這個旅途中一步步看到了更大的世界，也越來越有能力和信心將我們相信的東西變爲現實：
我有一個夢想，未來的軟件工程師不用再爲維護數據庫加班熬夜，各種數據相關的問題都將被數據庫自動且妥善的處理；
我有一個夢想，未來我們對數據的處理將不再碎片化，任何業務系統都能夠方便的存儲和獲取數據；
我有一個夢想，未來的我們在面臨數據的洪流時候，能從容地以不變應萬變。
最近我聽到一句話，我個人很喜歡：雄心的一半是耐心。構建一個完美的數據庫並不是一朝一夕的工作，但是我相信我們正走在正確的道路上。
凡所過往，皆爲序章。
作者：黃東旭，PingCAP 聯合創始人兼 CTO，資深基礎軟件工程師，架構師，曾就職於微軟亞洲研究院，網易有道及豌豆莢。擅長分佈式系統以及數據庫開發，在分佈式存儲領域有豐富的經驗和獨到的見解。狂熱的開源愛好者以及開源軟件作者，代表作品分佈式 Redis 緩存方案 Codis，以及分佈式關係型數據庫 TiDB。2015 年創業，成立 PingCAP，在 PingCAP 的主要工作是從零開始設計並研發開源 NewSQL 數據庫 TiDB，目前 GitHub 上該項目累積 star 數超過 23000+，成爲本領域全球頂級的開源項目。
One More Thing
接下來的四周，本文作者黃東旭將開啓「The Future of Database 系列直播」，爲大家描繪我們眼中未來數據庫的模樣，並分享我們在探索未來之路上的里程碑——TiDB 4.0 的設計哲學與實踐。第一期直播將在本週六晚 20:00 開啓，詳情請點擊：https://www.oschina.net/event/2315776
