2017雲棲大會Hbase專場，阿裏巴巴技術專家天穆帶來Ali-HBase的SQL實踐與改進的演講。本文主要從為什麽需要SQL開始談起，進而講解了SQL on Hbase，接著著重分享了Ali-Hbase SQL的優化與改進，最後對未來進行了展望。
以下是精彩內容整理：

為什麽需要SQL？
1

時間序列數據的存取：按照時間順序追加新記錄，按照時間範圍查詢數據，查詢結果按時間倒排。我們數據是按照時間產生的，最新寫的數據一定寫在表頭，在分布式情況下所有操作都落在表頭，這臺服務器必然會成為熱點。

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

我們需要做一些折中，也就是分桶，我們對它做一個取模的操作，任何一次操作都可以落在隨機的“桶”裏面，數據在桶內是有序的，可以按照時間範圍來查詢。代價是範圍查詢時必須並發查所有桶。在查完所有桶以外需要進行一次合並。
4

我們來查時間範圍，先查第一個分桶，再查第二個和第三個分桶，得到了70、60、50的結果。分桶方案其實在一定程度上提升了讀的性能。
基於HBase Native api的實現
5

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

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

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

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

商品報表是另外一套吞吐型的業務，它也有實時的全量寫，而且也需要二級索引來生成多維報表。這個報表的場景跟DUMP場景不一樣，這個單表比較大，在我們業務裏面最大的表在壓縮之後有80個TB。
物聯網設備信息存儲
10

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

為了支持這些場景，我們在HBase做了很多的優化和改進，在HBase本身我們針對阿裏的場景做了很多性能和功能上的變革。在穩定性方面，我們做了很多工作，能夠讓HBase久經雙十一沙場。Ali-HBaseSQL與Phoenix在功能補齊、功能增強、數據導入導出方面有所改善。Phoenix本身需要人去指定一個索引表，我們把這個事情自動化了，同時增強了可以訪問多張索引表的能力，數據可以在各個系統之間產生流動。
性能優化
目標是將簡單請求的性能優化到極致，與對應的HBase Native API性能差距小於5%。單行讀寫的場景下，SQL和HBase API的差距很明顯。
客戶端的元數據緩存，元數據：列名、數據類型、表屬性、索引信息等等。元數據更新策略：並不是每次都刷新元數據，我們做了周期性的刷新，通過版本號的方式來識別是不是最新的，如果不是最新的就更新一版，這是優化UPSERT的緩存更新策略。

12

SELECT優化，我們會根據油壺請求的大小來合理選擇適用，這個選擇對性能影響非常大，因為我們的目標是優化簡單的請求，優化一點點在用戶那邊的體現都是非常明顯的。我們並不是分析型的場景，並不需要數據的預取，做到這些事情以後讀的性能已經跟HBase Select比較接近了。
此外，阿裏雲上的SQL，從其他的RDBMS遷移至雲HBase。
未來的工作
未來一定是支持列名映射，支持ImmutableDataEncoding，我們現在正在調研，在大寬表的情況下能夠節省1/3—1/2的存儲空間。但是有一個限制，這個數據只能寫下去，不能改。我們要優化功能都需要讓用戶去申請SQL的客戶端，這是非常惡心的事情；支持query server mode和瘦客戶端，解決了產品不斷叠代的問題，用戶不需要升級也可以享受到我們的改進；支持分布式Sequence，最終我們也要把SQL的能力做到分布式；可選的索引一致性，異步全局二級索引，有些場景下用戶不需要強一致性，比如說日誌，最終在1分鐘之內一致就OK了，所以我們做一個異步的全局更新，更新成本也進一步降低了。
原文鏈接請添加鏈接描述
本文為雲棲社區原創內容，未經允許不得轉載。

Ali-HBase的SQL實踐與改進