客户端
有关HBase客户端的更多信息，请参阅客户端。
ScannerTimeoutException或UnknownScannerException
如果从客户端到RegionServer的RPC调用之间的时间超过扫描超时，则抛出此异常。例如，如果Scan.setCaching设置为500，然后在ResultScanner上每调用500个.next()行，就会有一个RPC调用来获取下一批行，因为数据正以500行为一个块的形式传输到客户端。减少setCaching值可能是一个选项，但将此值设置得太低会导致对行数的处理效率低下。
请参阅扫描缓存。
Thrift和Java API的性能差异
如果Scan.setCaching太高，可能会出现性能不佳，甚至可能发生ScannerTimeoutExceptions，如上文的“ScannerTimeoutException或UnknownScannerException”中所述。如果Thrift客户端对给定工作负载使用错误的缓存设置，则与Java API相比，性能会受到影响。要在Thrift客户端中为给定扫描设置缓存，请使用该scannerGetList(scannerId, numRows)方法，其中numRows是一个表示要缓存的行数的整数。在一个案例中，我们发现在相同的查询条件下，将Thrift扫描的缓存从1000减少到100，。
调用Scanner.next时的LeaseException
在某些情况下，从RegionServer获取数据的客户端会获得LeaseException而不是通常的ScannerTimeoutException或UnknownScannerException。通常，例外的来源是org.apache.hadoop.hbase.regionserver.Leases.removeLease(Leases.java:230)（行号可能会有所不同）。它往往发生在缓慢/冻结的RegionServer#next调用中。可以通过hbase.rpc.timeout > hbase.regionserver.lease.period来防止它。Harsh J调查了该问题，作为邮件列表线程HBase的一部分，mail＃user – Lease不存在异常。
Shell或客户端应用程序在正常操作期间会引发许多可怕的异常
从0、20.0开始，\org.apache.hadoop.hbase.*\的默认日志级别为DEBUG。
在您的客户端上，编辑 $ HBASE_HOME / conf / log4j.properties，并更改log4j.logger.org.apache.hadoop.hbase=DEBUG为：log4j.logger.org.apache.hadoop.hbase=INFO，或者甚至log4j.logger.org.apache.hadoop.hbase=WARN。
长客户端暂停压缩
这是关于Apache HBase dist-list的一个相当常见的问题。这种情况下，客户端通常将大量数据插入到相对未优化的HBase集群中。压缩会加剧暂停，尽管它不是问题的根源。
请参阅用于预创建区域的模式上的“表创建：预创建区域”，并确认该表不是以单个区域开始的。
对于集群配置，请参考HBase配置，特别是hbase.hstore.blockingStoreFiles，hbase.hregion.memstore.block.multiplier，MAX_FILESIZE（区域的大小），和MEMSTORE_FLUSHSIZE.
暂停原因可能发生的稍长解释如下：在MemStores上有时会阻塞Puts，这些Plusher被阻塞的刷新线程阻塞，因为压缩文件太多而无法压缩，因为压缩程序有太多小文件要压缩而且必须重复压缩相同的数据。即使是轻微的压缩，也可能发生这种情况。更糟糕的是，Apache HBase不会压缩内存中的数据。因此，存储在MemStore中的64MB可能在压缩后变为6MB文件 – 这导致更小的StoreFile。好处是更多的数据被打包到同一个区域，但是通过能够编写更大的文件来实现性能 – 这就是为什么HBase在写入新的StoreFile之前等待flushsize的原因。较小的StoreFiles成为压缩的目标。如果不进行压缩，文件就会大得多，不需要那么多的压缩，但是这是以I/O为代价的。
有关其他信息，请参阅具有压缩的长客户端暂停上的此线程。
安全客户端连接（[由GSS异常引起：未提供有效凭据…]）
您可能会遇到以下错误：
Secure Client Connect ([Caused by GSSException: No valid credentials provided
(Mechanism level: Request is a replay (34) V PROCESS_TGS)])
此问题是由MIT Kerberos replay_cache组件中的＃1201和＃5924错误引起的。这些错误导致旧版本的krb5-server错误地阻止从Principal发送的后续请求。这导致krb5-server阻止从一个客户端发送的连接（每个RegionServer具有多个线程连接实例的HTable实例）；客户端日志中记录了诸如Request is a replay (34)之类的消息，您可以忽略这些消息，因为默认情况下，HTable将为每个失败的连接重试5 * 10（50）次。如果重试后与RegionServer的任何连接失败，HTable将抛出IOException，以便HTable实例的用户客户端代码可以进一步处理它。注意：HTable在HBase 1.0中弃用，使用Table。
或者，将krb5-server更新为解决这些问题的版本，例如krb5-server-1.10.3。有关详细信息，请参阅JIRA HBASE-10379。
ZooKeeper客户端连接错误
像这样的错误：
11/07/05 11:26:41 WARN zookeeper.ClientCnxn: Session 0x0 for server null,
unexpected error, closing socket connection and attempting reconnect
java.net.ConnectException: Connection refused: no further information
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1078)
11/07/05 11:26:43 INFO zookeeper.ClientCnxn: Opening socket connection to
server localhost/127.0.0.1:2181
11/07/05 11:26:44 WARN zookeeper.ClientCnxn: Session 0x0 for server null,
unexpected error, closing socket connection and attempting reconnect
java.net.ConnectException: Connection refused: no further information
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(Unknown Source)
at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1078)
11/07/05 11:26:45 INFO zookeeper.ClientCnxn: Opening socket connection to
server localhost/127.0.0.1:2181
要么是由于ZooKeeper关闭，要么是由于网络问题而无法访问。
实用程序zkcli可能有助于调查ZooKeeper问题。
客户端耗尽内存虽然堆大小似乎是稳定的（但堆外/直接堆不断增长）
您可能会遇到在邮件线程HBase，mail # user-疑似内存泄漏，中描述和处理的问题，邮件# user -疑似内存泄漏，并继续在HBase，mail # dev – FeedbackRe:疑似内存泄漏。解决方案是为-XX:MaxDirectMemorySize向客户端JVM传递一个合理的值。默认情况下，MaxDirectMemorySize等于-Xmx最大堆大小设置(如果设置了-Xmx)。尝试将其设置为较小的值(例如，一个用户在客户端堆为12g时成功地将其设置为1g)。如果你把它设置得太小，它就会导致fullgc，所以要把它设置得大一点。只有在运行新的实验性服务器端堆外缓存时，您才希望将此设置设置为客户端，因为此特性依赖于能够使用大的直接缓冲区(您可能必须保持单独的客户端和服务器端配置dirs)。
安全客户端无法连接（[由GSS异常引起：未提供有效凭据（机制级别：无法找到任何Kerberos tgt）]）
导致此问题的原因可能有多种。
首先，检查您是否拥有有效的Kerberos ticket。这是需要的，为了与安全的Apache HBase集群建立通信。通过运行klist命令行实用程序，检查当前在凭证缓存中的ticket（如果有）。如果未列出ticket，则必须通过运行带有指定密钥表的kinit命令或通过交互方式输入所需主体的密码来获取ticket。
然后，请参阅“Java安全指南疑难解答”部分。通过将javax.security.auth.useSubjectCredsOnly系统属性值设置为false，可以解决最常见的问题。
由于MIT Kerberos写入其凭证缓存的格式发生了变化，因此Oracle JDK 6 Update 26及更早版本中存在一个错误，导致Java无法读取由MIT Kerberos 1.8.1或更高版创建的Kerberos凭证缓存。如果您的环境中存在这种有问题的组件组合，要解决此问题，请先使用kinit登录，然后立即使用kinit -R刷新凭证缓存。刷新将重写凭证缓存而不会出现有问题的格式设置。
在JDK 1.4之前，JCE是一个非捆绑产品，因此，JCA和JCE通常被称为独立的，不同的组件。由于JCE现在捆绑在JDK 7.0中，因此区别越来越不明显。由于JCE使用与JCA相同的架构，因此JCE应该更恰当地被视为JCA的一部分。
由于JDK 1.5或更早版本，您可能需要安装Java Cryptography Extension或JCE。确保JCE jar在服务器和客户端系统上的类路径中。
您可能还需要下载无限强度的JCE策略文件。解压缩并解压缩下载的文件，并将策略jar安装到 /lib/security中。