hbase协处理器

大数据架构-使用HBase和Solr将存储与索引放在不同的机器上 摘要： HBase可以通过协处理器 Coprocessor 的方式向Solr发出请求，Solr对于接收到的数据可以做相关的同步：增、删、改索引的操作，这样就可以同时使用HBase存储量大和Solr检索性能高的优点了，更何况HBase和Solr都可以集群。这对海量数据存储、检索提供了一种方式，将存储与索引放在不同的机器上，是大数据 架构的必须品。 关键词： HBase, Solr, Coprocessor , 大数据 , 架构 正如我的之前的博客“ Solr与HBase架构设计 ” http://http://www.cnblogs.com/wgp13x/p/a8bb8ccd469c96917652201007ad3c50.html ​中所述，HBase和Solr可以通过协处理器 Coprocessor 的方式向Solr发出请求，Solr对于接收到的数据可以做相关的同步：增、删、改索引的操作。将存储与索引放在不同的机器上，这 是大数据架构的必须品，但目前还有很多不懂得此道的同学，他们对于这种思想感到很新奇，不过，这绝对是好的方向，所以不懂得抓紧学习吧。 有个朋友给我的那篇博客留言，说CDH也可以做这样的事情，我还没有试过，他还问我要与此相关的代码，于是我就稍微整理了一下，作为本篇文章的主要内容。关于CDH的事

1.起因(Why HBase Coprocessor) HBase作为列族数据库最常常被人诟病的特性包含：无法轻易建立“二级索引”，难以运行求和、计数、排序等操作。比方，在旧版本号的(<0.92)Hbase中， 统计数据表 的总行数。须要使用Counter方法，运行一次MapReduce Job才干得到。尽管HBase在 数据存储层 中集成了MapReduce。能够有效用于数据表的分布式计算。然而在非常多情况下，做一些简单的相加或者聚合计算的时候，假设直接将计算过程放置在server端，能够降低通讯开销，从而获得非常好的性能提升。于是，HBase在0.92之后引入了协处理器(coprocessors)。实现一些激动人心的新特性：能够轻易建立二次索引、复杂过滤器(谓词下推)以及訪问控制等。 2.灵感来源( Source of Inspration) HBase协处理器的灵感来自于Jeff Dean 09年的 演讲 ( P66-67)。 它依据该演讲实现了相似于bigtable的协处理器，包含以下特性: 每一个表服务器的随意子表都能够 运行代码 client的高层 调用接口 (client能够直接訪问数据表的行地址。多行读写会自己主动分片成多个并行的RPC调用) 提供一个非常灵活的、可用于建立分布式服务的数据模型 能够自己主动化扩展、负载均衡、应用请求路由

1.HBase基础 1.1.HBase基本介绍 1.2.HBase配置安装 1.3.HBase使用用例 1.3.1.增 1.3.2.删 1.3.3.改 1.3.4.查 1.4.HBase基本概念 1.4.1.表，rowkey，列蔟，列 1.4.2.数据版本TTL 1.4.3.root，meta，namespace表 1.4.4.master，regionserver，thriftserver 1.4.5.get，scan 1.5.HBase常用命令 1.5.1.shell所有命令 2.HBase进阶 2.1.HBase架构 2.1.1.写流程 2.1.2.读流程 2.1.3.split流程 2.1.4.merge流程 2.1.5.compact流程 2.1.6.balancer路程 2.1.7.WAL 2.2.HBase API 2.2.1.JAVA API 2.2.2.MapReduce API 2.3.HBase配置解析 2.3.1.hbase-env.sh 2.3.2.hbase-site.xml 2.4.HBase性能优化 2.4.1.客户端 2.4.2.服务端 2.4.3.ycsb 3.HBase高阶 3.1.HBase运维 3.1.1.节点启停 3.1.2.meta表修复 3.1.3.HBase监控 3.2.HBase协处理器 3.2.1.observer协处理器 3

1.hbase 的 Coprocessor 的简介 HBase 是一个分布式的存储体系，数据按照 RowKey 分成不同的 Region ，再分配给 RegionServer 管理。但是 RegionServer 只承担了存储的功能，如果 Region 能拥有一部分的计算能力，从而实现一个 HBase 框架上的 MapReduce ，那 HBase 的操作性能将进一步提升。正是为了解决这一问题， HBase 0.92 版本后推出了 Coprocessor -- 协处理器，一个工作在 Master/RegionServer 中的框架，能运行用户的代码，从而灵活地完成分布式数据处理的任务。 Coprocessor 包含两个组件，一个是 EndPoint （类似关系型数据库的存储过程），用以加快特定查询的响应，另一个就是 Observer （类似关系型数据库的触发器）。 Observer 也分为几个类型，其中 RegionObserver 提供了一组表数据操作的钩子函数，覆盖了 Get 、 Put 、 Scan 、 Delete 等操作（通常有 pre 和 post 两种情况，表示在操作发生之前或发生之后），我们可以通过重载这些钩子函数，利用 RegionServer 实现特定的数据处理需求。 2.Coprocessors 提供了两种部署方式： 1. 全局部署。把 jar 包的路径加入

宽表与高表的选择 hbase中的宽表是指很多列较少行，即列多行少的表，一行中的数据量较大，行数少；高表是指很多行较少列，即行多列少，一行中的数据量较少，行数大。 hbase的row key是分布式的索引，也是分片的依据。 hbase的row key + column family + column qualifier + timestamp + value 是HFile中数据排列依据。HFile据此，对数据的索引到data block级别，而不是行级别。所以这种key是HFile内部的粗粒度（data block粒度）本地索引的主键。 据此，在HBase中使用宽表、高表的优劣总结如下： 查询性能：高表更好，因为查询条件都在row key中, 是全局分布式索引的一部分。高表一行中的数据较少。所以查询缓存BlockCache能缓存更多的行，以行数为单位的吞吐量会更高。 分片能力：高表分片粒度更细，各个分片的大小更均衡。因为高表一行的数据较少，宽表一行的数据较多。HBase按行来分片。 元数据开销：高表元数据开销更大。高表行多，row key多，可能造成region数量也多，- root -、 .meta表数据量更大。过大的元数据开销，可能引起HBase集群的不稳定、master更大的负担（这方面后续再好好总结）。 事务能力：宽表事务性更好。HBase对一行的写入（Put

转自： https://blog.csdn.net/finad01/article/details/45952781 ------------------------------------------------------------------------------------------ hbase数据加盐（Salting）存储与协处理器查询数据的方法 用HBase存储数据时，如果不加任何处理，用户数据往往会集中在几个region中，从而导致数据处理的性能问题，写性能会不断下降，同时用MR处理时，往往会导致个别map处理非常耗时，下面主要介绍一种能够兼顾读写性能的hbase数据存储方法。 在HBase中，表的数据按Region存储，每个Region有StartKey，EndKey，默认情况下新建一个表只有一个region，然后随着不断写入数据，数据越来越多，region的size越来越大时，大到一定的阀值时Region会进行split成两个region，依次不断增加。这种默认方式，缺点主要是写的性能不断下降，数据主要集中在几个region中，同时region会经常split，当regionsplit的时候会导致regionserver的停顿，造成性能问题。 我们在实际使用中，用HBase存储的数据主要有用作两方面，一个是作为数据中心（历史数据备份库）

1. Hbase与hive的对比 A. Hive（数据仓库） ：Hive的本质其实就相当于将HDFS中已经存储的文件在mysql中做了一个双射关系，以便使用HSQL查询。hive适用于离线数据的分析和清洗，延迟较高。hive基于hdfs和mapreduce。 B. HBase（数据库） ：列式存储的非关系型数据库，用于存储结构化和半结构化的数据，不适合关联查询，基于hdfs，数据的持久化存储的体现形式是Hfile，存放于DataNode中。延迟较低。 总结 ：Hive和HBase是两种基于hadoop的不同技术，hive是一种类sql查询引擎，并且运行mapreduce任务，Hbase是在hadoop之上的nosql的key-value数据库。这两种工具可以同时使用，hive用来统计查询，hbase用来实时查询。两者之间数据可以互相写入。 2. HBase和Hive整合 A. hive的结果导入HBase中 --创建Hive表 create external table if not exists course.score(id int,cname string,score int) row format delimited fields terminated by '\t' stored as textfile ; --数据内容 1 zhangsan 80 2 lisi 60 3

1、系统架构 Client 1 包含访问hbase的接口，client维护着一些cache来加快对hbase的访问，比如regione的位置信息。 Zookeeper 1 保证任何时候，集群中只有一个master 2 存贮所有Region的寻址入口 3 实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master 4 存储Hbase的schema,包括有哪些table，每个table有哪些column family Master职责 1 为Region server分配region 2 负责region server的负载均衡 3 发现失效的region server并重新分配其上的region 4 HDFS上的垃圾文件回收 5 处理schema更新请求 Region Server职责 1 Region server维护Master分配给它的region，处理对这些region的IO请求 2 Region server负责切分在运行过程中变得过大的region 可以看到，client访问hbase上数据的过程并不需要master参与（寻址访问zookeeper和region server，数据读写访问regione server），master仅仅维护者table和region的元数据信息，负载很低。 2、整体结构（ 物理存储 ） 1

一、Phoenix简介 Phoenix 是 HBase 的开源 SQL 中间层，它允许你使用标准 JDBC 的方式来操作 HBase 上的数据。在 Phoenix 之前，如果你要访问 HBase，只能调用它的 Java API，但相比于使用一行 SQL 就能实现数据查询，HBase 的 API 还是过于复杂。 Phoenix 的理念是 we put sql SQL back in NOSQL ，即你可以使用标准的 SQL 就能完成对 HBase 上数据的操作。同时这也意味着你可以通过集成 Spring Data JPA 或 Mybatis 等常用的持久层框架来操作 HBase。 其次 Phoenix 的性能表现也非常优异， Phoenix 查询引擎会将 SQL 查询转换为一个或多个 HBase Scan，通过并行执行来生成标准的 JDBC 结果集。它通过直接使用 HBase API 以及协处理器和自定义过滤器，可以为小型数据查询提供毫秒级的性能，为千万行数据的查询提供秒级的性能。同时 Phoenix 还拥有二级索引等 HBase 不具备的特性，因为以上的优点，所以 Phoenix 成为了 HBase 最优秀的 SQL 中间层。 二、Phoenix安装 我们可以按照官方安装说明进行安装，官方说明如下： download and expand our installation tar

为什么要有HBase？ Hadoop生态圈中有了Hive，Hive可以像关系型数据库那样操作数据，那么为什么还要有HBase？ 首先HBase是一个非关系型数据库，是用于存储数据的，Hive是用于处理数据的。 Hive操作数据时虽然可以像关系型数据库那样操作，但Hive只是一个操作工具，而非一个针对大批量数据存储的解决方案。 我们先来看看HBase是什么，在去做做比较，这样大家就清晰多了。 什么是HBase？ HBase是谷歌的BigTable论文的开源实现，也有很多不同，BigTable使用GFS作为文件存储系统，HBase是使用HDFS作为存储系统(可配置)，依然是熟知的Apache下的产品。 HBase是一个高可靠、高性能、面向列的可伸缩分布式非关系型分布式存储系统，志在在廉价的PC上搭建起一个存储结构化和非结构化数据并处理大批量数据服务器集群，说白了就是把配置低的PC组成集群来处理成万上亿的数据。 HBase可以分为两种角色，一种是存储系统，一种是作为数据处理模型的MapReduce框架。 HBase与HDFS HBase HDFS 分布式存储提供文件系统 提供表状(逻辑化)的面向列的数据存储 针对存储大尺寸文件进行优化，不需要针对HDFS上的文件进行随机读写 针对表状的数据随机读取进行优化 直接使用文件 Key-Value操作数据 数据模型不灵活 灵活的数据模型