HBase 默認配置

hbase-site.xml和hbase-default.xml

在Hadoop中將特定於站點的HDFS配置添加到hdfs-site.xml文件，那麼對於HBase，特定於站點的配置文件為conf/hbase-site.xml。有關可配置屬性的列表，請參見下面的HBase默認配置或查看src/main/resources的HBase源代碼中的原始hbase-default.xml源文件。

並不是所有的配置選項都會將其發送到hbase-default.xml。一些配置只會出現在源代碼中；因此識別這些更改的唯一方法是通過代碼審查。

目前，這裡的更改將需要為HBase重啟集群來注意到這個變化。

HBase 默認配置

以下文檔是使用默認的HBase配置文件hbase-default.xml作為源生成的。

• hbase.tmp.dir
• 這是本地文件系統上的臨時目錄。將此設置更改為指向比“/tmp”更持久的位置，這是java.io.tmpdir的常見解決方案，因為在重新啟動計算機時清除了“/tmp”目錄。默認為： ${java.io.tmpdir}/hbase-${user.name}

• hbase.rootdir
• 這個目錄是region servers共享的目錄，HBase保持不變。該URL應該是“完全限定的”以包括文件系統的scheme。例如，要指定HDFS實例的"/hbase"目錄，namenode運行在namenode.example.org的9000端口，請將此值設置為：hdfs：//namenode.example.org：9000 / hbase。默認情況下，我們會寫$ {hbase.tmp.dir}，通常是/tmp - 所以改變這個配置，否則所有的數據在計算機重啟時都會丟失。默認為：${hbase.tmp.dir}/hbase

• hbase.cluster.distributed
• 群集所處的模式。對於獨立模式，可能的值為false，對於分佈式模式，可能的值為true。如果為false，啟動將在一個JVM中一起運行所有HBase和ZooKeeper守護程序。默認為：false

• hbase.zookeeper.quorum
• 使用逗號分隔的ZooKeeper集合中的服務器列表（這個配置應該被命名為hbase.zookeeper.ensemble）。例如，“host1.mydomain.com，host2.mydomain.com，host3.mydomain.com”。默認情況下，對於本地和偽分佈式操作模式，將其設置為localhost。對於完全分佈式安裝，應將其設置為ZooKeeper集成服務器的完整列表。如果在hbase-env.sh中設置HBASE_MANAGES_ZK，這是hbase將作為群集啟動/停止的一部分來啟動/停止ZooKeeper的服務器列表。客戶端，我們將把這個集合成員的列表，並把它與hbase.zookeeper.property.clientPort配置放在一起。並將其作為connectString參數傳遞給zookeeper構造函數。默認為：localhost

• zookeeper.recovery.retry.maxsleeptime
• 在重試 zookeeper操作之前的最大睡眠時間（以毫秒為單位），這裡需要最大時間，以便睡眠時間不會無限增長。默認為：60000

• hbase.local.dir
• 將本地文件系統上的目錄用作本地存儲。默認為：${hbase.tmp.dir}/local/

• hbase.master.port
• HBase Master應該綁定的端口。默認為：16000

• hbase.master.info.port
• HBase Master Web UI的端口。如果您不想運行UI實例，請將其設置為-1。默認為：16010

• hbase.master.info.bindAddress
• HBase Master Web UI的綁定地址默認為：0.0.0.0

• hbase.master.logcleaner.plugins
• 由LogsCleaner服務調用的BaseLogCleanerDelegate的逗號分隔列表。這些WAL清理是按順序調用的。要實現您自己的BaseLogCleanerDelegate，只需將其放入HBase的類路徑中，並在此添加完全限定的類名。始終在列表中添加上面的默認日誌清理工具。默認為：org.apache.hadoop.hbase.master.cleaner.TimeToLiveLogCleaner,org.apache.hadoop.hbase.master.cleaner.TimeToLiveProcedureWALCleaner

• hbase.master.logcleaner.ttl
• WAL在歸檔（{hbase.rootdir} / oldWALs）目錄中保留多久，之後將由主線程清除。該值以毫秒為單位。默認為：600000

• hbase.master.procedurewalcleaner.ttl
• 程序WAL將在歸檔目錄中保留多久，之後將由主線程清除。該值以毫秒為單位。默認為：604800000

• hbase.master.hfilecleaner.plugins
• 由HFileCleaner服務調用的BaseHFileCleanerDelegate的逗號分隔列表。這些HFile清理器按順序調用。要實現您自己的BaseHFileCleanerDelegate，只需將其放入HBase的類路徑中，並在此添加完全限定的類名。總是在列表中添加上面的默認日誌清除程序，因為它們將被覆蓋在hbase-site.xml中。默認為：org.apache.hadoop.hbase.master.cleaner.TimeToLiveHFileCleaner

• hbase.master.infoserver.redirect
• Master是否監聽Master Web UI端口（hbase.master.info.port）並將請求重定向到由Master和RegionServer共享的Web UI服務器。配置，當主服務區域（而不是默認）時是有意義的。默認為：true

• hbase.master.fileSplitTimeout
• 分割一個區域，在放棄嘗試之前等待文件分割步驟需要多長時間。默認值：600000。這個設置在hbase-1.x中被稱為hbase.regionserver.fileSplitTimeout。Split現在運行主端，因此重命名（如果找到'hbase.master.fileSplitTimeout'設置，將使用它來填充當前'hbase.master.fileSplitTimeout'配置。默認為：600000

• hbase.regionserver.port
• HBase RegionServer綁定的端口。默認為：16020

• hbase.regionserver.info.port
• HBase RegionServer Web UI的端口如果您不希望RegionServer UI運行，請將其設置為-1。默認為：16030

• hbase.regionserver.info.bindAddress
• HBase RegionServer Web UI的地址默認為：0.0.0.0

• hbase.regionserver.info.port.auto
• Master或RegionServer UI是否應搜索要綁定的端口。如果hbase.regionserver.info.port已被使用，則啟用自動端口搜索。用於測試，默認關閉。
  默認為：false

• hbase.regionserver.handler.count
• 在RegionServers上啟動RPC Listener實例的計數。Master使用相同的屬性來處理主處理程序的數量。太多的處理者可能會適得其反。使其成為CPU數量的倍數。如果主要是隻讀的，處理程序計數接近CPU計數做得很好。從CPU數量的兩倍開始，並從那裡調整。默認為：30

• hbase.ipc.server.callqueue.handler.factor
• 確定呼叫隊列數量的因素。值為0表示在所有處理程序之間共享單個隊列。值為1意味著每個處理程序都有自己的隊列。默認為：0.1

• hbase.ipc.server.callqueue.read.ratio
• 將調用隊列分成讀寫隊列。指定的時間間隔（應該在0.0到1.0之間）將乘以調用隊列的數量。值為0表示不分割調用隊列，這意味著讀取和寫入請求將被推送到相同的一組隊列中。低於0.5的值意味著將比寫入隊列更少的讀取隊列。值為0.5意味著將有相同數量的讀寫隊列。大於0.5的值意味著將有更多的讀隊列而不是寫入隊列。值為1.0意味著除了一個之外的所有隊列都用於發送讀取請求。示例：假設調用隊列的總數為10，則read.ratio為0意味著：10個隊列將同時包含讀/寫請求。0.3的讀取比例意味著：3個隊列將只包含讀取請求，7個隊列將只包含寫入請求。0.5的read.ratio表示：5個隊列將只包含讀取請求，5個隊列將只包含寫入請求。0.8的read.ratio意味著：8個隊列將只包含讀取請求，2個隊列將只包含寫入請求。1的read.ratio表示：9個隊列將只包含讀取請求，1個隊列將只包含寫入請求。默認為：0

• hbase.ipc.server.callqueue.scan.ratio
• 考慮到讀取的調用隊列的數量（根據調用隊列的總數乘以callqueue.read.ratio計算），scan.ratio屬性將把讀取的調用隊列拆分為小讀取和長讀取隊列。低於0.5的值意味著長讀隊列比短讀隊列少。值為0.5意味著將有相同數量的短讀取和長讀取隊列。大於0.5的值意味著將會有比長讀取隊列更多的長讀取隊列。值0或1表示使用同一組隊列進行獲取和掃描。示例：給定讀取調用隊列的總數為8，scan.ratio為0或1意味著：8個隊列將包含長讀請求和短讀請求。0.3的scan.ratio表示：2個隊列只包含長讀請求，6個隊列只包含短讀請求。0.5的scan.ratio表示：4個隊列只包含長讀請求，4個隊列只包含短讀請求。0.8的scan.ratio意味著：6個隊列只包含長讀請求，2個隊列只包含短讀請求。默認為：0

• hbase.regionserver.msginterval
• 從RegionServer到Master的消息間隔（以毫秒為單位）。默認為：3000

• hbase.regionserver.logroll.period
• 無論有多少次編輯，我們將滾動提交日誌的時間段。默認為：3600000

• hbase.regionserver.logroll.errors.tolerated
• 在觸發服務器中止之前，我們將允許連續的WAL關閉錯誤的數量。如果在日誌滾動過程中關閉當前WAL書寫器失敗，則設置為0將導致區域服務器中止。即使是一個很小的值（2或3）也會讓區域服務器承擔瞬間的HDFS錯誤。默認為：2

• hbase.regionserver.hlog.reader.impl
• WAL文件讀取器的實現。默認為：org.apache.hadoop.hbase.regionserver.wal.ProtobufLogReader

• hbase.regionserver.hlog.writer.impl
• WAL文件編寫器的實現。默認為：org.apache.hadoop.hbase.regionserver.wal.ProtobufLogWriter

• hbase.regionserver.global.memstore.size
• 在新更新被阻止並刷新之前，區域服務器中所有存儲區的最大大小。默認為堆的40％（0.4）。更新被阻止，強制刷新直到區域服務器中的所有內存大小都達到hbase.regionserver.global.memstore.size.lower.limit。此配置中的默認值已被故意留空，以便兌現舊的hbase.regionserver.global.memstore.upperLimit屬性（如果存在）。沒有默認值。

• hbase.regionserver.global.memstore.size.lower.limit
• 強制刷新之前，區域服務器中所有存儲區的最大大小。默認為hbase.regionserver.global.memstore.size（0.95）的95％。當由於內存限制而導致更新被阻塞時，此值的100％會導致最小可能的刷新。此配置中的默認值已被故意留空，以便兌現舊的hbase.regionserver.global.memstore.lowerLimit屬性（如果存在）。沒有默認值。

• hbase.systemtables.compacting.memstore.type
• 確定用於系統表（如META，名稱空間表等）的memstore的類型。默認情況下，NONE是類型，因此我們對所有系統表使用默認的memstore。如果我們需要為系統表使用壓縮存儲器，那麼將這個屬性設置為：BASIC / EAGER默認值：NONE

• hbase.regionserver.optionalcacheflushinterval
• 在自動刷新之前，編輯在內存中的最長時間。默認為1小時。將其設置為0將禁用自動刷新。默認為：3600000

• hbase.regionserver.dns.interface
• 區域服務器應從中報告其IP地址的網絡接口的名稱。默認為：default

• hbase.regionserver.dns.nameserver
• 域名服務器應使用的名稱服務器（DNS）的主機名或IP地址，以確定主機用於通信和顯示的主機名。默認為：default

• hbase.regionserver.region.split.policy
• 分割策略決定了一個區域應該何時拆分。當前可用的各種其他拆分策略是：BusyRegionSplitPolicy，ConstantSizeRegionSplitPolicy，DisabledRegionSplitPolicy，DelimitedKeyPrefixRegionSplitPolicy，KeyPrefixRegionSplitPolicy和SteppingSplitPolicy。DisabledRegionSplitPolicy會阻止手動區域分割。默認為：org.apache.hadoop.hbase.regionserver.SteppingSplitPolicy

• hbase.regionserver.regionSplitLimit
• 限制區域數量，之後不再發生區域分割。這並不是硬性限制區域數量，而是作為區域服務商在一定限度之後停止分裂的指導方針。默認設置為1000。默認為：1000

• zookeeper.session.timeout
• ZooKeeper會話超時（以毫秒為單位）。它使用兩種不同的方式。首先，這個值用於HBase用來連接到集合的ZK客戶端。當它啟動一個ZK服務器時它也被HBase使用，並且它被作為'maxSessionTimeout'傳遞。請參閱http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#ch_zkSessions。例如，如果HBase區域服務器連接到也由HBase管理的ZK集合，那麼會話超時將是由此配置指定的。但是，連接到以不同配置管理的集成的區域服務器將受到該集合的maxSessionTimeout的限制。所以，儘管HBase可能會建議使用90秒，但是整體的最大超時時間可能會低於此值，並且會優先考慮。ZK目前的默認值是40秒，比HBase的低。默認為：90000

• zookeeper.znode.parent
• ZooKeeper中用於HBase的Root ZNode。所有配置了相對路徑的HBase的ZooKeeper文件都會在這個節點下。默認情況下，所有的HBase的ZooKeeper文件路徑都被配置為一個相對路徑，所以它們將全部進入這個目錄下，除非被改變。默認為：/hbase

• zookeeper.znode.acl.parent
• Root ZNode用於訪問控制列表。默認為：acl

• hbase.zookeeper.dns.interface
• ZooKeeper服務器應從中報告其IP地址的網絡接口的名稱。默認為：default

• hbase.zookeeper.dns.nameserver
• 名稱服務器（DNS）的主機名或IP地址，ZooKeeper服務器應使用該名稱服務器來確定主機用於通信和顯示的主機名。默認為：default

• hbase.zookeeper.peerport
• ZooKeeper同伴使用的端口進行彼此會話。有關更多信息，請參閱http://hadoop.apache.org/zookeeper/docs/r3.1.1/zookeeperStarted.html#sc_RunningReplicatedZooKeeper。默認為：2888

• hbase.zookeeper.leaderport
• ZooKeeper用於leader選舉的端口。有關更多信息，請參閱http://hadoop.apache.org/zookeeper/docs/r3.1.1/zookeeperStarted.html#sc_RunningReplicatedZooKeeper。默認為：3888

• hbase.zookeeper.property.initLimit
• 來自ZooKeeper的配置zoo.cfg的屬性。初始同步階段可以採用的時鐘（ticks）週期數。默認為：10

• hbase.zookeeper.property.syncLimit
• 來自ZooKeeper的配置zoo.cfg的屬性。發送請求和獲取確認之間可以傳遞的時鐘（ticks）數量。默認為：5

• hbase.zookeeper.property.dataDir
• 來自ZooKeeper的配置zoo.cfg的屬性。快照存儲的目錄。默認為：${hbase.tmp.dir}/zookeeper

• hbase.zookeeper.property.clientPort
• 來自ZooKeeper的配置zoo.cfg的屬性。客戶端將連接的端口。默認為：2181

• hbase.zookeeper.property.maxClientCnxns
• 來自ZooKeeper的配置zoo.cfg的屬性。限制由IP地址標識的單個客戶端的併發連接數量（在套接字級別）可能會對ZooKeeper集合的單個成員產生影響。設置為高，以避免獨立運行和偽分佈式運行的zk連接問題。默認為：300

• hbase.client.write.buffer
• BufferedMutator寫入緩衝區的默認大小（以字節為單位）。一個更大的緩衝區需要更多的內存 - 在客戶端和服務器端，因為服務器實例化傳遞的寫入緩衝區來處理它 - 但更大的緩衝區大小減少了RPC的數量。對於估計使用的服務器端內存，計算：hbase.client.write.buffer * hbase.regionserver.handler.count默認為：2097152

• hbase.client.pause
• 一般客戶端pause值。在運行失敗的get，region lookup等的重試之前，主要用作等待的值。默認為：100

• hbase.client.pause.cqtbe
• 是否為CallQueueTooBigException（cqtbe）使用特殊的客戶端pause。如果您觀察到來自同一個RegionServer的頻繁的CQTBE，並且其中的調用隊列保持充滿，則將此屬性設置為比hbase.client.pause更高的值沒有默認值。

• hbase.client.retries.number
• 最大重試次數。用作所有可重試操作（如獲取單元格值，啟動行更新等）的最大值。重試間隔是基於hbase.client.pause的粗略函數。首先，我們在這段時間重試，但後來退後，我們很快就達到每十秒鐘重試一次。請參閱HConstants＃RETRY_BACKOFF瞭解備份如何提升。改變這個設置和hbase.client.pause來適應你的工作負載。默認為：15

• hbase.client.max.total.tasks
• 單個HTable實例發送到集群的最大併發突變任務數。默認為：100

• hbase.client.max.perserver.tasks
• 單個HTable實例將發送到單個區域服務器的併發突變任務的最大數量。默認為：2

• hbase.client.max.perregion.tasks
• 客戶端將維護到單個Region的最大併發突變任務數。也就是說，如果已經有hbase.client.max.perregion.tasks寫入這個區域，那麼新的放入將不會被髮送到這個區域，直到一些寫入完成。默認為：1

• hbase.client.perserver.requests.threshold
• 所有客戶端線程（進程級別）中一個服務器的併發未決請求的最大數量。超過請求將立即拋出ServerTooBusyException，以防止用戶的線程被佔用和只被一個緩慢的區域服務器阻止。如果使用固定數量的線程以同步方式訪問HBase，請將此值設置為與線程數量相關的適當值，這些值將對您有所幫助。默認為：2147483647

• hbase.client.scanner.caching
• 如果從本地，客戶端內存中未提供，則在掃描程序上調用next時嘗試獲取的行數。此配置與hbase.client.scanner.max.result.size一起使用，可以有效地使用網絡。缺省值默認為Integer.MAX_VALUE，這樣網絡將填充由hbase.client.scanner.max.result.size定義的塊大小，而不受特定行數的限制，因為行的大小隨表格的不同而不同。如果您事先知道掃描中不需要超過一定數量的行，則應通過掃描＃setCaching將此配置設置為該行限制。緩存值越高，掃描器的速度越快，但是會佔用更多的內存，而當緩存空置時，下一次調用的時間可能會越來越長。請勿設置此值，以便調用之間的時間大於掃描器超時；即hbase.client.scanner.timeout.period默認為：2147483647

• hbase.client.keyvalue.maxsize
• 指定KeyValue實例的組合的最大允許大小。這是為保存在存儲文件中的單個條目設置上限。由於它們不能被分割，所以有助於避免因為數據太大而導致地區不能被分割。將此設置為最大區域大小的一小部分似乎是明智的。將其設置為零或更少將禁用檢查。默認為：10485760

• hbase.server.keyvalue.maxsize
• 單個單元格的最大允許大小，包括值和所有關鍵組件。值為0或更小將禁用檢查。默認值是10MB。這是保護服務器免受OOM情況的安全設置。默認為：10485760

• hbase.client.scanner.timeout.period
• 客戶端掃描程序的租期以毫秒為單位。默認為：60000

• hbase.client.localityCheck.threadPoolSize
• 默認為：2

• hbase.bulkload.retries.number
• 最大重試次數，這是在面對分裂操作時嘗試原子批量加載的最大迭代次數，0意味著永不放棄。默認為：10

• hbase.master.balancer.maxRitPercent
• 平衡時轉換區域的最大百分比。默認值是1.0。所以沒有平衡器節流。如果將此配置設置為0.01，則意味著在平衡時轉換中最多有1％的區域。那麼當平衡時，集群的可用性至少為99％。默認為：1.0

• hbase.balancer.period
• 區域平衡器在主站運行的時間段。默認為：300000

• hbase.normalizer.period
• 區域標準化程序在主程序中運行的時段。默認為：300000

• hbase.regions.slop
• 如果任何區域服務器具有平均值+（平均*斜率）區域，則重新平衡。StochasticLoadBalancer（默認負載均衡器）中此參數的默認值為0.001，其他負載均衡器（即SimpleLoadBalancer）中的默認值為0.2。默認為：0.001

• hbase.server.thread.wakefrequency
• 在兩次搜索之間休息的時間（以毫秒為單位）。用作日誌滾筒等服務線程的睡眠間隔。默認為：10000

• hbase.server.versionfile.writeattempts
• 在放棄之前重試嘗試寫入版本文件的次數。每個嘗試都由hbase.server.thread.wake頻率毫秒分隔。默認為：3

• hbase.hregion.memstore.flush.size
• 如果memstore的大小超過此字節數，Memstore將被刷新到磁盤。值由每個hbase.server.thread.wakefrequency運行的線程檢查。默認為：134217728

• hbase.hregion.percolumnfamilyflush.size.lower.bound.min
• 如果使用了FlushLargeStoresPolicy，並且有多個列族，那麼每當我們達到完全的memstore限制時，我們就會找出所有memstore超過“下限”的列族，只有在保留其他內存的同時刷新它們。默認情況下，“下限”將是“hbase.hregion.memstore.flush.size/column_family_number”，除非該屬性的值大於該值。如果沒有一個族的memstore大小超過下限，所有的memstore都將被刷新（就像往常一樣）。默認為：16777216

• hbase.hregion.preclose.flush.size
• 如果我們關閉時某個區域的存儲空間大於或等於這個大小，則可以運行“預先刷新（pre-flush）”來清除存儲區，然後再放置區域關閉標記並使區域脫機。關閉時，在關閉標誌下運行刷新以清空內存。在此期間，該地區處於離線狀態，我們沒有進行任何寫入。如果memstore內容很大，則此刷新可能需要很長時間才能完成。這個預刷新是為了清理大部分的memstore，然後把關閉標誌放到離線區域，這樣在關閉標誌下運行的刷新沒有什麼用處。默認為：5242880

• hbase.hregion.memstore.block.multiplier
• 如果memstore具有hbase.hregion.memstore.block.multiplier乘以hbase.hregion.memstore.flush.size個字節，則阻止更新。在更新通信高峰期間有用的防止失控的memstore。如果沒有上限，memstore就會填滿，當刷新生成的flush文件需要很長時間才能壓縮或拆分。默認為：4

• hbase.hregion.memstore.mslab.enabled
• 啟用MemStore-Local分配緩衝區，該功能可用於在繁重的寫入負載下防止堆碎片。這可以減少在大堆停止全局GC pause的頻率。默認為：true

• hbase.hregion.max.filesize
• 最大HFile大小。如果一個地區的HFiles的總和已經超過了這個數值，這個地區就會被分成兩部分。默認為：10737418240

• hbase.hregion.majorcompaction
• 主要壓縮之間的時間，以毫秒錶示。設置為0可禁用基於時間的自動重要壓縮。用戶請求的和基於大小的主要壓縮將仍然運行。這個值乘以hbase.hregion.majorcompaction.jitter，使壓縮在一個給定的時間窗口內稍微隨機的時間開始。默認值是7天，以毫秒錶示。如果主要壓縮導致您的環境中斷，則可以將它們配置為在部署的非高峰時間運行，或者通過將此參數設置為0來禁用基於時間的主要壓縮，並在cron作業或另一個外部機制。默認為：604800000

• hbase.hregion.majorcompaction.jitter
• 應用於hbase.hregion.majorcompaction的乘數會導致壓縮發生在給定的時間量的任何一側的hbase.hregion.majorcompaction。數字越小，壓縮將越接近hbase.hregion.majorcompaction時間間隔。默認為：0.50

• hbase.hstore.compactionThreshold
• 如果任何一個Store中存在超過此數量的StoreFiles（每個MemStore刷新一個StoreFile），則會執行壓縮以將所有StoreFile重寫為單個StoreFile。較大的值會延遲壓實，但是當壓縮發生時，需要較長時間才能完成。默認為：3

• hbase.hstore.flusher.count
• 刷新線程的數量。用更少的線程，MemStore刷新將排隊。隨著線程數量的增加，刷新將並行執行，增加了HDFS的負載，並可能導致更多的壓縮。默認為：2

• hbase.hstore.blockingStoreFiles
• 如果任何一個Store中存在超過此數量的StoreFiles（每次刷新MemStore時將寫入一個StoreFile），則會阻止該區域的更新，直到壓縮完成或超出hbase.hstore.blockingWaitTime。默認為：16

• hbase.hstore.blockingWaitTime
• 在達到hbase.hstore.blockingStoreFiles定義的StoreFile限制後，區域將阻止更新的時間。經過這段時間後，即使壓縮尚未完成，該地區也將停止阻止更新。默認為：90000

• hbase.hstore.compaction.min
• 壓縮可以運行之前，必須有符合進行壓縮條件的最小StoreFiles數量。調整hbase.hstore.compaction.min的目標是避免使用太多的小型StoreFiles來壓縮。如果將此值設置為2，則每次在Store中有兩個StoreFiles時會導致輕微的壓縮，這可能不合適。如果將此值設置得太高，則需要相應調整所有其他值。對於大多數情況下，默認值是適當的。在以前的HBase版本中，參數hbase.hstore.compaction.min被命名為hbase.hstore.compactionThreshold。默認為：3

• hbase.hstore.compaction.max
• 無論符合條件的StoreFiles的數量如何，將為單個次要壓縮選擇的StoreFiles的最大數量。有效地，hbase.hstore.compaction.max的值控制單個壓縮完成所需的時間長度。將其設置得更大意味著更多的StoreFiles包含在壓縮中。對於大多數情況下，默認值是適當的。默認為：10

• hbase.hstore.compaction.min.size
• StoreFile（或使用ExploringCompactionPolicy時選擇的StoreFiles）小於此大小將始終有資格進行輕微壓縮。這個大小或更大的HFile通過hbase.hstore.compaction.ratio進行計算，以確定它們是否合格。由於此限制表示所有StoreFiles的“自動包含”限制小於此值，因此在需要刷新多個StoreFile（1-2 MB範圍內的許多StoreFiles）的寫入繁重環境中可能需要降低此值，因為每個StoreFile都將作為目標，對於壓縮而言，所得到的StoreFile可能仍然在最小尺寸下，並且需要進一步的壓縮。如果此參數降低，比率檢查會更快地觸發。這解決了在早期版本的HBase中看到的一些問題，但是在大多數情況下不再需要更改此參數。默認為：134217728

• hbase.hstore.compaction.max.size
• StoreFile（或使用ExploringCompactionPolicy時選擇的StoreFiles）大於此大小將被排除在壓縮之外。提高hbase.hstore.compaction.max.size的效果較少，較大的StoreFiles不經常壓縮。如果你覺得壓縮過於頻繁而沒有太多好處，你可以嘗試提高這個價值。默認值：LONG.MAX_VALUE的值，以字節表示。默認為：9223372036854775807

• hbase.hstore.compaction.ratio
• 對於輕微壓縮，此比率用於確定大於hbase.hstore.compaction.min.size的給定StoreFile是否適合壓縮。其作用是限制大型StoreFiles的壓縮。hbase.hstore.compaction.ratio的值以浮點小數表示。一個很大的比例，如10，將產生一個大型的StoreFile。相反，低值（如0.25）會產生類似於BigTable壓縮算法的行為，產生四個StoreFiles。推薦使用1.0到1.4之間的中等數值。在調整此值時，您要平衡寫入成本與讀取成本。提高價值（如1.4）會有更多的寫入成本，因為你會壓縮更大的StoreFiles。然而，在讀取期間，HBase將需要通過更少的StoreFiles來完成讀取。如果您不能利用Bloom過濾器，請考慮使用這種方法。否則，可以將此值降低到1.0以降低寫入的背景成本，並使用Bloom過濾器來控制讀取期間觸摸的StoreFiles的數量。對於大多數情況下，默認值是適當的。默認為：1.2F

• hbase.hstore.compaction.ratio.offpeak
• 允許您設置不同（默認情況下，更積極）的比率，以確定在非高峰時段是否包含較大的StoreFiles。以與hbase.hstore.compaction.ratio相同的方式工作。僅當hbase.offpeak.start.hour和hbase.offpeak.end.hour也被啟用時才適用。默認為：5.0F

• hbase.hstore.time.to.purge.deletes
• 使用未來的時間戳延遲清除標記的時間。如果未設置，或設置為0，則將在下一個主要壓縮過程中清除所有刪除標記（包括具有未來時間戳的標記）。否則，將保留一個刪除標記，直到在標記的時間戳之後發生的主要壓縮加上此設置的值（以毫秒為單位）。默認為：0

• hbase.offpeak.start.hour
• 非高峰時段開始，以0到23之間的整數表示，包括0和23之間的整數。設置為-1以禁用非高峰。默認為：-1

• hbase.offpeak.end.hour
• 非高峰時段結束，以0到23之間的整數表示，包括0和23之間的整數。設置為-1以禁用非高峰。默認為：-1

• hbase.regionserver.thread.compaction.throttle
• 有兩個不同的線程池用於壓縮，一個用於大型壓縮，另一個用於小型壓縮。這有助於保持精簡表（如hbase：meta）的快速壓縮。如果壓縮度大於此閾值，則會進入大型壓縮池。在大多數情況下，默認值是適當的。默認值：2 x hbase.hstore.compaction.max x hbase.hregion.memstore.flush.size（默認為128MB）。值字段假定hbase.hregion.memstore.flush.size的值與默認值相同。默認為：2684354560

• hbase.regionserver.majorcompaction.pagecache.drop
• 指定是否通過主要壓縮刪除讀取/寫入系統頁面緩存的頁面。將其設置為true有助於防止重大壓縮汙染頁面緩存，這幾乎總是要求的，特別是對於具有低/中等內存與存儲率的群集。默認為：true

• hbase.regionserver.minorcompaction.pagecache.drop
• 指定是否通過較小的壓縮刪除讀取/寫入系統頁面緩存的頁面。將其設置為true有助於防止輕微壓縮汙染頁面緩存，這對於內存與存儲比率較低的群集或寫入較重的群集是最有利的。當大部分讀取位於最近寫入的數據上時，您可能希望在中等到低寫入工作負載下將其設置為false。默認為：true

• hbase.hstore.compaction.kv.max
• 刷新或壓縮時要讀取並批量寫入的KeyValues的最大數量。如果你有較大的KeyValues，並且Out Of Memory Exceptions有問題，請將它設置得更低。默認為：10

• hbase.storescanner.parallel.seek.enable
• 在StoreScanner中啟用StoreFileScanner並行搜索功能，該功能可以在特殊情況下減少響應延遲。默認為：false

• hbase.storescanner.parallel.seek.threads
• 如果啟用了並行查找功能，則默認線程池大小。默認為：10

• hfile.block.cache.size
• StoreFile使用的最大堆（-Xmx設置）分配給塊緩存的百分比。默認值為0.4意味著分配40％。設置為0禁用，但不建議；您至少需要足夠的緩存來保存存儲文件索引。默認為：0.4

• hfile.block.index.cacheonwrite
• 這允許在索引被寫入時將非根多級索引塊放入塊高速緩存中。默認為：false

• hfile.index.block.max.size
• 當多級塊索引中葉級，中級或根級索引塊的大小增長到這個大小時，塊將被寫出並啟動一個新塊。默認為：131072

• hbase.bucketcache.ioengine
• 在哪裡存儲bucketcache的內容。其中之一：offheap、文件或mmap。如果有文件，則將其設置為file(s)：PATH_TO_FILE。mmap意味著內容將在一個mmaped文件中。使用mmap：PATH_TO_FILE。沒有默認值。

• hbase.bucketcache.size
• EITHER表示緩存的總堆內存大小的百分比（如果小於1.0），則表示BucketCache的總容量（兆字節）。默認值：0.0

• hbase.bucketcache.bucket.sizes
• 用於bucketcache的存儲區大小的逗號分隔列表。可以是多種尺寸。列出從最小到最大的塊大小。您使用的大小取決於您的數據訪問模式。必須是256的倍數，否則當你從緩存中讀取時，你會遇到“java.io.IOException：Invalid HFile block magic”。如果您在此處未指定任何值，那麼您可以選取代碼中設置的默認bucketsizes。沒有默認值。

• hfile.format.version
• 用於新文件的HFile格式版本。版本3添加了對hfiles中標籤的支持（請參閱http://hbase.apache.org/book.html#hbase.tags）。另請參閱配置“hbase.replication.rpc.codec”。默認為：3

• hfile.block.bloom.cacheonwrite
• 為複合Bloom過濾器的內聯塊啟用寫入緩存。默認為：false

• io.storefile.bloom.block.size
• 複合Bloom過濾器的單個塊（“chunk”）的字節大小。這個大小是近似的，因為Bloom塊只能被插入到數據塊的邊界處，而每個數據塊的key的個數也不相同。默認為：131072

• hbase.rs.cacheblocksonwrite
• 塊完成後，是否應將HFile塊添加到塊緩存中。默認為：false

• hbase.rpc.timeout
• 這是為了讓RPC層定義一個遠程調用超時（毫秒）HBase客戶端應用程序超時。它使用ping來檢查連接，但最終會拋出TimeoutException。默認為：60000

• hbase.client.operation.timeout
• 操作超時是一個頂級的限制（毫秒），確保表格中的阻止操作不會被阻止超過這個限制。在每個操作中，如果rpc請求由於超時或其他原因而失敗，則將重試直到成功或拋出RetriesExhaustedException。但是，如果總的阻塞時間在重試耗盡之前達到操作超時，則會提前中斷並拋出SocketTimeoutException。默認為：1200000

• hbase.cells.scanned.per.heartbeat.check
• 在heartbeat檢查之間掃描的單元格的數量。在掃描處理過程中會發生heartbeat檢查，以確定服務器是否應該停止掃描，以便將heartbeat消息發送回客戶端。heartbeat消息用於在長時間運行掃描期間保持客戶端 - 服務器連接的活動。較小的值意味著heartbeat檢查將更頻繁地發生，因此將對掃描的執行時間提供更嚴格的界限。數值越大意味著heartbeat檢查發生的頻率越低。默認為：10000

• hbase.rpc.shortoperation.timeout
• 這是“hbase.rpc.timeout”的另一個版本。對於集群內的RPC操作，我們依靠此配置為短操作設置短超時限制。例如，區域服務器試圖向活動主服務器報告的短rpc超時可以更快地進行主站故障轉移過程。默認為：10000

• hbase.ipc.client.tcpnodelay
• 在rpc套接字連接上設置沒有延遲。默認為：true

• hbase.regionserver.hostname
• 這個配置適用於對HBase很熟悉的人：除非你真的知道你在做什麼，否則不要設定它的價值。當設置為非空值時，這表示底層服務器的（面向外部）主機名。沒有默認值。

• hbase.regionserver.hostname.disable.master.reversedns
• 這個配置適用於對HBase很熟練的人：除非你真的知道你在做什麼，否則不要設定它的價值。當設置為true時，regionserver將使用當前節點主機名作為服務器名稱，HMaster將跳過反向DNS查找並使用regionserver發送的主機名。請注意，此配置和hbase.regionserver.hostname是互斥的。默認為：false

• hbase.master.keytab.file
• 用於登錄配置的HMaster服務器主體的kerberos密鑰表文件的完整路徑。沒有默認值。

• hbase.master.kerberos.principal
• “hbase/[email protected]”，應該用來運行HMaster進程的Kerberos主體名稱。主體名稱的格式應為：user/hostname @ DOMAIN。如果使用“_HOST”作為主機名部分，它將被替換為正在運行的實例的實際主機名。沒有默認值。

• hbase.regionserver.keytab.file
• 用於登錄配置的HRegionServer服務器主體的kerberos密鑰表文件的完整路徑。沒有默認值。

• hbase.regionserver.kerberos.principal
• “hbase/[email protected]”。應該用來運行HRegionServer進程的kerberos主體名稱。主體名稱的格式應為：user/hostname @ DOMAIN。如果使用“_HOST”作為主機名部分，它將被替換為正在運行的實例的實際主機名。此主體的條目必須存在於hbase.regionserver.keytab.file中指定的文件中
  沒有默認值。

• hadoop.policy.file
• RPC服務器使用策略配置文件對客戶端請求進行授權決策。僅在啟用HBase安全性時使用。默認為：hbase-policy.xml

• hbase.superuser
• 用戶或組列表（以逗號分隔），允許在整個集群中擁有完全權限（不管存儲的ACL）。僅在啟用HBase安全性時使用。沒有默認值。

• hbase.auth.key.update.interval
• 服務器中認證令牌的主密鑰的更新間隔（以毫秒為單位）。僅在啟用HBase安全性時使用。默認為：86400000

• hbase.auth.token.max.lifetime
• 驗證令牌過期的最長生存時間（以毫秒為單位）。僅在啟用HBase安全性時使用。默認為：604800000

• hbase.ipc.client.fallback-to-simple-auth-allowed
• 當客戶端配置為嘗試安全連接，但嘗試連接到不安全的服務器時，該服務器可能會指示客戶端切換到SASL SIMPLE（不安全）身份驗證。此設置控制客戶端是否接受來自服務器的此指令。如果為false（默認值），則客戶端將不允許回退到SIMPLE身份驗證，並會中止連接。默認為：false

• hbase.ipc.server.fallback-to-simple-auth-allowed
• 當服務器配置為需要安全連接時，它將拒絕來自使用SASL SIMPLE（不安全）身份驗證的客戶端的連接嘗試。此設置允許安全服務器在客戶端請求時接受來自客戶端的SASL SIMPLE連接。如果為false（默認值），服務器將不允許回退到SIMPLE身份驗證，並將拒絕連接。警告：只有在將客戶端轉換為安全身份驗證時，才應將此設置用作臨時措施。必須禁止它才能進行安全操作。默認為：false

• hbase.display.keys
• 當它被設置為true時，webUI等將顯示所有開始/結束鍵作為表格細節，區域名稱等的一部分。當這被設置為假時，鍵被隱藏。默認為：true

• hbase.coprocessor.enabled
• 啟用或禁用協處理器加載。如果'false'（禁用），任何其他協處理器相關的配置將被忽略。默認為：true

• hbase.coprocessor.user.enabled
• 啟用或禁用用戶（又名錶）協處理器加載。如果'false'（禁用），則表格描述符中的任何表協處理器屬性將被忽略。如果“hbase.coprocessor.enabled”為“false”，則此設置無效。默認為：true

• hbase.coprocessor.region.classes
• 在所有表上默認加載的區域觀察者或端點協處理器的逗號分隔列表。對於任何覆蓋協處理器方法，這些類將按順序調用。在實現自己的協處理器之後，將其添加到HBase的類路徑中，並在此處添加完全限定的類名稱。協處理器也可以通過設置HTableDescriptor或者HBase shell來按需加載。沒有默認值。

• hbase.coprocessor.master.classes
• 在活動的HMaster進程中默認加載的org.apache.hadoop.hbase.coprocessor.MasterObserver協處理器的逗號分隔列表。對於任何實施的協處理器方法，列出的類將按順序調用。在實現你自己的MasterObserver之後，把它放在HBase的類路徑中，並在這裡添加完全限定的類名稱。沒有默認值。

• hbase.coprocessor.abortonerror
• 如果協處理器加載失敗，初始化失敗或引發意外的Throwable對象，則設置為true將導致託管服務器（主服務器或區域服務器）中止。將其設置為false將允許服務器繼續執行，但所涉及的協處理器的系統範圍狀態將變得不一致，因為它只能在一部分服務器中正確執行，所以這對於僅調試是非常有用的。默認為：true

• hbase.rest.port
• HBase REST服務器的端口。默認為：8080

• hbase.rest.readonly
• 定義REST服務器將啟動的模式。可能的值有：false：此時，所有的HTTP方法都是允許的 - GET / PUT / POST / DELETE。true：此時只允許GET方法。默認為：false

• hbase.rest.threads.max
• REST服務器線程池的最大線程數。池中的線程被重用來處理REST請求。這將控制同時處理的最大請求數。這可能有助於控制REST服務器使用的內存以避免OOM問題。如果線程池已滿，則傳入的請求將排隊並等待一些空閒的線程。默認為：100

• hbase.rest.threads.min
• REST服務器線程池的最小線程數。線程池總是至少有這麼多的線程，所以REST服務器已經準備好為傳入的請求提供服務。默認為：2

• hbase.rest.support.proxyuser
• 啟用運行REST服務器以支持代理用戶模式。默認為：false

• hbase.defaults.for.version.skip
• 設置為true可以跳過“hbase.defaults.for.version”檢查。將其設置為true可以在除maven生成的另一側之外的上下文中有用；即運行在IDE中。你需要設置這個布爾值為true以避免看到RuntimeException：“hbase-default.xml文件似乎是HBase（\\ $ {hbase.version}）的舊版本，這個版本是XXX-SNAPSHOT”默認為：false

• hbase.table.lock.enable
• 設置為true以啟用鎖定zookeeper中的表以進行模式更改操作。從主服務器鎖定表可以防止併發的模式修改損壞表狀態。默認為：true

• hbase.table.max.rowsize
• 單行字節的最大大小（默認值為1 Gb），用於Get-ing或Scan'ning，不設置行內掃描標誌。如果行大小超過此限制RowTooBigException被拋出到客戶端。默認為：1073741824

• hbase.thrift.minWorkerThreads
• 線程池的“核心大小”。在每個連接上創建新線程，直到創建了許多線程。默認為：16

• hbase.thrift.maxWorkerThreads
• 線程池的最大大小。待處理的請求隊列溢出時，將創建新線程，直到其號碼達到此數字。之後，服務器開始丟棄連接。默認為：1000

• hbase.thrift.maxQueuedRequests
• 在隊列中等待的最大等待節點連接數。如果池中沒有空閒線程，則服務器將請求排隊。只有當隊列溢出時，才會添加新的線程，直到hbase.thrift.maxQueuedRequests線程。默認為：1000

• hbase.regionserver.thrift.framed
• 在服務器端使用Thrift TFramedTransport。對於thrift服務器，這是推薦的傳輸方式，需要在客戶端進行類似的設置。將其更改為false將選擇默認傳輸，當由於THRIFT-601發出格式錯誤的請求時，容易受到DoS的影響。默認為：false

• hbase.regionserver.thrift.framed.max_frame_size_in_mb
• 使用成幀傳輸時的默認幀大小，以MB為單位。默認為：2

• hbase.regionserver.thrift.compact
• 使用Thrift TCompactProtocol二進制序列化協議。默認為：false

• hbase.rootdir.perms
• 安全（kerberos）安裝程序中根數據子目錄的FS Permissions。主服務器啟動時，會使用此權限創建rootdir，如果不匹配則設置權限。
• 默認為：700

• hbase.wal.dir.perms
• 安全（kerberos）安裝程序中的根WAL目錄的FS Permissions。當主服務器啟動時，它將使用此權限創建WAL目錄，如果不匹配則設置權限。默認為：700

• hbase.data.umask.enable
• 如果啟用，則啟用該文件權限應分配給區域服務器寫入的文件默認為：false

• hbase.data.umask
• 當hbase.data.umask.enable為true時，應該用來寫入數據文件的文件權限默認為：000

• hbase.snapshot.enabled
• 設置為true以允許taken/restored/cloned。默認為：true

• hbase.snapshot.restore.take.failsafe.snapshot
• 設置為true以在還原操作之前得到快照。所得到的快照將在失敗的情況下使用，以恢復以前的狀態。在還原操作結束時，此快照將被刪除默認為：true

• hbase.snapshot.restore.failsafe.name
• restore操作所採用的故障安全快照的名稱。您可以使用{snapshot.name}，{table.name}和{restore.timestamp}變量根據要恢復的內容創建一個名稱。默認為：hbase-failsafe-{snapshot.name}-{restore.timestamp}

• hbase.server.compactchecker.interval.multiplier
• 這個數字決定了我們掃描的頻率，看是否需要壓縮。通常情況下，壓縮是在某些事件（如memstore flush）之後完成的，但是如果區域在一段時間內沒有收到大量的寫入，或者由於不同的壓縮策略，則可能需要定期檢查。檢查之間的時間間隔是hbase.server.compactchecker.interval.multiplier乘以hbase.server.thread.wakefrequency。默認為：1000

• hbase.lease.recovery.timeout
• 在放棄之前，我們等待dfs lease的總恢復時間。默認為：900000

• hbase.lease.recovery.dfs.timeout
• dfs恢復lease調用之間的時間間隔。應該大於namenode為datanode的一部分發出塊恢復命令所需的時間總和；dfs.heartbeat.interval和主數據節點所花費的時間，在死數據節點上執行數據塊恢復到超時；通常是dfs.client.socket-timeout。默認為：64000

• hbase.column.max.version
• 新的列族描述符將使用此值作為要保留的默認版本數。默認為：1

• dfs.client.read.shortcircuit
• 如果設置為true，則此配置參數啟用short-circuit本地讀取。默認為：false

• dfs.domain.socket.path
• 如果將dfs.client.read.shortcircuit設置為true，則這是一個UNIX域套接字的路徑，該套接字將用於DataNode與本地HDFS客戶端之間的通信。如果該路徑中存在字符串“_PORT”，則會被DataNode的TCP端口替換。請注意託管共享域套接字的目錄的權限。默認為：none

• hbase.dfs.client.read.shortcircuit.buffer.size
• 如果未設置DFSClient配置dfs.client.read.shortcircuit.buffer.size，我們將使用此處配置的內容作為short-circuit讀取默認直接字節緩衝區大小。DFSClient本機默認值是1MB；HBase保持HDFS文件的打開狀態，所以文件塊*1MB的數量很快就開始累積起來，並由於直接內存不足而威脅OOME。所以，我們從默認設置下來。使它大於在HColumnDescriptor中設置的默認hbase塊大小，通常是64k。默認為：131072

• hbase.regionserver.checksum.verify
• 如果設置為true（默認），HBase將驗證hfile塊的校驗和。當HBase寫出hfiles時，HBase將校驗和寫入數據。HDFS（在此寫入時）將校驗和寫入單獨的文件，而不是需要額外查找的數據文件。設置這個標誌可以節省一些I/O。設置此標誌時，HDFS的校驗和驗證將在hfile流內部禁用。如果hbase-checksum驗證失敗，我們將切換回使用HDFS校驗和（所以不要禁用HDFS校驗！除此功能外，還適用於hfiles，而不適用於WAL）。如果這個參數設置為false，那麼hbase將不會驗證任何校驗和，而是取決於HDFS客戶端中的校驗和驗證。默認為：true

• hbase.hstore.bytes.per.checksum
• 新創建的校驗和塊中的字節數，用於hfile塊中的HBase級校驗和。默認為：16384

• hbase.hstore.checksum.algorithm
• 用於計算校驗和的算法的名稱。可能的值是NULL，CRC32，CRC32C。默認為：CRC32C

• hbase.client.scanner.max.result.size
• 調用掃描器的下一個方法時返回的最大字節數。請注意，當單個行大於此限制時，行仍然完全返回。默認值是2MB，這對於1ge網絡是有好處的。有了更快和/或更高的延遲網絡，這個值應該增加。默認為：2097152

• hbase.server.scanner.max.result.size
• 調用掃描器的下一個方法時返回的最大字節數。請注意，當單個行大於此限制時，行仍然完全返回。默認值是100MB。這是保護服務器免受OOM情況的安全設置。默認為：104857600

• hbase.status.published
• 該設置激活了主控發佈區域服務器的狀態。當一臺區域服務器死亡並開始恢復時，主服務器會將這些信息推送到客戶端應用程序，讓他們立即切斷連接，而不是等待超時。默認為：false

• hbase.status.publisher.class
• 用multicast消息實現狀態發佈。默認為：org.apache.hadoop.hbase.master.ClusterStatusPublisher$MulticastPublisher

• hbase.status.listener.class
• 使用multicast消息實現狀態監聽器。默認為：org.apache.hadoop.hbase.client.ClusterStatusListener$MulticastListener

• hbase.status.multicast.address.ip
• 用於multicase狀態發佈的multicase地址。默認為：226.1.1.3

• hbase.status.multicast.address.port
• 用於multicase狀態發佈的multicase端口。默認為：16100

• hbase.dynamic.jars.dir
• 自定義過濾器JAR的目錄可以由區域服務器動態加載，而無需重新啟動。但是，已加載的過濾器/協處理器類將不會被卸載。不適用於協處理器。默認為：${hbase.rootdir}/lib

• hbase.security.authentication
• 控制是否為HBase啟用安全身份驗證。可能的值是“simple”（不認證）和“Kerberos”。默認為：simple

• hbase.rest.filter.classes
• 用於REST服務的Servlet過濾器。默認為：org.apache.hadoop.hbase.rest.filter.GzipFilter

• hbase.master.loadbalancer.class
• 用於在期間發生時執行區域平衡的類。它將DefaultLoadBalancer替換為默認值（因為它被重命名為SimpleLoadBalancer ）。默認為：org.apache.hadoop.hbase.master.balancer.StochasticLoadBalancer

• hbase.master.loadbalance.bytable
• 平衡器運行時的因子表名稱。默認：false。默認為：false

• hbase.master.normalizer.class
• 用於執行期間發生時的區域標準化的類。默認為：org.apache.hadoop.hbase.master.normalizer.SimpleRegionNormalizer

• hbase.rest.csrf.enabled
• 設置為true以啟用對跨站點請求forgery（CSRF）的保護。默認為：false

• hbase.rest-csrf.browser-useragents-regex
• 通過將hbase.rest.csrf.enabled設置為true來啟用為REST服務器，針對跨站點請求偽造（CSRF）的防護時，用於匹配HTTP請求的User-Agent標頭的正則表達式的逗號分隔列表。如果傳入的用戶代理與這些正則表達式中的任何一個相匹配，則認為該請求被瀏覽器發送，因此CSRF預防被強制執行。如果請求的用戶代理與這些正則表達式中的任何一個都不匹配，則該請求被認為是由除瀏覽器以外的其他東西發送的，例如腳本自動化。在這種情況下，CSRF不是一個潛在的攻擊向量，所以預防沒有被執行。這有助於實現與尚未更新以發送CSRF預防報頭的現有自動化的向後兼容性。默認為：Mozilla.
  ,Opera.

• hbase.security.exec.permission.checks
• 如果啟用此設置，並且基於ACL的訪問控制處於活動狀態（AccessController協處理器作為系統協處理器安裝，或作為表協處理器安裝在表上），則必須授予所有相關用戶EXEC權限（如果需要執行協處理器端點調用。像任何其他權限一樣，EXEC權限可以在全局範圍內授予用戶，也可以授予每個表或命名空間的用戶。有關協處理器端點的更多信息，請參閱HBase聯機手冊的協處理器部分。有關使用AccessController授予或撤消權限的更多信息，請參閱HBase聯機手冊的安全性部分。默認為：false

• hbase.procedure.regionserver.classes
• 在活動HRegionServer進程中默認加載的org.apache.hadoop.hbase.procedure.RegionServerProcedureManager過程管理器的逗號分隔列表。生命週期方法（init / start / stop）將由活動的HRegionServer進程調用，以執行特定的全局barriered過程。在實現你自己的RegionServerProcedureManager之後，把它放在HBase的類路徑中，並在這裡添加完全限定的類名稱。

• hbase.procedure.master.classes
• 在活動HMaster進程中默認加載的org.apache.hadoop.hbase.procedure.MasterProcedureManager過程管理器的逗號分隔列表。程序通過其簽名進行標識，用戶可以使用簽名和即時名稱來觸發全局程序的執行。在實現你自己的MasterProcedureManager之後，把它放在HBase的類路徑中，並在這裡添加完全限定的類名稱。

• hbase.coordinated.state.manager.class
• 協調狀態管理員的完全合格的名字。默認為：org.apache.hadoop.hbase.coordination.ZkCoordinatedStateManager

• hbase.regionserver.storefile.refresh.period
• 用於刷新輔助區域的存儲文件的時間段（以毫秒為單位）。0意味著此功能被禁用。輔助區域在次要區域刷新區域中的文件列表時會看到來自主要文件的新文件（來自刷新和壓縮）（沒有通知機制）。但是頻繁刷新可能會導致額外的Namenode壓力。如果文件的刷新時間不能超過HFile TTL（hbase.master.hfilecleaner.ttl），請求將被拒絕。此設置還建議將HFile TTL配置為較大的值。默認為：0

• hbase.region.replica.replication.enabled
• 是否啟用對輔助區域副本的異步WAL複製。如果啟用了此功能，則會創建一個名為“region_replica_replication”的複製對等項，它將對日誌進行尾隨處理，並將突變複製到區域複製大於1的區域複製的區域複製。如果啟用一次，禁用此複製也需要禁用複製對等使用shell或Admin java類。複製到輔助區域副本可以在標準群集間複製上工作。默認為：false

• hbase.http.filter.initializers
• 一個以逗號分隔的類名列表。列表中的每個類都必須擴展org.apache.hadoop.hbase.http.FilterInitializer。相應的過濾器將被初始化。然後，過濾器將應用於所有面向jsp和servlet網頁的用戶。列表的排序定義了過濾器的排序。默認的StaticUserWebFilter添加hbase.http.staticuser.user屬性定義的用戶主體。默認為：org.apache.hadoop.hbase.http.lib.StaticUserWebFilter

• hbase.security.visibility.mutations.checkauths
• 如果啟用此屬性，將檢查可見性表達式中的標籤是否與發出突變的用戶相關聯默認為：false

• hbase.http.max.threads
• HTTP服務器將在其ThreadPool中創建的最大線程數。默認為：16

• hbase.replication.rpc.codec
• 啟用複製時要使用的編解碼器，以便標籤也被複制。這與支持標籤的HFileV3一起使用。如果標籤未被使用或者所使用的hfile版本是HFileV2，則可以使用KeyValueCodec作為複製編解碼器。請注意，在沒有標籤時使用KeyValueCodecWithTags進行復制不會造成任何傷害。默認為：org.apache.hadoop.hbase.codec.KeyValueCodecWithTags

• hbase.replication.source.maxthreads
• 任何複製源將用於並行傳送編輯到接收器的最大線程數。這也限制了每個複製批次被分解成的塊的數量。較大的值可以提高主群集和從群集之間的複製吞吐量。默認值為10，很少需要改變。默認為：10

• hbase.serial.replication.waitingMs
• 默認情況下，在複製中，我們不能確定slave集群中的操作順序與master集群中的順序相同。如果將REPLICATION_SCOPE設置為2，我們將按照寫入順序進行編輯。這個配置是設置在下一次檢查之前，我們將等待多長時間（以毫秒為單位），如果日誌不能被推送，因為有一些日誌寫在它之前還沒有被推入。較大的等待將減少hbase：meta上的查詢數量，但會增加複製的延遲。此功能依賴於zk-less分配，因此用戶必須將hbase.assignment.usezk設置為false來支持它。默認為：10000

• hbase.http.staticuser.user
• 要在呈現內容時在靜態網頁過濾器上過濾的用戶名稱。一個示例使用是HDFS Web UI（用於瀏覽文件的用戶）。默認為：dr.stack

• hbase.regionserver.handler.abort.on.error.percent
• 區域服務器RPC線程的百分比無法中止RS。-1表示禁用中止；0表示即使單個處理程序已經死亡也會中止；0.x表示只有當這個百分比的處理程序死亡時才中止；1表示只中止所有的處理程序已經死亡。默認為：0.5

• hbase.mob.file.cache.size
• 要緩存的已打開文件處理程序的數量。更大的值將通過為每個移動文件緩存提供更多的文件處理程序來減少頻繁的文件打開和關閉，從而有利於讀取。但是，如果設置得太高，則可能導致“打開的文件處理程序太多”。默認值為1000。默認為：1000

• hbase.mob.cache.evict.period
• mob高速緩存驅逐高速緩存的mob文件之前的時間（秒）。默認值是3600秒。默認為：3600

• hbase.mob.cache.evict.remain.ratio
• 當緩存的移動文件數量超過hbase.mob.file.cache.size時，觸發驅逐後保留的文件的比率（介於0.0和1.0之間）會被觸發。默認值是0.5f。默認為：0.5f

• hbase.master.mob.ttl.cleaner.period
• ExpiredMobFileCleanerChore運行的時間段。該單位是秒。默認值是一天。MOB文件名僅使用文件創建時間的日期部分。我們使用這個時間來決定文件的TTL到期時間。所以刪除TTL過期的文件可能會被延遲。最大延遲可能是24小時。默認為：86400

• hbase.mob.compaction.mergeable.threshold
• 如果一個mob文件的大小小於這個值，那麼它被認為是一個小文件，需要在mob compaction中合併。默認值是1280MB。默認為：1342177280

• hbase.mob.delfile.max.count
• mob壓縮中允許的最大del文件數。在mob壓縮中，當現有的del文件的數量大於這個值時，它們被合併，直到del文件的數量不大於該值。默認值是3。默認為：3

• hbase.mob.compaction.batch.size
• 在一批mob壓縮中所允許的mob文件的最大數量。mob壓縮合並小的mob文件到更大的。如果小文件的數量非常大，則可能導致合併中的“打開的文件處理程序太多”。合併必須分成批次。此值限制在一批mob壓縮中選擇的mob文件的數量。默認值是100。默認為：100

• hbase.mob.compaction.chore.period
• MobCompactionChore運行的時間。該單位是秒。默認值是一個星期。默認為：604800

• hbase.mob.compactor.class
• 執行mob compactor，默認一個是PartitionedMobCompactor。默認為：org.apache.hadoop.hbase.mob.compactions.PartitionedMobCompactor

• hbase.mob.compaction.threads.max
• MobCompactor中使用的最大線程數。默認為：1

• hbase.snapshot.master.timeout.millis
• 主快照程序執行的超時。默認為：300000

• hbase.snapshot.region.timeout
• 區域服務器將線程保持在快照請求池中等待超時。默認為：300000

• hbase.rpc.rows.warning.threshold
• 批處理操作中的行數，超過該值將記錄警告。默認為：5000

• hbase.master.wait.on.service.seconds
• 默認是5分鐘。做30秒的測試。有關上下文，請參見HBASE-19794。默認為：30

hbase-env.sh

hbase-env.sh文件用來設置HBase環境變量。比如包括在啟動HBase守護程序（如堆大小和垃圾回收器配置）時傳遞JVM的選項。您還可以設置HBase配置、日誌目錄、niceness、ssh選項，定位進程pid文件的位置等的配置。打開conf/hbase-env.sh文件並仔細閱讀其內容。每個選項都有相當好的記錄。如果希望在啟動時由HBase守護進程讀取，請在此處添加您自己的環境變量。

此處的更改將需要重啟HBase才能注意到更改。

log4j.properties

編輯此文件以更改HBase文件的滾動速度，並更改HBase記錄消息的級別。

此處的更改將需要重新啟動集群以注意到更改，儘管可以通過HBase UI為特定的守護程序更改日誌級別。

客戶端配置和依賴關係連接到HBase集群

如果您在獨立模式下運行HBase，則不必為您的客戶端配置任何內容，只要保證它們在同一臺計算機上即可。

由於HBase Master可以移動，客戶可以通過向ZooKeeper尋找當前的關鍵位置來進行引導。ZooKeeper是保存所有這些值的地方。因此客戶需要ZooKeeper集合的位置才能做其他事情。通常這個集合位置被保存在hbase-site.xml中，並由客戶端從CLASSPATH中提取。

如果你正在配置一個IDE來運行一個HBase客戶端，你應該在你的類路徑中包含conf/目錄，這樣可以找到hbase-site.xml設置（或者添加src/test/resources來獲取使用的hbase-site.xml文件通過測試）。

最小的情況是，當連接到集群時，HBase客戶機需要依賴關係中的hbase-client模塊：

一個基本的客戶端的hbase-site.xml的使用示例可能如下所示：

Java客戶端配置

Java客戶端使用的配置保存在HBaseConfiguration實例中。

HBaseConfiguration的工廠方法，HBaseConfiguration.create();，在調用時會讀取客戶端上的第一個hbase-site.xml的內容（CLASSPATH如果存在的話）（調用也將包含在任何發現的hbase-default.xml中；hbase-default.xml在hbase.X.X.X.jar裡面）。也可以直接指定配置，而無需從hbase-site.xml中讀取數據。例如，要以編程方式設置集群的ZooKeeper集成，請執行以下操作:

如果多個ZooKeeper實例組成ZooKeeper集合，則可以在逗號分隔列表中指定它們（就像在hbase-site.xml文件中一樣）。這個填充的Configuration實例然後可以傳遞給一個表，依此類推。

閱讀更多 會飛的魚go 的文章

關鍵字: HBase Hadoop 通常