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

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

為什么需要SQL？

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

Hash散列

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

分桶

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

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

基于HBase Native api的實現

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

SQL on HBase

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

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

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

商品報表

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

物聯網設備信息存儲

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

Ali-Hbase SQL

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

性能優化

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

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

未來的工作

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

原文鏈接

本文為云棲社區原創內容，未經允許不得轉載。