## 背景 2015年7月，PetaData分布式數據庫開放了低成本存儲體系，隨后便服務了天象等多個大數據業務，這些業務存量數據在數百T，日新增10T，新增數據大多是秒級監控數據，既要數據實時可見，又要支持多維度低延遲查詢，還要大幅降低成本。 在PetaData第一代低成本存儲體系中，融合了ApsaraDB團隊多年的技術積累，包括方寸山分布式框架、MySQL TokuDB存儲引擎、低成本機型等技術，最極限的一個業務，使用了少量sata盤機型滿足了存量400T+，日新增數據10T+的更新需求，以及熱數據查詢毫秒級，冷數據查詢亞秒級的查詢需求。 隨著業務的不斷發展，第一代存儲體系面對P級存量、日新增百T的數據業務，已經力不從心，PetaData不斷探索，開發出了第二代低成本存儲體系，本文將從多個角度進行介紹。 ## 存儲架構 * 整體外觀 PetaData利用數據sharding的思想，將業務數據分布在多個MySQL實例上，這些MySQL實例是ApsaraDB團隊為PetaData深度訂制的存儲引擎，實例間share nothing，從而支持水平擴展。整套系統運行在全新設計的軟硬件一體資源容器中，并配套開發了改進的運維體系。  圖中的關鍵技術包括分布式、單機存儲引擎、遷移、軟硬件結合等部分。 * 分布式 在分布式層，PetaData利用了分庫分表的思想來支持數據sharding，數據被切分到若干數據庫分庫上，在MySQL的物理遷移和多主復制基礎上開發了快速擴容。 1. 數據分區 數據分區是大數據的普遍策略，PetaData的數據入口Proxy，將用戶的請求路由到各個存儲分區上，以達到性能的線性擴展。  由于數據分區間share nothing，對于一些多分區更新和查詢會有一定的限制，這主要從兩個方面彌補：多分區的更新通過分布式事務來支持，多分區的查詢通過計算引擎來支持。 2. 數據擴容 傳統分庫分表中間件，在數據擴容時，需要將所有數據整體做邏輯導出導入，整體開銷很大，為了避免影響用戶業務，也要將多個源分區產生的增量更新，復制到目標分區上，這對于單復制通道的數據庫極為復雜，甚至可能要分時復用復制通道。 PetaData將擴容分為全量遷移和增量復制二個階段：在全量遷移階段，使用MySQL的物理遷移，在分區間直接拷貝存儲引擎的數據文件，大幅提升全量遷移的性能；在增量復制階段，使用MySQL的多主復制，以供單個分區從多個分區復制增量數據，避免分時復用帶來的復雜性；整個擴容方案干凈而高效。 3. 異步聚合 第二代架構下，PetaData在Proxy處支持了異步聚合能力，用戶session的更新請求，送入每個存儲分區的異步隊列后便返回，由異步刷寫線程存儲分區遞送請求，用戶的session可以快速發出下一批請求，從而與異步刷寫線程的工作時序重疊起來，既提升了吞吐量，也降低了寫rt。 異步刷寫線程，也可以將同個分區的寫請求，打包成一個請求，送入存儲分區，減少存儲分區的事務開銷，有效提升存儲分區的吞吐率，異步聚合并不兼容傳統數據庫的隔離級別定義。 在存儲分區壓力過大，異步線程來不及刷寫時，異步寫會退化為同步寫，此時用戶session會暫時阻塞在單次的寫請求上，此時rt會增大，也代表著存儲分區帶寬打滿了。 * 單機存儲引擎 PetaData的單機存儲引擎，使用了MySQL-TokuDB引擎，該引擎支持事務，寫性能強勁，壓縮比高，非常適合大數據業務場景。  1. 異步更新 TokuDB引擎的數據結構為緩沖B樹，每個中間節點均帶有更新緩沖，寫入時無需將更新實時刷入葉節點，而是緩存在中間節點，然后整批向下層合并。整個過程因為事務WAL的存在，數據無需實時寫盤，而redolog本身近乎順序寫，對sata盤親和度很高，使得低成本機型有了很大的應用空間。 最優情況下，寫入根節點后，立刻返回。然后TokuDB的異步線程逐步將更新合并到葉節點，后續查詢從葉節點取回數據； 最差情況下，寫入根節點后，進行唯一性檢查，從磁盤取回頁面數據并更新，寫延遲增大。寫返會后，立刻查詢，此時只能由讀過程負責合并，增大讀延遲； 第二代架構下，ApsaraDB團隊先后為TokuDB增加了事務級并行復制等Patch，使得PetaData能適應更多的大數據場景。 2. 壓縮 TokuDB的緩沖B樹節點，頁面為4M，內部支持壓縮，即使帶上索引，日常壓縮比也通常高達4以上，這也變相地降低了大數據用戶的成本。目前TokuDB支持的壓縮算法，包括zlib、snappy等，用戶可以根據需要進行選擇，也可以支持快速的變更。 * 遷移 1. 流式全量/增量遷移 ApsaraDB的傳統遷移方案，需要先對數據庫進行熱備（熱備的數據包括數據庫完整的全量數據，以及熱備全量數據過程中產生的增量更新），將熱備出來的數據完整上傳到外部后備存儲后，在將熱備導入目標機器上。整個過程耗時很長，也易受網絡帶寬限制。 第二代架構下，ApsaraDB團隊設計了新的流式遷移模型，將熱備出來的全量數據，實時導入目標機器上，時間開銷大幅縮減。為了避免在遷移熱備數據時，過大的增量更新占滿磁盤，熱備過程中需要將binlog實時傳遞到外部后備存儲，在熱備完全進入目標機器后，再重放這部分binlog。此方案可以應對大全量、大增量的更新業務。 * 軟硬件結合 為了盡可能優化PetaData的存儲體系，ApsaraDB團隊也將硬件機型納入到存儲體系的范疇，PetaData也為低成本存儲體系選擇了更合適的硬件。 1. 混合存儲 早在阿里去IOE時代，集團就考慮過ssd盤+sata盤組flashcache的混合存儲方案，此方案在大部分場景下，既有ssd盤的訪問性能，又有sata盤的容量，成本也較為可控。 第二代架構下，PetaData選擇了類似的混合存儲方案，來進一步提升整體存儲的性價比。新的混合存儲更加穩定，且擁有更強的彈性。 2. 萬兆網絡 隨著ApsaraDB數據庫服務規模的擴大，網絡帶寬的需求愈發旺盛。PetaData的存儲分區也處于這些數據庫實例中。與ApsaraDB的其他關系型數據庫產品不同，PetaData要解決高并發讀寫的問題，而讀寫一次數據，往往需要為外部運維、審計等功能成倍的放大讀寫請求，也會嚴重增請求的流量。 第二代架構下，PetaData接入了萬兆網絡，更高的帶寬，可以極大提升備份和遷移的速度，改進產品的副本恢復策略，提升SLA。 ## 展望 PetaData定位為HTAP分布式數據庫，所謂HTAP，即為Hybrid Transactional/Analytical Processing，使用一份數據同時支持OLTP在線事務與OLAP在線分析，為此，PetaData團隊還在如下幾個領域不斷耕耘著： * 計算架構 PetaData支持的OLAP測試集包括TPC-H、TPC-DS等，并將OLAP業務劃分為： 1. 實時高并發類型：上萬級qps，秒級rt，兩階段計算迭代可以完成，數據可預建模； 2. 在線復雜分析類：個位數級qps，秒級到小時級rt，需多輪計算迭代可以完成，數據無法預建模； 這幾類業務運行在一套計算引擎框架上，輔以列存索引加速計算性能，極大地擴展了PetaData的計算能力。 * 分布式事務 PetaData在跨分區更新時，需要通過分布式事務來保證，PetaData的架構中，有分布式事務協調者，配合各個存儲分區的事務引擎，共同支持了兩階段提交分布式事務。 ## 結語 在新的存儲體系下，PetaData進一步改進了系統的吞吐量和rt，降低了成本，以迎接百T日新增數據的時代。 融合了大數據技術的PetaData，已經不僅僅是一個數據庫，而更像是一類綜合數據服務容器，讓用戶將更多精力放在大數據本身上，而無需關注外圍的成本、存儲、計算、一致性、可用性、接口等問題，降低了大數據的門檻。 PetaData的技術團隊，致力于數據服務容器本身的改進上，打造出精致的分布式數據庫服務，以迎接未來大數據的挑戰。