HBase 客户端类型

HBase  自带了很多用于各种编程语言客户端。

 

1. 介绍 (Introduction)
----------------------------
从目前非常流行的语言和环境可以访问 HBase。可以直接使用客户端 API, 或者通过一些中间代理访问，将用户请求翻译成 API 调用。这些代理将原生的
Java API 包装成其它协议的 API，这样客户端就可以使用这些对外提供的 API 以任意语言来编写。通常来说，外部 API 实现为一个专用的基于 Java 的
服务器，可以在内部使用 HBase 提供的 Table 客户端 API. 这样简化了网关服务器(gateway servers)的实现和维护。

另一方面，有很多工具尽量隐藏 HBase 和它所提供的 API, 用户可与特定的接口对话，或者面向一组库来开发来形成访问层，例如，提供一个数据访问对象(
data access objects, DAOs)的持久层.

 

1.1 网关 (Gateways)
-----------------------------------------------------------------------------------------------------------------------------------------
回到网关的方法，网关与客户端之间是由当前可用的选择和远程客户端的要求驱动的。其中最常用的就是 REST(Representational State Transfer,
即表述性状态传递)，它是基于现有的 web 技术。实际的传输协议是典型的 HTTP 协议，web 应用的标准协议。由于协议层负责传输可互操作格式的数据，这
使 REST 称为异构系统之间传输数据的理想选择。

REST 自定义了语义，这样，协议就可以用于以普通的方式定位远程服务的资源。不用改变协议，REST 可以兼容现有的技术，例如，web server 以及 proxy.
资源作为请求 URI 的一部分唯一指定，与此相反，例如，基于 SOAP 的服务，要定义一个新协议来适应标准。

然而，REST 和 SOAP 都面临冗长的协议等级，用于客户端和服务器端通信的人类可读文本，可以是纯文本或者基于 XML。对网络间传输的数据进行透明压缩
可以在一定程度上缓解这个问题。

作为一个结果，拥有大量服务器的企业，大量的带宽占用和许多相互隔离的服务，觉得需要降低带宽开销并实现自己的 RPC 层。Google 就是其中之一，它们
实现了 Protocol Buffers。由于这个实现起初没有发布，Facebook 开发了自己的版本，叫做 Thrift.

这些项目都有类似的特性集，不同之处在于它们所支持的语言数量。Protocol Buffers 与 Thrift 比较关键不同的是，Protocol Buffers 没有自己的 RPC
栈(RPC stack), 而是生成 RPC 定义，可以与其它 RPC 库使用。

HBase 为 REST 和 Thrift 提供了辅助服务器，它们实现为独立网关服务器(standalone gateway servers), 可以运行在独立或专用的服务器上。由于 Thrift
有自己的 RPC 实现，网关服务器只是为它们提供了简单的封装。对于 REST, HBase 有自己的实现，提供访问存储的数据。

    NOTE:
    -------------------------------------------------------------------------------------------------------------------------------------
    HBase 提供的 RESTServer 实际上支持 Protocol Buffers，没有实现一个单独的 RPC 服务器，而是利用了 HTTP 的 Accept 头来发送和接收在
    Protocol Buffers 中编码的数据。
    
没有人建议网关服务器如何部署，可以将它与其它服务器共存运行，也可以运行在专用的集群上。

另一种方法时直接将它们允许在客户端节点上。例如，有一个 web 服务器，通过 PHP 构建网页，将网关进程运行在这台服务器上是有利的。这样，客户端与
网关的通信是在本地，而网关与 HBase 之间的 RPC 通信是原生协议。

选择一种网关类型不是一个简单的任务，这取决于用户的应用场景：

    REST Use Case
    -------------------------------------------------------------------------------------------------------------------------------------
    REST 支持现有的基于 web 的体系，它能够完美地融合反向代理和其它缓存技术。并行运行多个 REST 服务器可以分摊它们之间的负载。例如，在每个
    运行应用服务器的机器上运行 REST 服务，构建一个 single-app-to-server 关系。

    Thrift/Avro Use Case
    -------------------------------------------------------------------------------------------------------------------------------------
    当需要在吞吐量上获取最好的性能时，使用紧凑的二进制协议。可以运行较少的服务器，例如，每个 region 服务器上运行一个 Thrift/Avro 服务器，
    构成 many-apps-to-server 关系。

    NOTE:
    -------------------------------------------------------------------------------------------------------------------------------------
    HBase 也含有一个 Avro 的 gateway server, 但由于较少的关注和支持，已在 HBase 0.96 之后的版本中放弃了。

 

1.2 框架 (Frameworks)
-----------------------------------------------------------------------------------------------------------------------------------------
软件开发的一个长期的趋势是模块化和解耦特定工作单元。可以将其称为职责分离(separation of responsibilities)或其它类似的名称，但它们的目标是
一致的：一次性构建通用的软件片段，而不是一遍一遍地重复发明轮子。很多编程语言都有模块的概念，在 Java 中是 JAR 文件，它为众多的消费者提供
共享代码。持久化库，或通用数据访问，就是这些类库之一。其中，一个流行的选择是 Hibernate，它为所有对象的持久化提供了通用接口。

也有数据操纵(data manipulation) 专用的语言，或者类似的尽可能无缝地进行数据操纵任务，以使其不对业务逻辑造成混乱。我们将会在下面探讨的域特定
语言(domain-specific languages, DSLs)涉及这些方面。另外一个新的趋势是将应用程序开发抽象出来，platform-as-a-service (PaaS)就是其最显著的表现。
它提供了快速编写应用所需的所有组件，包括应用程序服务器，相关的库文件，数据库，等待。

通过 PaaS, 仍需要编写代码并把它部署到 PaaS 所提供的基础设施上。逻辑上，下一步是提供数据访问 API, 应用程序不需要更进一步的设置就可以使用。
Google App Engine 服务就是这类服务之一，在它的服务上，用户可以与数据存储 API(作为一个库提供) 直接对话。这限制了应用程序的自由度，但假设
其存储 API 足够强大，并且对应用程序开发者的创造性没有强加限制，这可以使开发和管理应用程序非常容易。

Hadoop 是非常强大而且灵活的系统。实际上，Hadoop 上的很多组件都可以被替换，并且对于 Hadoop, 更应将它当做一个思想体系，而非特殊技术的集合。
由于这些原因，一类新的活跃的框架正在兴起是显而易见的。类似于 Google App Engine 服务，Hadoop 提供了服务器组件用于接受部署到其上的应用程序
请求，并对底层服务抽象出接口，例如存储服务。

令人感兴趣的是，这类框架，将它们称为数据应用程序服务器(data application servers), 或者 data-as-a-service (DaaS), 包括 Hadoop 的原生服务，
它是数据优先的(data first)。就像智能手机，安装实现业务场景的应用并运行在共享的数据所在的主机上。不需要耗费高昂的代价移动大量的数据来产生
结果。利用 HBase 作为存储引擎，可以让这些框架最优利用很多内置的特性，例如，利用服务器端的协处理器降低选择断言以及分析功能等。这里有一个
例子 Cask.

库和框架的共同之处是抽象层的概念，它是一个通用的数据访问 API 或 DSL。HBase 之上的框架也是如此，以及其它实现了 SQL 能力的通用存储层。将会在
后面的章节中分别讨论(see “SQL over NoSQL”), 它们提供了不同级别的 SQL 标准，例如 Impala, Hive, and Phoenix.

 

*
*
*

2. Gateway 客户端 (Gateway Clients)
-----------------------------------------------------------------------------------------------------------------------------------------
第一组客户端由 gateway 类型(gateway kind)组成, 向服务器按需发送客户端调用，如 get, put, 或 delete 。基于所选择的协议，通过所提供的 gateway
服务器，可以在自己的程序中访问。另一方面，也可以利用所提供的存储 API 来实现通用的，数据为中心的解决方案。

2.1 原生 Java API (Native Java)
-----------------------------------------------------------------------------------------------------------------------------------------
原生 Java API 已在前面各个章节讨论过，不需要启动任何 gateway 服务器，直接使用 Table 或 BufferedMutator 与 HBase 服务器通信，经由原生 RPC
调用。

 

2.2 REST
-----------------------------------------------------------------------------------------------------------------------------------------
HBase 自带了一个强大的 REST 服务器，完全支持客户端和管理 API. 它也为不同的消息格式提供支持，为客户端提供了多种选择来与服务器通信。

 

■ 操作 (Operation)
-----------------------------------------------------------------------------------------------------------------------------------------
对基于 REST 的客户端，要能够连接到 HBase, 需要启动合适的 gateway 服务器。这要通过所提供的脚本启动。下面的命令展示了如何获得命令行帮助，以
及以非守护进程的模式启动 REST 服务器。

    $ bin/hbase rest
    usage: bin/hbase rest start [--infoport <arg>] [-p <arg>] [-ro]
    --infoport <arg> Port for web UI
    -p,--port <arg> Port to bind to [default: 8080]
    -ro,--readonly Respond only to GET HTTP method requests [default:false]

    To run the REST server as a daemon, execute bin/hbase-daemon.sh start|stop rest [--infoport <port>] [-p <port>] [-ro]
    $ bin/hbase rest start
    ^C

需要按下 Ctrl-C 来退出该进程。help 中说明了需要使用一个不同的脚本来以一个后台进程运行服务器：

    $ bin/hbase-daemon.sh start rest
    starting rest, logging to /var/lib/hbase/logs/hbase-larsgeorgerest-<servername>.out

一旦服务器启动了，需要在命令行上使用 curl 来验证其是可操作的：

    $ curl http://<servername>:8080/
    testtable

    $ curl http://<servername>:8080/version
    rest 0.0.3 [JVM: Oracle Corporation 1.7.0_51-24.51-b03] [OS: Mac OS X 10.10.2 x86_64] [Server: jetty/6.1.26] [Jersey: 1.9]

获取根 URL(root URL), 即 "/" 返回可用表的列表，例子中为 testtable。通过 "/version" 获取 REST 服务器版本，以及它运行所在机器相关的信息。

另一方面，可以打开由 REST 服务器提供的 web-based UI。可以通过 --infoport 命令行参数在启动 REST 服务器时指定其他端口，或者修改配置属性：
hbase.rest.info.port, 默认值为 8085.

UI 界面具有的功能，与 HBase 提供的很多 web-based UIs 功能是共同的。中间部分提供有关服务器及其状态信息。对于 REST 服务器，除了 HBase 版本，
编译信息，和服务器启动时间外，没有太多信息。底部有到 HBase Wiki 的链接，对 REST API 进行解释。在该页面的顶部有几个链接用于提供额外的功能。

    ● Home
    -------------------------------------------------------------------------------------------------------------------------------------
    链接到服务器的 Home 页

    ● Local logs
    -------------------------------------------------------------------------------------------------------------------------------------
    打开一个列出本地日志目录的页面，提供基于 web 访问其他方式无法访问的日志文件   

    ● Log Level
    -------------------------------------------------------------------------------------------------------------------------------------
    这个页面可以为任何类查询和设置日志级别，或打包载入到服务器进程。
    
    ● Metrics Dump
    -------------------------------------------------------------------------------------------------------------------------------------
    HBase 中所有的服务器都有 metric 跟踪其活动，通过这个链接可以 JSON 格式访问。
    
    ● HBase Configuration
    -------------------------------------------------------------------------------------------------------------------------------------    
    打印出用于当前服务器进程的配置信息。
    
要停止作为守护进程运行的 REST 服务器，调用同一个脚本，只是把 start 替换为 stop 命令。

    $ bin/hbase-daemon.sh stop rest
    stopping rest..

可以根据自己的喜好启动任意数量的 REST 服务器，并且，也可以利用一个负载均衡器在多个 REST 服务器间路由数据流量。由于 REST 是无状态的，任何
所需的状态都是作为请求的一部分携带的，可以使用循环算法(或类似的方法)来分布负载。

--readonly, 或 -ro 参数将服务器切换到只读模式(read-only mode), 意思是只对 HTTP GET 操作响应。最后，使用 -p 或 --port 参数为服务器侦听指定
一个不同的端口，默认为 8080. 还有一些 REST 服务器在启动时关注的属性，下表列出它们及其默认值：

    Configuration options for the REST server
    +---------------------------------------+---------------+--------------------------------------------------------------------------
    | Property                                | Default        | Description
    +---------------------------------------+---------------+--------------------------------------------------------------------------
    | hbase.rest.dns.nameserver                | default        | Defines the DNS server used for the name lookup (NOTE:)
    +---------------------------------------+---------------+--------------------------------------------------------------------------
    | hbase.rest.dns.interface                | default        | Defines the network interface that the name is associated with (NOTE:)
    +---------------------------------------+---------------+--------------------------------------------------------------------------
    | hbase.rest.port                        | 8080            | Sets the HTTP port the server will bind to. Also settable per instance
    |