2019 HBase Meetup 演讲者和议题征集

过往记忆 发表了文章 • 0 个评论 • 62 次浏览 • 3 天前 • 来自相关话题

HBase Meetup 会议由 HBase技术社区主办,在全国各大城市举办。在过去的2018年,我们在北京、上海、杭州、深圳以及武汉等城市举办了9场 HBase Meetup 会议,来自各大公司的 HBase PMC、committer 以及 HBase 开发者共聚一堂,为大家分享了 HBase 技术解析及应用实践。 
 
2019年,我们继续在全国举办 HBase 线下交流会。现向大家征集这几次会议的大会演讲者和议题,如果大家有意来分享,可以到 http://hbasegroup.mikecrm.com/zh19LHN 参加调查问卷,欢迎大家踊跃参与。同时愿意主动主办的公司,也可以来联系我。
 
议题范围:HBase、Spark、Phoenix、Solr、时序、时空以及图等使用案例,相关经验等。
投送议题时需要说明议题名称和简介,PPT可后续完成。
 
报名咨询:
微信:iteblog (备注 HBase Meetup)
钉钉:rvix4rb

各地 Meetup 举办时间:
  查看全部
HBase Meetup 会议由 HBase技术社区主办,在全国各大城市举办。在过去的2018年,我们在北京、上海、杭州、深圳以及武汉等城市举办了9场 HBase Meetup 会议,来自各大公司的 HBase PMC、committer 以及 HBase 开发者共聚一堂,为大家分享了 HBase 技术解析及应用实践。 
 
2019年,我们继续在全国举办 HBase 线下交流会。现向大家征集这几次会议的大会演讲者和议题,如果大家有意来分享,可以到 http://hbasegroup.mikecrm.com/zh19LHN 参加调查问卷,欢迎大家踊跃参与。同时愿意主动主办的公司,也可以来联系我。
 
议题范围:HBase、Spark、Phoenix、Solr、时序、时空以及图等使用案例,相关经验等。
投送议题时需要说明议题名称和简介,PPT可后续完成。
 
报名咨询:
微信:iteblog (备注 HBase Meetup)
钉钉:rvix4rb

各地 Meetup 举办时间:
 

HBase Meetup 2019 年计划安排

过往记忆 发表了文章 • 4 个评论 • 368 次浏览 • 2019-01-02 16:49 • 来自相关话题

2018年我们在全国各地举办了9场HBase Meetup会议。2019年,我们将继续为大家举办 HBase Meetup 会议,目前计划安排如下:
 
2018年我们在全国各地举办了9场HBase Meetup会议。2019年,我们将继续为大家举办 HBase Meetup 会议,目前计划安排如下:
 

HBase在58的实践和应用

过往记忆 发表了文章 • 0 个评论 • 448 次浏览 • 2018-12-29 09:28 • 来自相关话题

本文是58何良均嘉宾在中国HBase技术社区第九届meetup-HBase典型应用场景与实践的分享。介绍内容:HBase在58的实践和应用,包括平台建设、生态建设、平台监控、平台运营等
 
本文是58何良均嘉宾在中国HBase技术社区第九届meetup-HBase典型应用场景与实践的分享。介绍内容:HBase在58的实践和应用,包括平台建设、生态建设、平台监控、平台运营等
 

图数据库 hgraphdb 介绍

过往记忆 发表了文章 • 0 个评论 • 267 次浏览 • 2018-12-24 10:04 • 来自相关话题

本文是阿里陈江嘉宾在中国HBase技术社区第九届meetup-HBase典型应用场景与实践的分享。
课程介绍::HGraphDB是一个使用HBase作为底层存储的图数据库,是Apache TinkerPop3接口的实现。
讲师:陈江——阿里高级技术专家
在分布式存储领域及数据库领域有非常丰富的经验。
  查看全部
本文是阿里陈江嘉宾在中国HBase技术社区第九届meetup-HBase典型应用场景与实践的分享。
课程介绍::HGraphDB是一个使用HBase作为底层存储的图数据库,是Apache TinkerPop3接口的实现。
讲师:陈江——阿里高级技术专家
在分布式存储领域及数据库领域有非常丰富的经验。
 

HBase 基本知识介绍及典型案例分析

过往记忆 发表了文章 • 0 个评论 • 393 次浏览 • 2018-12-24 10:01 • 来自相关话题

本文是阿里的吴阳平嘉宾在中国HBase技术社区第九届meetup-HBase典型应用场景与实践的分享。课程介绍:HBase基础知识介绍,Rowkey设计技巧,HBase企业级特性及组件介绍,HBase+Spark典型案例分析。
讲师:吴阳平——阿里云HBase业务架构师 「过往记忆博客( https://www.iteblog.com ) 博主。」
负责HBase时空、时序、分析、图等业务架构、业务场景以及车联网、物联网等行业的存储分析大数据方案。热衷于大数据(Hadoop、HBase、Spark等)相关技术。 查看全部
本文是阿里的吴阳平嘉宾在中国HBase技术社区第九届meetup-HBase典型应用场景与实践的分享。课程介绍:HBase基础知识介绍,Rowkey设计技巧,HBase企业级特性及组件介绍,HBase+Spark典型案例分析。
讲师:吴阳平——阿里云HBase业务架构师 「过往记忆博客( https://www.iteblog.com ) 博主。」
负责HBase时空、时序、分析、图等业务架构、业务场景以及车联网、物联网等行业的存储分析大数据方案。热衷于大数据(Hadoop、HBase、Spark等)相关技术。

HBase 2.0 在360的技术改进与应用实践

过往记忆 发表了文章 • 0 个评论 • 401 次浏览 • 2018-12-24 09:55 • 来自相关话题

本文是360的王小勇嘉宾在中国HBase技术社区第九届meetup-HBase典型应用场景与实践的分享。课程介绍:HBase在360的使用现状和发展历程,以及在升级HBase2.0的过程中发现的问题与改进。
讲师:王小勇——360系统部分布式存储方向架构师
在360先后负责hdfs的版本开发和功能定制化、参与并完成了hbase 0.8.9版本的定制化和多项技术升级;带领技术团队,hbase2.0的应用实践过程中主导了多项改进,推动了hbase从低版本到hbase 2.0版本的平滑过度和功能迁移。 查看全部
本文是360的王小勇嘉宾在中国HBase技术社区第九届meetup-HBase典型应用场景与实践的分享。课程介绍:HBase在360的使用现状和发展历程,以及在升级HBase2.0的过程中发现的问题与改进。
讲师:王小勇——360系统部分布式存储方向架构师
在360先后负责hdfs的版本开发和功能定制化、参与并完成了hbase 0.8.9版本的定制化和多项技术升级;带领技术团队,hbase2.0的应用实践过程中主导了多项改进,推动了hbase从低版本到hbase 2.0版本的平滑过度和功能迁移。

中国HBase技术社区第九届meetup-HBase典型应用场景与实践

过往记忆 发表了文章 • 0 个评论 • 165 次浏览 • 2018-12-18 19:38 • 来自相关话题

会议时间
2018年12月23日 14:00 ~ 2018年12月23日 18:00  (北京朝阳)360公司 A座一层发布厅,报名地址:http://www.huodongxing.com/event/1469391290300





 本期嘉宾介绍





本期活动主题

  13:30-14:00  

   签到

  14:00-14:40 

  HBase 2.0 在360的技术改进与应用实践       

  讲师:王小勇——360系统部分布式存储方向架构师

  介绍内容:HBase在360的使用现状和发展历程,以及在升级HBase2.0的过程中发现的问题与改进。

  14:40-15:20   

   HBase 基本知识介绍及典型案例分析

   讲师:吴阳平——阿里云HBase业务架构师

   介绍内容:HBase基础知识介绍,Rowkey设计技巧,HBase企业级特性及组件介绍,HBase+Spark典型案例分析。

  15:20-15:30   

   抽奖环节 送360、阿里、京东、58专属定制的礼品

  15:30-16:10    

   HBase在无界零售中的应用

   讲师:诸葛子房——京东大数据工程师

   介绍内容:Hbase存储的优势;Hbase案例分享;Hbase数据分析

  16:10-16:50    

   图数据库hgraphdb介绍

   讲师:陈江——阿里高级技术专家

   介绍内容:HGraphDB 是一个使用 HBase 作为底层存储的图数据库, 是 Apache TinkerPop 3 接口的实现。


  16:50-17:30   

   HBase在58的实践和应用

   讲师:何良均——58大数据工程师

   介绍内容:HBase在58的实践和应用,包括平台建设、生态建设、平台监控、平台运营等


主办:中国HBase技术社区

协办:360技术委员会;阿里云飞天八部多模型数据库组;云栖社区;360大学;360系统部,DataFun社区

合作伙伴:开源中国;SegmentFault;掘金;示说网

活动官方报名平台:活动行


技术社群及公众号推荐:


【HBase中国钉钉技术交流社群】:

为了更好的服务HBase开发者,我们启用了钉钉企业号。并每周在群内进行【技术分享直播】和【在线回答技术问题】。

欢迎大家入群,点击link 入群:  https://dwz.cn/Fvqv066s 查看全部
会议时间
2018年12月23日 14:00 ~ 2018年12月23日 18:00  (北京朝阳)360公司 A座一层发布厅,报名地址:http://www.huodongxing.com/event/1469391290300

head_image.jpg

 本期嘉宾介绍

微信图片_20181218193751.jpg

本期活动主题

  13:30-14:00  

   签到

  14:00-14:40 

  HBase 2.0 在360的技术改进与应用实践       

  讲师:王小勇——360系统部分布式存储方向架构师

  介绍内容:HBase在360的使用现状和发展历程,以及在升级HBase2.0的过程中发现的问题与改进。

  14:40-15:20   

   HBase 基本知识介绍及典型案例分析

   讲师:吴阳平——阿里云HBase业务架构师

   介绍内容:HBase基础知识介绍,Rowkey设计技巧,HBase企业级特性及组件介绍,HBase+Spark典型案例分析。

  15:20-15:30   

   抽奖环节 送360、阿里、京东、58专属定制的礼品

  15:30-16:10    

   HBase在无界零售中的应用

   讲师:诸葛子房——京东大数据工程师

   介绍内容:Hbase存储的优势;Hbase案例分享;Hbase数据分析

  16:10-16:50    

   图数据库hgraphdb介绍

   讲师:陈江——阿里高级技术专家

   介绍内容:HGraphDB 是一个使用 HBase 作为底层存储的图数据库, 是 Apache TinkerPop 3 接口的实现。


  16:50-17:30   

   HBase在58的实践和应用

   讲师:何良均——58大数据工程师

   介绍内容:HBase在58的实践和应用,包括平台建设、生态建设、平台监控、平台运营等


主办:中国HBase技术社区

协办:360技术委员会;阿里云飞天八部多模型数据库组;云栖社区;360大学;360系统部,DataFun社区

合作伙伴:开源中国;SegmentFault;掘金;示说网

活动官方报名平台:活动行


技术社群及公众号推荐:


【HBase中国钉钉技术交流社群】:

为了更好的服务HBase开发者,我们启用了钉钉企业号。并每周在群内进行【技术分享直播】和【在线回答技术问题】。

欢迎大家入群,点击link 入群:  https://dwz.cn/Fvqv066s

HBase在苏宁的应用和实践

过往记忆 发表了文章 • 0 个评论 • 619 次浏览 • 2018-11-19 10:21 • 来自相关话题

嘉宾介绍:张立明,苏宁高级研发工程师,HBase组件负责人,负责HBase平台的可用性和稳定性建设,热衷于大数据相关技术。
分享主题: HBase在苏宁的应用和实践
内容概要:介绍HBase在苏宁的主要使用场景,围绕使用场景介绍HBase在苏宁的使用现状及发展历程、功能增强及性能优化、运维监控。 查看全部
嘉宾介绍:张立明,苏宁高级研发工程师,HBase组件负责人,负责HBase平台的可用性和稳定性建设,热衷于大数据相关技术。
分享主题: HBase在苏宁的应用和实践
内容概要:介绍HBase在苏宁的主要使用场景,围绕使用场景介绍HBase在苏宁的使用现状及发展历程、功能增强及性能优化、运维监控。

Base在审计行业的应用

过往记忆 发表了文章 • 0 个评论 • 308 次浏览 • 2018-11-19 10:17 • 来自相关话题

嘉宾介绍:蒋晓明  现就职于毕马威智能创新空间,技术经理,主要从事数据平台的建设,热衷于大数据相关技术的研究
内容概要:a. 企业财务详情查询,HBase提供多维度快速查询;b. 企业自动化电子对账,HBase提供多维度匹配。
嘉宾介绍:蒋晓明  现就职于毕马威智能创新空间,技术经理,主要从事数据平台的建设,热衷于大数据相关技术的研究
内容概要:a. 企业财务详情查询,HBase提供多维度快速查询;b. 企业自动化电子对账,HBase提供多维度匹配。

中国HBase技术社区第八届MeetUp ——HBase典型应用场景与实践(南京站)

过往记忆 发表了文章 • 0 个评论 • 243 次浏览 • 2018-11-06 14:30 • 来自相关话题

HBase—Hadoop Database是一个分布式的、面向列的开源数据库,该技术来源于 Fay Chang 所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。HBase的特点是高可靠性、高性能、面向列、可伸缩的分布式存储系统,如今HBase已经广泛应用于各互联网行业。那么我们如何熟练掌握HBase技术及应用呢?

2018年11月17号,由中国HBase技术社区、DataFun社区联合氪空间主办的中国第八届HBase Meetup将来到南京,届时来自阿里云、毕马威、苏宁等公司HBase的专家们,将为大家分享HBase的应用实践。

主办方:中国HBase技术社区、DataFun社区
联合主办方:氪空间
合作伙伴:云栖社区、掘金社区
时间:2018.11.17,13:00-18:00
地点:南京市玄武区同仁西街7号南楼三层氪空间(地铁珠江路附近)
注:报名通过审核后,请持有效票二维码参会。




议程安排:




分享介绍:




玄陵(郭超) 阿里云 工程师
嘉宾介绍:玄陵(郭超),阿里云工程师,了解常见分布式大数据数据库,并有一定实战经验。
分享主题:阿里云HBase备份恢复的原理以及实践
内容概要: 主要介绍阿里云HBase的备份恢复的设计背景,原理以及实现,以及与业内大部分的分布式大数据数据库备份恢复的异同。





蒋晓明  毕马威智能创新空间 技术经理
嘉宾介绍:蒋晓明  现就职于毕马威智能创新空间,主要从事数据平台的建设,热衷于大数据相关技术的研究
分享主题:HBase在审计行业的应用
内容概要:a. 企业财务详情查询,HBase提供多维度快速查询;b. 企业自动化电子对账,HBase提供多维度匹配。






张立明 苏宁高级研发工程师&HBase组件负责人
嘉宾介绍:张立明,苏宁高级研发工程师,HBase组件负责人,负责HBase平台的可用性和稳定性建设,热衷于大数据相关技术。
分享主题: HBase在苏宁的应用和实践
内容概要:介绍HBase在苏宁的主要使用场景,围绕使用场景介绍HBase在苏宁的使用现状及发展历程、功能增强及性能优化、运维监控。

a. 使用现状及发展历程主要包括:集群规模、版本升级、集群部署方式;
b. 功能增强及性能优化主要包括:HA,全局限流,性能优化经验介绍;
c. 运维监控主要包括:系统稳定性和性能方面监控,以及根据监控信息快速定位问题经验介绍,表健康状态监控及自动优化。

主办方介绍:

中国HBase技术社区:为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,由阿里巴巴、小米、网易、滴滴、知乎等公司的HBase技术研究人员共同发起了组建:中国HBase技术社区(Chinese HBase Technical Community 简称CHTC)。

我们非常欢迎对HBase有技术激情的同学一起加入探讨HBase技术,同时诚邀广大HBase技术爱好者加入。大家在工作学习遇到HBase技术问题,可以把问题发布到中国HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术,关注HBase技术社区公众号(微信号:hbasegroup),邀请进社区的讨论群。




DataFun定位于最“实用”的数据科学社区,主要形式为线下的深度沙龙、线上的内容整理。希望将工业界专家在各自场景下的实践经验,通过DataFun的平台传播和扩散,对即将或已经开始相关尝试的同学有启发和借鉴。DataFun的愿景是:为大数据、人工智能从业者和爱好者打造一个分享、交流、学习、成长的平台,让数据科学领域的知识和经验更好的传播和落地产生价值。

DataFun社区成立至今,已经成功在全国范围内举办数十场线下技术沙龙,有超过一百位的业内专家参与分享,聚集了万余大数据、算法相关领域从业者。




联合主办方:




合作社区: 查看全部
HBase—Hadoop Database是一个分布式的、面向列的开源数据库,该技术来源于 Fay Chang 所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。HBase的特点是高可靠性、高性能、面向列、可伸缩的分布式存储系统,如今HBase已经广泛应用于各互联网行业。那么我们如何熟练掌握HBase技术及应用呢?

2018年11月17号,由中国HBase技术社区、DataFun社区联合氪空间主办的中国第八届HBase Meetup将来到南京,届时来自阿里云、毕马威、苏宁等公司HBase的专家们,将为大家分享HBase的应用实践。

主办方:中国HBase技术社区、DataFun社区
联合主办方:氪空间
合作伙伴:云栖社区、掘金社区
时间:2018.11.17,13:00-18:00
地点:南京市玄武区同仁西街7号南楼三层氪空间(地铁珠江路附近)
注:报名通过审核后,请持有效票二维码参会。
微信图片_20181106142054.jpg

议程安排:
1.jpg

分享介绍:
1.png

玄陵(郭超) 阿里云 工程师
嘉宾介绍:玄陵(郭超),阿里云工程师,了解常见分布式大数据数据库,并有一定实战经验。
分享主题:阿里云HBase备份恢复的原理以及实践
内容概要: 主要介绍阿里云HBase的备份恢复的设计背景,原理以及实现,以及与业内大部分的分布式大数据数据库备份恢复的异同。

2.jpg

蒋晓明  毕马威智能创新空间 技术经理
嘉宾介绍:蒋晓明  现就职于毕马威智能创新空间,主要从事数据平台的建设,热衷于大数据相关技术的研究
分享主题:HBase在审计行业的应用
内容概要:a. 企业财务详情查询,HBase提供多维度快速查询;b. 企业自动化电子对账,HBase提供多维度匹配。

32.jpg


张立明 苏宁高级研发工程师&HBase组件负责人
嘉宾介绍:张立明,苏宁高级研发工程师,HBase组件负责人,负责HBase平台的可用性和稳定性建设,热衷于大数据相关技术。
分享主题: HBase在苏宁的应用和实践
内容概要:介绍HBase在苏宁的主要使用场景,围绕使用场景介绍HBase在苏宁的使用现状及发展历程、功能增强及性能优化、运维监控。

a. 使用现状及发展历程主要包括:集群规模、版本升级、集群部署方式;
b. 功能增强及性能优化主要包括:HA,全局限流,性能优化经验介绍;
c. 运维监控主要包括:系统稳定性和性能方面监控,以及根据监控信息快速定位问题经验介绍,表健康状态监控及自动优化。

主办方介绍:

中国HBase技术社区:为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,由阿里巴巴、小米、网易、滴滴、知乎等公司的HBase技术研究人员共同发起了组建:中国HBase技术社区(Chinese HBase Technical Community 简称CHTC)。

我们非常欢迎对HBase有技术激情的同学一起加入探讨HBase技术,同时诚邀广大HBase技术爱好者加入。大家在工作学习遇到HBase技术问题,可以把问题发布到中国HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术,关注HBase技术社区公众号(微信号:hbasegroup),邀请进社区的讨论群。
4.jpg

DataFun定位于最“实用”的数据科学社区,主要形式为线下的深度沙龙、线上的内容整理。希望将工业界专家在各自场景下的实践经验,通过DataFun的平台传播和扩散,对即将或已经开始相关尝试的同学有启发和借鉴。DataFun的愿景是:为大数据、人工智能从业者和爱好者打造一个分享、交流、学习、成长的平台,让数据科学领域的知识和经验更好的传播和落地产生价值。

DataFun社区成立至今,已经成功在全国范围内举办数十场线下技术沙龙,有超过一百位的业内专家参与分享,聚集了万余大数据、算法相关领域从业者。
menu.saveimg_.savepath20181106143601_.jpg

联合主办方:
6.png

合作社区:
C80F6D6B-479D-4d5f-97FC-C5FA8B0159AD.png

8.jpg

9.png

HBase Meetup 成都站 PPT下载

过往记忆 发表了文章 • 0 个评论 • 219 次浏览 • 2018-11-05 10:12 • 来自相关话题

2018年11月3号,由中国HBase技术社区、DataFun社区、爱奇艺主办的中国第七届HBase Meetup来到成都。各位嘉宾分享了 HBase 相关的知识。
 
本次会议的分享议题如下:
 
分享主题:HBase2.0重新定义小对象实时存取,PPT下载:http://hbase.group/slides/167
 
嘉宾介绍:天引,专注在大数据领域,拥有多年分布式、高并发、大规模系统的研发与实践经验,先后参与hbase、phoenix、lindorm等产品的内核引擎研发,目前负责阿里上万节点的HBase As a Service的发展与落地。
内容概要:小对象,特别指1K~10MB范围的数据,比如图片,短视频,文档等广泛的存在于人工智能,医疗,教育,生活分享,电子商务等领域。HBase2.0在MOB技术的加持下重新定义小对象实时存取,具有低延迟,读写强一致,检索能力强,水平易扩展等关键能力。本文介绍了MOB特性的原理与实现,以及与经典对象存储相比,MOB带来的差异性与优势。

       2. 分享主题:HBase在爱奇艺的应用实践,PPT下载:http://hbase.group/slides/168 

嘉宾介绍:郑浩南,爱奇艺资深研发工程师,专注于大数据领域,负责Hadoop服务的运维研究以及DevOps平台开发。
内容概要:随着大数据存储计算对延时吞吐要求越来越高,需求日益复杂化,HBase在爱奇艺中被广泛应用和实践以应对多样化的业务场景。本次演讲将介绍HBase在爱奇艺的部署模式和使用场景,以及在爱奇艺私有云环境下的运维策略。
 
      3. 分享主题:Hbase在车联网的应用与实践,PPT下载:http://hbase.group/slides/169 

嘉宾介绍:巨鹏,g7高级数据运维工程师,负责g7的数据维护以及中间件的稳定性建设。
内容概要:为大家分享在大数据量的IOT车联网环境中,是如何发挥HBase优势解决实际问题以及他稳定性如何保障。 查看全部
2018年11月3号,由中国HBase技术社区、DataFun社区、爱奇艺主办的中国第七届HBase Meetup来到成都。各位嘉宾分享了 HBase 相关的知识。
 
本次会议的分享议题如下:
 
  1. 分享主题:HBase2.0重新定义小对象实时存取,PPT下载:http://hbase.group/slides/167

 
嘉宾介绍:天引,专注在大数据领域,拥有多年分布式、高并发、大规模系统的研发与实践经验,先后参与hbase、phoenix、lindorm等产品的内核引擎研发,目前负责阿里上万节点的HBase As a Service的发展与落地。
内容概要:小对象,特别指1K~10MB范围的数据,比如图片,短视频,文档等广泛的存在于人工智能,医疗,教育,生活分享,电子商务等领域。HBase2.0在MOB技术的加持下重新定义小对象实时存取,具有低延迟,读写强一致,检索能力强,水平易扩展等关键能力。本文介绍了MOB特性的原理与实现,以及与经典对象存储相比,MOB带来的差异性与优势。

       2. 分享主题:HBase在爱奇艺的应用实践,PPT下载:http://hbase.group/slides/168 

嘉宾介绍:郑浩南,爱奇艺资深研发工程师,专注于大数据领域,负责Hadoop服务的运维研究以及DevOps平台开发。
内容概要:随着大数据存储计算对延时吞吐要求越来越高,需求日益复杂化,HBase在爱奇艺中被广泛应用和实践以应对多样化的业务场景。本次演讲将介绍HBase在爱奇艺的部署模式和使用场景,以及在爱奇艺私有云环境下的运维策略。
 
      3. 分享主题:Hbase在车联网的应用与实践,PPT下载:http://hbase.group/slides/169 

嘉宾介绍:巨鹏,g7高级数据运维工程师,负责g7的数据维护以及中间件的稳定性建设。
内容概要:为大家分享在大数据量的IOT车联网环境中,是如何发挥HBase优势解决实际问题以及他稳定性如何保障。

HBase在车联网中的应用与实践

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

本次分享来自中国HBase技术社区第七届MeetUp成都站,分享嘉宾巨鹏 g7 高级数据运维工程师,负责g7的数据维护以及中间件的稳定性建设。

为大家分享在大数据量的IOT车联网环境中,是如何发挥HBase优势解决实际问题以及他稳定性如何保障。
 
本次分享来自中国HBase技术社区第七届MeetUp成都站,分享嘉宾巨鹏 g7 高级数据运维工程师,负责g7的数据维护以及中间件的稳定性建设。

为大家分享在大数据量的IOT车联网环境中,是如何发挥HBase优势解决实际问题以及他稳定性如何保障。
 

HBase在爱奇艺的应用实践

过往记忆 发表了文章 • 0 个评论 • 1026 次浏览 • 2018-11-03 20:14 • 来自相关话题

本次分享来自中国HBase技术社区第七届MeetUp成都站,分享嘉宾郑浩南 爱奇艺 资深研发工程师,专注于大数据领域,负责Hadoop服务的运维研究以及DevOps平台开发。

随着大数据存储计算对延时吞吐要求越来越高,需求日益复杂化,HBase在爱奇艺中被广泛应用和实践以应对多样化的业务场景。本次演讲将介绍HBase在爱奇艺的部署模式和使用场景,以及在爱奇艺私有云环境下的运维策略。
  查看全部
本次分享来自中国HBase技术社区第七届MeetUp成都站,分享嘉宾郑浩南 爱奇艺 资深研发工程师,专注于大数据领域,负责Hadoop服务的运维研究以及DevOps平台开发。

随着大数据存储计算对延时吞吐要求越来越高,需求日益复杂化,HBase在爱奇艺中被广泛应用和实践以应对多样化的业务场景。本次演讲将介绍HBase在爱奇艺的部署模式和使用场景,以及在爱奇艺私有云环境下的运维策略。
 

HBase2.0重新定义小对象实时存取

过往记忆 发表了文章 • 0 个评论 • 809 次浏览 • 2018-11-03 18:51 • 来自相关话题

本次分享来自中国HBase技术社区第七届MeetUp成都站,分享嘉宾天引 阿里巴巴 技术专家专注在大数据领域,拥有多年分布式、高并发、大规模系统的研发与实践经验,先后参与hbase、phoenix、lindorm等产品的内核引擎研发,目前负责阿里上万节点的HBase As a Service的发展与落地。
   
分享主题:HBase2.0重新定义小对象实时存取
内容概要:小对象,特别指1K~10MB范围的数据,比如图片,短视频,文档等广泛的存在于人工智能,医疗,教育,生活分享,电子商务等领域。HBase2.0在MOB技术的加持下重新定义小对象实时存取,具有低延迟,读写强一致,检索能力强,水平易扩展等关键能力。本文介绍了MOB特性的原理与实现,以及与经典对象存储相比,MOB带来的差异性与优势。
  查看全部
本次分享来自中国HBase技术社区第七届MeetUp成都站,分享嘉宾天引 阿里巴巴 技术专家专注在大数据领域,拥有多年分布式、高并发、大规模系统的研发与实践经验,先后参与hbase、phoenix、lindorm等产品的内核引擎研发,目前负责阿里上万节点的HBase As a Service的发展与落地。
   
分享主题:HBase2.0重新定义小对象实时存取
内容概要:小对象,特别指1K~10MB范围的数据,比如图片,短视频,文档等广泛的存在于人工智能,医疗,教育,生活分享,电子商务等领域。HBase2.0在MOB技术的加持下重新定义小对象实时存取,具有低延迟,读写强一致,检索能力强,水平易扩展等关键能力。本文介绍了MOB特性的原理与实现,以及与经典对象存储相比,MOB带来的差异性与优势。
 

HBase Coprocessor的实现与应用

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

本文来自于中国HBase技术社区武汉站HBase MeetUp线下交流会的烽火大数据平台研发负责人叶铿(云端浪子)。
HBase Coprocessor的实现与应用PPT下载:http://hbase.group/slides/159





本次分享的内容主要分为以下五点:
 
Coprocessor简介Endpoint服务端实现Endpoint客户端实现Observer实现二级索引Coprocessor应用场景

1.Coprocessor简介

HBase协处理器的灵感来自于Jeff Dean 09年的演讲,根据该演讲实现类似于Bigtable的协处理器,包括以下特性:每个表服务器的任意子表都可以运行代码客户端的高层调用接口(客户端能够直接访问数据表的行地址,多行读写会自动分片成多个并行的RPC调用),提供一个非常灵活的、可用于建立分布式服务的数据模型,能够自动化扩展、负载均衡、应用请求路由。HBase的协处理器灵感来自Bigtable,但是实现细节不尽相同。HBase建立框架为用户提供类库和运行时环境,使得代码能够在HBase Region Server和Master上面进行处理。





(1)实现目的
 
HBase无法轻易建立“二级索引”;执行求和、计数、排序等操作比较困难,必须通过MapReduce/Spark实现,对于简单的统计或聚合计算时,可能会因为网络与IO开销大而带来性能问题。

(2)灵感来源

灵感来源于Bigtable的协处理器,包含如下特性:
每个表服务器的任意子表都可以运行代码;客户端能够直接访问数据表的行,多行读写会自动分片成多个并行的RPC调用。

(3)提供接口
 
RegionObserver:提供客户端的数据操纵事件钩子:Get、Put、Delete、Scan等;WALObserver:提供WAL相关操作钩子;MasterObserver:提供DDL-类型的操作钩子。如创建、删除、修改数据表等;Endpoint:终端是动态RPC插件的接口,它的实现代码被安装在服务器端,能够通过HBase RPC调用唤醒。

(4)应用范围
 
通过使用RegionObserver接口可以实现二级索引的创建和维护;通过使用Endpoint接口,在对数据进行简单排序和sum,count等统计操作时,能够极大提高性能。

本文将通过具体实例来演示两种协处理器的开发方法的详细实现过程。

2.Endpoint服务端实现

在传统关系型数据库里面,可以随时的对某列进行求和sum,但是目前HBase目前所提供的接口,直接求和是比较困难的,所以先编写好服务端代码,并加载到对应的Table上,加载协处理器有几种方法,可以通过HTableDescriptor的addCoprocessor方法直接加载,同理也可以通过removeCoprocessor方法卸载协处理器。

Endpoint协处理器类似传统数据库的存储过程,客户端调用Endpoint协处理器执行一段Server端代码,并将Server端代码的结果返回给Client进一步处理,最常见的用法就是进行聚合操作。举个例子说明:如果没有协处理器,当用户需要找出一张表中的最大数据即max聚合操作,必须进行全表扫描,客户端代码遍历扫描结果并执行求max操作,这样的方法无法利用底层集群的并发能力,而将所有计算都集中到Client端统一执行, 效率非常低。但是使用Coprocessor,用户将求max的代码部署到HBase Server端,HBase将利用底层Cluster的多个节点并行执行求max的操作即在每个Region范围内执行求最大值逻辑,将每个Region的最大值在Region Server端计算出,仅仅将该max值返回给客户端。客户端进一步将多个Region的max进一步处理而找到其中的max,这样整体执行效率提高很多。但是一定要注意的是Coprocessor一定要写正确,否则导致RegionServer宕机。





 
Protobuf定义

如前所述,客户端和服务端之间需要进行RPC通信,所以两者间需要确定接口,当前版本的HBase的协处理器是通过Google Protobuf协议来实现数据交换的,所以需要通过Protobuf来定义接口。

如下所示:
option java_package = "com.my.hbase.protobuf.generated";
option java_outer_classname = "AggregateProtos";
option java_generic_services = true;
option java_generate_equals_and_hash = true;
option optimize_for = SPEED;

import "Client.proto";

message AggregateRequest {
required string interpreter_class_name = 1;
required Scan scan = 2;
optional bytes interpreter_specific_bytes = 3;
}

message AggregateResponse {
repeated bytes first_part = 1;
optional bytes second_part = 2;
}

service AggregateService {
rpc GetMax (AggregateRequest) returns (AggregateResponse);
rpc GetMin (AggregateRequest) returns (AggregateResponse);
rpc GetSum (AggregateRequest) returns (AggregateResponse);
rpc GetRowNum (AggregateRequest) returns (AggregateResponse);
rpc GetAvg (AggregateRequest) returns (AggregateResponse);
rpc GetStd (AggregateRequest) returns (AggregateResponse);
rpc GetMedian (AggregateRequest) returns (AggregateResponse);
}可以看到这里定义7个聚合服务RPC,名字分别叫做GetMax、GetMin、GetSum等,本文通过GetSum进行举例,其他的聚合RPC也是类似的内部实现。RPC有一个入口参数,用消息AggregateRequest表示;RPC的返回值用消息AggregateResponse表示。Service是一个抽象概念,RPC的Server端可以看作一个用来提供服务的Service。在HBase Coprocessor中Service就是Server端需要提供的Endpoint Coprocessor服务,主要用来给HBase的Client提供服务。AggregateService.java是由Protobuf软件通过终端命令“protoc filename.proto--java_out=OUT_DIR”自动生成的,其作用是将.proto文件定义的消息结构以及服务转换成对应接口的RPC实现,其中包括如何构建request消息和response响应以及消息包含的内容的处理方式,并且将AggregateService包装成一个抽象类,具体的服务以类的方法的形式提供。AggregateService.java定义Client端与Server端通信的协议,代码中包含请求信息结构AggregateRequest、响应信息结构AggregateResponse、提供的服务种类AggregateService,其中AggregateRequest中的interpreter_class_name指的是column interpreter的类名,此类的作用在于将数据格式从存储类型解析成所需类型。AggregateService.java由于代码太长,在这里就不贴出来了。

下面我们来讲一下服务端的架构,

首先,Endpoint Coprocessor是一个Protobuf Service的实现,因此需要它必须继承某个ProtobufService。我们在前面已经通过proto文件定义Service,命名为AggregateService,因此Server端代码需要重载该类,其次作为HBase的协处理器,Endpoint 还必须实现HBase定义的协处理器协议,用Java的接口来定义。具体来说就是CoprocessorService和Coprocessor,这些HBase接口负责将协处理器和HBase 的RegionServer等实例联系起来以便协同工作。Coprocessor接口定义两个接口函数:start和stop。

加载Coprocessor之后Region打开的时候被RegionServer自动加载,并会调用器start 接口完成初始化工作。一般情况该接口函数仅仅需要将协处理器的运行上下文环境变量CoprocessorEnvironment保存到本地即可。

CoprocessorEnvironment保存协处理器的运行环境,每个协处理器都是在一个RegionServer进程内运行并隶属于某个Region。通过该变量获取Region的实例等 HBase运行时环境对象。

Coprocessor接口还定义stop()接口函数,该函数在Region被关闭时调用,用来进行协处理器的清理工作。本文里我们没有进行任何清理工作,因此该函数什么也不干。

我们的协处理器还需要实现CoprocessorService接口。该接口仅仅定义一个接口函数 getService()。我们仅需要将本实例返回即可。HBase的Region Server在接收到客户端的调用请求时,将调用该接口获取实现RPCService的实例,因此本函数一般情况下就是返回自身实例即可。

完成以上三个接口函数之后,Endpoint的框架代码就已完成。每个Endpoint协处理器都必须实现这些框架代码而且写法雷同。





Server端的代码就是一个Protobuf RPC的Service实现,即通过Protobuf提供的某种服务。其开发内容主要包括:
 
实现Coprocessor的基本框架代码实现服务的RPC具体代码

Endpoint 协处理的基本框架

Endpoint 是一个Server端Service的具体实现,其实现有一些框架代码,这些框架代码与具体的业务需求逻辑无关。仅仅是为了和HBase运行时环境协同工作而必须遵循和完成的一些粘合代码。因此多数情况下仅仅需要从一个例子程序拷贝过来并进行命名修改即可。不过我们还是完整地对这些粘合代码进行粗略的讲解以便更好地理解代码。public Service getService() {
return this;
}

public void start(CoprocessorEnvironment env) throws IOException {
if(env instanceof RegionCoprocessorEnvironment) {
this.env = (RegionCoprocessorEnvironment)env;
} else {
throw new CoprocessorException("Must be loaded on a table region!");
}
}

public void stop(CoprocessorEnvironment env) throws IOException {
}Endpoint协处理器真正的业务代码都在每一个RPC函数的具体实现中。


在本文中,我们的Endpoint协处理器仅提供一个RPC函数即getSUM。我将分别介绍编写该函数的几个主要工作:了解函数的定义,参数列表;处理入口参数;实现业务逻辑;设置返回参数。
public void getSum(RpcController controller, AggregateRequest request, RpcCallbackdone) {
AggregateResponse response = null;
RegionScanner scanner = null;
long sum = 0L;
try {
ColumnInterpreter ignored = this.constructColumnInterpreterFromRequest(request);
Object sumVal = null;
Scan scan = ProtobufUtil.toScan(request.getScan());
scanner = this.env.getRegion().getScanner(scan);
byte[] colFamily = scan.getFamilies()[0];
NavigableSet qualifiers = (NavigableSet) scan.getFamilyMap().get(colFamily);
byte[] qualifier = null;
if (qualifiers != null && !qualifiers.isEmpty()) {
qualifier = (byte[]) qualifiers.pollFirst();
}

ArrayList results = new ArrayList();
boolean hasMoreRows = false;

do {
hasMoreRows = scanner.next(results);
int listSize = results.size();

for (int i = 0; i < listSize; ++i) {
//取出列值
Object temp = ignored.getValue(colFamily, qualifier,
(Cell) results.get(i));
if (temp != null) {
sumVal = ignored.add(sumVal, ignored.castToReturnType(temp));
}
}

results.clear();
} while (hasMoreRows);

if (sumVal != null) {
response = AggregateResponse.newBuilder().addFirstPart(
ignored.getProtoForPromotedType(sumVal).toByteString()).build();
}
} catch (IOException var27) {
ResponseConverter.setControllerException(controller, var27);
} finally {
if (scanner != null) {
try {
scanner.close();
} catch (IOException var26) {
;
}
}

}

log.debug("Sum from this region is " +
this.env.getRegion().getRegionInfo().getRegionNameAsString() + ": " + sum);
done.run(response);
}Endpoint类比于数据库的存储过程,其触发服务端的基于Region的同步运行再将各个结果在客户端搜集后归并计算。特点类似于传统的MapReduce框架,服务端Map客户端Reduce。

3.Endpoint客户端实现

HBase提供客户端Java包org.apache.hadoop.hbase.client.HTable,提供以下三种方法来调用协处理器提供的服务:
 
coprocessorService(byte[])coprocessorService(Class, byte[], byte[],Batch.Call),coprocessorService(Class, byte[], byte[],Batch.Call, Batch.Callback)
 





该方法采用rowkey指定Region。这是因为HBase客户端很少会直接操作Region,一般不需要知道Region的名字;况且在HBase中Region名会随时改变,所以用rowkey来指定Region是最合理的方式。使用rowkey可以指定唯一的一个Region,如果给定的Rowkey并不存在,只要在某个Region的rowkey范围内依然用来指定该Region。比如Region 1处理[row1, row100]这个区间内的数据,则rowkey=row1就由Region 1来负责处理,换句话说我们可以用row1来指定Region 1,无论rowkey等于”row1”的记录是否存在。CoprocessorService方法返回类型为CoprocessorRpcChannel的对象,该 RPC通道连接到由rowkey指定的Region上面,通过此通道可以调用该Region上面部署的协处理器RPC。





有时候客户端需要调用多个 Region上的同一个协处理器,比如需要统计整个Table的sum,在这种情况下,需要所有的Region都参与进来,分别统计自身Region内部的sum并返回客户端,最终客户端将所有Region的返回结果汇总,就可以得到整张表的sum。


这意味着该客户端同时和多个Region进行批处理交互。一个可行的方法是,收集每个 Region的startkey,然后循环调用第一种coprocessorService方法:用每一个Region的startkey 作为入口参数,获得RPC通道创建stub对象,进而逐一调用每个Region上的协处理器RPC。这种做法需要写很多的代码,为此HBase提供两种更加简单的 coprocessorService方法来处理多个Region的协处理器调用。先来看第一种方法 coprocessorService(Class, byte[],byte[],Batch.Call),

该方法有 4 个入口参数。第一个参数是实现RPC的Service 类,即前文中的AggregateService类。通过它,HBase就可以找到相应的部署在Region上的协处理器,一个Region上可以部署多个协处理器,客户端必须通过指定Service类来区分究竟需要调用哪个协处理器提供的服务。

要调用哪些Region上的服务则由startkey和endkey来确定,通过 rowkey范围即可确定多个 Region。为此,coprocessorService方法的第二个和第三个参数分别是 startkey和endkey,凡是落在[startkey,endkey]区间内的Region都会参与本次调用。

第四个参数是接口类Batch.Call。它定义了如何调用协处理器,用户通过重载该接口的call()方法来实现客户端的逻辑。在call()方法内,可以调用RPC,并对返回值进行任意处理。即前文代码清单1中所做的事情。coprocessorService将负责对每个 Region调用这个call()方法。

coprocessorService方法的返回值是一个Map类型的集合。该集合的key是Region名字,value是Batch.Call.call方法的返回值。该集合可以看作是所有Region的协处理器 RPC 返回的结果集。客户端代码可以遍历该集合对所有的结果进行汇总处理。

这种coprocessorService方法的大体工作流程如下。首先它分析startkey和 endkey,找到该区间内的所有Region,假设存放在regionList中。然后,遍历regionList,为每一个Region调用Batch.Call,在该接口内,用户定义具体的RPC调用逻辑。最后coprocessorService将所有Batch.Call.call()的返回值加入结果集合并返回。





coprocessorService的第三种方法比第二个方法多了一个参数callback。coprocessorService第二个方法内部使用HBase自带的缺省callback,该缺省 callback将每个Region的返回结果都添加到一个Map类型的结果集中,并将该集合作为coprocessorService方法的返回值。

HBase 提供第三种coprocessorService方法允许用户定义callback行为,coprocessorService 会为每一个RPC返回结果调用该callback,用户可以在callback 中执行需要的逻辑,比如执行sum累加。用第二种方法的情况下,每个Region协处理器RPC的返回结果先放入一个列表,所有的 Region 都返回后,用户代码再从该列表中取出每一个结果进行累加;用第三种方法,直接在callback中进行累加,省掉了创建结果集合和遍历该集合的开销,效率会更高一些。

因此我们只需要额外定义一个callback即可,callback是一个Batch.Callback接口类,用户需要重载其update方法。
 
public S sum(final HTable table, final ColumnInterpreter<R, S, P, Q, T> ci,final Scan scan)throws Throwable {

final AggregateRequest requestArg = validateArgAndGetPB(scan, ci, false);

class SumCallBack implements Batch.Callback {

S sumVal = null;

public S getSumResult() {
return sumVal;
}

@Override
public synchronized void update(byte[] region, byte[] row, S result) {
sumVal = ci.add(sumVal, result);
}}

SumCallBack sumCallBack = new SumCallBack();
table.coprocessorService(AggregateService.class, scan.getStartRow(), scan.getStopRow(),
new Batch.Call<AggregateService, S>() {
@Override
public S call(AggregateService instance) throws IOException {
ServerRpcController controller = new ServerRpcController();
BlockingRpcCallback<AggregateResponse> rpcCallback =
new BlockingRpcCallback<AggregateResponse>();
//RPC 调用
instance.getSum(controller, requestArg, rpcCallback);
AggregateResponse response = rpcCallback.get();
if (controller.failedOnException()) {
throw controller.getFailedOn();
}
if (response.getFirstPartCount() == 0) {
return null;
}
ByteString b = response.getFirstPart(0);
T t = ProtobufUtil.getParsedGenericInstance(ci.getClass(), 4, b);
S s = ci.getPromotedValueFromProto(t);
return s;
}
}, sumCallBack);
return sumCallBack.getSumResult();4.Observer实现二级索引

Observer类似于传统数据库中的触发器,当发生某些事件的时候这类协处理器会被 Server 端调用。Observer Coprocessor是一些散布在HBase Server端代码的 hook钩子, 在固定的事件发生时被调用。比如:put操作之前有钩子函数prePut,该函数在pu 操作执 行前会被Region Server调用;在put操作之后则有postPut 钩子函数。




 
RegionObserver工作原理

RegionObserver提供客户端的数据操纵事件钩子,Get、Put、Delete、Scan,使用此功能能够解决主表以及多个索引表之间数据一致性的问题





 
客户端发出put请求;该请求被分派给合适的RegionServer和Region;coprocessorHost拦截该请求,然后在该表上登记的每个 RegionObserver 上调用prePut();如果没有被preGet()拦截,该请求继续送到 region,然后进行处理;Region产生的结果再次被CoprocessorHost拦截,调用postGet();假如没有postGet()拦截该响应,最终结果被返回给客户端;
 





如上图所示,HBase可以根据rowkey很快的检索到数据,但是如果根据column检索数据,首先要根据rowkey减小范围,再通过列过滤器去过滤出数据,如果使用二级索引,可以先查基于column的索引表,获取到rowkey后再快速的检索到数据。





如图所示首先继承BaseRegionObserver类,重写postPut,postDelete方法,在postPut方法体内中写Put索引表数据的代码,在postDelete方法里面写Delete索引表数据,这样可以保持数据的一致性。

在Scan表的时候首先判断是否先查索引表,如果不查索引直接scan主表,如果走索引表通过索引表获取主表的rowkey再去查主表。

使用Elastic Search建立二级索引也是一样。

我们在同一个主机集群上同时建立了HBase集群和Elastic Search集群,存储到HBase的数据必须实时地同步到Elastic Search。而恰好HBase和Elastic Search都没有更新的概念,我们的需求可以简化为两步:
 
当一个新的Put操作产生时,将Put数据转化为json,索引到ElasticSearch,并把RowKey作为新文档的ID;当一个新的Delete操作产生时获取Delete数据的rowkey删除Elastic Search中对应的ID。

5.协处理的主要应用场景 
Observer允许集群在正常的客户端操作过程中可以有不同的行为表现;Endpoint允许扩展集群的能力,对客户端应用开放新的运算命令;Observer类似于RDBMS的触发器,主要在服务端工作;Endpoint类似于RDBMS的存储过程,主要在服务端工作;Observer可以实现权限管理、优先级设置、监控、ddl控制、二级索引等功能;Endpoint可以实现min、max、avg、sum、distinct、group by等功能。

例如HBase源码org.apache.hadoop.hbase.security.access.AccessController利用Observer实现对HBase进行了权限控制,有兴趣的读者可以看看相关代码。 查看全部
本文来自于中国HBase技术社区武汉站HBase MeetUp线下交流会的烽火大数据平台研发负责人叶铿(云端浪子)。
HBase Coprocessor的实现与应用PPT下载:http://hbase.group/slides/159

搜狗截图20181031141018.png

本次分享的内容主要分为以下五点:
 
  1. Coprocessor简介
  2. Endpoint服务端实现
  3. Endpoint客户端实现
  4. Observer实现二级索引
  5. Coprocessor应用场景


1.Coprocessor简介

HBase协处理器的灵感来自于Jeff Dean 09年的演讲,根据该演讲实现类似于Bigtable的协处理器,包括以下特性:每个表服务器的任意子表都可以运行代码客户端的高层调用接口(客户端能够直接访问数据表的行地址,多行读写会自动分片成多个并行的RPC调用),提供一个非常灵活的、可用于建立分布式服务的数据模型,能够自动化扩展、负载均衡、应用请求路由。HBase的协处理器灵感来自Bigtable,但是实现细节不尽相同。HBase建立框架为用户提供类库和运行时环境,使得代码能够在HBase Region Server和Master上面进行处理。

menu.saveimg_.savepath20181031141144_.jpg

(1)实现目的
 
  1. HBase无法轻易建立“二级索引”;
  2. 执行求和、计数、排序等操作比较困难,必须通过MapReduce/Spark实现,对于简单的统计或聚合计算时,可能会因为网络与IO开销大而带来性能问题。


(2)灵感来源

灵感来源于Bigtable的协处理器,包含如下特性:
  1. 每个表服务器的任意子表都可以运行代码;
  2. 客户端能够直接访问数据表的行,多行读写会自动分片成多个并行的RPC调用。


(3)提供接口
 
  1. RegionObserver:提供客户端的数据操纵事件钩子:Get、Put、Delete、Scan等;
  2. WALObserver:提供WAL相关操作钩子;
  3. MasterObserver:提供DDL-类型的操作钩子。如创建、删除、修改数据表等;
  4. Endpoint:终端是动态RPC插件的接口,它的实现代码被安装在服务器端,能够通过HBase RPC调用唤醒。


(4)应用范围
 
  1. 通过使用RegionObserver接口可以实现二级索引的创建和维护;
  2. 通过使用Endpoint接口,在对数据进行简单排序和sum,count等统计操作时,能够极大提高性能。


本文将通过具体实例来演示两种协处理器的开发方法的详细实现过程。

2.Endpoint服务端实现

在传统关系型数据库里面,可以随时的对某列进行求和sum,但是目前HBase目前所提供的接口,直接求和是比较困难的,所以先编写好服务端代码,并加载到对应的Table上,加载协处理器有几种方法,可以通过HTableDescriptor的addCoprocessor方法直接加载,同理也可以通过removeCoprocessor方法卸载协处理器。

Endpoint协处理器类似传统数据库的存储过程,客户端调用Endpoint协处理器执行一段Server端代码,并将Server端代码的结果返回给Client进一步处理,最常见的用法就是进行聚合操作。举个例子说明:如果没有协处理器,当用户需要找出一张表中的最大数据即max聚合操作,必须进行全表扫描,客户端代码遍历扫描结果并执行求max操作,这样的方法无法利用底层集群的并发能力,而将所有计算都集中到Client端统一执行, 效率非常低。但是使用Coprocessor,用户将求max的代码部署到HBase Server端,HBase将利用底层Cluster的多个节点并行执行求max的操作即在每个Region范围内执行求最大值逻辑,将每个Region的最大值在Region Server端计算出,仅仅将该max值返回给客户端。客户端进一步将多个Region的max进一步处理而找到其中的max,这样整体执行效率提高很多。但是一定要注意的是Coprocessor一定要写正确,否则导致RegionServer宕机。

menu.saveimg_.savepath20181031141342_.jpg

 
Protobuf定义

如前所述,客户端和服务端之间需要进行RPC通信,所以两者间需要确定接口,当前版本的HBase的协处理器是通过Google Protobuf协议来实现数据交换的,所以需要通过Protobuf来定义接口。

如下所示:
option java_package = "com.my.hbase.protobuf.generated";
option java_outer_classname = "AggregateProtos";
option java_generic_services = true;
option java_generate_equals_and_hash = true;
option optimize_for = SPEED;

import "Client.proto";

message AggregateRequest {
required string interpreter_class_name = 1;
required Scan scan = 2;
optional bytes interpreter_specific_bytes = 3;
}

message AggregateResponse {
repeated bytes first_part = 1;
optional bytes second_part = 2;
}

service AggregateService {
rpc GetMax (AggregateRequest) returns (AggregateResponse);
rpc GetMin (AggregateRequest) returns (AggregateResponse);
rpc GetSum (AggregateRequest) returns (AggregateResponse);
rpc GetRowNum (AggregateRequest) returns (AggregateResponse);
rpc GetAvg (AggregateRequest) returns (AggregateResponse);
rpc GetStd (AggregateRequest) returns (AggregateResponse);
rpc GetMedian (AggregateRequest) returns (AggregateResponse);
}
可以看到这里定义7个聚合服务RPC,名字分别叫做GetMax、GetMin、GetSum等,本文通过GetSum进行举例,其他的聚合RPC也是类似的内部实现。RPC有一个入口参数,用消息AggregateRequest表示;RPC的返回值用消息AggregateResponse表示。Service是一个抽象概念,RPC的Server端可以看作一个用来提供服务的Service。在HBase Coprocessor中Service就是Server端需要提供的Endpoint Coprocessor服务,主要用来给HBase的Client提供服务。AggregateService.java是由Protobuf软件通过终端命令“protoc filename.proto--java_out=OUT_DIR”自动生成的,其作用是将.proto文件定义的消息结构以及服务转换成对应接口的RPC实现,其中包括如何构建request消息和response响应以及消息包含的内容的处理方式,并且将AggregateService包装成一个抽象类,具体的服务以类的方法的形式提供。AggregateService.java定义Client端与Server端通信的协议,代码中包含请求信息结构AggregateRequest、响应信息结构AggregateResponse、提供的服务种类AggregateService,其中AggregateRequest中的interpreter_class_name指的是column interpreter的类名,此类的作用在于将数据格式从存储类型解析成所需类型。AggregateService.java由于代码太长,在这里就不贴出来了。

下面我们来讲一下服务端的架构,

首先,Endpoint Coprocessor是一个Protobuf Service的实现,因此需要它必须继承某个ProtobufService。我们在前面已经通过proto文件定义Service,命名为AggregateService,因此Server端代码需要重载该类,其次作为HBase的协处理器,Endpoint 还必须实现HBase定义的协处理器协议,用Java的接口来定义。具体来说就是CoprocessorService和Coprocessor,这些HBase接口负责将协处理器和HBase 的RegionServer等实例联系起来以便协同工作。Coprocessor接口定义两个接口函数:start和stop。

加载Coprocessor之后Region打开的时候被RegionServer自动加载,并会调用器start 接口完成初始化工作。一般情况该接口函数仅仅需要将协处理器的运行上下文环境变量CoprocessorEnvironment保存到本地即可。

CoprocessorEnvironment保存协处理器的运行环境,每个协处理器都是在一个RegionServer进程内运行并隶属于某个Region。通过该变量获取Region的实例等 HBase运行时环境对象。

Coprocessor接口还定义stop()接口函数,该函数在Region被关闭时调用,用来进行协处理器的清理工作。本文里我们没有进行任何清理工作,因此该函数什么也不干。

我们的协处理器还需要实现CoprocessorService接口。该接口仅仅定义一个接口函数 getService()。我们仅需要将本实例返回即可。HBase的Region Server在接收到客户端的调用请求时,将调用该接口获取实现RPCService的实例,因此本函数一般情况下就是返回自身实例即可。

完成以上三个接口函数之后,Endpoint的框架代码就已完成。每个Endpoint协处理器都必须实现这些框架代码而且写法雷同。

menu.saveimg_.savepath20181031141452_.jpg

Server端的代码就是一个Protobuf RPC的Service实现,即通过Protobuf提供的某种服务。其开发内容主要包括:
 
  1. 实现Coprocessor的基本框架代码
  2. 实现服务的RPC具体代码


Endpoint 协处理的基本框架

Endpoint 是一个Server端Service的具体实现,其实现有一些框架代码,这些框架代码与具体的业务需求逻辑无关。仅仅是为了和HBase运行时环境协同工作而必须遵循和完成的一些粘合代码。因此多数情况下仅仅需要从一个例子程序拷贝过来并进行命名修改即可。不过我们还是完整地对这些粘合代码进行粗略的讲解以便更好地理解代码。
public Service getService() {
return this;
}

public void start(CoprocessorEnvironment env) throws IOException {
if(env instanceof RegionCoprocessorEnvironment) {
this.env = (RegionCoprocessorEnvironment)env;
} else {
throw new CoprocessorException("Must be loaded on a table region!");
}
}

public void stop(CoprocessorEnvironment env) throws IOException {
}
Endpoint协处理器真正的业务代码都在每一个RPC函数的具体实现中。


在本文中,我们的Endpoint协处理器仅提供一个RPC函数即getSUM。我将分别介绍编写该函数的几个主要工作:了解函数的定义,参数列表;处理入口参数;实现业务逻辑;设置返回参数。
public void getSum(RpcController controller, AggregateRequest request, RpcCallbackdone) {
AggregateResponse response = null;
RegionScanner scanner = null;
long sum = 0L;
try {
ColumnInterpreter ignored = this.constructColumnInterpreterFromRequest(request);
Object sumVal = null;
Scan scan = ProtobufUtil.toScan(request.getScan());
scanner = this.env.getRegion().getScanner(scan);
byte[] colFamily = scan.getFamilies()[0];
NavigableSet qualifiers = (NavigableSet) scan.getFamilyMap().get(colFamily);
byte[] qualifier = null;
if (qualifiers != null && !qualifiers.isEmpty()) {
qualifier = (byte[]) qualifiers.pollFirst();
}

ArrayList results = new ArrayList();
boolean hasMoreRows = false;

do {
hasMoreRows = scanner.next(results);
int listSize = results.size();

for (int i = 0; i < listSize; ++i) {
//取出列值
Object temp = ignored.getValue(colFamily, qualifier,
(Cell) results.get(i));
if (temp != null) {
sumVal = ignored.add(sumVal, ignored.castToReturnType(temp));
}
}

results.clear();
} while (hasMoreRows);

if (sumVal != null) {
response = AggregateResponse.newBuilder().addFirstPart(
ignored.getProtoForPromotedType(sumVal).toByteString()).build();
}
} catch (IOException var27) {
ResponseConverter.setControllerException(controller, var27);
} finally {
if (scanner != null) {
try {
scanner.close();
} catch (IOException var26) {
;
}
}

}

log.debug("Sum from this region is " +
this.env.getRegion().getRegionInfo().getRegionNameAsString() + ": " + sum);
done.run(response);
}
Endpoint类比于数据库的存储过程,其触发服务端的基于Region的同步运行再将各个结果在客户端搜集后归并计算。特点类似于传统的MapReduce框架,服务端Map客户端Reduce。

3.Endpoint客户端实现

HBase提供客户端Java包org.apache.hadoop.hbase.client.HTable,提供以下三种方法来调用协处理器提供的服务:
 
  1. coprocessorService(byte[])
  2. coprocessorService(Class, byte[], byte[],Batch.Call),
  3. coprocessorService(Class, byte[], byte[],Batch.Call, Batch.Callback)

 

menu.saveimg_.savepath20181031141634_.jpg

该方法采用rowkey指定Region。这是因为HBase客户端很少会直接操作Region,一般不需要知道Region的名字;况且在HBase中Region名会随时改变,所以用rowkey来指定Region是最合理的方式。使用rowkey可以指定唯一的一个Region,如果给定的Rowkey并不存在,只要在某个Region的rowkey范围内依然用来指定该Region。比如Region 1处理[row1, row100]这个区间内的数据,则rowkey=row1就由Region 1来负责处理,换句话说我们可以用row1来指定Region 1,无论rowkey等于”row1”的记录是否存在。CoprocessorService方法返回类型为CoprocessorRpcChannel的对象,该 RPC通道连接到由rowkey指定的Region上面,通过此通道可以调用该Region上面部署的协处理器RPC。

menu.saveimg_.savepath20181031141702_.jpg

有时候客户端需要调用多个 Region上的同一个协处理器,比如需要统计整个Table的sum,在这种情况下,需要所有的Region都参与进来,分别统计自身Region内部的sum并返回客户端,最终客户端将所有Region的返回结果汇总,就可以得到整张表的sum。


这意味着该客户端同时和多个Region进行批处理交互。一个可行的方法是,收集每个 Region的startkey,然后循环调用第一种coprocessorService方法:用每一个Region的startkey 作为入口参数,获得RPC通道创建stub对象,进而逐一调用每个Region上的协处理器RPC。这种做法需要写很多的代码,为此HBase提供两种更加简单的 coprocessorService方法来处理多个Region的协处理器调用。先来看第一种方法 coprocessorService(Class, byte[],byte[],Batch.Call),

该方法有 4 个入口参数。第一个参数是实现RPC的Service 类,即前文中的AggregateService类。通过它,HBase就可以找到相应的部署在Region上的协处理器,一个Region上可以部署多个协处理器,客户端必须通过指定Service类来区分究竟需要调用哪个协处理器提供的服务。

要调用哪些Region上的服务则由startkey和endkey来确定,通过 rowkey范围即可确定多个 Region。为此,coprocessorService方法的第二个和第三个参数分别是 startkey和endkey,凡是落在[startkey,endkey]区间内的Region都会参与本次调用。

第四个参数是接口类Batch.Call。它定义了如何调用协处理器,用户通过重载该接口的call()方法来实现客户端的逻辑。在call()方法内,可以调用RPC,并对返回值进行任意处理。即前文代码清单1中所做的事情。coprocessorService将负责对每个 Region调用这个call()方法。

coprocessorService方法的返回值是一个Map类型的集合。该集合的key是Region名字,value是Batch.Call.call方法的返回值。该集合可以看作是所有Region的协处理器 RPC 返回的结果集。客户端代码可以遍历该集合对所有的结果进行汇总处理。

这种coprocessorService方法的大体工作流程如下。首先它分析startkey和 endkey,找到该区间内的所有Region,假设存放在regionList中。然后,遍历regionList,为每一个Region调用Batch.Call,在该接口内,用户定义具体的RPC调用逻辑。最后coprocessorService将所有Batch.Call.call()的返回值加入结果集合并返回。

menu.saveimg_.savepath20181031141730_.jpg

coprocessorService的第三种方法比第二个方法多了一个参数callback。coprocessorService第二个方法内部使用HBase自带的缺省callback,该缺省 callback将每个Region的返回结果都添加到一个Map类型的结果集中,并将该集合作为coprocessorService方法的返回值。

HBase 提供第三种coprocessorService方法允许用户定义callback行为,coprocessorService 会为每一个RPC返回结果调用该callback,用户可以在callback 中执行需要的逻辑,比如执行sum累加。用第二种方法的情况下,每个Region协处理器RPC的返回结果先放入一个列表,所有的 Region 都返回后,用户代码再从该列表中取出每一个结果进行累加;用第三种方法,直接在callback中进行累加,省掉了创建结果集合和遍历该集合的开销,效率会更高一些。

因此我们只需要额外定义一个callback即可,callback是一个Batch.Callback接口类,用户需要重载其update方法。
 
public S sum(final HTable table, final ColumnInterpreter<R, S, P, Q, T> ci,final Scan scan)throws Throwable {

final AggregateRequest requestArg = validateArgAndGetPB(scan, ci, false);

class SumCallBack implements Batch.Callback {

S sumVal = null;

public S getSumResult() {
return sumVal;
}

@Override
public synchronized void update(byte[] region, byte[] row, S result) {
sumVal = ci.add(sumVal, result);
}}

SumCallBack sumCallBack = new SumCallBack();
table.coprocessorService(AggregateService.class, scan.getStartRow(), scan.getStopRow(),
new Batch.Call<AggregateService, S>() {
@Override
public S call(AggregateService instance) throws IOException {
ServerRpcController controller = new ServerRpcController();
BlockingRpcCallback<AggregateResponse> rpcCallback =
new BlockingRpcCallback<AggregateResponse>();
//RPC 调用
instance.getSum(controller, requestArg, rpcCallback);
AggregateResponse response = rpcCallback.get();
if (controller.failedOnException()) {
throw controller.getFailedOn();
}
if (response.getFirstPartCount() == 0) {
return null;
}
ByteString b = response.getFirstPart(0);
T t = ProtobufUtil.getParsedGenericInstance(ci.getClass(), 4, b);
S s = ci.getPromotedValueFromProto(t);
return s;
}
}, sumCallBack);
return sumCallBack.getSumResult();
4.Observer实现二级索引

Observer类似于传统数据库中的触发器,当发生某些事件的时候这类协处理器会被 Server 端调用。Observer Coprocessor是一些散布在HBase Server端代码的 hook钩子, 在固定的事件发生时被调用。比如:put操作之前有钩子函数prePut,该函数在pu 操作执 行前会被Region Server调用;在put操作之后则有postPut 钩子函数。
menu.saveimg_.savepath20181031141817_.jpg

 
RegionObserver工作原理

RegionObserver提供客户端的数据操纵事件钩子,Get、Put、Delete、Scan,使用此功能能够解决主表以及多个索引表之间数据一致性的问题

menu.saveimg_.savepath20181031141844_.jpg

 
  1. 客户端发出put请求;
  2. 该请求被分派给合适的RegionServer和Region;
  3. coprocessorHost拦截该请求,然后在该表上登记的每个 RegionObserver 上调用prePut();
  4. 如果没有被preGet()拦截,该请求继续送到 region,然后进行处理;
  5. Region产生的结果再次被CoprocessorHost拦截,调用postGet();
  6. 假如没有postGet()拦截该响应,最终结果被返回给客户端;

 

menu.saveimg_.savepath20181031141924_.jpg

如上图所示,HBase可以根据rowkey很快的检索到数据,但是如果根据column检索数据,首先要根据rowkey减小范围,再通过列过滤器去过滤出数据,如果使用二级索引,可以先查基于column的索引表,获取到rowkey后再快速的检索到数据。

menu.saveimg_.savepath20181031141955_.jpg

如图所示首先继承BaseRegionObserver类,重写postPut,postDelete方法,在postPut方法体内中写Put索引表数据的代码,在postDelete方法里面写Delete索引表数据,这样可以保持数据的一致性。

在Scan表的时候首先判断是否先查索引表,如果不查索引直接scan主表,如果走索引表通过索引表获取主表的rowkey再去查主表。

使用Elastic Search建立二级索引也是一样。

我们在同一个主机集群上同时建立了HBase集群和Elastic Search集群,存储到HBase的数据必须实时地同步到Elastic Search。而恰好HBase和Elastic Search都没有更新的概念,我们的需求可以简化为两步:
 
  1. 当一个新的Put操作产生时,将Put数据转化为json,索引到ElasticSearch,并把RowKey作为新文档的ID;
  2. 当一个新的Delete操作产生时获取Delete数据的rowkey删除Elastic Search中对应的ID。


5.协处理的主要应用场景 
  1. Observer允许集群在正常的客户端操作过程中可以有不同的行为表现;
  2. Endpoint允许扩展集群的能力,对客户端应用开放新的运算命令;
  3. Observer类似于RDBMS的触发器,主要在服务端工作;
  4. Endpoint类似于RDBMS的存储过程,主要在服务端工作;
  5. Observer可以实现权限管理、优先级设置、监控、ddl控制、二级索引等功能;
  6. Endpoint可以实现min、max、avg、sum、distinct、group by等功能。


例如HBase源码org.apache.hadoop.hbase.security.access.AccessController利用Observer实现对HBase进行了权限控制,有兴趣的读者可以看看相关代码。

中国HBase技术社区第七届MeetUp ——HBase技术与应用实践(成都站)

过往记忆 发表了文章 • 0 个评论 • 554 次浏览 • 2018-10-29 10:45 • 来自相关话题

HBase—Hadoop Database是一个分布式的、面向列的开源数据库,该技术来源于Fay Chang 所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。HBase的特点是高可靠性、高性能、面向列、可伸缩的分布式存储系统,如今HBase已经广泛应用于各互联网行业。那么我们如何熟练掌握HBase技术及应用呢?

2018年11月3号,由中国HBase技术社区、DataFun社区、爱奇艺主办的中国第七届HBase Meetup将来到成都,届时来自阿里、爱奇艺、G7等公司HBase的专家们,将为大家分享HBase技术的相关应用与发展情况。
主办方:中国HBase技术社区、DataFun社区、爱奇艺
联合主办方:泰智会
合作伙伴:极客邦科技、掘金社区
时间:2018.11.3,13:00-18:00
地点:成都市武侯区世外桃源广场 B座8层(磨子桥A出口,沿科华北路向南860m)
注:报名通过审核后,请持有效票二维码参会。





议程安排




分享介绍






天引 阿里巴巴 技术专家
嘉宾介绍:
天引,专注在大数据领域,拥有多年分布式、高并发、大规模系统的研发与实践经验,先后参与hbase、phoenix、lindorm等产品的内核引擎研发,目前负责阿里上万节点的HBase As a Service的发展与落地
分享主题:HBase2.0重新定义小对象实时存取
内容概要:小对象,特别指1K~10MB范围的数据,比如图片,短视频,文档等广泛的存在于人工智能,医疗,教育,生活分享,电子商务等领域。HBase2.0在MOB技术的加持下重新定义小对象实时存取,具有低延迟,读写强一致,检索能力强,水平易扩展等关键能力。本文介绍了MOB特性的原理与实现,以及与经典对象存储相比,MOB带来的差异性与优势。







郑浩南 爱奇艺 资深研发工程师
嘉宾介绍:郑浩南,爱奇艺资深研发工程师,专注于大数据领域,负责Hadoop服务的运维研究以及DevOps平台开发。
分享主题:HBase在爱奇艺的应用实践
内容概要:随着大数据存储计算对延时吞吐要求越来越高,需求日益复杂化,HBase在爱奇艺中被广泛应用和实践以应对多样化的业务场景。本次演讲将介绍HBase在爱奇艺的部署模式和使用场景,以及在爱奇艺私有云环境下的运维策略。




巨鹏 g7 高级数据运维工程师
嘉宾介绍:巨鹏,g7高级数据运维工程师,负责g7的数据维护以及中间件的稳定性建设。
分享主题:Hbase在车联网的应用与实践
内容概要:为大家分享在大数据量的IOT车联网环境中,是如何发挥HBase优势解决实际问题以及他稳定性如何保障。
 
主办方介绍

中国HBase技术社区:为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,由阿里巴巴、小米、网易、滴滴、知乎等公司的HBase技术研究人员共同发起了组建:中国HBase技术社区(Chinese HBase Technical Community 简称CHTC)。

我们非常欢迎对HBase有技术激情的同学一起加入探讨HBase技术,同时诚邀广大HBase技术爱好者加入。大家在工作学习遇到HBase技术问题,可以把问题发布到中国HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术,关注HBase技术社区公众号(微信号:hbasegroup),邀请进社区的讨论群。




DataFun定位于最“实用”的数据科学社区,主要形式为线下的深度沙龙、线上的内容整理。希望将工业界专家在各自场景下的实践经验,通过DataFun的平台传播和扩散,对即将或已经开始相关尝试的同学有启发和借鉴。DataFun的愿景是:为大数据、人工智能从业者和爱好者打造一个分享、交流、学习、成长的平台,让数据科学领域的知识和经验更好的传播和落地产生价值。

DataFun社区成立至今,已经成功在全国范围内举办数十场线下技术沙龙,有超过一百位的业内专家参与分享,聚集了万余大数据、算法相关领域从业者。




爱奇艺成都研发中心成立于2018年初,以算法和数据研发为主,团队初期成员来自于谷歌、微软、百度、腾讯等公司。爱奇艺成都将和开源社区一同努力,为广大成都技术爱好者持续打造更好的技术环境和学习交流氛围。





联合主办方

泰智会是国内首家产业加速器,致力于整合产业链上下游资源,聚焦细分产业领域,运营创新创业载体,打造原始创新的产业生态系统。

泰智会成立于2015年10月,已在北京、深圳、上海、成都、漳州等地布局专业孵化器和垂直产业加速体系;完成了国内首家产业促进组织加速器、园区协同创新中心,运营了人工智能、虚拟现实、车联网等主题的众创空间,形成了高新技术企业+产业联盟+产业园区的三位一体产业生态培育体系。




  查看全部
HBase—Hadoop Database是一个分布式的、面向列的开源数据库,该技术来源于Fay Chang 所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。HBase的特点是高可靠性、高性能、面向列、可伸缩的分布式存储系统,如今HBase已经广泛应用于各互联网行业。那么我们如何熟练掌握HBase技术及应用呢?

2018年11月3号,由中国HBase技术社区、DataFun社区、爱奇艺主办的中国第七届HBase Meetup将来到成都,届时来自阿里、爱奇艺、G7等公司HBase的专家们,将为大家分享HBase技术的相关应用与发展情况。
主办方:中国HBase技术社区、DataFun社区、爱奇艺
联合主办方:泰智会
合作伙伴:极客邦科技、掘金社区
时间:2018.11.3,13:00-18:00
地点:成都市武侯区世外桃源广场 B座8层(磨子桥A出口,沿科华北路向南860m)
注:报名通过审核后,请持有效票二维码参会。

微信图片_20181029104745.png

议程安排
E7BCAF95-7769-49d5-9729-9234BE724B45.png

分享介绍

1.png


天引 阿里巴巴 技术专家
嘉宾介绍
天引,专注在大数据领域,拥有多年分布式、高并发、大规模系统的研发与实践经验,先后参与hbase、phoenix、lindorm等产品的内核引擎研发,目前负责阿里上万节点的HBase As a Service的发展与落地
分享主题:HBase2.0重新定义小对象实时存取
内容概要:小对象,特别指1K~10MB范围的数据,比如图片,短视频,文档等广泛的存在于人工智能,医疗,教育,生活分享,电子商务等领域。HBase2.0在MOB技术的加持下重新定义小对象实时存取,具有低延迟,读写强一致,检索能力强,水平易扩展等关键能力。本文介绍了MOB特性的原理与实现,以及与经典对象存储相比,MOB带来的差异性与优势。


2.jpg


郑浩南 爱奇艺 资深研发工程师
嘉宾介绍:郑浩南,爱奇艺资深研发工程师,专注于大数据领域,负责Hadoop服务的运维研究以及DevOps平台开发。
分享主题:HBase在爱奇艺的应用实践
内容概要:随着大数据存储计算对延时吞吐要求越来越高,需求日益复杂化,HBase在爱奇艺中被广泛应用和实践以应对多样化的业务场景。本次演讲将介绍HBase在爱奇艺的部署模式和使用场景,以及在爱奇艺私有云环境下的运维策略。
3.jpg

巨鹏 g7 高级数据运维工程师
嘉宾介绍:巨鹏,g7高级数据运维工程师,负责g7的数据维护以及中间件的稳定性建设。
分享主题:Hbase在车联网的应用与实践
内容概要:为大家分享在大数据量的IOT车联网环境中,是如何发挥HBase优势解决实际问题以及他稳定性如何保障。
 
主办方介绍

中国HBase技术社区:为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,由阿里巴巴、小米、网易、滴滴、知乎等公司的HBase技术研究人员共同发起了组建:中国HBase技术社区(Chinese HBase Technical Community 简称CHTC)。

我们非常欢迎对HBase有技术激情的同学一起加入探讨HBase技术,同时诚邀广大HBase技术爱好者加入。大家在工作学习遇到HBase技术问题,可以把问题发布到中国HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术,关注HBase技术社区公众号(微信号:hbasegroup),邀请进社区的讨论群。
4.jpg

DataFun定位于最“实用”的数据科学社区,主要形式为线下的深度沙龙、线上的内容整理。希望将工业界专家在各自场景下的实践经验,通过DataFun的平台传播和扩散,对即将或已经开始相关尝试的同学有启发和借鉴。DataFun的愿景是:为大数据、人工智能从业者和爱好者打造一个分享、交流、学习、成长的平台,让数据科学领域的知识和经验更好的传播和落地产生价值。

DataFun社区成立至今,已经成功在全国范围内举办数十场线下技术沙龙,有超过一百位的业内专家参与分享,聚集了万余大数据、算法相关领域从业者。
5.jpg

爱奇艺成都研发中心成立于2018年初,以算法和数据研发为主,团队初期成员来自于谷歌、微软、百度、腾讯等公司。爱奇艺成都将和开源社区一同努力,为广大成都技术爱好者持续打造更好的技术环境和学习交流氛围。
6.jpg


联合主办方

泰智会是国内首家产业加速器,致力于整合产业链上下游资源,聚焦细分产业领域,运营创新创业载体,打造原始创新的产业生态系统。

泰智会成立于2015年10月,已在北京、深圳、上海、成都、漳州等地布局专业孵化器和垂直产业加速体系;完成了国内首家产业促进组织加速器、园区协同创新中心,运营了人工智能、虚拟现实、车联网等主题的众创空间,形成了高新技术企业+产业联盟+产业园区的三位一体产业生态培育体系。
7.png

 

HBase基本知识介绍及典型案例分析

过往记忆 发表了文章 • 0 个评论 • 448 次浏览 • 2018-10-25 20:13 • 来自相关话题

本文来自于2018年10月20日由中国 HBase 技术社区在武汉举办的中国 HBase Meetup 第六次线下交流会。分享者为过往记忆。
本文ppt下载地址:http://hbase.group/slides/162





 
本次分享的内容主要分为以下五点:
 
HBase基本知识;HBase读写流程;RowKey设计要点;HBase生态介绍;HBase典型案例分析。

首先我们简单介绍一下 HBase 是什么。





HBase 最开始是受 Google 的 BigTable 启发而开发的分布式、多版本、面向列的开源数据库。其主要特点是支持上亿行、百万列,支持强一致性、并且具有高扩展、高可用等特点。

既然 HBase 是一种分布式的数据库,那么其和传统的 RMDB 有什么区别的呢?我们先来看看HBase表核心概念,理解这些基本的核心概念对后面我理解 HBase 的读写以及如何设计 HBase 表有着重要的联系。





HBase 表主要由以下几个元素组成:
 
RowKey:表中每条记录的主键;Column Family:列族,将表进行横向切割,后面简称CF;Column:属于某一个列族,可动态添加列;Version Number:类型为Long,默认值是系统时间戳,可由用户自定义;Value:真实的数据。

大家可以从上面的图看出:一行(Row)数据是可以包含一个或多个 Column Family,但是我们并不推荐一张 HBase 表的 Column Family 超过三个。Column 是属于 Column Family 的,一个 Column Family 包含一个或多个 Column。

在物理层面上,所有的数据其实是存放在 Region 里面的,而 Region 又由 RegionServer 管理,其对于的关系如下:




 
Region:一段数据的集合;RegionServer:用于存放Region的服务。

从上面的图也可以清晰看到,一个 RegionServer 管理多个 Region;而一个 Region 管理一个或多个 Column Family。
到这里我们已经了解了 HBase 表的组成,但是 HBase 表里面的数据到底是怎么存储的呢?





上面是一张从逻辑上看 HBase 表形式,这个和关系型数据库很类似。那么如果我们再深入看,可以看出,这张表的划分可以如下图表示。




从上图大家可以明显看出,这张表有两个 Column Family ,分别为 personal 和 office。而 personal 又有三列name、city 以及 phone;office 有两列 tel 以及 address。由于存储在 HBase 里面的表一般有上亿行,所以 HBase 表会对整个数据按照 RowKey 进行字典排序,然后再对这张表进行横向切割。切割出来的数据是存储在 Region 里面,而不同的 Column Family 虽然属于一行,但是其在底层存储是放在不同的 Region 里。所以这张表我用了六种颜色表示,也就是说,这张表的数据会被放在六个 Region 里面的,这就可以把数据尽可能的分散到整个集群。

在前面我们介绍了 HBase 其实是面向列的数据库,所以说一行 HBase 的数据其实是分了好几行存储,一个列对应一行,HBase 的 KV 结构如下:




为了简便期间,在后面的表示我们删除了类似于 Key Length 的属性,只保留 Row Key、Column Family、Column Qualifier等信息。所以 RowKey 为 Row1 的数据第一列表示为上图最后一行的形式。以此类推,整个表的存储就可以如下表示:




大家可以从上面的 kv 表现形式看出,Row11 的 phone 这列其实是没有数据的,在 HBase 的底层存储里面也就没有存储这列了,这点和我们传统的关系型数据库有很大的区别,有了这个特点, HBase 特别适合存储稀疏表。

我们前面也将了 HBase 其实是多版本的,那如果我们修改了 HBase 表的一列,HBase 又是如何存储的呢?




比如上如中我们将 Row1 的 city 列从北京修改为上海了,如果使用 KV 表示的话,我们可以看出其实底层存储了两条数据,这两条数据的版本是不一样的,最新的一条数据版本比之前的新。总结起来就是:
 
HBase支持数据多版本特性,通过带有不同时间戳的多个KeyValue版本来实现的;每次put,delete都会产生一个新的Cell,都拥有一个版本;默认只存放数据的三个版本,可以配置;查询默认返回最新版本的数据,可以通过制定版本号或版本数获取旧数据。

到这里我们已经了解了 HBase 表及其底层的 KV 存储了,现在让我们来了解一下 HBase 是如何读写数据的。首先我们来看看 HBase 的架构设计,这种图来自于社区:





HBase 的写过程如下:
先将数据写到WAL中;WAL 存放在HDFS之上;每次Put、Delete操作的数据均追加到WAL末端;持久化到WAL之后,再写到MemStore中;两者写完返回ACK到客户端。





MemStore 其实是一种内存结构,一个Column Family 对应一个MemStore,MemStore 里面的数据也是对 Rowkey 进行字典排序的,如下:




既然我们写数都是先写 WAL,再写 MemStore ,而 MemStore 是内存结构,所以 MemStore 总会写满的,将 MemStore 的数据从内存刷写到磁盘的操作成为 flush:




以下几种行为会导致 flush 操作
全局内存控制;MemStore使用达到上限;RegionServer的Hlog数量达到上限;手动触发;关闭RegionServer触发。

每次 flush 操作都是将一个 MemStore 的数据写到一个 HFile 里面的,所以上图中 HDFS 上有许多个 HFile 文件。文件多了会对后面的读操作有影响,所以 HBase 会隔一定的时间将 HFile 进行合并。根据合并的范围不同分为 Minor Compaction 和 Major Compaction:





Minor Compaction: 指选取一些小的、相邻的HFile将他们合并成一个更大的Hfile。
Major Compaction:

将一个column family下所有的 Hfiles 合并成更大的;
删除那些被标记为删除的数据、超过TTL(time-to-live)时限的数据,以及超过了版本数量限制的数据。

HBase 读操作相对于写操作更为复杂,其需要读取 BlockCache、MemStore 以及 HFile。




上图只是简单的表示 HBase 读的操作,实际上读的操作比这个还要复杂,我这里就不深入介绍了。

到这里,有些人可能就想到了,前面我们说 HBase 表按照 Rowkey 分布到集群的不同机器上,那么我们如何去确定我们该读写哪些 RegionServer 呢?这就是 HBase Region 查找的问题,




客户端按照上面的流程查找需要读写的 RegionServer 。这个过程一般是第一次读写的时候进行的,在第一次读取到元数据之后客户端一般会把这些信息缓存到自己内存中,后面操作直接从内存拿就行。当然,后面元数据信息可能还会变动,这时候客户端会再次按照上面流程获取元数据。

到这里整个读写流程得基本知识就讲完了。现在我们来看看 HBase RowKey 的设计要点。我们一般都会说,看 HBase 设计的好不好,就看其 RowKey 设计的好不好,所以RowKey 的设计在后面的写操作至关重要。我们先来看看 Rowkey 的作用




HBase 中的 Rowkey 主要有以下的作用:

读写数据时通过Row Key找到对应的Region
MemStore 中的数据按RowKey字典顺序排序
HFile中的数据按RowKey字典顺序排序

从下图可以看到,底层的 HFile 最终是按照 Rowkey 进行切分的,所以我们的设计原则是结合业务的特点,并考虑高频查询,尽可能的将数据打散到整个集群。




一定要充分分析清楚后面我们的表需要怎么查询。下面我们来看看三种比较场景的 Rowkey 设计方案。














这三种 Rowkey 的设计非常常见,具体的内容图片上也有了,我就不打文字了。

数据如果只是存储在哪里其实并没有什么用,我们还需要有办法能够使用到里面的数据。幸好的是,当前 HBase 有许多的组件可以满足我们各种需求。如下图是 HBase 比较常用的组件:




HBase 的生态主要有:
Phoenix:主要提供使用 SQL 的方式来查询 HBase 里面的数据。一般能够在毫秒级别返回,比较适合 OLTP 场景。Spark:我们可以使用 Spark 进行 OLAP 分析;也可以使用 Spark SQL 来满足比较复杂的 SQL 查询场景;使用 Spark Streaming 来进行实时流分析。Solr:原生的 HBase 只提供了 Rowkey 单主键,如果我们需要对 Rowkey 之外的列进行查找,这时候就会有问题。幸好我们可以使用 Solr 来建立二级索引/全文索引充分满足我们的查询需求。HGraphDB:HGraphDB是分布式图数据库。依托图关联技术,帮助金融机构有效识别隐藏在网络中的黑色信息,在团伙欺诈、黑中介识别等。GeoMesa:目前基于NoSQL数据库的时空数据引擎中功能最丰富、社区贡献人数最多的开源系统。OpenTSDB:基于HBase的分布式的,可伸缩的时间序列数据库。适合做监控系统;譬如收集大规模集群(包括网络设备、操作系统、应用程序)的监控数据并进行存储,查询。

下面简单介绍一下这些组件。






























有了这么多组件,我们都可以干什么呢?来看看 HBase 的典型案例。




HBase 在风控场景、车联网/物联网、广告推荐、电子商务等行业有这广泛的使用。下面是四个典型案例的架构,由于图片里有详细的文字,我就不再打出来了。



















  查看全部
本文来自于2018年10月20日由中国 HBase 技术社区在武汉举办的中国 HBase Meetup 第六次线下交流会。分享者为过往记忆。
本文ppt下载地址:http://hbase.group/slides/162

HBase2-iteblog.jpg

 
本次分享的内容主要分为以下五点:
 
  • HBase基本知识;
  • HBase读写流程;
  • RowKey设计要点;
  • HBase生态介绍;
  • HBase典型案例分析。


首先我们简单介绍一下 HBase 是什么。

HBase4-iteblog.jpg

HBase 最开始是受 Google 的 BigTable 启发而开发的分布式、多版本、面向列的开源数据库。其主要特点是支持上亿行、百万列,支持强一致性、并且具有高扩展、高可用等特点。

既然 HBase 是一种分布式的数据库,那么其和传统的 RMDB 有什么区别的呢?我们先来看看HBase表核心概念,理解这些基本的核心概念对后面我理解 HBase 的读写以及如何设计 HBase 表有着重要的联系。

HBase5-iteblog.jpg

HBase 表主要由以下几个元素组成:
 
  • RowKey:表中每条记录的主键;
  • Column Family:列族,将表进行横向切割,后面简称CF;
  • Column:属于某一个列族,可动态添加列;
  • Version Number:类型为Long,默认值是系统时间戳,可由用户自定义;
  • Value:真实的数据。


大家可以从上面的图看出:一行(Row)数据是可以包含一个或多个 Column Family,但是我们并不推荐一张 HBase 表的 Column Family 超过三个。Column 是属于 Column Family 的,一个 Column Family 包含一个或多个 Column。

在物理层面上,所有的数据其实是存放在 Region 里面的,而 Region 又由 RegionServer 管理,其对于的关系如下:
HBase6-iteblog.jpg

 
  • Region:一段数据的集合;
  • RegionServer:用于存放Region的服务。


从上面的图也可以清晰看到,一个 RegionServer 管理多个 Region;而一个 Region 管理一个或多个 Column Family。
到这里我们已经了解了 HBase 表的组成,但是 HBase 表里面的数据到底是怎么存储的呢?

HBase7-iteblog.jpg

上面是一张从逻辑上看 HBase 表形式,这个和关系型数据库很类似。那么如果我们再深入看,可以看出,这张表的划分可以如下图表示。
HBase8-iteblog.jpg

从上图大家可以明显看出,这张表有两个 Column Family ,分别为 personal 和 office。而 personal 又有三列name、city 以及 phone;office 有两列 tel 以及 address。由于存储在 HBase 里面的表一般有上亿行,所以 HBase 表会对整个数据按照 RowKey 进行字典排序,然后再对这张表进行横向切割。切割出来的数据是存储在 Region 里面,而不同的 Column Family 虽然属于一行,但是其在底层存储是放在不同的 Region 里。所以这张表我用了六种颜色表示,也就是说,这张表的数据会被放在六个 Region 里面的,这就可以把数据尽可能的分散到整个集群。

在前面我们介绍了 HBase 其实是面向列的数据库,所以说一行 HBase 的数据其实是分了好几行存储,一个列对应一行,HBase 的 KV 结构如下:
HBase9-iteblog.jpg

为了简便期间,在后面的表示我们删除了类似于 Key Length 的属性,只保留 Row Key、Column Family、Column Qualifier等信息。所以 RowKey 为 Row1 的数据第一列表示为上图最后一行的形式。以此类推,整个表的存储就可以如下表示:
HBase10-iteblog.jpg

大家可以从上面的 kv 表现形式看出,Row11 的 phone 这列其实是没有数据的,在 HBase 的底层存储里面也就没有存储这列了,这点和我们传统的关系型数据库有很大的区别,有了这个特点, HBase 特别适合存储稀疏表。

我们前面也将了 HBase 其实是多版本的,那如果我们修改了 HBase 表的一列,HBase 又是如何存储的呢?
HBase11-iteblog.jpg

比如上如中我们将 Row1 的 city 列从北京修改为上海了,如果使用 KV 表示的话,我们可以看出其实底层存储了两条数据,这两条数据的版本是不一样的,最新的一条数据版本比之前的新。总结起来就是:
 
  • HBase支持数据多版本特性,通过带有不同时间戳的多个KeyValue版本来实现的;
  • 每次put,delete都会产生一个新的Cell,都拥有一个版本;
  • 默认只存放数据的三个版本,可以配置;
  • 查询默认返回最新版本的数据,可以通过制定版本号或版本数获取旧数据。


到这里我们已经了解了 HBase 表及其底层的 KV 存储了,现在让我们来了解一下 HBase 是如何读写数据的。首先我们来看看 HBase 的架构设计,这种图来自于社区:

HBase13-iteblog.jpg

HBase 的写过程如下:
  • 先将数据写到WAL中;
  • WAL 存放在HDFS之上;
  • 每次Put、Delete操作的数据均追加到WAL末端;
  • 持久化到WAL之后,再写到MemStore中;
  • 两者写完返回ACK到客户端。


HBase14-iteblog.jpg

MemStore 其实是一种内存结构,一个Column Family 对应一个MemStore,MemStore 里面的数据也是对 Rowkey 进行字典排序的,如下:
HBase15-iteblog.jpg

既然我们写数都是先写 WAL,再写 MemStore ,而 MemStore 是内存结构,所以 MemStore 总会写满的,将 MemStore 的数据从内存刷写到磁盘的操作成为 flush:
HBase16-iteblog.jpg

以下几种行为会导致 flush 操作
  • 全局内存控制;
  • MemStore使用达到上限;
  • RegionServer的Hlog数量达到上限;
  • 手动触发;
  • 关闭RegionServer触发。


每次 flush 操作都是将一个 MemStore 的数据写到一个 HFile 里面的,所以上图中 HDFS 上有许多个 HFile 文件。文件多了会对后面的读操作有影响,所以 HBase 会隔一定的时间将 HFile 进行合并。根据合并的范围不同分为 Minor Compaction 和 Major Compaction:

HBase17-iteblog.jpg

Minor Compaction: 指选取一些小的、相邻的HFile将他们合并成一个更大的Hfile。
Major Compaction:

将一个column family下所有的 Hfiles 合并成更大的;
删除那些被标记为删除的数据、超过TTL(time-to-live)时限的数据,以及超过了版本数量限制的数据。

HBase 读操作相对于写操作更为复杂,其需要读取 BlockCache、MemStore 以及 HFile。
HBase18-iteblog.jpg

上图只是简单的表示 HBase 读的操作,实际上读的操作比这个还要复杂,我这里就不深入介绍了。

到这里,有些人可能就想到了,前面我们说 HBase 表按照 Rowkey 分布到集群的不同机器上,那么我们如何去确定我们该读写哪些 RegionServer 呢?这就是 HBase Region 查找的问题,
HBase19-iteblog.jpg

客户端按照上面的流程查找需要读写的 RegionServer 。这个过程一般是第一次读写的时候进行的,在第一次读取到元数据之后客户端一般会把这些信息缓存到自己内存中,后面操作直接从内存拿就行。当然,后面元数据信息可能还会变动,这时候客户端会再次按照上面流程获取元数据。

到这里整个读写流程得基本知识就讲完了。现在我们来看看 HBase RowKey 的设计要点。我们一般都会说,看 HBase 设计的好不好,就看其 RowKey 设计的好不好,所以RowKey 的设计在后面的写操作至关重要。我们先来看看 Rowkey 的作用
HBase21-iteblog.jpg

HBase 中的 Rowkey 主要有以下的作用:

读写数据时通过Row Key找到对应的Region
MemStore 中的数据按RowKey字典顺序排序
HFile中的数据按RowKey字典顺序排序

从下图可以看到,底层的 HFile 最终是按照 Rowkey 进行切分的,所以我们的设计原则是结合业务的特点,并考虑高频查询,尽可能的将数据打散到整个集群。
HBase22-iteblog.jpg

一定要充分分析清楚后面我们的表需要怎么查询。下面我们来看看三种比较场景的 Rowkey 设计方案。

HBase23-iteblog.jpg

HBase24-iteblog.jpg


HBase25-iteblog.jpg

这三种 Rowkey 的设计非常常见,具体的内容图片上也有了,我就不打文字了。

数据如果只是存储在哪里其实并没有什么用,我们还需要有办法能够使用到里面的数据。幸好的是,当前 HBase 有许多的组件可以满足我们各种需求。如下图是 HBase 比较常用的组件:
HBase27-iteblog.jpg

HBase 的生态主要有:
  • Phoenix:主要提供使用 SQL 的方式来查询 HBase 里面的数据。一般能够在毫秒级别返回,比较适合 OLTP 场景。
  • Spark:我们可以使用 Spark 进行 OLAP 分析;也可以使用 Spark SQL 来满足比较复杂的 SQL 查询场景;使用 Spark Streaming 来进行实时流分析。
  • Solr:原生的 HBase 只提供了 Rowkey 单主键,如果我们需要对 Rowkey 之外的列进行查找,这时候就会有问题。幸好我们可以使用 Solr 来建立二级索引/全文索引充分满足我们的查询需求。
  • HGraphDB:HGraphDB是分布式图数据库。依托图关联技术,帮助金融机构有效识别隐藏在网络中的黑色信息,在团伙欺诈、黑中介识别等。
  • GeoMesa:目前基于NoSQL数据库的时空数据引擎中功能最丰富、社区贡献人数最多的开源系统。
  • OpenTSDB:基于HBase的分布式的,可伸缩的时间序列数据库。适合做监控系统;譬如收集大规模集群(包括网络设备、操作系统、应用程序)的监控数据并进行存储,查询。


下面简单介绍一下这些组件。

HBase28-iteblog.jpg


HBase29-iteblog.jpg


HBase30-iteblog.jpg


HBase31-iteblog.jpg


HBase32-iteblog.jpg


HBase33-iteblog.jpg

有了这么多组件,我们都可以干什么呢?来看看 HBase 的典型案例。

HBase35-iteblog.jpg
HBase 在风控场景、车联网/物联网、广告推荐、电子商务等行业有这广泛的使用。下面是四个典型案例的架构,由于图片里有详细的文字,我就不再打出来了。
HBase36-iteblog.jpg


HBase37-iteblog.jpg


HBase38-iteblog.jpg


HBase39-iteblog.jpg

 

HBase基本知识介绍及典型案例分析

过往记忆 发表了文章 • 0 个评论 • 2019 次浏览 • 2018-10-25 13:44 • 来自相关话题


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

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