NodeJS->HBase(5)存储设计和数据访问

因为在前面的第4节中,涉及的内容主要是从Redis中校验数据和缓存数据更新,所以这里把HBase给拆分出来了,单独的放在这个章节,便于后续对这HBase内容和线索的扩张学习。

HBase被设计成为用来存储百亿行、百万列(高表、宽表、简称又长又粗)的结构化的数据,但是HBase里面数据存储和RowKey设计是有一定讲究的。因此,在设计这个HBase表去存储车辆运行数据的时候,要好好想想怎么样才能最高效的查询到我们要的数据,毕竟写入数据的最终目的是为了查询。

还有就是,永远不要指望使用HBase来实现RDBMS那样的灵活的查询功能(例如,表和表的join,这算SQL最基本的要求了吧!表如果不能用来join,那还要它干嘛,是不是都是这么想的),如果有这个想法,就尽早死了这条心,有些事情坚持很重要的,但是也要懂得放弃。
最后,HBase的目的是为了高并发的简单读和写和海量存储设计的,复杂的关系查询和多维计算天生就是不是它能干的,因此它还有有个好搭档Hive,这个后面再说,兄弟两关系不错。如果合二为一的话就是RDBMS了。

1/ 为什么要用HBase

HBase是根据Google BigTable的论文来设计的:用插入实现更新、强一致性、不支持关系型查询,几乎无限的存储能力是吸引我们的最重要的原因。为什么要用HBase,而不是主流使用的RDBMS(例如,MySQL、Oralce、DB2、Postgre等)。

因为,在我们这个Demo项目中,HBase它的定位是:

  • 作为OT(物联网机器)数据的存储湖
    汽车TBOX的数据属于OT(机器数据)数据的范畴,不属于IT(企业数据),所以我们将其视为企业的外部数据源,由于其量比较大,而且TB级别起步,比较耗费数据存储,因此是个经济的选择。
  • 没什么大量在线用户直接去查询它
    只是一个机器数据的最终归宿地,保存个十年,八年都没有问题,存储成本也比较低。
  • 没有OLAP,联机应用会去经常的读写访问它,所以比较适合做一个:
    高频写,低频批处理的数据库,当历史库最好了
  • Schema~Less的数据库
    随着外部的数据源越来越多,新增字段比较方便的接入进来,不需要修改表结构,这的确是个优势。
  • 海量数据的存储,而且是长期的存储
    对于车辆网IoT方式发送来的数据,可能需要保存很久:
    例如:
    例如新能源车辆的动力电池的运行数据,需要保存8年以上(国家要求),处于对动力电池的一个运行情况的售后和质保的信息处理。

1.1 数据存储

以下的一些数据存储相关软件会被用到:

  • Redis
    缓存一些频繁被查询的主数据(做前端校验),应对外部的超高并发的场景,按照目前的估计。
    缓存的数据,大概在1000万条级别,基本上都是K + V(V是hash类型,非string)。
  • HBase
    单一键值的简单数据结构的数据(车联网消息,量大,但是消息简单),高性能写入、和唯一键值的查询。
  • Hive
    会基于HBase的数据,形成一个OLAP的数据仓库,分析车辆网的数据
  • MySQL(多个库)
    – 主数据管理的DB(车辆主数据)
    – 消费者终端App的底层DB(查询爱车一般数据查询、车况状态、打分、保养推荐、等等信息)
    – 企业内部实时监控应用系统的DB(所有车辆运行状态、轨迹、车况、数据告警,维修、实时运行信息)

2/ 部署->配置->启动

过去很多HBase部署在Windows都使用Cygwin,但是比较新的版本好像不需要这样做了,貌似可以直接支持Windows了,接下来我们看看。

2.1 下载,解压缩

  • Windows
    使用hbase-1.2.6-bin.tar.gz,下载后直接解压缩目录下,因为只有比较新的版本才支持Windows,虽然可以启动,使用但是依然问题是非常多,非常不建议使用。
  • Unix/Linux
    则使用0.94.16的版本,这就是为什么需要一台Macbook的原因。

最好不要在Windows下面开发HBase的东西,因为有很多NodeJS的库文件,还没有支持1.2以上的版本,很多都仅仅只是支持到0.94.16。
例如:hbase-client 这个npm的包,目前只支持到0.94.16的版本,如果高于这个版本,则需要用户去使用 hbase-rpc-client,但是它是基于CoffeeScript的。

为什么不使用hbase这个包(非纯JavaScript实现),而是使用 hbase-client这个包(是由国人fengmk开发的纯JavaScript实现的),那是因为hbase在后续的npm install hbase –save的过程中,有几个krb的文件在编译过程中出现了问题,始终无法成功使用,所以我就放弃这个排名第一的npm包,而转向使用hbase-client包。
https://www.npmjs.com/package/hbase-client

2.2 修改配置信息 – 单机部署方式(Window下举例)

HBase是有几种安装和部署方式的:

  • 单机部署
    使用本地的OS的文件系统作为HBase的存储系统
  • 单机伪分布式
    使用单机Hadoop的HDFS文件系统作为HBase的存储系统
  • 集群+分布式部署
    HBase集群(多节点)+Haoop集群的方式

在本例中,我们可以尝试1和2这两种模式,其区别就是使用HDFS作为文件系统,还是本机OS的文件系统作为存储,进入到hbase解压缩后的conf目录中.

1)文件和目录:hbase-env.cmd    (如果是MacOS则修改hbase-env.sh)

2)文件和目录:log4j.properties

3)文件和目录:hbase-site.xml

在Windows环境下,这些Value路径的写法就是c:\\目录\\,使用的是双斜杠。如果HBase所在的操作系统不是MacOS,则直接就是\目录\目录\目录,默认HBase是会保存在\tmp这个目录下。

但是,你知道\tmp只是一个临时目录,本地自己玩玩还可以,真正的生产环境的话,基本上都是需要使用HDFS文件系统来作为数据存储路径,而非本地某个文件夹下。

保存上面修改的配置文件,然后准备启动咯。

2.3 启动HBase(不依赖HDFS)

在Window环境下,开启一个命令行窗口,然后直接运行:start-hbase.cmd(Unix/Linux下则是start-hbase.sh),在浏览器中输入http://localhost:16010 会发现HBase在Web界面上显示了它的所有的运行和状态信息。

 

使用HBase Shell验证一下HBase的运行状态:

  • 执行hbase.cmd shell(Linux: hbase shell)启动这个交互式客户端
  • 在hbase的shell下执行以下的命令,完成HBase一个基本交互测试,看看是否可以创建表,显示数据
    create ‘test’,’cf’     创建test表,以及cf作为这个表的列簇
    list                          显示当前hbase有多少表,结果肯定是只有一个
    put ‘test’,’rowid0001′, ‘cf:name‘,’alex’
    put ‘test’,’rowid0001′, ‘cf:gender‘,’man’
    scan ‘test’             显示这个test表里面所有数据,当然只有一行

如果以上过程没问题,说明这个HBase是运行良好的。

3/ 分布式场景怎么撸

先将HBase停掉,执行stop-hbase.sh/cmd就可以,然后jps一把,看看是否还有服务出于启动的状态。

单机环境玩玩就好,但是生产集群都是分布式的,部署HBase的集群你要考虑的组件,例如HBase Master、RegionServer、HDFS Datanode、ZooKeeper(独立的,非HBase自带的Zookeeper)等。因此,我们需要安装Hadoop(HDFS),以及ZooKeeper,作为HBase所依靠的基础。

网络上找了图(说明HBase和HDFS、ZooKeeper之间的关系)

 

  • HDFS
    它是作为HBase的持久层,存储数据用的,这点不用解释(就跟OS的文件系统一样),由Hadoop来提供。
  • Region
    就是HBase的表(可以暂时先这么理解),一个表可以有多个region(它是HBase数据存储的最基本单位。
    Region 是 HBase 可用性和分布式的基本单位。如果当一个表格很大,并由多个 CF 组成时,那么表的数据将存放在多个 Region 之间(在有的生产环境下,一个表的region多大6000+个以上),并且在每个 Region 中会关联多个存储的单元(Store)。
  • Region Server
    用来管理多个Region(管理HBase表),客户端连接的HBase的时候,实际上就是连接Region Server进行数据的读写。
  • HMaster
    可以理解成为HANA里面的nameserver,它知道所有region server的状态,并且将Region分配到不同的region server(这个表)。
    协调多个region server,平衡负载。
  • ZooKeeper
    这玩意哪儿都有它存在,之前在搞Spark、Kafka环境配置的时候就有它。
    这里,HBase也需要它,那是因为Zookeeper已经在事实上成为了Hadoop技术平台上的所有软件组件去实现HA的基础(高可用),它可以在分布式情况下,保证只有一个HMaster处于工作状态(如果你单机的话,那怎么也无法保证哈!)。

Spark、Kafka、Hive都有Master Node + Salve Node这样的概念,所以大家都遵照分布式设计,从而统一利用ZooKeeper来管理自己的HA容错机制。

 

3.1 Hadoop安装,配置

选择2.7.2的hadoop版本,解压缩。然后将HADOOP_HOME、JAVA_HOME放入到系统的path路径中,下面以Unix/Linux为例,修改/etc/profile,添加一下内容(这里的)

然后,执行source profile命令一下,让其立即生效。

3.1.1 修改core-site.xml文件

该文件位于hadoop解压缩后的/etc/hadoop目录下的),以下的property的配置内容都需要放入到<configuration> ….. </configuration>之间

说明:

  • fs.default.name,它的值hdfs://localhost:8020是Hadoop的NameNode的主机名,8020则是其访问端口。
  • hadoop.tmp.dir,这个属性不配置的话,默认就是/tmp目录,但是要求修改为自己的目录,只要不是/tmp就好(因为系统重启会清理掉这个目录),不安全,所以建议修改。
    注意:它不是临时目录,是hadoop的HDFS的文件系统基础,是hadoop存储数据块的位置目录

3.1.2 修改hdfs-site.xml文件

说明:1表示,存放在HDFS文件系统中的数据的副本只有1个,通常是3份,这里是单机模拟的,所以没必要3份。

3.1.3 修改mapred-site.xml文件

从mapred-site.xml.template拷贝过来,去掉.template后缀)

说明:这个是mapreduce job的tracker服务器的主机名,以及访问端口。最多有多少map任务,最多有多少个reduce任务等等

3.1.4 修改hadoop-env.sh文件

2.7.2版本的hadoop发行版,其实这个文件什么都不用改。将操作系统的JAVA_HOME的值拿出来放入到这个变量中而已。

也可以不修改#export HADOOP_HEAPSIZE=的值,默认就是1000,可以不用修改。

3.1.5 格式化namenode

启动Hadoop试试看,按照以下顺序执行shell命令

  • start-dfs.sh
  • start-yarn.sh
  • 打开浏览器:http://localhost:8088/
  • 打开浏览器:http://localhost:50070/
    切换到datanode,确保datanodenamenode都已经启动了才行
  • jps,执行结果如下
    3089 DataNode
    3346 ResourceManager
    3204 SecondaryNameNode
    2998 NameNode
    3735 Jps
    3437 NodeManager

格式化namenode,意味着初始化HDFS的这个环境,如果在hadoop运行起来之后,你在hdfs中保存过文件,那么再再执行一次格式化的操作将会把这些数据目录全部删除。相当于format c:/的意思。

到这里为止,Hadoop这个基础软件组件就已经安装好了。

3.2 ZooKeeper安装,配置

Zookeeper在我们的《Spark+Kafka开发测试(1)环境搭建》 讲解过。所以,这里就不再重复,记得修改dataDir的默认值就好了。

启动zookeeper服务。执行jps命令,应该发现多了一个服务

  • QuorumPeerMain,它就是zookeeper服务

3.3 修改HBase配置信息

1)文件和目录:hbase-env.cmd    (如果是MacOS则修改hbase-env.sh)

注意:这里的HBASE_MANAGES_ZK设置为true(true意味着使用HBase自带的Zookeeper服务,生产环境下则建议使用独立的zookeeper集群服务)

2)文件和目录:hbase-site.xml

  • hbase.rootdir
    HBase在什么地方对它的数据(元数据、数据等)进行持久化,这里使用了HDFS的标准URL,其中”/hbase”目录是会在HBase其中之后会在HDFS中进行创建。
  • hbase.cluster.distributed
    这里是true,因为我们用了hdfs作为HBase的持久层存储的(单节点的伪分布式也是分布式啊!)

修改完,保存!

3.4 基于Hadoop/HDFS的HBase

如果是基于分布式的模式来启动HBase,那么它所依赖的文件系统HDFS服务要先启动,其执行顺序如下:

  • start-dfs.sh
  • start-yarn.sh
  • start-hbase.sh
    启动hbase, 然后将在前面单机下的hbase shell的一些步骤都执行一遍,而且看看http://localhost:16010/中是否有刚才创建的数据表
  • jps,查看结果,应该多了两个服务(除了HDFS、Name/Data Node、Zookeeper的那些服务之外)
    HRegionServer
    HMaster

接下来,我们就可以连接进入hbase shell看看这个只有这么几个API(Create, Put, Get, Delete, Scan,Alert)的强大高性能分布式数据库到底神奇在什么地方。

4/ 连线HBase看看

启动HBase Shell,在命令下执行hbase.cmd  shell or hbase.sh shell就可以启动HBase的交互式客户端(Windows下则hbase.cmd shell),HBase Shell是一个使用JRuby开发的封装了JAVA API的HBase的客户端应用软件。

执行list,就可以列出当前Hbase中所有的数据库表,及其名称。

目前看来,HBase处于可用的状态。

4.1 经常用的API介绍

接下来,我们创建一个名为“test”的表看看。

  • 创建表
    create ‘message’,’cf’
  • 删除表
    disable ‘message’
    drop ‘message’
  • 插入数据
    put ‘message’,’唯一主键’,’cf:列a’,’列a的值’
    put ‘message’,’唯一主键’,’cf:列b’,’列b的值’
  • 查询单条
    get ‘表名’, ‘唯一主键’
  • 扫描表
    scan ‘表名’
    scan ‘表名’, filter
  • 更新数据
  • 创建namespace
    目前没发现有多大用处,用来管理权限和表的逻辑命名空间。

4.2  Put和Get

HBase的PUT和GET都是需要知道主键(row_key)才能操作的,PUT就是写入一条记录的某一列,GET就是取出一条记录(可以只取出某列簇中的某几列),这些通过额外参数都可以做到:

  • Put
    put ‘test’,’rowid0001′,’cf:name’,’alex’
    put ‘test’,’rowid0001′,’cf:age’,’21’
    put ‘test’,’rowid0001′,’cf:gender’,’man’
  • Get
    Get ‘test’,’rowid0001′

4.3  强大的Scan(扫描)命令和Filter(过滤器)

因为GET操作都是要基于唯一主键(row key)的,如果需要查询多条记录,进行数据的过滤赛选,那就只能使用Scan了(想象成select吧,这样好理解),然后配上filter(类似SQL的where条件语句)可以实现一定程度上的数据查询功能。

例如:

row_keycf:namecf:agecf:gendercf:account_balance City
rowid0001alex21male20000Beijing
rowid0002apple34female54107Shanghai
rowid0003kevin34male15001Wuhan
rowid0004helen34female55100shanghai
rowid0005tom35male100000shenzhen

以上有5条记录。

  • 取出所有性别为male的所有数据

    貌似:female的也会被取出来,毕竟是substring,目前没有找到好办法,以后最好是设计为W/M(或者0/1)来标识,不要用长字符串来标识。

    或者使用

    也可以实现这个目的。还可以使用比较符号:是 =、>=、 <、<=、!=等,这里不作细究,要用的时候再查也不迟。
    此外,操作符还可以使用:
    binaryprefix:m,M开头的
    regexstring:m*n,以M开头,N结束的
    将其转换为binary进行比较。

  • 取出年龄大于 21,并且列名为age

  • 扫描某些列

    效果和下面一样的

    scan ‘test’,{COLUMNS=> ‘cf:gender’}
    或者

    可以输出多个列

  • RowFilter – 通过过滤RowKey

    这样可以把rowkey中包含”5”的全部取出来,也可以使用binary/binaryprefix/regexstring这些比较符号来进行组合。

关于Filter的一些补充

– ValueFilter、ColumnPrefixFilter 这些过滤条件都都有大小写区分,只能过滤列(不能对RowKey)
– 在FILTER中可以使用OR、AND(还可以结合SKIP来使用)来拼接过滤条件
– MultipleColumnPrefixFilter比ColumnPrefixFilter可以多放入几个列作为筛选条件
– PrefixFilter 只能用来比较row_key。
例如PrefixFilter (‘EES001SVG002’),既可以把车辆为SVG002的所有的消息ID为EES001的数据全部选择出来。

现在想想后续开发新应用(Web、手机、用户自主查询、对外数据服务),其底层数据库数据库还真的不适合用HBase来干。貌似使用RDBMS是最合适的,这个我们后续在好好想想。

5/ 表, RowKey和列簇的设计

HBase是NoSQL数据库的反范式设计的,并且算是Schema-Free 或者是Schema-Less(自由模式),总的来说,就是不怎么讲究这些玩意。

对Schema没有什么强约束(例如:只需要定义cf-column family,而不需要定义列,方便后续扩展新的列),这些设计和我们使用的传统的RDBMS有着相当的不同,哪怕是一出校门就开始进入到开源世界的同学们,也是一样的不习惯,毕竟RDBMS是计算机专业的必修课程,而SQL也被视为正统。

所以,你会觉得用起来,屡试屡屡不爽,具体体现为:

  • 弱schema的设计,不定义列
  • 没有复合主键,只有唯一主键
  • 没有外键,没有外键约束功能(哪怕不用,你得有啊)
  • 几乎没有什么SQL的标准函数
  • 也不支持UDF的函数
  • 几乎没有SQL92或者ANSI SQL的功能,以前学的SQL全部没用
  • 不知道如何查询数据
  • 查询数据,还得写一段程序才能拿出来(虽然提供了JAVA、Python、JS的那种接口API)

我们看到了这些所谓的“缺点”,也要看到它的极强的优点:

  • 强一致性
  • 写很快
  • 分布式
  • 海量存储
    百亿级的表,百万列的表不是问题

在Hadoop整个生态圈里面,看到了很多重新造轮子的项目,目的有很多,不想去讨论。根据其创新性,HBase用HDFS的方式来接解决了传统RDBMS的数据的上限问题,这的确是是个创新。
将传统RDBMS的数据存储从TB提升到了PB、ZB级别,这点的确是HBase作为一个“数据库”的角色做到的最大的创新,也当之无愧的成为K-V数据库的最顶级的项目之一。

 

5.1 车联网消息的表设计

那么,来自车联网的消息表应该怎么设计呢?可否设计成一个宽表呢?以数据采集的时间点为基准呢?我们可以好好思考以下这些消息的情况:

  • 一辆车有400+多的数据采集点
  • 有的信息是1秒钟、5秒钟、10秒、有的则是30秒采集一次。如果车辆的信息采集时间间隔有10个,那就设计成10个表。
    car,一秒钟一次的
    car_5,5秒钟一次的
    car_10
    car_20
    car_30
    car_40
    car_60
    car_120
  • 很难将不同时间维度的数据进行对齐,因为他们的时间点都不一样。
  • 将相同时间点所采集的数据全部放在一个一个表里面,是可行的,而且无转换成本。
  • 室外温度、当前速度、电池包外壳温度、电池包最高温度、最低温度、最高电压、最低电压、所在GPS位置、电动机1/2的转速、剩余电池容量(千瓦时),这些是5秒钟一次,那我们就将其全部放在一个表中。
  • 表命名为car_5

那么,表是设计好了,主键呢? Row_Key呢?

5.2 表RowKey设计和最优化的读&写?

  • RowKey是表中全局唯一,不可重复
  • RowKey要包含一些关键信息、例如:车架号、车牌号、消息类型。
  • 时间戳可以体现在RowKey中,但是不要放在Key的前面,尽量放在Rowkey的后面,前面尽量放散列字段(车牌号、发动机号、消息类型ID等),容易造成热点问题。

Region热点问题:(网上摘取了一段别人写的,感觉像是从英文直接翻译来的
HBase中的行是按照rowkey的字典顺序排序的,这种设计优化了scan操作,可以将相关的行以及会被一起读取的行存取在临近位置,便于scan。然而糟糕的rowkey设计是热点的源头。热点发生在大量的client直接访问集群的一个或极少数个节点(访问可能是读,写或者其他操作)。大量访问会使热点region所在的单个机器超出自身承受能力,引起性能下降甚至region不可用,这也会影响同一个RegionServer上的其他region。

没看懂吧!没看懂吧!没问题,我们重新来理解一下:
Rowkey是按照字典顺序排序的(0-9,从小到大向后排),这样的数据排列很适合Scan操作,如果Rowkey是以时间戳作为前缀+其他主键信息的话,那么问题来了。因为任何一个Hbase表都会被分割为几个region(hbase.hregion.max.filesize在hbase-site.xml中的配置,一个region默认大小是10GB)。
一旦某个region超出了这个大小,这个region就被会被切分,然后出现一个新的region。我们知道,每个region server都负责几个region。如果是采用时间戳作为rowkey的前缀字符,那么每次写入的数据都是在最后一个region上(因为时间戳数据分布是顺序递增的,因此新数据没有机会被写入到其他的region server所管理的region中),这样会容易导致这个region所在的服务器负担很大,甚至影响这个节点上的其他数据库表的region的访问,这就是所谓的热点问题。(其实传统的列存储数据库也有这样的概念)。
因此,我们要避免数据库的读写,总是发生在某个region server所管理的某个region上,最好是让读写的数据随意的分散在不同的region server所管理的region上,真正的利用好分布式的优势,否则老是一台服务器在干活,这对其他的节点有点不公平啊。

RowKey 的设计方式规则有几种:

  • RowKey的前端
    前端最好是散列字段(一条条插入HBase表的数据的rowkey的前端不要是顺序的,最好是散列化的,有的建议用随机数)
  • RowKey的数据最好分为三段,也可以考虑用“-”来分割
    散列字段 + 时间 + 扩展
    例如,车架号-消息类型-时间戳
    车联网发来的数据,都是所有的车辆发来的,所以车架号(或者车牌号)算是一个散裂化的值,并且还具有含义,因此可以放在rowkey的前端。
  • 直接将传统RDBMS的几个复合主键合并成为一个
    或者是,将多个主键合并,然后后端加上时间序列,方便快速查找
  • 字符类型最佳
    定义为string类型
  • 定长
    最好是定长,不要长短不一
  • 唯一
  • 不要超过16字节,我们的例子中中为27位,流行建议为控制在16字节。
    虽然越短越好,但是也要考虑它的含义
    设计的好的RowKey,对于提高scan的性能很有帮助,并且有助于提升region server的命中率,
  • rowkey中不存放日期,只放入时间(避免连续数据的问题,同一天以内),我们的场景还是放了,那是因为我们的应用场景不同。

接下来,我们用前面写入的数据库表记录的row_key来举例,SVG002EES00120170810152020,就是一个车联网情况下的Row_Key的编码规则,在message这个表里面是唯一记录。

车架号消息类型ID日期(年月日)时间(时分秒)
SVG002EES00120170810152020

注意:关于这个编码规则我没有在任何的实际SAP公司负责的车联网项目使用过,你觉得有参考意义那就有,这些编码仅仅是本人自己设计。如果你愿意,你可以也可以在实际的工作中来使用,其实没问题的(不会有热点问题,毕竟散列字段已经在前面了,也考虑到了关键信息用于scan和filter,算是成功的设计了)。

5.3 多条件查询RowKey

针对上面的这个RowKey设计,我们来查询数据,做做统计分析看看,这里只能用scan操作:

  • 查询某个汽车(通过车架号<-车牌号)的一天的GPS轨迹(只输出GPS列的信息)

    或者,使用Columns来输出某几列:
  • 查询某个车从20170810的凌晨第一秒开始—->到20170824的夜晚23点59分的GPS数据

其实,在HBase Shell中,直接写这样的语句还是很不舒服的,所以对于Java、Python、Node也都有提供了对应API,方便用户来操作,后面我们将在Node中将数据写入HBase中。

5.4 那么列簇呢?

暂时不用管那多么,尽量按照以下要求就行:

  • 一个表,最好就一个列簇,2个也行,不要超过2个
  • 列簇名字,越短越好,2个字符足以。
  • 列簇的属性名,类似cf:message_id,这都太长了,最好是cf:mess_id,越短越好,只要你自己认识就可以,没必要把字段写很长,很全,写的一眼就能看懂,完全没必要,浪费存储空间。

6/ 数据终于要进HBase了

6.1 HBase支持哪些数据访问接口

使用HBase作为数据库来进行编程的情况下,还是使用Java会多一些,毕竟都是Java写的,亲切,效率高,原生API。所以:

  • 原生JAVA API
    支持JAVA语言来进行访问,在我们的例子里面是Node,所以可以不看.
  • Thrift Gateway
    利用Thrift的序列化技术可以支持C++, Python等,可以在线的访问Hbase表. HBase也提供了Thrift 服务,直接启动和停止就可以了。
  • REST Server
    利用HBase的REST服务,通过http来访问HBase表,这样所有的程序都可以访问它了,不管是你ASP, .Net,Node,还是Python,Node,PHP就都可以访问它了,只要你能发出HTTP协议的请求访问就可以了。HBase提供了REST服务,直接启动和停止就好了。
  • HBase Shell
    这其实不算一个接口,做做管理还可以

6.2 HBase的REST Server

HBase对Java是原生的API

修改hbase-site.xml文件,将hbase的rest服务的端口修改为8081,默认情况下不配置的话,如果启动HBase的REST Server的话,它会占用8080的端口,考虑在本机还有其他的一些服务可能会使用(例如,将来NodeJS的Web应用服务可能会用这个端口),所以将其修改为8081,避免端口占用的冲突。

 

6.2 安装访问hbase的npm包,测试连接

目前主流的NPM包有这么几个:

  • hbase 
    走的REST Connector的模式,需要hbase启动REST Server,用户很多,也很热门,每个月的下载量都很多。我们打算用这个,原因很简单,因为它排名第一。
  • hbase-rest-cli
    有点冷门,不怎么了解
  • hbase-client
    比较热门的一个包(好像是阿里巴巴的一个哥们写的,发布在Github上的一个开源项目),特点是使用 Asynchronous HBase client for Node.js, pure JavaScript implementation。Current State: Full tests on HBase 0.94.0 and 0.94.16 ,从它的NPM包网站介绍上拷贝下来的。目前只支持0.94的Hbase版本,这个有点麻烦。

 

使用hbase包,执行以下命令:

安装总是提示出错,问题目前看到是Hbase—>依赖—–> Krb5这个包——–>依赖openssl,而openssl在MacOS 10.11之后有一些改动。所以找不到h头文件。但是我们尝试了很多次安装这个包,都失败了,但是最终还是解决了这个小问题。如何解决的过程,写在一个单独的博客中《MacOS 10.11以上解决npm hbase依赖krb5的openssl找不到的问题》

 

 

Leave a Reply

Your email address will not be published.