最近一個專案中使用了HBase，有一部分實時查詢的需求。HBase本身只有一種排序，即按照rowkey的字典升序來排序資料。然而我們常常會碰到各種各樣的排序需求。

        對於簡單的需求（比如專案確定只有某一種特定排序的需求），則可以通過對rowkey本身進行“組合”設計來達到目的。比如專案涉及到的資料為全球各類學校學生情況，需要按照在校人數的降序來展示資料，則可以採用“Integer.MAX_VALUE - 在校人數 + 學校簡稱” 組成rowkey（注意保證整數部分佔有相同位元組數）。

        對於稍微複雜一點的需求，比如需要有分別按照某幾列排序的功能，可以考慮對這幾列建立二級索引表，索引表的rowkey為該列的每一個值，索引表只含一列，列值為對應的原資料的rowkey。當選擇按照某一列進行排序時，首先讀取索引表的內容，進而再根據索引表的列值再向原資料表發起查詢，得到按照該列進行排序後的資料。關於建立二級索引表有很多的討論，感興趣的小夥伴可以自行去了解。

        第三種需求，就是我目前碰到的問題。專案有N張資料表，每張表都可以自定義查詢條件，並可以按照每一列進行排序。這要是用SQL，簡直就太開心啦，分分鐘的事情。可是我面對的是HBase，而且我是個初學者，跟小白差不多，只熟練掌握了各種filter的使用，自定義查詢條件的需求可以輕鬆搞定，但排序就哭了。聽聞HBase的coprocessor功能強大，有網友提到可以用它來做排序，可能我太愚蠢，看來看去，就覺得coprocessor跟spring裡的aop概念有一拼，實在想不出它能跟排序有幾毛錢關係。

        迷茫中看到了Hive，但是Hive是把SQL語句轉化成map reduce來做的，並不適合做實時查詢。

        然後看到了phoenix，phoenix官網上是這麼詮釋它的：High performance relational database layer over HBase for low latency applications。一些測評資料也顯示，在100M行以內的資料集上，phoenix的效能遠超Hive，可以在數秒內甚至毫秒級別得到結果（Hive基本上是幾十秒起步）。正好符合我的需求。

        這時問題來了，怎麼在phoenix上做分頁呢？

        傳統SQL的LIMIT關鍵字可以跟兩個引數，一個是起始index，一個是需要的行數，做分頁so easy啊。但phoenix的LIMIT只支援一個引數：需要的行數。

        在原始的HBase上做分頁也比較簡單，可以使用PageFilter設定需要的行數，再根據逐頁查詢記錄下每一頁起始行的rowkey，來設定Scan的起始rowkey。

        查了phoenix的issues，phoenix的開發者推薦了一種做法：使用組合條件，組合排序依據的列值及rowkey。下面舉例子說明具體做法。

        有一張表，包含關鍵字PK（及原始HBase中的rowkey），以及若干列ORG_NAME, ORG_NUM, ORG_CODE等等。（其中PK的大小和該行資訊的新舊程度成反比，即PK越小，該條資訊越新）

        現在需要可以自定義了查詢條件後，再根據任一列進行排序，比如當ORG_NAME為“一”時，根據ORG_CODE做升序、降序，每頁資料為20條。

        1. 查詢第一頁時：

           (1) SELECT * FROM ORG WHERE ORG_NAME = '一'

                 ORDER BY ORG_CODE ASC, PK ASC LIMIT 21 （升序）

           (2) SELECT * FROM ORG WHERE ORG_NAME = '一'

                 ORDER BY ORG_CODE DESC, PK DESC LIMIT 21 （降序）

            每頁資料為20條，但我們這裡取了21條，這個很關鍵，第21條就是第二頁的第一行，需要記錄下這行的ORG_CODE值（記為CODE2），以及PK（記為PK2），為第二頁的查詢做鋪墊。

        2.查詢第二頁時：

           (1) SELECT * FROM ORG WHERE ORG_NAME='一' AND

                (ORG_CODE = CODE2 AND PK >= PK2 OR ORG_CODE > CODE2)

                ORDER BY ORG_CODE ASC ,PK ASC LIMIT 21（升序）

           (2) SELECT * FROM ORG WHERE ORG_NAME='一' AND

                (ORG_CODE = CODE2 AND PK >= PK2 OR ORG_CODE < CODE2)

                ORDER BY ORG_CODE DESC ,PK ASC LIMIT 21（降序）

        後面的頁數依次類推，將CODE2和PK2替換為相應的值即可

        回頭想想，這個做法其實就是結合了SQL的分頁做法和HBase的分頁做法，就跟phoenix本身一樣——為SQL和HBase搭起了溝通的橋樑。

        雖然phoenix還是存在一些問題：沒法對中文進行有意義的排序。mysql對中文的有意義排序可以通過設定字符集為GBK來解決，而phoenix目前只能處理utf-8編碼的資料，用GBK編碼資料存到HBase中，直接從HBase中讀出來沒有問題，但通過phoenix讀出來就全成了亂碼。給phoenix的mailing list發了郵件，一直未收到回覆，期待有中國的大神以後可以給phoenix打個補丁。

        困擾了我很久的HBase按列排序問題終於得到了還算妥善的解決，心情真是美麗啊。凡事還是要多學習，多實踐才好，繼續加油哦。