HBase in Practice-性能、监控及问题解决

hbase过往记忆 发表了文章 • 0 个评论 • 1012 次浏览 • 2018-08-01 09:38 • 来自相关话题

本文根据阿里李钰老师在中国HBase技术社区第二届MeetUp:“HBase技术解析及应用实践”中分享的《HBase in Practice-性能、监控及问题解决》编辑整理而成,在未改变原意的基础上稍做整理。




李钰老师



今天分享主要从两个大的部分介绍,第一部分会讲一些性能优化的知识,针对IO的性能优化,不同版本值得注意的性能问题/优化;第二部分将监控应该关注哪些指标以及在日志里面如何做问题排查。




首先讲一下针对IO性能优化,每个厂商IO硬件性能都不一样,针对不同的硬件,需要利用的功能和注意的问题也不一样。如HDD,它的IO能力比较弱,很容易打爆,如果在云上应用HBase,有很多不同的硬盘可以使用。在HDD架设HBase要避免磁盘被打爆,HBase提供了很多方法,第一个就是Compaction限流,基本思想就是限制它每秒能写出的数据量,在1.1.0版本以上才能使用,对于1.3.0版本分界线以上以下配置不同,具体配置如上图所示。你可以设置其吞吐 的上限和下限,也可以设置平峰期的限制。我们进行限流肯定一般是在高峰期,在平峰期没有必要,也或者平峰期你有没有其他的应用,有时也会跑一些其他的应用,如spark等。Flush限流是在1.3.0版本以上支持的,其实主要的IO来源就是Compaction和Flush,配置与Compaction比较像。值得注意的是限流不能过低,如果过低Compaction的Hfile数就降不下来,block stoken file默认值是20,如果超过20,flush就会delay,内存会膨胀,如果膨胀超过一定区域就会block update,会出现写入延迟阻塞。因此两者限流需要依据实际限流,不能限流过低。




另外一个在HDD上比较适合是Per-CF Flush,在1.1.0版本以上就支持,默认配置是flush all stores,当main Store的大小达到设定阀值,就会将所有的CF都flush出来。但是有些CF文件比较小,会出现浪费io,另外刷出很多小文件需要compaction,对磁盘也会有影响。因此出现了HBase available,在1.1.0版本以上可以用,从1.1.0-2.0实质是设置了一个下限,如果CF文件在main Store时超过16M就将其flush,没有超过就不flush。后续在社区基础上做了改变,将默认值改为flush大小除以CF的个数,这样的问题有可能出现CF过多,因此也会有下限值控制,也是16M。使用这个功能也需要注意,开启这个功能有很多数据是不flush,但是如果出现故障,replay的数据会变多,在HBase中有个参数optional flush internal,可以设置过多长时间强制flush一次,还有一个flush prechanges,就是有多少change就flush一次;一个默认值是1小时,后面是3千万。




第三个方案是多盘,多盘在社区1.0版本就有多log的功能。如果在自己的机器上,服务器都是12块硬盘,如果用一个write tacklog,HDFS是三个副本,虽然能将吞吐打满,三个副本需要三个盘,无法使用完,IO能力没充分利用。解决方式就是用多个write tacklog,一个region server配置4个hlog,测试性能会提升20%。版本低于1.2.0:replication存在问题, hbase.wal.provider ->multiwall,hbase.wal.regiongrouping.strategy -> bounded ,根据盘数设置hbase.wal.regiongrouping.numgroups。需要注意写多少Hlog是依据你的盘确定,IO能力是否充足。




SSD在HBase里面也有很好的支持,SSD对性能的优化分为两个部分,一方面是读,另一方面是写。影响写的性能就是write height log的写,SSD能很大的降低其响应时间,在用SSD时也可以用Multi WAL,其写入性能比单WAL提升40%以上。从读方面来说,在CF可以设置Storage Policy,但该功能在2.0版本上才有。对不同的CF设置不同的Storage Policy(wan SSD,all SSD),设置多CF的原因是数据的冷热程度是不一样的。Bulkload也需要支持Storage Policy配置,如果生成的文件都是HDD,会影响读取的性能。




SSD需要注意的是如果是Wan SSD需要允许HDFS client优先读远程SSD上的副本,但是未合入社区版本,需要手动backport。对于Hybrid,WAL策略可以是WAL SSD,对CF级别也可以是WAL SSD。值得注意的是SSD也需要开启限流。Merge MVCCand SequenceId引发的性能问题:branch-1.0不要使用1.0.3以下版本,branch-1.1不要使用1.1.3以下版本。高负载下写入性能瓶颈: 如果线上发现wait在WALKey#get Write Entry,建议升级到1.4.0以上版本,对ASYNC_WAL写入性能提升尤其明显 。在读的性能,如果用的是Bucket Cache,在高并发读取单key的性能问题,在1.2.0以上版本可以解决。如果远程读SSD,需要考虑网络开销,Hybrid开销尤其大。








接下来讲一下问题排查,首先是RPC相关监控:Server响应时间,Server处理时间,请求排队时间。Total Call Time记录的是请求到达你的regionServer开始到server请求完结束,不包含发送结果的时间。业务在请求,但是server处理也好,这种情况需要去业务debug客户端网络是不是拥塞。Total Call Time肯定是等于ProcessCall Time+QueueCall Time,请求到达server是先进入一个队列,如果heightlog不繁忙,QueueCall Time会很短,但是如果server很繁忙active handler数很满,calltime会很长,请求是从队列出来后处理。Active Handler 在1.4.0版本以前是没有读写分离监控的。读写分离的好处就是Handler打满到底是读出问题还是写出问题就可以很容易监控。RPC队列长度也可以判断机器是否出问题了,RPC连接数很高也是消耗系统资源。上图是我们监控指标图,如图一峰值就可以推测这台机器可能有点问题。

请求相关指标对debug很重要,Put请求latency,Get请求latency,Scan请求latency等这些都会监控。我想说明就是对latency监控,Hbase出问题到底是文件系统出问题了还是regionServer出问题了,这个困扰了我们很久,因为底层会有一个文件系统,文件系统过肯定会受影响,因次对于put来说你要监控WAL sync latency,对于get要监控HDFS pread latency,Scan请求latency。对于HDFS pread latency需要1.4.0版本以上。如果发现Get请求latency很高,HDFS pread latency也很高,那么基本确定HDFS陡了,至少可以定位问题。否则就必须定位999的regionserver一一排查。




第三个就是内存相关的指标,GC对于排查问题作用未必很大,但是可以监控整体情况。对于GC更多的是查GC日志更有效果,pause Time Without GC不是进程GC导致的问题时,在1.4.0版本以上会发现一些日志的,这个时候需要关注一些系统的指标,如内存整理,那么你整个系统会停止,或者资源瓶颈或者CPU满了都会导致进程堵塞。再一个就是对Block Cache/MemStore 的监控,如何监控Hfile数过多,一方面可以监控blockupdate的字符和频率,另一方面是看MemStore数是否变大了。Block Cache在1.3.0版本以上可以区分data和meta命中率,meta block命中率一般都很高,访问频率也很高,如果不区分这个命中率有可能是假的。真实的data block命中率在65%,但是meta命中率基本是100%。




RegionServer单机指标,如果看到一个regionserver打满了,需要看regionServer单机指标。如region大小,这个指标引起cache的命中率,get和写操作数,看topN那些请求非常高,handler打满,get时间非常高,可以查询那个region访问过多,有些情况是访问值超过正常值导致的,因此可以通过表找到问题去解决。再一个就是compaction队列长度和flush队列长度。

如何发现stale的Region Server,如果出现坏盘,请求卡在IO上一直无法返回,响应时间相关指标无法捕捉,在total call time中无法体现。还有就是你的数值很好但是机器已经出问题,因为出问题的请求没有汇报给server,另外如果机器资源耗尽,新的请求无法连接server,从响应时间等server metrics上也体现不出来。因此做了一个增强health check,定期向自己发请求并设置超时时间,失败超过一定概率报警,有一个问题就是还没有Upstreaming in progress,但后续会完成。其实会出现一个情况就是系统资源耗尽,但是已经启动的线程可以运行,但是无法启动新的线程,就是一台机器已经不能服务,但是master还是可以服务。




接下来讲一下日志的排查,首先关于慢请求。如发现一个server的999时间很长,第一反应是登陆该台regionServer查看日志,尤其是responsetooslow日志,但是老版本是不会打印任何有关processingtime 、roll具体信息的,因此会关注这两个HBASE-16033/HBASE-16972 response Too Slow,会打印详细信息,前面一个jQuery是对普通请求,后面一个jQuery是对scan。经常会看到scan超时等这些信息都是很重要的。branch-1.1要求1.1.8以上,branch-1.2要求1.2.5以上,或1.3.0以上版本。在自己的版本还做了一些事情,但是还未放到社区,会区分如果是慢请求,到底long process time还是long call Time,因为一个long process time会导致一系列的long call Time。如果不区分会看到很多response TooSlow,但是你并不知道出现的问题是什么。当然还需要设置阈值,超过多长时间才算慢请求,我们是超过10秒才算慢请求,这个可以自己配置。如设置10秒其实8秒也不短,这时需要去region Server上解scandetail,去查看handler线程wait在什么地方,wait的地方出现了多少。




在Client端也有些日志也是非常重要的,对于single请求打印很全,但是要注意batch,branch-1.1要求1.1.6以上,branch-1.2要求1.2.3以上,或1.3.0以上版本。在有慢请求时,去打印具体是哪个region,还有目前运行在哪个server上,或者在batch请求异常时打印异常的batch栈。客户端还有其他好的机制,HBase客户端是由backoff policy,就是通过regionServer的region load判断是否需要sleep一段时间。后续有机会可以讨论如何排查GC、内存泄漏等复杂问题,如何定位疯狂访问RS的问题客户端应用,如何规避HDFS故障对HBase的影响,2.0黑科技在线上应用可能踩的坑,升级HBase版本有哪些必须的准备以及线上升级操作有哪些注意事项。




  查看全部
1.jpg
本文根据阿里李钰老师在中国HBase技术社区第二届MeetUp:“HBase技术解析及应用实践”中分享的《HBase in Practice-性能、监控及问题解决》编辑整理而成,在未改变原意的基础上稍做整理。
2.jpg

李钰老师
3.png
今天分享主要从两个大的部分介绍,第一部分会讲一些性能优化的知识,针对IO的性能优化,不同版本值得注意的性能问题/优化;第二部分将监控应该关注哪些指标以及在日志里面如何做问题排查。
4.png

首先讲一下针对IO性能优化,每个厂商IO硬件性能都不一样,针对不同的硬件,需要利用的功能和注意的问题也不一样。如HDD,它的IO能力比较弱,很容易打爆,如果在云上应用HBase,有很多不同的硬盘可以使用。在HDD架设HBase要避免磁盘被打爆,HBase提供了很多方法,第一个就是Compaction限流,基本思想就是限制它每秒能写出的数据量,在1.1.0版本以上才能使用,对于1.3.0版本分界线以上以下配置不同,具体配置如上图所示。你可以设置其吞吐 的上限和下限,也可以设置平峰期的限制。我们进行限流肯定一般是在高峰期,在平峰期没有必要,也或者平峰期你有没有其他的应用,有时也会跑一些其他的应用,如spark等。Flush限流是在1.3.0版本以上支持的,其实主要的IO来源就是Compaction和Flush,配置与Compaction比较像。值得注意的是限流不能过低,如果过低Compaction的Hfile数就降不下来,block stoken file默认值是20,如果超过20,flush就会delay,内存会膨胀,如果膨胀超过一定区域就会block update,会出现写入延迟阻塞。因此两者限流需要依据实际限流,不能限流过低。
5.png

另外一个在HDD上比较适合是Per-CF Flush,在1.1.0版本以上就支持,默认配置是flush all stores,当main Store的大小达到设定阀值,就会将所有的CF都flush出来。但是有些CF文件比较小,会出现浪费io,另外刷出很多小文件需要compaction,对磁盘也会有影响。因此出现了HBase available,在1.1.0版本以上可以用,从1.1.0-2.0实质是设置了一个下限,如果CF文件在main Store时超过16M就将其flush,没有超过就不flush。后续在社区基础上做了改变,将默认值改为flush大小除以CF的个数,这样的问题有可能出现CF过多,因此也会有下限值控制,也是16M。使用这个功能也需要注意,开启这个功能有很多数据是不flush,但是如果出现故障,replay的数据会变多,在HBase中有个参数optional flush internal,可以设置过多长时间强制flush一次,还有一个flush prechanges,就是有多少change就flush一次;一个默认值是1小时,后面是3千万。
6.png

第三个方案是多盘,多盘在社区1.0版本就有多log的功能。如果在自己的机器上,服务器都是12块硬盘,如果用一个write tacklog,HDFS是三个副本,虽然能将吞吐打满,三个副本需要三个盘,无法使用完,IO能力没充分利用。解决方式就是用多个write tacklog,一个region server配置4个hlog,测试性能会提升20%。版本低于1.2.0:replication存在问题, hbase.wal.provider ->multiwall,hbase.wal.regiongrouping.strategy -> bounded ,根据盘数设置hbase.wal.regiongrouping.numgroups。需要注意写多少Hlog是依据你的盘确定,IO能力是否充足。
7.jpg

SSD在HBase里面也有很好的支持,SSD对性能的优化分为两个部分,一方面是读,另一方面是写。影响写的性能就是write height log的写,SSD能很大的降低其响应时间,在用SSD时也可以用Multi WAL,其写入性能比单WAL提升40%以上。从读方面来说,在CF可以设置Storage Policy,但该功能在2.0版本上才有。对不同的CF设置不同的Storage Policy(wan SSD,all SSD),设置多CF的原因是数据的冷热程度是不一样的。Bulkload也需要支持Storage Policy配置,如果生成的文件都是HDD,会影响读取的性能。
8.png

SSD需要注意的是如果是Wan SSD需要允许HDFS client优先读远程SSD上的副本,但是未合入社区版本,需要手动backport。对于Hybrid,WAL策略可以是WAL SSD,对CF级别也可以是WAL SSD。值得注意的是SSD也需要开启限流。Merge MVCCand SequenceId引发的性能问题:branch-1.0不要使用1.0.3以下版本,branch-1.1不要使用1.1.3以下版本。高负载下写入性能瓶颈: 如果线上发现wait在WALKey#get Write Entry,建议升级到1.4.0以上版本,对ASYNC_WAL写入性能提升尤其明显 。在读的性能,如果用的是Bucket Cache,在高并发读取单key的性能问题,在1.2.0以上版本可以解决。如果远程读SSD,需要考虑网络开销,Hybrid开销尤其大。
9.jpg

10.jpg

接下来讲一下问题排查,首先是RPC相关监控:Server响应时间,Server处理时间,请求排队时间。Total Call Time记录的是请求到达你的regionServer开始到server请求完结束,不包含发送结果的时间。业务在请求,但是server处理也好,这种情况需要去业务debug客户端网络是不是拥塞。Total Call Time肯定是等于ProcessCall Time+QueueCall Time,请求到达server是先进入一个队列,如果heightlog不繁忙,QueueCall Time会很短,但是如果server很繁忙active handler数很满,calltime会很长,请求是从队列出来后处理。Active Handler 在1.4.0版本以前是没有读写分离监控的。读写分离的好处就是Handler打满到底是读出问题还是写出问题就可以很容易监控。RPC队列长度也可以判断机器是否出问题了,RPC连接数很高也是消耗系统资源。上图是我们监控指标图,如图一峰值就可以推测这台机器可能有点问题。

请求相关指标对debug很重要,Put请求latency,Get请求latency,Scan请求latency等这些都会监控。我想说明就是对latency监控,Hbase出问题到底是文件系统出问题了还是regionServer出问题了,这个困扰了我们很久,因为底层会有一个文件系统,文件系统过肯定会受影响,因次对于put来说你要监控WAL sync latency,对于get要监控HDFS pread latency,Scan请求latency。对于HDFS pread latency需要1.4.0版本以上。如果发现Get请求latency很高,HDFS pread latency也很高,那么基本确定HDFS陡了,至少可以定位问题。否则就必须定位999的regionserver一一排查。
11.jpg

第三个就是内存相关的指标,GC对于排查问题作用未必很大,但是可以监控整体情况。对于GC更多的是查GC日志更有效果,pause Time Without GC不是进程GC导致的问题时,在1.4.0版本以上会发现一些日志的,这个时候需要关注一些系统的指标,如内存整理,那么你整个系统会停止,或者资源瓶颈或者CPU满了都会导致进程堵塞。再一个就是对Block Cache/MemStore 的监控,如何监控Hfile数过多,一方面可以监控blockupdate的字符和频率,另一方面是看MemStore数是否变大了。Block Cache在1.3.0版本以上可以区分data和meta命中率,meta block命中率一般都很高,访问频率也很高,如果不区分这个命中率有可能是假的。真实的data block命中率在65%,但是meta命中率基本是100%。
12.png

RegionServer单机指标,如果看到一个regionserver打满了,需要看regionServer单机指标。如region大小,这个指标引起cache的命中率,get和写操作数,看topN那些请求非常高,handler打满,get时间非常高,可以查询那个region访问过多,有些情况是访问值超过正常值导致的,因此可以通过表找到问题去解决。再一个就是compaction队列长度和flush队列长度。

如何发现stale的Region Server,如果出现坏盘,请求卡在IO上一直无法返回,响应时间相关指标无法捕捉,在total call time中无法体现。还有就是你的数值很好但是机器已经出问题,因为出问题的请求没有汇报给server,另外如果机器资源耗尽,新的请求无法连接server,从响应时间等server metrics上也体现不出来。因此做了一个增强health check,定期向自己发请求并设置超时时间,失败超过一定概率报警,有一个问题就是还没有Upstreaming in progress,但后续会完成。其实会出现一个情况就是系统资源耗尽,但是已经启动的线程可以运行,但是无法启动新的线程,就是一台机器已经不能服务,但是master还是可以服务。
13.jpg

接下来讲一下日志的排查,首先关于慢请求。如发现一个server的999时间很长,第一反应是登陆该台regionServer查看日志,尤其是responsetooslow日志,但是老版本是不会打印任何有关processingtime 、roll具体信息的,因此会关注这两个HBASE-16033/HBASE-16972 response Too Slow,会打印详细信息,前面一个jQuery是对普通请求,后面一个jQuery是对scan。经常会看到scan超时等这些信息都是很重要的。branch-1.1要求1.1.8以上,branch-1.2要求1.2.5以上,或1.3.0以上版本。在自己的版本还做了一些事情,但是还未放到社区,会区分如果是慢请求,到底long process time还是long call Time,因为一个long process time会导致一系列的long call Time。如果不区分会看到很多response TooSlow,但是你并不知道出现的问题是什么。当然还需要设置阈值,超过多长时间才算慢请求,我们是超过10秒才算慢请求,这个可以自己配置。如设置10秒其实8秒也不短,这时需要去region Server上解scandetail,去查看handler线程wait在什么地方,wait的地方出现了多少。
14.jpg

在Client端也有些日志也是非常重要的,对于single请求打印很全,但是要注意batch,branch-1.1要求1.1.6以上,branch-1.2要求1.2.3以上,或1.3.0以上版本。在有慢请求时,去打印具体是哪个region,还有目前运行在哪个server上,或者在batch请求异常时打印异常的batch栈。客户端还有其他好的机制,HBase客户端是由backoff policy,就是通过regionServer的region load判断是否需要sleep一段时间。后续有机会可以讨论如何排查GC、内存泄漏等复杂问题,如何定位疯狂访问RS的问题客户端应用,如何规避HDFS故障对HBase的影响,2.0黑科技在线上应用可能踩的坑,升级HBase版本有哪些必须的准备以及线上升级操作有哪些注意事项。
15.jpg

 

通过Java上传文件到hdfs出错

hbase过往记忆 回复了问题 • 2 人关注 • 1 个回复 • 361 次浏览 • 2018-07-31 11:05 • 来自相关话题

HBase 在贝壳找房的应用实践

hbase过往记忆 发表了文章 • 0 个评论 • 442 次浏览 • 2018-07-31 11:01 • 来自相关话题

本文来自于2018年7月21日在北京举行的 HBase Meetup 第二次会议。分享者邓钫元 现就职于贝壳找房,主要负责贝壳大数据基础引擎建设。毕业于浙江大学,曾就职于百度商业平台部-风控平台研发,现负责贝壳找房大数据集群及基础引擎建设,专注于hadoop生态组件,热爱开源,为社区贡献多个patch,有丰富的性能调优经验。

























PPT下载:

HBase在贝壳找房的应用实践.pdf



  查看全部
本文来自于2018年7月21日在北京举行的 HBase Meetup 第二次会议。分享者邓钫元 现就职于贝壳找房,主要负责贝壳大数据基础引擎建设。毕业于浙江大学,曾就职于百度商业平台部-风控平台研发,现负责贝壳找房大数据集群及基础引擎建设,专注于hadoop生态组件,热爱开源,为社区贡献多个patch,有丰富的性能调优经验。

HBase在贝壳找房的应用实践-01_副本.jpg


HBase在贝壳找房的应用实践-11_副本.jpg


HBase在贝壳找房的应用实践-21_副本.jpg


HBase在贝壳找房的应用实践-31_副本.jpg


HBase在贝壳找房的应用实践-41_副本.jpg

PPT下载:


 

HBase Procedure V2介绍

hbase过往记忆 发表了文章 • 0 个评论 • 303 次浏览 • 2018-07-31 10:49 • 来自相关话题

本文来自于2018年7月21日在北京举行的 HBase Meetup 会议。分析者张铎,HBase PMC member,目前在小米人工智能与云平台负责HBase的研发工作。主要介绍一下Procedure V2的设计和结构,以及为什么用Procedure V2能比较容易实现出正确的AssignmentManager。以及在2.1分支上对一些Procedure实现修正和改进。下面是 PPT 原文









 PPT下载:

HBase_Procedure_V2介绍.pdf



  查看全部
本文来自于2018年7月21日在北京举行的 HBase Meetup 会议。分析者张铎,HBase PMC member,目前在小米人工智能与云平台负责HBase的研发工作。主要介绍一下Procedure V2的设计和结构,以及为什么用Procedure V2能比较容易实现出正确的AssignmentManager。以及在2.1分支上对一些Procedure实现修正和改进。下面是 PPT 原文

HBase_Procedure_V2介绍_副本.jpg

HBase_Procedure_V2介绍-11_副本.jpg

 PPT下载:


 

阅读HBase源码的正确姿势建议

hbase过往记忆 发表了文章 • 0 个评论 • 646 次浏览 • 2018-07-31 10:37 • 来自相关话题

关于如何阅读开源社区源码,最近陆续有同学过来问我这个问题。前段时间,在HBase技术交流群里,大家也讨论过一些零散的方法,但都不系统。借着这个问题,我也认真回顾了一下自己所用过的一些方法,觉的有必要整理出来,供大家参考。

先选择合适的源码版本

因为不同的版本间的特性/流程方面存在较大的差异,阅读源码时选择合适的版本还是至关重要的。因此,需要先审视自己的需求:

“我阅读源码,是单纯的为了学习?还是希望在业务系统中更好的用好它?”

如果是前者,那完全可以选择最新发布或待发布的稳定版本。
如果是后者,则需要选择自己业务系统中正在使用的版本。

借助书籍或官方资料快速了解技术架构和关键特性

如果有介绍原理的书籍,可以先快速浏览一遍,粗略了解整体架构、关键特性。
这些信息也可以从官方资料中一探究竟,尤其是架构介绍相关的章节。

从快速试用开始加强自己对该项目的感性认识
先参考官方资料中的Quick Start章节,先学习如何使用,加强自己对于整体项目的感性认识。
这个过程,基本能摸清楚利用该项目"能做什么",以及"如何做"。当然,这里仅仅涉及了最基础的功能。
简单了解源码模块结构,而后从最基础的流程入手
快速了解源码的模块组成结构,以及每一个模块的主要作用。

这样有助于从源码结构上把握整体项目的轮廓,而后选择最基础的流程入手。
对于HBase而言,最基础的流程无非是如何建表以及如何写数据的流程。
学习一个特性要从了解配置和如何使用着手,同时建议阅读相关特性的设计文档或网上已有的源码解析文章

在学习一个特性时,也应该先从如何使用这个特性开始,接口如何被调用,关键配置有哪些,都是了解基础功能的基本起点。

接下来,可以先自己思考一下,这个特性如果由自己来设计,那整体思路应该是怎样的。

部分关键的特性/流程,在社区的问题单中,通常会有简洁的设计文档,这些文档能帮你理清方案的整体框架和思路。如果没有设计文档,那问题单中的Comments也是值得参考的。

当然,网上如果已经存在一些源码解析文章,也可以先参考一下,但好的文章往往是可遇不可求的。

如果在阅读源码之前,能够大致了解方案的思路,对自己会有很大的帮助,"瞎子摸象"式的阅读非常费时费力。

有一点需要强调一下:书籍或别人的文章中所描述的流程,在新版本中有可能已经发生了变化,因此,阅读时一定要带着辨证的思维。

摸清主线,避免过早陷入一些旁枝末节

刚开始阅读源码时,会遇到很多"好奇点":
这个算法居然实现的如此神奇?这个数据结构怎么没有见过?这个参数是干嘛的?

我自己也时常经不起这些"诱惑",陷于对这些细节的考究中,常常"离题"半天以后,才被拉回到主线中。

在阅读源码的时候,能遇到一些感兴趣的细节是好事,但建议先将这些细节点记录下来,等过完整体流程以后再回头看这些细节,避免过早陷入。

阅读源码过程中,通常需要动手做一些测试,此时,可以借助jstack工具(针对Java项目),它能为你提供如下有价值的信息:
线程模型调用栈

调用栈信息可以帮你理清整体调用流程(另外,在定位问题时,jstack打印出的信息也时常可以发挥重要作用)。

重视阅读日志信息

在进程启动或运行过程中,一些关键的操作或处理,都会记录日志信息,因此,阅读日志往往是一条有助于理清流程主线的捷径。

(PS: 感谢范欣欣同学补充的此条建议,笔者在实践中也时常用到)

阅读源码过程中,同步绘制时序图,固化对流程的理解

好不容易摸清的主线,建议及时用时序图的方式固化下来,这样可以帮助自己快速回顾整个流程。

当然,除了时序图,还建议附带简单的文字性总结。

阅读源码过程中,不断发现或提出疑问,并且记下来

当理清了主线流程以后,要继续深入探索这些细节疑问点,这些点决定了你对整个特性/流程的理解深度。

掌握一个特性/流程的基本前提,就是需要自己解答自己提出的所有疑问。

对于一些"莫名其妙"或"匪夷所思"的设计,请一定要对照参考社区问题单中的描述信息、设计文档或Comments信息。

阅读源码过程中,遇到晦涩难懂的细节,如何应对?

此时,建议开启Debug模式,详细跟踪每一步的调用流程,Debug可以分两种形式:
 
远程Debug本地Debug

对于HBase而言,相比于远程Debug,本地Debug似乎更难以理解了,因为我们所熟知的HBase部署形态就是分布式的,要对运行时的HBase集群进行Debug,自然采用远程Debug模式了。

其实,Debug也可以针对HBase提供的测试用例,大部分用例都是基于一个本地模拟的Mini Cluster运行的,这个Mini Cluster运行在一个进程中,使用线程模拟HBase的关键进程。

这个过程中,也可以动手小改一下源码,验证自己的想法,或者观察因为改动所带来的行为变化。

重视阅读测试用例源码

很多人并不习惯于阅读HBase的测试用例源码,其实,阅读测试用例的源码,可以帮你理解一些正确的行为应该是怎样的。

因为每一个被定义的正确行为,都以具体的测试用例固化下来了。

重视实际遇到的每一个Bug,每一个Bug都可以讲一个完整的故事

阅读源码过程中,自己提出的疑问,往往还不是最深刻的。最深刻的点,往往存在于所遇到的每一个Bug中。

对于Bug,很多人的态度往往是,能规避则规避之,集群只要能恢复正常,就不再有任何兴致去探究根因。

Bug往往是一些未考虑充足的边界场景,如果想探究Bug的根因,必然需要先摸清与之相关的所有流程,而后结合问题现象进行相关推理。一个Bug的前因后果,通常可以讲一个完整的故事。只有经过一个个Bug的历练,才能逐步成长为内核专家。

能力进阶:开始关注社区动态,或尝试为社区贡献Patch

关注社区动态,可以及时获知一些重要的Bugs或社区正在开发的大的Features。关注的方式包括但不限于:




订阅社区的Mail List

关注社区的问题单

如果感觉自己已经很好的掌握了源码,而且发现了部分设计不合理,或者是部分能力不完善(结合实际的业务需求),也可以主动为社区贡献Patch,对于大部分开源项目而言,都是非常鼓励大家贡献Patch的。

总结

本文主要从方法论的角度探讨了阅读开源项目源码的一些建议,供大家参考。这是第一个版本的内容,欢迎大家在评论中贡献自己的优秀实践方法,我可以继续完善它的内容,期望能够为更多人带来有价值的指导信息。 查看全部
关于如何阅读开源社区源码,最近陆续有同学过来问我这个问题。前段时间,在HBase技术交流群里,大家也讨论过一些零散的方法,但都不系统。借着这个问题,我也认真回顾了一下自己所用过的一些方法,觉的有必要整理出来,供大家参考。

先选择合适的源码版本

因为不同的版本间的特性/流程方面存在较大的差异,阅读源码时选择合适的版本还是至关重要的。因此,需要先审视自己的需求:

“我阅读源码,是单纯的为了学习?还是希望在业务系统中更好的用好它?”

如果是前者,那完全可以选择最新发布或待发布的稳定版本。
如果是后者,则需要选择自己业务系统中正在使用的版本。

借助书籍或官方资料快速了解技术架构和关键特性

如果有介绍原理的书籍,可以先快速浏览一遍,粗略了解整体架构、关键特性。
这些信息也可以从官方资料中一探究竟,尤其是架构介绍相关的章节。

从快速试用开始加强自己对该项目的感性认识
先参考官方资料中的Quick Start章节,先学习如何使用,加强自己对于整体项目的感性认识。
这个过程,基本能摸清楚利用该项目"能做什么",以及"如何做"。当然,这里仅仅涉及了最基础的功能。
简单了解源码模块结构,而后从最基础的流程入手
快速了解源码的模块组成结构,以及每一个模块的主要作用。

这样有助于从源码结构上把握整体项目的轮廓,而后选择最基础的流程入手。
对于HBase而言,最基础的流程无非是如何建表以及如何写数据的流程。
学习一个特性要从了解配置和如何使用着手,同时建议阅读相关特性的设计文档或网上已有的源码解析文章

在学习一个特性时,也应该先从如何使用这个特性开始,接口如何被调用,关键配置有哪些,都是了解基础功能的基本起点。

接下来,可以先自己思考一下,这个特性如果由自己来设计,那整体思路应该是怎样的。

部分关键的特性/流程,在社区的问题单中,通常会有简洁的设计文档,这些文档能帮你理清方案的整体框架和思路。如果没有设计文档,那问题单中的Comments也是值得参考的。

当然,网上如果已经存在一些源码解析文章,也可以先参考一下,但好的文章往往是可遇不可求的。

如果在阅读源码之前,能够大致了解方案的思路,对自己会有很大的帮助,"瞎子摸象"式的阅读非常费时费力。

有一点需要强调一下:书籍或别人的文章中所描述的流程,在新版本中有可能已经发生了变化,因此,阅读时一定要带着辨证的思维。

摸清主线,避免过早陷入一些旁枝末节

刚开始阅读源码时,会遇到很多"好奇点":
  • 这个算法居然实现的如此神奇?
  • 这个数据结构怎么没有见过?
  • 这个参数是干嘛的?


我自己也时常经不起这些"诱惑",陷于对这些细节的考究中,常常"离题"半天以后,才被拉回到主线中。

在阅读源码的时候,能遇到一些感兴趣的细节是好事,但建议先将这些细节点记录下来,等过完整体流程以后再回头看这些细节,避免过早陷入。

阅读源码过程中,通常需要动手做一些测试,此时,可以借助jstack工具(针对Java项目),它能为你提供如下有价值的信息:
  • 线程模型
  • 调用栈


调用栈信息可以帮你理清整体调用流程(另外,在定位问题时,jstack打印出的信息也时常可以发挥重要作用)。

重视阅读日志信息

在进程启动或运行过程中,一些关键的操作或处理,都会记录日志信息,因此,阅读日志往往是一条有助于理清流程主线的捷径。

(PS: 感谢范欣欣同学补充的此条建议,笔者在实践中也时常用到)

阅读源码过程中,同步绘制时序图,固化对流程的理解

好不容易摸清的主线,建议及时用时序图的方式固化下来,这样可以帮助自己快速回顾整个流程。

当然,除了时序图,还建议附带简单的文字性总结。

阅读源码过程中,不断发现或提出疑问,并且记下来

当理清了主线流程以后,要继续深入探索这些细节疑问点,这些点决定了你对整个特性/流程的理解深度。

掌握一个特性/流程的基本前提,就是需要自己解答自己提出的所有疑问。

对于一些"莫名其妙"或"匪夷所思"的设计,请一定要对照参考社区问题单中的描述信息、设计文档或Comments信息。

阅读源码过程中,遇到晦涩难懂的细节,如何应对?

此时,建议开启Debug模式,详细跟踪每一步的调用流程,Debug可以分两种形式:
 
  • 远程Debug
  • 本地Debug


对于HBase而言,相比于远程Debug,本地Debug似乎更难以理解了,因为我们所熟知的HBase部署形态就是分布式的,要对运行时的HBase集群进行Debug,自然采用远程Debug模式了。

其实,Debug也可以针对HBase提供的测试用例,大部分用例都是基于一个本地模拟的Mini Cluster运行的,这个Mini Cluster运行在一个进程中,使用线程模拟HBase的关键进程。

这个过程中,也可以动手小改一下源码,验证自己的想法,或者观察因为改动所带来的行为变化。

重视阅读测试用例源码

很多人并不习惯于阅读HBase的测试用例源码,其实,阅读测试用例的源码,可以帮你理解一些正确的行为应该是怎样的。

因为每一个被定义的正确行为,都以具体的测试用例固化下来了。

重视实际遇到的每一个Bug,每一个Bug都可以讲一个完整的故事

阅读源码过程中,自己提出的疑问,往往还不是最深刻的。最深刻的点,往往存在于所遇到的每一个Bug中。

对于Bug,很多人的态度往往是,能规避则规避之,集群只要能恢复正常,就不再有任何兴致去探究根因。

Bug往往是一些未考虑充足的边界场景,如果想探究Bug的根因,必然需要先摸清与之相关的所有流程,而后结合问题现象进行相关推理。一个Bug的前因后果,通常可以讲一个完整的故事。只有经过一个个Bug的历练,才能逐步成长为内核专家。

能力进阶:开始关注社区动态,或尝试为社区贡献Patch

关注社区动态,可以及时获知一些重要的Bugs或社区正在开发的大的Features。关注的方式包括但不限于:




订阅社区的Mail List

关注社区的问题单

如果感觉自己已经很好的掌握了源码,而且发现了部分设计不合理,或者是部分能力不完善(结合实际的业务需求),也可以主动为社区贡献Patch,对于大部分开源项目而言,都是非常鼓励大家贡献Patch的。

总结

本文主要从方法论的角度探讨了阅读开源项目源码的一些建议,供大家参考。这是第一个版本的内容,欢迎大家在评论中贡献自己的优秀实践方法,我可以继续完善它的内容,期望能够为更多人带来有价值的指导信息。

HBasecon Asia 2018 招聘志愿者

活动过往记忆 发表了文章 • 0 个评论 • 456 次浏览 • 2018-07-30 14:29 • 来自相关话题

Apache旗下顶级开源盛会 HBasecon Asia 2018 将于8月17日在京举行。作为国内的主要社区贡献者,阿里巴巴此次联合小米、华为、滴滴等国内主流互联网企业承办的 HBasecon Asia 2018 峰会落户北京,不仅得到了 Apache 官方授权,还得了有来自 Cloudera,Intel 等商业公司社区 PMC 的强烈支持。通过参会不仅可以了解到 HBase 社区的最新动态和发展计划,还可以了解到国内外一线大厂围绕 HBase 生态的生产实践经验,是 HBase 开发者和使用者不可错过的盛会。
 
为维护大会的有序进行,现面向社会招募本次大会志愿者约8人,名额有限,先到先得。

具体说明如下:
一、时间:2018年8月17日
二、地点:歌华开元大酒店
三、性质:志愿服务
四、报名条件:服从组织安排,8月17日那天周五要能来。
五、服务内容:大会嘉宾注册、嘉宾入场、接待、咨询、引导、媒体宣传等;
六、报名时间:即日起到2018年8月16日。
七、志愿者报名联系:微信: iteblog、钉钉:rvix4rb
八、志愿者福利:每名志愿者都可以获取限量版大会定制T恤、送餐票、优先加入 hbase技术社区,成为社区助理,参与社区活动。 查看全部
Apache旗下顶级开源盛会 HBasecon Asia 2018 将于8月17日在京举行。作为国内的主要社区贡献者,阿里巴巴此次联合小米、华为、滴滴等国内主流互联网企业承办的 HBasecon Asia 2018 峰会落户北京,不仅得到了 Apache 官方授权,还得了有来自 Cloudera,Intel 等商业公司社区 PMC 的强烈支持。通过参会不仅可以了解到 HBase 社区的最新动态和发展计划,还可以了解到国内外一线大厂围绕 HBase 生态的生产实践经验,是 HBase 开发者和使用者不可错过的盛会。
 
为维护大会的有序进行,现面向社会招募本次大会志愿者约8人,名额有限,先到先得。

具体说明如下
一、时间:2018年8月17日
二、地点:歌华开元大酒店
三、性质:志愿服务
四、报名条件:服从组织安排,8月17日那天周五要能来。
五、服务内容:大会嘉宾注册、嘉宾入场、接待、咨询、引导、媒体宣传等;
六、报名时间:即日起到2018年8月16日。
七、志愿者报名联系:微信: iteblog、钉钉:rvix4rb
八、志愿者福利:每名志愿者都可以获取限量版大会定制T恤、送餐票、优先加入 hbase技术社区,成为社区助理,参与社区活动。

2018 HBase Meetup 演讲者和议题征集

活动过往记忆 发表了文章 • 0 个评论 • 1271 次浏览 • 2018-07-30 14:21 • 来自相关话题

HBase Meetup 会议由 HBase技术社区主办,分别在各大城市进行。前四期 HBase Meetup 会议分别在北京、杭州和上海圆满结束。来自各大公司的各位 HBase 的 PMC、committer 共聚一堂,为大家分享了 HBase 技术解析及应用实践。 

接下来我们将在武汉、成都、南京、苏州、广州、西安、厦门以及重庆等城市继续举办 HBase Meetup 会议。现向大家征集这几次会议的大会演讲者和议题,如果大家有意来分享,可以到 http://cn.mikecrm.com/zh19LHN 参加调查问卷,欢迎大家踊跃参与。同时愿意主动主办的公司,也可以来联系我。
 
议题范围:HBase 内容相关,鼓励大家分享 HBase 使用场景。
 
投送议题时需要说明议题名称和简介,PPT可后续完成。
 
报名咨询:
微信:iteblog
钉钉:rvix4rb

各地 Meetup 举办时间:











下面几个城市需要投票决定是否举办,投票地址:https://wj.qq.com/s/2315656/9e0f






后续活动报名时间以及网址请关照 HBase技术社区官方网站以及 HBase技术社区 公众号。
 
  查看全部
HBase Meetup 会议由 HBase技术社区主办,分别在各大城市进行。前四期 HBase Meetup 会议分别在北京、杭州和上海圆满结束。来自各大公司的各位 HBase 的 PMC、committer 共聚一堂,为大家分享了 HBase 技术解析及应用实践。 

接下来我们将在武汉、成都、南京、苏州、广州、西安、厦门以及重庆等城市继续举办 HBase Meetup 会议。现向大家征集这几次会议的大会演讲者和议题,如果大家有意来分享,可以到 http://cn.mikecrm.com/zh19LHN 参加调查问卷,欢迎大家踊跃参与。同时愿意主动主办的公司,也可以来联系我。
 
议题范围:HBase 内容相关,鼓励大家分享 HBase 使用场景。
 
投送议题时需要说明议题名称和简介,PPT可后续完成。
 
报名咨询:
微信:iteblog
钉钉:rvix4rb

各地 Meetup 举办时间

menu.saveimg_.savepath20180912101143_.jpg


menu.saveimg_.savepath20180912101158_.jpg


下面几个城市需要投票决定是否举办,投票地址:https://wj.qq.com/s/2315656/9e0f

微信图片_20180912100740.png


后续活动报名时间以及网址请关照 HBase技术社区官方网站以及 HBase技术社区 公众号。
 
 

关于rowkey的设计

hbasehbasegroup 回复了问题 • 4 人关注 • 4 个回复 • 569 次浏览 • 2018-07-30 13:29 • 来自相关话题

blukload入库时出现的问题

回复

hbaselvwenyuan 发起了问题 • 2 人关注 • 0 个回复 • 593 次浏览 • 2018-07-30 12:43 • 来自相关话题

Hbase 存储爬虫详情页 相关设计

hbase过往记忆 回复了问题 • 4 人关注 • 2 个回复 • 1085 次浏览 • 2018-07-28 09:41 • 来自相关话题

Apache旗下顶级开源盛会 HBasecon Asia 2018将于8月在京举行

活动过往记忆 发表了文章 • 0 个评论 • 379 次浏览 • 2018-07-26 16:37 • 来自相关话题

作为Apache基金会旗下HBase社区的顶级用户峰会,HBaseCon大会是Apache HBase™官方从2012年开始发起和延续至今的技术会议,先后在美国加州、日本东京和中国深圳等地举办,得到了Google、Facebook、雅虎和阿里巴巴等众多全球顶级互联网公司支持。

第二届Apache HBasecon Asia 峰会将于8月17日在北京举行。届时将有超30位来自亚洲一线互联网和大数据生态相关企业的技术专家和社区领袖亮相本次峰会,带来Hbase及大数据技术生态的最新洞察和行业实践。

Apache HBase是基于Apache Hadoop构建的一个高可靠性、高性能、可伸缩的分布式存储系统,它提供了大数据背景下的高性能的随机读写能力,HBase是Google Big table的开源实现,类似Google Bigtable中的GFS文件存储系统。通过在廉价PC Server上搭建起大规模结构化存储集群,可为众多企业从软件系统、解决方案、稳定护航、发展支撑等全方位提供一站式大数据基础存储服务。

HBase项目最初是以Hadoop子项目的形式进行孵化,2010年5月正式毕业成为Apache顶级项目并独立发展。伴随着互联网时代数据的爆炸性增长,HBase作为基础存储系统得到了快速发展与应用,Facebook、阿里、雅虎等大量知名商业公司先后加入到了HBase生态建设队伍,成为Apache最活跃的社区之一。

随着HBase逐渐成为开源大数据领域的核心项目, 阿里、华为、小米、滴滴和360等众多国内互联网公司也迅速跟进,在生产中大规模应用及改进HBase,有效带动了整个HBase生态在国内的普及和发展。截至目前国内共有4位PMC和14位HBase Committer,中国力量已成为HBase生态积极壮大的核心源动力。

过去几年随着互联网技术在行业应用场景的细化,围绕HBase建立起来的技术生态体系也正越发茁壮,涌现出一批非常有代表性的衍生项目,比如基于HBase的SQL引擎Phoenix可有效解决HTAP和OLAP混合场景问题;时序数据库OpenTSDB已成为IoT场景的首选开源方案;JanusGraph图数据库已在面向关系分析、安全风控的大数据场景成为必备品;此外还有时空数据库GeoMesa,在共享出行、自动驾驶、城市大脑和智慧物流等新兴行业拥有广阔的前景空间。

作为国内的主要社区贡献者,阿里巴巴此次联合小米、华为、滴滴等国内主流互联网企业承办的HBasecon Asia 2018峰会落户北京,不仅得到了Apache官方授权,还得了有来自Cloudera,Intel等商业公司社区PMC的强烈支持。通过参会不仅可以了解到HBase社区的最新动态和发展计划,还可以了解到国内外一线大厂围绕HBase生态的生产实践经验,是HBase开发者和使用者不可错过的盛会。

重量嘉宾先睹为快

1、 演讲主题:HBase 2.0的前世今生
简介:介绍HBase 2.0 release的内容以及未来的计划
演讲嘉宾:Michael Stack, HBase资深PMC,HBase项目发起者之一, Cloudera HBase负责人

2、演讲主题:HBase与非易失性内存的结合
简介:介绍HBase如何结合Intel非易失性内存AEP提供更好的可靠性(HA)和更快的故障恢复(MTTR)
演讲嘉宾:Anoop Sam John, HBase资深PMC, Intel HBase资深专家

3、演讲主题:HBase同步复制
简介:介绍如何通过同步复制功能达到故障时访问直接切换到备集群的同时保证数据的强一致性,以及该项工作在社区的进展
演讲嘉宾:Duo Zhang (张铎), HBase PMC, 小米HBase团队负责人

4、演讲主题:HBase高可用性实践
简介: 介绍如何在数千节点集群环境中快速发现僵死RS节点,如何规避HDFS故障对于HBase的影响等生产实践经验
演讲嘉宾:Yu Li (李钰), HBase PMC, 阿里巴巴高级技术专家, 搜索HBase团队负责人

5、演讲主题:HBase上一种内建的冷热多层异构存储特性
简介:介绍了一种冷热自动分离的特性,能够在系统内部对数据按时间进行物理分层和异构存储(如冷数据使用低成本介质和高压缩率算法,热数据使用高速介质和低压缩率算法),并对用户访问保持透明。
演讲嘉宾:Wenlong Yang(杨文龙),HBase Committer,阿里巴巴技术专家,HBase内核负责人

更多此次大会详情和报名申请,请访问官方网站:https://yq.aliyun.com/promotion/631 
 




  查看全部
作为Apache基金会旗下HBase社区的顶级用户峰会,HBaseCon大会是Apache HBase™官方从2012年开始发起和延续至今的技术会议,先后在美国加州、日本东京和中国深圳等地举办,得到了Google、Facebook、雅虎和阿里巴巴等众多全球顶级互联网公司支持。

第二届Apache HBasecon Asia 峰会将于8月17日在北京举行。届时将有超30位来自亚洲一线互联网和大数据生态相关企业的技术专家和社区领袖亮相本次峰会,带来Hbase及大数据技术生态的最新洞察和行业实践。

Apache HBase是基于Apache Hadoop构建的一个高可靠性、高性能、可伸缩的分布式存储系统,它提供了大数据背景下的高性能的随机读写能力,HBase是Google Big table的开源实现,类似Google Bigtable中的GFS文件存储系统。通过在廉价PC Server上搭建起大规模结构化存储集群,可为众多企业从软件系统、解决方案、稳定护航、发展支撑等全方位提供一站式大数据基础存储服务。

HBase项目最初是以Hadoop子项目的形式进行孵化,2010年5月正式毕业成为Apache顶级项目并独立发展。伴随着互联网时代数据的爆炸性增长,HBase作为基础存储系统得到了快速发展与应用,Facebook、阿里、雅虎等大量知名商业公司先后加入到了HBase生态建设队伍,成为Apache最活跃的社区之一。

随着HBase逐渐成为开源大数据领域的核心项目, 阿里、华为、小米、滴滴和360等众多国内互联网公司也迅速跟进,在生产中大规模应用及改进HBase,有效带动了整个HBase生态在国内的普及和发展。截至目前国内共有4位PMC和14位HBase Committer,中国力量已成为HBase生态积极壮大的核心源动力。

过去几年随着互联网技术在行业应用场景的细化,围绕HBase建立起来的技术生态体系也正越发茁壮,涌现出一批非常有代表性的衍生项目,比如基于HBase的SQL引擎Phoenix可有效解决HTAP和OLAP混合场景问题;时序数据库OpenTSDB已成为IoT场景的首选开源方案;JanusGraph图数据库已在面向关系分析、安全风控的大数据场景成为必备品;此外还有时空数据库GeoMesa,在共享出行、自动驾驶、城市大脑和智慧物流等新兴行业拥有广阔的前景空间。

作为国内的主要社区贡献者,阿里巴巴此次联合小米、华为、滴滴等国内主流互联网企业承办的HBasecon Asia 2018峰会落户北京,不仅得到了Apache官方授权,还得了有来自Cloudera,Intel等商业公司社区PMC的强烈支持。通过参会不仅可以了解到HBase社区的最新动态和发展计划,还可以了解到国内外一线大厂围绕HBase生态的生产实践经验,是HBase开发者和使用者不可错过的盛会。

重量嘉宾先睹为快

1、 演讲主题:HBase 2.0的前世今生
简介:介绍HBase 2.0 release的内容以及未来的计划
演讲嘉宾:Michael Stack, HBase资深PMC,HBase项目发起者之一, Cloudera HBase负责人

2、演讲主题:HBase与非易失性内存的结合
简介:介绍HBase如何结合Intel非易失性内存AEP提供更好的可靠性(HA)和更快的故障恢复(MTTR)
演讲嘉宾:Anoop Sam John, HBase资深PMC, Intel HBase资深专家

3、演讲主题:HBase同步复制
简介:介绍如何通过同步复制功能达到故障时访问直接切换到备集群的同时保证数据的强一致性,以及该项工作在社区的进展
演讲嘉宾:Duo Zhang (张铎), HBase PMC, 小米HBase团队负责人

4、演讲主题:HBase高可用性实践
简介: 介绍如何在数千节点集群环境中快速发现僵死RS节点,如何规避HDFS故障对于HBase的影响等生产实践经验
演讲嘉宾:Yu Li (李钰), HBase PMC, 阿里巴巴高级技术专家, 搜索HBase团队负责人

5、演讲主题:HBase上一种内建的冷热多层异构存储特性
简介:介绍了一种冷热自动分离的特性,能够在系统内部对数据按时间进行物理分层和异构存储(如冷数据使用低成本介质和高压缩率算法,热数据使用高速介质和低压缩率算法),并对用户访问保持透明。
演讲嘉宾:Wenlong Yang(杨文龙),HBase Committer,阿里巴巴技术专家,HBase内核负责人

更多此次大会详情和报名申请,请访问官方网站:https://yq.aliyun.com/promotion/631 
 
menu.saveimg_.savepath20180726163707_.jpg

 

中国HBase技术社区第二届MeetUp资料分享

hbase过往记忆 发表了文章 • 0 个评论 • 468 次浏览 • 2018-07-26 14:23 • 来自相关话题

2018-7-21 由中国 HBase 技术社区及 DataFun 社区主办的中国HBase技术社区第二届MeetUp-HBase技术解析及应用实践举办圆满成功。

再次非常感谢以下单位:
主办方:中国HBase技术社区
              DataFun社区

联合主办方:贝壳找房
视频支持:IT大咖说

让我们来一睹昨天大会现场的照片吧
1、中国HBase技术社区(hbasegroup)介绍





2、HBase应用实践
邓钫元 贝壳找房 资深研发工程师 
PPT下载:





3、Procedure V2介绍
张铎 小米人工智能与云平台 研发工程师
PPT下载:
HBase_Procedure_V2介绍.pdf







4、HBase in Practise: 性能、监控和问题排查
李钰 阿里巴巴计算平台事业部高级技术专家




让我们看看 小伙伴们的热情吧 本次会场爆满 250+









最后让小编再放出一张 大佬和小伙伴的合影。帅呆了,向大佬学习






最后,小伙伴们,让我们再次期待:
八月,北京的HBaseCon亚洲大会(https://m.aliyun.com/markets/a ... ia2018)
九月,中国HBase技术社区Meetup,第三届杭州站,届时欢迎大家参加。
  查看全部
2018-7-21 由中国 HBase 技术社区及 DataFun 社区主办的中国HBase技术社区第二届MeetUp-HBase技术解析及应用实践举办圆满成功。

再次非常感谢以下单位:
主办方:中国HBase技术社区
              DataFun社区

联合主办方:贝壳找房
视频支持:IT大咖说

让我们来一睹昨天大会现场的照片吧
1、中国HBase技术社区(hbasegroup)介绍
1.jpg


2、HBase应用实践
邓钫元 贝壳找房 资深研发工程师 
PPT下载:
2.jpg


3、Procedure V2介绍
张铎 小米人工智能与云平台 研发工程师
PPT下载:
3.jpg


4、HBase in Practise: 性能、监控和问题排查
李钰 阿里巴巴计算平台事业部高级技术专家
4.jpg

让我们看看 小伙伴们的热情吧 本次会场爆满 250+
5.jpg

6.jpg


最后让小编再放出一张 大佬和小伙伴的合影。帅呆了,向大佬学习

7.jpg


最后,小伙伴们,让我们再次期待:
八月,北京的HBaseCon亚洲大会(https://m.aliyun.com/markets/a ... ia2018)
九月,中国HBase技术社区Meetup,第三届杭州站,届时欢迎大家参加。
 

HBase in Practice - 性能、监控及问题解决

hbasehbasegroup 发表了文章 • 0 个评论 • 388 次浏览 • 2018-07-23 21:45 • 来自相关话题

李钰(社区ID:Yu Li),阿里巴巴计算平台事业部高级技术专家,HBase开源社区PMC&committer。开源技术爱好者,主要关注分布式系统设计、大数据基础平台建设等领域。连续4年基于HBase/HDFS设计和开发存储系统应对双十一访问压力,具备丰富的大规模集群生产实战经验



内容摘要

性能优化
1针对IO的性能优化
2不同版本值得注意的性能问题/优化
监控和问题排查
1  Important metrics
2 Logs and debugging



针对IO的性能优化



























不同版本值得注意的性能问题







问题排查: 重要的监控指标
















































问题排查: Server端日志







问题排查:Client端日志







To Be Continued










大家工作学习遇到HBase技术问题,把问题发布到HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup),非常欢迎大家积极投稿。

长按下面的二维码加入HBase技术社区微信群





现任中国HBase技术社区成员,了解互联网金融、大数据相关知识





  查看全部

李钰(社区ID:Yu Li),阿里巴巴计算平台事业部高级技术专家,HBase开源社区PMC&committer。开源技术爱好者,主要关注分布式系统设计、大数据基础平台建设等领域。连续4年基于HBase/HDFS设计和开发存储系统应对双十一访问压力,具备丰富的大规模集群生产实战经验



内容摘要

性能优化
1针对IO的性能优化
2不同版本值得注意的性能问题/优化
监控和问题排查
1  Important metrics
2 Logs and debugging



针对IO的性能优化

1.jpg


2.jpg


3.jpg


4.jpg


5.jpg



不同版本值得注意的性能问题

6.jpg



问题排查: 重要的监控指标

7.jpg


8.jpg


9.jpg


10.jpg


11.jpg


12.jpg


13.jpg


14.jpg



15.jpg



问题排查: Server端日志


16.jpg


问题排查:Client端日志


17.jpg


To Be Continued


微信图片_20180723213732.jpg





大家工作学习遇到HBase技术问题,把问题发布到HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup),非常欢迎大家积极投稿。

长按下面的二维码加入HBase技术社区微信群

微信图片_20180623105555.jpg

现任中国HBase技术社区成员,了解互联网金融、大数据相关知识

qrcode_for_gh_e12b18786730_258_(3).jpg

 

雷布斯,谦逊的男神——暨小米大数据实践分享

hbasehbasegroup 发表了文章 • 2 个评论 • 354 次浏览 • 2018-07-23 21:36 • 来自相关话题

上周末非常有幸和同学一起参加武汉大学北京校友会,当听到雷军要去的时候,就迫不及待地让我同学帮我报名,由于现场参会人员太多,最终也算好不容易报上名了参加了志愿者。先来说和武大不解之缘吧,高考没能如愿进入武大。在研究生期间,由于机缘,有幸能够在武汉大学遥感信息工程学院学习接近一年。武大真是一个优秀的学校,在那边期间认识的几个师兄师姐以及师弟师妹,都给人一种做事很踏实的感觉。

此处必须放几张武大照片镇楼,哈哈哈







还记得听到雷军要来,大家都在门口等了很久,迫不及待地想和雷总合影。那种场面真是第一次见到,大家追了一路,为了和师兄合影。突然感觉有种网红的感觉,哈哈哈,然后校长说让师兄吃个饭,大家都跑到餐桌上和师兄合影,终于校长把大家都轰走了。看着师兄低着头吃饭,突然有一种很难过的感觉。是啊,雷军也是人,不是神,人都要吃饭睡觉的,看着师兄,竟然不忍心强行要求与其合影。于是在桌子的对面拍了几张师兄的照片,顺便和师兄隔着桌子合了个影,也算是与雷军同框了。











雷军,谦逊的男神

虽然跻身首富行列,但是在我们这群师弟师妹面前还是表现的如此谦逊,还记得雷军去年给学校捐款捐了一亿差一块钱,当时还不太理解,后来才知道泰康集团CEO陈东升学长给学校捐了一个亿,所以雷师兄为了不抢陈东升师兄的风头,少捐了一块钱。



上面是打广告部分了,通过和卢学裕师兄的交流,师兄之前在小米任职,现在自己创业,下面来和大家分享一下师兄介绍的小米在大数据方面的应用,干货满满。



小米数据工场的技术架构

卢学裕表示, 小米数据工厂跟各家的大数据平台、数据系统有很多类似之处也有自己独特的点。工厂整个底层基础平台建立在Hadoop体系,除此小米跟Cloudera合作也非常紧密。小米整个底层平台会有专门平台组去开发,最底用的HDFS,上面用的Hive、Spark和Mapreduce这些是混合到一个亚运集群上。Impala小米很早就在用,是一个很重的计算角色。

 






小米数据工场总体结构


如上图, 上半部分是自研的数据工厂,是为最顶业务层提供服务的。数据工厂主要是提供数据可视化、计算任务管理、数据管理、权限管理、任务调度、数据共享等服务。卢学裕表示,公司越大就更希望数据能够开放给公司的各个部门,数据可相互利用。但不能没有任何限制的去使用,所以需要对数据权限做管理。任务调度是整个工厂里面最重的部分。数据共享就是类似非常火的用户画像类数据,还有其他公共数据如IP库,这些数据具有公共特点,就不用重复计算,就可以通过数据共享的方式在各个团队之间使用这些数据。

数据管理,分为数据预览、元数据、数据源三部分。数据预览是每个团队用来互相了解数据的。

元数据,就是数据使用过程中要把非结构化的数据转换结构化的数据。元数据管理就是去了解每个字段的含义和机器解析。机器解析包括Mapreduce程序可直接读文件可解析,如用Impala、Spark和Hive同样也能解析,而不需要每个使用者再去格式化,再去解析这个数据。但面临的问题是数据一旦出现格式的转变或者某些字段的调整,以前任务可能都会出现问题,故一定要统一管理的地方。数据源,数据管理非常核心的是数据集成,能够把各个地方的数据集成到平台上来。

HDFS目录管理。有公共数据空间、业务数据空间、团队数据空间、个人数据空间、Yarn计算空间五部分。

(1)公共数据空间,是用来把公共数据放到上面,把维护权限和读的权限分开。这样大部分都是读这个空间,空间数据安全性等级相对来讲比较低,可以付给更多人。

(2)业务数据空间,因为每个业务数据的增长量是不一样的,甚至有些业务会出现如刚上来一个新功能,数据量迅速的增大,有的甚至会出现某个团队的数据增加,导致把整个集群空间全吃掉,又没有事先招呼。这种情况下做好业务间的限额配额是非常重要,防止某一个团队的增长导致整个集群出现一些问题。

(3)团队数据空间,就是把权限控制到个人,用来帮助做团队之间的数据协作。如把线上任务会放到团队账号中去,团队账号的权限要做好控制,权限不随便开放。团队人员发生变动后,整个团队任务不用再去切换账户而导致交接的复杂性。

(4)个人数据空间,数据工程师、开发工程师等是需要做一些调试或做自己的计算这就要给这些人一定空间的同时对其数据做配额。这是为了防止这些人过多的使用资源和为了空间不够需要清理数据时,哪些数据要清理,哪些数据不能清理一目了然。这样限制空间的情况下,这种废文件或者垃圾文件的积累会相对较少。

(5)Yarn计算空间,做配额限制呢是为了杜绝空间滥用的问题。卢学裕举例道,“之前发生过一件事,某人在Reduce里面写了一个死循环,不停的输出数据,导致整个集群很快就去报警。后来才发现这个计算造成的一些问题,最后差点导致那些日志上传、数据的写入都出问题,幸亏处理的比较及时。”所以,Yarn计算空间是需要做一个配额限制,防止对整个集群造成过大的影响。

卢学裕表示,小米数据存储格式统一采用的Parquet,优点在于其使用的是列式存储,支持Mapreduce、Hive、Impala、Spark和读取快占用空间少。

 






客户端数据接入两种模式优劣势


客户端数据接入。客户端指的是如说Wap、App等数据,存在方式有SDK和服务端Log两种模式。上图为两种模式的优劣势。

服务器端数据源。除前端数据源外,整个处理数据时还会有大量服务器端数据源需要处理。业务数据库类,用ETL工具做导入。服务器端日志,用Scribe将数据写入HDFS。

元数据管理。当公司业务变多后,每一个数据的处理方式都有可能不一样,这时候就凸显出元数据管理的重要性。如视频播放日志,分析师希望用Hive,用Impala直接写SQL去计算,但数据挖掘工程师就要去写Mapreduce,写Spark的方式去读,去解析。元数据管理就是要做数据统一,既能够满足Hive、Spark、Impala,还能满足Mapreduce。这样一来节省大家对数据理解、执行的时间。






元数据管理

如上图,小米数据工厂是每一份数据的描述都需要在数据工厂上提交,之后数据工厂会在MetaStore中做建表的同时带上元数据的行为,供Hive、Spark、Impala使用。数据管理还会生成Jave  Class,给Mapreduce使用。当去解析用某个数据时候,可以直接用这样的方式把它解析成Jave类。







计算管理

计算管理。卢学裕表示,计算是很重要的事情,数据管理相对来讲是一次性的活,计算就是很复杂的事情。计算任务数一天达到几千或过万时,就会变得非常复杂。对于计算管理这快优化,小米做了如上图的一些工作。

Docker。为了管理好这些纷繁的计算框架和模型,在计算的执行方面,小米使用Docker来解决对环境的不同需求和异构问题,并且与Hive、Impala、Spark这些不同的计算模型都进行了对接,去适配不同应用场景计算不同数据的模型。另外,在不同业务场景下,同一个计算逻辑也可以选用不同的计算模型,Docker 的使用也避免了资源的浪费。比如一个计算任务每天凌晨运行,为了追求吞吐量,可以放到Hive里跑;还是同样一个计算模型,现在就要跑,可以不用更改,就放到Impala里运行。Docker不仅解决了环境的异构,也解决了资源问题。另外,Docker的环境适应性很强,做横向扩展会比较容易。对于数据隐私方面,小米考虑得非常重。采用Docker与自身安全策略的综合,小米用户数据的隐私和安全性也得到了极其严格的控制。

小团队如何玩转大数据

小团队玩大数据会面临哪些问题?小团队会面临人力资源不足,技术储备不足,时间有限等问题。面对这些问题,卢学裕在技术选型上给出如下三个建议。

(1)选择热门技术。因为人才比较多,相对获取这样人才会比较容易。技术成熟,因为小团队没有时间去踩坑。还有帮助多,这如说网上文档帮助、社群帮助,朋友帮助等。

(2)够用。针对一些小团队或者初创公司的特点,业务变化特别快,也不稳定,这种情况下做到够用就好,不需要过分的设计和采用过重的系统。尽量根据业务驱动,业务需要什么数据就抓什么数据。

(3)演进。随着需求的变化需要不断的演进,包括系统演进、使用方式演进。

一定要做好数据积累。卢学裕表示,无论你用什么样的技术,用Hadoop也好,不用Hadoop也好,一定要做好数据的积累,这是对一家数据公司非常重要的部分。这就需要提前规划好数据,还要避免逻辑孤岛。还需要注意ID问题,也就是关联的问题。当采集了数据,却发现没有采用户ID,没有提前做好这个规划,当算到用户级别时候那就尴尬了。


大家工作学习遇到HBase技术问题,把问题发布到HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup),非常欢迎大家积极投稿。







现任中国HBase技术社区成员,了解互联网金融、大数据相关知识,有意向进入小米,可协助帮忙内推,直达CEO雷布斯邮箱





  查看全部
上周末非常有幸和同学一起参加武汉大学北京校友会,当听到雷军要去的时候,就迫不及待地让我同学帮我报名,由于现场参会人员太多,最终也算好不容易报上名了参加了志愿者。先来说和武大不解之缘吧,高考没能如愿进入武大。在研究生期间,由于机缘,有幸能够在武汉大学遥感信息工程学院学习接近一年。武大真是一个优秀的学校,在那边期间认识的几个师兄师姐以及师弟师妹,都给人一种做事很踏实的感觉。

此处必须放几张武大照片镇楼,哈哈哈

微信图片_20180720230212.jpg



还记得听到雷军要来,大家都在门口等了很久,迫不及待地想和雷总合影。那种场面真是第一次见到,大家追了一路,为了和师兄合影。突然感觉有种网红的感觉,哈哈哈,然后校长说让师兄吃个饭,大家都跑到餐桌上和师兄合影,终于校长把大家都轰走了。看着师兄低着头吃饭,突然有一种很难过的感觉。是啊,雷军也是人,不是神,人都要吃饭睡觉的,看着师兄,竟然不忍心强行要求与其合影。于是在桌子的对面拍了几张师兄的照片,顺便和师兄隔着桌子合了个影,也算是与雷军同框了。

微信图片_20180720230233.jpg


微信图片_20180720230228.jpg


雷军,谦逊的男神

虽然跻身首富行列,但是在我们这群师弟师妹面前还是表现的如此谦逊,还记得雷军去年给学校捐款捐了一亿差一块钱,当时还不太理解,后来才知道泰康集团CEO陈东升学长给学校捐了一个亿,所以雷师兄为了不抢陈东升师兄的风头,少捐了一块钱。



上面是打广告部分了,通过和卢学裕师兄的交流,师兄之前在小米任职,现在自己创业,下面来和大家分享一下师兄介绍的小米在大数据方面的应用,干货满满。



小米数据工场的技术架构

卢学裕表示, 小米数据工厂跟各家的大数据平台、数据系统有很多类似之处也有自己独特的点。工厂整个底层基础平台建立在Hadoop体系,除此小米跟Cloudera合作也非常紧密。小米整个底层平台会有专门平台组去开发,最底用的HDFS,上面用的Hive、Spark和Mapreduce这些是混合到一个亚运集群上。Impala小米很早就在用,是一个很重的计算角色。

 
1.jpg



小米数据工场总体结构


如上图, 上半部分是自研的数据工厂,是为最顶业务层提供服务的。数据工厂主要是提供数据可视化、计算任务管理、数据管理、权限管理、任务调度、数据共享等服务。卢学裕表示,公司越大就更希望数据能够开放给公司的各个部门,数据可相互利用。但不能没有任何限制的去使用,所以需要对数据权限做管理。任务调度是整个工厂里面最重的部分。数据共享就是类似非常火的用户画像类数据,还有其他公共数据如IP库,这些数据具有公共特点,就不用重复计算,就可以通过数据共享的方式在各个团队之间使用这些数据。

数据管理,分为数据预览、元数据、数据源三部分。数据预览是每个团队用来互相了解数据的。

元数据,就是数据使用过程中要把非结构化的数据转换结构化的数据。元数据管理就是去了解每个字段的含义和机器解析。机器解析包括Mapreduce程序可直接读文件可解析,如用Impala、Spark和Hive同样也能解析,而不需要每个使用者再去格式化,再去解析这个数据。但面临的问题是数据一旦出现格式的转变或者某些字段的调整,以前任务可能都会出现问题,故一定要统一管理的地方。数据源,数据管理非常核心的是数据集成,能够把各个地方的数据集成到平台上来。

HDFS目录管理。有公共数据空间、业务数据空间、团队数据空间、个人数据空间、Yarn计算空间五部分。

(1)公共数据空间,是用来把公共数据放到上面,把维护权限和读的权限分开。这样大部分都是读这个空间,空间数据安全性等级相对来讲比较低,可以付给更多人。

(2)业务数据空间,因为每个业务数据的增长量是不一样的,甚至有些业务会出现如刚上来一个新功能,数据量迅速的增大,有的甚至会出现某个团队的数据增加,导致把整个集群空间全吃掉,又没有事先招呼。这种情况下做好业务间的限额配额是非常重要,防止某一个团队的增长导致整个集群出现一些问题。

(3)团队数据空间,就是把权限控制到个人,用来帮助做团队之间的数据协作。如把线上任务会放到团队账号中去,团队账号的权限要做好控制,权限不随便开放。团队人员发生变动后,整个团队任务不用再去切换账户而导致交接的复杂性。

(4)个人数据空间,数据工程师、开发工程师等是需要做一些调试或做自己的计算这就要给这些人一定空间的同时对其数据做配额。这是为了防止这些人过多的使用资源和为了空间不够需要清理数据时,哪些数据要清理,哪些数据不能清理一目了然。这样限制空间的情况下,这种废文件或者垃圾文件的积累会相对较少。

(5)Yarn计算空间,做配额限制呢是为了杜绝空间滥用的问题。卢学裕举例道,“之前发生过一件事,某人在Reduce里面写了一个死循环,不停的输出数据,导致整个集群很快就去报警。后来才发现这个计算造成的一些问题,最后差点导致那些日志上传、数据的写入都出问题,幸亏处理的比较及时。”所以,Yarn计算空间是需要做一个配额限制,防止对整个集群造成过大的影响。

卢学裕表示,小米数据存储格式统一采用的Parquet,优点在于其使用的是列式存储,支持Mapreduce、Hive、Impala、Spark和读取快占用空间少。

 

2.jpg


客户端数据接入两种模式优劣势


客户端数据接入。客户端指的是如说Wap、App等数据,存在方式有SDK和服务端Log两种模式。上图为两种模式的优劣势。

服务器端数据源。除前端数据源外,整个处理数据时还会有大量服务器端数据源需要处理。业务数据库类,用ETL工具做导入。服务器端日志,用Scribe将数据写入HDFS。

元数据管理。当公司业务变多后,每一个数据的处理方式都有可能不一样,这时候就凸显出元数据管理的重要性。如视频播放日志,分析师希望用Hive,用Impala直接写SQL去计算,但数据挖掘工程师就要去写Mapreduce,写Spark的方式去读,去解析。元数据管理就是要做数据统一,既能够满足Hive、Spark、Impala,还能满足Mapreduce。这样一来节省大家对数据理解、执行的时间。

3.jpg


元数据管理

如上图,小米数据工厂是每一份数据的描述都需要在数据工厂上提交,之后数据工厂会在MetaStore中做建表的同时带上元数据的行为,供Hive、Spark、Impala使用。数据管理还会生成Jave  Class,给Mapreduce使用。当去解析用某个数据时候,可以直接用这样的方式把它解析成Jave类。


4.jpg


计算管理

计算管理。卢学裕表示,计算是很重要的事情,数据管理相对来讲是一次性的活,计算就是很复杂的事情。计算任务数一天达到几千或过万时,就会变得非常复杂。对于计算管理这快优化,小米做了如上图的一些工作。

Docker。为了管理好这些纷繁的计算框架和模型,在计算的执行方面,小米使用Docker来解决对环境的不同需求和异构问题,并且与Hive、Impala、Spark这些不同的计算模型都进行了对接,去适配不同应用场景计算不同数据的模型。另外,在不同业务场景下,同一个计算逻辑也可以选用不同的计算模型,Docker 的使用也避免了资源的浪费。比如一个计算任务每天凌晨运行,为了追求吞吐量,可以放到Hive里跑;还是同样一个计算模型,现在就要跑,可以不用更改,就放到Impala里运行。Docker不仅解决了环境的异构,也解决了资源问题。另外,Docker的环境适应性很强,做横向扩展会比较容易。对于数据隐私方面,小米考虑得非常重。采用Docker与自身安全策略的综合,小米用户数据的隐私和安全性也得到了极其严格的控制。

小团队如何玩转大数据

小团队玩大数据会面临哪些问题?小团队会面临人力资源不足,技术储备不足,时间有限等问题。面对这些问题,卢学裕在技术选型上给出如下三个建议。

(1)选择热门技术。因为人才比较多,相对获取这样人才会比较容易。技术成熟,因为小团队没有时间去踩坑。还有帮助多,这如说网上文档帮助、社群帮助,朋友帮助等。

(2)够用。针对一些小团队或者初创公司的特点,业务变化特别快,也不稳定,这种情况下做到够用就好,不需要过分的设计和采用过重的系统。尽量根据业务驱动,业务需要什么数据就抓什么数据。

(3)演进。随着需求的变化需要不断的演进,包括系统演进、使用方式演进。

一定要做好数据积累。卢学裕表示,无论你用什么样的技术,用Hadoop也好,不用Hadoop也好,一定要做好数据的积累,这是对一家数据公司非常重要的部分。这就需要提前规划好数据,还要避免逻辑孤岛。还需要注意ID问题,也就是关联的问题。当采集了数据,却发现没有采用户ID,没有提前做好这个规划,当算到用户级别时候那就尴尬了。


大家工作学习遇到HBase技术问题,把问题发布到HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup),非常欢迎大家积极投稿。

微信图片_20180623105555.jpg



现任中国HBase技术社区成员,了解互联网金融、大数据相关知识,有意向进入小米,可协助帮忙内推,直达CEO雷布斯邮箱

qrcode_for_gh_e12b18786730_258_(3).jpg

 

hbase 读取数据的时候怎么找到最新版本的数据的。

hbaseLeo 回复了问题 • 3 人关注 • 2 个回复 • 424 次浏览 • 2018-07-23 15:01 • 来自相关话题

Hbase是如何做到强CP的?

hbasew0807m 回复了问题 • 1 人关注 • 2 个回复 • 845 次浏览 • 2018-07-20 15:13 • 来自相关话题

Phoenix的delete导致数据异常

phoenixPeng 回复了问题 • 4 人关注 • 2 个回复 • 1280 次浏览 • 2018-07-19 15:29 • 来自相关话题

hbase 删表过程是怎么样的

hbasePeng 回复了问题 • 3 人关注 • 2 个回复 • 497 次浏览 • 2018-07-18 10:14 • 来自相关话题


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

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