最近比较忙，隔了一段时间没有更新博客了。今天拿点时间来分享下关于hbase分页查询的实现思路，自己已经应用了该hbase分页查询。
从所周知，hbase通过scan来扫描表，通过startKey，stopKey来确定范围，hbase官方提供了一个PageFilter来支持一次scan可以返回多少条数据即每页的行数。假如一页是10条，这样是第一页还好，但是第二页呢，如果不改变PageFilter的pageSize，那返回的还是第一页的数据，如果改变pageSize为20，则返回了第一页10多余的数据，在客户端要过滤掉，性能不好。那怎么办呢，方法就是在查询下一页时，指定下一页的startKey，这样PageFilter每次就不会返回多余的记录，stopKey可以不用变，那现在问题是，怎么得到下一页的startKey(即下一页第一行的rowkey)呢?,有两种方法来取每一页的startKey

一  上一页的最后一行记录的rowkey作为下一页的startKey。
二   在每次scan时多取一条记录，即把下一页第一条行页取出来，把该行的rowkey做为下一页的startKey。

不管用一还是二，都要注意，hbase scan时是包含startKey的，如果是采用第一种，则要在记录多取一条，排除第一条。第二种页是多取一条，但是排除最后一条，用来做下一页的startKey。还有需要注意的是在计算是否有下一页时，可以根据返回的条数来判断。

startKey怎么取没有问题了。但是怎么存储呢，有同学可能会想到存到session，但是如果你的服务是rest api型的，就没有session的概念了。那还有两种选择：
一 是存到客户端，让客户端每次请求时把startKey再传回来，这样需要依赖客户端，如果客户端是远程，或者是开放平台的情况下，可能不合适。
二 存在服务端，存在服务端需要注意并发访问的情况。比如scan同一个表，一个访问第2页，一个访问第3页，服务端就需要对每一个table的scan 存每一页的startKey，需要为同一个查询条件包含pageSize，因为pageSize不一样，startKey也会不一样，
在服务crash情况下，从起后都从第一页开始。
我自己是采用第二种方案，存在服务端，如果你有更好的方案的请分享出来。
注：hbase的分页一般只提供下一页，不提供直接最后一页，