981
曆程剖析：阿裏雲自研HTAP數據庫的技術發展之路
摘要：8月24日，阿裏雲數據庫技術峰會到來，本次技術峰會邀請到了阿裏集團和阿裏雲數據庫老司機們，為大家分享了一線數據庫實踐經驗和技術幹貨。阿裏雲高級數據庫技術專家隊皓庭分享了高度兼容MySQL，並且能免去傳統數倉ETL過程實現數據分析，同時支持高並發、大吞吐量的在線事務處理的PB級數據存儲數據庫是如何實現的，幫助大家了解了同時支持海量數據在線事務（OLTP）和在線分析（OLAP）的HTAP關係型數據庫是如何打造出來的。本文將介紹HybridDB for MySQL的定位和現狀，以及其技術演進路線和尚待解決的問題。
一、產品現狀
HybridDB for MySQL在SQL兼容性方麵做了很多的擴展，包括支持了TPC-H和TPC-DS這兩個OLAP領域的測試集。由於是阿裏雲的雲數據庫服務，HybridDB for MySQL繼承了RDS的雲服務特征，高可靠、高可用等特性一應俱全並支持在線的擴容。目前HybridDB for MySQL的線上服務規模遍及國內外十多個region，為阿裏雲及外部的用戶提供了可靠服務，總數據量已經達到TB級，日新增數據達百T級。
三、技術演進路線
1、發展起點
單機數據庫幾乎無法解決這種問題，因為它所有的數據（數據結構和磁盤存儲）都落在一台機器上，沒有辦法進行線性擴展。在並發密度高的環境下，不同並發線程間會資源爭搶。從硬件的CPU、內存，再到軟件的鎖、日誌和事務，都是線程密集爭搶的對象。因此並發越高，數據庫的整體存儲下降地愈發明顯。從這個角度出發，阿裏雲思考如何將單機數據庫的性能擴展起來？
2、合久必分
傳統解決方案利用中間件把一個大數據庫的數據切成多個分片，集成到用戶的業務代碼中提高並行能力，中間件把用戶的大查詢拆成多個小查詢，並行的計算並行的合並。這個思路讓用戶的代碼背上了沉重的中間件，不同的用戶想使用這套體係的時候還需要重複地編碼。
從這個角度出發，阿裏雲研發團隊把中間件抽取出來加入到數據庫服務器中，對外呈現同一套的數據庫訪問協議，讓用戶使用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行的級別。
3、存儲優化
- 性能與成本的平衡。使用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實時地流式傳輸出去可以避免在全量遷移過程中產生較大的磁盤空間對爆。
物聯網中心數據庫和曆史數據業務很適合使用這樣低成本的存儲體係。在物聯網業務中，多點傳感器直接向中心數據庫匯聚數據，其對於並發連接的優化能夠擴大傳感器規模，再加上低廉的存儲成本，使解決物聯網場景變得格外有效；在曆史數據業務中，用戶的日誌和曆史數據可能非常大並且不會被刪除，例如金融、遊戲用戶等數據匯聚到這種數據庫中十分合適。
4、計算優化
阿裏雲研發團隊為該產品引入了一個全功能計算引擎，該引擎基於開源的大數據框架Flink以及阿裏雲自研的MPP引擎。它將存儲分區視作通用存儲分區，將數據通過一係列算子計算後由SQL接口展示給用戶。在過這個程中研發人員遇到的問題及解決策略如下：
- SQL兼容性，即SQL語句的支持程度。研發團隊改造了解析器和優化器，使其能夠支持各種SQL語法。團隊選擇開源優化器生成執行計劃，並將所有的執行計劃統一在執行算子上麵。這樣的架構模型類似於SparkSQL，但基於流式的Flink使響應延遲比Spark低更多。這樣的計算引擎讓複雜查詢下的並行計算能力大幅增強並讓計算能夠貼著存儲部署（本地計算可以通過本地引擎過濾）。例如存儲引擎可以過濾映射，將全局的group by、join in交給計算引擎，來保證網絡間的數據交換盡可能的少。研發團隊使用了兩層優化器：基於規則的和基於開銷的。在優化器框架下，研發人員利用存儲分區上的數據規模代價做了很多深度優化。
- 全局數據一致性，即用戶通過事務更新數據時，如何保證複雜計算下數據的一致。複雜查詢運行在獨立的計算引擎上，它無法看到之前的update數據。為此研發人員在MySQL內核打了patch，暴露出數據的讀視圖，這樣就保證了通用的數據一致性。
- 資源隔離，即在線AP類業務與TP類業務的資源爭搶問題。數據庫對OLTP業務和OLAP業務共享，但區別不出它們的重要性。研發人員在內核中做了patch根據SQL的query級別做IOPS隔離。這樣，兩類業務可以單獨進行資源隔離控製，服務質量得到了單獨的保障。
5、細分場景
- 行列存引擎。列存索引build會有延時，並且不能保證全局事務的強一致性（數據在行存上更新後不能立即在列存索引上可見）。所幸用戶可以接受這種程度的延遲。
- 查詢優化器。引入新的開銷模型，考慮了存儲引擎的存儲格式。由於不同索引格式適合於不同計算，數據庫在不同索引上有不同的代價模型，融入到之前的優化器框架裏麵。
6、持續創新
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支持不斷擴容，用戶可以從小規模數據不斷成長起來。
四、產品限製
五、產品展望
最後，本文將介紹研發團隊對HybridDB for MySQL一至兩年內的展望。
- 改進體驗。團隊希望用戶從小規模數據開始使用HybridDB for MySQL，進而逐步成長為大規模數據而不需要經過痛苦的改造，可以像使用MySQL一樣使用HybridDB for MySQL。
- 降低成本。
- 增強兼容性和安全性。支持更豐富的UDF和索引格式，為MySQL提供更高的擴展；
- 支持SSL協議；支持多種字符集。
- 改進運維。包括引入共享存儲引擎，支持智能調度，數據的動態拆分，合理利用資源將計算和存儲貼合在一起。
最後更新：2017-09-04 12:32:39