編者按：
9 月 10 日晚，七牛雲主辦的「雲加數據，智驅未來」數據科學系列論壇如期舉行。在直播中，PingCAP 聯合創始人兼 CTO 黃東旭爲我們帶來了主題爲《 TiDB 在實時數據分析中的最佳實踐》的精彩分享。
MySQL 作爲單機數據庫，當數據量增加時必然涉及到分庫分表等操作去換取水平擴展能力，這時候的複雜度將會呈現幾何倍的上升。TiDB 五年前的初心是想設計一個替換 MySQL 分庫分表的方案，因此 TiDB 最早的目的是想做一個既能夠像單機數據庫一樣使用，同時又擁有水平擴展能力的 OLTP 分佈式數據庫。
但是，當用戶使用 TiDB 存儲數據量越來越多後，有一個新類型的需求冒出來：用戶會想我能不能直接在 TiDB 去做一些離線，甚至是準在線的數據分析，而不是把數據轉移到 Hadoop 上。我認爲有很大一部分比例 OLAP 的需求不用做很重的 ETL，比如電商用戶，就想看一下現在賣出去多少東西，或者算一下今天賺了多少錢這種報表。但是過去的 Transaction Database 並不是爲了這種比較複雜的分析而設計的。
所以這兩年有一個新概念叫 HTAP，儘可能模糊了 OLTP 與 OLAP 的概念。過去因爲技術、數據結構、硬件、網絡等條件都不成熟，因此這兩套設計水火不容，所以在技術上強行劃分出了 OLTP 和 OLAP。我認爲在未來這些技術細節或者底層差異會越來越模糊，包括 Gartner 在一個報告中也提到，未來只會有一種 Database。所以在 HTAP 的新概念之下會有很多更新的 Workload 誕生出來。
HTAP的技術演進過程
在 HTAP 之前，互聯網公司是按照下圖所示的一個傳統架構去做在線業務和離線業務。
在業務側，OLTP 的數據可能有很多 MySQL 或者分庫分表，這些通過 Binlog 打到 Kafka 作爲消息隊列，傳送到一個近實時的系統。比如用 HBase 去做一些數據的歸攏，然後再把這個數據在 Hadoop 上用 hive 或者 Spark 這樣的技術去做大數據分析和 ETL，或者再去把 ETL 產生的數據回寫到另外的一些 MySQL，或者在另外的一些在線數據庫上對外提供服務。這是一個傳統的大數據處理架構，但這種架構的一個問題就是：在線和離線的業務是分得很開的，中間都要通過 ETL 的過程和數據的傳輸層來去串聯整個系統。
這就爲什麼有很多公司只能看到前一天的數據，因爲可能要一批一批地去加載。所以我認爲 HTAP 這個技術的方向對於用戶來說，就像智能手機對於傳統手機一樣，有了智能手機我就不再需要 GPS、單反相機、移動電話，一個 iPhone 就夠了，極大地降低了業務和架構的複雜度。另外，原來可能要維護很多套系統、很多個團隊，如果 HTAP 真的存在了，對於絕大多數業務而言只需要維護一套系統。從領導者的角度來說，運維成本和團隊人員成本都會降低。
最後一點，我認爲對於業務而言意義更大。從前我們很多決策依託的是老數據，但現在可以考慮依託實時數據。比如在一個線下商店，只要用戶進入商店，就能通過人臉識別或者會員卡馬上知道他接下來會想要去消費什麼東西，對什麼東西感興趣，從而快速做出決策。這種情況下，如果系統不是實時的就沒有意義，可能用戶看一看就流失了。所以在這些基礎之上疊加起來，可以對整個業務的迭代和敏捷程度有一個很大的提升。我認爲 HTAP 是一種新的數據庫物種，它不是傳統 OLTP 和 OLAP 的改良。
仍然以電商爲例，如上圖所示：左邊是偏交易的，右邊是偏分析的。我們把電商平臺內部系統切分成訂單管理、賬單的歷史明細、推薦、聯合倉儲實時查詢庫存、實時大屏、促銷調價、歷史報表。線上最左端是訂單管理，包括在線交易的部分，所以從最左端是靠近 OLTP 的，最右端是靠近 OLAP 的。
我們可以發現，像銷售歷史報表這種是純離線場景，及時性要求不強的，我可以明天或者下個月看到這個月的報表都不受影響。但是，實時的促銷調價、實時大屏、倉儲查詢都是偏實時的，需要根據線上訂單情況、用戶訪問情況、實時交易情況以及其他渠道的推廣情況實時去做計算。這些場景裏，過去要實現一個這種系統需要用到 Flink、Spark streaming、Kafka 等技術以及很多實時數據同步工具才能實現。
這是一個很複雜的問題，會面臨很多技術挑戰：
第一個挑戰是 OLTP 數據庫的水平擴展性，對於 OLTP 數據庫來說，拓展方案上只能用分庫分表或者在業務層面做切分。
第二個挑戰是 OLTP 系統需要同時兼具 OLAP 的能力，且同時支持行存列存。一般的 OLTP 系統都是用行存去作爲底層的存儲模型，而 OLAP 是使用列存，在查詢的效率大概差了上百倍，業務人員很難放心的在一個 OLTP 系統上去跑複雜查詢，背後是有一些風險的。因此不僅需要打消用戶的擔心，而且還需要在去跑 OLAP 端的時候能跑得快，必須得支持列存。
第三個挑戰是需要兩者有機統一而僅僅是兩套分離的系統。如果分離就會面臨互聯互通的問題，比如在 OLTP 裏邊的數據怎麼同步到 OLAP 系統裏，同步的時延大概是多少，這些都是技術挑戰。
TiDB 4.0：一個真正的HTAP系統
TiDB 最新的版本是 4.0。在我心中 TiDB 4.0 之前和 TiDB 4.0之後是兩個完全不一樣的產品。4.0 之前它是一個交易型數據庫，是 MySQL 分庫分表的很好替換，能支持海量數據的 MySQL 協議的在線業務，但它並不是一個好的數據倉庫，也不是一個好的實時分析的產品，因爲它是一個行存的數據庫，雖然用起來很方便。
而 TiDB 4.0 可以說是一個真正的 HTAP 系統：
首先 TiDB 4.0 引入了列存的存儲引擎，說明在與其它 AP 系統相比時，本質上是沒有劣勢的。
第二， TiDB 4.0 裏，計算引擎是根據列存來做向量化的，相當於利用一些 CPU 批量計算的指令集，去在比較緊湊的數據結構格式上去做很高性能計算的一種技術，這是在 OLAP 數據庫裏面經常使用的一個技術。
還有一點，在傳統的 OLAP 數據庫裏面幾乎沒法做的一個事情就是：有一些數據是在行存裏是更好的，比如一個隨機的帶索引的點查，要去大海撈針式的查詢，可能是在 OLTP 端是很好的 ，就可以直接找到數據。而列存是比較適合比如說我一張大表全部要掃描一遍，批量的掃描、批量的聚合。在 TiDB 4.0 裏面，我們用了一些技術可以把這兩種不同的存儲領域的優勢合併在一起，我們最近有一篇關於 HTAP 的論文入選 VLDB ，大家有興趣可以仔細看看。
簡單來說，整個 TiDB 的存儲和計算是完全分開的。如果大家熟悉 HBase 就會知道它裏面有 region ，每一塊數據是一塊小分片，在 TiDB 裏每一個 region 其實是一個 Raft 的複製小組。相當於我們對每一小塊數據的 Raft 複製小組裏面引入了一塊列存的副本，由於計算層跟存儲層是分開的，所以我們的計算層可以根據 SQL 來確定請求，OLAP 的請求就發到 OLAP 的副本上， OLTP 的請求就發到 OLTP 的副本上。因爲底層數據的同步，一直是通過 Raft 化整爲零的同步。第二就是說在 workload 上，你的 OLTP 業務永遠是在 TiKV 這種節點上去執行，OLAP 業務其實是在 TiFlash 的節點上執行，在原理上它是完全分開的，就硬件軟件是分開的，你就不用擔心說在這邊跑一個複雜查詢會不會阻塞這邊，而且數據的同步是完全實時的。
所以底層的核心要點在於本身 TiKV 這邊提供了一個很好的數據彈性伸縮機制，我們叫 Multi-Raft。實際上把我們所有的 data 拆成了無數個 Raft 的複製小組，我只需要清楚怎麼去支撐支持這種異構的數據源，只需要給我的 Raft 的小組裏邊多一份異構的數據副本，這就很漂亮的嵌入到了原來的 Multi-Raft 的體系裏。
而且在這一點上，它與其他的基於 Binlog、Kafka 的數據同步相比，有一個天然的優勢，就是不需要其他的 Kafka。想象一下，如果我是兩套不同的系統，左邊是 MySQL，右邊是 Hadoop，中間通過 Kafka 去同步，如果左右兩邊的數據吞吐量都特別大，Kafka 變成數據同步的過程，就會變成你的瓶頸。
所以在這一點上，TiDB 複製模式的漂亮之處在於它的數據同步的拓展是隨着數據本身的拓展是一起的，相當於把整個數據的同步過程化整爲零，拆到了每一塊數據分片裏面。
在前述 HTAP 場景下，簡單就是說一句 SQL 開啓一個表的列傳模式，後 OLTP 業務完全不用做任何修改，但同時又能直接能在數據庫上做 OLAP 的分析，這樣整體的架構的複雜度，運維的成本，業務的實質性與業務的敏捷性就有很大的提升。所以從傳統的交易分析的架構簡化成爲一個大的中央的 the source of truth 的架構，同時提供 APP 的 server 以及這種事實分析的商業智能的服務。
同時，你也可以去結合現有數倉把 TiDB 作爲一個數據的中間層，當然我並不是說他一定會去替換掉原來的這種 Hadoop，或者說這種 database 的這種模型。因爲確實有一些非實時的查詢，避免不了 ETL，但是可以使用 TiDB 架在 Hadoop 之上提升整個數據扭轉的一個實時性。
TiDB 是整體架構中的實時層的很好補充，這就是我今天的一個分享，謝謝大家。