<b>摘要：</b>8月24日，阿裡雲資料庫技術峰會到來，本次技術峰會邀請到了阿裡集團和阿裡雲資料庫老司機們，為大家分享了一線資料庫實踐經驗和技術幹貨。阿裡雲進階資料庫技術專家隊皓庭分享了高度相容mysql，并且能免去傳統數倉etl過程實作資料分析，同時支援高并發、大吞吐量的線上事務處理的pb級資料存儲資料庫是如何實作的，幫助大家了解了同時支援海量資料線上事務（oltp）和線上分析（olap）的htap關系型資料庫是如何打造出來的。
本文将介紹hybriddb for mysql的定位和現狀，以及其技術演進路線和尚待解決的問題。
<b>一、産品現狀</b>
hybriddb for mysql在rds mysql的基礎上做了很多拓展和改進，同時也保留了一些傳統關系型資料庫的特性。hybrid是在2005年提出的htap資料庫的概念，指混合的事務和分析處理。傳統的資料庫因為各方面的限制，偏向于oltp或olap的場景，兩者很難兼得，目前也隻有oracle勉強地解決了這個問題。但是在更大的資料場景下，因為oracle産品價格高昂，一般使用者往往難以承擔。而mysql在國内外擁有很高的知名度和使用者量，從這個生态出發可以讓阿裡雲研發團隊收獲更多的産品改進思路。hybriddb for mysql從個角度出發，提供一種高成本效益、大資料庫的産品，在解決oltp和olap業務的同時，維持好mysql的生态。
hybriddb for mysql在sql相容性方面做了很多的擴充，包括支援了tpc-h和tpc-ds這兩個olap領域的測試集。由于是阿裡雲的雲資料庫服務，hybriddb for mysql繼承了rds的雲服務特征，高可靠、高可用等特性一應俱全并支援線上的擴容。目前hybriddb for mysql的線上服務規模遍及國内外十多個region，為阿裡雲及外部的使用者提供了可靠服務，總資料量已經達到tb級，日新增資料達百t級。
<b>二、産品定位</b>
hybriddb for mysql的定位是使用一份資料同時支援oltp和olap。它的創新包括實作了share noting的架構，支援線性的資訊擴充，以及使用了更新穎的高壓縮比引擎，可以在大資料規模下有很好的表現。從定位上說，hybriddb for mysql與其他分布式資料庫産品各有分工。與其他阿裡雲資料庫産品有所偏向不同，hybriddb for mysql在oltp和olap方面均有不錯的擴充能力。hybriddb for mysql吸收各家所長，希望提供一個通用的資料庫解決方案來幫助使用者解決大資料場景下基于sql的業務問題。
<b>三、技術演進路線</b>
2013年從單機資料庫加中間件的思路出發，阿裡雲利用分庫分表中間件形成分庫分表資料庫。之後，阿裡雲對存儲和計算方面進行了大幅度的優化，支援大資料存儲的同時大幅降低成本，改進了sql相容性。今年開始做行列混合存儲引擎，期望在更高的分析領域場景提供更好的服務。明年期望把rds的polardb當作存儲引擎，使整套資料能夠運作在共享存儲上，解決棘手的運維問題。
<b></b>
1、發展起點
單機資料庫在遇到大資料場景下有很多瓶頸，以mysql為例，它對sql的執行隻有一個session線程，最多隻能利用一個cpu的核。當單表資料量超過千萬時，它的檢索顯得力不從心。這時候主流搜尋引擎像innodb被加數層級會變得比較高，緻使單次oltp的查詢或更新的代價更大，相應時間變高。
單機資料庫幾乎無法解決這種問題，因為它所有的資料（資料結構和磁盤存儲）都落在一台機器上，沒有辦法進行線性擴充。在并發密度高的環境下，不同并發線程間會資源争搶。從硬體的cpu、記憶體，再到軟體的鎖、日志和事務，都是線程密集争搶的對象。是以并發越高，資料庫的整體存儲下降地愈發明顯。從這個角度出發，阿裡雲思考如何将單機資料庫的性能擴充起來？
<b>2、合久必分</b>
傳統解決方案利用中間件把一個大資料庫的資料切成多個分片，內建到使用者的業務代碼中提高并行能力，中間件把使用者的大查詢拆成多個小查詢，并行的計算并行的合并。這個思路讓使用者的代碼背上了沉重的中間件，不同的使用者想使用這套體系的時候還需要重複地編碼。
從這個角度出發，阿裡雲研發團隊把中間件抽取出來加入到資料庫伺服器中，對外呈現同一套的資料庫通路協定，讓使用者使用sql連接配接資料庫進行查詢和更新。在這個過程中，中間件代理使用者完成并行計算。
整個設計思路偏向于mpp資料庫。mpp資料庫将使用者的語句通過查詢解析器、優化器翻譯成一個并行控制的執行計劃。這樣一個執行計劃可以最大程度地利用多級計算資源，将資料分而治之，所有使用者都可以使用mysql的協定去通路hybriddb for mysql而不再關心額外的業務代碼。
在這個設計架構下，阿裡雲研發團隊遇到的問題及解決政策如下：
事務狀态機。研發團隊需要解決的問題是如何維護多級間資料一緻性，尤其是要與原先使用者的事務特性保證相容？研發人員引入兩階段送出來解決分布式事務的問題。使用者的跨區更新可以通過兩階段送出協定來保證強一緻性。
流式執行器。資料庫伺服器的記憶體和磁盤空間都是有限的，不能解決超大規模的查詢。例如一個表做一個全局的join in，需要把資料從各個表取出來做本地join in，如果此時再需要按不同次元排序，很可能産生臨時表，而臨時表往往扛不住這種壓力。是以本階段隻考慮可以流式執行的sql，包括count、sum等聚合函數以及一個次元的order by。
請求級連接配接池。連接配接到資料庫的使用者session很可能超過了單機上限。目前采取的措施是支援一個使用者的請求級連接配接池。資料庫從每一個連接配接請求中提取出執行計劃，分析它後端引用的分區，不同的會話可以共享後端的分區連接配接。這樣某些業務的前端并發連接配接高達數十萬，而後端僅需要幾千個連接配接。
最終，研發團隊完成了一個連接配接數、qps/tps、容量線性提升，支援動态擴容的一個通用的資料庫伺服器。使用者可以使用mysql協定順利接入而不需要繁瑣的代碼改造。目前線上服務的典型使用者包括rds的新聞資料，日均tps達到20000多，前端并發連接配接日常達到8000多，每秒入庫量在50000行的級别。
<b>3、存儲優化</b>
當使用者資料量不斷擴大時，資料庫将面臨巨大的成本問題和運維問題。一個資料分區的存儲容量高達一個多tb時，一個副本損壞後的重建需要花費數天的周期。從這個角度出發，阿裡雲團隊做了如下改進：
性能與成本的平衡。使用ssd盤加sata盤組成混合存儲：ssd盤做第一級的讀寫cache，sata盤做持久化存儲。這個解決方案是阿裡團隊在facebook的flashcache上改造實作的bcache，它在不需要上層應用改制的前提下将ssd盤和sata盤組合成混合存儲。在cache命中率比較好的前提下，它的讀寫性能可以媲美flash卡，容量可以媲美sata盤。
sql優化器。該産品的存儲引擎放棄mysql主流的innodb而使用tokudb。它對壓縮有很好的支援。一些優化的較好的insert語句可以直接寫入它的根buffer，随着時間推移異步向葉節點合并。使用者的更新隻要寫入根buffer就可以立即傳回。這樣的設計對成本做了很大優化，使同等資源規格、容量比普通rds更大的執行個體的成本變為rds的1/6。
針對運維問題開發了新的遷移方案，即使用流式的方式解決遷移問題。包括使用資料庫的全量快照去做多級間的流式對反，不再通過外部存儲做中轉。同時，binlog實時地流式傳輸出去可以避免在全量遷移過程中産生較大的磁盤空間對爆。
最終，研發團隊完成了一個pb級容量的hybriddb for mysql，它的tb級副本可以在數小時内遷移完畢。根據最新資料顯示，一個1.3tb的副本可以在四小時内遷移完畢。目前線上幾個規模比較大的資料庫資料量在200至500tb左右，壓縮比在3到5倍。一個典型的業務是rds業務，240tb資料壓縮到40tb，低成本機型下隻消耗了不到32台機器，成本較以前降低了1/10左右。
物聯網中心資料庫和曆史資料業務很适合使用這樣低成本的存儲體系。在物聯網業務中，多點傳感器直接向中心資料庫彙聚資料，其對于并發連接配接的優化能夠擴大傳感器規模，再加上低廉的存儲成本，使解決物聯網場景變得格外有效；在曆史資料業務中，使用者的日志和曆史資料可能非常大并且不會被删除，例如金融、遊戲使用者等資料彙聚到這種資料庫中十分合适。
<b>4、計算優化</b>
随着線上業務的繼續擴充，使用者也提出了更多需求：資料庫是否可以在存儲之外附加更多功能讓資料更具價值？為了提供複雜查詢的能力，阿裡雲對架構做了進一步改造，即在olap領域做了進一步的改進。
阿裡雲研發團隊為該産品引入了一個全功能計算引擎，該引擎基于開源的大資料架構flink以及阿裡雲自研的mpp引擎。它将存儲分區視作通用存儲分區，将資料通過一系列算子計算後由sql接口展示給使用者。在過這個程中研發人員遇到的問題及解決政策如下：
sql相容性，即sql語句的支援程度。研發團隊改造了解析器和優化器，使其能夠支援各種sql文法。團隊選擇開源優化器生成執行計劃，并将所有的執行計劃統一在執行算子上面。這樣的架構模型類似于sparksql，但基于流式的flink使響應延遲比spark低更多。這樣的計算引擎讓複雜查詢下的并行計算能力大幅增強并讓計算能夠貼着存儲部署（本地計算可以通過本地引擎過濾）。例如存儲引擎可以過濾映射，将全局的group by、join in交給計算引擎，來保證網絡間的資料交換盡可能的少。研發團隊使用了兩層優化器：基于規則的和基于開銷的。在優化器架構下，研發人員利用存儲分區上的資料規模代價做了很多深度優化。
全局資料一緻性，即使用者通過事務更新資料時，如何保證複雜計算下資料的一緻。複雜查詢運作在獨立的計算引擎上，它無法看到之前的update資料。為此研發人員在mysql核心打了patch，暴露出資料的讀視圖，這樣就保證了通用的資料一緻性。
資源隔離，即線上ap類業務與tp類業務的資源争搶問題。資料庫對oltp業務和olap業務共享，但差別不出它們的重要性。研發人員在核心中做了patch根據sql的query級别做iops隔離。這樣，兩類業務可以單獨進行資源隔離控制，服務品質得到了單獨的保障。
這樣，研發團隊收獲了一個支援tpc-h和tpc-ds測試集的資料庫，它的複雜查詢的性能得到了大幅度的優化。目前hybriddb for mysql解決的業務主要是實時寫入實時查詢實時分析的業務，比如使用者在多點彙聚性能資料，資料既要對外部客戶做實時展現，還需要多元度聚合保證使用者看到期望的視圖展現的業務類型。典型的例子是cdn的一個業務場景，它需要将使用者各region的流量實時統計上來并對使用者做實時報表。資料量每秒入庫數萬行，查詢延遲不能超過毫秒級。
<b>5、細分場景</b>
對于olap業務而言，行存并不适合，為此研發團隊附加了列存索引。它會把行存資料build成各樣格式，比如位圖索引等。這樣資料庫在olap場景下的性能有了大幅度提升，也在olap領域提供了更多功能。在這個過程中遇到的問題及解決方案如下：
行列存引擎。列存索引build會有延時，并且不能保證全局事務的強一緻性（資料在行存上更新後不能立即在列存索引上可見）。所幸使用者可以接受這種程度的延遲。
查詢優化器。引入新的開銷模型，考慮了存儲引擎的存儲格式。由于不同索引格式适合于不同計算，資料庫在不同索引上有不同的代價模型，融入到之前的優化器架構裡面。
最終，研發團隊完成了一個在不同業務場景下去做細分的存儲結構，而且可以根據業務做自适應的優化。典型業務有線上業務實時報表，例如在電商的交易類業務中訂單資料存儲後直接做大盤統計和分析。相比于之前的高延遲，資料庫實作了實時的報表展示。
<b>6、持續創新</b>
前不久，rds團隊推出了重磅産品polardb。polardb基于共享存儲，它的思路來自于亞馬遜的aurora。
aurora将存儲和計算做了分離。它的server層隻負責非持久化的記憶體資料管理，而将持久化部分交給共享存儲。副本間的資料同步抛棄binlog使用readlog，使一緻性變得更強。資料的data格式直接在共享存儲上存放成使用者預期的innodb格式，這樣主副本完全負責寫和實時的讀操作，而備庫可以從共享存儲上取得資料但不承擔寫壓力。
rds團隊将這樣的架構引入雲資料庫産品中，也就有了polardb。polardb的引入解決了大副本的資料遷移問題。由于共享存儲中的資料已經被獨立切片，使用者不再需要關心1tb大副本的遷移問題而由共享存儲做分片間的資料搬移，這樣使效率得到提升并很容易build成多種資料格式。
polardb的引入是明年預期的目标。polardb引入後，hybriddb for mysql在oltp中的并發事務處理能力會得到很大的提升。使用polardb後，petadata可以從pb跨越到10pb的等級，這樣就可以稱hybriddb for mysql為實時海量資料庫，因為它的存儲幾乎可以不斷擴充下去。
hybriddb for mysql從一個中間件的種子逐漸成長為目前具有混和事務混合處理能力的複雜架構。使用者的大資料業務甚至是通用的混合業務都可以在petadata上嘗試，這是因為hybriddb for mysql支援不斷擴容，使用者可以從小規模資料不斷成長起來。
<b>四、産品限制</b>
hybriddb for mysql不是萬能的。研發團隊在進行分布式架構的設計時做了很多折中和犧牲。它暫不适合的業務場景包括業務結構簡單且資料量小的業務，例如百萬級的表。百萬級的表從全局取資料的代價比較高，且存儲在單機資料庫中就可以收獲較高效率。同時hybriddb for mysql也不支援一些進階特性：觸發器、存儲過程、遊标和外鍵。另外，hybriddb for mysql目前隻支援有限的分區規則：隻支援哈希分區和一個字段作為分區鍵。所幸這個限制并不太影響使用者，因為使用者使用最廣的分區規則仍然是哈希。
五、産品展望
最後，本文将介紹研發團隊對hybriddb for mysql一至兩年内的展望。
改進體驗。團隊希望使用者從小規模資料開始使用hybriddb for mysql，進而逐漸成長為大規模資料而不需要經過痛苦的改造，可以像使用mysql一樣使用hybriddb for mysql。
降低成本。
增強相容性和安全性。支援更豐富的udf和索引格式，為mysql提供更高的擴充；
支援ssl協定；支援多種字元集。
改進運維。包括引入共享存儲引擎，支援智能排程，資料的動态拆分，合理利用資源将計算和存儲貼合在一起。