HBase憑借其高可用性、高擴展性和強一致性,以及在廉價PC服務(wù)器上的低部署成本,廣泛應(yīng)用于大規(guī)模數(shù)據(jù)分析。然而,隨著業(yè)務(wù)需求的變化,HBase在某些功能上顯現(xiàn)出不足。針對HBase歷史業(yè)務(wù)場景的核心痛點,騰訊云數(shù)據(jù)庫產(chǎn)品TDSQL MySQL版(TDStore引擎)提供了適配方案,助力業(yè)務(wù)成功上云,并解決了業(yè)務(wù)多年來的瓶頸,實現(xiàn)了成本與性能的雙重優(yōu)勢。
一、引言
HBase是一個建立在Hadoop之上的分布式KV數(shù)據(jù)庫系統(tǒng),首個獨立版本于2010年2月發(fā)布。憑借其高可用性、高擴展性和強一致性,以及在廉價PC服務(wù)器上的低部署成本,HBase迅速成為物聯(lián)網(wǎng)、社交網(wǎng)絡(luò)和監(jiān)控數(shù)據(jù)存儲的首選方案,并在大規(guī)模數(shù)據(jù)分析領(lǐng)域得到廣泛應(yīng)用。然而,隨著業(yè)務(wù)需求變化,HBase在某些功能上顯現(xiàn)不足,如缺乏二級索引和不支持跨行事務(wù)等。與此同時,隨著數(shù)據(jù)庫技術(shù)不斷進步,NewSQL日益嶄露頭角,TDSQL MySQL版(TDStore引擎)采用了主流NewSQL架構(gòu),具備容器化云原生管理能力,并100%兼容MySQL 8.0語法。此外,TDStore支持原生Online DDL,可動態(tài)更改表結(jié)構(gòu),并具備高效的壓縮存儲能力,降低成本的同時支持海量存儲。本文將深入探討在歷史庫場景中使用TDStore替換HBase所帶來的成本和性能優(yōu)勢。
二、使用HBase的業(yè)務(wù)場景和痛點
HBase在擴展性以及存儲方面具備一定優(yōu)勢,能夠滿足業(yè)務(wù)系統(tǒng)的歷史庫使用需求。在過去的十多年里,許多大型公司和組織使用HBase作為海量數(shù)據(jù)的首選存儲方案。例如,在金融領(lǐng)域,監(jiān)管機構(gòu)要求金融機構(gòu)對交易記錄、客戶信息等敏感數(shù)據(jù)進行長期保存,以便在必要時進行追溯和核查。
騰訊金融科技業(yè)務(wù)系統(tǒng)的歷史庫也曾廣泛采用HBase,但使用HBase后也出現(xiàn)了一些核心痛點。
1)、業(yè)務(wù)背景
上圖是騰訊金融科技的一個充值記錄類型業(yè)務(wù)的架構(gòu)圖:
-通過binlog采集以及DTS傳輸服務(wù),增量數(shù)據(jù)消費雙寫到歷史數(shù)據(jù)的兩個HBase集群:一主一備,分布在兩個城市,具備跨可用區(qū)的容災(zāi)能力。
-超出保留時間的數(shù)據(jù)會從MySQL集群中刪除,這些數(shù)據(jù)保存在HBase中成為靜態(tài)歷史數(shù)據(jù)。
-在線庫熱數(shù)據(jù)的查詢占比95%,歷史庫HBase冷數(shù)據(jù)的查詢占比5%。
-為方便業(yè)務(wù)開發(fā),統(tǒng)一使用HBase Proxy通過SQL訪問歷史數(shù)據(jù)。
-歷史數(shù)據(jù)需要長期保存,不能刪除;隨著數(shù)據(jù)的不斷增長,使用成本在快速擴張。
2)、業(yè)務(wù)痛點
-組件多,運維復(fù)雜
1.HBase組件眾多,支持復(fù)雜查詢等功能還需引入額外工具,運維復(fù)雜。
2.此外,HBase社區(qū)發(fā)展停滯,促使我們尋找更好的解決方案。
-不支持二級索引
3.業(yè)務(wù)需要先查詢索引表,再查詢主表,鏈路長、延遲高。
-不支持跨行事務(wù)
4.只能保證單行的原子性,主表與索引表的一致性無法保證。
-容災(zāi)依賴雙寫
5.跨可用區(qū)容災(zāi)依賴雙寫,加大了程序的復(fù)雜性,且難以保證主備HBase的數(shù)據(jù)一致性。
-使用成本
6.主備2套HBase集群,需配置5-6個副本,存儲成本高昂。
7.壓縮算法默認為Snappy,如使用壓縮率更優(yōu)的ZSTD需依賴Hadoop 3.0,存在Core Dump的概率。
面對業(yè)務(wù)使用HBase的局限性,TDStore團隊主動深入分析業(yè)務(wù)痛點,最終為其提供了一套更合適的解決方案,采用TDStore替代HBase。
三、遷移后的性能和效率比較
在上述提到的充值記錄業(yè)務(wù)場景中,我們已經(jīng)成功地將HBase數(shù)據(jù)(使用Snappy壓縮)遷移到了TDStore(使用LZ4+ZSTD壓縮)。以下是遷移后性能和效率的對比分析:
1)存儲成本大幅降低
結(jié)果顯示,單副本(不包括索引)的壓縮率達到了47%,顯著降低了騰訊金融科技業(yè)務(wù)系統(tǒng)的數(shù)據(jù)庫使用成本。
同時,由于原先需要雙寫主備兩套HBase集群,現(xiàn)在只需一套TDStore實例即可滿足跨AZ的高可用。在副本數(shù)上兩者也有明顯差異,將其納入計算后,成本進一步降低。
2)業(yè)務(wù)訪問延遲降低
遷移前,業(yè)務(wù)需要先查詢HBase的索引表,再查詢主表,導(dǎo)致鏈路較長,平均耗時達到150毫秒。而遷移至TDStore后,平均耗時縮短至37毫秒,執(zhí)行效率顯著提升。
3)業(yè)務(wù)數(shù)據(jù)規(guī)范性大幅提升
HBase作為KV數(shù)據(jù)庫,其數(shù)據(jù)結(jié)構(gòu)只有鍵和值兩個元素,沒有預(yù)定義的數(shù)據(jù)結(jié)構(gòu),任何可以轉(zhuǎn)換為字節(jié)數(shù)組的內(nèi)容都可以存儲在HBase的單元格中;這就導(dǎo)致如果執(zhí)行了錯誤的PUT操作,HBase會無條件保存數(shù)據(jù),并依賴滯后的數(shù)據(jù)校驗程序去發(fā)現(xiàn)和校正。
TDStore作為關(guān)系型數(shù)據(jù)庫,使用表格形式來組織數(shù)據(jù),每個表都有預(yù)定義的列,并且每列都有預(yù)定義的數(shù)據(jù)類型。這種結(jié)構(gòu)化的數(shù)據(jù)組織方式使得數(shù)據(jù)更加規(guī)范,也避免了日常繁雜的數(shù)據(jù)校驗工作。
四、總結(jié)
四、總結(jié)作為TDSQL新一代引擎,TDSQL TDStore版具有以下的特點:
1)透明分布式
兼容性:兼容原生MySQL 8.0語法,對用戶業(yè)務(wù)層無入侵。
分布式:業(yè)務(wù)層無須手動分庫分表,使用時無需指定分片鍵,單機MySQL上的業(yè)務(wù)可以無損遷移到TDStore上。
2)高性能計算+海量存儲
計算層:不同于傳統(tǒng)的M-S模式,TDStore為多主模式,每個節(jié)點均可讀寫;單實例可支撐千萬級QPS,幫助用戶應(yīng)對突如其來的業(yè)務(wù)峰值壓力。
存儲層:采用高壓縮比的分布式存儲引擎,海量數(shù)據(jù)業(yè)務(wù)的性價比首選。
3)容器化云原生的彈性擴縮容
基于容器化平臺的管控系統(tǒng)具備云原生能力,可根據(jù)業(yè)務(wù)需求彈性擴縮容,支持業(yè)務(wù)動態(tài)負載以及容量彈性伸縮。
4)原生Online DDL支持業(yè)務(wù)的頻繁變化
支持在線加減列操作,支持在線加減索引,支持大部分DDL操作以原生Online方式執(zhí)行。使用者在業(yè)務(wù)運行過程中有動態(tài)更改表結(jié)構(gòu)的需求時,無須依賴如pt或ghost等外部工具組件。
也是因為TDStore有這些特點,歷史庫場景下的HBase業(yè)務(wù)非常適合遷移至TDStore。TDStore與HBase的功能相比,主要具有以下特征:
-長期數(shù)據(jù)保存:TDStore具有極易擴展性。
-提高數(shù)據(jù)質(zhì)量:TDStore具有嚴格約束,避免問題或錯誤數(shù)據(jù)存入庫中。從而節(jié)省修復(fù)數(shù)據(jù)的時間。
-成本敏感:TDStore具有更高的壓縮比,并在滿足容災(zāi)需求的情況下減少副本數(shù)量,從而大幅降低使用成本。
-統(tǒng)一SQL訪問:上游數(shù)據(jù)來自MySQL,業(yè)務(wù)希望統(tǒng)一使用SQL訪問兩側(cè)數(shù)據(jù)庫,HBase需要加裝phoenix或其他中間件來支持SQL,TDStore原生支持SQL接口,且性能更佳。
-更便捷的運維體驗:TDStore自主研發(fā),依托容器化管控平臺,在日常運維和升級工作中更為便捷。
TDStore正在快速發(fā)展,其在歷史庫場景中替代HBase的實踐僅是成本效益和性能優(yōu)勢的一部分。未來,我們將致力于提升產(chǎn)品性能和用戶體驗。作為騰訊云數(shù)據(jù)庫長期戰(zhàn)略的核心,TDStore將始終以業(yè)務(wù)需求為導(dǎo)向,專注產(chǎn)品打磨,為用戶提供更高效、更穩(wěn)定的服務(wù)。