期待已久的Apache HBase2.0已经正式发布

hbasehbasegroup 发表了文章 • 0 个评论 • 307 次浏览 • 2018-05-06 20:29 • 来自相关话题

激动
HBase2.0 啥时候发布?好奇宝宝也是期待了很久,曾几何时都把stack问“烦”了,就在2018年4月30日中午,期待已久的HBase 2.0发布啦!你是不是也很迫不及待想了解它?这次,作为一枚HBase搬运工,已经为你准备好了一大波 HBase 2.0.0导读材料,拿走不谢~北京时间2018年4月30日(星期一) 中午12:24,HBase的“掌门人”Michael Stack 在Announce Mail List中宣布了HBase 2.0.0 版本正式Release,大家可以开始下载使用了。
膜拜
拜读stack大神announce email原文,激动人心的时刻:The HBase team is happy to announce the immediate availability of Apache HBase 2.0.0. Apache HBase™ is the Hadoop database, a distributed, scalable, big data store. To learn more about HBase, see https://hbase.apache.org/. HBase 2.0.0 is our second major release, the first release off the HBase 2.0 line. Please review 'Upgrading from 1.x to 2.x' in the bundled HBase 2.0.0 Reference Guide before installing or upgrading for a list of notable incompatibilities, major changes, and features including a new Region assignment manager ("AMv2"), a means for configuring the read and/or write path to run off-heap, and an optional In-Memory Compaction ("IMC", A.K.A "Accordion") facility. According to our adopted Semantic Versioning guidelines[2], we allowed ourselves make breaking changes in this major version release. For example, Coprocessors will need to be recast to fit more constrained APIs and rolling upgrade of an hbase-1.x install to hbase-2.x without downtime is (currently) not possible. That said, a bunch of effort has been expended mitigating the differences; a hbase-1.x client can perform DML against an hbase-2 cluster. A bundled compatibility report showing difference from 1.2.6 may be of help [3]. For the complete list of fixes and improvements, see the included `CHANGES.md` (or online at [1]) and `RELEASENOTES.md`. ......邮件简述了HBase 2.0.0 有新版Assignment Manager V2,offhead read/write, in-memory compaction等。你是不是也很好奇,HBase 2.0 到底还有有哪些features?https://s.apache.org/hbase-2.0.0-JIRA-changes 上显示了HBase2.0.0相关的issue多达4551个issue, 这么多改动,还有哪些features值得关注一下呢?
了解
下面整理了一些HBase2.0.0 主要的feature介绍,更多特性,可以参考上述链接:
1.A new Region assignment manager ("AMv2") ,HBASE-14350 , HBASE-14614
AssignmentManager V2基于Procedure V2实现,能够更快速的分配Region,维护的region状态机存储不再依赖于ZooKeeper。亲可以搭建一个hbase2.0 集群,查看ZK节点列表,已经找不到类似region-in-transistion节点了。
2.Offheaping of Read/Write Path  HBASE-11425,HBASE-15179
读写路径中,使用Offheap区的内存,大大减少GC压力,提高稳定性、降低99延时。细节见下面offheap扩展阅读材料。
3.In-Memory Compaction  HBASE-17343
重新设计了CompactingMemStore 替代 DefaultMemStore,数据会在内存中事先进行合并compact,有效提高后续常规compaction的效率。
4.NettyRpcServer  HBASE-17263  
其实并不新鲜,早在1.x 淘宝就有使用,现在2.0 开始默认使用NettyRpcServer 。使用Netty替代HBase原生的RPC server,大大提升了HBaseRPC的吞吐能力,降低了延迟。
5.Async Client HBASE-16833 HBASE-15921
Client不在是原来同步等待,而是利用异步RPC机制,大大提高Client端请求并发度,有效提高资源利用率,扩大吞吐。
6. Support for MOB (Medium-Sized Objects)  HBASE-11339
MOB特性使得HBase支持存储小于10MB 的中等媒体对象数据,相比原来直接存储大对象插入hbase,其读写效率更高;Mob数据存储还是以hfile格式存储,兼容HBase现有特性,如snapshot、bulkload、replication等。MOB数据文件有独立的compaction和expire clean机制,稳定性更可控。
研究
还不过瘾?下面还真为热爱专研的砖友们网罗了一些hbase2.0特性详细的扩展阅读!都是大神执笔的干货:
1.  hbase2.0 in-memory compaction
2.  HBase 2.0 read replicas 功能介绍
3.  基于HBase2.0上的备份恢复
4.  HBase 2.0 offheap write
5.  HBase 2.0 offheap read
https://issues.apache.org/jira/browse/HBASE-11425
https://blogs.apache.org/hbase/search?q=offheap
6.  HBase 2.0 MOB 设计文档
7.  HBase 2.0 MOB 使用手册
8.  HBase 2.x Backup/Restore
9.  HBase 2.0 release issue
10. HBase 2.0 NettyRpcServer
11. HBase 2.0 In-memory compaction
12. HBase 2.0 AMv2
https://docs.google.com/docume ... /edit
https://docs.google.com/docume ... oycwj
https://docs.google.com/docume ... aring
13. HBase 2.0 ProcedureV2
官方下载&指南
HBase 2.0.0 安装包下载地址:
http://www.apache.org/dyn/closer.lua/hbase/2.0.0/ 
官方阅读:
1. https://s.apache.org/hbase-2.0.0-JIRA-changes  所有hbase2.0相关的jira,subtask 
2. http://hbase.apache.org/2.0/bo ... ost10  最新的HBase 2.0.0官方指南
3.http://apache.mirrors.tds.net/ ... .html  整理了v1.2.6和v2.0.0版本之间的兼容性报告
其他更多优化特性,不一一列举,后续可能会由HBase技术社区为你带来更多HBase 2.0细节上的特性优化文章分享。
结束语
大家在工作学习中遇到HBase技术问题发布在HBase技术社区论坛http://hbase.group ,欢迎大家在上面提问留言。想了解更多HBase技术请关注HBase社区公众号(微信号:hbasegroup),扫描下面二维码关注,也欢迎大家积极投稿。




大家可以添加社区人员微信(微信号:HackerUncle或者u7758258f),进HBase技术社区微信群交流HBase技术栈。 查看全部
激动
HBase2.0 啥时候发布?好奇宝宝也是期待了很久,曾几何时都把stack问“烦”了,就在2018年4月30日中午,期待已久的HBase 2.0发布啦!你是不是也很迫不及待想了解它?这次,作为一枚HBase搬运工,已经为你准备好了一大波 HBase 2.0.0导读材料,拿走不谢~北京时间2018年4月30日(星期一) 中午12:24,HBase的“掌门人”Michael Stack 在Announce Mail List中宣布了HBase 2.0.0 版本正式Release,大家可以开始下载使用了。
膜拜
拜读stack大神announce email原文,激动人心的时刻:
The HBase team is happy to announce the immediate availability of Apache HBase 2.0.0. Apache HBase™ is the Hadoop database, a distributed, scalable, big data store. To learn more about HBase, see https://hbase.apache.org/. HBase 2.0.0 is our second major release, the first release off the HBase 2.0 line. Please review 'Upgrading from 1.x to 2.x' in the bundled HBase 2.0.0 Reference Guide before installing or upgrading for a list of notable incompatibilities, major changes, and features including a new Region assignment manager ("AMv2"), a means for configuring the read and/or write path to run off-heap, and an optional In-Memory Compaction ("IMC", A.K.A "Accordion") facility. According to our adopted Semantic Versioning guidelines[2], we allowed ourselves make breaking changes in this major version release. For example, Coprocessors will need to be recast to fit more constrained APIs and rolling upgrade of an hbase-1.x install to hbase-2.x without downtime is (currently) not possible. That said, a bunch of effort has been expended mitigating the differences; a hbase-1.x client can perform DML against an hbase-2 cluster. A bundled compatibility report showing difference from 1.2.6 may be of help [3]. For the complete list of fixes and improvements, see the included `CHANGES.md` (or online at [1]) and `RELEASENOTES.md`. ......
邮件简述了HBase 2.0.0 有新版Assignment Manager V2,offhead read/write, in-memory compaction等。你是不是也很好奇,HBase 2.0 到底还有有哪些features?https://s.apache.org/hbase-2.0.0-JIRA-changes 上显示了HBase2.0.0相关的issue多达4551个issue, 这么多改动,还有哪些features值得关注一下呢?
了解
下面整理了一些HBase2.0.0 主要的feature介绍,更多特性,可以参考上述链接:
1.A new Region assignment manager ("AMv2") ,HBASE-14350 , HBASE-14614
AssignmentManager V2基于Procedure V2实现,能够更快速的分配Region,维护的region状态机存储不再依赖于ZooKeeper。亲可以搭建一个hbase2.0 集群,查看ZK节点列表,已经找不到类似region-in-transistion节点了。
2.Offheaping of Read/Write Path  HBASE-11425,HBASE-15179
读写路径中,使用Offheap区的内存,大大减少GC压力,提高稳定性、降低99延时。细节见下面offheap扩展阅读材料。
3.In-Memory Compaction  HBASE-17343
重新设计了CompactingMemStore 替代 DefaultMemStore,数据会在内存中事先进行合并compact,有效提高后续常规compaction的效率。
4.NettyRpcServer  HBASE-17263  
其实并不新鲜,早在1.x 淘宝就有使用,现在2.0 开始默认使用NettyRpcServer 。使用Netty替代HBase原生的RPC server,大大提升了HBaseRPC的吞吐能力,降低了延迟。
5.Async Client HBASE-16833 HBASE-15921
Client不在是原来同步等待,而是利用异步RPC机制,大大提高Client端请求并发度,有效提高资源利用率,扩大吞吐。
6. Support for MOB (Medium-Sized Objects)  HBASE-11339
MOB特性使得HBase支持存储小于10MB 的中等媒体对象数据,相比原来直接存储大对象插入hbase,其读写效率更高;Mob数据存储还是以hfile格式存储,兼容HBase现有特性,如snapshot、bulkload、replication等。MOB数据文件有独立的compaction和expire clean机制,稳定性更可控。
研究
还不过瘾?下面还真为热爱专研的砖友们网罗了一些hbase2.0特性详细的扩展阅读!都是大神执笔的干货:
1.  hbase2.0 in-memory compaction
2.  HBase 2.0 read replicas 功能介绍
3.  基于HBase2.0上的备份恢复
4.  HBase 2.0 offheap write
5.  HBase 2.0 offheap read
https://issues.apache.org/jira/browse/HBASE-11425
https://blogs.apache.org/hbase/search?q=offheap
6.  HBase 2.0 MOB 设计文档
7.  HBase 2.0 MOB 使用手册
8.  HBase 2.x Backup/Restore
9.  HBase 2.0 release issue
10. HBase 2.0 NettyRpcServer
11. HBase 2.0 In-memory compaction
12. HBase 2.0 AMv2
https://docs.google.com/docume ... /edit
https://docs.google.com/docume ... oycwj
https://docs.google.com/docume ... aring
13. HBase 2.0 ProcedureV2
官方下载&指南
HBase 2.0.0 安装包下载地址:
http://www.apache.org/dyn/closer.lua/hbase/2.0.0/ 
官方阅读:
1. https://s.apache.org/hbase-2.0.0-JIRA-changes  所有hbase2.0相关的jira,subtask 
2. http://hbase.apache.org/2.0/bo ... ost10  最新的HBase 2.0.0官方指南
3.http://apache.mirrors.tds.net/ ... .html  整理了v1.2.6和v2.0.0版本之间的兼容性报告
其他更多优化特性,不一一列举,后续可能会由HBase技术社区为你带来更多HBase 2.0细节上的特性优化文章分享。
结束语
大家在工作学习中遇到HBase技术问题发布在HBase技术社区论坛http://hbase.group ,欢迎大家在上面提问留言。想了解更多HBase技术请关注HBase社区公众号(微信号:hbasegroup),扫描下面二维码关注,也欢迎大家积极投稿。
9949390940b1325a1378b7dc82c960f3.jpg

大家可以添加社区人员微信(微信号:HackerUncle或者u7758258f),进HBase技术社区微信群交流HBase技术栈。

Hbase client 不定期超时

hbasetu 回复了问题 • 2 人关注 • 1 个回复 • 2291 次浏览 • 2018-05-05 23:30 • 来自相关话题

HBase流量限制和表负载均衡剖析

hbasehbasegroup 发表了文章 • 1 个评论 • 510 次浏览 • 2018-04-26 14:59 • 来自相关话题

1.概述
在HBase-1.1.0之前,HBase集群中资源都是全量的。用户、表这些都是没有限制的,看似完美实则隐患较大。今天,笔者就给大家剖析一下HBase的流量限制和表的负载均衡。
2.内容
也许有同学有疑问,为啥要做流量限制,无限制全量跑不是更好吗?举个例子,比如今天的双十一日,数据流量是非常大的。如果不限制用户和表的流量,某些重要的核心业务,需要在资源有限的情况下优先保证正常运行。如果非核心业务在此期间其QPS一直降不下来,严重消耗系统资源,影响核心业务的正常运作。
针对上述问题,可以采取以下方案来解决:
• 资源限制:针对用户、命名空间及表的请求大小和QPS进行限制。
• 资源隔离:将不同表中的数据通过物理隔离,均衡到不同的RegionServer上。
3.资源限制
开启HBase资源限制是有条件,其中包含以下两个条件:
• 版本必须在1.1.0以上,或者在低版本中打上了HBase对应的Patch(HBASE-11598)
• HBase的资源限制开关默认是关闭的,需要在HBase的配置文件中进行开启。添加内容如下所示:
# 编辑HBase配置文件vi $HBASE_HONE/conf/hbase-site.xml
# 添加如下内容 
<property>
   <name>hbase.quota.enabled</name>
   <value>true</value>
 </property>
# 退出编辑并保存
如果不是在首次启动时配置的,需要额外重启HMaster服务进程才能使之生效。
3.1 Quota语句
HBase中限流是通过Quota语句来操作的,限流的方式有两种,一种是针对用户进行限流;另一种是针对表来进行限流。操作命令如下所示:
# 限制用户u1每秒请求10次
hbase> set_quota TYPE => THROTTLE, USER => 'u1', LIMIT => '10req/sec'
# 限制用户u1每秒的读请求为10次
hbase> set_quota TYPE => THROTTLE, THROTTLE_TYPE => READ, USER => 'u1', LIMIT => '10req/sec'
# 限制用户u1每天的请求量为10M
hbase> set_quota TYPE => THROTTLE, USER => 'u1', LIMIT => '10M/day'
# 限制用户u1的写请求量每秒为10M
hbase> set_quota TYPE => THROTTLE, THROTTLE_TYPE => WRITE, USER => 'u1', LIMIT => '10M/sec'
# 限制用户u1在操作表t2时,每分钟的请求量为5K
hbase> set_quota TYPE => THROTTLE, USER => 'u1', TABLE => 't2', LIMIT => '5K/min'
# 限制用户u1在操作表t2时,每秒的读请求为10次
hbase> set_quota TYPE => THROTTLE, THROTTLE_TYPE => READ, USER => 'u1', TABLE => 't2', LIMIT => '10req/sec'
# 删除用户u1在命令空间ns2的请求限制
hbase> set_quota TYPE => THROTTLE, USER => 'u1', NAMESPACE => 'ns2', LIMIT => NONE
# 限制在命名空间ns1中每小时的请求为10次
hbase> set_quota TYPE => THROTTLE, NAMESPACE => 'ns1', LIMIT => '10req/hour'
# 限制表t1每小时的请求为10T
hbase> set_quota TYPE => THROTTLE, TABLE => 't1', LIMIT => '10T/hour'
# 删除用户u1的所有请求限制
hbase> set_quota TYPE => THROTTLE, USER => 'u1', LIMIT => NONE
# 显示用户u1在命名空间ns2中的所有限制详情
hbase> list_quotas USER => 'u1', NAMESPACE => 'ns2'
#显示命令空间ns2的所有限制详情
hbase>list_quotas NAMESPACE => 'ns2'
#显示表t1的所有限制详情
hbase>list_quotas TABLE => 't1'
#显示所有限制详情
hbase>list_quotas
从操作的命令中可以看出,HBase限制流量支持表和用户。可以通过THROTTLE_TYPE来控制READ(读)、WRITE(写)操作,这类操作在HBase中是随机进行限制的。而LIMIT关键字,可以从两个维度进行资源限制,分别是req/time和size/time。
1. req/time:这种表示限制单位时间内的请求次数,time可以是秒、分、时、天,req表示次数。
2. size/time:这种表示单位时间内请求数据的量,time可以是秒、分、时、天,size可以时B (bytes), K (kilobytes), M (megabytes), G (gigabytes), T(terabytes), P (petabytes)。
LIMIT限制默认大小是:10req/day 或 100P/hour。对于命令set_quota来说,执行这条命令仅仅是限制单个RegionServer上的流量,并不是整个集群的限制总量(集群限制总量=每个RegionServer的限制量*RegionNum)。另外,执行set_quota命令后,默认是需要等待300000秒(5分钟)才会生效。如果觉得时间太长,可以将生效时间缩短,通过hbase-site.xml文件中的参数hbase.quota.refresh.period来设置时间,比如:
# 一分钟后生效
hbase.quota.refresh.period=60000
3.2 限制命名空间中的表个数
在创建命名空间中的表个数,可以在创建命名空间时指定,也可以在创建之后在此修改表个数,同样也可以删除表限制。通过设置hbase.namespace.quota.maxtables属性值来改变。操作内容如下所示:
# 创建一个命令空间最大包含5个表
hbase> create_namespace 'ns1', {'hbase.namespace.quota.maxtables'=>'5'}
# 修改一个已存在的命令空间所允许的表数量大小为8个
hbase> alter_namespace 'ns2', {METHOD => 'set', 'hbase.namespace.quota.maxtables'=>'8'}
# 显示命令空间下的所有详情
hbase> describe_namespace 'ns2'
# 删除命令空间中表个数的限制
hbase> alter_namespace 'ns2', {METHOD => 'unset', NAME=>'hbase.namespace.quota.maxtables'}
3.3 限制命名空间的Region
在创建命名空间时 ,可以限制Region的个数。在创建之后也可以通过命令来修改个数的上限值。具体操作如下所示:
# 创建一个命名空间最大包含10个Region
hbase> create_namespace 'ns1', {'hbase.namespace.quota.maxregions'=>'10'
# 显示命令空间中详情
hbase> describe_namespace 'ns1'
# 修改命名空间中最大Region个数为20个
hbase> alter_namespace 'ns2', {METHOD => 'set', 'hbase.namespace.quota.maxregions'=>'20'}
# 删除命名空间中Region个数的限制
hbase> alter_namespace 'ns2', {METHOD => 'unset', NAME=> 'hbase.namespace.quota.maxregions'}
这里也许有些同学在操作的过程当中遇到过,在请求操作限制阀值时,日志没有打印出错误信息,这是由于默认日志输出时INFO级别,不会打印这类异常,如果要查看,可以通过修改log4j的日志级别为DEBUG,这样就可以查看到对应的异常信息了。
 4.资源隔离
在HBase中可以通过资源隔离的方式来间接的限流。将请求均衡到多个RegionServer中去。通过balance_switch命令来实现自动均衡操作。命令如下:
# 查看自动均衡状态
balance_switch status
# 停止自动均衡
balance_switch stop
# 开启自动均衡
balance_switch start
在实际业务中,如果HBase某个表的RegionServer全部集中在一个上,这时候可以考虑使用move命令手动均衡操作,具体操作语法如下:
# move手动操作语法
move [region id] [ServerName]
如下图所示:








从图中一个Table Region来说,”t2,,1510401809742.bd015fc10e75b70a52-adc0c32a2321c2.“其中region id为”bd015fc10e75b70a52-adc0c32a2321c2“。我们可以在HBase集群客户端执行以下命令来手动指定region。命令如下所示:
# 将该Region(dn3)移动到Region(dn1)
echo "move 'bd015fc10e75b70a52adc0c32a2321c2','dn1,16020,1510401268652'"|hbase shell
在往HBase表中写数据的时候,默认是往一个Region中写数据,当数据量很大时,才会自动拆分成多个Region,拆分的规则和RowKey设计有关。为了防止出现这种情况,我们可以在创建表的时候进行预分区操作。命令如下所示:
# 创建表的预分区(6个Region),RegionTotals = SPLITS.length + 1
create 't2', 'cf', SPLITS => ['0001','0002','0003','0004','0005']
这样我们可以拆分成6个Region,这里也许有同学要问,为什么是6个Region。其实,从上图中就可以看出,表分区中第一个Region是没有StartKey,最后一个Region是没有EndKey的。为什么会出现这种情况,下面就给大家来剖析这个原因。如下图所示:




从图中可知,在第一个Region中只有EndKey,没有StartKey。第一个Region中的EndKey(0001),就是第二个Region的StartKey,以此类推,到最后一个Region就只有StartKey(0005)了。这就是为什么第一个Region没有StartKey,最后一个Region没有EndKey的原因。
其实,我们在使用HBase的Java API获取Region的StartKey和EndKey的时候,有时会出现Null,也就是这个原因。
5.总结
在使用Quota命令进行限流时,需要确保hbase-site.xml文件中的限流属性开启。另外,在对表做手动均衡操作时,使用move命令即可。HBase是有自动均衡的策略的,均衡的Region取决于设计分割的Key,Key的产生又和HBase中中Rowkey的设计息息相关。所以,HBase中表的RowKey设计的是否优秀,决定了Region均衡时,分割Key的选取。
6.结束语
备注:大家在工作学习中遇到HBase技术问题发布在HBase技术社区论坛http://hbase.group ,欢迎大家在上面提问留言。想了解更多HBase技术请关注HBase社区公众号(微信号:hbasegroup),扫描下面二维码关注,也欢迎大家积极投稿。




大家可以添加社区人员微信(微信号:HackerUncle或者u7758258f),进HBase技术社区微信群交流HBase技术栈。 查看全部
1.概述
在HBase-1.1.0之前,HBase集群中资源都是全量的。用户、表这些都是没有限制的,看似完美实则隐患较大。今天,笔者就给大家剖析一下HBase的流量限制和表的负载均衡。
2.内容
也许有同学有疑问,为啥要做流量限制,无限制全量跑不是更好吗?举个例子,比如今天的双十一日,数据流量是非常大的。如果不限制用户和表的流量,某些重要的核心业务,需要在资源有限的情况下优先保证正常运行。如果非核心业务在此期间其QPS一直降不下来,严重消耗系统资源,影响核心业务的正常运作。
针对上述问题,可以采取以下方案来解决:
• 资源限制:针对用户、命名空间及表的请求大小和QPS进行限制。
• 资源隔离:将不同表中的数据通过物理隔离,均衡到不同的RegionServer上。
3.资源限制
开启HBase资源限制是有条件,其中包含以下两个条件:
• 版本必须在1.1.0以上,或者在低版本中打上了HBase对应的Patch(HBASE-11598)
• HBase的资源限制开关默认是关闭的,需要在HBase的配置文件中进行开启。添加内容如下所示:
# 编辑HBase配置文件vi $HBASE_HONE/conf/hbase-site.xml
# 添加如下内容 
<property>
   <name>hbase.quota.enabled</name>
   <value>true</value>
 </property>
# 退出编辑并保存
如果不是在首次启动时配置的,需要额外重启HMaster服务进程才能使之生效。
3.1 Quota语句
HBase中限流是通过Quota语句来操作的,限流的方式有两种,一种是针对用户进行限流;另一种是针对表来进行限流。操作命令如下所示:
# 限制用户u1每秒请求10次
hbase> set_quota TYPE => THROTTLE, USER => 'u1', LIMIT => '10req/sec'
# 限制用户u1每秒的读请求为10次
hbase> set_quota TYPE => THROTTLE, THROTTLE_TYPE => READ, USER => 'u1', LIMIT => '10req/sec'
# 限制用户u1每天的请求量为10M
hbase> set_quota TYPE => THROTTLE, USER => 'u1', LIMIT => '10M/day'
# 限制用户u1的写请求量每秒为10M
hbase> set_quota TYPE => THROTTLE, THROTTLE_TYPE => WRITE, USER => 'u1', LIMIT => '10M/sec'
# 限制用户u1在操作表t2时,每分钟的请求量为5K
hbase> set_quota TYPE => THROTTLE, USER => 'u1', TABLE => 't2', LIMIT => '5K/min'
# 限制用户u1在操作表t2时,每秒的读请求为10次
hbase> set_quota TYPE => THROTTLE, THROTTLE_TYPE => READ, USER => 'u1', TABLE => 't2', LIMIT => '10req/sec'
# 删除用户u1在命令空间ns2的请求限制
hbase> set_quota TYPE => THROTTLE, USER => 'u1', NAMESPACE => 'ns2', LIMIT => NONE
# 限制在命名空间ns1中每小时的请求为10次
hbase> set_quota TYPE => THROTTLE, NAMESPACE => 'ns1', LIMIT => '10req/hour'
# 限制表t1每小时的请求为10T
hbase> set_quota TYPE => THROTTLE, TABLE => 't1', LIMIT => '10T/hour'
# 删除用户u1的所有请求限制
hbase> set_quota TYPE => THROTTLE, USER => 'u1', LIMIT => NONE
# 显示用户u1在命名空间ns2中的所有限制详情
hbase> list_quotas USER => 'u1', NAMESPACE => 'ns2'
#显示命令空间ns2的所有限制详情
hbase>list_quotas NAMESPACE => 'ns2'
#显示表t1的所有限制详情
hbase>list_quotas TABLE => 't1'
#显示所有限制详情
hbase>list_quotas
从操作的命令中可以看出,HBase限制流量支持表和用户。可以通过THROTTLE_TYPE来控制READ(读)、WRITE(写)操作,这类操作在HBase中是随机进行限制的。而LIMIT关键字,可以从两个维度进行资源限制,分别是req/time和size/time。
1. req/time:这种表示限制单位时间内的请求次数,time可以是秒、分、时、天,req表示次数。
2. size/time:这种表示单位时间内请求数据的量,time可以是秒、分、时、天,size可以时B (bytes), K (kilobytes), M (megabytes), G (gigabytes), T(terabytes), P (petabytes)。
LIMIT限制默认大小是:10req/day 或 100P/hour。对于命令set_quota来说,执行这条命令仅仅是限制单个RegionServer上的流量,并不是整个集群的限制总量(集群限制总量=每个RegionServer的限制量*RegionNum)。另外,执行set_quota命令后,默认是需要等待300000秒(5分钟)才会生效。如果觉得时间太长,可以将生效时间缩短,通过hbase-site.xml文件中的参数hbase.quota.refresh.period来设置时间,比如:
# 一分钟后生效
hbase.quota.refresh.period=60000
3.2 限制命名空间中的表个数
在创建命名空间中的表个数,可以在创建命名空间时指定,也可以在创建之后在此修改表个数,同样也可以删除表限制。通过设置hbase.namespace.quota.maxtables属性值来改变。操作内容如下所示:
# 创建一个命令空间最大包含5个表
hbase> create_namespace 'ns1', {'hbase.namespace.quota.maxtables'=>'5'}
# 修改一个已存在的命令空间所允许的表数量大小为8个
hbase> alter_namespace 'ns2', {METHOD => 'set', 'hbase.namespace.quota.maxtables'=>'8'}
# 显示命令空间下的所有详情
hbase> describe_namespace 'ns2'
# 删除命令空间中表个数的限制
hbase> alter_namespace 'ns2', {METHOD => 'unset', NAME=>'hbase.namespace.quota.maxtables'}
3.3 限制命名空间的Region
在创建命名空间时 ,可以限制Region的个数。在创建之后也可以通过命令来修改个数的上限值。具体操作如下所示:
# 创建一个命名空间最大包含10个Region
hbase> create_namespace 'ns1', {'hbase.namespace.quota.maxregions'=>'10'
# 显示命令空间中详情
hbase> describe_namespace 'ns1'
# 修改命名空间中最大Region个数为20个
hbase> alter_namespace 'ns2', {METHOD => 'set', 'hbase.namespace.quota.maxregions'=>'20'}
# 删除命名空间中Region个数的限制
hbase> alter_namespace 'ns2', {METHOD => 'unset', NAME=> 'hbase.namespace.quota.maxregions'}
这里也许有些同学在操作的过程当中遇到过,在请求操作限制阀值时,日志没有打印出错误信息,这是由于默认日志输出时INFO级别,不会打印这类异常,如果要查看,可以通过修改log4j的日志级别为DEBUG,这样就可以查看到对应的异常信息了。
 4.资源隔离
在HBase中可以通过资源隔离的方式来间接的限流。将请求均衡到多个RegionServer中去。通过balance_switch命令来实现自动均衡操作。命令如下:
# 查看自动均衡状态
balance_switch status
# 停止自动均衡
balance_switch stop
# 开启自动均衡
balance_switch start
在实际业务中,如果HBase某个表的RegionServer全部集中在一个上,这时候可以考虑使用move命令手动均衡操作,具体操作语法如下:
# move手动操作语法
move [region id] [ServerName]
如下图所示:
2.jpg

3.jpg

从图中一个Table Region来说,”t2,,1510401809742.bd015fc10e75b70a52-adc0c32a2321c2.“其中region id为”bd015fc10e75b70a52-adc0c32a2321c2“。我们可以在HBase集群客户端执行以下命令来手动指定region。命令如下所示:
# 将该Region(dn3)移动到Region(dn1)
echo "move 'bd015fc10e75b70a52adc0c32a2321c2','dn1,16020,1510401268652'"|hbase shell
在往HBase表中写数据的时候,默认是往一个Region中写数据,当数据量很大时,才会自动拆分成多个Region,拆分的规则和RowKey设计有关。为了防止出现这种情况,我们可以在创建表的时候进行预分区操作。命令如下所示:
# 创建表的预分区(6个Region),RegionTotals = SPLITS.length + 1
create 't2', 'cf', SPLITS => ['0001','0002','0003','0004','0005']
这样我们可以拆分成6个Region,这里也许有同学要问,为什么是6个Region。其实,从上图中就可以看出,表分区中第一个Region是没有StartKey,最后一个Region是没有EndKey的。为什么会出现这种情况,下面就给大家来剖析这个原因。如下图所示:
4.jpg

从图中可知,在第一个Region中只有EndKey,没有StartKey。第一个Region中的EndKey(0001),就是第二个Region的StartKey,以此类推,到最后一个Region就只有StartKey(0005)了。这就是为什么第一个Region没有StartKey,最后一个Region没有EndKey的原因。
其实,我们在使用HBase的Java API获取Region的StartKey和EndKey的时候,有时会出现Null,也就是这个原因。
5.总结
在使用Quota命令进行限流时,需要确保hbase-site.xml文件中的限流属性开启。另外,在对表做手动均衡操作时,使用move命令即可。HBase是有自动均衡的策略的,均衡的Region取决于设计分割的Key,Key的产生又和HBase中中Rowkey的设计息息相关。所以,HBase中表的RowKey设计的是否优秀,决定了Region均衡时,分割Key的选取。
6.结束语
备注:大家在工作学习中遇到HBase技术问题发布在HBase技术社区论坛http://hbase.group ,欢迎大家在上面提问留言。想了解更多HBase技术请关注HBase社区公众号(微信号:hbasegroup),扫描下面二维码关注,也欢迎大家积极投稿。
1.jpg

大家可以添加社区人员微信(微信号:HackerUncle或者u7758258f),进HBase技术社区微信群交流HBase技术栈。

hbase修复数据如何使用权限?

回复

hbasewelch_wl 发起了问题 • 1 人关注 • 0 个回复 • 397 次浏览 • 2018-04-26 11:10 • 来自相关话题

外部应用访问hbase thrift权限管控方案

回复

hbasewelch_wl 发起了问题 • 1 人关注 • 0 个回复 • 399 次浏览 • 2018-04-20 14:19 • 来自相关话题

HBase集群的某台主机内存占用居高不下

回复

hbaselinjunzhu 发起了问题 • 1 人关注 • 0 个回复 • 2187 次浏览 • 2018-04-17 11:55 • 来自相关话题

RegionTooBusyException: Above memstore limit

hbaseZephyrGuo 回复了问题 • 2 人关注 • 1 个回复 • 2583 次浏览 • 2018-04-17 11:42 • 来自相关话题

stripe整理目前用的多吗?有哪些适应场景

hbasehmaster 回复了问题 • 2 人关注 • 1 个回复 • 1972 次浏览 • 2018-03-28 17:04 • 来自相关话题

hbase的可用性怎么样?

hbasehbase 回复了问题 • 2 人关注 • 1 个回复 • 2289 次浏览 • 2018-03-19 10:43 • 来自相关话题

Phoenix是否有集群概念?

hbasehbase 回复了问题 • 2 人关注 • 1 个回复 • 2300 次浏览 • 2018-03-19 10:37 • 来自相关话题

有没有比较详细全面的Phoenix功能原理文档

回复

phoenixjinqian 回复了问题 • 2 人关注 • 1 个回复 • 2499 次浏览 • 2018-03-16 14:57 • 来自相关话题

单数RegionServer可以正常部署吗?

hbasexiaoxiaomo 回复了问题 • 2 人关注 • 1 个回复 • 2142 次浏览 • 2018-03-15 16:31 • 来自相关话题

hbase2什么时候发布?

hbasehmaster 回复了问题 • 5 人关注 • 3 个回复 • 2130 次浏览 • 2018-03-12 14:37 • 来自相关话题

HBase技术社区兼职招聘社区秘书

招聘hbase 发表了文章 • 0 个评论 • 506 次浏览 • 2018-02-09 17:19 • 来自相关话题

背景说明

HBase是一个分布式的面向列的开源数据库,是大数据生态圈中非常重要的一环,主要应用在大数据量(PB级)存储及超大规模(千万级QPS)随机读写访问。HBase在国内的火爆程度逐年上涨,但目前国内尚无一个有较大影响力的HBase从业者和爱好者的聚集地。

为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,阿里巴巴、小米、网易、京东、滴滴、知乎等公司的HBase技术研究人员共同发起了组建HBase技术社区。
 
由于各位公司的同学都非常忙,为了保障社区的正常运转,我们希望在此能找到一些志愿者,在未来一起将HBase技术社区做大做强做成圈内权威。


作为HBase社区秘书,你可以获得什么?

我们将有可能形成一个全国范围内20万HBase从业者、爱好者的社区,而你,是这个平台的搭建者,一个成熟的技术社区的影响力在国内的意义非比一般,你作为开拓者,价值非凡,这个牛也够你吹一辈子了。
你将与阿里巴巴、小米、网易、京东、滴滴、知乎等诸位产品和技术人员一同共事,在别的同学做兼职办家教发传单的时候,你就已经接触到了国内最顶尖的技术和产品人员,并获得他们的指导,学习到国内一流公司的工作方法,这将为你将来的职业生涯探明道路,打下坚实的基础,同时毕业后你将获得这些国内一流公司的优先录取权。你将学习到如何将一个社区从0打造成1的过程,这段经验足以让你在毕业找工作时遥遥领先你的同学,并成为你进入国内一流公司的重要砝码;你将接触到众多HBase相关技术,在DT时代,数据的重要性无须赘述,而你获得了最先进的大数据相关知识,这对你的学业方向或者职业方向,都大有裨益。
 
主要的事项:
组织线上线下会议,参加技术大会维护公众号、网站的日常维护负责收集、整理、发布技术文章
 
我们对你的要求:
必须是理工科专业,计算机、通信、自动化、电子专业优先考虑;必须学习过至少一门数据库相关的课程,对数据库有基础概念;必须是未来两年有时间精力保障社区工作的学生,另外大一新生还请专心学业;我们需要的合伙人是能至少与我们共事2年的同学,还请各位同学仔细斟酌后再投递简历。对社区运营工作有极大热忱,运营工作需要细心、耐心和责任心,请先思考你的性格和兴趣是否适合做这样一份工作。运营社区是几个公司有理想的产品和研发人员组建,非盈利性质,大家在一起是做一件意义非凡的事情,但我希望这个时代,能有一位不问物质但求本心的人与我们一同前行。有过微博、今日头条、微信公众号或QQ、微信群(100人以上)运营管理经验的同学优先考虑,聪明好学者也可以忽略这条,只要你有潜质,我们愿意培养你。

有意向者,可将简历发送至 wenzheng.zwz@alibaba-inc.com,或扫描以下微信二维码,注明应聘者身份,期待你与我们一起共创HBase国内第一大社区。 查看全部
背景说明

HBase是一个分布式的面向列的开源数据库,是大数据生态圈中非常重要的一环,主要应用在大数据量(PB级)存储及超大规模(千万级QPS)随机读写访问。HBase在国内的火爆程度逐年上涨,但目前国内尚无一个有较大影响力的HBase从业者和爱好者的聚集地。

为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,阿里巴巴、小米、网易、京东、滴滴、知乎等公司的HBase技术研究人员共同发起了组建HBase技术社区。
 
由于各位公司的同学都非常忙,为了保障社区的正常运转,我们希望在此能找到一些志愿者,在未来一起将HBase技术社区做大做强做成圈内权威。


作为HBase社区秘书,你可以获得什么?

我们将有可能形成一个全国范围内20万HBase从业者、爱好者的社区,而你,是这个平台的搭建者,一个成熟的技术社区的影响力在国内的意义非比一般,你作为开拓者,价值非凡,这个牛也够你吹一辈子了。
  • 你将与阿里巴巴、小米、网易、京东、滴滴、知乎等诸位产品和技术人员一同共事,在别的同学做兼职办家教发传单的时候,你就已经接触到了国内最顶尖的技术和产品人员,并获得他们的指导,学习到国内一流公司的工作方法,这将为你将来的职业生涯探明道路,打下坚实的基础,同时毕业后你将获得这些国内一流公司的优先录取权。
  • 你将学习到如何将一个社区从0打造成1的过程,这段经验足以让你在毕业找工作时遥遥领先你的同学,并成为你进入国内一流公司的重要砝码;
  • 你将接触到众多HBase相关技术,在DT时代,数据的重要性无须赘述,而你获得了最先进的大数据相关知识,这对你的学业方向或者职业方向,都大有裨益。

 
主要的事项:
  • 组织线上线下会议,参加技术大会
  • 维护公众号、网站的日常维护
  • 负责收集、整理、发布技术文章

 
我们对你的要求:
  • 必须是理工科专业,计算机、通信、自动化、电子专业优先考虑;
  • 必须学习过至少一门数据库相关的课程,对数据库有基础概念;
  • 必须是未来两年有时间精力保障社区工作的学生,另外大一新生还请专心学业;我们需要的合伙人是能至少与我们共事2年的同学,还请各位同学仔细斟酌后再投递简历。
  • 对社区运营工作有极大热忱,运营工作需要细心、耐心和责任心,请先思考你的性格和兴趣是否适合做这样一份工作。
  • 运营社区是几个公司有理想的产品和研发人员组建,非盈利性质,大家在一起是做一件意义非凡的事情,但我希望这个时代,能有一位不问物质但求本心的人与我们一同前行。
  • 有过微博、今日头条、微信公众号或QQ、微信群(100人以上)运营管理经验的同学优先考虑,聪明好学者也可以忽略这条,只要你有潜质,我们愿意培养你。


有意向者,可将简历发送至 wenzheng.zwz@alibaba-inc.com,或扫描以下微信二维码,注明应聘者身份,期待你与我们一起共创HBase国内第一大社区。

新数仓系列:开源组件运营(3)

hbasesuozai 发表了文章 • 0 个评论 • 216 次浏览 • 2018-02-07 21:43 • 来自相关话题

大数据前几年各种概念争论很多,NoSQL/NewSQL,CAP/BASE概念一堆堆的,现在这股热潮被AI接过去了。大数据真正落地到车联网,分控,各种数据分析等等具体场景。

概念很高大上,搞得久了就会发现,大部分都还是数据仓库的衍伸,所以我们称呼这个为“新数仓”,我准备写一系列相关的文章,有没有同学愿意一起来的?请联系我。

产品决定的是长期竞争力,运营决定的是短期用户体验。本文简单梳理下开源组件的运营方法。不正确的,欢迎大家给我留言多讨论。


一、运营基本概念
运营主要分为内容运营、用户运营、活动运营和产品运营。

1. 内容运营

内容运营这样一个分支,其实核心要解决的问题是:围绕着内容的生产和消费搭建起来一个良性循环,持续提升各类跟内容相关的数据,如:内容数量、内容浏览量、内容互动数、内容传播数……等等。


因而,内容运营这个模块下要关注和解决的问题可能包括了以下问题中的一个或多个——

我的内容基础属性是什么?(文字?图片?音频?)需要具备何种调性?(逗比搞笑?段子八卦?深度评论?一手资讯?文艺暖心?)内容从哪里来?(UGC?PGC?)

我的内容如何组织和展现?(专题?列表?分类导航?字体?字号?行距?段距?)

如何在已有基础上做出用户更喜欢看的内容?(内容策划?内容选题?内容如何借势热点事件和人物?)

我现有的内容如何能够更容易、更高频地被用户所消费?(内容标题怎么写?好内容如何推送给用户?推送频次如何?推送手段有哪些?EDM?站内信?Push?)

我的内容生产如何可以具备持续性?(做活动?稿费?用户激励机制?其他利益交换?)

如何更好地引导用户来与我的内容发生互动甚至传播内容?(制造话题?讨论氛围引导?传播机制设计?)

2. 用户运营

跟内容运营相似,所谓用户运营这样一个分支,其实核心要解决的问题,也是围绕着用户的新增-留存-活跃-传播以及用户之间的价值供给关系建立起来一个良性的循环,持续提升各类跟用户有关的数据,如:用户数、活跃用户数、精英用户数、用户停留时间……等。

所以,用户运营要关注的问题可能包括了以下问题中的一个或多个——

我们的用户该从哪里来?(微博?豆瓣?广告?BD合作?线下地推?人肉?现有用户传播?)如何落实?(BD?付费?渠道建设?产品机制设定?)

用户来了之后,我们如何建立和维护我们跟用户间的关系?(多互动?多要反馈?多送礼品?多帮用户解决实际问题?)

如何让愿意留在这里玩的用户更多?(分析数据?关注留存?提升留存?关注活跃?拉升活跃?用户积分体系设计?用户激励体系设计?)

当用户量慢慢多起来比如达到几百万的时候,如何增强我对整个用户生态的影响力和掌控力?(如何对用户进行分类?针对每类用户我们应该如何服务和管理?怎样让不同类型的用户之间产生价值关系?如何构建起一个良性可掌控的站内用户模型?)

用户如果出现流失怎么办?(分析流失原因?建立流失预警机制?召回?放弃?)该如何召回?(召回策略?EDM?短信?Push?)


3. 活动运营

至于活动运营,核心就是围绕着一个或一系列活动的策划、资源确认、宣传推广、效果评估等一系列流程做好全流程的项目推进、进度管理和执行落地。一个活动运营,必须事先明确活动的目标,并持续跟踪活动过程中的相关数据,做好活动效果的评估。

其实,活动是一种再常见不过的运营手段,也是一个合格的运营必须要掌握和熟练运用的一种手段。往往在我们做内容运营和用户运营的过程中,也必不可少的会涉及到很多活动。所以其实,单独把“活动运营”设为一个独立岗位的互联网公司,其实并不是特别多。


基本上,一个公司可能会专门设置出来一个“活动运营”岗的典型场景,可能仅有两种——

该公司对“活动”的定位较高,会定期通过一些中大型的活动来拉升某些核心数据或是宣传公司品牌,而活动的策划设计、执行确认等也通常比较复杂,需要专门有人来主Hold和跟进(类似支付宝集五福这样的活动,就很复杂);

该公司用户已有一定用户体量,为了做好用户的维系,需要定期策划和落地一些活动。又或该项业务本身就需要持续不断的活动来助推(好比电商网站,淘宝天猫等各种定期购物节)。


4. 产品运营

所谓产品运营,其实要做的事情,就是通过一系列各式各样的运营手段(比如活动策划、内外部资源拓展和对接、优化产品方案、内容组织等等),去拉升某个产品的特定数据,如:装机量、注册量、用户访问深度、用户访问频次、用户关系对数量、发帖量……等等。

所以,一个真正意义上的“产品运营”,其实是一个综合能力比较均衡,既熟悉各类运营手段,又熟悉产品,甚至能够自己完成一些产品方案的人。

对于一家互联网公司,会设置一个“产品运营”岗位的场景,以下两种情况是比较典型的——

一个比较成熟的产品新上了一个分支功能,在一段时间内需要一个人对接协调各种资源,干好各种活,对该功能相关产品数据负责(如新浪微博上线了一个“微群组”功能);

一个中早期的互联网公司,不需要对运营划分得那么复杂,就是需要有一个人啥都至少会点儿,啥都能干,还能把产品养活起来,所以ta就成了“产品运营”……


二、开源组件运营


开源组件的运营,实际和产品运营比较贴切;

前面系列文章比较了Cassandra和Hbase。Cassandra在国外用的相对广泛,整体活跃度要高于hbase;和hbase在国内反而要火一些。




Cassandra最近两年在大数据公司Datastax的大力培育下获得长足发展,功能和性能均大幅提升,Datastax的估值也达数亿美元。从apache cassandra首页来看,大概有超过1500个公司在使用cassandra。其中除了facebook和twitter外还一些有代表性的公司列举如下:

Instagram:inbox、newsfeed、 audit、fraud detection,12 EC2 node,1.2T,2w+ wps,1.5w+ rps;

eBay:200+TB,400+M写,100+M读,应用场景:商品详情页上的Social Signals,如Like,Want,Own,Favorites等;用户和商品的hunch taste graph;时间序列如移动通知,反作弊,soa,监控,日志服务等;

Netflix:包含288+96+60个实例的大规模集群,每秒110万的写操作,3个AWS EC2 美国东部region的zone自动复制副本,总计330万写操作/秒;

Apple:75000+ nodes, 10s of PBs,Millions ops/s, largest cluster 1000+ nodes。




从技术实现上来讲,cassandra同时具备AWS Dynamo和Google Bigtable的设计理念,同时引入了P2P技术,具备大规模可分区行存储能力,强调AP,实现了最终一致性,具备多数据中心复制支持,具备市场上最具有竞争力的可扩展性,无中心节点,一致性和时延可调,无单点故障,每个节点只有一个进程等等大数据存储管理的先进特点,并支持spark、storm、hadoop的集成。但同时,Cassandra实现复杂性高,没有相应的中文社区,文档太少,国内应用和实践太少,Datastax也未进入中国市场,因此在中国的推广会比较困难。


众多大数据开源组件里面,相对来说,搞的相对比较好的是spark,mongoDB。搞的好,通常需要一个商业组织在负责和管理,纯粹靠开源运作和个人兴趣,是比较难的。可以先看一眼mongoDB的中文社区http://mongoing.com/webinar_cn,相比我前面讲的hbase没有一个共同的社区要好不少。


开源运营通常的手段有:

1、  有一个好的社区(用于用户互动,不限于论坛,微信群,QQ群)。

2、  好的资料;用户手册(中文手册)、出版书籍、周报、日报等,帮助解决入门门槛问题。

3、  线上线下交流活动(meetup,专家讲座,summit等)。

4、  成功的用户案例。

5、  ISV(云应用市场,线下团队)

6、  最最重要的还是产品要好,要有一个广泛的适应场景,解决客户足够多的问题,持续的演进和竞争力(低成本、高性能、稳定性、易用性),出了问题及时响应解决。


现在很多云服务都是基于开源组件实现,做云服务核心核心之一就是做生态,所以相比传统的产品销售,只靠产品特性打动用户是远远不够的。

产品决定的是长期竞争力,运营决定的是短期用户体验。云服务领域,产品和运营,两手抓、两手都要硬! 查看全部
大数据前几年各种概念争论很多,NoSQL/NewSQL,CAP/BASE概念一堆堆的,现在这股热潮被AI接过去了。大数据真正落地到车联网,分控,各种数据分析等等具体场景。

概念很高大上,搞得久了就会发现,大部分都还是数据仓库的衍伸,所以我们称呼这个为“新数仓”,我准备写一系列相关的文章,有没有同学愿意一起来的?请联系我。

产品决定的是长期竞争力,运营决定的是短期用户体验。本文简单梳理下开源组件的运营方法。不正确的,欢迎大家给我留言多讨论。


一、运营基本概念
运营主要分为内容运营、用户运营、活动运营和产品运营。

1. 内容运营

内容运营这样一个分支,其实核心要解决的问题是:围绕着内容的生产和消费搭建起来一个良性循环,持续提升各类跟内容相关的数据,如:内容数量、内容浏览量、内容互动数、内容传播数……等等。


因而,内容运营这个模块下要关注和解决的问题可能包括了以下问题中的一个或多个——

我的内容基础属性是什么?(文字?图片?音频?)需要具备何种调性?(逗比搞笑?段子八卦?深度评论?一手资讯?文艺暖心?)内容从哪里来?(UGC?PGC?)

我的内容如何组织和展现?(专题?列表?分类导航?字体?字号?行距?段距?)

如何在已有基础上做出用户更喜欢看的内容?(内容策划?内容选题?内容如何借势热点事件和人物?)

我现有的内容如何能够更容易、更高频地被用户所消费?(内容标题怎么写?好内容如何推送给用户?推送频次如何?推送手段有哪些?EDM?站内信?Push?)

我的内容生产如何可以具备持续性?(做活动?稿费?用户激励机制?其他利益交换?)

如何更好地引导用户来与我的内容发生互动甚至传播内容?(制造话题?讨论氛围引导?传播机制设计?)

2. 用户运营

跟内容运营相似,所谓用户运营这样一个分支,其实核心要解决的问题,也是围绕着用户的新增-留存-活跃-传播以及用户之间的价值供给关系建立起来一个良性的循环,持续提升各类跟用户有关的数据,如:用户数、活跃用户数、精英用户数、用户停留时间……等。

所以,用户运营要关注的问题可能包括了以下问题中的一个或多个——

我们的用户该从哪里来?(微博?豆瓣?广告?BD合作?线下地推?人肉?现有用户传播?)如何落实?(BD?付费?渠道建设?产品机制设定?)

用户来了之后,我们如何建立和维护我们跟用户间的关系?(多互动?多要反馈?多送礼品?多帮用户解决实际问题?)

如何让愿意留在这里玩的用户更多?(分析数据?关注留存?提升留存?关注活跃?拉升活跃?用户积分体系设计?用户激励体系设计?)

当用户量慢慢多起来比如达到几百万的时候,如何增强我对整个用户生态的影响力和掌控力?(如何对用户进行分类?针对每类用户我们应该如何服务和管理?怎样让不同类型的用户之间产生价值关系?如何构建起一个良性可掌控的站内用户模型?)

用户如果出现流失怎么办?(分析流失原因?建立流失预警机制?召回?放弃?)该如何召回?(召回策略?EDM?短信?Push?)


3. 活动运营

至于活动运营,核心就是围绕着一个或一系列活动的策划、资源确认、宣传推广、效果评估等一系列流程做好全流程的项目推进、进度管理和执行落地。一个活动运营,必须事先明确活动的目标,并持续跟踪活动过程中的相关数据,做好活动效果的评估。

其实,活动是一种再常见不过的运营手段,也是一个合格的运营必须要掌握和熟练运用的一种手段。往往在我们做内容运营和用户运营的过程中,也必不可少的会涉及到很多活动。所以其实,单独把“活动运营”设为一个独立岗位的互联网公司,其实并不是特别多。


基本上,一个公司可能会专门设置出来一个“活动运营”岗的典型场景,可能仅有两种——

该公司对“活动”的定位较高,会定期通过一些中大型的活动来拉升某些核心数据或是宣传公司品牌,而活动的策划设计、执行确认等也通常比较复杂,需要专门有人来主Hold和跟进(类似支付宝集五福这样的活动,就很复杂);

该公司用户已有一定用户体量,为了做好用户的维系,需要定期策划和落地一些活动。又或该项业务本身就需要持续不断的活动来助推(好比电商网站,淘宝天猫等各种定期购物节)。


4. 产品运营

所谓产品运营,其实要做的事情,就是通过一系列各式各样的运营手段(比如活动策划、内外部资源拓展和对接、优化产品方案、内容组织等等),去拉升某个产品的特定数据,如:装机量、注册量、用户访问深度、用户访问频次、用户关系对数量、发帖量……等等。

所以,一个真正意义上的“产品运营”,其实是一个综合能力比较均衡,既熟悉各类运营手段,又熟悉产品,甚至能够自己完成一些产品方案的人。

对于一家互联网公司,会设置一个“产品运营”岗位的场景,以下两种情况是比较典型的——

一个比较成熟的产品新上了一个分支功能,在一段时间内需要一个人对接协调各种资源,干好各种活,对该功能相关产品数据负责(如新浪微博上线了一个“微群组”功能);

一个中早期的互联网公司,不需要对运营划分得那么复杂,就是需要有一个人啥都至少会点儿,啥都能干,还能把产品养活起来,所以ta就成了“产品运营”……


二、开源组件运营


开源组件的运营,实际和产品运营比较贴切;

前面系列文章比较了Cassandra和Hbase。Cassandra在国外用的相对广泛,整体活跃度要高于hbase;和hbase在国内反而要火一些。




Cassandra最近两年在大数据公司Datastax的大力培育下获得长足发展,功能和性能均大幅提升,Datastax的估值也达数亿美元。从apache cassandra首页来看,大概有超过1500个公司在使用cassandra。其中除了facebook和twitter外还一些有代表性的公司列举如下:

Instagram:inbox、newsfeed、 audit、fraud detection,12 EC2 node,1.2T,2w+ wps,1.5w+ rps;

eBay:200+TB,400+M写,100+M读,应用场景:商品详情页上的Social Signals,如Like,Want,Own,Favorites等;用户和商品的hunch taste graph;时间序列如移动通知,反作弊,soa,监控,日志服务等;

Netflix:包含288+96+60个实例的大规模集群,每秒110万的写操作,3个AWS EC2 美国东部region的zone自动复制副本,总计330万写操作/秒;

Apple:75000+ nodes, 10s of PBs,Millions ops/s, largest cluster 1000+ nodes。




从技术实现上来讲,cassandra同时具备AWS Dynamo和Google Bigtable的设计理念,同时引入了P2P技术,具备大规模可分区行存储能力,强调AP,实现了最终一致性,具备多数据中心复制支持,具备市场上最具有竞争力的可扩展性,无中心节点,一致性和时延可调,无单点故障,每个节点只有一个进程等等大数据存储管理的先进特点,并支持spark、storm、hadoop的集成。但同时,Cassandra实现复杂性高,没有相应的中文社区,文档太少,国内应用和实践太少,Datastax也未进入中国市场,因此在中国的推广会比较困难。


众多大数据开源组件里面,相对来说,搞的相对比较好的是spark,mongoDB。搞的好,通常需要一个商业组织在负责和管理,纯粹靠开源运作和个人兴趣,是比较难的。可以先看一眼mongoDB的中文社区http://mongoing.com/webinar_cn,相比我前面讲的hbase没有一个共同的社区要好不少。


开源运营通常的手段有:

1、  有一个好的社区(用于用户互动,不限于论坛,微信群,QQ群)。

2、  好的资料;用户手册(中文手册)、出版书籍、周报、日报等,帮助解决入门门槛问题。

3、  线上线下交流活动(meetup,专家讲座,summit等)。

4、  成功的用户案例。

5、  ISV(云应用市场,线下团队)

6、  最最重要的还是产品要好,要有一个广泛的适应场景,解决客户足够多的问题,持续的演进和竞争力(低成本、高性能、稳定性、易用性),出了问题及时响应解决。


现在很多云服务都是基于开源组件实现,做云服务核心核心之一就是做生态,所以相比传统的产品销售,只靠产品特性打动用户是远远不够的。

产品决定的是长期竞争力,运营决定的是短期用户体验。云服务领域,产品和运营,两手抓、两手都要硬!

新数仓系列:Hbase周边生态梳理(1)

hbasesuozai 发表了文章 • 0 个评论 • 292 次浏览 • 2018-02-07 21:41 • 来自相关话题

大数据前几年各种概念争论很多,NoSQL/NewSQL,CAP/BASE概念一堆堆的,现在这股热潮被AI接过去了。大数据真正落地到车联网,分控,各种数据分析等等具体场景。

概念很高大上,搞得久了就会发现,大部分都还是数据仓库的衍伸,所以我们称呼这个为“新数仓”,我准备写一系列相关的文章,有没有同学愿意一起来的?请联系我。

本文简单梳理下其中一个应用比较广的HBASE的生态,可能不全,有更多的请大家留言。具体HBASE的基本原理扫描大家可以自行百度下,另外,要系统掌握HBASE,推荐看下《HBASE权威指南》。

1 Kerberos

什么是Kerberos?
Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography.

简单地说,Kerberos是一种认证机制,通过密钥系统为客户端/服务器应用程序提供强大的认证服务。

Kerberos存在的意义

在Hadoop1.0.0或者CDH3 版本之前,并不存在安全认证一说。默认集群内所有的节点都是可靠的,值得信赖的。用户与HDFS或者M/R进行交互时并不需要进行验证。导致存在恶意用户伪装成真正的用户或者服务器入侵到hadoop集群上,恶意的提交作业,修改JobTracker状态,篡改HDFS上的数据,伪装成NameNode 或者TaskTracker接受任务等。尽管在版本0.16以后, HDFS增加了文件和目录的权限,但是并没有强认证的保障,这些权限只能对偶然的数据丢失起保护作用。恶意的用户可以轻易的伪装成其他用户来篡改权限,致使权限设置形同虚设,不能够对Hadoop集群起到安全保障。

在Hadoop1.0.0或者CDH3版本后,加入了Kerberos认证机制。使得集群中的节点就是它们所宣称的,是信赖的。Kerberos可以将认证的密钥在集群部署时事先放到可靠的节点上。集群运行时,集群内的节点使用密钥得到认证。只有被认证过节点才能正常使用。企图冒充的节点由于没有事先得到的密钥信息,无法与集群内部的节点通信。防止了恶意的使用或篡改Hadoop集群的问题,确保了Hadoop集群的可靠安全。

Kerberos的工作原理


·       Client向KDC发送自己的身份信息,完成认证,获取TGT(ticket-granting ticket)

·       Client利用之前获得的TGT向KDC请求其他Service的Ticket,从而通过其他Service的身份鉴别

① Client将之前获得的TGT和要请求的服务信息发送给KDC

② KDC生成用于访问该服务的Session Ticket发给Client。 Session Ticket使用KDC与Service之间的密钥加密

③ Client将刚才收到的Ticket转发到Service。由于Client不知道KDC与Service之间的密钥,所以它无法篡改Ticket中的信息

④ Service 收到Ticket后利用它与KDC之间的密钥将Ticket中的信息解密出来,验证Client的身份。

2 Phoenix

Phoenix最早是saleforce的一个开源项目,后来成为Apache基金的顶级项目。

Phoenix是构建在HBase上的一个SQL层,能让我们用标准的JDBC APIs而不是HBase客户端APIs来创建表,插入数据和对HBase数据进行查询。

put the SQL back in NoSQL

Phoenix完全使用Java编写,作为HBase内嵌的JDBC驱动。Phoenix查询引擎会将SQL查询转换为一个或多个HBase扫描,并编排执行以生成标准的JDBC结果集。直接使用HBase API、协同处理器与自定义过滤器,对于简单查询来说,其性能量级是毫秒,对于百万级别的行数来说,其性能量级是秒。


HBase的查询工具有很多,如:Hive、Tez、Impala、Spark SQL、Phoenix等。


Phoenix通过以下方式使我们可以少写代码,并且性能比我们自己写代码更好:


·       将SQL编译成原生的HBase scans。

·       确定scan关键字的最佳开始和结束

·       让scan并行执行

·       ...


3 多维查询kylin

Apache Kylin™是一个开源的分布式分析引擎,提供Hadoop之上的SQL查询接口及多维分析(OLAP)能力以支持超大规模数据,最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。

Kylin相当于给HBASE提供了一个多为查询的SQL能力。


4 时序列数据库OpenTSDB

OpenTSDB ,可以认为是一个时系列数据(库),它基于HBase存储数据,充分发挥了HBase的分布式列存储特性,支持数百万每秒的读写,它的特点就是容易扩展,灵活的tag机制。

其最主要的部件就是TSD了,这是接收数据并存储到HBase处理的核心所在。而带有C(collector)标志的Server,则是数据采集源,将数据发给 TSD服务。


5 地理数据处理套件GeoMesa

GeoMesa 是由locationtech开源的一套地理大数据处理工具套件。其可在分布式计算系统上进行大规模的地理空间查询和分析。使用GeoMesa开源帮助用户管理、使用来自于物联网、社交媒体、手机应用的海量的时空(spatio-temporal)数据。

GeoMesa支持将海量的时空数据存储到Accumulo,HBase,Google Bigtable和Cassandra数据库中,并提供高效的索引来读取、查询这些数据。并支持通过指定空间条件(距离和范围)来快速查询。另外GeoMesa还基于Apache Kafka提供了时空数据的近实时流处理功能。

通过和GIS Server(GeoServer)的整合, GeoMesa 提供了通过标准OGC接口(WMS/WFS)访问数据的能力,通过这些接口,用户可以方便对GeoMesa处理的数据进行展示和分析,比如查询、直方图、时间序列分析等。


为什么选择GeoMesa

能够存储和处理海量时空数据

支持实时性强、需要快速读写的数据

支持spark分析

支持水平扩展

通过GeoServer提供地图服务,并支持Common Query Language (CQL)

项目地址

http://www.geomesa.org/


授权

GeoMesa使用Apache License Version 2.0协议。

http://apache.org/licenses/LICENSE-2.0.html


6 图数据库JanusGraph

Titan在停止更新了很长一段时间后,fork出了JanusGraph继续开源发展。JanusGraph是一个图形数据库引擎。JanusGraph本身专注于紧凑的图形序列化、丰富的图形数据建模和高效的查询执行。此外,JanusGraph利用Hadoop进行图形分析和批处理图处理。JanusGraph实现了健壮的模块化接口,用于数据持久性、数据索引和客户端访问。JanusGraph的模块化体系结构允许它与广泛的存储、索引和客户端技术进行互操作;它还简化了扩展JanusGraph以支持新用户的过程。

 在JanusGraph和磁盘之间,有一个或多个存储和索引适配器。JanusGraph以以下适配器为标准,但是JanusGraph的模块化体系结构支持第三方适配器

JanusGraph 体系结构

1、JanusGraph的应用分为批处理(OLAP)和流式计算(OLTP) 
2、批处理(OLAP),常用在大数据平台使用Spark、Giraph、Hadoop工具使用 
3、流式计算(OLTP),使用TinkerPop中的Traversal(遍历)工具使用 
4、数据可以存储到Cassandra、Hbase、BerkeleyDB中 
5、外部查询索引存储到ElasticSearch、Solr、Lucene中 


写在最后:本文主要简单总结下Hbase周边配合生态,提供SQL接口,多维查询能力,以及用于车联网,时序,地理数据处理等。后面持续写写新数仓相关文章,以飨读者。 查看全部
大数据前几年各种概念争论很多,NoSQL/NewSQL,CAP/BASE概念一堆堆的,现在这股热潮被AI接过去了。大数据真正落地到车联网,分控,各种数据分析等等具体场景。

概念很高大上,搞得久了就会发现,大部分都还是数据仓库的衍伸,所以我们称呼这个为“新数仓”,我准备写一系列相关的文章,有没有同学愿意一起来的?请联系我。

本文简单梳理下其中一个应用比较广的HBASE的生态,可能不全,有更多的请大家留言。具体HBASE的基本原理扫描大家可以自行百度下,另外,要系统掌握HBASE,推荐看下《HBASE权威指南》。

1 Kerberos

什么是Kerberos?
Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography.

简单地说,Kerberos是一种认证机制,通过密钥系统为客户端/服务器应用程序提供强大的认证服务。

Kerberos存在的意义

在Hadoop1.0.0或者CDH3 版本之前,并不存在安全认证一说。默认集群内所有的节点都是可靠的,值得信赖的。用户与HDFS或者M/R进行交互时并不需要进行验证。导致存在恶意用户伪装成真正的用户或者服务器入侵到hadoop集群上,恶意的提交作业,修改JobTracker状态,篡改HDFS上的数据,伪装成NameNode 或者TaskTracker接受任务等。尽管在版本0.16以后, HDFS增加了文件和目录的权限,但是并没有强认证的保障,这些权限只能对偶然的数据丢失起保护作用。恶意的用户可以轻易的伪装成其他用户来篡改权限,致使权限设置形同虚设,不能够对Hadoop集群起到安全保障。

在Hadoop1.0.0或者CDH3版本后,加入了Kerberos认证机制。使得集群中的节点就是它们所宣称的,是信赖的。Kerberos可以将认证的密钥在集群部署时事先放到可靠的节点上。集群运行时,集群内的节点使用密钥得到认证。只有被认证过节点才能正常使用。企图冒充的节点由于没有事先得到的密钥信息,无法与集群内部的节点通信。防止了恶意的使用或篡改Hadoop集群的问题,确保了Hadoop集群的可靠安全。

Kerberos的工作原理


·       Client向KDC发送自己的身份信息,完成认证,获取TGT(ticket-granting ticket)

·       Client利用之前获得的TGT向KDC请求其他Service的Ticket,从而通过其他Service的身份鉴别

① Client将之前获得的TGT和要请求的服务信息发送给KDC

② KDC生成用于访问该服务的Session Ticket发给Client。 Session Ticket使用KDC与Service之间的密钥加密

③ Client将刚才收到的Ticket转发到Service。由于Client不知道KDC与Service之间的密钥,所以它无法篡改Ticket中的信息

④ Service 收到Ticket后利用它与KDC之间的密钥将Ticket中的信息解密出来,验证Client的身份。

2 Phoenix

Phoenix最早是saleforce的一个开源项目,后来成为Apache基金的顶级项目。

Phoenix是构建在HBase上的一个SQL层,能让我们用标准的JDBC APIs而不是HBase客户端APIs来创建表,插入数据和对HBase数据进行查询。

put the SQL back in NoSQL

Phoenix完全使用Java编写,作为HBase内嵌的JDBC驱动。Phoenix查询引擎会将SQL查询转换为一个或多个HBase扫描,并编排执行以生成标准的JDBC结果集。直接使用HBase API、协同处理器与自定义过滤器,对于简单查询来说,其性能量级是毫秒,对于百万级别的行数来说,其性能量级是秒。


HBase的查询工具有很多,如:Hive、Tez、Impala、Spark SQL、Phoenix等。


Phoenix通过以下方式使我们可以少写代码,并且性能比我们自己写代码更好:


·       将SQL编译成原生的HBase scans。

·       确定scan关键字的最佳开始和结束

·       让scan并行执行

·       ...


3 多维查询kylin

Apache Kylin™是一个开源的分布式分析引擎,提供Hadoop之上的SQL查询接口及多维分析(OLAP)能力以支持超大规模数据,最初由eBay Inc. 开发并贡献至开源社区。它能在亚秒内查询巨大的Hive表。

Kylin相当于给HBASE提供了一个多为查询的SQL能力。


4 时序列数据库OpenTSDB

OpenTSDB ,可以认为是一个时系列数据(库),它基于HBase存储数据,充分发挥了HBase的分布式列存储特性,支持数百万每秒的读写,它的特点就是容易扩展,灵活的tag机制。

其最主要的部件就是TSD了,这是接收数据并存储到HBase处理的核心所在。而带有C(collector)标志的Server,则是数据采集源,将数据发给 TSD服务。


5 地理数据处理套件GeoMesa

GeoMesa 是由locationtech开源的一套地理大数据处理工具套件。其可在分布式计算系统上进行大规模的地理空间查询和分析。使用GeoMesa开源帮助用户管理、使用来自于物联网、社交媒体、手机应用的海量的时空(spatio-temporal)数据。

GeoMesa支持将海量的时空数据存储到Accumulo,HBase,Google Bigtable和Cassandra数据库中,并提供高效的索引来读取、查询这些数据。并支持通过指定空间条件(距离和范围)来快速查询。另外GeoMesa还基于Apache Kafka提供了时空数据的近实时流处理功能。

通过和GIS Server(GeoServer)的整合, GeoMesa 提供了通过标准OGC接口(WMS/WFS)访问数据的能力,通过这些接口,用户可以方便对GeoMesa处理的数据进行展示和分析,比如查询、直方图、时间序列分析等。


为什么选择GeoMesa

能够存储和处理海量时空数据

支持实时性强、需要快速读写的数据

支持spark分析

支持水平扩展

通过GeoServer提供地图服务,并支持Common Query Language (CQL)

项目地址

http://www.geomesa.org/


授权

GeoMesa使用Apache License Version 2.0协议。

http://apache.org/licenses/LICENSE-2.0.html


6 图数据库JanusGraph

Titan在停止更新了很长一段时间后,fork出了JanusGraph继续开源发展。JanusGraph是一个图形数据库引擎。JanusGraph本身专注于紧凑的图形序列化、丰富的图形数据建模和高效的查询执行。此外,JanusGraph利用Hadoop进行图形分析和批处理图处理。JanusGraph实现了健壮的模块化接口,用于数据持久性、数据索引和客户端访问。JanusGraph的模块化体系结构允许它与广泛的存储、索引和客户端技术进行互操作;它还简化了扩展JanusGraph以支持新用户的过程。

 在JanusGraph和磁盘之间,有一个或多个存储和索引适配器。JanusGraph以以下适配器为标准,但是JanusGraph的模块化体系结构支持第三方适配器

JanusGraph 体系结构

1、JanusGraph的应用分为批处理(OLAP)和流式计算(OLTP) 
2、批处理(OLAP),常用在大数据平台使用Spark、Giraph、Hadoop工具使用 
3、流式计算(OLTP),使用TinkerPop中的Traversal(遍历)工具使用 
4、数据可以存储到Cassandra、Hbase、BerkeleyDB中 
5、外部查询索引存储到ElasticSearch、Solr、Lucene中 


写在最后:本文主要简单总结下Hbase周边配合生态,提供SQL接口,多维查询能力,以及用于车联网,时序,地理数据处理等。后面持续写写新数仓相关文章,以飨读者。

新数仓系列:Hbase国内开发者生存现状(2)

hbasesuozai 发表了文章 • 0 个评论 • 267 次浏览 • 2018-02-07 21:40 • 来自相关话题

大数据前几年各种概念争论很多,NoSQL/NewSQL,CAP/BASE概念一堆堆的,现在这股热潮被AI接过去了。大数据真正落地到车联网,分控,各种数据分析等等具体场景。

概念很高大上,搞得久了就会发现,大部分都还是数据仓库的衍伸,所以我们称呼这个为“新数仓”,我准备写一系列相关的文章,有没有同学愿意一起来的?请联系我。


本文简单梳理下其中一个应用比较广的HBASE的国内开发者现状,可能不全,有更多信息或者纠正的,请给我留言。


一、  社区


1      国内commiter现状:

目前国内一共10个committer。4个在小米,4个在阿里,一个是小米前员工离职创业去了,一个在英特尔。小米历史上的5个committer,四个是在小米当选的,一个是在豌豆荚当committer后过来的 @张铎还成为国内第一个HBase PMC member。

阿里的话有国内第一个committer,这四个committer分别属于三个大部门。


消息来源:知乎上杨肉(HBase Committer)的回答,这个兄弟又从小米跳槽到一个AI创业公司了。

https://www.zhihu.com/question/27598510



2      和国外的互动
随着PMC、Committer的增多,也逐渐和社区互动起来,2017第一次举行HBaseCon Asia,华为主办的。

http://developer.51cto.com/art/201708/547605.htm


3      技术社区:
好像没有看到一个影响力比较大的统一技术社区,如果有更多信息的同学告诉我?

·  hbase-help:http://hbase-help.com/

·  csdn HBase资料库:http://lib.csdn.net/hbase/node/734



二、商业应用
 
4      各大公司的实践

阿里Hbase大牛封神整理的,具体链接: https://yq.aliyun.com/articles ... H0StL

基本围绕在用户画像、安全风控、订单存储、交通轨迹、物理网、监控、大数据中间存储、搜索、推荐等方面:

·         阿里巴巴-大数据时代的结构化存储HBase在阿里的应用实践:讲述在阿里巴巴集团的实践,HBase在阿里集团已经10000台左右,主要在订单、监控、风控、消息、大数据计算等领域使用

·         阿里巴巴搜索-Hbase在阿里巴巴搜索中的完美应用实践:讲述在搜索场景下hbase的应用及相关的改进

·         日均采集1200亿数据点,腾讯千亿级服务器监控数据存储实践:本文将从当前存储架构存在的问题出发,介绍从尝试使用 Opentsdb 到自行设计 Hbase 存储方案来存储 TMP 服务器海量监控数据的实践历程。

·         滴滴-HBase在滴滴出行的应用场景和最佳实践:统计结果、报表类数据、原始事实类数据、中间结果数据、线上系统的备份数据的一些应用

·         HBase在京东的实践 :跟阿里一样,京东各个业务线使用了HBase,如:风控、订单、商品评价等

·         中国人寿基于HBase的企业级大数据平台:使用一个大跨表存储所有的保单,HBase宽表的实践

·         HBase在Hulu的使用和实践:用户画像、订单存储系统、日志存储系统的使用

·         Apache HBase at Netease:在报表、监控、日志类业务、消息类业务、推荐类业务、风控类业务有所使用,另外讲述了一些优化的点。

·         10 Million Smart Meter Data with Apache HBase:讲述Hitachi为什么选择hbase及在HBase方面的应用

·         G7:如何用云计算链接30万车辆--EMR&Hbase 在物联网领域的实践及解决方案 讲述了怎么使用spark及hbase来满足物联网的需求


三 、云生态


5 国内典型云服务厂商

1)阿里云  云数据库 HBase 版

云数据库 HBase 版(ApsaraDB for HBase)是基于 Hadoop 且100%兼容HBase协议的高性能、可弹性伸缩、面向列的分布式数据库,轻松支持PB级大数据存储,满足千万级QPS高吞吐随机读写场景。


https://www.aliyun.com/product ... dRXId


2)华为云 表格存储服务 CloudTable表格存储服务(CloudTable Service)是华为云基于Apache HBase提供的分布式、可伸缩、全托管的KeyValue数据存储服务,它提供了高性能的随机读写能力,适用于海量结构化数据、半结构化数据以及时序数据的存储和查询应用

http://www.huaweicloud.com/product/cloudtable.html


3)腾讯云 列式数据库HBase

列式数据库HBase(Cloud HBase Service)是腾讯云基于全球广受欢迎的HBase打造的高性能、可伸缩、面向列的分布式存储系统,100%完全兼容HBase协议, 适用于写吞吐量大、海量数据存储以及分布式计算的场景,为您提供稳定丰富的集群管理,弹性可扩展的系统服务。https://cloud.tencent.com/product/HBase


6 国外典型云服务厂商

这项技术发源美国,所以AWS/Azure/Google技术实力较强。他们实现的都比开源猛!

1)AWS  Amazon DynamoDB

适用于任何规模的快速灵活的 NoSQL 数据库服务。

https://aws.amazon.com/cn/dynamodb/?nc2=h_m1


2)Azure 表存储

适用于使用大量半结构化数据集进行快速开发的 NoSQL 键-值存储

https://azure.microsoft.com/zh ... bles/

3)Google CLOUD BigTable&datastore

BigTableHBASE的始祖,开源Hbase就是抄这个。

一种用于处理大规模分析和运营工作负载的高性能 NoSQL 数据库服务


https://cloud.google.com/bigtable/


Google还在bigdata基础上提供了一个更强事务和SQL能力的datastore

https://cloud.google.com/datastore/


本文主要梳理下Hbase开发者现状,国内用户主要集中在互联网厂商,用户生态比postgresql/Mysql差一些。2016年是IoT爆发的元年,随着Hbase尤其适合的IoT应用的发展,Hbase有很大发展潜力。 查看全部
大数据前几年各种概念争论很多,NoSQL/NewSQL,CAP/BASE概念一堆堆的,现在这股热潮被AI接过去了。大数据真正落地到车联网,分控,各种数据分析等等具体场景。

概念很高大上,搞得久了就会发现,大部分都还是数据仓库的衍伸,所以我们称呼这个为“新数仓”,我准备写一系列相关的文章,有没有同学愿意一起来的?请联系我。


本文简单梳理下其中一个应用比较广的HBASE的国内开发者现状,可能不全,有更多信息或者纠正的,请给我留言。


一、  社区


1      国内commiter现状:

目前国内一共10个committer。4个在小米,4个在阿里,一个是小米前员工离职创业去了,一个在英特尔。小米历史上的5个committer,四个是在小米当选的,一个是在豌豆荚当committer后过来的 @张铎还成为国内第一个HBase PMC member。

阿里的话有国内第一个committer,这四个committer分别属于三个大部门。


消息来源:知乎上杨肉(HBase Committer)的回答,这个兄弟又从小米跳槽到一个AI创业公司了。

https://www.zhihu.com/question/27598510



2      和国外的互动
随着PMC、Committer的增多,也逐渐和社区互动起来,2017第一次举行HBaseCon Asia,华为主办的。

http://developer.51cto.com/art/201708/547605.htm


3      技术社区:
好像没有看到一个影响力比较大的统一技术社区,如果有更多信息的同学告诉我?

·  hbase-help:http://hbase-help.com/

·  csdn HBase资料库:http://lib.csdn.net/hbase/node/734



二、商业应用
 
4      各大公司的实践

阿里Hbase大牛封神整理的,具体链接: https://yq.aliyun.com/articles ... H0StL

基本围绕在用户画像、安全风控、订单存储、交通轨迹、物理网、监控、大数据中间存储、搜索、推荐等方面:

·         阿里巴巴-大数据时代的结构化存储HBase在阿里的应用实践:讲述在阿里巴巴集团的实践,HBase在阿里集团已经10000台左右,主要在订单、监控、风控、消息、大数据计算等领域使用

·         阿里巴巴搜索-Hbase在阿里巴巴搜索中的完美应用实践:讲述在搜索场景下hbase的应用及相关的改进

·         日均采集1200亿数据点,腾讯千亿级服务器监控数据存储实践:本文将从当前存储架构存在的问题出发,介绍从尝试使用 Opentsdb 到自行设计 Hbase 存储方案来存储 TMP 服务器海量监控数据的实践历程。

·         滴滴-HBase在滴滴出行的应用场景和最佳实践:统计结果、报表类数据、原始事实类数据、中间结果数据、线上系统的备份数据的一些应用

·         HBase在京东的实践 :跟阿里一样,京东各个业务线使用了HBase,如:风控、订单、商品评价等

·         中国人寿基于HBase的企业级大数据平台:使用一个大跨表存储所有的保单,HBase宽表的实践

·         HBase在Hulu的使用和实践:用户画像、订单存储系统、日志存储系统的使用

·         Apache HBase at Netease:在报表、监控、日志类业务、消息类业务、推荐类业务、风控类业务有所使用,另外讲述了一些优化的点。

·         10 Million Smart Meter Data with Apache HBase:讲述Hitachi为什么选择hbase及在HBase方面的应用

·         G7:如何用云计算链接30万车辆--EMR&Hbase 在物联网领域的实践及解决方案 讲述了怎么使用spark及hbase来满足物联网的需求


三 、云生态


5 国内典型云服务厂商

1)阿里云  云数据库 HBase 版

云数据库 HBase 版(ApsaraDB for HBase)是基于 Hadoop 且100%兼容HBase协议的高性能、可弹性伸缩、面向列的分布式数据库,轻松支持PB级大数据存储,满足千万级QPS高吞吐随机读写场景。


https://www.aliyun.com/product ... dRXId


2)华为云 表格存储服务 CloudTable表格存储服务(CloudTable Service)是华为云基于Apache HBase提供的分布式、可伸缩、全托管的KeyValue数据存储服务,它提供了高性能的随机读写能力,适用于海量结构化数据、半结构化数据以及时序数据的存储和查询应用

http://www.huaweicloud.com/product/cloudtable.html


3)腾讯云 列式数据库HBase

列式数据库HBase(Cloud HBase Service)是腾讯云基于全球广受欢迎的HBase打造的高性能、可伸缩、面向列的分布式存储系统,100%完全兼容HBase协议, 适用于写吞吐量大、海量数据存储以及分布式计算的场景,为您提供稳定丰富的集群管理,弹性可扩展的系统服务。https://cloud.tencent.com/product/HBase


6 国外典型云服务厂商

这项技术发源美国,所以AWS/Azure/Google技术实力较强。他们实现的都比开源猛!

1)AWS  Amazon DynamoDB

适用于任何规模的快速灵活的 NoSQL 数据库服务。

https://aws.amazon.com/cn/dynamodb/?nc2=h_m1


2)Azure 表存储

适用于使用大量半结构化数据集进行快速开发的 NoSQL 键-值存储

https://azure.microsoft.com/zh ... bles/

3)Google CLOUD BigTable&datastore

BigTableHBASE的始祖,开源Hbase就是抄这个。

一种用于处理大规模分析和运营工作负载的高性能 NoSQL 数据库服务


https://cloud.google.com/bigtable/


Google还在bigdata基础上提供了一个更强事务和SQL能力的datastore

https://cloud.google.com/datastore/


本文主要梳理下Hbase开发者现状,国内用户主要集中在互联网厂商,用户生态比postgresql/Mysql差一些。2016年是IoT爆发的元年,随着Hbase尤其适合的IoT应用的发展,Hbase有很大发展潜力。

学术界关于HBase在物联网/车联网/互联网/金融/高能物理等八大场景的理论研究

hbasehbase 发表了文章 • 0 个评论 • 309 次浏览 • 2018-02-07 13:43 • 来自相关话题

引言

 HBase在互联网领域有广泛的应用,比如:互联网的消息系统的存储、订单的存储、搜索原材料的存储、用户画像数据的存储等,除此之外,在其它领域也有非常多的应用。这得益于HBase海量的存储量及超高并发写入读取量。HBase在09年就开始在工业界大范围使用,在学术界,也有非常多的高校、机构在研究HBase应用于不同的行业,本文主要梳理下这些资料(主要是中文资料,有一些是硕士论文\期刊,便于广大读者阅读,特别选择了中文资料),很多都在工业界使用了。 由于涉及到版权,笔者提供链接,不提供资源下载,请大家见谅,可以自行搜索或者下载。感谢各位学者辛苦的研究,也论证了hbase技术在大规模存储的优势,在不同领域的应用场景。

HBase最主要的特性 
  HBase基于HDFS,可以提供廉价的解决方案。在阿里云ApsaraDB for HBase会发布基于D1、I2的物理机方案,存储成本为0.1元每GB每月左右,且可以在线动态添加节点,增加容量。 无需一次性投入全年的量。HBase容量可以无限扩容:在100T的数据量上毫无压力,在1P的数据量上也类似。HBase提供超高的并发量:主要得益于系统的除了Master之外的所有节点都直接跟客户端通信,且系统自动分区。有的系统会有一个路由中心,此会极大的限制并发量及流量,跟Spark、HadoopMR等分析系统结合
行业

物联网行业 & 车联网
基于HBase的海量GIS数据分布式处理实践:设计了一种基于分布式数据库HBase的GIS数据管理系统。系统优化了栅格数据的生成和存储过程,将海量栅格数据直接写入HBase存储、索引。同时,针对矢量空间数据的存储、索引与检索,提出了一种新的rowkey设计,既考虑经纬度,又考虑空间数据类型和属性,使得在按空间位置检索矢量地理信息时,能通过HBase的rowkey迅速定位需要返回的数据。在HBase的集群环境上用真实GIS数据对上述方法进行了验证,结果表明,提出的系统具有较高的海量数据存储和检索性能,实现了海量地理信息数据的高效存储和实时高速检索。基于 HBase的分布式空间数据库技术:针对在大型地理信息系统(GIS)中,需要对海量矢量数据和栅格数据进行存储并对高并发的用户查询请求提供高效响应,传统的设计方案难以满足需求的问题,提出一种使用基于内存存储的分布式数据库HBase存储空间数据,并设计基于GeoHash的分布式空间索引,实现了矢量空间数据与栅格空间数据的分布式存储与快速查询.实验表明,该方法提升了海量空间数据的查询速度基于HBase的大规模无线传感网络数据存储系统: 无线传感网络(WSN)存在分布的跨区域性,随着无线传感网络的扩张,传感器数目增多,将产生大规模的传感数据.针对存储大规模无线传感网络数据的问题,提出了一个两层分布式存储架构,使用分布式数据库HBase存储跨区域的无线传感网络数据和全局数据存储管理目录,实现一个近实时的存储系统.实验结果证明,该系统有良好的扩展性、存储和查询效率基于HBase的全天候全域出租车聚集实时监测方法:本发明为基于HBase的全天候全域出租车聚集实时监测方法,公开了一种车辆聚集监测方法。本发明首先将监测区域划分成网格,使用历史GPS数据计算出每个网格出租车数的最大值。然后,实时扫描GPS数据,按时刻截取一段时间的数据进行分析,循环扫描每一个网格,如果某个网格连续n个时刻都大于历史最大值,则观察这n个时刻的车数是否呈递增趋势,如果是则继续计算本时刻是否有一定数量的车和上一时刻相同,成立则说明该网格发生车辆聚集,否则扫描下一个网格。本发明利用出租车GPS数据实时监测每个区域,通过海量的历史出租车GPS和实时数据、HBase数据库、Spark计算框架、数据挖掘方法和最小二乘法构建出了一套快速、准确而有效的实时聚集监测方法基于HBase的车联网传感数据管理系统设计 :关系型数据库由于面向行存储以及无法扩展等原因,已很难满足大规模车联网传感数据的存储与查询要求.针对该问题,设计了一个基于非关系型数据库HBase存储的车联网传感数据管理系统.该系统采用Hadoop与HBase搭建分布式实验平台,采用C#语言开发Web网页端.通过与传统关系型数据库SQL Server的存储与查询效率进行对比分析,表明HBase在处理大规模车联网传感数据方面具有明显优势.
交通
面向海量交通数据的HBase时空索引:针对HBase无法直接建立时空索引所带来的交通数据查询性能问题,基于HBase行键设计了面向海量交通数据的HBase时空索引.首先利用Geohash降维方法将二维空间位置数据转化为一维编码,再与时间维度进行组合:然后根据组合顺序的不同,提出了四种结构模型,分别讨论了模型的具体构成以及交通数据查询中的适应面;最后提出了相应的时空索引管理算法及基于Hbase时空索引的交通数据查询方法.通过实验验证了提出的HBase时空索引结构能有效提升海量交通数据的区域查询性能,并比较了四种时空索引结构在不同数据规模、不同查询半径以及不同时间范围的查询性能,量化验证了不同索引结构在交通数据查询中的适应场景基于HBase的交通数据区域查询方法:随着智能交通的发展,交通数据呈现出指数性增长.为了提升时空区域查询性能,论文提出了一种基于HBase的交通数据区域查询方法HRQ.该方法利用交通数据的三维时空特性,采用Geohash算法将交通数据的经纬度信息转为Geohash编码,然后与时间组合作为HBase行键,并设计了相应的查询算法.实验结果表明,与直接组合经纬度和时间作为行键的方法相比,在基于时间范围的区域查询上HRQ方法的性能要高30%以上,在基于区域范围的区域查询上HRQ的性能优势随着查询区域的增大而增加基于HBase的交通流数据实时存储系统:交通流数据具有多来源、高速率、体量大等特征,传统数据存储方法和系统暴露出扩展性弱和存储实时性低等问题.针对上述问题,设计并实现了一套基于HBase交通流数据实时存储系统.该系统采用分布式存储架构,通过前端的预处理操作对数据进行规范化整理,利用多源缓冲区结构对不同类型的流数据进行队列划分,并结合一致性哈希算法、多线程技术、行键优化设计等策略将数据并行存储到HBase集群服务器中.实验结果表明:该系统与基于Oracle的实时存储系统相比,其存储性能提升了3~5倍;与原生的HBase方法相比,其存储性能提升了2~3倍,并且具有良好的扩展性能.基于HBase的交通卡口数据存储和查询系统研发:该系统采用分布式架构,前端摄像头传感器以Http协议方式将交通卡口数据发送给Flume分布式采集系统,采集系统对多源异构数据进行分类、聚合规范化整理,然后将不同类型的卡口数据传入到Kafka分布式消息队列中进行数据划分,数据划分中重写了Kafka原有的Partition类,从而更好的实现了卡口数据读取的实时性。Storm分布式实时计算系统从消息队列中获取卡口数据并且完成存储过程,最终将卡口数据写入到HBase集群服务器中。利用Phoenix-client作为HBase之上的Sql层,实现对HBase数据库查询。在保证系统高可靠、高可用的情况下,实现了卡口系统数据的快速写入和读取。
互联网
针对微博信息分析的HBase存储结构设计 :随着互联网的发展,微博对人们生活的影响日益加深。由于微博用户的激增,微博数据量已经非常庞大,且每时每刻都在急速增长。面对这种形势,传统数据库对于海量数据的处理效率已经难以满足需求,于是NoSQL数据库应运而生。文章采用的HBase是目前比较受欢迎的开源NoSQL之一。作为依赖于HDFS分布式存储架构的新型NoSQL数据库,HBase不仅能满足高效的结构化数据存储,并通过Mapreduce实现高效处理,还能存储非结构化数据,为海量数据提供相对灵活的信息存储管理。 基于 HBase 的互联网电视运营分析架构和模型设计:随着云时代的来临,互联网电视(OTT TV)业务吸引了越来越多的关注。新疆建设兵团所处地域辽阔,生产和生活的网络视频化的管理与服务的需求也日益明显。兵团的互联网电视业务在日常运营中会生成并累积大量的用户行为数据。由于不同类型的用户行为数据来自不同的数据平台,数据结构各异且数量庞大,从成本和性能方面考虑,传统的关系型数据库难以出色地完成用户行为分析。为此,本文介绍一种基于Hbase的互联网电视用户行为分析系统架构和模型设计,实现大规模异构行为数据的挖掘分析,为更好的运营兵团地域的互联网电视业务提供解决办法。
电力
 基于HBase的配用电海量时序数据存取研究:针对配用电海量时间序列数据,目前南方电网普遍采用关系型数据库进行存储,在技术上使用分库、分区、分表、联合索引等方式进行优化,灵活性、可扩展性、存储量等方面都存在问题.为满足配用电海量时间序列数据的存储要求,分析了关系型数据库优缺点,提出采用分布式数据库HBase构建电力系统数据中心以提高系统性能,并重点分析了HBase数据存储机制及实现方法,最后通过仿真实验进行对比.实验结果表明,基于HBase的配用电海量时间序列数据存取技术在存储及查询操作上具有较大的性能优势. HBase 在智能电网异构数据同步中的应用:未来的智能电网在运行中将会产生海量的多态、异构数据,对这些数据的可靠获取、实时分析、同步及处理会给电网信息系统带来前所未有的压力。因此,把电网大数据迁移到云端—数据中心,来实现异构数据的精准、实时同步则显得尤为必要。以解决未来智能电网大数据处理问题为出发点,通过对电网数据中心相关功能需求进行细致分析,对比传统的关系型数据库建模基础,提出了基于Hbase架构的智能电网数据中心的解决方案。最后通过对比 MySQL 性能进行模拟测试,得出所提出的设计方案能够很好地适用于未来智能电网数据中心的构建以及异构数据的同步,达到电网大数据的实时共享、监测及准确分析、处理的目的,在未来智能电网信息管理系统中具有广阔的应用前景。

 金融
 基于HBase的金融时序数据存储系统 : 设计并实现了1个基于HBase的金融时序数据的存储系统。设计了基于金融时序数据的HBase预分区策略,可解决HBase存储热点的问题;采用了行键优化策略和基于时序数据的表设计策略,可解决数据存储分散的问题;使用了提供异步处理机制的事件驱动的Netty框架所编写的中间件接收采集器发送的请求,可解决高并发事务的处理问题。实验结果表明,与HBase原生方法相比,该系统的性能在处理高并发事务时更好。

医疗
 基于HBase的海量DICOM医学影像存储系统的设计与研究:文章结合传统医学影像存储的不足和云计算的特点,提出了基于HBase的医学影像存储方案,结果表明基于HBase的DICOM影像数据库能有效解决传统PB级医学影像存储及医疗信息资源共享问题.  

航空
 基于HBase的民用航空发动机大数据管理系统: 为克服传统关系型数据库存储管理海量航空发动机状态监控数据的不足,本研究提出了基于HBase的民用航空发动机大数据管理系统.首先分析了该系统的功能需求,给出了系统整体架构与模块设计,并对关键技术进行了阐述.最后设计试验对比HBase与Oracle的搜索效率.试验结果表明检索结果集较大时HBase的搜索效率明显高于Oracle.本研究中提出的航空发动机大数据管理系统为发动机海量数据的存储管理提供了一种解决方案.
小文件存储(图片视频等)
 一种基于HBase的海量图片存储技术针对海量图片存储,已有若干个基于Hadoop的方案被设计出来.这些方案在系统层小文件合并、全局名字空间以及通用性方面存在不足.本文基于HBase提出了一种海量图片存储技术,成功解决了上述问题.本文将介绍基于HBase海量图片存储技术方案,分析其原理及优势,该方案在城市交通监控中得到应用验证.   基于 HBase 的小文件高效存储方法 :基于 Hadoop 平台的相关系统得到了广泛应用。Hadoop 分布式文件系统(Hadoop distributed file system, HDFS)通过分布式的工作方式,负责处理海量文件数据。对 HDFS 而言,海量数据中的小文件存储问题制约着系统高效工作的能力。针对海量数据中小文件读写效率低的情况,提出一种基于 HBase(Hadoop database)的海量小文件高效存储方法,利用 HBase 的存储优势,将小文件直接存储于 HBase,从而有效减少元数据节点服务器(Name-Node)的负载,并对上层应用系统提供透明的访问接口。实验结果表明,该方法可以实现海量小文件的高效存储,提高 HDFS 环境下小文件的读写效率。
高能物理
 高能物理大数据挑战与海量事例特征索引技术研究:一次大型实验即可产生万亿级的事例.传统高能物理数据处理以ROOT文件为基本存储和处理单位,每个ROOT文件可以包含数千至数亿个事例.这种基于文件的处理方式虽然降低了高能物理数据管理系统的开发难度,但物理分析仅对极少量的稀有事例感兴趣,这导致了数据传输量大、IO瓶颈以及数据处理效率低等问题.提出一种面向事例的高能物理数据管理方法,重点研究海量事例特征高效索引技术.

地理
 基于HBase的海量地形数据存储:随着遥感技术的发展,遥感数据的类型和量级发生了巨大变化,对于传统的存储方法产生了挑战.针对HBase中海量地形数据管理效率不高的问题,提出一种四叉树-Hilbert相结合的索引设计方法-基于HBase的矢量空间数据分布式存储研究:分析了分布式数据库HBase的存储模型;结合对HBase集群技术的研究,设计了基于HBase的矢量空间数据存储模型和一种基于MapReduce的并行构建网格空间索引方法,使得海量空间矢量数据的网格索引构建分配到各子节点进行,大大加快索引构建的处理速度;最后,利用HBase集群环境对所提出的方法进行验证,该方法具有较好的可行性和较高的效率.  

写在最后 
更多关于Hbase学术的论文参考:HBase应用 ,或者在 http://xueshu.baidu.com/ 搜索 hbase相关的论文,比如 hbase 传感器
  查看全部
引言

 HBase在互联网领域有广泛的应用,比如:互联网的消息系统的存储、订单的存储、搜索原材料的存储、用户画像数据的存储等,除此之外,在其它领域也有非常多的应用。这得益于HBase海量的存储量及超高并发写入读取量。HBase在09年就开始在工业界大范围使用,在学术界,也有非常多的高校、机构在研究HBase应用于不同的行业,本文主要梳理下这些资料(主要是中文资料,有一些是硕士论文\期刊,便于广大读者阅读,特别选择了中文资料),很多都在工业界使用了。 由于涉及到版权,笔者提供链接,不提供资源下载,请大家见谅,可以自行搜索或者下载。感谢各位学者辛苦的研究,也论证了hbase技术在大规模存储的优势,在不同领域的应用场景。

HBase最主要的特性 
  1.   HBase基于HDFS,可以提供廉价的解决方案。在阿里云ApsaraDB for HBase会发布基于D1、I2的物理机方案,存储成本为0.1元每GB每月左右,且可以在线动态添加节点,增加容量。 无需一次性投入全年的量。
  2. HBase容量可以无限扩容:在100T的数据量上毫无压力,在1P的数据量上也类似。
  3. HBase提供超高的并发量:主要得益于系统的除了Master之外的所有节点都直接跟客户端通信,且系统自动分区。有的系统会有一个路由中心,此会极大的限制并发量及流量,跟Spark、HadoopMR等分析系统结合

行业

物联网行业 & 车联网
  • 基于HBase的海量GIS数据分布式处理实践:设计了一种基于分布式数据库HBase的GIS数据管理系统。系统优化了栅格数据的生成和存储过程,将海量栅格数据直接写入HBase存储、索引。同时,针对矢量空间数据的存储、索引与检索,提出了一种新的rowkey设计,既考虑经纬度,又考虑空间数据类型和属性,使得在按空间位置检索矢量地理信息时,能通过HBase的rowkey迅速定位需要返回的数据。在HBase的集群环境上用真实GIS数据对上述方法进行了验证,结果表明,提出的系统具有较高的海量数据存储和检索性能,实现了海量地理信息数据的高效存储和实时高速检索。
  • 基于 HBase的分布式空间数据库技术:针对在大型地理信息系统(GIS)中,需要对海量矢量数据和栅格数据进行存储并对高并发的用户查询请求提供高效响应,传统的设计方案难以满足需求的问题,提出一种使用基于内存存储的分布式数据库HBase存储空间数据,并设计基于GeoHash的分布式空间索引,实现了矢量空间数据与栅格空间数据的分布式存储与快速查询.实验表明,该方法提升了海量空间数据的查询速度
  • 基于HBase的大规模无线传感网络数据存储系统: 无线传感网络(WSN)存在分布的跨区域性,随着无线传感网络的扩张,传感器数目增多,将产生大规模的传感数据.针对存储大规模无线传感网络数据的问题,提出了一个两层分布式存储架构,使用分布式数据库HBase存储跨区域的无线传感网络数据和全局数据存储管理目录,实现一个近实时的存储系统.实验结果证明,该系统有良好的扩展性、存储和查询效率
  • 基于HBase的全天候全域出租车聚集实时监测方法:本发明为基于HBase的全天候全域出租车聚集实时监测方法,公开了一种车辆聚集监测方法。本发明首先将监测区域划分成网格,使用历史GPS数据计算出每个网格出租车数的最大值。然后,实时扫描GPS数据,按时刻截取一段时间的数据进行分析,循环扫描每一个网格,如果某个网格连续n个时刻都大于历史最大值,则观察这n个时刻的车数是否呈递增趋势,如果是则继续计算本时刻是否有一定数量的车和上一时刻相同,成立则说明该网格发生车辆聚集,否则扫描下一个网格。本发明利用出租车GPS数据实时监测每个区域,通过海量的历史出租车GPS和实时数据、HBase数据库、Spark计算框架、数据挖掘方法和最小二乘法构建出了一套快速、准确而有效的实时聚集监测方法
  • 基于HBase的车联网传感数据管理系统设计 :关系型数据库由于面向行存储以及无法扩展等原因,已很难满足大规模车联网传感数据的存储与查询要求.针对该问题,设计了一个基于非关系型数据库HBase存储的车联网传感数据管理系统.该系统采用Hadoop与HBase搭建分布式实验平台,采用C#语言开发Web网页端.通过与传统关系型数据库SQL Server的存储与查询效率进行对比分析,表明HBase在处理大规模车联网传感数据方面具有明显优势.

交通
  • 面向海量交通数据的HBase时空索引:针对HBase无法直接建立时空索引所带来的交通数据查询性能问题,基于HBase行键设计了面向海量交通数据的HBase时空索引.首先利用Geohash降维方法将二维空间位置数据转化为一维编码,再与时间维度进行组合:然后根据组合顺序的不同,提出了四种结构模型,分别讨论了模型的具体构成以及交通数据查询中的适应面;最后提出了相应的时空索引管理算法及基于Hbase时空索引的交通数据查询方法.通过实验验证了提出的HBase时空索引结构能有效提升海量交通数据的区域查询性能,并比较了四种时空索引结构在不同数据规模、不同查询半径以及不同时间范围的查询性能,量化验证了不同索引结构在交通数据查询中的适应场景
  • 基于HBase的交通数据区域查询方法:随着智能交通的发展,交通数据呈现出指数性增长.为了提升时空区域查询性能,论文提出了一种基于HBase的交通数据区域查询方法HRQ.该方法利用交通数据的三维时空特性,采用Geohash算法将交通数据的经纬度信息转为Geohash编码,然后与时间组合作为HBase行键,并设计了相应的查询算法.实验结果表明,与直接组合经纬度和时间作为行键的方法相比,在基于时间范围的区域查询上HRQ方法的性能要高30%以上,在基于区域范围的区域查询上HRQ的性能优势随着查询区域的增大而增加
  • 基于HBase的交通流数据实时存储系统:交通流数据具有多来源、高速率、体量大等特征,传统数据存储方法和系统暴露出扩展性弱和存储实时性低等问题.针对上述问题,设计并实现了一套基于HBase交通流数据实时存储系统.该系统采用分布式存储架构,通过前端的预处理操作对数据进行规范化整理,利用多源缓冲区结构对不同类型的流数据进行队列划分,并结合一致性哈希算法、多线程技术、行键优化设计等策略将数据并行存储到HBase集群服务器中.实验结果表明:该系统与基于Oracle的实时存储系统相比,其存储性能提升了3~5倍;与原生的HBase方法相比,其存储性能提升了2~3倍,并且具有良好的扩展性能.
  • 基于HBase的交通卡口数据存储和查询系统研发:该系统采用分布式架构,前端摄像头传感器以Http协议方式将交通卡口数据发送给Flume分布式采集系统,采集系统对多源异构数据进行分类、聚合规范化整理,然后将不同类型的卡口数据传入到Kafka分布式消息队列中进行数据划分,数据划分中重写了Kafka原有的Partition类,从而更好的实现了卡口数据读取的实时性。Storm分布式实时计算系统从消息队列中获取卡口数据并且完成存储过程,最终将卡口数据写入到HBase集群服务器中。利用Phoenix-client作为HBase之上的Sql层,实现对HBase数据库查询。在保证系统高可靠、高可用的情况下,实现了卡口系统数据的快速写入和读取。

互联网
  • 针对微博信息分析的HBase存储结构设计 :随着互联网的发展,微博对人们生活的影响日益加深。由于微博用户的激增,微博数据量已经非常庞大,且每时每刻都在急速增长。面对这种形势,传统数据库对于海量数据的处理效率已经难以满足需求,于是NoSQL数据库应运而生。文章采用的HBase是目前比较受欢迎的开源NoSQL之一。作为依赖于HDFS分布式存储架构的新型NoSQL数据库,HBase不仅能满足高效的结构化数据存储,并通过Mapreduce实现高效处理,还能存储非结构化数据,为海量数据提供相对灵活的信息存储管理。
  •  基于 HBase 的互联网电视运营分析架构和模型设计:随着云时代的来临,互联网电视(OTT TV)业务吸引了越来越多的关注。新疆建设兵团所处地域辽阔,生产和生活的网络视频化的管理与服务的需求也日益明显。兵团的互联网电视业务在日常运营中会生成并累积大量的用户行为数据。由于不同类型的用户行为数据来自不同的数据平台,数据结构各异且数量庞大,从成本和性能方面考虑,传统的关系型数据库难以出色地完成用户行为分析。为此,本文介绍一种基于Hbase的互联网电视用户行为分析系统架构和模型设计,实现大规模异构行为数据的挖掘分析,为更好的运营兵团地域的互联网电视业务提供解决办法。

电力
  •  基于HBase的配用电海量时序数据存取研究:针对配用电海量时间序列数据,目前南方电网普遍采用关系型数据库进行存储,在技术上使用分库、分区、分表、联合索引等方式进行优化,灵活性、可扩展性、存储量等方面都存在问题.为满足配用电海量时间序列数据的存储要求,分析了关系型数据库优缺点,提出采用分布式数据库HBase构建电力系统数据中心以提高系统性能,并重点分析了HBase数据存储机制及实现方法,最后通过仿真实验进行对比.实验结果表明,基于HBase的配用电海量时间序列数据存取技术在存储及查询操作上具有较大的性能优势.
  •  HBase 在智能电网异构数据同步中的应用:未来的智能电网在运行中将会产生海量的多态、异构数据,对这些数据的可靠获取、实时分析、同步及处理会给电网信息系统带来前所未有的压力。因此,把电网大数据迁移到云端—数据中心,来实现异构数据的精准、实时同步则显得尤为必要。以解决未来智能电网大数据处理问题为出发点,通过对电网数据中心相关功能需求进行细致分析,对比传统的关系型数据库建模基础,提出了基于Hbase架构的智能电网数据中心的解决方案。最后通过对比 MySQL 性能进行模拟测试,得出所提出的设计方案能够很好地适用于未来智能电网数据中心的构建以及异构数据的同步,达到电网大数据的实时共享、监测及准确分析、处理的目的,在未来智能电网信息管理系统中具有广阔的应用前景。


 金融
  •  基于HBase的金融时序数据存储系统 : 设计并实现了1个基于HBase的金融时序数据的存储系统。设计了基于金融时序数据的HBase预分区策略,可解决HBase存储热点的问题;采用了行键优化策略和基于时序数据的表设计策略,可解决数据存储分散的问题;使用了提供异步处理机制的事件驱动的Netty框架所编写的中间件接收采集器发送的请求,可解决高并发事务的处理问题。实验结果表明,与HBase原生方法相比,该系统的性能在处理高并发事务时更好。


医疗


航空
  •  基于HBase的民用航空发动机大数据管理系统: 为克服传统关系型数据库存储管理海量航空发动机状态监控数据的不足,本研究提出了基于HBase的民用航空发动机大数据管理系统.首先分析了该系统的功能需求,给出了系统整体架构与模块设计,并对关键技术进行了阐述.最后设计试验对比HBase与Oracle的搜索效率.试验结果表明检索结果集较大时HBase的搜索效率明显高于Oracle.本研究中提出的航空发动机大数据管理系统为发动机海量数据的存储管理提供了一种解决方案.

小文件存储(图片视频等)
  •  一种基于HBase的海量图片存储技术针对海量图片存储,已有若干个基于Hadoop的方案被设计出来.这些方案在系统层小文件合并、全局名字空间以及通用性方面存在不足.本文基于HBase提出了一种海量图片存储技术,成功解决了上述问题.本文将介绍基于HBase海量图片存储技术方案,分析其原理及优势,该方案在城市交通监控中得到应用验证.  
  •  基于 HBase 的小文件高效存储方法 :基于 Hadoop 平台的相关系统得到了广泛应用。Hadoop 分布式文件系统(Hadoop distributed file system, HDFS)通过分布式的工作方式,负责处理海量文件数据。对 HDFS 而言,海量数据中的小文件存储问题制约着系统高效工作的能力。针对海量数据中小文件读写效率低的情况,提出一种基于 HBase(Hadoop database)的海量小文件高效存储方法,利用 HBase 的存储优势,将小文件直接存储于 HBase,从而有效减少元数据节点服务器(Name-Node)的负载,并对上层应用系统提供透明的访问接口。实验结果表明,该方法可以实现海量小文件的高效存储,提高 HDFS 环境下小文件的读写效率。

高能物理
  •  高能物理大数据挑战与海量事例特征索引技术研究:一次大型实验即可产生万亿级的事例.传统高能物理数据处理以ROOT文件为基本存储和处理单位,每个ROOT文件可以包含数千至数亿个事例.这种基于文件的处理方式虽然降低了高能物理数据管理系统的开发难度,但物理分析仅对极少量的稀有事例感兴趣,这导致了数据传输量大、IO瓶颈以及数据处理效率低等问题.提出一种面向事例的高能物理数据管理方法,重点研究海量事例特征高效索引技术.


地理
  •  基于HBase的海量地形数据存储:随着遥感技术的发展,遥感数据的类型和量级发生了巨大变化,对于传统的存储方法产生了挑战.针对HBase中海量地形数据管理效率不高的问题,提出一种四叉树-Hilbert相结合的索引设计方法
  • -基于HBase的矢量空间数据分布式存储研究:分析了分布式数据库HBase的存储模型;结合对HBase集群技术的研究,设计了基于HBase的矢量空间数据存储模型和一种基于MapReduce的并行构建网格空间索引方法,使得海量空间矢量数据的网格索引构建分配到各子节点进行,大大加快索引构建的处理速度;最后,利用HBase集群环境对所提出的方法进行验证,该方法具有较好的可行性和较高的效率.  


写在最后 
更多关于Hbase学术的论文参考:HBase应用 ,或者在 http://xueshu.baidu.com/ 搜索 hbase相关的论文,比如 hbase 传感器
 

中国HBase技术社区微信公众号:
hbasegroup

欢迎加入HBase生态+Spark社区钉钉大群