Impala与HBase整合实践

我们知道,HBase是一个基于列的NoSQL数据库,它可以实现的数据的灵活存储。它本身是一个大表,在一些应用中,通过设计RowKey,可以实现对海量数据的快速存储和访问。但是,对于复杂的查询统计类需求,如果直接基于HBase API来实现,性能非常差,或者,可以通过实现MapReduce程序来进行查询分析,这也继承了MapReduce所具备的延迟性。
实现Impala与HBase整合,我们能够获得的好处有如下几个:

  • 可以使用我们熟悉的SQL,像操作传统关系型数据库一样,很容易给出复杂查询、统计分析的SQL设计
  • Impala查询统计分析,比原生的MapReduce以及Hive的执行速度快很多

Impala与HBase整合,需要将HBase的RowKey和列映射到Impala的Table字段中。Impala使用Hive的Metastore来存储元数据信息,与Hive类似,在于HBase进行整合时,也是通过外部表(EXTERNAL)的方式来实现。

准备工作

首先,我们需要做如下准备工作:

涉及到相关系统的安装配置,可以参考相关文档和资料。
下面,我们通过一个示例表test_info来说明,Impala与HBase整合的步骤:

整合过程

  • 在HBase中创建表

首先,我们使用HBase Shell创建一个表,如下所示:

1 create 'test_info', 'info'

表名为test_info,只有一个名称为info的列簇(Column Family),我们计划该列簇中存在4个列,分别为info:user_id、info:user_type、info:gender、info:birthday。

  • 在Hive中创建外部表

创建外部表,对应的DDL如下所示:

1 CREATE EXTERNAL TABLE sho.test_info(
2 user_id string,
3 user_type tinyint,
4 gender string,
5 birthday string)
6 ROW FORMAT SERDE 'org.apache.hadoop.hive.hbase.HBaseSerDe'
7 STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler'
8 WITH SERDEPROPERTIES ("hbase.columns.mapping" = ":key, info:user_type, info:gender, info:birthday")
9 TBLPROPERTIES("hbase.table.name" = "test_info");

上面DDL语句中,在WITH SERDEPROPERTIES选项中指定Hive外部表字段到HBase列的映射,其中“:key”对应于HBase中的RowKey,名称为“user_id”,其余的就是列簇info中的列名。最后在TBLPROPERTIES中指定了HBase中要进行映射的表名。

  • 在Impala中同步元数据

Impala共享Hive的Metastore,这时需要同步元数据,可以通过在Impala Shell中执行同步命令:

1 INVALIDATE METADATA;

然后,就可以查看到映射HBase中表的结构:

1 DESC test_info;

表结构如图所示:



通过上面三步,我们就完成了Impala和HBase的整合配置。

验证整合

下面,我们通过实践来验证上述的配置是否生效。
我们模拟客户端插入数据到HBase表中,可以使用HBase API或者HBase Thrift来实现,这里我们使用了HBase Thrift接口来进行操作,详见文章 HBase Thrift客户端Java API实践
然后,我们就可以通过Impala Shell进行查询分析。基于上面创建整合的示例表,插入20000000(2000万)记录,我们做一个统计分析的示例,SQL语句如下所示:

1 SELECT user_type, COUNT(user_id) AS cnt FROM test_info WHERE gender='M' GROUP BYuser_type ORDER BY cnt DESC LIMIT 10;

运行结果信息,如下图所示:

上述程序运行所在Hadoop集群共有3个Datanode,执行上述统计SQL共用时88.13s。我的Hadoop集群配置比较低,2个节点是双核CPU,另一个是4核,内存足够,大概10G左右,而且还有好多程序在共享这些节点,如数据库服务器、SOLR集群等。如果提高配置,做一些优化,针对20000000(2000万)条记录做统计分析,应该可以在5s以内出来结果。
由于测试数据是我们随机生成的,gender取值为’M’和’F’,user_type的值为1到10,经过统计分组后,数据分布还算均匀。

时间: 2024-08-31 15:32:16

Impala与HBase整合实践的相关文章

Hive与Hbase整合

Hive与Hbase整合 我们这边开始使用hbase做实时查询,但是分析的任务还是得交给hive,hive计算的结果导入到hbase. hive提供了几个jar包,帮助我们实现: 创建与hbase共享的表,数据(数据和表两边都有) 映射来自hbase的表到hive hive查询的结果直接导入hbase 启动hive 启动命令如下,主要是指定jar包,以及hbase使用的zookeeper的地址 bin/hive --auxpath /opt/CDH/hive/lib/hive-hbase-han

服务器-Springmvc 和 Hbase整合

问题描述 Springmvc 和 Hbase整合 求大神指点 运行到图中红线处报错,但是我用junit 测试这个方法是正常的,部署到tomcat服务器上之后运行就会出错.HbaeDAO就是访问hbase的一个类,测试运行的时候没问题的 解决方案 这不是明显的少jar包吗

SNS与在线旅游的整合实践

SNS与在线旅游的整合实践 (5月12日,应邀在环球旅讯高峰论坛上做了"SNS与在线旅游"的主题演讲,以下内容根据演讲记录整理而成.) 摘要:旅游本身的黏度不足以支持SNS,另外SNS架构也不利于内容的积累.分类与检索,因此纯粹的旅游SNS很难成功.但SNS在用户互动方面的优势使其天然适合作为旅游社区的操作系统来使用,在电子商务中植入SNS元素也是很好的尝试. SNS用户互动强于BBS, 但在内容整合方面存在致命缺陷 社会化网络服务SNS在2008年,是整个互联网最热门的词汇.它是以个

小米hadoop&hbase微实践

小米hadoop&hbase微实践 谢良 • 选型依据 • upstream重要issue • 集群check list • 若干案例解析 • 一些微改进点与社区回馈 小米hadoop&hbase微实践

Kafka+Spark Streaming+Redis实时计算整合实践

基于Spark通用计算平台,可以很好地扩展各种计算类型的应用,尤其是Spark提供了内建的计算库支持,像Spark Streaming.Spark SQL.MLlib.GraphX,这些内建库都提供了高级抽象,可以用非常简洁的代码实现复杂的计算逻辑.这也得益于Scala编程语言的简洁性.这里,我们基于1.3.0版本的Spark搭建了计算平台,实现基于Spark Streaming的实时计算. 我们的应用场景是分析用户使用手机App的行为,描述如下所示: 手机客户端会收集用户的行为事件(我们以点击

大数据工具篇之Hive与HBase整合完整教程

一.引言 最近的一次培训,用户特意提到Hadoop环境下HDFS中存储的文件如何才能导入到HBase,关于这部分基于HBase Java API的写入方式,之前曾经有过技术文章共享,本文就不再说明.本文基于Hive执行HDFS批量向HBase导入数据,讲解Hive与HBase的整合问题.这方面的文章已经很多,但是由于版本差异,可操作性不大,本文采用的版本均基于以下版本说明中的版本. 二.版本说明 序号 软件 版本 1 Hive  0.10.0 2 HBase 0.94.0 3 Hadoop 1.

HBase最佳实践-多租户机制简析

背景介绍 在HBase1.1.0发布之前,HBase同一集群上的用户.表都是平等的,没有优劣之分.这种'大同'社会看起来完美,实际上有很多问题.最棘手的主要有这么两个,其一是某些业务较其他业务重要,需要在资源有限的情况下优先保证核心重要业务的正常运行,其二是有些业务在某些场景下会时常'抽风',QPS常常居高不下,严重消耗系统资源,导致其他业务无法正常运转.这实际上是典型的多租户问题,社区针对这个问题提出了相应的应对措施,主要有如下三点: (1)资源限制,主要针对用户.namespace以及表的Q

Kafka+Storm+HDFS整合实践

在基于Hadoop平台的很多应用场景中,我们需要对数据进行离线和实时分析,离线分析可以很容易地借助于Hive来实现统计分析,但是对于实时的需求Hive就不合适了.实时应用场景可以使用Storm,它是一个实时处理系统,它为实时处理类应用提供了一个计算模型,可以很容易地进行编程处理.为了统一离线和实时计算,一般情况下,我们都希望将离线和实时计算的数据源的集合统一起来作为输入,然后将数据的流向分别经由实时系统和离线分析系统,分别进行分析处理,这时我们可以考虑将数据源(如使用Flume收集日志)直接连接

HBase最佳实践 – 客户端重试机制

在运维HBase的这段时间里,发现业务用户一方面比较关注HBase本身服务的读写性能:吞吐量以及读写延迟,另一方面也会比较关注HBase客户端使用上的问题,主要集中在两个方面:是否提供了重试机制来保证系统操作的容错性?是否有必要的超时机制保证系统能够fastfail,保证系统的低延迟特性? 这个系列我们集中介绍HBase客户端使用上的这两大问题,本文通过分析之前一个真实的案例来介绍HBase客户端提供的重试机制,并通过配置合理的参数使得客户端在保证一定容错性的同时还能够保证系统的低延迟特性. 案