HBase Read Replicas功能介绍系列

hbasegroup 发表了文章 • 0 个评论 • 583 次浏览 • 2018-05-07 12:35 • 来自相关话题

1.概述
对于HBase read replicas模块打算有几篇文章组成一个系列,详细的介绍这个功能,大概分read replicas综述、正常情况下的读写流程分析、异常情况下的读写流程分析;
本文主要介绍的有:概述、读流程链路、写流程链路、如何使用read replicas,example。我们知道HBase是一个强一致的系统,最初是因为一个regionserver下负责的多个region的读写都是经历这个regionserver去做处理,这样的话,该regionserver是单点的做读写,不会存在数据不一致的问题。但是相应的该regionserver如果挂掉了,会造成该regionserver负责的region都不能提供服务。这个降低了整个流程的服务可用性。那么为了解决该问题,HBase引入了 Read Replicas的功能,也就是对于一个region在多个节点上都有对应的副本,HBase可以通过balance保证各个region的各个副本在不同的机器,机架上。我们给主region 一个数字为0的replica_id,其余的副本都可以叫做secondary regions,他们的对应replica_id 是1、2、…,所有的写请求都是replica_id为0的节点(regionserver)做处理,然后异步的发送到1、2、…等节点。有了这个功能HBase的读流程的可用性就由原来的3个9变成了4个9。当然有利也有弊,我们做设计就是在做tradeoff,引入这个功能的话,对系统读取数据的一致性有一点影响。不过这个主要看业务方可否接受,为了提高服务可用性,牺牲一点点数据一致性是否可以考虑。




2.读流程链路
在HBase进行Get的时候,构造的Get对象里面有一个Consistency的子项,默认是Consistency.STRONG,除此之外还有一个Consistency.TIMELINE的选项。我们文章涉及到的replicas主要和这个东西有关系。如果你希望让你的读操作具有更高的可用性,你就需要在Get对象进行一个设置,设置它的Consistency属性为TIMELINE。那么通过这个设置的话,读请求就先会去replica_id为0的主replica上面去读数据,如果在一定时间内,HBase client没有等到主的响应,那么就会并发的发送请求到备份的replicas,这个时间默认是10ms,可以通过在client端的配置文件里面设置hbase.client.primaryCallTimeout.get来配置。那么你可能就会问了,这个数据可能不是主上面的数据,可能是replica_id为1、2、等上面的数据,那么这个数据不就存在老数据的可能么?对!HBase 提供了一个接口用于判别数据是不是最新的,叫做isStale()。
但是如果用户使用的是Consistency.STRONG这种的话,就不会存在读到老数据的可能性。世上很难有完美的方案,那么怎么去做选择,就是需要业务基于自己的需求做一定的选择了。这个方案的有点是:提高了读服务的可用性,同样的会引入一些弊端,造成一定的内存开销以及网络开销,因为数据需要在replicas上进行存储,也存在请求到replicas上的可能性,那么就会增加网络开销;
3.写流程链路
上面概述里面提到我们需要把HBase的写的数据先经replica_id为0 的节点,然后异步分发到replicas上面去,那么分发的过程是异步的,不然存在影响整个写流程的体验。既然设计的是异步的,在HBase 里面存在2阶段不同的实现方案,分别是在HBase1.0+和HBase1.1+这2个大版本上面实现的;在HBase的官方分别叫做: StoreFile Refresher 和 Asnyc WAL replication。
3.1.StoreFile Refresher
这种机制就是一个regionserver上一个特定的线程,阶段性的将主replica上的store file 刷新到secondary replicas上面。开启这个功能的配置是在HBase的里面把hbase.regionserver.storefile.refresh.period进行一个配置,单位是毫秒级别的。通过设置这个,定时刷新线程会看到主上的memstore 的flush,以及compaction,bulck load 操作。那么对于内存里面的数据,可能就会在备份上面读不到。
3.2.Asnyc WAL replication
在HBase1.1+的版本里面新的一种数据被复制到secondary replicas的方式是:类似HBase replication,但是是单集群内部replicas之间的数据复制,由于主和secondary replicas之间的数据共享一份持久化数据,那么数据备份到replicas的时候是需要保证内存之间的数据是相同的。主在做写,compaction,bulkload等操作的时候会写数据到wal log,然后通过这个机制secondary replicas会观察到变化,然后讲数据在本地内存回放。
这个功能默认情况下是被关闭的,通过设置“hbase.region.replica.replication.enabled” 为true即可开启这个功能。
4.使用配置和使用步骤
如果要使用功能的话,分服务端和客户端,下面这份配置是服务端的:<property>
<name>hbase.regionserver.storefile.refresh.period</name>
<value>0</value>
<description>
这个值是secondary replicas,用来多久进行数据更新的一个间隔,单位是毫秒;如果设置为0的话,表示这个功能被关闭,secondary regions 察觉到主region上的数据变化就会更新一遍文件列表。此外建议把HFile的ttl设置的比较大。
</description>
</property>

<property>
<name>hbase.regionserver.meta.storefile.refresh.period</name>
<value>300000</value>
<description>
这个配置主要用于把hbase:meta表的store file 在secondary regions上进行更新。0的话意味着关闭该功能。secondary regions上面可以观测到主上由于flush 以及compaction带来的文件更新。如果meta的replicas功能被开启了这个值建议不为0,单位是毫秒。
</description>
</property>

<property>
<name>hbase.region.replica.replication.enabled</name>
<value>true</value>
<description>
无论异步同步wal replication是否开启,如果开启,那么一个名为“region_replica_replication”的replicaion peer就会被创建,写的数据就会被复制到replicas上面。一旦被开启,需要关闭的话,同样需要关闭replication peer。
</description>
</property>
<property>
<name>hbase.region.replica.replication.memstore.enabled</name>
<value>true</value>
<description>
如果设置这个为false,replicas就不会收到主上memstore的更新。但是即使是设置诶true,你依旧可以关闭memstore的复制。这是表级别的,将表的“REGION_MEMSTORE_REPLICATION”属性设为false即可。如果设置的话secondary replicas将仅仅更新flush和bulkload的事件。
</description>
</property>
<property>
<name>hbase.master.hfilecleaner.ttl</name>
<value>3600000</value>
<description>
将store file 保留在archive 文件夹里面的时间,超过以后就删除。
</description>
</property>

<property>
<name>hbase.meta.replica.count</name>
<value>3</value>
<description>
meta表的replication个数,默认是1;
</description>
</property>


<property>
<name>hbase.region.replica.storefile.refresh.memstore.multiplier</name>
<value>4</value>
<description>
这是一个“store file 更新”的系数,如果rs 有内存压力,如果secondary replica的最大memstore 的大小比主memstore的最大的memstore还大这么多,那么secondary region将进行更新store file (refresher)。
</description>
</property>

<property>
<name>hbase.region.replica.wait.for.primary.flush</name>
<value>true</value>
<description>
是否等待检测一个全面主的刷新完成,然后开始在secondary上进行数据的服务。
</description>
</property>客户端上面的配置更新:<property>
<name>hbase.ipc.client.specificThreadForWriting</name>
<value>true</value>
<description>
是否开启中断RPC的线程。
</description>
</property>
<property>
<name>hbase.client.primaryCallTimeout.get</name>
<value>10000</value>
<description>
超过这个时间将并发发送请求给secondary replica,默认是10ms。
</description>
</property>
<property>
<name>hbase.client.primaryCallTimeout.multiget</name>
<value>10000</value>
<description>
也是类似上述的时间限制,但是对于multget操作而言。
</description>
</property>
<property>
<name>hbase.client.replicaCallTimeout.scan</name>
<value>1000000</value>
<description>
同样上述操作,但是默认的时间是1s;
</description>
</property>
<property>
<name>hbase.meta.replicas.use</name>
<value>true</value>
<description>
是否使用meta表的replica;
</description>
</property>新建一张具有region replica 的表:shell命令:create 'test', 'info', {REGION_REPLICATION => 3}java的api操作:HTableDescriptor htd = new HTableDescriptor(TableName.valueOf(“test”));
htd.setRegionReplication(3);
...
admin.createTable(htd);读取数据:shell命令:hbase(main):001:0> get 'test','row', {CONSISTENCY => "TIMELINE"}java的api操作:Get get = new Get(row);
get.setConsistency(Consistency.TIMELINE);
...
Result result = table.get(get);结束语
大家在工作学习中遇到HBase技术问题发布在HBase技术社区论坛http://hbase.group ,欢迎大家在上面提问留言。想了解更多HBase技术请关注HBase社区公众号(微信号:hbasegroup),扫描下面二维码关注,也欢迎大家积极投稿。




大家可以添加社区人员微信(微信号:HackerUncle或者u7758258f),进HBase技术社区微信群交流HBase技术栈。 查看全部
1.概述
对于HBase read replicas模块打算有几篇文章组成一个系列,详细的介绍这个功能,大概分read replicas综述、正常情况下的读写流程分析、异常情况下的读写流程分析;
本文主要介绍的有:概述、读流程链路、写流程链路、如何使用read replicas,example。我们知道HBase是一个强一致的系统,最初是因为一个regionserver下负责的多个region的读写都是经历这个regionserver去做处理,这样的话,该regionserver是单点的做读写,不会存在数据不一致的问题。但是相应的该regionserver如果挂掉了,会造成该regionserver负责的region都不能提供服务。这个降低了整个流程的服务可用性。那么为了解决该问题,HBase引入了 Read Replicas的功能,也就是对于一个region在多个节点上都有对应的副本,HBase可以通过balance保证各个region的各个副本在不同的机器,机架上。我们给主region 一个数字为0的replica_id,其余的副本都可以叫做secondary regions,他们的对应replica_id 是1、2、…,所有的写请求都是replica_id为0的节点(regionserver)做处理,然后异步的发送到1、2、…等节点。有了这个功能HBase的读流程的可用性就由原来的3个9变成了4个9。当然有利也有弊,我们做设计就是在做tradeoff,引入这个功能的话,对系统读取数据的一致性有一点影响。不过这个主要看业务方可否接受,为了提高服务可用性,牺牲一点点数据一致性是否可以考虑。
2.jpeg

2.读流程链路
在HBase进行Get的时候,构造的Get对象里面有一个Consistency的子项,默认是Consistency.STRONG,除此之外还有一个Consistency.TIMELINE的选项。我们文章涉及到的replicas主要和这个东西有关系。如果你希望让你的读操作具有更高的可用性,你就需要在Get对象进行一个设置,设置它的Consistency属性为TIMELINE。那么通过这个设置的话,读请求就先会去replica_id为0的主replica上面去读数据,如果在一定时间内,HBase client没有等到主的响应,那么就会并发的发送请求到备份的replicas,这个时间默认是10ms,可以通过在client端的配置文件里面设置hbase.client.primaryCallTimeout.get来配置。那么你可能就会问了,这个数据可能不是主上面的数据,可能是replica_id为1、2、等上面的数据,那么这个数据不就存在老数据的可能么?对!HBase 提供了一个接口用于判别数据是不是最新的,叫做isStale()。
但是如果用户使用的是Consistency.STRONG这种的话,就不会存在读到老数据的可能性。世上很难有完美的方案,那么怎么去做选择,就是需要业务基于自己的需求做一定的选择了。这个方案的有点是:提高了读服务的可用性,同样的会引入一些弊端,造成一定的内存开销以及网络开销,因为数据需要在replicas上进行存储,也存在请求到replicas上的可能性,那么就会增加网络开销;
3.写流程链路
上面概述里面提到我们需要把HBase的写的数据先经replica_id为0 的节点,然后异步分发到replicas上面去,那么分发的过程是异步的,不然存在影响整个写流程的体验。既然设计的是异步的,在HBase 里面存在2阶段不同的实现方案,分别是在HBase1.0+和HBase1.1+这2个大版本上面实现的;在HBase的官方分别叫做: StoreFile Refresher 和 Asnyc WAL replication。
3.1.StoreFile Refresher
这种机制就是一个regionserver上一个特定的线程,阶段性的将主replica上的store file 刷新到secondary replicas上面。开启这个功能的配置是在HBase的里面把hbase.regionserver.storefile.refresh.period进行一个配置,单位是毫秒级别的。通过设置这个,定时刷新线程会看到主上的memstore 的flush,以及compaction,bulck load 操作。那么对于内存里面的数据,可能就会在备份上面读不到。
3.2.Asnyc WAL replication
在HBase1.1+的版本里面新的一种数据被复制到secondary replicas的方式是:类似HBase replication,但是是单集群内部replicas之间的数据复制,由于主和secondary replicas之间的数据共享一份持久化数据,那么数据备份到replicas的时候是需要保证内存之间的数据是相同的。主在做写,compaction,bulkload等操作的时候会写数据到wal log,然后通过这个机制secondary replicas会观察到变化,然后讲数据在本地内存回放。
这个功能默认情况下是被关闭的,通过设置“hbase.region.replica.replication.enabled” 为true即可开启这个功能。
4.使用配置和使用步骤
如果要使用功能的话,分服务端和客户端,下面这份配置是服务端的:
<property>
<name>hbase.regionserver.storefile.refresh.period</name>
<value>0</value>
<description>
这个值是secondary replicas,用来多久进行数据更新的一个间隔,单位是毫秒;如果设置为0的话,表示这个功能被关闭,secondary regions 察觉到主region上的数据变化就会更新一遍文件列表。此外建议把HFile的ttl设置的比较大。
</description>
</property>

<property>
<name>hbase.regionserver.meta.storefile.refresh.period</name>
<value>300000</value>
<description>
这个配置主要用于把hbase:meta表的store file 在secondary regions上进行更新。0的话意味着关闭该功能。secondary regions上面可以观测到主上由于flush 以及compaction带来的文件更新。如果meta的replicas功能被开启了这个值建议不为0,单位是毫秒。
</description>
</property>

<property>
<name>hbase.region.replica.replication.enabled</name>
<value>true</value>
<description>
无论异步同步wal replication是否开启,如果开启,那么一个名为“region_replica_replication”的replicaion peer就会被创建,写的数据就会被复制到replicas上面。一旦被开启,需要关闭的话,同样需要关闭replication peer。
</description>
</property>
<property>
<name>hbase.region.replica.replication.memstore.enabled</name>
<value>true</value>
<description>
如果设置这个为false,replicas就不会收到主上memstore的更新。但是即使是设置诶true,你依旧可以关闭memstore的复制。这是表级别的,将表的“REGION_MEMSTORE_REPLICATION”属性设为false即可。如果设置的话secondary replicas将仅仅更新flush和bulkload的事件。
</description>
</property>
<property>
<name>hbase.master.hfilecleaner.ttl</name>
<value>3600000</value>
<description>
将store file 保留在archive 文件夹里面的时间,超过以后就删除。
</description>
</property>

<property>
<name>hbase.meta.replica.count</name>
<value>3</value>
<description>
meta表的replication个数,默认是1;
</description>
</property>


<property>
<name>hbase.region.replica.storefile.refresh.memstore.multiplier</name>
<value>4</value>
<description>
这是一个“store file 更新”的系数,如果rs 有内存压力,如果secondary replica的最大memstore 的大小比主memstore的最大的memstore还大这么多,那么secondary region将进行更新store file (refresher)。
</description>
</property>

<property>
<name>hbase.region.replica.wait.for.primary.flush</name>
<value>true</value>
<description>
是否等待检测一个全面主的刷新完成,然后开始在secondary上进行数据的服务。
</description>
</property>
客户端上面的配置更新:
<property>
<name>hbase.ipc.client.specificThreadForWriting</name>
<value>true</value>
<description>
是否开启中断RPC的线程。
</description>
</property>
<property>
<name>hbase.client.primaryCallTimeout.get</name>
<value>10000</value>
<description>
超过这个时间将并发发送请求给secondary replica,默认是10ms。
</description>
</property>
<property>
<name>hbase.client.primaryCallTimeout.multiget</name>
<value>10000</value>
<description>
也是类似上述的时间限制,但是对于multget操作而言。
</description>
</property>
<property>
<name>hbase.client.replicaCallTimeout.scan</name>
<value>1000000</value>
<description>
同样上述操作,但是默认的时间是1s;
</description>
</property>
<property>
<name>hbase.meta.replicas.use</name>
<value>true</value>
<description>
是否使用meta表的replica;
</description>
</property>
新建一张具有region replica 的表:shell命令:
create 'test', 'info', {REGION_REPLICATION => 3}
java的api操作:
HTableDescriptor htd = new HTableDescriptor(TableName.valueOf(“test”));
htd.setRegionReplication(3);
...
admin.createTable(htd);
读取数据:shell命令:
hbase(main):001:0> get 'test','row', {CONSISTENCY => "TIMELINE"}
java的api操作:
Get get = new Get(row);
get.setConsistency(Consistency.TIMELINE);
...
Result result = table.get(get);
结束语
大家在工作学习中遇到HBase技术问题发布在HBase技术社区论坛http://hbase.group ,欢迎大家在上面提问留言。想了解更多HBase技术请关注HBase社区公众号(微信号:hbasegroup),扫描下面二维码关注,也欢迎大家积极投稿。
1.jpg

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

Accordion:HBase一种内存压缩算法

hbasegroup 发表了文章 • 0 个评论 • 495 次浏览 • 2018-05-07 12:26 • 来自相关话题

现如今,人们对基于HBase的产品的读写速度要求越来越高。在理想情况下,人们希望HBase 可以在保证其可靠的持久存储的前提下能并拥有内存数据读写的速度。为此,在HBase2.0中引入Accordion算法。
Hbase RegionServer 负责将数据划分到多个Region中。RegionServer 内部(垂直)的可伸缩性能对于最终用户体验以及整个系统的利用率至关重要。Accordion 算法通过提高对RAM利用来提升RegionServer扩展性。这样就使得内存中可以存放更多数据,从而降低了对磁盘的读取频率(即降低了HBase中磁盘占用和写入方法,更多的读写RAM,降低了对于磁盘的IO访问)。在HBase2.0之前,这些指标是不能同时满足的,并且相互限制,在引入Accordion之后,这一状况得到了改善。
According算法来源于HBase核心架构LSM算法。在HBase Region 中,数据是按照key-value形式映射为可查找的存放,其中put进来的新数据以及一些topmost(靠前)数据存放在内存中(MemStore),其余的为不变的HDFS文件,即HFile。当MemStore写满时,数据被flush到硬盘里,生成新的HFile文件。HBase采用多版本并发控制,MemStore将所有修改后的数据存储为独立版本。一条数据的多个版本可能同时存储在MemStore和HFile中。当读取一条多版本数据时,根据key从Hbas扫描BlockCache中的HFile获取最新的版本数据。为了降低对磁盘的访问频率,HFiles在后台合(即压缩过程,删除多余的cells,创建更大的文件)。
LSM通过将随机读写转换为顺序读写,从而提高了写入性能。之前的设计并未采用压缩内存数据,主要原因是在LSM树设计当初,RAM还是非常紧缺的资源,因此MemStore的容量很小。随着硬件不断提升,RegionServer管理的整个MemStore可能为数千兆字节,这就为HBase优化留下了大量空间。
According算法重新将LSM应用于MemStore,以便当数据仍在RAM中时可以消除冗余和其他开销。这样做可以减少flush到HDFS的频率,从而降低了写入放大和磁盘占用。 随着flush次数的减少,MemStore写入磁盘的频率会降低,进而提高HBase写入性能。磁盘上的数据较少也意味着对块缓存的压力较小,提高了读取的响应时间。最终,减少对磁盘写入也意味着在后台压缩次数降低,即读取和写入周期将缩短。总而言之,内存压缩算法的效果可以被看作是一个催化剂,它使整个系统的运行速度更快。
目前Accordion提供了两个级别的内存压缩:basic 级别和 eager 级别。前者适用于所有数据更新的优化,后者对于高数据流的应用非常有用,如生产-消费队列,购物车,共享计数器等。所有这些使用案例都会对rowkey进行频繁更新,生成多个冗余版本的数据,这些情况下Accordion算法将发挥其价值。但另一方面,eager 级压缩优化可能会增加计算开销(更多内存副本和垃圾收集),这可能会影响数据写入的响应时间。如果MemStore使用堆内MemStore-本地分配缓冲区(MSLAB),这会导致开销增大。所以建议不要将此配置与eager级压缩结合使用。
如何使用
内存压缩可以在全局和列族级别配置。目前支持三种级别配置:none(传统实现),basic和eager。
默认情况下,所有表都是basic内存压缩。此配置可以在hbase-site.xml中修改,如下所示:<property>
<name> hbase.hregion.compacting.memstore.type </name>
<value> <none|basic|eager> </value>
</property>也可在HBase shell中为每个列族进行单独配置,如下所示:create '<tablename>',{NAME =>'<cfname>',IN_MEMORY_COMPACTION =>' <NONE|BASIC|EAGER>' }性能提高
通过利用YCSB(Yahoo Cloud Service Benchmark)对HBase进行了全面测试。试验中采用数据集大小为100-200 GB,结果表明Accordion算法对于HBase性能有显著的提升。
Heavy-tailed (Zipf)分布:在测试负载中国,rowkey遵循大多数现实生活场景中出现的Zipf分布。在这种情况下,当100%的操作是写入操作时,Accordion实现写入放大率降低30%,写入吞吐量提高20%,GC降低22%。当50%的操作是读取时,tail读取延迟降低12%。
均匀分布:第二个测试中rowkey都均衡分布。当100%的操作是写入操作时,Accordion的写入放大率降低25%,写入吞吐量提高50%,GC降低36%。tail读取延迟不受影响(由于没有本地化)。
Accordion如何工作
High Level设计:
Accordion引入了MemStore的内部压缩(CompactingMemStore)实现方法。与默认的MemStore相比,Accordion将所有数据保存在一个整的数据结构中用segment来管理。最新的segment,称为active segment,是可变的,可用来接收Put操作,若active segment达到overflow条件(默认情况下32MB,MemStore的25%大小),它们将会被移到in-memory pipeline 中,并设为不可变segment,我们称这一过程为in-memory flush。Get操作通过扫描这些 segment和HFiles 取数据(后者操作通过块缓存进行访问,与平常访问HBase一样)。
CompactingMemStore 可能会不时在后台合并多个不可变segment,从而形成更大的segment。因此,pipeline是“会呼吸的”(扩张和收缩),类似于手风琴波纹管,所以我们也将Accordion 译为手风琴。
当RegionServer 刷入一个或多个MemStore到磁盘释放内存时,它会刷入 CompactingMemStore中已经移入pipeline中的segment到磁盘。基本原理是延长MemStore有效管理内存的生命周期,以减少整体I/O。当flush发生时,pipeline中所有的segment 段将被移出合成一个快照, 通过合并和流式传输形成新的HFile。图1展示了CompactingMemStore与传统设计的结构。




图1. CompactingMemStore与DefaultMemStore
Segment结构:
与默认的MemStore类似,CompactingMemStore在单元存储之上维护一个索引,这样可以通过key快速搜索。两者不同的是,MemStore索引实现是通过Java skiplist (ConcurrentSkipListMap--一种动态但奢侈的数据结构)管理大量小对象。CompactingMemStore 则在不可变的segment 索引之上实现了高效且节省空间的扁平化布局。这种优化可以帮助所有压缩策略减少RAM开销,甚至可以使数据几乎不存在冗余。当将一个Segment加入pipeline中,CompactingMemStore 就将其索引序列化为一个名为CellArrayMap 的有序数组,该数组可以快速进行二进制搜索。
CellArrayMap既支持从Java堆内直接分配单元,也支持MSLAB的自定义分配(堆内或堆外),实现差异通过被索引引用的KeyValue对象抽象出来(图2)。CellArrayMap本身始终分配在堆内。




图2.具有扁平CellArrayMap索引和MSLAB单元存储的不可变Segment
压缩算法:
内存中压缩算法在pipeline中的Segment上维护了一个单一的扁平化索引。这样的设计节省了存储空间,尤其是当数据项很小时,可以及时将数据刷入磁盘。单个索引可使搜索操作在单一空间进行,因此缩短了tail读取延迟。
当一个active segment被刷新到内存时,它将排列到压缩pipeline中,并会立即触发一个异步合并调度任务。该调度任务将同时扫描pipeline中的所有Segment(类似于磁盘上的压缩)并将它们的索引合并为一个。basic和eager 压缩策略之间的差异体现在它们处理单元数据的方式上。basic压缩不会消除冗余数据版本以避免物理复制,它只是重新排列KeyValue对象的引用。eager压缩则相反,它会过滤出冗余数据,但这是以额外的计算和数据迁移为代价的。例如,在MSLAB存储器中,surviving 单元被复制到新创建的MSLAB中。
未来的压缩可能会在basic压缩策略和eager压缩策略之间实现自动选择。例如,该算法可能会在一段时间内尝试eager压缩,并根据所传递的值(如:数据被删除的比例)安排下一次压缩。这种方法可以减轻系统管理员的先验决定,并适应不断变化的访问模式。
结束语
大家在工作学习中遇到HBase技术问题发布在HBase技术社区论坛http://hbase.group ,欢迎大家在上面提问留言。想了解更多HBase技术请关注HBase社区公众号(微信号:hbasegroup),扫描下面二维码关注,也欢迎大家积极投稿。




大家可以添加社区人员微信(微信号:HackerUncle或者u7758258f),进HBase技术社区微信群交流HBase技术栈。 查看全部
现如今,人们对基于HBase的产品的读写速度要求越来越高。在理想情况下,人们希望HBase 可以在保证其可靠的持久存储的前提下能并拥有内存数据读写的速度。为此,在HBase2.0中引入Accordion算法。
Hbase RegionServer 负责将数据划分到多个Region中。RegionServer 内部(垂直)的可伸缩性能对于最终用户体验以及整个系统的利用率至关重要。Accordion 算法通过提高对RAM利用来提升RegionServer扩展性。这样就使得内存中可以存放更多数据,从而降低了对磁盘的读取频率(即降低了HBase中磁盘占用和写入方法,更多的读写RAM,降低了对于磁盘的IO访问)。在HBase2.0之前,这些指标是不能同时满足的,并且相互限制,在引入Accordion之后,这一状况得到了改善。
According算法来源于HBase核心架构LSM算法。在HBase Region 中,数据是按照key-value形式映射为可查找的存放,其中put进来的新数据以及一些topmost(靠前)数据存放在内存中(MemStore),其余的为不变的HDFS文件,即HFile。当MemStore写满时,数据被flush到硬盘里,生成新的HFile文件。HBase采用多版本并发控制,MemStore将所有修改后的数据存储为独立版本。一条数据的多个版本可能同时存储在MemStore和HFile中。当读取一条多版本数据时,根据key从Hbas扫描BlockCache中的HFile获取最新的版本数据。为了降低对磁盘的访问频率,HFiles在后台合(即压缩过程,删除多余的cells,创建更大的文件)。
LSM通过将随机读写转换为顺序读写,从而提高了写入性能。之前的设计并未采用压缩内存数据,主要原因是在LSM树设计当初,RAM还是非常紧缺的资源,因此MemStore的容量很小。随着硬件不断提升,RegionServer管理的整个MemStore可能为数千兆字节,这就为HBase优化留下了大量空间。
According算法重新将LSM应用于MemStore,以便当数据仍在RAM中时可以消除冗余和其他开销。这样做可以减少flush到HDFS的频率,从而降低了写入放大和磁盘占用。 随着flush次数的减少,MemStore写入磁盘的频率会降低,进而提高HBase写入性能。磁盘上的数据较少也意味着对块缓存的压力较小,提高了读取的响应时间。最终,减少对磁盘写入也意味着在后台压缩次数降低,即读取和写入周期将缩短。总而言之,内存压缩算法的效果可以被看作是一个催化剂,它使整个系统的运行速度更快。
目前Accordion提供了两个级别的内存压缩:basic 级别和 eager 级别。前者适用于所有数据更新的优化,后者对于高数据流的应用非常有用,如生产-消费队列,购物车,共享计数器等。所有这些使用案例都会对rowkey进行频繁更新,生成多个冗余版本的数据,这些情况下Accordion算法将发挥其价值。但另一方面,eager 级压缩优化可能会增加计算开销(更多内存副本和垃圾收集),这可能会影响数据写入的响应时间。如果MemStore使用堆内MemStore-本地分配缓冲区(MSLAB),这会导致开销增大。所以建议不要将此配置与eager级压缩结合使用。
如何使用
内存压缩可以在全局和列族级别配置。目前支持三种级别配置:none(传统实现),basic和eager。
默认情况下,所有表都是basic内存压缩。此配置可以在hbase-site.xml中修改,如下所示:
<property>
<name> hbase.hregion.compacting.memstore.type </name>
<value> <none|basic|eager> </value>
</property>
也可在HBase shell中为每个列族进行单独配置,如下所示:
create '<tablename>',{NAME =>'<cfname>',IN_MEMORY_COMPACTION =>' <NONE|BASIC|EAGER>' }
性能提高
通过利用YCSB(Yahoo Cloud Service Benchmark)对HBase进行了全面测试。试验中采用数据集大小为100-200 GB,结果表明Accordion算法对于HBase性能有显著的提升。
Heavy-tailed (Zipf)分布:在测试负载中国,rowkey遵循大多数现实生活场景中出现的Zipf分布。在这种情况下,当100%的操作是写入操作时,Accordion实现写入放大率降低30%,写入吞吐量提高20%,GC降低22%。当50%的操作是读取时,tail读取延迟降低12%。
均匀分布:第二个测试中rowkey都均衡分布。当100%的操作是写入操作时,Accordion的写入放大率降低25%,写入吞吐量提高50%,GC降低36%。tail读取延迟不受影响(由于没有本地化)。
Accordion如何工作
High Level设计:
Accordion引入了MemStore的内部压缩(CompactingMemStore)实现方法。与默认的MemStore相比,Accordion将所有数据保存在一个整的数据结构中用segment来管理。最新的segment,称为active segment,是可变的,可用来接收Put操作,若active segment达到overflow条件(默认情况下32MB,MemStore的25%大小),它们将会被移到in-memory pipeline 中,并设为不可变segment,我们称这一过程为in-memory flush。Get操作通过扫描这些 segment和HFiles 取数据(后者操作通过块缓存进行访问,与平常访问HBase一样)。
CompactingMemStore 可能会不时在后台合并多个不可变segment,从而形成更大的segment。因此,pipeline是“会呼吸的”(扩张和收缩),类似于手风琴波纹管,所以我们也将Accordion 译为手风琴。
当RegionServer 刷入一个或多个MemStore到磁盘释放内存时,它会刷入 CompactingMemStore中已经移入pipeline中的segment到磁盘。基本原理是延长MemStore有效管理内存的生命周期,以减少整体I/O。当flush发生时,pipeline中所有的segment 段将被移出合成一个快照, 通过合并和流式传输形成新的HFile。图1展示了CompactingMemStore与传统设计的结构。
2.png

图1. CompactingMemStore与DefaultMemStore
Segment结构:
与默认的MemStore类似,CompactingMemStore在单元存储之上维护一个索引,这样可以通过key快速搜索。两者不同的是,MemStore索引实现是通过Java skiplist (ConcurrentSkipListMap--一种动态但奢侈的数据结构)管理大量小对象。CompactingMemStore 则在不可变的segment 索引之上实现了高效且节省空间的扁平化布局。这种优化可以帮助所有压缩策略减少RAM开销,甚至可以使数据几乎不存在冗余。当将一个Segment加入pipeline中,CompactingMemStore 就将其索引序列化为一个名为CellArrayMap 的有序数组,该数组可以快速进行二进制搜索。
CellArrayMap既支持从Java堆内直接分配单元,也支持MSLAB的自定义分配(堆内或堆外),实现差异通过被索引引用的KeyValue对象抽象出来(图2)。CellArrayMap本身始终分配在堆内。
3.png

图2.具有扁平CellArrayMap索引和MSLAB单元存储的不可变Segment
压缩算法:
内存中压缩算法在pipeline中的Segment上维护了一个单一的扁平化索引。这样的设计节省了存储空间,尤其是当数据项很小时,可以及时将数据刷入磁盘。单个索引可使搜索操作在单一空间进行,因此缩短了tail读取延迟。
当一个active segment被刷新到内存时,它将排列到压缩pipeline中,并会立即触发一个异步合并调度任务。该调度任务将同时扫描pipeline中的所有Segment(类似于磁盘上的压缩)并将它们的索引合并为一个。basic和eager 压缩策略之间的差异体现在它们处理单元数据的方式上。basic压缩不会消除冗余数据版本以避免物理复制,它只是重新排列KeyValue对象的引用。eager压缩则相反,它会过滤出冗余数据,但这是以额外的计算和数据迁移为代价的。例如,在MSLAB存储器中,surviving 单元被复制到新创建的MSLAB中。
未来的压缩可能会在basic压缩策略和eager压缩策略之间实现自动选择。例如,该算法可能会在一段时间内尝试eager压缩,并根据所传递的值(如:数据被删除的比例)安排下一次压缩。这种方法可以减轻系统管理员的先验决定,并适应不断变化的访问模式。
结束语
大家在工作学习中遇到HBase技术问题发布在HBase技术社区论坛http://hbase.group ,欢迎大家在上面提问留言。想了解更多HBase技术请关注HBase社区公众号(微信号:hbasegroup),扫描下面二维码关注,也欢迎大家积极投稿。
1.jpg

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

HBase运维基础——元数据逆向修复原理

hbasegroup 发表了文章 • 0 个评论 • 420 次浏览 • 2018-05-07 12:16 • 来自相关话题

背景
鉴于上次一篇文章——“云HBase小组成功抢救某公司自建HBase集群,挽救30+T数据”的读者反馈,对HBase的逆向工程比较感兴趣,并咨询如何使用相应工具进行运维等等。总的来说,就是想更深层理解HBase运维原理,提高运维HBase生产环境的能力,应对各种常见异常现象。不同的读者对hbase的了解程度不同,本文不打算着重编写一个工具怎么使用,而是从HBase的运维基础知识介绍开始讲解。为了能帮助大部分读者提高HBase运维能力,后续会写个“HBase运维系列” 专题系列文章,欢迎大家关注社区公众号最新动态。
介绍
相信很多自建HBase的企业会经常碰到各种各样的hbase运维问题。比如使用HBase的时候,HBase写入一段时间后开始RegionServer节点开始挂掉,重启RegionServer发现启动很慢,很多region出现RTI问题,导致读写某个region的业务hang住了 。还有一些人的HBase集群多次运维尝试后,直接HBase启动不了了,meta表上线就开始报错,导致最终业务不能正常上线运行等等系列问题。本文就HBase运维的原理基础开始入手,重点讲解数据完整性,以及元数据“逆向工程”恢复数据完整性的原理方法。开启后续一系列的HBase运维知识讲解。
HBase目录结构
本文就1.x版本进行讲解,不同版本大致相通。HBase在HDFS上会单独使用一个目录为HBase文件目录的根目录,通常为 “/hbase”。基于这个目录下,会有以下目录组织结构:/hbase/archive (1)
/hbase/corrupt (2)
/hbase/data/default/TestTable/.tabledesc/.tableinfo.0000000001 (3)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/info/
2e58b3e274ba4d889408b05e526d4b7b (4)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/
recovered.edits/340.seqid (5)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.regioninfo (6)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.tmp (7)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.splits (8)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.merges (9)
/hbase/data/hbase/acl (10)
/hbase/data/hbase/meta (11)
/hbase/hbase.id (12)
/hbase/hbase.version (13)
/hbase/MasterProcWALs (14)
/hbase/oldWALs (15)
/hbase/.tmp (16)
/hbase/.trashtables/data (17)
/hbase/WALs/tins-donot-rm-test-hb1-004.hbase.9b78df04-b.rds.aliyuncs.com,16020,1523502350378/tins-donot-rm-test-hb1-004.hbase.9b78df04-b.rds.aliyuncs.com%2C16020%2C1523502350378.default.1524538284034 (18)(1) 进行snapshot或者升级的时候使用到的归档目录。compaction删除hfile的时  候,也会把就的hfile归档到这里等。
(2) splitlog的corrupt目录,以及corrupt hfile的目录。
(3) 表的基本属性信息元文件tableinfo。
(4) 对应表下的hfile数据文件。
(5) 当splitlog发生时,一个RS的wal会按照region级别split WALs写到对应目录下的的recovered.edits目录上,使得此region再次被open的时候,回放这些recovered.edits 日志。
(6) regioninfo文件。
(7) compaction等的临时tmp目录。
(8) split时临时目录,如果上次region的split没有完成被中断了,这个region再open的时候会自动清理这个目录,一般不需要人工干预。
(9) merges时的临时目录,和split一样,如果没有正常完成的时候被中断了,那么他会在下次被open的时候自动清理。一般也不需要人工干预。
(10) acl 开启HBase权限控制时的权限记录系统表。
(11) meta 元数据表,记录region相关信息。
(12) hbase.id 集群启动初始化的时候,创建的集群唯一id。可以重新fix生成。
(13) hbase.version hbase 软件版本文件,代码静态版本,现在都是8。
(14) master执行过程程序的状态保存,用于中断恢复执行使用。
(15) oldWALs 历史wal,即wal记录的数据已经确认持久化了,那么这些wal就会被移到这里。splitlog完成的那些就日志,也会被放到这里。
(16) tmp 临时辅助目录,比如写一个hbase.id文件,在这里写成功后,rename到 /hbase/hbase.id。
(17) /hbase/.trashtables/data 当truncate table或者delete table的时候,这些数据会临时放在这里,默认1小时内被清。
(18) 记录着一台RegionServer上的WAL日志文件。可以看到它是regionserver名字是有时间的,即下一次启动时RS的wal目录就会使用新的目录结构存放wal,这个旧的RS wal 目录就会被splitlog过程拆分回放。
HBase涉及的主要文件及用途
HDFS静态文件,HDFS上的HBase 数据完整性
1. hfile文件:数据文件,目前最高版本也是默认常用版本为 3。 hfile文件结构细节可以参考官网http://hbase.apache.org/book.html#_hfile_format_2。我们这里逆向生成元数据主要使用到了HFile fileinfo的firstkey、lastkey信息。
2. hfilelink文件: 在hbase snapshot时用到, migration upgrade 也会使用到。很少碰到这类文件的运维问题,这里不作过多介绍。
3. reference文件:用来指定half hfile,一个region有reference时,这个region不能split。split/merge会创建这个。进行compaction后生成新的hfile后,会把这个reference删除。hfile的reference文件名格式一般是 hfile.parentEncRegion。如:/hbase/data/default/table/region-one/family/hfilename。其region-two有reference hfile文件名格式为:/hbase/data/default/table/region-two/family/hfile.region-one 通常无效引用就是 region-one的hfile不存在了,那么这个引用就会失效。他的修复方法一般是把reference无效的引用移除。
4. ".regioninfo" 文件,保存着 endkey/offline标志/regionid/regionName/split标志/startkey/tablename等
5. tableinfo文件这类文件保存着 tableName/table属性信息/table级别config信息/family信息。其中family信息保存着 famliyName/famiy属性/famliy级别config信息等。
通常,table属性有:REGION_MEMSTORE_REPLICATION,PRIORITY,IS_ROOT_KEY等,一般这些属性默认也是根据配置的一样。family属性有:BLOCKSIZE,TTL,REPLICATION_SCOPE等,一般属性是根据配置使用默认的。
6. hbase:meta表数据内容格式
regionname, info:regioninfo, regioninfo的encodeValue值
regionname, info:seqnumDuringOpen, 序列号
regionname, info:server, region所在的server名
regionname, info:serverstartcode, regionserver 启动的timestamp
元数据逆向生成原理
上述介绍的数据文件中,HBase的主要的元数据主要由meta表、tableinfo、regioninfo构成。这里的逆向生成元数据指的是,根据数据hfile数据文件,反向生成regioninfo/tableinfo/meta表的过程。
1. 逆向生成tableinfo文件
case1. 通过从master进程内存中的tabledescritor cache 完整恢复tableinfo文件,此时恢复的tableinfo是完整的,和之前的完全一样。
case2. 当cache中没有加载过此表的tableinfo时,修复过程只能从表的目录结构list所有familyNames 来恢复tableinfo,这个时候只能得到的是列簇的名字,恢复tableinfo文件内容中,除了表名、列簇名一致,其他的属性均采用默认值。这个时候如果运维人员知道有什么属性是自定义进去的,那么就需要要手动再次添加进去。
2.  逆向生成regioninfo文件
hfile 中的fileinfo读取firstkey/lastkey 排好序,得到region下所有hfile的最大rowkey和最小rowkey,并根据tableinfo中的表名 完整恢复  regioninfo文件。主要这里只能恢复 表明/startkey/endkey,  其他属性如:offline标志,regionName,split标志,hashcode等均使用代码生成或者配置的默认值。
3. 逆向填充meta表行
regioninfo文件序列化,填入meta表 info:regioninfo 列,并同时写入默认的server,等它被再次open的时候,重新分配region到实际的regionserver上,并更新这里的数据行。
逆向工程除了上面的直接文件、数据内容修复外,还涉及到数据的完整性其他方面修复。一个表示由无穷小的rowkey到无穷大的rowkey范围组成,还可能会发生的问题如:region空洞、region重叠现象,如:




如果有region空洞的时候,就会使用他们的空洞边界作为startkey/endkey,再修复创建一个region目录及目录下的regioninfo文件。如果是region重叠,则会把重叠的region进行合并,取所有region的最大最小rowkey作为merge后新region的最大最小rowkey。
元数据工具修复
元数据的缺少或者完整性有问题,会影响系统运行,甚至集群直接不可用。最常见的如 meta表上线失败,region 上线open失败等。这里介绍两个工具,工具一: hbase hbck 在线修复完整性修复元数据信息,工具二:OfflineMetaRepair 离线重建 hbase:meta 元数据表。
在线hbck修复:
前提:HDFS fsck 确保 hbase跟目录下文件没有损坏丢失,如果有,则先进行corrupt block 移除。
步骤1. hbase hbck 检查输出所以ERROR信息,每个ERROR都会说明错误信息。
步骤2. hbase hbck -fixTableOrphones 先修复tableinfo缺失问题,根据内存cache或者hdfs table 目录结构,重新生成tableinfo文件。
步骤3. hbase hbck -fixHdfsOrphones 修复regioninfo缺失问题,根据region目录下的hfile重新生成regioninfo文件
步骤4. hbase hbck -fixHdfsOverlaps 修复region重叠问题,merge重叠的region为一个region目录,并从新生成一个regioninfo
步骤5. hbase hbck -fixHdfsHoles 修复region缺失,利用缺失的rowkey范围边界,生成新的region目录以及regioninfo填补这个空洞。
步骤6. hbase hbck -fixMeta 修复meta表信息,利用regioninfo信息,重新生成对应meta row填写到meta表中,并为其填写默认的分配regionserver
步骤7. hbase hbck -fixAssignment 把这些offline的region触发上线,当region开始重新open 上线的时候,会被重新分配到真实的RegionServer上 , 并更新meta表上对应的行信息。
离线OfflineMetaRepair重建:
前提:HDFS fsck 确保 hbase跟目录下文件没有损坏丢失,如果有,则先进行corrupt block 移除
步骤: 执行 hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair -fix
最后,两个工具使用说明都比较详细,经过上面的基础介绍,相信都会看的懂的。这里不对工具再细致说明,工具的说明可以参考官网或者工具提示。题外话,有些开源组件设计的时候,向hbase元数据文件写入一些特有的信息,但是并没有修改到hbase工具的修复工具,或者它自己没有维护修复工具,如果这类文件损坏、丢失了,那么相应的组件就会运行不正常。使用这类组件的用户,应该不仅记录好你的表的基本结构,还要记录表的属性配置等,当发生修复运维行为的时候,主要再次核对确认。
结束语
本文介绍了运维hbase基础原理中的数据完整性以及逆向元数据修复原理,并举例介绍两个逆向修复元数据的工具和实用执行步骤。后续会出系列文章,说明更多hbase运维基础、运作原理等,希望对大家的运维和使用HBase有所帮助。欢迎更多意见和HBase技术交流。
大家在工作学习中遇到HBase技术问题发布在HBase技术社区论坛http://hbase.group ,欢迎大家在上面提问留言。想了解更多HBase技术请关注HBase社区公众号(微信号:hbasegroup),扫描下面二维码关注,也欢迎大家积极投稿。




大家可以添加社区人员微信(微信号:HackerUncle或者u7758258f),进HBase技术社区微信群交流HBase技术栈。 查看全部
背景
鉴于上次一篇文章——“云HBase小组成功抢救某公司自建HBase集群,挽救30+T数据”的读者反馈,对HBase的逆向工程比较感兴趣,并咨询如何使用相应工具进行运维等等。总的来说,就是想更深层理解HBase运维原理,提高运维HBase生产环境的能力,应对各种常见异常现象。不同的读者对hbase的了解程度不同,本文不打算着重编写一个工具怎么使用,而是从HBase的运维基础知识介绍开始讲解。为了能帮助大部分读者提高HBase运维能力,后续会写个“HBase运维系列” 专题系列文章,欢迎大家关注社区公众号最新动态。
介绍
相信很多自建HBase的企业会经常碰到各种各样的hbase运维问题。比如使用HBase的时候,HBase写入一段时间后开始RegionServer节点开始挂掉,重启RegionServer发现启动很慢,很多region出现RTI问题,导致读写某个region的业务hang住了 。还有一些人的HBase集群多次运维尝试后,直接HBase启动不了了,meta表上线就开始报错,导致最终业务不能正常上线运行等等系列问题。本文就HBase运维的原理基础开始入手,重点讲解数据完整性,以及元数据“逆向工程”恢复数据完整性的原理方法。开启后续一系列的HBase运维知识讲解。
HBase目录结构
本文就1.x版本进行讲解,不同版本大致相通。HBase在HDFS上会单独使用一个目录为HBase文件目录的根目录,通常为 “/hbase”。基于这个目录下,会有以下目录组织结构:
/hbase/archive (1)
/hbase/corrupt (2)
/hbase/data/default/TestTable/.tabledesc/.tableinfo.0000000001 (3)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/info/
2e58b3e274ba4d889408b05e526d4b7b (4)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/
recovered.edits/340.seqid (5)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.regioninfo (6)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.tmp (7)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.splits (8)
/hbase/data/default/TestTable/fc06f27a6c5bc2ff57ea38018b4dd399/.merges (9)
/hbase/data/hbase/acl (10)
/hbase/data/hbase/meta (11)
/hbase/hbase.id (12)
/hbase/hbase.version (13)
/hbase/MasterProcWALs (14)
/hbase/oldWALs (15)
/hbase/.tmp (16)
/hbase/.trashtables/data (17)
/hbase/WALs/tins-donot-rm-test-hb1-004.hbase.9b78df04-b.rds.aliyuncs.com,16020,1523502350378/tins-donot-rm-test-hb1-004.hbase.9b78df04-b.rds.aliyuncs.com%2C16020%2C1523502350378.default.1524538284034 (18)
(1) 进行snapshot或者升级的时候使用到的归档目录。compaction删除hfile的时  候,也会把就的hfile归档到这里等。
(2) splitlog的corrupt目录,以及corrupt hfile的目录。
(3) 表的基本属性信息元文件tableinfo。
(4) 对应表下的hfile数据文件。
(5) 当splitlog发生时,一个RS的wal会按照region级别split WALs写到对应目录下的的recovered.edits目录上,使得此region再次被open的时候,回放这些recovered.edits 日志。
(6) regioninfo文件。
(7) compaction等的临时tmp目录。
(8) split时临时目录,如果上次region的split没有完成被中断了,这个region再open的时候会自动清理这个目录,一般不需要人工干预。
(9) merges时的临时目录,和split一样,如果没有正常完成的时候被中断了,那么他会在下次被open的时候自动清理。一般也不需要人工干预。
(10) acl 开启HBase权限控制时的权限记录系统表。
(11) meta 元数据表,记录region相关信息。
(12) hbase.id 集群启动初始化的时候,创建的集群唯一id。可以重新fix生成。
(13) hbase.version hbase 软件版本文件,代码静态版本,现在都是8。
(14) master执行过程程序的状态保存,用于中断恢复执行使用。
(15) oldWALs 历史wal,即wal记录的数据已经确认持久化了,那么这些wal就会被移到这里。splitlog完成的那些就日志,也会被放到这里。
(16) tmp 临时辅助目录,比如写一个hbase.id文件,在这里写成功后,rename到 /hbase/hbase.id。
(17) /hbase/.trashtables/data 当truncate table或者delete table的时候,这些数据会临时放在这里,默认1小时内被清。
(18) 记录着一台RegionServer上的WAL日志文件。可以看到它是regionserver名字是有时间的,即下一次启动时RS的wal目录就会使用新的目录结构存放wal,这个旧的RS wal 目录就会被splitlog过程拆分回放。
HBase涉及的主要文件及用途
HDFS静态文件,HDFS上的HBase 数据完整性
1. hfile文件:数据文件,目前最高版本也是默认常用版本为 3。 hfile文件结构细节可以参考官网http://hbase.apache.org/book.html#_hfile_format_2。我们这里逆向生成元数据主要使用到了HFile fileinfo的firstkey、lastkey信息。
2. hfilelink文件: 在hbase snapshot时用到, migration upgrade 也会使用到。很少碰到这类文件的运维问题,这里不作过多介绍。
3. reference文件:用来指定half hfile,一个region有reference时,这个region不能split。split/merge会创建这个。进行compaction后生成新的hfile后,会把这个reference删除。hfile的reference文件名格式一般是 hfile.parentEncRegion。如:/hbase/data/default/table/region-one/family/hfilename。其region-two有reference hfile文件名格式为:/hbase/data/default/table/region-two/family/hfile.region-one 通常无效引用就是 region-one的hfile不存在了,那么这个引用就会失效。他的修复方法一般是把reference无效的引用移除。
4. ".regioninfo" 文件,保存着 endkey/offline标志/regionid/regionName/split标志/startkey/tablename等
5. tableinfo文件这类文件保存着 tableName/table属性信息/table级别config信息/family信息。其中family信息保存着 famliyName/famiy属性/famliy级别config信息等。
通常,table属性有:REGION_MEMSTORE_REPLICATION,PRIORITY,IS_ROOT_KEY等,一般这些属性默认也是根据配置的一样。family属性有:BLOCKSIZE,TTL,REPLICATION_SCOPE等,一般属性是根据配置使用默认的。
6. hbase:meta表数据内容格式
regionname, info:regioninfo, regioninfo的encodeValue值
regionname, info:seqnumDuringOpen, 序列号
regionname, info:server, region所在的server名
regionname, info:serverstartcode, regionserver 启动的timestamp
元数据逆向生成原理
上述介绍的数据文件中,HBase的主要的元数据主要由meta表、tableinfo、regioninfo构成。这里的逆向生成元数据指的是,根据数据hfile数据文件,反向生成regioninfo/tableinfo/meta表的过程。
1. 逆向生成tableinfo文件
case1. 通过从master进程内存中的tabledescritor cache 完整恢复tableinfo文件,此时恢复的tableinfo是完整的,和之前的完全一样。
case2. 当cache中没有加载过此表的tableinfo时,修复过程只能从表的目录结构list所有familyNames 来恢复tableinfo,这个时候只能得到的是列簇的名字,恢复tableinfo文件内容中,除了表名、列簇名一致,其他的属性均采用默认值。这个时候如果运维人员知道有什么属性是自定义进去的,那么就需要要手动再次添加进去。
2.  逆向生成regioninfo文件
hfile 中的fileinfo读取firstkey/lastkey 排好序,得到region下所有hfile的最大rowkey和最小rowkey,并根据tableinfo中的表名 完整恢复  regioninfo文件。主要这里只能恢复 表明/startkey/endkey,  其他属性如:offline标志,regionName,split标志,hashcode等均使用代码生成或者配置的默认值。
3. 逆向填充meta表行
regioninfo文件序列化,填入meta表 info:regioninfo 列,并同时写入默认的server,等它被再次open的时候,重新分配region到实际的regionserver上,并更新这里的数据行。
逆向工程除了上面的直接文件、数据内容修复外,还涉及到数据的完整性其他方面修复。一个表示由无穷小的rowkey到无穷大的rowkey范围组成,还可能会发生的问题如:region空洞、region重叠现象,如:
2.png

如果有region空洞的时候,就会使用他们的空洞边界作为startkey/endkey,再修复创建一个region目录及目录下的regioninfo文件。如果是region重叠,则会把重叠的region进行合并,取所有region的最大最小rowkey作为merge后新region的最大最小rowkey。
元数据工具修复
元数据的缺少或者完整性有问题,会影响系统运行,甚至集群直接不可用。最常见的如 meta表上线失败,region 上线open失败等。这里介绍两个工具,工具一: hbase hbck 在线修复完整性修复元数据信息,工具二:OfflineMetaRepair 离线重建 hbase:meta 元数据表。
在线hbck修复:
前提:HDFS fsck 确保 hbase跟目录下文件没有损坏丢失,如果有,则先进行corrupt block 移除。
步骤1. hbase hbck 检查输出所以ERROR信息,每个ERROR都会说明错误信息。
步骤2. hbase hbck -fixTableOrphones 先修复tableinfo缺失问题,根据内存cache或者hdfs table 目录结构,重新生成tableinfo文件。
步骤3. hbase hbck -fixHdfsOrphones 修复regioninfo缺失问题,根据region目录下的hfile重新生成regioninfo文件
步骤4. hbase hbck -fixHdfsOverlaps 修复region重叠问题,merge重叠的region为一个region目录,并从新生成一个regioninfo
步骤5. hbase hbck -fixHdfsHoles 修复region缺失,利用缺失的rowkey范围边界,生成新的region目录以及regioninfo填补这个空洞。
步骤6. hbase hbck -fixMeta 修复meta表信息,利用regioninfo信息,重新生成对应meta row填写到meta表中,并为其填写默认的分配regionserver
步骤7. hbase hbck -fixAssignment 把这些offline的region触发上线,当region开始重新open 上线的时候,会被重新分配到真实的RegionServer上 , 并更新meta表上对应的行信息。
离线OfflineMetaRepair重建:
前提:HDFS fsck 确保 hbase跟目录下文件没有损坏丢失,如果有,则先进行corrupt block 移除
步骤: 执行 hbase org.apache.hadoop.hbase.util.hbck.OfflineMetaRepair -fix
最后,两个工具使用说明都比较详细,经过上面的基础介绍,相信都会看的懂的。这里不对工具再细致说明,工具的说明可以参考官网或者工具提示。题外话,有些开源组件设计的时候,向hbase元数据文件写入一些特有的信息,但是并没有修改到hbase工具的修复工具,或者它自己没有维护修复工具,如果这类文件损坏、丢失了,那么相应的组件就会运行不正常。使用这类组件的用户,应该不仅记录好你的表的基本结构,还要记录表的属性配置等,当发生修复运维行为的时候,主要再次核对确认。
结束语
本文介绍了运维hbase基础原理中的数据完整性以及逆向元数据修复原理,并举例介绍两个逆向修复元数据的工具和实用执行步骤。后续会出系列文章,说明更多hbase运维基础、运作原理等,希望对大家的运维和使用HBase有所帮助。欢迎更多意见和HBase技术交流。
大家在工作学习中遇到HBase技术问题发布在HBase技术社区论坛http://hbase.group ,欢迎大家在上面提问留言。想了解更多HBase技术请关注HBase社区公众号(微信号:hbasegroup),扫描下面二维码关注,也欢迎大家积极投稿。
1.jpg

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

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

hbasegroup 发表了文章 • 0 个评论 • 600 次浏览 • 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 不定期超时

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

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

hbasegroup 发表了文章 • 1 个评论 • 855 次浏览 • 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修复数据如何使用权限?

回复

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

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

回复

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

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

回复

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

RegionTooBusyException: Above memstore limit

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

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

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

hbase的可用性怎么样?

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

Phoenix是否有集群概念?

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

单数RegionServer可以正常部署吗?

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

hbase2什么时候发布?

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

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

suozai 发表了文章 • 0 个评论 • 409 次浏览 • 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)

suozai 发表了文章 • 0 个评论 • 540 次浏览 • 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)

suozai 发表了文章 • 0 个评论 • 504 次浏览 • 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技术社区微信公众号:
hbasegroup

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