摘要：?2017云棲大會(huì)Hbase專場(chǎng)，阿里巴巴技術(shù)專家天穆帶來Ali-HBase的SQL實(shí)踐與改進(jìn)的演講。本文主要從為什么需要SQL開始談起，進(jìn)而講解了SQL on Hbase，接著著重分享了Ali-Hbase SQL的優(yōu)化與改進(jìn)，最后對(duì)未來進(jìn)行了展望。

2017云棲大會(huì)Hbase專場(chǎng)，阿里巴巴技術(shù)專家天穆帶來Ali-HBase的SQL實(shí)踐與改進(jìn)的演講。本文主要從為什么需要SQL開始談起，進(jìn)而講解了SQL on Hbase，接著著重分享了Ali-Hbase SQL的優(yōu)化與改進(jìn)，最后對(duì)未來進(jìn)行了展望。
以下是精彩內(nèi)容整理：

為什么需要SQL？

時(shí)間序列數(shù)據(jù)的存?。喊凑諘r(shí)間順序追加新記錄，按照時(shí)間范圍查詢數(shù)據(jù)，查詢結(jié)果按時(shí)間倒排。我們數(shù)據(jù)是按照時(shí)間產(chǎn)生的，最新寫的數(shù)據(jù)一定寫在表頭，在分布式情況下所有操作都落在表頭，這臺(tái)服務(wù)器必然會(huì)成為熱點(diǎn)。

Hash散列

解決寫熱點(diǎn)問題就是打散、隨機(jī)分布，任何一個(gè)操作都可以隨機(jī)地放在表格里面。這帶來一個(gè)新的問題，整個(gè)表不是有序，一旦時(shí)間有序就會(huì)產(chǎn)生寫熱點(diǎn)。

分桶

我們需要做一些折中，也就是分桶，我們對(duì)它做一個(gè)取模的操作，任何一次操作都可以落在隨機(jī)的“桶”里面，數(shù)據(jù)在桶內(nèi)是有序的，可以按照時(shí)間范圍來查詢。代價(jià)是范圍查詢時(shí)必須并發(fā)查所有桶。在查完所有桶以外需要進(jìn)行一次合并。

我們來查時(shí)間范圍，先查第一個(gè)分桶，再查第二個(gè)和第三個(gè)分桶，得到了70、60、50的結(jié)果。分桶方案其實(shí)在一定程度上提升了讀的性能。

基于HBase Native api的實(shí)現(xiàn)

現(xiàn)在說的場(chǎng)景是經(jīng)過高度抽象的場(chǎng)景，實(shí)際的場(chǎng)景不可能這么簡(jiǎn)單，即使在簡(jiǎn)單的場(chǎng)景下就需要做這么多事情。我們HBase API要想用好Hbase就需要很多額外的事情，需要寫非常多的代碼。學(xué)習(xí)成本也是非常高的，如果想很精準(zhǔn)地使用是需要有技巧的，很多東西都要靠經(jīng)驗(yàn)，用戶在利用HBase API的時(shí)候要付出很高的學(xué)習(xí)成本和開發(fā)成本。大部分的HBase用戶都會(huì)遇到這些類似的問題，而且每個(gè)用戶都需要了解怎么去解決這些問題，使用了HBase API以后可以對(duì)自己的業(yè)務(wù)做到完全地把控。

SQL on HBase

為什么HBase API這么難用，說到底就是太底層了，提供“原語(yǔ)級(jí)別的操作。我們希望能夠降低用戶的接入門檻，能夠低成本低接入Hbase，怎么做這件事情？阿里HBase大部分場(chǎng)景都是比較簡(jiǎn)單的，并且有共性，所以我們希望能夠引用中間層，大部分人都能夠用到。中間層就是SQL，SQL能夠替代API成為HBase的默認(rèn)戶接口。

基于Phoenix的SQL ON HBase解決方案，Phoenix就是針對(duì)HBase來設(shè)計(jì)的，而且Phoenix在HBase之間也可以結(jié)合得非常好，這也是我們選擇Phoenix的一個(gè)主要原因。
支付寶智能搜索dump平臺(tái)

支付寶智能搜索Dump平臺(tái)，左邊的數(shù)據(jù)源是各種各樣的業(yè)務(wù)數(shù)據(jù)庫(kù)，可能是MYSQL，可能是HBase的，對(duì)業(yè)務(wù)數(shù)據(jù)庫(kù)的變更操作會(huì)同步到HBase集群里面很多張維表里面，對(duì)維表生成寬表。對(duì)于HBase來講，這個(gè)場(chǎng)景除了實(shí)時(shí)寫之外還有很大的全量導(dǎo)入。讀是通過很多的全局二級(jí)索引，經(jīng)常變更的索引表。因?yàn)樗阉鞯臉I(yè)務(wù)，用戶的需求經(jīng)常發(fā)生變更，這樣對(duì)應(yīng)我們的索引表發(fā)生變更，雖然有一些成本，但是相比MYSQL來講，這個(gè)變更的成本是可以接受的。因?yàn)闃I(yè)務(wù)增長(zhǎng)比較快，所以線性擴(kuò)容也是關(guān)鍵點(diǎn)。

商品報(bào)表

商品報(bào)表是另外一套吞吐型的業(yè)務(wù)，它也有實(shí)時(shí)的全量寫，而且也需要二級(jí)索引來生成多維報(bào)表。這個(gè)報(bào)表的場(chǎng)景跟DUMP場(chǎng)景不一樣，這個(gè)單表比較大，在我們業(yè)務(wù)里面最大的表在壓縮之后有80個(gè)TB。

物聯(lián)網(wǎng)設(shè)備信息存儲(chǔ)

物聯(lián)網(wǎng)場(chǎng)景也非常典型，讀寫相對(duì)比較簡(jiǎn)單，但是數(shù)據(jù)量特別大，而且寫得很快。在這種情況下，存儲(chǔ)的成本以及寫的吞吐能力、擴(kuò)容能力HBase比較擅長(zhǎng)。在吞吐成本這塊，我們采用冷熱分離存儲(chǔ)以及壓縮算法降低成本。
HBase SQL的場(chǎng)景基本上都是HBase自己的場(chǎng)景，海量的數(shù)據(jù)、線性擴(kuò)展等等，但是HBase有了查詢的語(yǔ)意，從而拓展了HBase的業(yè)務(wù)邊界。

Ali-Hbase SQL

為了支持這些場(chǎng)景，我們?cè)贖Base做了很多的優(yōu)化和改進(jìn)，在HBase本身我們針對(duì)阿里的場(chǎng)景做了很多性能和功能上的變革。在穩(wěn)定性方面，我們做了很多工作，能夠讓HBase久經(jīng)雙十一沙場(chǎng)。Ali-HBaseSQL與Phoenix在功能補(bǔ)齊、功能增強(qiáng)、數(shù)據(jù)導(dǎo)入導(dǎo)出方面有所改善。Phoenix本身需要人去指定一個(gè)索引表，我們把這個(gè)事情自動(dòng)化了，同時(shí)增強(qiáng)了可以訪問多張索引表的能力，數(shù)據(jù)可以在各個(gè)系統(tǒng)之間產(chǎn)生流動(dòng)。

性能優(yōu)化

目標(biāo)是將簡(jiǎn)單請(qǐng)求的性能優(yōu)化到極致，與對(duì)應(yīng)的HBase Native API性能差距小于5%。單行讀寫的場(chǎng)景下，SQL和HBase API的差距很明顯。
客戶端的元數(shù)據(jù)緩存，元數(shù)據(jù)：列名、數(shù)據(jù)類型、表屬性、索引信息等等。元數(shù)據(jù)更新策略：并不是每次都刷新元數(shù)據(jù)，我們做了周期性的刷新，通過版本號(hào)的方式來識(shí)別是不是最新的，如果不是最新的就更新一版，這是優(yōu)化UPSERT的緩存更新策略。

SELECT優(yōu)化，我們會(huì)根據(jù)油壺請(qǐng)求的大小來合理選擇適用，這個(gè)選擇對(duì)性能影響非常大，因?yàn)槲覀兊哪繕?biāo)是優(yōu)化簡(jiǎn)單的請(qǐng)求，優(yōu)化一點(diǎn)點(diǎn)在用戶那邊的體現(xiàn)都是非常明顯的。我們并不是分析型的場(chǎng)景，并不需要數(shù)據(jù)的預(yù)取，做到這些事情以后讀的性能已經(jīng)跟HBase Select比較接近了。
此外，阿里云上的SQL，從其他的RDBMS遷移至云HBase。

未來的工作

未來一定是支持列名映射，支持ImmutableDataEncoding，我們現(xiàn)在正在調(diào)研，在大寬表的情況下能夠節(jié)省1/3—1/2的存儲(chǔ)空間。但是有一個(gè)限制，這個(gè)數(shù)據(jù)只能寫下去，不能改。我們要優(yōu)化功能都需要讓用戶去申請(qǐng)SQL的客戶端，這是非常惡心的事情；支持query server mode和瘦客戶端，解決了產(chǎn)品不斷迭代的問題，用戶不需要升級(jí)也可以享受到我們的改進(jìn)；支持分布式Sequence，最終我們也要把SQL的能力做到分布式；可選的索引一致性，異步全局二級(jí)索引，有些場(chǎng)景下用戶不需要強(qiáng)一致性，比如說日志，最終在1分鐘之內(nèi)一致就OK了，所以我們做一個(gè)異步的全局更新，更新成本也進(jìn)一步降低了。

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。