在本文中，我們列出了使用HBase時所需要的服務和一些必需的系統配置。
安裝Java
Java是Hadoop和HBase主要先決條件。首先應該使用"java -verion"檢查java是否存在在您的系統上。 java -version 命令的語法如下。
如果一切正常，它會得到下面的輸出。
如果Java還沒有安裝在系統中，請你安裝Java！
HBase版本與JDK
在下表中你可以看到HBase版本與其對應支持的JDK版本：
注意：HBase不會使用Java 6構建或編譯，並且，您必須在群集的每個節點上設置JAVA_HOME，hbase-env.sh 提供了一個方便的機制來做到這一點。
操作系統
SSH
（必須的）HBase廣泛使用安全Shell（ssh）命令和實用程序在集群節點之間進行通信。集群中的每臺服務器都必須運行ssh，以便可以管理Hadoop和HBase後臺進程。您必須能夠使用共享密鑰而不是密碼，通過SSH（包括本地節點）從主服務器和任何備份主服務器連接到所有節點。您可以在Linux或Unix系統中的“Procedure：Configure Passwordless SSH Access ”（配置無密碼SSH訪問）中看到這種設置的基本方法。如果群集節點使用OS X，請參閱Hadoop wiki上的，SSH：設置遠程桌面和啟用自登錄。
DNS
HBase使用本地主機名來自行報告其IP地址。正向和反向DNS解析必須在0.92.0之前的HBase版本中工作。hadoop-dns-checker 工具，可以用來驗證DNS在集群上是否正常工作。項目README文件提供了有關使用的詳細說明。
Loopback IP
在hbase-0.96.0之前，HBase只使用IP地址127.0.0.1來引用localhost，而這是不可配置的。有關更多詳細信息，請參閱Loopback IP。
NTP
群集節點上的時鐘應該同步。少量的變化是可以接受的，但是大量的不同會導致不穩定和意外的行為。如果在群集中看到無法解釋的問題，則時間同步是首先要檢查的事項之一。建議您在群集上運行網絡時間協議（NTP）服務或其他時間同步機制，並且所有節點都查找相同的服務以進行時間同步。請參閱Linux文檔項目（TLDP）中的基本NTP配置以設置NTP。
文件和進程數限制（ulimit）
Apache HBase是一個數據庫。它需要能夠一次打開大量的文件。許多Linux發行版限制了允許單個用戶打開的文件數量1024（或者256，在舊版本的OS X上）。當以運行 HBase 的用戶身份登錄時，您可以通過在服務器上運行ulimit -n命令來檢查服務器上的限制。您也可能會注意到以下錯誤：
建議將ulimit提高到至少10,000，但更可能是10,240，因為該值通常以1024的倍數表示。每個ColumnFamily至少有一個StoreFile，如果該區域處於加載狀態，則可能有多於六個的StoreFile。所需的打開文件的數量取決於ColumnFamilies的數量和區域的數量。以下是計算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日誌的第一行。
示例：ulimit在Ubuntu上的設置
要在Ubuntu上配置ulimit設置，請編輯：/etc/security/limits.conf，它是一個由四列組成的空格分隔的文件。在以下示例中，第一行將用戶名為hadoop的操作系統用戶的打開文件數（nofile）的軟限制和硬限制設置為32768。第二行將同一用戶的進程數設置為32000。
這些設置僅適用於可插入身份驗證模塊（PAM）環境指示使用它們的情況。要配置PAM以使用這些限制，請確保/etc/pam.d/common-session文件包含以下行：
Linux Shell
所有HBase附帶的shell腳本都依賴於 GNU Bash shell。
Windows
在HBase 0.96之前，在Microsoft Windows上運行HBase僅限於測試目的。不建議在Windows計算機上運行生產系統。
Hadoop
下表總結了每個HBase版本支持的Hadoop版本。基於HBase的版本，您應該選擇最合適的Hadoop版本。
建議使用 Hadoop 2.x：Hadoop 2.x 速度更快，包括短路讀取功能，這將有助於提高您的 HBase 隨機讀取配置文件；Hadoop 2.x 還包括重要的 bug 修復，可以改善您的整體 HBase 體驗；HBase 不支持使用早期版本的 Hadoop 運行；有關特定於不同 HBase 版本的要求，請參見下表；Hadoop 3.x 仍處於早期訪問版本中，尚未被 HBase 社區對生產用例進行充分測試。
使用以下的註解來解釋下面的這個表格：
Hadoop版本支持矩陣：
- “S”=支持
- “X”=不支持
- “NT”=未測試
Hadoop Pre-2.6.1 和 JDK 1.8 Kerberos
在 Kerberos 環境中使用 pre-2.6.1 Hadoop 版本和 JDK 1.8 時，HBase 服務器可能因 Kerberos keytab relogin 錯誤而失敗並中止。JDK 1.7 (1.7. 0_80) 的後期版本也有問題。在這種情況下考慮升級到Hadoop 2.6.1+。
Hadoop 2.6.x
如果您計劃在 HDFS 加密區域的頂部運行 HBase，則基於 2.6.x 行的 Hadoop 發行版必須具有 HADOOP-11710 應用。如果不這樣做，將導致群集故障和數據丟失。此修補程序存在於Apache Hadoop 2.6.1+版本中。
Hadoop 2.7.x
Hadoop 2.7.0版本未經測試或不受支持，因為Hadoop PMC明確將該版本標記為不穩定。
Hadoop 2.8.x
Hadoop 2.8.0和2.8.1版本未經測試或不受支持，因為Hadoop PMC明確標記版本不穩定。
更換與 HBase 捆綁的 Hadoop
因為 HBase 依賴於Hadoop，它將Hadoop jar的一個實例捆綁在其 lib 目錄下。捆綁的 jar 僅用於在獨立模式下使用。在分佈式模式下，群集上的 Hadoop 版本與 HBase 下的內容相匹配是至關重要的。將在 HBase lib 目錄中找到的 hadoop jar 替換為您在群集上運行的 hadoop jar，以避免版本不匹配問題。確保在整個集群中替換 HBase 中的 jar。
dfs.datanode.max.transfer.threads
HDFS DataNode在任何時候都會有一個文件數上限。在進行任何加載之前，請確保您已經配置了Hadoop的conf / hdfs-site.xml，並將該dfs.datanode.max.transfer.threads值設置為至少如下的值：
進行上述配置後，務必重新啟動HDFS。
沒有這個配置就會造成奇怪的故障。其中一種表現是對缺失區塊的投訴。例如：
ZooKeeper要求
動物園管理員3.4.x 是必需的。HBase 使用的多功能, 只可從動物園管理員3.4.0。hbase.zookeeper.useMulti 配置屬性默認為 true。參考 HBASE-12241 (在採用deadserver的複製隊列時會中斷複製的regionServer的崩潰) 和 HBASE-6775 (在可用於HBASE-6710 0.92 / 0.94兼容性修補程序時使用ZK.multi)。該屬性被棄用，並且在 HBase 2.0 中始終啟用 useMulti。
閱讀更多 會飛的魚go 的文章
