Apache HBase Configuration · HBase? 中文參考指南 3.0

# Apache HBase 配置 > 貢獻者：[xixici](https://github.com/xixici) 在上一章[快速開始](#getting_started)的內容中，你學習了如何啟動獨立式、偽分布式以及完全分布式 HBase，在本章中，我們將介紹更多關于 Apache HBase 的配置，以進一步了解 Apache HBase。請仔細閱讀本章，特別是[基本配置條件](#basic.prerequisites)部分，該部分能夠確保您的 HBase 測試和部署順利進行，并防止數據丟失。現在，一起進入學習吧！ ## 3\. 配置文件 Apache HBase 使用與 Apache Hadoop 相同的配置系統。所有配置文件都位于 _conf/_ 目錄中，需要保持群集中每個節點的同步。 ### HBase 配置文件說明 _backup-masters_ 默認情況下不存在。這是一個純文本文件，其中列出了主服務器應在其上啟動備份主進程的主機，每行一臺主機。 _hadoop-metrics2-hbase.properties_ 用于連接 HBase Hadoop 的 Metrics2 框架。有關 Metrics2 的更多信息，請參閱[Hadoop Wiki](https://wiki.apache.org/hadoop/HADOOP-6728-MetricsV2) 。默認情況下只包含注釋出的示例。 _hbase-env.cmd_ and _hbase-env.sh_ 用于 Windows 和 Linux/Unix 環境的腳本，以設置 HBase 的工作環境，包括 Java、Java 選項和其他環境變量的位置。該文件包含許多注釋示例來提供指導。 _hbase-policy.xml_ RPC 服務器使用默認策略配置文件對客戶端請求進行授權決策。僅在啟用 HBase[安全](#security)模式下使用。 _hbase-site.xml_ 主要的 HBase 配置文件。該文件指定覆蓋 HBase 的默認配置的配置選項。您可以在 _docs/hbase-default.xml_ 中查看（但不要編輯）默認配置文件。您還可以在 HBase Web UI 的 HBase 配置選項卡中查看群集的整個有效配置（默認和覆蓋）。 _log4j.properties_ 通過`log4j`進行 HBase 日志記錄的配置文件。 _regionservers_ 包含應該在 HBase 集群中運行 RegionServer 的主機列表的純文本文件。默認情況下，這個文件包含單個條目`localhost`t。它應該包含主機名或 IP 地址列表，每行一個，如果集群中的每個節點將在其`localhost`接口上運行 RegionServer 的話，則只應包含`localhost` > 檢查 XML 有效性 > > 在編輯 XML 時，最好使用支持 XML 的編輯器，以確保您的語法正確且 XML 格式良好。您還可以使用該`xmllint` 程序檢查您的 XML 格式是否正確。默認情況下，`xmllint` 重新流動并將 XML 打印到標準輸出。要檢查格式是否正確，并且只在存在錯誤時才打印輸出，請使用命令`xmllint -noout filename.xml`。 > 在集群之間保持同步配置 > > 當在分布式模式下運行時, 在對 HBase 配置進行編輯后，請確保將 conf/目錄的內容復制到群集的所有節點。HBase 不會為你這么做的。請使用 `rsync`, `scp`或其他安全機制將配置文件復制到你的節點。對于大多數配置, 服務器需要重新啟動才能成功更改。動態配置是這方面的一個例外，在之后的內容將對此進行說明。 ## 4\. HBase 基礎條件在本節中，我們列出了使用 HBase 時所需要的服務和一些必需的系統配置。 Java 在下表中你可以看到 HBase 版本與其對應支持的 JDK 版本：社區很樂意幫助你診斷和解決可能遇到的問題.你需要進去社區查找類似問題,可能需要你更改 java 環境.某些情況下,例如編譯/測試單元有效性,具體操作問題)也要注意. > 建議使用長期支持 JDKs > > HBase 建議用戶依賴長期支持 (LTS)版本的 JDK,無論是 OpenJDK 項目或其他.截至 2018 年 3 月，這意味著 Java 8 是唯一適用的版本，而下一個可能的測試版本將是 2018 Q3 的 Java 11。 | HBase Version | JDK 7 | JDK 8 | JDK 9 (Non-LTS) | JDK 10 (Non-LTS) | JDK 11 | | ------------- | ----- | ----- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | | 2.0+ | | | [HBASE-20264](https://issues.apache.org/jira/browse/HBASE-20264) | [HBASE-20264](https://issues.apache.org/jira/browse/HBASE-20264) | [HBASE-21110](https://issues.apache.org/jira/browse/HBASE-21110) | | 1.2+ | | | [HBASE-20264](https://issues.apache.org/jira/browse/HBASE-20264) | [HBASE-20264](https://issues.apache.org/jira/browse/HBASE-20264) | [HBASE-21110](https://issues.apache.org/jira/browse/HBASE-21110) | > HBase 不支持 Java 6 的構建或編譯 > 你必須在集群的每個節點上設置`JAVA_HOME` 。_hbase-env.sh_ 提供了一種方便的機制。操作系統 ssh （必須的）HBase 廣泛使用安全 Shell（ssh）命令和實用程序在集群節點之間進行通信。集群中的每臺服務器都必須運行`ssh`，以便可以管理 Hadoop 和 HBase 后臺進程。您必須能夠使用共享密鑰而不是密碼，通過 SSH（包括本地節點）從主服務器和任何備份主服務器連接到所有節點。您可以在 Linux 或 Unix 系統中的"[Procedure: Configure Passwordless SSH Access](#passwordless.ssh.quickstart)"（配置無密碼 SSH 訪問）中看到這種設置的基本方法。如果群集節點使用 OS X，請參閱[SSH: Setting up Remote Desktop and Enabling Self-Login](https://wiki.apache.org/hadoop/Running_Hadoop_On_OS_X_10.5_64-bit_%28Single-Node_Cluster%29) DNS HBase 使用本地主機名來自行報告其 IP 地址 NTP 群集節點上的時鐘應該同步。少量的變化是可以接受的，但是大量的不同會導致不穩定和意外的行為。如果在群集中看到無法解釋的問題，則時間同步是首先要檢查的事項之一。建議您在群集上運行網絡時間協議（NTP）服務或其他時間同步機制，并且所有節點都查找相同的服務以進行時間同步。請參閱 _The Linux Documentation Project (TLDP)_ 中的[Basic NTP Configuration](http://www.tldp.org/LDP/sag/html/basic-ntp-config.html)以設置 NTP。文件和進程數限制 Apache HBase 是一個數據庫。它需要能夠一次打開大量的文件。許多 Linux 發行版限制了允許單個用戶打開的文件數量`1024`（或者`256`，在舊版本的 OS X 上）。當以運行 HBase 的用戶身份登錄時，您可以通過在服務器上運行`ulimit -n` 命令來檢查服務器上的限制。限制太低會產生一些 [故障](#trouble.rs.runtime.filehandles) 您也可能會注意到以下錯誤： ``` 2010-04-06 03:04:37,542 INFO org.apache.hadoop.hdfs.DFSClient: Exception increateBlockOutputStream java.io.EOFException 2010-04-06 03:04:37,542 INFO org.apache.hadoop.hdfs.DFSClient: Abandoning block blk_-6935524980745310745_1391901 ``` 建議將 ulimit 提高到至少 10,000，但更可能是 10,240，因為該值通常以 1024 的倍數表示。每個 ColumnFamily 至少有一個 StoreFile，如果該區域處于加載狀態，則可能有多于六個的 StoreFile。所需的打開文件的數量取決于 ColumnFamilies 的數量和區域的數量。以下是計算 RegionServer 上打開的文件的潛在數量的粗略公式。計算打開文件的潛在數量： ``` (StoreFiles per ColumnFamily) x (regions per RegionServer) ``` 假設一個模式的每個區域有 3 個 ColumnFamilies，每個 ColumnFamily 平均有 3 個 StoreFiles，每個 RegionServer 有 100 個區域，則 JVM 將打開`3 * 3 * 100 = 900`文件描述符，不包括打開的 JAR 文件、配置文件等等。打開一個文件不需要很多資源，而且允許用戶打開太多文件的風險很小。另一個相關設置是允許用戶同時運行的進程數量。在 Linux 和 Unix 中，使用該`ulimit -u` 命令設置進程的數量。這不應與`nproc`命令混淆，該命令控制給定用戶可用的 CPU 數量。在負載下，`ulimit -u`太低會導致 OutOfMemoryError 異常。為運行 HBase 進程的用戶配置文件描述符和進程的最大數量是操作系統配置，而不是 HBase 配置。確保為實際運行 HBase 的用戶更改設置也很重要。要查看哪個用戶啟動了 HBase，以及該用戶的 ulimit 配置，請查看該實例的 HBase 日志的第一行。示例 2\. `ulimit` 在 Ubuntu 上的設置要在 Ubuntu 上配置 _limits.conf_ 設置，請編輯：_/etc/security/limits.conf_，它是一個由四列組成的空格分隔的文件。在以下示例中，第一行將用戶名為 hadoop 的操作系統用戶的打開文件數（nofile）的軟限制和硬限制設置為 32768。第二行將同一用戶的進程數設置為 32000。 ``` hadoop - nofile 32768 hadoop - nproc 32000 ``` 這些設置僅適用于可插入身份驗證模塊（PAM）環境指示使用它們的情況。要配置 PAM 以使用這些限制，請確保 _/etc/pam.d/common-session_ 文件包含以下行： ``` session required pam_limits.so ``` Linux Shell 所有 HBase 附帶的 shell 腳本都依賴于[GNU Bash](http://www.gnu.org/software/bash) shell. Windows 不建議在 Windows 計算機上運行生產系統。 ### 4.1\. [Hadoop](https://hadoop.apache.org) 下表總結了每個 HBase 版本支持的 Hadoop 版本。下表總結了每個版本的 HBase 支持的 Hadoop 版本。未出現在此表中的舊版本被視為不受支持，可能缺少必要的功能，而新版本未經測試，但可能適用。基于 HBase 的版本，您應該選擇最合適的 Hadoop 版本。參考更多關于 Hadoop 環境配置的內容！版本無區別. 請查看 [the Hadoop wiki](https://wiki.apache.org/hadoop/Distributions%20and%20Commercial%20Support) . > 建議使用 Hadoop 2.x > > Hadoop 2.x 速度更快，包括短路讀取功能( [Leveraging local data](#perf.hdfs.configs.localread))，這將有助于提高您的 HBase 隨機讀取配置文件；Hadoop 2.x 還包括重要的 bug 修復，可以改善您的整體 HBase 體驗；HBase 不支持使用早期版本的 Hadoop 運行；有關特定于不同 HBase 版本的要求，請參見下表 > > Hadoop 3.x 仍處于早期訪問版本中，尚未被 HBase 社區對生產用例進行充分測試。使用以下的注解來解釋下面的這個表格： Hadoop 版本支持 * T = 支持 * F = 不支持 * N = 未測試 | | HBase-1.2.x, HBase-1.3.x | HBase-1.4.x | HBase-2.0.x | HBase-2.1.x | | ------------- | ------------------------ | ----------- | ----------- | ----------- | | Hadoop-2.4.x | T | F | F | F | | Hadoop-2.5.x | T | F | F | F | | Hadoop-2.6.0 | F | F | F | F | | Hadoop-2.6.1+ | T | F | T | F | | Hadoop-2.7.0 | F | F | F | F | | Hadoop-2.7.1+ | T | T| T |T | Hadoop-2.8.[0-1] |F |F | F | F | | Hadoop-2.8.2 | N | N| N | N| | Hadoop-2.8.3+ | N | N | T | T | | Hadoop-2.9.0 | F | F | F | F | | Hadoop-2.9.1+ | N |N | N |N | | Hadoop-3.0.[0-2] |F | F | F | F | | Hadoop-3.0.3+ | F | F | T | T | | Hadoop-3.1.0 | F | F | F | F | | Hadoop-3.1.1+ | F | F | T | T | > Hadoop Pre-2.6.1 和 JDK 1.8 Kerbero > > 在 Kerberos 環境中使用 pre-2.6.1 Hadoop 版本和 JDK 1.8 時，HBase 服務器可能因 Kerberos keytab relogin 錯誤而失敗并中止。JDK 1.7 (1.7. 0_80) 的后期版本也有問題[HADOOP-10786](https://issues.apache.org/jira/browse/HADOOP-10786)。在這種情況下考慮升級到 Hadoop 2.6.1+。 > Hadoop 2.6. > > 如果您計劃在 HDFS 加密區域的頂部運行 HBase，則基于 2.6.x 行的 Hadoop 發行版**必須**具有 [HADOOP-11710](https://issues.apache.org/jira/browse/HADOOP-11710) 應用。如果不這樣做，將導致群集故障和數據丟失。此修補程序存在于 Apache Hadoop 2.6.1+版本中。 > Hadoop 2.y.0 > > Hadoop 2.7.0 開始兩個版本未經測試或不受支持，因為 Hadoop PMC 明確將該版本標記為不穩定.因此，HBase 明確建議用戶避免在這些版本之上運行。另外，Hadoop PMC 也給出了同樣的警告。有關參考，請參見 [Apache Hadoop 2.7.0](https://s.apache.org/hadoop-2.7.0-announcement), [Apache Hadoop 2.8.0](https://s.apache.org/hadoop-2.8.0-announcement), [Apache Hadoop 2.8.1](https://s.apache.org/hadoop-2.8.1-announcement), and [Apache Hadoop 2.9.0](https://s.apache.org/hadoop-2.9.0-announcement). > Hadoop 3.0.x > > 包含應用程序時間服務特性的 Hadoop 集群可能會導致出現意外的 HBase 類版本.用戶要確保[YARN-7190](https://issues.apache.org/jira/browse/YARN-7190) 存在于 yarn 服務中 (目前已修復 2.9.1+ , 3.1.0+). > Hadoop 3.1.0 > > Hadoop PMC 聲稱 3.1.0 不穩定且不能用于生產.因此,HBase 建議用戶避免使用本版本.詳情: [release announcement for Hadoop 3.1.0](https://s.apache.org/hadoop-3.1.0-announcement). > 更換 Hadoop > > 因為 hbase 依賴于 hadoop，并且 hadoop jar 存在 _lib_ 目錄下。這些的 jar 僅在獨立模式下使用。在分布式模式下，集群上的 Hadoop 版本與 HBase 下的版本匹配是 _ 至關重要 _ 的。將 hbase lib 目錄中的 hadoop jar 替換為集群上運行的版本中的 hadoop jar，以避免版本不匹配問題。確保在整個集群中替換 hbase 下的 jar。Hadoop 版本不匹配問題有多種表現形式。如果 HBase 出現掛起，請檢查是否不匹配。 #### 4.1.1\. `dfs.datanode.max.transfer.threads` HDFS DataNode 在任何時候都會有一個文件數上限。在進行任何加載之前，請確保您已經配置了 Hadoop 的 _conf/hdfs-site.xml_，并將該`dfs.datanode.max.transfer.threads`值設置為至少如下的值： ``` <property> <name>dfs.datanode.max.transfer.threads</name> <value>4096</value> </property> ``` 進行上述配置后，務必重新啟動 HDFS。沒有這個配置就會造成奇怪的故障。其中一種表現是缺失區塊。例如： ``` 10/12/08 20:10:31 INFO hdfs.DFSClient: Could not obtain block blk_XXXXXXXXXXXXXXXXXXXXXX_YYYYYYYY from any node: java.io.IOException: No live nodes contain current block. Will get new block locations from namenode and retry... ``` 查看 [casestudies.max.transfer.threads](#casestudies.max.transfer.threads) 并注意 `dfs.datanode.max.xcievers` (e.g. [Hadoop HDFS: Deceived by Xciever](http://ccgtech.blogspot.com/2010/02/hadoop-hdfs-deceived-by-xciever.html)). ### 4.2\. ZooKeeper 要求 ZooKeeper 3.4.x 必需. ## 5\. HBase 運行模式：獨立式和分布式 HBase 有兩種運行模式：獨立式和分布式。HBase 以獨立模式運行。無論您的模式如何，您都需要通過編輯 HBase _conf_ 目錄中的文件來配置 HBase 。至少，您必須編輯 conf/hbase-env.sh 來告訴 HBase 要使用哪個 java。在這個文件中，你設置了 HBase 環境變量，比如`JVM`的 heapsize 和其他選項，日志文件的首選位置等等。設置 JAVA_HOME 以指向你的 java 安裝的根目錄。 ### 5.1\. Standalone HBase 默認情況下使用的是獨立式的 HBase。在[快速開始](#quickstart)一節中，我們已經介紹過獨立模式。在獨立模式下，HBase 不使用 HDFS，而是使用本地文件系統，是在同一個 JVM 中運行所有 HBase 守護進程和本地 ZooKeeper。ZooKeeper 綁定到一個眾所周知的端口，通過該端口，客戶端可以和 HBase 進行通信。 #### 5.1.1\. Standalone HBase over HDFS 有時在獨立的 hbase 上有一個有用的變體，它的所有的守護進程都在一個 JVM 中運行，而不是堅持到本地文件系統，而是堅持到一個 HDFS 實例。當您打算使用簡單的部署配置文件時，您可能會考慮使用此配置文件，加載很輕松，但是數據必須在節點的出入之間持續存在。向 HDFS 寫入數據的地方可以確保后者。要配置此獨立變體，請編 _hbase-site.xml_，設置 _hbase.rootdir_ 以指向 HDFS 實例中的某個目錄，然后將 _hbase.cluster.distributed_ 設置為 _false_。例如： ``` <configuration> <property> <name>hbase.rootdir</name> <value>hdfs://namenode.example.org:8020/hbase</value> </property> <property> <name>hbase.cluster.distributed</name> <value>false</value> </property> </configuration> ``` ### 5.2\. 分布式分布式模式可以細分為 _ 分布式 _、_ 偽分布式 _（所有守護進程都在單個節點上運行）、_ 完全分布式 _（守護進程分布在集群中的所有節點上）。其中，偽分布式模式與完全分布式的命名來自于 Hadoop。偽分布式模式可以針對本地文件系統運行，也可以針對 _Hadoop 分布式文件系統（HDFS）_ 的實例運行。完全分布式模式只能在 HDFS 上運行。有關如何設置 HDFS，請參閱 [http://www.alexjf.net/blog/distributed-systems/hadoop-yarn-installation-definitive-guide](http://www.alexjf.net/blog/distributed-systems/hadoop-yarn-installation-definitive-guide). #### 5.2.1\. 偽分布式 > 偽分布式快速開始 > > [快速開始](#quickstart) 章節包含相關信息. 偽分布式模式的 HBase 就是在單個主機上運行的完全分布式模式。使用此 HBase 配置僅進行測試和原型設計。請勿將此配置用于生產或性能評估。 ### 5.3\. 完全分布式默認情況下，HBase 以獨立模式運行，獨立模式和偽分布模式用于小規模測試。對于生產環境，建議使用分布式模式。在分布式模式下，HBase 守護進程的多個實例在集群中的多個服務器上運行。就像在偽分布式模式中一樣，完全分布式的配置要求您將`hbase.cluster.distributed` 屬性設置為 `true`。通常情況下，`hbase.rootdir`被配置為指向高可用性的 HDFS。此外，集群還配置了以多個群集節點成為 RegionServer、ZooKeeper QuorumPeers 和備份 HMaster 服務器。詳見: [quickstart-fully-distributed](#quickstart_fully_distributed). 分布式 RegionServers 通常，你的群集將包含多個運行在不同服務器上的 RegionServer，以及主要和備份 Master 和 ZooKeeper 守護程序。主服務器上的 c_conf/regionservers_ 中包含一個主機列表，其 RegionServers 與該集群相關。每個主機都在一個單獨的行上。當主服務器啟動或停止時，此文件中列出的所有主機將啟動和停止其 RegionServer 進程。 ZooKeeper and HBase 有關 HBase 的 ZooKeeper 設置說明，請參見 [ZooKeeper](#zookeeper)部分。示例 3\. 分布式 HBase 集群示例是一個分布式 HBase 集群的簡單的 _conf/hbase-site.xml_ 。用于實際工作的群集將包含更多自定義配置參數。大多數 HBase 配置指令都具有默認值，除非在 _conf/hbase-site.xml_ 中覆蓋該值，否則將使用這些默認值。有關更多信息，請參閱“配置文件” ``` <configuration> <property> <name>hbase.rootdir</name> <value>hdfs://namenode.example.org:8020/hbase</value> </property> <property> <name>hbase.cluster.distributed</name> <value>true</value> </property> <property> <name>hbase.zookeeper.quorum</name> <value>node-a.example.com,node-b.example.com,node-c.example.com</value> </property> </configuration> ``` 這是 _conf/regionservers_ 文件的示例，其中包含應在集群中運行 RegionServer 的節點的列表。這些節點需要安裝 HBase，他們需要使用與主服務器相同的 _conf/_ 目錄內容： ``` node-a.example.com node-b.example.com node-c.example.com ``` 這是 _conf/backup-masters_ 文件的示例，其中包含應運行備份主實例的每個節點的列表。除非主主站變為不可用，否則備份主站實例將處于空閑狀態。 ``` node-b.example.com node-c.example.com ``` 分布式 HBase 快速入門請參閱[quickstart-fully-distributed](#quickstart_fully_distributed)，了解包含多個 ZooKeeper、備份 HMaster 和 RegionServer 實例的簡單三節點群集配置。過程: HDFS 客戶端配置 1. 值得注意的是，如果您在 Hadoop 集群上進行了 HDFS 客戶端配置更改（例如，HDFS 客戶端的配置指令），而不是服務器端配置，則必須使用以下方法之一來啟用 HBase 以查看和使用這些配置更改： 1. 在 _hbase-env.sh_ 中添加一個指向你`HADOOP_CONF_DIR`的`HBASE_CLASSPATH`環境變量 2. 在 _${HBASE_HOME}/conf_ 下添加一個 _hdfs-site.xml_（或 _hadoop-site.xml_）或更好的符號鏈接 3. 只有一小部分 HDFS 客戶端配置，請將它們添加到 _hbase-site.xml_ 這種 HDFS 客戶端配置的一個例子是`dfs.replication`。例如，如果希望以 5 的復制因子運行，則 HBase 將創建缺省值為 3 的文件，除非您執行上述操作以使配置可用于 HBase。 ## 6\. 開始運行保證 HDFS 第一次運行，你需要通過在 HADOOP_HOME 目錄中運行 _bin/start-hdfs.sh_ 來啟動和停止 Hadoop HDFS 守護進程。你確保它正確啟動的方法是通過在 Hadoop 文件系統中測試文件的 put 和 get。HBase 通常不使用 MapReduce 或 YARN 守護進程，因此它們不需要啟動。如果您正在管理您自己的 ZooKeeper，請啟動它并確認它正在運行，否則 HBase 將啟動 ZooKeeper 作為其啟動過程的一部分。你可以從`HBASE_HOME`目錄使用以下命令來啟動 HBase： ``` bin/start-hbase.sh ``` 您現在應該有一個正在運行的 HBase 實例。HBase 日志可以在 _log_ 子目錄中找到。檢查出來，特別是如果 HBase 啟動困難。 HBase 也提供了一個 UI 列出了重要的屬性。默認情況下，它被部署在 16010 端口的主控主機上（默認情況下 HBase RegionServers 偵聽端口 16020，并在端口 16030 建立一個信息 HTTP 服務器）。如果主服務器（Master ）在默認端口上指定`master.example.org` 主機上運行，請將瀏覽器指向 http://master.example.org:16010 以查看 Web 界面。一旦 HBase 啟動，請參閱下面的 shell 部分，了解創建表，添加數據，掃描插入內容以及最終禁用和刪除表的一些操作命令。退出 HBase shell 后停止 HBase 進入： ``` $ ./bin/stop-hbase.sh stopping hbase............... ``` 關機可能需要稍等一些時間才能完成。如果您的集群由多臺計算機組成，則可能需要更長的時間。如果您正在運行分布式操作，那么在停止 Hadoop 守護進程之前，一定要等到 HBase 完全關閉。 ## 7\. 默認配置 ### 7.1\. _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 重啟集群生效。 ### 7.2\. 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 屬性（如果存在）。默認: none `hbase.regionserver.global.memstore.size.lower.limit` 強制刷新之前，區域服務器中所有存儲區的最大大小。默認為 hbase.regionserver.global.memstore.size（0.95）的 95％。當由于內存限制而導致更新被阻塞時，此值的 100％會導致最小可能的刷新。此配置中的默認值已被故意留空，以便兌現舊的 hbase.regionserver.global.memstore.lowerLimit 屬性（如果存在）。默認: none `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](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](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](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 等的重試之前，主要用作等待的值。 hbase.client.retries.number 有關如何取消此初始暫停量以及此重試數量說明。默認: `100` `hbase.client.pause.cqtbe` 是否為 CallQueueTooBigException（cqtbe）使用特殊的客戶端 pause。如果您觀察到來自同一個 RegionServer 的頻繁的 CQTBE，并且其中的調用隊列保持充滿，則將此屬性設置為比 hbase.client.pause 更高的值默認: none `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，請將此值設置為與線程數量相關的適當值，這些值將對您有所幫助。詳見:[https://issues.apache.org/jira/browse/HBASE-16388](https://issues.apache.org/jira/browse/HBASE-16388) 默認: `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.normalizer.min.region.count` 區域標準化程序最小數量默認: `3` `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.regionserver.compaction.enabled` 開啟/關閉壓縮通過設置 true/false.也可以通過 compaction_switch shell 命令默認: `true` `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。詳見: [http://hbase.apache.org/book.html#offheap.blockcache](http://hbase.apache.org/book.html#offheap.blockcache) 默認: none `hbase.bucketcache.size` EITHER 表示緩存的總堆內存大小的百分比（如果小于 1.0），則表示 BucketCache 的總容量（兆字節）。默認值：0.0 默認: none `hbase.bucketcache.bucket.sizes` 用于 bucketcache 的存儲區大小的逗號分隔列表。可以是多種尺寸。列出從最小到最大的塊大小。您使用的大小取決于您的數據訪問模式。必須是 256 的倍數，否則當你從緩存中讀取時，你會遇到“java.io.IOException：Invalid HFile block magic”。如果您在此處未指定任何值，那么您可以選取代碼中設置的默認 bucketsizes。默認: none `hfile.format.version` 用于新文件的 HFile 格式版本。版本 3 添加了對 hfiles 中標簽的支持（請參閱 [http://hbase.apache.org/book.html#hbase.tags](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 套接字連接上設置沒有延遲。詳見: [http://docs.oracle.com/javase/1.5.0/docs/api/java/net/Socket.html#getTcpNoDelay(](http://docs.oracle.com/javase/1.5.0/docs/api/java/net/Socket.html#getTcpNoDelay()) 默認: `true` `hbase.regionserver.hostname` 這個配置適用于對 HBase 很熟悉的人：除非你真的知道你在做什么，否則不要設定它的價值。當設置為非空值時，這表示底層服務器的（面向外部）主機名。詳見: [https://issues.apache.org/jira/browse/HBASE-12954](https://issues.apache.org/jira/browse/HBASE-12954) 默認: none `hbase.regionserver.hostname.disable.master.reversedns` 這個配置適用于對 HBase 很熟練的人：除非你真的知道你在做什么，否則不要設定它的價值。當設置為 true 時，regionserver 將使用當前節點主機名作為服務器名稱，HMaster 將跳過反向 DNS 查找并使用 regionserver 發送的主機名。請注意，此配置和 hbase.regionserver.hostname 是互斥的。詳見: [https://issues.apache.org/jira/browse/HBASE-18226](https://issues.apache.org/jira/browse/HBASE-18226) 默認: `false` `hbase.master.keytab.file` 用于登錄配置的 HMaster 服務器主體的 kerberos 密鑰表文件的完整路徑。默認: none `hbase.master.kerberos.principal` Ex. "hbase/_HOST@EXAMPLE.COM"應該用來運行 HMaster 進程的 Kerberos 主體名稱。主體名稱的格式應為：user/hostname @ DOMAIN。如果使用“_HOST”作為主機名部分，它將被替換為正在運行的實例的實際主機名。默認: none `hbase.regionserver.keytab.file` 用于登錄配置的 HRegionServer 服務器主體的 kerberos 密鑰表文件的完整路徑。默認: none `hbase.regionserver.kerberos.principal` Ex. "hbase/_HOST@EXAMPLE.COM"應該用來運行 HRegionServer 進程的 kerberos 主體名稱。主體名稱的格式應為：user/hostname @ DOMAIN。如果使用“_HOST”作為主機名部分，它將被替換為正在運行的實例的實際主機名。此主體的條目必須存在于 hbase.regionserver.keytab.file 中指定的文件中默認: none `hadoop.policy.file` RPC 服務器使用策略配置文件對客戶端請求進行授權決策。僅在啟用 HBase 安全性時使用。默認: `hbase-policy.xml` `hbase.superuser` 用戶或組列表（以逗號分隔），允許在整個集群中擁有完全權限（不管存儲的 ACL）。僅在啟用 HBase 安全性時使用。默認: none `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 來按需加載。默認: none `hbase.coprocessor.master.classes` 在活動的 HMaster 進程中默認加載的 org.apache.hadoop.hbase.coprocessor.MasterObserver 協處理器的逗號分隔列表。對于任何實施的協處理器方法，列出的類將按順序調用。在實現你自己的 MasterObserver 之后，把它放在 HBase 的類路徑中，并在這里添加完全限定的類名稱。默認: none `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.snapshot.working.dir` 快照過程將發生的位置。已完成快照的位置不會更改，但快照進程發生的臨時目錄將設置為此位置。為了提高性能，它可以是一個獨立的文件系統，而不是根目錄。有關詳細信息，請參閱 HBase-21098 默認: none `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。詳見:HBASE-8389 默認: `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-1936 默認: `${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 ）。詳見: [http://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/master/balancer/StochasticLoadBalancer.html](http://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/master/balancer/StochasticLoadBalancer.html) 默認: `org.apache.hadoop.hbase.master.balancer.StochasticLoadBalancer` `hbase.master.loadbalance.bytable` 平衡器運行時的因子表名稱。默認：false。默認: `false` `hbase.master.normalizer.class` 用于執行期間發生時的區域標準化的類。詳見: [http://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/master/normalizer/SimpleRegionNormalizer.html](http://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/master/normalizer/SimpleRegionNormalizer.html) 默認: `org.apache.hadoop.hbase.master.normalizer.SimpleRegionNormalizer` `hbase.rest.csrf.enabled` 設置為 true 以啟用跨站請求偽造的保護。默認: `false` `hbase.rest-csrf.browser-useragents-regex` 通過將 hbase.rest.csrf.enabled 設置為 true 來啟用為 REST 服務器，針對跨站點請求偽造（CSRF）的防護時，用于匹配 HTTP 請求的 User-Agent 標頭的正則表達式的逗號分隔列表。如果傳入的用戶代理與這些正則表達式中的任何一個相匹配，則認為該請求被瀏覽器發送，因此 CSRF 預防被強制執行。如果請求的用戶代理與這些正則表達式中的任何一個都不匹配，則該請求被認為是由除瀏覽器以外的其他東西發送的，例如腳本自動化。在這種情況下，CSRF 不是一個潛在的攻擊向量，所以預防沒有被執行。這有助于實現與尚未更新以發送 CSRF 預防報頭的現有自動化的向后兼容性。默認: `<sup>Mozilla.**,**</sup>**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 的類路徑中，并在這里添加完全限定的類名稱。默認: none `hbase.procedure.master.classes` 在活動 HMaster 進程中默認加載的 org.apache.hadoop.hbase.procedure.MasterProcedureManager 過程管理器的逗號分隔列表。程序通過其簽名進行標識，用戶可以使用簽名和即時名稱來觸發全局程序的執行。在實現你自己的 MasterProcedureManager 之后，把它放在 HBase 的類路徑中，并在這里添加完全限定的類名稱。默認: none `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.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` ### 7.3\. _hbase-env.sh_ hbase-env.sh 文件用來設置 HBase 環境變量。比如包括在啟動 HBase 守護程序（如堆大小和垃圾回收器配置）時傳遞 JVM 的選項。您還可以設置 HBase 配置、日志目錄、niceness、ssh 選項，定位進程 pid 文件的位置等的配置。打開 _conf/hbase-env.sh_ 文件并仔細閱讀其內容。每個選項都有相當好的記錄。如果希望在啟動時由 HBase 守護進程讀取，請在此處添加您自己的環境變量。此處的更改將需要重啟 HBase 才能注意到更改。 ### 7.4\. _log4j.properties_ 編輯此文件以更改 HBase 文件的滾動速度，并更改 HBase 記錄消息的級別。此處的更改將需要重新啟動集群以注意到更改，盡管可以通過 HBase UI 為特定的守護程序更改日志級別。 ### 7.5\. 客戶端配置和依賴關系連接到 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 模塊： ``` <dependency> <groupId>org.apache.hbase</groupId> <artifactId>hbase-shaded-client</artifactId> <version>2.0.0</version> </dependency> ``` 一個基本的客戶端的 _hbase-site.xml_ 的使用示例可能如下所示： ``` <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="configuration.xsl"?> <configuration> <property> <name>hbase.zookeeper.quorum</name> <value>example1,example2,example3</value> <description>The directory shared by region servers. </description> </property> </configuration> ``` #### 7.5.1\. Java 客戶端配置 ava 客戶端使用的配置保存在[HBaseConfiguration](https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/HBaseConfiguration)實例中。 HBaseConfiguration 的工廠方法，`HBaseConfiguration.create();`;，在調用時會讀取客戶端上的第一個 _hbase-site.xml_ 的內容（`CLASSPATH`如果存在的話）（調用也將包含在任何發現的 _hbase-default.xml_ 中；_hbase-default.xml_ 在 _hbase.X.X.X.jar_ 里面）。也可以直接指定配置，而無需從 _hbase-site.xml_ 中讀取數據。例如，要以編程方式設置集群的 ZooKeeper 集成，請執行以下操作： ``` Configuration config = HBaseConfiguration.create(); config.set("hbase.zookeeper.quorum", "localhost"); // Here we are running zookeeper locally ``` 如果多個 ZooKeeper 實例組成 ZooKeeper 集合，則可以在逗號分隔列表中指定它們（就像在 _hbase-site.xml_ 文件中一樣）。這個填充的`Configuration`實例然后可以傳遞給一個[表](https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Table.html)，依此類推。 ### 7.6\. 超時配置 HBase 提供了各種各樣的超時設置來限制各種遠程操作的執行時間。 * hbase.rpc.timeout * hbase.rpc.read.timeout * hbase.rpc.write.timeout * hbase.client.operation.timeout * hbase.client.meta.operation.timeout * hbase.client.scanner.timeout.period `hbase.rpc.timeout`屬性限制單個 rpc 調用在超時之前可以運行的時間。要微調讀或寫相關的 RPC 超時，請設置`hbase.rpc.read.timeout`和`hbase.rpc.write.timeout`配置屬性。如果沒有這些屬性，將使用`hbase.rpc.timeout`。更高級別的超時為`hbase.client.operation.timeout`，對每個客戶端調用都有效。例如，當由于`hbase.rpc.timeout`而導致 rpc 調用失敗時，將重試該調用，直到達到`hbase.client.operation.timeout`。可以通過設置`hbase.client.meta.operation.timeout`配置值來微調系統表的客戶端操作超時。如果不設置，則其值將使用`hbase.client.operation.timeout`。掃描操作的超時控制方式不同。使用`hbase.client.scanner.timeout.period`屬性設置此超時。 ## 8\. HBase 配置示例 ### 8.1\. 基本分布式 HBase 安裝在下文內容中是一個分布式 10 節點的群集的基本配置示例：其中，節點被命名為 example0，example1...一直到 example9，在這個例子中；HBase Master 和 HDFS NameNode 正在節點 example0 上運行；RegionServers 在節點 example1- example9 上運行；一個 3 節點 ZooKeeper 集合運行在 example1、example2，以及 example3 的默認端口上；ZooKeeper 的數據被保存到：_/export/zookeeper_r。下面我們顯示在 HBase conf 目錄中找到的主要配置文件 _hbase-site.xml_, _regionservers_, and _hbase-env.sh_。 #### 8.1.1\. _hbase-site.xml_ ``` <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="configuration.xsl"?> <configuration> <property> <name>hbase.zookeeper.quorum</name> <value>example1,example2,example3</value> <description>The directory shared by RegionServers. </description> </property> <property> <name>hbase.zookeeper.property.dataDir</name> <value>/export/zookeeper</value> <description>Property from ZooKeeper config zoo.cfg. The directory where the snapshot is stored. </description> </property> <property> <name>hbase.rootdir</name> <value>hdfs://example0:8020/hbase</value> <description>The directory shared by RegionServers. </description> </property> <property> <name>hbase.cluster.distributed</name> <value>true</value> <description>The mode the cluster will be in. Possible values are false: standalone and pseudo-distributed setups with managed ZooKeeper true: fully-distributed with unmanaged ZooKeeper Quorum (see hbase-env.sh) </description> </property> </configuration> ``` #### 8.1.2\. _regionservers_ 在此文件中列出將運行 RegionServers 的節點。在我們的例子中，這些節點是 example1- example9。 ``` example1 example2 example3 example4 example5 example6 example7 example8 example9 ``` #### 8.1.3\. _hbase-env.sh_ _hbase-env.sh_ 文件中的以下行顯示了如何設置`JAVA_HOME`環境變量（HBase 需要的）并將堆設置為 4 GB（而不是默認值 1 GB）。如果您復制并粘貼此示例，請務必調整`JAVA_HOME`以適合您的環境。 ``` # The java implementation to use. export JAVA_HOME=/usr/java/jdk1.8.0/ # The maximum amount of heap to use. Default is left to JVM default. export HBASE_HEAPSIZE=4G ``` 使用 rsync 將 _conf_ 目錄的內容復制到群集的所有節點。 ## 9\. HBase 重要配置下面我們列出一些 _ 重要 _ 的配置。我們已經將這部分分為必需的配置和值得推薦的配置。 ### 9.1\. 所需的配置請你參考本教程中 HBase 基礎條件中的操作系統和 Hadoop 部分的內容！ #### 9.1.1\. 大型群集配置如果您擁有一個包含大量區域的群集，那么在主服務器啟動后，Regionserver 可能會暫時地進行檢查，而所有剩余的 RegionServers 落后。要簽入的第一臺服務器將被分配到所有不是最優的區域。為防止出現上述情況，請將其`hbase.master.wait.on.regionservers.mintostart`屬性從其默認值 1 中調高。詳見: [HBASE-6389 Modify the conditions to ensure that Master waits for sufficient number of Region Servers before starting region assignments](https://issues.apache.org/jira/browse/HBASE-6389) ### 9.2\. 推薦的配置 #### 9.2.1\. ZooKeeper 配置 ##### `zookeeper.session.timeout` 默認的超時時間是三分鐘（以毫秒為單位）。這意味著，如果服務器崩潰，則在主服務器在三分鐘前發現崩潰并開始恢復。您可能需要將超時調整到一分鐘甚至更短的時間，以便主服務器盡快通知故障。在更改此值之前，請確保您的 JVM 垃圾收集配置處于受控狀態，否則，長時間的垃圾回收會超出 ZooKeeper 會話超時時間，將取出您的 RegionServer。（如果一個 RegionServer 長時間處于 GC 狀態，你可能需要在服務器上啟動恢復）。要更改此配置，請編輯 _hbase-site.xml_，將更改的文件復制到群集中并重新啟動。我們將這個值設置得很高，以避免不必要的麻煩。如果出現類似“為什么我在執行一個大規模數據導入的時候 Region Server 死掉啦”這樣的問題，可以解釋的原因是：他們的 JVM 未被解析，并且正在運行長時間的 GC 操作。 ##### ZooKeeper 數量詳見 [zookeeper](#zookeeper). #### 9.2.2\. HDFS 配置 ##### `dfs.datanode.failed.volumes.tolerated` 這是“DataNode 停止提供服務之前允許失敗的卷數。默認情況下，任何卷失敗都會導致 datanode 關閉”_ 從 HDFS-default.xml_ 中的描述。您可能希望將其設置為可用磁盤數量的一半左右。 ##### `hbase.regionserver.handler.count` 此設置定義了為應答傳入的用戶表請求而保持打開的線程數。經驗法則是，當每個請求的有效載荷接近 MB（大容量、掃描使用大緩存）時保持低數字，并且當有效負載小（獲取，小投入，ICV，刪除）時保持此數字為高。正在進行的查詢的總大小受設置 `hbase.ipc.server.max.callqueue.size`的限制。如果這個數字的有效載荷很小，那么將這個數字設置為最大傳入客戶端數量是安全的，典型的例子是一個服務于網站的集群，因為 put 通常不被緩沖，大部分操作都是獲取的。保持此設置的高風險的原因是，當前在區域服務器中發生的所有投入的總大小可能對其內存造成太大的壓力，甚至會觸發 OutOfMemoryError。在低內存上運行的 RegionServer 將觸發其 JVM 的垃圾收集器，以更頻繁的方式運行，直到 GC 暫停變得明顯（原因是用于保留所有請求的有效載荷的所有內存不能被丟棄，即便垃圾收集器正在進行嘗試）。一段時間之后，整個群集吞吐量都會受到影響，因為每個碰到該 RegionServer 的請求都將花費更長的時間，這更加劇了問題的嚴重性。您可以通過[rpc.logging](#rpc.logging)查看某個 RegionServer 上是否有太多或太多的處理程序，然后跟蹤其日志（排隊請求消耗內存）。 #### 9.2.3\. 大型內存機器的配置 HBase 提供了一個合理的，保守的配置，可以在幾乎所有人們可能想要測試的機器類型上運行。如果你有更大的機器 - HBase 有 8G 或更大的堆 - 你可能會發現下面的配置選項很有幫助。 #### 9.2.4\. 壓縮您應該考慮啟用 ColumnFamily 壓縮。有幾個選項可以在大多數情況下都是通過減小 StoreFiles 的大小來提高性能，從而減少 I / O。詳見 [compression](#compression) #### 9.2.5\. 配置 WAL 文件的大小和數量在發生 RS 故障的情況下，HBase 使用 wal 恢復尚未刷新到磁盤的 memstore 數據。這些 WAL 文件應該配置為略小于 HDFS 塊（默認情況下，HDFS 塊為 64Mb，WAL 文件為?60Mb）。 HBase 也對 WAL 文件的數量有限制，旨在確保在恢復過程中不會有太多的數據需要重放。這個限制需要根據 memstore 配置進行設置，以便所有必要的數據都可以適用。建議分配足夠多的 WAL 文件來存儲至少那么多的數據（當所有的存儲都接近完整時）。例如，對于 16Gb RS 堆，默認的 memstore 設置（0.4）和默認的 WAL 文件大小（?60Mb），16Gb * 0.4 / 60，WAL 文件數的起點為?109。但是，由于所有的 memstores 不會一直占滿，所以可以分配更少的 WAL 文件。 #### 9.2.6\. 管理分割 HBase 通常會根據您的 _hbase-default.xml_ 和 _hbase-site.xml_ 配置文件中的設置來處理您所在區域的分割。重要的設置包括：`hbase.regionserver.region.split.policy`, `hbase.hregion.max.filesize`, `hbase.regionserver.regionSplitLimit`。分割的一個簡單的觀點是，當一個區域發展到 hbase.hregion.max.filesize 時，它被分割。對于大多數使用模式，您應該使用自動分割。詳見: [manual region splitting decisions](#manual_region_splitting_decisions) for more information about manual region splitting. 不要讓 HBase 自動分割你的區域，你可以選擇自己管理分割。HBase 0.90.0 增加了這個功能。如果你知道你的密鑰空間，手動管理分割就行，否則讓 HBase 為你分割。手動分割可以減輕在負載下的區域創建和移動。這也使得區域邊界是已知的和不變的（如果你禁用區域分割）。如果使用手動分割，則可以更輕松地進行交錯式的基于時間的主要壓縮來分散網絡 IO 負載。禁用自動分割要禁用自動拆分，可以在集群配置或表配置中設置區域拆分策略： `org.apache.hadoop.hbase.regionserver.DisabledRegionSplitPolicy` > 自動分割建議 > > 如果禁用自動分割來診斷問題或在數據快速增長期間，建議在您的情況變得更加穩定時重新啟用它們。確定預分割區域的最佳數目預分割區域的最佳數量取決于您的應用程序和環境。一個好的經驗法則是從每個服務器的 10 個預分割區域開始，隨著時間的推移數據不斷增長。盡量在區域太少的地方犯錯，稍后進行滾動分割更好。區域的最佳數量取決于您所在區域中最大的 StoreFile。如果數據量增加，最大的 StoreFile 的大小將隨著時間增加。目標是使最大的區域足夠大，壓實選擇算法僅在定時的主要壓實期間將其壓縮。否則，該集群可能會同時出現大量壓實區域的壓實風暴。數據增長導致壓縮風暴，而不是人工分割決策，這一點很重要。如果區域被分割成太多的區域，可以通過配置`HConstants.MAJOR_COMPACTION_PERIOD 來增加主要的壓縮間隔。`org.apache.hadoop.hbase.util.RegionSplitter`提供所有區域的網絡 IO 安全滾動分割。 #### 9.2.7\. 管理壓縮默認情況下，主要的壓縮計劃在 7 天內運行一次。如果您需要精確控制主要壓縮的運行時間和頻率，可以禁用托管的主要壓縮。請參閱 `hbase.hregion.majorcompaction` [compaction.parameters](#compaction.parameters) > 不禁用主要壓縮 > > 對于 StoreFile 清理來說，重要的壓縮是絕對必要的。不要完全禁用它們。您可以通過 HBase shell 或[Admin API](https://hbase.apache.org/apidocs/org/apache/hadoop/hbase/client/Admin.html#majorCompact-org.apache.hadoop.hbase.TableName-)手動運行主要壓縮。詳見: [compaction](#compaction) #### 9.2.8\. 預測執行預測執行 MapReduce 任務是默認開啟的，對于 HBase 集群，通常建議關閉系統級的推測執行，除非您需要在特定情況下可以配置每個作業。將屬性 `mapreduce.map.speculative` 和 `mapreduce.reduce.speculative` 設置為 false。 ### 9.3\. 其他配置 #### 9.3.1\. 平衡器平衡器（Balancer）是在主服務器上運行的一個周期性操作，用于重新分配集群上的區域。它通過`hbase.balancer.period`配置，默認為 300000（5 分鐘）。詳見: [master.processes.loadbalancer](#master.processes.loadbalancer) #### 9.3.2\. 禁用 Blockcache 不要關閉塊緩存（你可以通過設置`hfile.block.cache.size`為零來實現）。這樣做沒有好處，因為 RegionServer 將花費所有的時間一次又一次地加載 HFile 索引。如果你的工作集是這樣配置塊緩存，那么沒有益處，最少應保證 hfile 指數保存在塊緩存內的大小（你可以通過調查 RegionServer UI 粗略地了解你需要的大小；請參閱占網頁頂部附近的索引塊大小） #### 9.3.3\. [Nagle’s](http://en.wikipedia.org/wiki/Nagle’s_algorithm) 或小 package 問題如果在對 HBase 的操作中出現大約 40ms 左右的延遲，請嘗試 Nagles 的設置。例如，請參閱用戶郵件列表線程[Inconsistent scan performance with caching set to 1](http://search-hadoop.com/m/pduLg2fydtE/Inconsistent+scan+performance+with+caching+set+&subj=Re+Inconsistent+scan+performance+with+caching+set+to+1) 將緩存設置為 1 的不一致掃描性能以及其中所引用的設置`notcpdelay`來提高掃描速度的問題。詳見文檔底部圖表[HBASE-7008 Set scanner caching to a better default](https://issues.apache.org/jira/browse/HBASE-7008) 設置了掃描緩存到一個更好的默認位置，我們的 Lars Hofhansl 會嘗試使用 Nagle 打開和關閉測量效果的各種數據大小。 #### 9.3.4\. 更好的平均恢復時間這部分是關于在服務器出現故障后會使服務器恢復更快的配置。詳見:[Introduction to HBase Mean Time to Recover (MTTR)](http://hortonworks.com/blog/introduction-to-hbase-mean-time-to-recover-mttr/) [HBASE-8354 forces Namenode into loop with lease recovery requests](https://issues.apache.org/jira/browse/HBASE-8389) 使用 lease 恢復請求循環的問題是混亂的，但在低超時以及如何引起更快的恢復，包括引用添加到 HDFS 的修復程序方面，有很多好的討論。下面建議的配置是 Varun 的建議的提煉和測試，確保你在 HDFS 版本上運行，所以你有他所提到的修補程序，并且他自己添加到 HDFS，幫助 HBase MTTR（例如 HDFS-3703，HDFS-3712 和 HDFS-4791 -Hadoop 2 確保有他們并且后期 Hadoop 1 有一些）。在 RegionServer 中設置以下內容： ``` <property> <name>hbase.lease.recovery.dfs.timeout</name> <value>23000</value> <description>How much time we allow elapse between calls to recover lease. Should be larger than the dfs timeout.</description> </property> <property> <name>dfs.client.socket-timeout</name> <value>10000</value> <description>Down the DFS timeout from 60 to 10 seconds.</description> </property> ``` 在 NameNode/DataNode 端，設置以下內容來啟用 HDFS-3703，HDFS-3912 中引入的`staleness`： ``` <property> <name>dfs.client.socket-timeout</name> <value>10000</value> <description>Down the DFS timeout from 60 to 10 seconds.</description> </property> <property> <name>dfs.datanode.socket.write.timeout</name> <value>10000</value> <description>Down the DFS timeout from 8 * 60 to 10 seconds.</description> </property> <property> <name>ipc.client.connect.timeout</name> <value>3000</value> <description>Down from 60 seconds to 3.</description> </property> <property> <name>ipc.client.connect.max.retries.on.timeouts</name> <value>2</value> <description>Down from 45 seconds to 3 (2 == 3 retries).</description> </property> <property> <name>dfs.namenode.avoid.read.stale.datanode</name> <value>true</value> <description>Enable stale state in hdfs</description> </property> <property> <name>dfs.namenode.stale.datanode.interval</name> <value>20000</value> <description>Down from default 30 seconds</description> </property> <property> <name>dfs.namenode.avoid.write.stale.datanode</name> <value>true</value> <description>Enable stale state in hdfs</description> </property> ``` #### 9.3.5\. JMX JMX（Java Management Extensions，Java 管理擴展）提供了內置的工具，使您能夠監視和管理 Java VM。要啟用遠程系統的監視和管理，在啟動 Java VM 時，您需要設置系統屬性`com.sun.management.jmxremote.port`（要啟用 JMX RMI 連接的端口號）。詳見:[official documentation](http://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html). 從歷史上看，除了上面提到的端口之外，JMX 還會打開兩個附加的隨機 TCP 偵聽端口，這可能會導致端口沖突問題。詳見: [HBASE-10289](https://issues.apache.org/jira/browse/HBASE-10289) 作為一種替代方法，您可以使用 HBase 提供的基于協處理器的 JMX 實現。啟用它，請在`hbase-site.xml`中添加以下屬性：: ``` <property> <name>hbase.coprocessor.regionserver.classes</name> <value>org.apache.hadoop.hbase.JMXListener</value> </property> ``` > 不要同時為 Java VM 設置 `com.sun.management.jmxremote.port` 目前它支持 Master 和 RegionServer Java VM。默認情況下，JMX 偵聽 TCP 端口 10102，您可以使用以下屬性進一步配置端口： ``` <property> <name>regionserver.rmi.registry.port</name> <value>61130</value> </property> <property> <name>regionserver.rmi.connector.port</name> <value>61140</value> </property> ``` 在大多數情況下，注冊表端口可以與連接器端口共享，所以只需要配置 regionserver.rmi.registry.port。但是，如果要使用 SSL 通信，則必須將 2 個端口配置為不同的值。默認情況下，密碼認證和 SSL 通信被禁用。要啟用密碼驗證，您需要像下面那樣更新 _hbase-env.sh_： ``` export HBASE_JMX_BASE="-Dcom.sun.management.jmxremote.authenticate=true \ -Dcom.sun.management.jmxremote.password.file=your_password_file \ -Dcom.sun.management.jmxremote.access.file=your_access_file" export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE " export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE " ``` 請參閱 _$JRE_HOME/lib/management_ 下面的示例 password/access 文件。要使用密碼驗證啟用 SSL 通信，請按照以下步驟操作： ``` #1\. generate a key pair, stored in myKeyStore keytool -genkey -alias jconsole -keystore myKeyStore #2\. export it to file jconsole.cert keytool -export -alias jconsole -keystore myKeyStore -file jconsole.cert #3\. copy jconsole.cert to jconsole client machine, import it to jconsoleKeyStore keytool -import -alias jconsole -keystore jconsoleKeyStore -file jconsole.cert ``` 更新 _hbase-env.sh_ : ``` export HBASE_JMX_BASE="-Dcom.sun.management.jmxremote.ssl=true \ -Djavax.net.ssl.keyStore=/home/tianq/myKeyStore \ -Djavax.net.ssl.keyStorePassword=your_password_in_step_1 \ -Dcom.sun.management.jmxremote.authenticate=true \ -Dcom.sun.management.jmxremote.password.file=your_password file \ -Dcom.sun.management.jmxremote.access.file=your_access_file" export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS $HBASE_JMX_BASE " export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS $HBASE_JMX_BASE " ``` 最后，使用密鑰存儲在客戶端上啟動 `jconsole` ``` jconsole -J-Djavax.net.ssl.trustStore=/home/tianq/jconsoleKeyStore ``` > To 要在主服務器上啟用 HBase JMX 實現，還需要在 > _hbase-site.xml_ 中添加以下屬性： ``` <property> <name>hbase.coprocessor.master.classes</name> <value>org.apache.hadoop.hbase.JMXListener</value> </property> ``` 端口配置的相應屬性為：`master.rmi.registry.port`（默認為 10101）和`master.rmi.connector.port`（默認情況下與 registry.port 相同）。 ## 10\. 動態配置你可以在不重新啟動服務器的情況下更改配置的子集。在 HBase shell 中，有新的操作符，`update_config` 以及 `update_all_config`，它們會提示服務器或所有服務器重新加載配置。當前正在運行的服務器中，只能更改所有配置的子集。以下是這些支持動態更改的配置： | Key | | ------------------------------------------------------------ | | hbase.ipc.server.fallback-to-simple-auth-allowed | | hbase.cleaner.scan.dir.concurrent.size | | hbase.regionserver.thread.compaction.large | | hbase.regionserver.thread.compaction.small | | hbase.regionserver.thread.split | | hbase.regionserver.throughput.controller | | hbase.regionserver.thread.hfilecleaner.throttle | | hbase.regionserver.hfilecleaner.large.queue.size | | hbase.regionserver.hfilecleaner.small.queue.size | | hbase.regionserver.hfilecleaner.large.thread.count | | hbase.regionserver.hfilecleaner.small.thread.count | | hbase.regionserver.hfilecleaner.thread.timeout.msec | | hbase.regionserver.hfilecleaner.thread.check.interval.msec | | hbase.regionserver.flush.throughput.controller | | hbase.hstore.compaction.max.size | | hbase.hstore.compaction.max.size.offpeak | | hbase.hstore.compaction.min.size | | hbase.hstore.compaction.min | | hbase.hstore.compaction.max | | hbase.hstore.compaction.ratio | | hbase.hstore.compaction.ratio.offpeak | | hbase.regionserver.thread.compaction.throttle | | hbase.hregion.majorcompaction | | hbase.hregion.majorcompaction.jitter | | hbase.hstore.min.locality.to.skip.major.compact | | hbase.hstore.compaction.date.tiered.max.storefile.age.millis | | hbase.hstore.compaction.date.tiered.incoming.window.min | | hbase.hstore.compaction.date.tiered.window.policy.class | | hbase.hstore.compaction.date.tiered.single.output.for.minor.compaction | | hbase.hstore.compaction.date.tiered.window.factory.class | | hbase.offpeak.start.hour | | hbase.offpeak.end.hour | | hbase.oldwals.cleaner.thread.size | | hbase.oldwals.cleaner.thread.timeout.msec | | hbase.oldwals.cleaner.thread.check.interval.msec | | hbase.procedure.worker.keep.alive.time.msec | | hbase.procedure.worker.add.stuck.percentage | | hbase.procedure.worker.monitor.interval.msec | | hbase.procedure.worker.stuck.threshold.msec | | hbase.regions.slop | | hbase.regions.overallSlop | | hbase.balancer.tablesOnMaster | | hbase.balancer.tablesOnMaster.systemTablesOnly | | hbase.util.ip.to.rack.determiner | | hbase.ipc.server.max.callqueue.length | | hbase.ipc.server.priority.max.callqueue.length | | hbase.ipc.server.callqueue.type | | hbase.ipc.server.callqueue.codel.target.delay | | hbase.ipc.server.callqueue.codel.interval | | hbase.ipc.server.callqueue.codel.lifo.threshold | | hbase.master.balancer.stochastic.maxSteps | | hbase.master.balancer.stochastic.stepsPerRegion | | hbase.master.balancer.stochastic.maxRunningTime | | hbase.master.balancer.stochastic.runMaxSteps | | hbase.master.balancer.stochastic.numRegionLoadsToRemember | | hbase.master.loadbalance.bytable | | hbase.master.balancer.stochastic.minCostNeedBalance | | hbase.master.balancer.stochastic.localityCost | | hbase.master.balancer.stochastic.rackLocalityCost | | hbase.master.balancer.stochastic.readRequestCost | | hbase.master.balancer.stochastic.writeRequestCost | | hbase.master.balancer.stochastic.memstoreSizeCost | | hbase.master.balancer.stochastic.storefileSizeCost | | hbase.master.balancer.stochastic.regionReplicaHostCostKey | | hbase.master.balancer.stochastic.regionReplicaRackCostKey | | hbase.master.balancer.stochastic.regionCountCost | | hbase.master.balancer.stochastic.primaryRegionCountCost | | hbase.master.balancer.stochastic.moveCost | | hbase.master.balancer.stochastic.maxMovePercent | | hbase.master.balancer.stochastic.tableSkewCost |