HBase的Scan和Get不同，前者獲取數據是串行，后者則是並行；是不是有種大跌眼鏡的感覺？
Scan有四種模式：scan，（Table）snapScan，（Table）scanMR，snapshotscanMR；前面兩個是串行玩；后面兩個是放置到MapReduce中玩；其中性能最好的就是SnapshotScanMR；
首先解釋一下什么是snapshort，snapshot是HBase數據表元數據的一個快照，是的，不包括數據；有一點概念要建立清楚，HBase的數據的存儲並不是HBase管理，而是HDFS；其實關系型數據庫的存儲也是OSFS管理的。HBase的設計就是一旦數據寫入了，就不改變了，改變操作（update，delete）並不是修改HFile，而是填充墓碑文件而已；所以快照尤其價值，比如可以快速拷貝一個HBase表（只是拷貝表結構，重用原始表的HDFS數據）。
剛才講的snapshot在scan里面也有應用場景，就是snapshotscan以及snapshortscanMR；注意MR的scan模式就不再是最上面提到的串行查詢，而是並行查詢；底層機制是Map-reduce；所以就下來而言，MR是要高的；畢竟是多個region查詢。
接着，就是ScanAPI的設計：
1. 業務調用HBase Client，HBaseClient首先是查找緩存是否還有數據，如果有則返回數據；
2. 如果沒有數據，則通過向RegionServer繼續請求下面的100條記錄；
3. 作為服務器端接收到next請求之后，將會通過查詢BlockCache→HFile→Memstore流程來一行一行的返回數據。
這種API的調用模式（每次返回100條）目的是避免網絡資源以及HBase Client端內存資源發生壓力；所以可以看到，scanAPI其實只是適合於少量數據的處理；
那么對於海量數據的查詢怎么處理呢？就是上面提到的MR；MR整體分為兩種：TableScanMR（對應的處理類：TableMapReduceUtil.initTableMapperJob）以及SnapshotScanMR（對應處理類：TableMapReduceUtil.initSnapshotMapperJob），下面兩張圖表示了在架構上面的差異：
可以看到，模式很類似，都是在client中通過多線程模式進行並行處理；但是snapshotscanMR不再和region server交互，而是直接在客戶端和HDFS交互；這樣設計的好處即使減輕了Region Server的壓力；但是需要事先和Region Server交互，獲取snapshot的信息，即HBase的元數據信息（表結構以及hdfs存儲信息），這樣，就可以跳過region server直接和hdfs地址交互；但是snapshot有一個缺點：實時性不夠；可能最近的一些數據的修改沒有在snapshot中體現出來。可能會讀到一些臟數據（刪除更新數據仍然存在，只不過在墓碑記錄而已，當然如果merge過后就沒了），可能讀不到一些最新數據。
參考：
http://hbasefly.com/2017/10/29/hbase-scan-3/
http://blog.cloudera.com/blog/2013/03/introduction-to-apache-hbase-snapshots/