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

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

為什么需要SQL？

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

Hash散列

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

分桶

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

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

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

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

SQL on HBase

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

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

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

商品報表

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

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

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

Ali-Hbase SQL

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

性能優(yōu)化

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

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

未來的工作

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

原文鏈接

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