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