HBase架構

HBase的特點

1. 大：一個表可以有上億行，上百萬列，
2. 面向列：面向列簇的存盤和權限控制，列簇獨立檢索，
3. 稀疏：對于空（null）的列，并不占用存盤空間，因此，表可以設計的非常稀疏，
4. 無模式（no Schema）：每一行都有一個可以排序的主鍵和任意多的列，列可以根據需要動態增加，同一張表中不同的行可以有截然不同的列，
5. 資料多版本：每個單元格中的資料可以有多個版本，默認情況下，版本號自動分配，版本號就是單元格插入時的時間戳，
6. 資料型別單一：HBase中的資料都是位元組陣列，沒有型別，

HBase架構組件

• Region Server：提供資料的讀寫服務，當客戶端訪問資料時，直接和Region Server通信，
• HBase Master：Region的分配，DDL操作（創建表，洗掉表），
• Zookeeper：是HDFS的一部分，維護一個活躍的集群狀態，

??Hadoop DataNode存盤著Region Server管理的資料，所有HBase資料存盤在HDFS檔案系統中，Region Server在HDFS DataNode中是可配置的，并使資料存盤靠近在它所需要的地方，就近服務，當往HBase寫資料時Local，但是當一個region被移動之后，HBase的資料就不是Local的，除非做了壓縮（compaction）操作，NameNode維護物理資料塊的元資料資訊，

Regions

??HBase Table 通過rowkey range 的范圍被水平切分成多個Region，一個Region包含了所有的，在Region開始鍵和結束之內的行，Regions被分配到集群的節點上，成為Region Servers，提供資料的讀寫服務，一個region server 可以服務1000個Region，

Region的分裂策略

??region中存盤的是一張表的資料，當region中的資料條數過多的時候，會直接影響查詢效率，當region過大的時候，region會拆分為兩個region，HMaster會將分裂的region分配到不同的region server上，這樣可以讓請求分散到不同的Region Server上，已達到負載均衡，這也是HBase的一個優點，

• ConstantSizeRegionSplitPolicy

  0.94版本前，HBase region的默認切分策略

  當region中最大的store大小超過某個閾值(hbase.hregion.max.filesize=10G)之后就會觸發切分，一個region等分為2個region，

  但是在生產線上這種切分策略卻有相當大的弊端（切分策略對于大表和小表沒有明顯的區分）：

  • 閾值(hbase.hregion.max.filesize)設定較大對大表比較友好，但是小表就有可能不會觸發分裂，極端情況下可能就1個，形成熱點，這對業務來說并不是什么好事，
  • 如果設定較小則對小表友好，但一個大表就會在整個集群產生大量的region，這對于集群的管理、資源使用、failover來說都不是一件好事，

• IncreasingToUpperBoundRegionSplitPolicy

  0.94版本~2.0版本默認切分策略

  ? 總體看和ConstantSizeRegionSplitPolicy思路相同，一個region中最大的store大小大于設定閾值就會觸發切分，
  但是這個閾值并不像ConstantSizeRegionSplitPolicy是一個固定的值，而是會在一定條件下不斷調整，調整規則和region所屬表在當前regionserver上的region個數有關系.

  region split閾值的計算公式是：

  • 設regioncount：是region所屬表在當前regionserver上的region的個數

  • 閾值 = regioncount^3 * 128M * 2，當然閾值并不會無限增長，最大不超過MaxRegionFileSize（10G),當region中最大的store的大小達到該閾值的時候進行region split

  例如：

  • 第一次split閾值 = 1^3 * 256 = 256MB
  • 第二次split閾值 = 2^3 * 256 = 2048MB
  • 第三次split閾值 = 3^3 * 256 = 6912MB
  • 第四次split閾值 = 4^3 * 256 = 16384MB > 10GB，因此取較小的值10GB
  • 后面每次split的size都是10GB了

  特點

  • 相比ConstantSizeRegionSplitPolicy，可以自適應大表、小表；
  • 在集群規模比較大的情況下，對大表的表現比較優秀
  • 對小表不友好，小表可能產生大量的小region，分散在各regionserver上
  • 小表達不到多次切分條件，導致每個split都很小，所以分散在各個regionServer上

• SteppingSplitPolicy

  2.0版本默認切分策略

  ? 相比 IncreasingToUpperBoundRegionSplitPolicy 簡單了一些
  ? region切分的閾值依然和待分裂region所屬表在當前regionserver上的region個數有關系

  • 如果region個數等于1，切分閾值為flush size 128M * 2
  • 否則為MaxRegionFileSize，

  這種切分策略對于大集群中的大表、小表會比 IncreasingToUpperBoundRegionSplitPolicy 更加友好，小表不會再產生大量的小region，而是適可而止，

• KeyPrefixRegionSplitPolicy

  根據rowKey的前綴對資料進行磁區，這里是指定rowKey的前多少位作為前綴，比如rowKey都是16位的，指定前5位是前綴，那么前5位相同的rowKey在相同的region中，

• DelimitedKeyPrefixRegionSplitPolicy

  保證相同前綴的資料在同一個region中，例如rowKey的格式為：userid_eventtype_eventid，指定的delimiter為 _ ，則split的的時候會確保userid相同的資料在同一個region中，
  按照分隔符進行切分，而KeyPrefixRegionSplitPolicy是按照指定位數切分，

• BusyRegionSplitPolicy

  按照一定的策略判斷Region是不是Busy狀態，如果是即進行切分

  如果你的系統常常會出現熱點Region，而你對性能有很高的追求，那么這種策略可能會比較適合你，它會通過拆分熱點Region來緩解熱點Region的壓力，但是根據熱點來拆分Region也會帶來很多不確定性因素，因為你也不知道下一個被拆分的Region是哪個，

• DisabledRegionSplitPolicy

  不啟用自動拆分, 需要指定手動拆分

Compaction操作

Minor Compaction：

• 指選取一些小的、相鄰的StoreFile將他們合并成一個更大的StoreFile，在這個程序中不會處理已經Deleted或Expired的Cell，一次 Minor Compaction 的結果是更少并且更大的StoreFile，

Major Compaction：

• 指將所有的StoreFile合并成一個StoreFile，這個程序會清理三類沒有意義的資料：被洗掉的資料、TTL過期資料、版本號超過設定版本號的資料，另外，一般情況下，major compaction時間會持續比較長，整個程序會消耗大量系統資源，對上層業務有比較大的影響，因此線上業務都會將關閉自動觸發major compaction功能，改為手動在業務低峰期觸發，

HBase HMaster

??分配Region，DDL操作（創建表，洗掉表）
??協調各個Region Server

在啟動時分配Region、在恢復或是負載均衡時重新分配Region，
監控所有集群當中的Region Server實體，從Zookeeper中監聽通知，

??管理功能：

提供創建、洗掉、更新表的介面，

Zookeeper 協調器

??Zookeeper一般在分布式系統中的成員之間協調共享的狀態資訊，Region Server和活躍的HMaster通過會話連接到Zookeeper，Zookeeper維護短暫的階段，通過心跳機制用于活躍的會話，

組件之間如何作業

??Zookeeper一般在分布式系統中的成員之間協調共享的狀態資訊，Region Server活躍的HMaster通過會話連接到Zookeeper，Zookeeper維護短暫的階段，通過心跳機制用于活躍的會話，

??每個Region Server創建一個短暫的節點，HMaster監控這些節點發現可用的Region Server，同時HMaster 也監控這些節點的服務器故障，HMaster 通過撞見一個臨時的節點，Zookeeper 決定其中一個HMaster 作為活躍的，活躍的HMaster 給 Zookeeper發送心跳資訊，不活躍的HMaster在活躍的HMaster出現故障時，接受通知，

?? 如果一個Region Server 或是一個活躍的HMaster 在發送心跳資訊失敗或是出現了故障，則會話過期，相應的臨時節點將被洗掉，監聽器將因這些洗掉的節點更新通知資訊，活躍的HMaster將監聽Region Server ，并且將會恢復出現故障的 Region Server ，不活躍的HMaster 監聽活躍的HMaster 故障，如果一個活躍的HMaster出現故障，則不活躍的HMaster將會變得活躍，

HBase 的首次讀寫

??有一個特殊的HBase目錄表叫做Meta表，它擁有Region在集群中的位置資訊，Zookeeper存盤著Meta表的位置，

??如下就是客戶端首次讀寫HBase 所發生的事情：

1. 客戶端從Zookeeper的Meta表中獲取Region Server，
2. 客戶端將查詢 META 服務器，獲取它想訪問的相對應的Region Server 的行鍵，客戶端將這些資訊以及META表的位置資訊，
3. 客戶端將從相應的Region Server獲取行，

??如果再次讀取，客戶端將使用快取來獲取META 的位置及之前的行鍵，這樣時間久了，客戶端不需要查詢META表，除非Region移動所導致的丟失，這樣的話，則會重新查詢更新快取，

HBase META 表

• META 表集群中所有Region的串列
• META 表像是一個B樹
• META 表結構為：
  • Key：region start key,region id
  • Values：Region Server

RegionServer 的組件

??Region Server 運行在HDFS DataNode上，并有如下組件：

WAL:Write Ahead Log 提前寫日志是一個分布式檔案系統上的檔案，WAL存盤沒有持久化的新資料，用于故障恢復，類似Oracle 的Redo Log，

• BlockCache：讀快取，它把頻繁讀取的資料放入記憶體中，采用LRU，
• MemStore：寫快取，存盤來沒有來得及寫入磁盤的新資料，每一個region的每一個列族有一個MemStore，
• Hfiles ：存盤行，作為鍵值對，在硬碟上，

HBase寫步驟

??當客戶端提交一個Put 請求，第一步是把資料寫入WAL：

• 編輯到在磁盤上的WAL的檔案，添加到WAL檔案的末尾
• WAL用于宕機恢復

??一旦資料寫入WAL，將會把它放到MemStore里，然后將回傳一個ACk給客戶端

MemStore

??MemStore 存盤以鍵值對的方式更新記憶體，和存盤在HFile是一樣的，每一個列簇就有一個MemStore ，以每個列簇順序的更新，

HBase Region 重繪（Flush）

??當MemStore 積累到足夠的資料，則整個排序后的集合被寫到HDFS的新的HFile中，每個列簇使用多個HFiles，列簇包含真實的單元格，或者是鍵值對的實體，隨著KeyValue鍵值對在MemStores中編輯排序后，作為檔案重繪到磁盤上，

??注意列簇是有數量限制的，每一個列族有一個MemStore，當MemStore滿了，則進行重繪，它也會保持最后一次寫的序列號，這讓系統知道直到現在都有什么已經被持久化了，

??最高的序列號作為一個meta field 存盤在HFile中，來顯示持久化在哪里結束，在哪里繼續，當一個region 啟動后，讀取序列號，最高的則作為新編輯的序列號，

HBase HFile

??資料存盤在HFile，HFile 存盤鍵值，當MemStore 積累到足夠的資料，整個排序的鍵值集合會寫入到HDFS中新的HFile 中，這是一個順序的寫，非常快，能避免移動磁頭，

HFile 的結構

??HFile 包含一個多層的索引，這樣不必讀取整個檔案就能查找到資料，多層索引像一個B+樹，

• 鍵值對以升序存盤，
• 在64K的塊中，索引通過行健指向鍵值對的資料，
• 每個塊有自己的葉子索引，
• 每個塊的最后的鍵被放入到一個中間索引中，
• 根索引指向中間索引，

??trailer (追蹤器)指向 meta的塊，并在持久化到檔案的最后時被寫入，trailer 擁有 bloom過濾器的資訊以及時間范圍（time range）的資訊，Bloom 過濾器幫助跳過那些不含行健的檔案，時間范圍（time range）則跳過那些不包含在時間范圍內的檔案，

HFile Index

??索引是在HFile 打開并放入記憶體中時被加載的，這允許在單個磁盤上執行查找，

HBase 讀合并

??一個行的鍵值單元格可以被存盤在很多地方，行單元格已經被存盤到HFile中、在MemStore最近被更新的單元格、在Block cache最佳被讀取的單元格，所以當你讀取一行資料時，系統怎么能把相對應的單元格內容回傳呢？一次讀把block cache, MemStore, and HFiles中的鍵值合并的步驟如下：

1. 首先，掃描器（scanner ）在讀快取的Block cache尋找行單元格，最近讀取的鍵值快取在Block cache中，當記憶體需要時剛使用過的（Least Recently Used ）將會被丟棄，
2. 接下來，掃描器（scanner）將在MemStore中查找，以及在記憶體中最近被寫入的寫快取，
3. 如果掃描器（scanner）在MemStore 和Block Cache沒有找到所有的資料，則HBase 將使用 Block Cache的索引以及bloom過濾器把含有目標的行單元格所在的HFiles 加載到記憶體中，

??每個MemStore有許多HFiles 檔案，這樣對一個讀取操作來說，多個檔案將不得不被多次檢查，勢必會影響性能，這種現象叫做讀放大（read amplification），

HBase 輔壓縮（minor compaction）

??HBase將會自動把小HFiles 檔案重寫為大的HFiles 檔案，這個程序叫做minor compaction，

??輔助壓縮減少檔案的數量，并執行合并排序，

HBase 主壓縮（Major Compaction）

??主壓縮將會合并和重寫一個region 的所有HFile 檔案，根據每個列族寫一個HFile 檔案，并在這個程序中，洗掉deleted 和expired 的單元格，這將提高讀性能，

??然而因為主壓縮重寫了所有的檔案，這個程序中將會導致大量的磁盤IO操作以及網路擁堵，我們把這個程序叫做寫放大（write amplification），

Region = 臨近的鍵

• 一個表將被水平分割為一個或多個Region，一個Region包含相鄰的起始鍵和結束鍵之間的行的排序后的區域，
• 每個region默認1GB，
• 一個region的表通過Region Server 向客戶端提供服務，
• 一個region server可以服務1000 個region，

Region 分裂

??初始時一個table在一個region 中，當一個region 變大之后，將會被分裂為2個子region，每個子Region 代表一半的原始Region，在一個相同的 Region server中并行打開，

??然后把分裂報告給HMaster，因為需要負載均衡的緣故，HMaster 可能會調度新的Region移動到其他的Server上，

讀負載均衡（Read Load Balancing）

??分裂一開始發生在相同的region server上，但是由于負載均衡的原因，HMaster 可能會調度新的Region被移動到其他的服務器上，導致的結果是新的Region Server 提供資料的服務需要讀取遠端的HDFS 節點，直到主壓縮把資料檔案移動到Regions server本地節點上，Hbase資料當寫入時是本地的，但是當一個region 移動（諸如負載均衡或是恢復操作等），它將不會是本地的，直到做了主壓縮的操作（major compaction.）

HDFS資料復制

??所有的讀寫操作發生在主節點上，HDFS 復制WAL和HFile 塊，HFile復制是自動發生的，HBase 依賴HDFS提供資料的安全，當資料寫入HDFS，本地化地寫入一個拷貝，然后復制到第二個節點，然后復制到第三個節點，WAL 檔案和 HFile檔案通過磁盤和復制進行持久化，那么HBase怎么恢復還沒來得及進行持久化到HFile中的MemStore更新呢？

HBase 故障恢復

??當一個RegionServer 掛掉了，壞掉的Region 不可用直到發現和恢復的步驟發生，Zookeeper 決定節點的失敗，然后失去region server的心跳，

??然后HMaster 將會被通知Region Server已經掛掉了，

??當HMaster檢查到region server已經掛掉后，HMaster 將會把故障Server上的Region重寫分配到活躍的Region servers上，為了恢復宕掉的region server，memstore 將不會重繪到磁盤上，HMaster 分裂屬于region server 的WAL 到單獨的檔案，然后存盤到新的region servers的資料節點上，每個Region Server從單獨的分裂的WAL回放WAL，來重建壞掉的Region的MemStore，

資料恢復

??WAL 檔案包含編輯串列，一個編輯代表一個單獨的put 、delete.Edits 是按時間的前后順序排列地寫入，為了持久化，增加的檔案將會Append到WAL 檔案的末尾，

??當資料在記憶體中而沒有持久化到磁盤上時失敗了將會發生什么？通過讀取WAL將WAL 檔案回放，添加和排序包含的edits到當前的MemStore，最后MemStore 重繪將改變寫入到HFile中，

HBase架構的優點

• 強一致模型：當寫操作回傳時，所有的讀將看到一樣的結果
• 自動擴展：Regions 隨著資料變大將分裂；使用HDFS傳播和復制資料
• 內建的恢復機制：使用WAL
• Hadoop的集成：直接使用mapreduce

HBase架構的缺點

• WAL回放較慢
• 故障恢復較慢
• 主壓縮導致IO瓶頸

HBase 讀寫流程

HBase寫資料和存資料的程序

HBase資料的寫入程序

1. Client訪問zookeeper，獲取元資料存盤所在的regionserver
2. 通過剛付訓取的地址訪問對應的regionserver，拿到對應的表存盤的regionserver
3. 去表所在的regionserver進行資料的添加
4. 查找對應的region，在region中尋找列族，先向memstore中寫入資料
5. 當memstore寫入的值變多，觸發溢寫操作（flush），進行檔案的溢寫，成為一個StoreFile
6. 當溢寫的檔案過多時，會觸發檔案的合并（Compact）操作，合并有兩種方式（major，minor）

多個StoreFile合并成一個StoreFile,同時進行版本合并和資料洗掉

• minor compaction：小范圍合并，默認是3-10個檔案進行合并，不會洗掉其他版本的資料，
• major compaction：將當前目錄下的所有檔案全部合并，一般手動觸發，會洗掉其他版本的資料（不同時間戳的）

7. 當region中的資料逐漸變大之后，達到某一個閾值，會進行裂變（一個region等分為兩個region，并分配到不同的regionserver），原本的Region會下線，新Split出來的兩個Region會被HMaster分配到相應的HRegionServer上，使得原先1個Region的壓力得以分流到2個Region上，

??由此可知HBase只是增加資料，所有的更新和洗掉操作，都是在Compact階段做的，所以用戶寫操作只需要進入到記憶體即可立即回傳，從而保證I/O高性能讀寫，

1. HStore存盤是HBase存盤的核心，其中由兩部分組成，一部分是Memstore，一部分是StoreFile，
2. HLog的功能： 宕機資料恢復

??在分布式系統環境中，我們是無法避免系統出錯或者宕機的，一旦HRegionServer意外退出，MemStore中的記憶體資料就會丟失，而引入HLog就是為了防止這種情況，

作業機制：每個HRegionServer中都會有一個HLog物件，HLog是一個實作Write Ahead Log的類，每次用戶操作寫入Memstore的同時，也會寫一份資料到HLog檔案中，HLog檔案定期會滾動出新，并洗掉舊的檔案（已持久化到Storefile中的資料），當HRegionServer意外終止后，HMaster會通過Zookeeper感知，HMaster首先處理遺留的HLog檔案，將不同region的log資料拆分，分別放在相應region目錄下，然后再將失效的region（帶有剛剛拆分的log）重新分配，領取到這些region的HRegionServer在Load Region的程序中，會發現有歷史HLog需要處理，因此會Replay HLog中的資料到Memstore中，然后flush到StoreFile，完成資料恢復，

3. Region就是StoreFiles，StoreFiles里由HFile構成，HFile里由hbase的data塊構成，一個data塊里面又有很多的keyvalue對，每個keyvalue里存了我們需要的值，
4. 一 張表，有兩個列族（紅顏色的一個，黃顏色的一個），一個列族有兩個列，從圖中可以看出，這就是列式資料庫的最大特點，同一個列族的資料在在一起的，我們還 發現如果是有多個版本，同時也會存多個版本，最后我們還發現里面存了這樣的值：r1:鍵值，cf1:列族的名字，c1:列名，t1：版本號，value值 （最后一幅圖說明的是value值可以存放的位置），通過這樣的看法，我們會發現如果在設計表的時候把這幾個東西：r1:鍵值，cf1:列族的名 字，c1:列明的名字取短一點，我們就可以節省出好多存盤的空間！

??我們看倒數第二張圖，欄位篩選的效率從左到右明顯下降，所以在keyvalue的設計時用戶可以考慮把一些重要的篩選資訊左移到合適的位置，從而在不改變數 據量的情況下，提高查詢性能，那么簡單的說就是用戶應當盡量把查詢維度或資訊存盤在行健中，因為它篩選資料的效率最高，

??HBase 的資料存盤時會被有順序的存盤到一個特定的范圍，因為我們存盤的時候一般都是按順序的，所以會一直存到同一個region上，由于一個region只能由 一個服務器管理，這樣我們老是添加到同一個region上，會造成讀寫熱點，從而使集群性能下降，

??那么解決這個問題的辦法還是有的，假如我們 有9臺服務器，那么我們就會去當前時間，然后mod9，加到行鍵前綴，這樣就會被平均的分到不同的region服務器上了，這樣帶來的好處是，因為相連的資料 都分布到不同的服務器上了，用戶可以多執行緒并行的讀取資料，這樣查詢的吞吐量會提高，關于版本的控制，我們要么就讓多臺服務器上的時間都同步，要么干脆就在put插入資料時，設定一個客戶端的時間戳來代替，

關于表的設計

??設計表的時候，有兩種設計方式，一種是高表設計，一種是胖表設計，根據HBase的拆分規則，我們的高表設計更容易拆分（使用組合鍵），不過如果我們設計成胖表，而我們這個胖表里的資料需要經常修改，這樣的設計是很合理的，以為HBase保證了行級原子性，如果設計成高表，反而就不合適了，因為不能保證跨行的原子性，

寫快取

??每一個put的操作實際上是RPC的操作，它將客戶端的資料傳送到服務器然后回傳，這只適合小資料量的操作，如果有個應用程式需要每秒存盤上千行資料到HBase中，這樣處理就不太合適了，HBase的API配備了一個客戶端的寫緩沖區，緩沖區負責收集put操作，然后呼叫RPC操作，一次性將put送往服務器，默認情況下，客戶端緩沖區是禁止的，可以通過自動刷寫設定為FALSE來激活緩沖區，

??table.setAutoFlush(false);void flushCommits () throws IOException這個方法是強制 將資料寫到服務器，用戶還可以根據下面的方法來配置客戶端寫緩沖區的大小，

??void setWritaeBufferSize(long writeBufferSize) throws IOException;默認大小是 2MB，這個也是適中的，一般用戶插入的資料不大，不過如果你插入的資料大的話，可能要考慮增大這個值，從而允許客戶端更高效地以一定數量的資料組成一組，然后通過一次RPC請求來執行，

??在每一個客戶端設定一個寫緩沖區是一件麻煩的事，我們可以在Hbase-site.xml中給用戶設定一個較大的預設值，

<property>
<name>hbase.client.write.buffer</name>
<value>20971520</value>
</property>

壓縮

??hbase支持大量的演算法，并且支持列族級別以上的壓縮演算法，除非有特殊原因，不然我們應該盡量使用壓縮，壓縮通常會帶來較好的性能，通過一些測驗，我們推薦使用SNAPPY這種演算法來進行我們hbase的壓縮，

HBase資料的讀取流程

1. Client訪問zookeeper，獲取元資料存盤所在的regionserver
2. 通過剛付訓取的地址訪問對應的regionserver，拿到對應的表存盤的regionserver
3. 去表所在的regionserver進行資料的讀取
4. 查找對應的region，在region中尋找列族，先找到memstore，找不到去blockcache中尋找，再找不到就進行storefile的遍歷
5. 找到資料之后會先快取到blockcache中，再將結果回傳blockcache逐漸滿了之后，會采用LRU的淘汰策略，

• 在HBase中，所有的存盤檔案都被劃分成了若干個小存盤塊，這些存盤塊在get或scan操作時會加載到記憶體中，他們類似與RDBMS中的存盤單元頁，這個引數的默認大小是64k，HBase會順序的讀取一個資料塊到記憶體快取中，其讀取相鄰的資料時就可以在記憶體中讀取而不需要從磁盤中再次讀取，有效的減少了磁盤的I/O的次數，這個引數默認為TRUE，這意味著每次讀取的塊都會快取到記憶體中，
  • 但是：如果用戶順序讀寫某個特定的列族，這個時候，這個機制就會把其他我們不需要的列族的資料也加載到記憶體中，增加了我們的負擔，那么1就需要將其關閉，void setBlockCacheEnable(boolean blockCacheEnable);
• 禁止自動刷寫:
  • 我們有大批資料要插入時，如果我們沒有禁止，Put實體會被逐個的傳送到region服務器，（一條一條的往磁盤中寫，害怕不？）如果用戶禁止了自動刷寫的功能，put操作會在寫緩沖區被填滿時才會被送出，
  • 使用掃描快取，如果HBase被用作一個mapreduce作業的輸入源，請最好將作為mapreduce作業輸入掃描器實體的快取用setCaching()方法設定為默認值1更大的數，使用默認值意味著map任務會在處理每條記錄時都請求region服務器，不過，這個值是500的話，則一次可傳送500條資料到客戶端進行處理，當然了這資料也是根據具體情況而定，
• 限定掃描范圍:
  • 比如我們要處理大量行（特別是作為mapreduce的輸入源），其中用到scan的時候我們有Scan.addFamily();的方法，這個時候我們如果只是需要到這幾個列族中的幾個列，那么我們一定要精確，因為過多的列會導致效率的損失，
• 塊快取的用法:
  • 首先我們的塊快取是通過Scan.setCacheBlocks();啟動的，那么被頻繁訪問的行，我們應該使用快取塊，但是MapReduce作業使用掃描大量的行，我們就不該使用這個了，

到底啦！關注靚仔學習更多的大資料知識！😊