張瑞，阿裡集團資料庫技術團隊負責人，阿裡巴巴研究員，oracle ace。雙十一資料庫技術總負責人，曾兩次擔任雙十一技術保障總負責人。自2005年加入阿裡巴巴以來，一直主導整個阿裡資料庫技術的不斷革新。
近日，在京舉行的2017中國資料庫技術大會上，來自阿裡巴巴集團研究員張瑞發表了題為《面向未來的資料庫體系架構的思考》的主題演講。主要介紹了阿裡資料庫技術團隊正在建設阿裡下一代資料庫技術體系的想法和經驗，希望能夠把阿裡的成果、踩過的坑以及面向未來思考介紹給與會者，為中國資料庫技術的發展出一份力。
我先介紹一下我自己，我2005年加入阿裡一直在做資料庫方面的工作，今天這個主題是我最近在思考阿裡巴巴下一代資料庫體系方面的一些想法，在這裡分享給大家，希望能夠抛磚引玉。大家如果能夠在我今天分享後，結合自己面對的實際場景，得到一些體會，有點想法的話，我今天分享的目的就達到了。
今天我會講以下幾方面内容：首先講一下我們在核心上的一點創新、資料庫怎麼實作彈性排程、關于智能化的思考、最後是曾經踩過的坑和看到未來的方向。
阿裡場景下資料庫所面臨的問題
首先說一下，阿裡巴巴最早一代使用的資料庫技術是oracle，後面大家也知道一件事情就是去ioe，去ioe過程中我們邁向了使用開源資料庫的時代，這個時代今天已經過去，這個過程大概持續了五六年，整個阿裡巴巴有一個大家都知道的開源mysql分支--alisql，我們在上面做了大量的改進，是以我這裡列了一下在alisql上的一些改進，但今天我實際上并不想講這個，我想講一下面向未來的下一代資料庫技術、資料庫架構會往哪個方向走。
我覺得是這樣的，因為今天的阿裡巴巴畢竟是一個技術的公司，是以很多時候我們會看比如說google或者是一些網際網路的大的公司，他們在技術上創新點來自于哪裡？來自于問題。就是說今天在座的各位和我是一樣的，你所面對場景下的問題是什麼、你看問題深度如何決定了你今天創造的創新有多大。
是以今天我們重新看一下阿裡面臨的問題是什麼，相信在座的各位一定也有這樣的想法，阿裡所面臨的問題不一定是你們的問題，但我想說今天通過阿裡面臨的問題，以及我們看到這些問題後所做的事情，期待能夠給大家帶來參考，希望大家也能夠看到自己所面臨的問題是什麼，你将如何思考。
可以看到其實阿裡巴巴的應用和facebook、google的還是有很大差別的，我們也找他們做了交流，發現跟他們的業務場景真的不一樣，首先我們的主要應用是交易型的，這些應用會有些什麼要求，你會看到有這些點（見圖檔），下面主要講一下我們的思考。
今天資料的高可用和強一緻是非常重要的，資料不一緻帶來的問題是非常非常巨大的，大家也用淘寶，也是阿裡巴巴一些服務的使用者，資料不一緻帶來的問題，每一個使用者、甚至我的父母都會關注這些事情。
第二，今天存儲成本是非常高的，所有的資料中心已經在用ssd，但資料的存儲成本依然是一個大型企業面臨的一個非常大的問題，這都是實實在在錢的問題。
另外剛才也提到了，資料都是有生命周期的，那麼資料尤其是交易資料是有非常明顯的冷和熱的狀态，大家一定很少看自己一年前在淘寶的購買記錄，但是當下的購買記錄會去看，那系統就需要經常會去讀它、更新它。
還有一個特點是今天阿裡的業務還是相對簡單的，比如我們要在oltp性能上做到極緻性。還有一個阿裡巴巴特有的點就是雙十一，雙十一本質上是什麼，本質上就是制造了一個技術上非常大的熱點效應。這對我們提出什麼樣的需求呢？需求就是一個極緻彈性的能力，資料庫實際上在這個方向是非常欠缺的，資料庫怎麼樣去做到彈性伸縮是非常難的事情。
最後我想說說dba，今天在座的很多人可能都是dba，我想說一下阿裡在智能化這個方向上得到的思考是什麼樣的，我們有海量的資料，我們也有很多經驗很豐富的dba，但這些dba怎麼樣去完成下一步的轉型、怎麼樣不成為業務的瓶頸？資料庫怎麼樣做到自診斷、自優化。這是我們看到的問題，最後我也會來分享一下我在這方面的思考。
阿裡在資料庫核心方向上的思考
我先講一下我們在資料庫核心上的思考。首先我很尊敬做國産資料庫的廠商，凡是在核心上改進的人都知道，其實每個功能都是要一行行代碼寫出來都是非常不容易的，我想表達對國産資料庫廠商包括這些技術人的尊敬。今天我要講的内容是我第一次在國内的會議上來講，首先我會講一下alisql x-cluster。x-cluster是在alisql上做的一個三節點叢集，這是我們在引入了paxos一緻性協定，保證mysql變成一個叢集，并且這個叢集具有資料強一緻、面向異地部署，且能夠容忍網絡高延遲等一系列特性。
今天很多資料庫都會和paxos聯系在一起，比如大家都知道的google的spanser資料庫，但是以前大家沒有特别想過資料庫和paxos會有什麼關系，其實以前确實沒有什麼關系的，但是今天的資料庫在幾個地方是需要用到paxos協定的，第一個我們需要用paxos來選舉，尤其在高可用的場景下需要唯一地選舉出一個節點作為主節點，這就需要用到paxos；第二是用paxos協定來保證資料庫在沒有共享存儲的前提下資料的強一緻，就是資料怎麼樣在多個節點間保證是強一緻，且保證高可用。
是以說現在的資料庫架構設計上paxos的應用非常廣泛，今天外面很多展商包括goolge spanser也都在用paxos協定和資料庫結合在一起來做。是以alisql的三節點叢集也是一樣，就是利用paxos協定變成一個資料強一緻的叢集。下面我大概解釋一下paxos協定在資料庫裡的作用是什麼。
本質上來說paxos也是現在通用的技術，大家都是搞資料庫的，簡單來說，paxos協定用在我們資料庫裡面，就是一個事務組的送出在一個節點并落地後，必須在多個節點同時落地，也就是說原來寫入隻需要寫入一個節點上，但是現在需要跨網絡寫到另外一個節點上，這個節點可能是異地的，也可能是全球的另外一個城市，中間需要經過非常漫長的網絡時延，這時候需要有一些核心技術。
我們的目标是什麼？首先沒有辦法抗拒實體時延，過去在資料庫上的操作隻要送出到本地，但現在資料庫全球部署、異地部署，甚至跨網絡，這個時延特性是沒有辦法克服的，但是在這種情況下我們能做到什麼？在時延增長情況下盡可能保證吞吐不下降，原來做多少qps、tps，這一點是可以保證的，隻要工程做的好是可以保證的，但是時延一定會提升。
這也是大家經常在goolgle spanser論文裡看到的“我的時延很高”的描述，在這種時延很高的情況下，怎麼樣寫一個好的應用來保證可用、高吞吐，這是另外一個話題。大家很長一段時間裡已經習慣一個概念，那就是資料庫一定是時延很低的，時延高就會導緻應用出問題，實際上這個問題要花另外一個篇幅去講，那就是應用程式必須要去适應這種時延高的資料庫系統。當然用了batching和pipelining技術，本質上是通用的工程優化，讓跨網絡多複本同步變的高效，但是時延一定會增加。
實際上大家知道資料庫要做三副本或者三節點，本質上就是為了實作資料強一緻，而且大家都在這個方向上做努力，比如oracle前一段時間推出的group replication，也是三節點技術，x-cluster和它的差別是，我們一開始的目标就是跨城市，最開始設計的時候就認為這個節點一定要跨非常遠的距離來部署的，設計之初提出這個目标造成我們設計上、工程實踐上、包括最終的性能上有比較大的差異。
這裡我們也做了一些x-cluster和oracle的group replication的對比，同城的環境下我們要比他們好一些；在異地場景下這個差異就更大了，因為我們本來設計的時候就是面向異地的場景。可能大家也知道，阿裡一直在講異地多活的概念，就是idc之間做異地多活怎麼樣能夠做到，是以最開始我們設計的就是面向異地的場景做的。
這是一個典型的x-cluster在異地多活的場景下怎麼做的架構圖，這是一個典型的3城市4份資料5份日志架構，如果要簡化且考慮資料存儲成本的話，實際上可以做到3份資料5份日志，這樣的話就可以保證城市級、機房機、包括單機任何的故障都可以避免，并且是零資料丢失的，在今天我們可以這麼做，且能保證資料是零丢失、強一緻的。在任何一個點上的資料至少會被寫到另一個城市的資料中心的資料庫裡面，這是我們x-cluster設計之初的目标，這也是一個典型的異地多活的架構。
再講一個小的，但是非常實用的創新點，可能大家都比較感興趣，這就是x-kv。這裡還要說一下，我們所有的下一代技術元件都是以x開頭的。這個x-kv是基于原來mysql的memcached plugin做的改進，做到非常高的性能，大家可能都了解mysql的memcached plugin，可以通過memcached plugin的接口直接通路innodb buffer 裡的資料，讀的性能可以做到非常高，這對于大家來說，或者對于所謂的架構師，或者設計的過程中意義在什麼地方呢？
那就是很多場景下不需要緩存了，因為資料庫+緩存結構基本上是所有業務通用的場景，但是緩存的問題在于緩存和資料庫裡的資料永遠是不一緻的，需要一個同步或者失效機制來做這個事情。使用x-kv後讀的問題基本上就能解決掉。這是因為一份資料隻要通過這個接口通路就基本上做到和原來通路緩存差不多的能力，或者說在大部分情況下其實就不需要緩存了。
第二是說它降低了應用的響應時間，原來用sql通路的話響應時間會比較高，我們在這上面做了一些改進，本來memcached plugin插件有一些支援資料的類型限制，包括對一些索引類型支援不太好，是以我們做了改進，這個大家都可以用的，如果用這個方式的話基本上很多緩存系統是不需要的。
第三個事情我想講一下怎麼樣解決冷熱資料分離的，我們天然地利用了mysql的架構，這裡就直接拿了mysql的大圖來展示，大家可以看到mysql本質上來說就是上面有個client，中間有個server，底下有個存儲層，在存儲層裡面可以有各種各樣的引擎，是以通過不同的引擎可以實作不同的特性。大家今天最常用的就是innodb引擎，每個存儲引擎的特性本質上是由其結構造成的。比如innodb采用b+ tree的結構，它帶來的特性就是相對來說讀和寫都比較均衡，因為發展了這麼多年确實是比較成熟的。
比如我們現在選擇rocksdb，這是因為我們和facebook在rocksdb上有一些合作，就是把它引入到mysql上面，它本質的結構是lsm tree，這個結構就帶來的好處包括寫入比較友好、壓縮的特性好等。把它引入進來對我們的改革還不僅僅是引入了一個結構，而是今天我們用這兩種引擎解決我們今天資料分離的問題。我們也跟facebook有過一些交流，rocksdb今天并沒有那麼穩定、那麼好，但是作為innodb存儲引擎的補充的話，是非常有效的。
尤其在穩定資料庫的背景下，使用者今天怎麼樣才能對自己的資料的冷熱沒有太多的感覺，因為大家可能也知道，你們以前也有一些資料的分離，但是對應用方來說，需要把資料從某個存儲倒到某個存儲裡，然後再删掉；或者動不動dba去找業務開發方說你的存儲空間不夠了，占用很多空間，能不能删一些資料或者把這些資料導入到成本更低的存儲引擎裡。我們經常這麼幹，這裡說的直白一點，我相信大家都這麼幹過。
但是用這種雙引擎結構的話，rocksdb壓縮率高的特性，特别是oltp行存儲的場景下，能夠給我們帶來比較大的收益。是以我們可以把這兩個引擎在mysql特性下面把它結合起來，并且可以利用到比較廉價的架構，尤其是lsm tree這種架構，他對廉價的存儲媒體是比較友好的，因為他的寫都是順序寫的。這就是我們今天在資料庫核心上面的一些思考。
為什麼要實作彈性排程
第二部分，我想說一下資料庫彈性排程這個事，大家都知道阿裡雙十一，雙十一對我們來說最大的挑戰就是應用程式可能已經很容易去做彈性排程，包括上雲、彈性擴容和縮容，但是資料庫确實比較難，我們也在這上面也探索了一段時間，今天會把我們的思考分享給大家。
我之前聽好多人說資料庫容器化是個僞命題，為什麼要做容器化，為什麼要把資料庫放到容器裡呢？第二也有一些新技術，比如剛才的分享嘉賓也提到的，把存儲放在遠端通過網絡通路是可能的。但是我們從正向來思考，先别想資料庫彈性排程可能不可能，資料庫如果要實作彈性排程，它的前提是什麼？
我們先去想資料庫要像應用一樣非常簡單的彈性排程，那麼資料庫要做到什麼？我覺得有兩大前提是必須要做的：1、它必須要放到一個容器裡；2、計算和存儲必須分離。因為如果計算和存儲本質上不分離的話，資料庫基本上沒有辦法彈性排程。大家知道計算資源是很容易被移動的，但是存儲資源基本上很難在短時間内移動它，是以做彈性是非常非常困難的。是以這是兩大基礎條件。
在我們的場景下如果你也碰到這種問題的話，那就不是僞命題，我覺得這個東西合不合理，更多時候不是技術有沒有正确性，而是在你的場景下是否需要它，是以今天我們就做了兩件事情，第一是把它放到容器裡面，我們目前實體機，vm和docker都在支援，有一層會把容器的複雜性屏蔽掉，資料庫一定要放到容器裡。應用程式放到容器裡很多時候是為了部署，但是我們把資料庫放容器裡就是為了做排程，因為資料庫本身沒有特别多的釋出，不需要像應用一樣做頻繁釋出。做了容器化之後，資料庫在一個實體機上可以和其他的容器做混部。
我們做dba的都有一些傳統的觀點，比如資料庫伺服器上肯定不能跑應用，資料庫肯定是不能用容器的。不知道在座的各位，每當有人或者你的老闆問你這個問題的時候，你是不是從來都是馬上回絕他說“資料庫肯定不能這麼做”，但是今天你也許可以告訴你的老闆可以試一試。
存儲計算分離，最早做資料庫的時候，存儲和計算其實就是分離的，用一個oracle的資料庫，用一個san網絡，底下接一個存儲，存儲和計算本身就是分離的，中間用san網絡連起來。然後演進到用local的盤，用ssd盤，用pc做伺服器。，那未來重新要回到存儲和計算分離的結構下，今天的網絡技術的發展，不說專有網絡，就說通用的25g網絡，還有rdma和spdk等新技術的使用，讓我們具備了存儲計算分離的能力，讓資料庫存儲計算分離的條件已經具備。
今天在資料庫上已經看到大量優化的特性可以減少io，可以把離散的io變成順序的io，可以對下層的存儲做的很友好。從存儲成本上來說，共享存儲會極大的降低成本，是因為存儲碎片會被極大地壓縮，因為原來每個機器上都空閑30%、50%的空間，其他的機器是很難利用到的，當你今天把這些碎片變成一個pool的時候是有很大收益的。
還有資料庫未來如果采用存儲和計算分離的話，就會打破目前主流的資料庫一主一備的架構，這個架構至少有一半的計算資源是被完全浪費的，不管你的備庫是否用來做報表或者其他的應用，但是基本是浪費的。如果可以做到共享存儲，那這将是一個巨大的收益。這是我們在排程上的思考，明天分會場上也會有一個阿裡同學就這個主題給大家做容器和存儲資源上的細節介紹，我今天隻講了一個大概。
dba未來的工作内容是什麼？
最後講一下dba的事情，剛才也在說，我這裡說從自動化走向智能化，我們内部講從自助化走向智能化，不知道大家是不是受到一個困擾，業務發展的速度遠遠大于dba人數的增長，如果你沒有後面的這些我可以不講了，但是如果你有，你可以聽一下我們在這方面的思考，我們也碰到同樣的問題，dba要怎麼樣的發展，自動化的下一步應該做什麼，很多人說dba是不是會被淘汰掉，至少我們想清楚了這些問題之後，阿裡的dba不糾結這個事情，是以我今天跟大家分享一下這個思考。
首先我們今天做了一個事情，我們放棄了原來的思路，原來的思路是什麼呢？最早的時候我們每個上線的sql都需要dba看一下；第二個階段，我們做了一個系統，在每個sql上線之前系統都要預估一下它的性能好不好，如果好才上線。所有我們今天覺得最大的變化和思考是什麼？所有基于單條語句的優化都是沒有特别多意義的，因為隻有基于大的資料和計算，才有可能變成一個智能化的東西，否則都是基于規則的。
基于規則的系統是很難有特别長久的生命力，因為有永遠寫不完的規則。我們也曾經做過這樣的嘗試，一些sql進來的時候，系統要對它進行一些判斷，最後發現永遠寫不完的規則。是以後來我們就找到了另外一個方向，我相信今天在座的所有人，你所在的公司不論大小都都有一個監控系統，我們就從這個監控系統出發，怎麼樣把一個監控系統變成一個智能的優化引擎，我們在這裡也不說是大腦，就說是引擎好了。這個引擎會做什麼？
首先來說，我們已經放棄掉基于單條sql的優化，因為沒有意義，dba也沒有審閱單條sql，系統去看單條sql的意義也不大。今天我們的第一個場景是說大量的資料，大量的資料是什麼？我們就從我們的監控系統出發，提出了第一個目标，把每一條運作的sql采集下來，不是采樣，是每一條。在規模比較大的系統來說對存儲來說是個巨大的壓力，因為這樣會産生大量的副産品。
就像facebook在做監控産品時産生的時序資料庫一樣，今天我們産生的副産品也是在時序資料庫方面帶來壓力，這個具體的我今天先不展開。我們采集每一條sql的運作情況，因為我們在核心裡做了改進，可以把每條sql的來源、路徑、以及它在資料庫裡所有的資訊全部采集下來。把監控名額壓到秒級，所有監控項的名額必須最小達到秒級，這是我們現有的技術能夠做到的。
另外，我們把應用端日志和資料庫結合在一起。原來做資料庫的時候，應用方吼一嗓子說“資料庫有沒有問題啊”dba說沒有問題。但是從應用那端看，其實看到資料庫有很多問題，包括應用報錯，包括響應時間，把應用端報錯也要和資料庫結合在一起，尤其是應用裡面報資料庫的錯誤，以及這一整條鍊路。
響應時間，隻有應用端的響應時間才是真正意義上可以衡量一個資料庫是不是好的名額，而不是資料庫本身怎麼樣，什麼load低啊，cpu使用率多少。當把這些資料全部采集下來之後，這些大量的時序資料我們叫做副産品，這對我們整個鍊路産生了一個巨大的壓力。我們做整個監控系統平台的同學覺得日子要活不下去了，因為原來的存儲系統支撐不了、分析系統支撐不了、原來的平台計算不出來。是以先從這個目标考慮，基于鍊路做了巨大的改進，包括怎麼樣實作廉價存儲、怎麼樣實時分析，這是存儲和計算的要求。
我們今天這個目标是在阿裡内部明确提的，我們希望兩到三年内希望大部分把dba的工作替換掉，我不知道兩到三年能不能做到，我希望能做到。其實今天dba是這樣的，dba的工作本質上分為兩類，第一類就是運維，但運維本質上來說是比較好解決的，不管是用雲，小公司用雲全搞定，大公司基本上都有一些自動化運維的系統。
但是最難解決的就是剛才我說的診斷和優化。我也了解過很多公司，比如說google、facebook，我說你們為什麼沒有dba呢？他們說我們沒有dba，沒有像國内這種特别傳統的針對診斷和性能優化的dba，這種職責很少。是以這個東西希望能夠做到。
最後我們有了資料、有了計算，我們覺得未來的方向可能就是現在比較火的機器學習，這個主題明天也有一個阿裡同學會來分享，機器學習這裡我就不多講了，因為我覺得我們也在入門，是以沒有什麼值得講的，但是我們覺得這個設計挺有戲的，你隻要積累足夠的資料和計算的話這個事情還是挺有戲的。
我們對資料庫未來的其他思考
最後一頁ppt我用大白話講一下我對整個資料庫體系的一些了解。
今天在一個公司裡邊沒有一個存儲或者是資料庫可以解決所有問題，今天越來越多的趨勢看到，資料存儲的多樣性是必然會存在的，因為行存有行存的優勢、列存有列存的優勢、做計算有計算的優勢、做分析有做分析的優勢、做oltp有oltp的優勢，不要指望，或者很難指望一個系統幹所有的事情很，這個話我說了可能不太好，但是确實比較難，但是我們看到的一點是什麼？就是每個技術或産品在生産中幹一件事情可以幹到最好，你就用它做的最好的那件事解你的問題就好了。
這就回到之前的問題，我們也走過一些彎路，資料存儲類型越來越多，今天用這個明天用那個，怎麼辦？我們的運維沒法搞定，這個支援很痛苦。
是以今天我們建議建立兩個平台：1、建立一個支撐的平台，這個支撐的平台盡可能把下層存儲的複雜性屏蔽掉，對上層提供統一的接口和服務；2、建立一個服務的平台，明确面向研發的平台，研發人員可以直接通過這個平台來用資料庫的服務。我看到很多公司把運維平台和dba開發的平台混在一起，但阿裡的思路是，支撐平台和服務平台是兩個分層的平台，支撐平台在下面，上層服務平台為所有的開發人員服務，開發人員上了這個平台就能看到我用了什麼資料庫，性能怎麼樣，在上面可以做什麼事情，這樣就可以大量節省dba的人力。
我們内部有句開玩笑的話叫“不節省人力的平台、不節省成本的技術都是耍流氓”，這句話怎麼講？就是說我們的自動化系統，尤其是大公司越建越多，最後的結果就是人沒有能力了，我不知道大家有沒有這個問題，這就是我最後講的一點，自動化系統的悖論。每個公司每個人今天你們在做自動化系統的過程中有沒有發生一件事情？反正在阿裡是發生了，就是人的能力弱化了。
這個自動化系統的悖論是我們無意中看到的，在講飛機的自動駕駛的時候，因為自動駕駛做的足夠好，當出現緊急問題的時候，飛機駕駛員反而沒有足夠的能力去處理緊急的情況，這就是自動化系統的悖論。
可以對比看一下，我們今天做了很多自動化系統，結果人隻會點系統，系統一卡殼就完蛋，很多次生故障都是出現在系統卡殼，卡殼人搞不定，怎麼辦？這是今天要去想的問題，在這個過程中今天所有帶團隊的或者今天在這個體系的人都要思考的問題，我們也在直面這個問題，讓人的能力和系統的能力能夠結合在一起，這是另外一個話題，我今天不能給出答案，但是要特别重視這些問題。
不要相信那些已經過期的神話，資料庫存儲和計算是可以分離的，資料庫也是可以放在容器裡的，但你真的要去看一下，原來那些神話或者是那個背後它的問題到底是什麼，其實作在可能都已經有解法了，是以在座的各位，當你的老闆、cto或者什麼人來問你“能不能做到這樣？”我希望你能告訴他“我能！”
我們内部有一句話原來我們的dba哪裡看過一篇文章，說dba的概念是什麼？我印象特别深，有一個開發的同學在底下的回複是說“dba就是一群永遠在說不的人”就是不能這樣不能那樣，我們今天我覺得未來我們變成一群永遠可以說“yes”，說“可以”的人，謝謝！