HTAP會成為資料庫的未來嗎？
在互聯網浪潮出現之前，企業的數據量普遍不大，特別是核心的業務數據，通常一個單機的資料庫就可以保存。那時候的存儲並不需要複雜的架構，所有的線上請求 (OLTP, Online Transactional Processing) 和後台分析 (OLAP, Online Analytical Processing) 都跑在同一個資料庫實例上。
隨著互聯網的發展，企業的業務數據量不斷增多，單機資料庫的容量限制制約了其在海量數據場景下的使用。因此在實際應用中，為了面對各種需求，OLTP、OLAP 在技術上分道揚鑣，在很多企業架構中，這兩類任務處理由不同團隊完成。當物聯網大數據應用不斷深入，具有海量的感測器數據要求實時更新和查詢，對資料庫的性能要求也越來越高，此時，新的問題隨之出現：
1、OLAP 和 OLTP 系統間通常會有幾分鐘甚至幾小時的時延，OLAP 資料庫和 OLTP 資料庫之間的一致性無法保證，難以滿足對分析的實時性要求很高的業務場景。
2、企業需要維護不同的資料庫以便支持兩類不同的任務，管理和維護成本高。
因此，能夠統一支持事務處理和工作負載分析的資料庫成為眾多企業的需求。在此背景下，由Gartner提出的 HTAP（混合事務 / 分析處理，Hybrid Transactional/Analytical Processing）成為希望。基於創新的計算存儲框架，HTAP資料庫能夠在一份數據上同時支撐業務系統運行和OLAP場景，避免在傳統架構中，在線與離線資料庫之間大量的數據交互。此外，HTAP基於分散式架構，支持彈性擴容，可按需擴展吞吐或存儲，輕鬆應對高並發、海量數據場景。
目前，實現 HTAP 的資料庫不多，主要有 PingCAP 的 TiDB、阿里雲的 HybridDB for MySQL、百度的 BaikalDB 等。其中，TiDB 是國內首家開源的 HTAP 分散式資料庫，接下來，本文將以此例進行深入分析。
TiDB 的理論基礎來源於 2013 年 Google 發布的 Spanner / F1 論文 ，以及 2014 年 Stanford 工業級分散式一致性協議演算法 Raft 論文。在架構上，TiDB 將計算和存儲層進行高度的抽象和分離，對混合負載的場景通過 IO 優先順序隊列、智能副本調度、行列混合存儲等技術，使 HTAP 變為可能。
參考 Google Spanner / F1 的設計，TiDB 整體架構分為上下兩層：負責計算的 TiDB Server 和 負責存儲的 TiKV Server，二者由集群管理模塊 PD Server 調度和管理。
根據PingCAP 高級技術總監、CMC 成員、華南區總經理姚維最近的《TiDB性能設計及鯤鵬平台優化實踐》演講，TiDB Server對應於 Google F1， 是一層無狀態的 SQL Layer ，其本身並不存儲數據，只負責計算。在接收到SQL請求後，該計算層會通過 PD Server 找到存儲計算所需數據的 TiKV 地址，然後與 TiKV Server交互獲取數據，最終返回結果。在水平擴展方面，隨著業務的增長，用戶可以簡單地添加 TiDB Server 節點，提高資料庫整體的處理能力和吞吐。
作為整個集群的管理模塊，PD（Placement Driver ) 主要工作有三類：一是存儲集群的元信息；二是對 TiKV 集群進行調度和負載均衡，如數據的遷移、Raft group leader 的遷移等；三是分配全局唯一且遞增的事務 ID。
TiKV Server是一個分散式 Key Value 資料庫，對應於Google Spanner ，支持彈性水平擴展。不同於 HBase 或者 BigTable 那樣依賴底層的分散式文件系統，TiKV Server在性能和靈活性上更好，這對於在線業務來說非常重要。隨著數據量的增長，用戶可以部署更多的 TiKV Server 節點解決數據 Scale 的問題。PD 模塊則會在 TiKV 節點之間以 Region 為單位做調度，將部分數據遷移到新加的節點上。
總體來看，TiDB 具備如下核心特性：
水平線性擴展
強一致分散式事務
故障自恢復（auto -failover）的金融級高可用（非主從）
真正跨數據中心多活
據了解，TiDB 對業務沒有任何侵入性，能夠替換傳統的資料庫中間件、資料庫分庫分表等 Sharding 方案。同時它也讓開發運維人員不用關注資料庫 Scale 的細節問題，專註於業務開發，大幅度提升研發生產力。目前，TiDB已被近千家不同行業的企業引入到實際生產環境中，涉及互聯網、遊戲、金融、政府、電信、製造業等多個領域，並得到成功應用。
姚維在接受 InfoQ 採訪時表示：「2020 年是 PingCAP 的里程碑年。」在今年的 5 月底、6 月初，PingCAP 將發布 TiDB 重要的 4.0 版本。該版本將會在性能、易用性、易管理性等方面有明顯的增強， 事務處理能力方面也有大幅度提高。
除此之外，在 4.0 版本上真正實現了 HTAP 功能。簡單來說，用戶可以在一套資料庫上同時運行截然不同的計算負載，即聯機交易的計算負載和海量數據的實時分析。此前，在資料庫領域，這兩種計算還不能完全放在一起，因為它們對資源的消耗、對計算本身的性能要求，以及對數據的處理方式是完全矛盾的。
姚維表示：「我們經過兩年多的內部開發，終於將 OLAP 和 OLTP 真正放在同一套 TiDB 集群上，讓 TiDB 可以同時支持聯機交易和海量的數據分析。並且這兩種計算在內部轉換的過程對用戶是透明的。」通過底層數據同步及行列透明轉換的技術，TiDB 將 TiKV 面向聯機交易的行存式引擎與 TiFlash 面向實時分析場景的列存引擎，轉為真正的行列混合數據架構。同時，該版本在 TiDB 分散式計算層實現了透明的可根據請求自動選擇行列存儲引擎的能力，使高並發、低延遲的聯機交易與海量數據實時分析查詢計算，在 TiDB 新一代架構上完美地融合在一起。
在演講中，姚維也為我們展示了 TiDB 4.0 版本性能優化的部分成果（圖中的縱軸是指語句耗時，該值越低代表性能越好）：
和很多企業一樣，PingCAP 也是雲的用戶，數據中心的上百台機器在雲上 24 小時不停運轉著。
姚維感慨道：「雲給我們的業務帶來了看得到的便利，比如降低成本、提高效率、靈活性高等，這些好處都是實實在在的。因此，我們相信，未來雲一定會成為主流的方向。TiDB 在過去兩年時間裡面已經在做雲的適配。TiDB 跑在雲上，底層有很強的計算能力、擴展能力，以及完備的基礎設施和基礎網路作為支撐，再加上資料庫引擎本身的自動橫向彈性伸縮能力，其整體所提供的能力很多用戶非常想要獲得。」
在企業全面上雲的大背景下，資料庫因其成本昂貴、高運維難度、以及低擴展性和可用性受到挑戰，尤其是對傳統的資料庫而言，在服務用戶的過程當中往往沒有辦法滿足用戶上雲的很多需求。而雲計算 資料庫將帶來更低的運營成本、更高的靈活性，以及與未來物聯網、5G 結合滿足龐大而複雜數據需求的能力。將資料庫「搬」到雲上，將成為未來資料庫發展的主旋律。
在研發 TiDB 的 Cloud 版本過程中，PingCAP 前期主要在與 x86 架構適配。如今，基於用戶對異構平台的需求，PingCAP 主要在做 TiDB 在鯤鵬計算平台上的性能優化。根據姚維的介紹，除了市場訴求外，在技術層面還有以下兩個主要原因：
1、來自分散式資料庫的底層需求。x86 平台現在雖然比較成熟，但該架構的擴展性具有比較明顯的限制。TiDB 在 x86 架構和 ARM 架構上最大的一個差異在於單台伺服器上 CPU 核的數量。因為在固定的情況下，分散式資料庫意味著需要多台伺服器來組成該集群。PingCAP 在與用戶合作的過程中發現，很多企業希望採用具有更多核心的伺服器。x86 架構的伺服器多為 64 核，而基於鯤鵬高密度的 CPU 核架構，資料庫的性能可以有很大的提高。
相應地，對用戶而言，部署成本也會有所降低。當單台機器 CPU 核數增多，處理能力會隨之增強。在達到同樣性能的情況下，採用 ARM 架構的機器台數要比 x86 架構下少。機架、伺服器、電源、交換機等周邊費用，也會有比較明顯的降低。
2、ARM 的指令級不同於 x86 複雜的指令級，其在語言的優化層面有較大的空間。TiDB 有兩種開發語言，其中，與資料庫性能息息相關的存儲引擎 TiKV 採用的是 Rust 語言，這是一種支持並行的編譯型語言，通過優化該語言對鯤鵬處理器架構有比較好的支持性，同時也為編譯器等底層的進一步優化提供了空間。
在 TiDB 遷移到鯤鵬計算平台的過程中，PingCAP 做了深入的性能優化，其中涉及諸多層面和細節，僅代碼上的重要優化少則有幾十項。姚維為我們介紹了其中對 TiDB 性能影響較大的三個優化工作：
1、在源碼適配上，TiDB 底層使用 Rust 語言編寫，上層的分散式計算引擎採用 Go 語言編寫。TiDB 轉移到鯤鵬計算平台上，需要將 TiDB 的源碼與該平台進行適配。根據姚維的介紹，在適配過程中，超過三分之一的優化工作都是由編譯器自身機制來完成。
2、在存儲引擎上，TiDB 中的數據被打散在多個節點上，每一個節點中都會有部分的數據存儲以及數據冗餘副本。在存儲引擎框架負責單節點的數據存取操作時，保證數據在內存、磁碟、操作系統、文件系統、存儲等各個層面的準確性至關重要，這就需要資料庫內部有一個足夠強壯的檢查機制。
TiDB 通過調用多種校驗核的計算方法來實現上述檢查。在 x86 上，由於核數不多，該架構上的核心不僅要承載 TiDB 自身的任務處理請求，如資料庫的增刪改查等運算，還要擠出一部分資源用於校驗的計算。而在核數較多的鯤鵬平台上，與數據校驗有關的計算可以利用更加寬裕的處理器核資源執行。這類高密度數值類的計算優化，為資料庫的性能帶來了比較大的影響。
3、在網路吞吐的中斷上，雖然中斷與網卡有關，但也和 CPU 處理網路隊列的方式有直接的關聯。因此 TiDB 遷移到鯤鵬平台上後，PingCAP 基於 ARM 對網路相關的架構進行了優化和適配，以實現更加穩定高效的集群間通訊。
在整個優化過程中，PingCAP 進行了一輪又一輪針對各項的嚴格測試，對資料庫穩定性基準、性能基準也在做反覆的核驗工作。在演講中，姚維也為我們直接展示了 TiDB 在鯤鵬平台上的性能優化成果：
對於用戶來講，這些優化工作最直接的效益就是在成本可控的情況下，能夠大幅度提高整個資料庫的服務能力，這也是任何產品在用戶心中最核心的價值考量。
無論是多大體量的用戶，在數據中心未來持續發展的規划過程中，性價比是不得不考量的一個要素。隨著集群規模的加大，如果單台集群的性能優化成本很高，那麼總體的成本將非常可觀，這其中包括不可避免的機房、機架、供電、高端的配設網路等基礎設施支出。TiDB 與 ARM 架構的適配，在同樣的處理能力甚至更高密度的處理能力之下，可以幫助用戶實現總體應用成本不升反降的效果。
傳統技術在市場上的衰弱和退出，意味著新機會的產生。隨著人們對計算、存儲、網路等層面的要求越來越高，新技術將迎來更多的機會，這也是 IT 界自然迭代的過程。無論是 TiDB 的出現，還是 TiDB 在鯤鵬平台上的遷移實踐，都為後續更高性能和更高性價比的資料庫發展帶來了足夠的信心。
