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