作者介紹：馬曉宇，PingCAP HTAP 產品部負責人。
數據實時化成爲業務必須
數字化轉型浪潮是現在進行時，在企業數字化轉型的過程中，我們看到一個普遍的趨勢，企業對“海量、實時、在線”的數據需求變得更加迫切。數字化轉型並不是互聯網公司的專利，人工智能、大數據、物聯網這些技術也不僅僅是互聯網公司纔會使用。事實證明，越來越多的傳統企業正在應用這些新興技術進行業務的創新。每一項新技術的應用都需要一定的技術積累，互聯網公司也許會配備很多工程師來支持一個數據體系架構。但對於傳統公司來說也許不具備這樣的實力，他們會發現自己很難駕馭大數據技術棧。此外，傳統大技術棧已經慢慢開始難以應對日新月異的業務需求和爆炸性的數據增長。企業的很多業務對數據實時性的要求越來越高，比如風控、反欺詐等，更早地識別和阻斷風險可以讓企業減少損失；在物流行業，更實時的數據讓物流企業可以更實時地調配行車路線和各類資源，以達到更好的運營效率；公共服務也會對實時數據產生要求，如果去櫃檯辦理一個業務，需要等很久才能查到剛剛辦的上一個流程的數據，這對於用戶體驗來說是非常糟糕的。
用戶希望用簡單的數據庫使用體驗應對大數據到來
數據的實時化對技術本身要求非常高，一個實時化的數據技術棧，對業務和技術的複雜度提出了更進一步的需求。現實的情況往往是企業的前臺業務和離線數倉之間缺少良好的銜接，缺少一個可以與成熟大數據技術無縫銜接的體系。在企業的混合負載場景中，ERP、CRM、MES 等包含多種不同數據訪問模式，無法簡單區分 OLTP（在線交易處理） 與 OLAP（在線分析處理），DBA 需要不斷實時查詢各種不同維度的報表。以往用戶使用傳統單機數據庫承載業務，但當數據量暴漲之後，他們被迫使用更復雜的架構去重構業務系統，這個代價和時間成本通常是業務無法承受的。
舉個例子，比如 DBA 把流水賬以 OLTP 的方式來錄入，同時有一部分數據是轉存到離線數倉之中提供報表查詢。在這樣的數據架構中，數據鏈路變得非常複雜：首先應用服務器同時面對數倉類和 OLTP 類的數據庫，這兩類數據庫之間還要搭建 T+1 的 ETL 數據處理流程，從而使兩者能共享數據。前端的業務也會面臨直接跟應用服務器打交道或者從大數據技術棧撈取數據的情況，這對於應用架構來說非常複雜。更進一步而言， SaaS 或應用軟件供應商會覺得尤其痛苦，因爲他們要面對客戶的所有系統，技術棧的複雜度和維護難度將呈指數級上升。
在流式計算場景中，基於大數據或者互聯網架構，通常得把日誌流傳向後端，然後進行日誌和行爲分析。傳統業務在使用流計算場景的時候，更多的時候前端可能是 OLTP 類的數據庫，通過 CDC （Change Data Capture 變更數據捕捉）組件向下遊輸出帶有“刪”和“改”不同類型操作的數據日誌。這些日誌在傳統的架構下，並沒有一個非常好的技術棧去處理。對於下游來說，根據不同的業務需求，也會派生出不同的數據存儲去存放和應對這些不同的數據請求。
如果希望承載 CDC 的日誌，要求下游的數據庫也能實現實時的對應“刪”和“改”，或許可以選 MySQL，但選擇傳統單機數據庫遇到經常遇到的問題是在海量數據下沒有辦法做很好的擴容。如果選擇既可以擴容、又支持刪改的，第一個可能想到 NoSQL 數據庫，但是 NoSQL 沒有辦法進行復雜的數據分析，即使用來做數據分析，也無法達到理想的性能。所以這兩種選擇在數據量增長的數據分析場景都不太適用。
還有一些其他的選擇，比如 Elasticsearch，他其實是一個搜索引擎，如果用來做聚合，就會面臨靈活性喪失的問題。此外還有傳統的 MPP，他是根據傳統 T+1 數倉入庫的流程而設計的，所以無法很好地應對數據的實時更新，尤其是 CDC 類的數據更新。
綜上所述，無論是從數據鏈路層，還是到整個下游的承載，目前都缺少成熟的方案來應對，這就造成了很多時候數據架構師們會把不同的技術架構棧組合在一起以滿足業務層的需求。 舉個例子，企業的某種業務包含多個子需求，這些子需求需要多種查詢系統或者多種數據平臺聯合起來工作才能完成，這就造成了企業整個數據架構棧會變得非常複雜，而且棧和棧之間數據的一致性和時效性無法保障。
在 2000 年互聯網浪潮還沒有到來之前，大多數企業已經在建設上一代的數字化，主要是通過使用數據庫來實現的。單體數據庫在那個階段可以能勝任大多數不同的業務需求，所有的數據訪問需求其實都應該由數據庫來完成，而不是由各種各樣複雜的組件來完成。尤其對於傳統企業來說，他們更傾向有一個更像傳統數據庫的技術解決方案來降低技術轉型的門檻，這套方案在提供傳統數據庫體驗的同時，還能給數字化轉型帶來的業務和規模複雜度提供等量的支持。
從大數據技術的發展趨勢可以看到，Hadoop 這類傳統的大數據技術棧前行的腳步在放緩，整個傳統的大數據技術棧已經達到了應有的成熟度，遇到了相應的天花板，要想達到類似成熟數據庫一般的體驗，幾乎是不可能的。在技術發展變緩的前提底下，現有的產品仍然無法達到企業期待的成熟度，於是企業開始尋找其他理想的方案。企業期待中的理想方案是怎麼樣子的？首先，可以應對不斷膨脹的數據規模 ；其次，需要應對不同作業類型所需業務模型的技術能力 ；最後，需要像經典數據庫一樣架構簡單，使用和維護也更加簡單。 在 TiDB 4.0 中，HTAP 架構是由 TiKV 和 TiFlash 共同組成的行列混合的存儲架構引擎，使用 TiDB 作爲共享的 SQL 入口，共享前端，用同樣的數據權管控，優化器會自動根據代價來選擇行存或者列存。4.0 架構不完美的地方主要體現在存儲和計算能力之間的不匹配。從存儲節點而言，TiKV 或者 TiFlash，舒適區是在數據量幾百 TB 這個級別。從算力上講，TiDB-Server 雖然可以多機部署，但是多機部署本身無法實現多機協同，缺少共同做一個大複雜查詢切分的能力。形象一點進行比喻，在 TiDB 4.0 以及 4.0 之前，TiDB 擁有非常大的數據存儲能力就像小熊龐大的身體，但計算能力就像小熊的頭部，兩者是不成比例的。
在 TiDB 5.0 的 HTAP 體系中，TiFlash 已經不僅僅是一個列式存儲引擎這麼簡單。TiFlash 引入了 MPP 模式，使得整個 TiFlash 從單純的存儲節點升級成爲一個全功能的分析引擎，保留單一的入口，使用用同樣的權限控制，OLTP 和 OLAP 仍然是由優化器提供自動的選擇。
TiDB 4.0 中， OLTP 和 OLAP 的選擇只涉及選擇行存或者選擇列存，5.0 可以提供更加多維度的選擇，例如選擇 MPP 引擎或者選擇用單機來進行計算。在架構更新的同時，TiDB 5.0 基於 MPP 引擎，提供了超越傳統大數據解決方案的性能。
TiDB 5.0 HTAP 架構設計
TiDB 5.0 HTAP 架構圖中，可以看到右下角的 Storage Cluster 是整個 TiDB 的存儲引擎，包含 TiKV 節點，使用的是行式存儲，所謂行式存儲就是一行的數據會連續存放在相鄰的位置。TiFlash 節點使用的是列式存儲，列式存儲的含義就是不同行當中同一列數據會相鄰存儲在一起，行和列分別會應對不同的業務需求，行存傾向於響應 OLTP 類業務。
一般 OLTP 類業務是少量查詢個別的行，進行修改，然後再進行回寫，業務希望儘可能地把所有一次操作的數據都放在同一個地點，這就是行存具備的能力。列存一般用來響應報表類和 BI 類請求，例如從一個相當寬的表當中選出其中幾列進行篩選和聚合，在這個場景，列存可以選擇其中需要讀到的列，而不用去碰那些不用的列，而這在行存當中是無法實現的。此外，列存引擎也會更好地配合向量化引擎，做到從磁盤讀取或者到內存計算，都是一個向量的方式來進行數據的排布，這是對 BI 和分析型引擎最好的加速。
在 TiDB 5.0 中，TiFlash 會全面補充 TiDB 的計算能力，TiDB 在 OLAP 場景下就會退化成一個 master 節點，PD 職責沒有任何變化。基於 MPP 架構，用戶會向 TiDB Server 發送查詢 SQL，這個查詢 SQL 會由共享的 TiDB 服務器來承擔。這些 TiDB 服務器會進行 Join，然後交給優化器去決策。優化器會把使用行存、列存、某些索引、單機引擎、MPP 引擎，或者是使用不同組合產生不同的執行計劃，都納入到同一個代價模型中進行評估，最後選出一個最優的執行方案。假設業務需要根據某一個人的訂單號去查詢當前的訂單，這是一個點查的查詢，優化器將直接向 TiKV 發送點查請求。如果業務有一個報表類查詢需求，需要關聯百萬甚至千萬級別的表，並在關聯的結果之上再進行聚合與分析，這就是一個 典型的 MPP 加列存的查詢，優化器就會把這部分查詢下發給 TiFlash 的分析型引擎節點進行計算。
上圖是分析型引擎的執行計劃拆分和處理流程的示意。圖中所有紅色的虛線框都代表一組節點的物理邊界，例如右上角的一個查詢，需要 SELECT COUNT 兩張表的關聯，並按照條件排序。這樣的一個表查詢就會被拆分成一個查詢計劃，有兩組機器進行掃描，這兩組機器可能是共享同一組硬件資源，有一組節點負責掃描左表，有另一組節點負責掃描右表，兩個節點分別按照關聯查詢條件 Join 數據，同樣的數據會被關聯到一起，屬於同一個分片的數據都會到達同一組機器或者同一個機器上，機器再進行局部的關聯，把結果合併產生一個完整的結果，最後進行聚合後返回給用戶。這就是整個 MPP 架構帶來的好處，類似 Join 這樣大規模的查詢，可以很方便地通過多節點來進行分擔。
很多人關心 MPP 引擎到底有多快，這裏展示了一個真實場景對比測試的結果。在三節點 TPC-H 100GB 環境下，主表達到幾億規模的數據量，查看在同等的硬件和資源投入下測試執行不同 Query 所需要的時間。從測試結果可以看到，對比 Greenplum 6.15.0 和 Apache Spark 3.1.1，TiDB 5.0 MPP 展示了更好的性能加速，總體獲得 2 - 3 倍的性能優勢，個別查詢可達 8 倍性能提升。
在 TiDB HTAP 底下用戶只要寫 SQL 就好
相對於 TiDB 4.0 來說，TiFlash 已經不僅僅是一個列式存儲引擎，已經進化成爲一個完整的計算分析引擎，最終實現了把 OLTP 和 OLAP 完整地合二爲一，使用同一個前端，數據庫就回到了接近於最初經典形態的樣子。一個數據庫其實可以同時處理各種形式的查詢，數據庫只要保證以儘可能高效的方式運行，返回用戶應該有的結果就行了。用戶只管寫 SQL，只管對提出查詢或者寫入需求，不用管業務是 OLTP 還是 OLAP，TiDB 提供統一入口，同一份邏輯數據，兩種存儲格式，依靠前端優化器自由選擇最優的執行方式，對用戶屏蔽了底層架構的複雜度，用戶只管寫 SQL 就可以了。
在混合負載場景下，使用 TiDB 可以承載 OLTP 類業務，同時使用 TiFlash 加速實時報表，加速對分析業務的查詢響應。從架構上來說，以往需要有不同的數據鏈路去維護不同數據引擎之間的數據流轉和存儲，現在對用戶而言只需要一個入口，一個 APP Server，不同的業務類型可以不加區分地接入這個 APP Server，APP Server 向 TiDB 發送請求，TiDB 將不同的業務向不同的引擎進行分流和加速，整套技術架構棧變得非常簡潔。
數字時代，越來越多的業務對實時分析的需求更加迫切，在流式計算場景下，對於傳統的日誌流分析的需求，大數據提供了比較成熟的解決方案。在聯機交易或者要求傳統 OLTP 類數據庫傳輸帶有刪改的數據，以及帶有 Join 數據的場景下，TiDB 就是目前最理想的方案。
首先，TiDB 是一款真正的 HTAP 分佈式數據庫，可以非常方便地作爲一個從庫，掛接在 Oracle 或者 MySQL 這樣的數據庫後面，不需要複雜的數據同步手段，藉助 Kafka 或者其他數據管道來進行同步即可。TiDB 可以掛在 MySQL 後面作爲從庫或者作爲 Oracle 的一個複製目的地。與此同時，如果業務希望做一些數據處理的話，也可以隨時切換到傳統的數據架構上。
TiDB 本身是一個帶有 OLTP 類屬性的 HTAP 數據庫，對於任何實時的刪改增落地，TiDB 是可以達到實時響應，整條數據鏈路可以實現秒級查詢。TiDB 本身的行列混合屬性也意味數據落地不論是明細數據的明細查詢，還是對於數據的各種不同維度的實時聚合，都可以很好地響應。
在數據中樞場景中，假設前端有多個業務線，每個業務線都有自己不同的 OLTP 類數據庫，例如財務、EPR、銷售、倉儲數據庫，有 Click Stream、有 User Profile、也有產品庫，還有用戶登錄和第三方不同的數據源，這些數據存放在各自的數據庫中，可以通過 CDC 的方式或者通過 Kafka 實時集成到 TiDB 裏面。這些從不同數據源、不同業務線整合過來的數據，可以放在數據中樞層。
數據中樞層是相對於離線的數倉層來說的一個概念，首先他只存放一部分時間段內的數據，而數倉可能會放更久遠的歷史數據；數據中樞層更傾向於是存放溫和熱的數據，可以提供實時的數據存取和查詢服務。相對於大數據和離線數倉層而言，數據中樞可以直接對接數據應用端，作爲一個既可以承接高併發訪問，又能夠以數據服務的形式來提供全量數據的存取，而離線數倉和數據湖更傾向於離線的方式，通常提供不太新鮮的數據來進行報表與 BI 類查詢。
當 TiDB 集成到整個數據平臺當中，他充當了一個數據中樞的角色。即使數據平臺中已經有了離線數層和 Hadoop 平臺，仍然可以把 TiDB 放在業務層、Hadoop 層，或者在數據倉庫層之間，作爲提供一個實時數據存儲和管理的平臺，用來滿足越來越多用戶對於實時存取與實時分析的需求。
從以上幾個場景可以看到，TiDB 的能力已經超越了一個分佈式關係型數據庫本身，隨着 5.0 MPP 功能的引入與多項企業級特性的增強，TiDB 已經發展成爲“一棧式數據服務生態”，即“one stack to serve them all”。在這整個數據服務生態中，並不只有 PingCAP 在創造和建設，廣大社區小夥伴們參與了這套生態的共建和迭代，總計有 538 位 Contributor 提交了 12513 個 PR 協同 PingCAP 一起完成 5.0 這個里程碑版本的開發。例如知乎，給社區貢獻了多個大數據生態相關的組件和生態工具，對於大體量用戶的業務場景極具應用價值。
我們相信開放和透明的協作，必定會創造出全新的、無限的可能性，把 TiDB 打造成爲一個更加完善的“一棧式數據服務生態”，我們一起在路上。