HBaseCon Asia 2019 Track 3 概要回顾

818 阅读9分钟


                           Track 3:Application


Track3是关于HBase应用的分享,来自腾讯、快手、滴滴、Pinterest、中国移动、中国人寿等多家公司的工程师为我们分享了HBase在应用和实践中遇到的问题和经验。

Track3-1: HBase at Tencent

PPT下载链接: http://t.cn/AijgoTGY

来自腾讯的工程师程广旭为我们带来了 HBase 在腾讯的业务中的应用场景和经验。

腾讯目前有90多个 HBase 集群,最大的集群有500多台节点。腾讯内部多个业务包括腾讯视频,微信支付和腾讯云等都在使用HBase服务。其首先分享了使用 HBase 进行数据迁移的经验:Replication 和 ExportSnapshot.在实际使用中,业务每天的数据量都很大,这些数据需要保存的周期要么很大,要么很小。因此采取了按天分表的方式,也就是每天会创建一个新的表,对于过期的数据,直接把当天的表删掉即可。其次分享了对带宽的优化。

写入HBase的流量主要有五个部分:

1.写入,2.WAL,3.Flush,4.Small Compaction,5.Major Compaction。优化的方法有:1.开启CellBlock的压缩。2.WAL的压缩。3.增大memstore,减少Flush,减少Compaction。4.减少Compaction的线程数目。5.关闭Major Compaction。6.按天建表。最后介绍了如何共享RestServer。当每个HBase集群搭建一个RestServer时,如果读取集群的请求很少,那么集群的RestServer资源比较浪费。腾讯做了一个改进,配置一个RestServer可以访问多个HBase集群,同时在MySQL里记了哪些表可以通过这种方式访问。

Track3-2: HBase at Kuaishou

PPT下载链接:http://t.cn/AijgodXA


来自快手的工程师徐明为我们分享了HBase在快手的应用和实践。

快手每天有大量的用户上传大量的视频,这部分视频大部分是几MB的对象,其存储方案是:数据直接存储在HDFS上,数据的索引存储在HBase上,而最新的数据则存储在memcache中。

为了提高HBase的可用性,加快故障恢复速度,快手自研了hawk系统,其包括master,agent,sniffer三个组件,由多个agent投票来确认一个节点是否挂了,然后由sniffer来处理挂的节点,并将有问题的节点迅速的从zk上删掉。同时快手做了一些优化来加速split log和assign region的过程。在Client端,则主要是确保有问题节点的region location能被快速清理掉。

RSGroup功能也在快手被大量使用,并做了一些优化。一个是添加了FallBack RSGroup,如果某个RSGroup的全部节点都挂了,就从这个FallBack RSGroup中选择机器;一个是添加了Global RSGroup,主要是满足监控需求,因为hbase的canary表需要分布在各个机器上。

快手还分享了其如何使用HBase来存储和分析海量数据的案例。比如要解决计算用户留存的问题,如果使用SQL的话执行很慢,快手使用了Bitmap的解决方案。把需要提取的维度转化成Bitmap,使用空间来减少消耗的时间。使用MR把选择的维度转成Bitmap,把Bitmap切成小块,Bitmap的数据及meta都导入到HBase中。

Track3-3: HBase at DiDi

PPT下载链接:

http://t.cn/AijgK2qq


来自滴滴的工程师唐天航为我们带来了HBase在滴滴的业务中的应用场景和经验。

滴滴国内的HBase集群有7个,海外国际化集群有4个。覆盖了滴滴全部的业务线,目前服务的项目大概有200多个,数据级是PB级。

滴滴使用HBase主要有两个场景:1.离线数据查询,包括Phoenix、Kylin、openTSDB的使用,2.GeoMesa系统构建的轨迹数据系统,可用于实时查询、监控和特征工程的数据挖掘。GeoMesa系统提供导入和导出接口,导入接口支持Native API、MR/BulkLoad、StreamingSQL,导出接口支持SparkCore、SparkSQL、CQL、GeoServer。这样使用GeoMesa可以有以下好处:1、开箱即用,2、类SQL文本语言支持,3、横向可扩张、4基于Hadoop生态。

滴滴在实践中对zookeeper的改进为:分离server和client所依赖ZK,当client端的突发大量访问造成zk不可用时,不会影响到服务端。(HBASE-20159,ZOOKEEPER-832)。滴滴在HBase/Phoenix上的改进,主要是Quota设置、replication以及查询优化(HBASE-21964,HBASE-22620,PHOENIX-5242)

最后, 滴滴建立了从Client端到HAProxy,然后到Thriftserver和QueryServer上,之后再到Hbase的多元用户全链路追踪,能够更加有效提升运维效率。

Track3-4: Phoenix Best Practice In China Life Insurance Company

PPT下载链接:http://t.cn/AijgKfM4

来自中国人寿的工程师袁利鸥为我们分享了Phoenix在中国人寿的最佳实践

中国人寿目前总的节点数有200多个,Phoenix集群的节点是30多个。集群整体的数据量是1300T,HBase单表最大30T,每天大概会有上百个脚本运行。

Phoenix在中国人寿的应用场景:数据源是从核心的交易系统上产生,然后通过SharePlex,打到Kafka上,数据从Kafka实时接入到Phoenix集群上,通过查询服务,为APP提供权益信息访问。从物理架构上看,最底层是Phoenix集群,向上有两条链路,一条是Phoenix Gateway,另一条是实时查询服务,通过负载平衡,承接到Weblogic集群上。

袁利鸥介绍了Spark Streaming的设计:1、对于整合后的表,会加入一些控制字段,记录更新时间、删除还是插入操作等。2、实时同步程序,按照表名或者统计字段做区分。

袁利鸥接着介绍了关于Phoenix的优化,把Phoenix的系统表做为一个分组,数据表放在另一个分组中。客户端访问时,每天会拉去一次元数据,随后就不用去访问Phoenix 系统表,可以降低负载。基于HBase的一些优化包括:1、Region Balance By Table。 2、G1GC

3、Manual MajorCompaction

Track3-5: HBase Practice in China Mobile

PPT下载链接:http://t.cn/AijgOxGa

来自中国移动苏州研发中心Hbase负责人陈叶超介绍了Hbase在中国移动的实践


中国移动目前大概有6000个物理节点,100多个集群,几十PB数据,单集群最大600多个节点,单表最大1.6PB,最大3000万并发访问,存储的数据采用较高压缩比进行压缩,减少存储空间。

HBase在中国移动的几个应用场景:1.北京移动的流量清单,比如手机使用流量,这个在掌上营业厅是可以查到的。2、DPI数据,主要是信令相关的,有一些网络优化的设计。3、监控和日志,包括小图片、用户标签、爬虫和市场营销等。

中国移动在实践中通过数据抽样解决BulkLoad中数据倾斜问题。数据压缩在Flush 和BulkLoad阶段都不开启,只在compaction阶段使用,提高读写性能。混合使用SSD/HDD磁盘,compaction后数据存储在HDD磁盘。对于更好的使用SSD,中国移动做了如下工作:1,backport HSM To HBase 1.2.6版本。2,所有用户过来的写入路径都是SSD的,写性能提高50%。此外,中国移动还开发了HBase集群智能运维工具:Slider和RegionServerGroup,可以控制资源的分配,并基于Region做了一套权限认证体系。

Track3-6: Recent work on HBase at Pinterest

PPT下载链接:http://t.cn/AijgO0KU

来自Pinterest 的技术lead徐良鸿分享了HBase在Pinterest的最新进展

Pinterest目前集群规模50台,都部署在AWS上,数据量大概在PB级。2013年开始使用HBase 0.94 , 2016年升级为1.2版本。

Pinterest通过Apache Omid实现HBase对事务的支持,使用中发现Omid存在性能瓶颈,随后自研Sparrow系统,主要改进有:1,将commit操作移到客户端,解决Transaction Manager 单点问题。2,将Transaction Manager 改为多线程实现,begin操作可以不用等待commit完成。Sparrow与Omid相比,对于P99延时,Begin阶段有100倍降低,commit阶段也有3倍降低。

Pinterest自研了Argus系统,与Kafka结合使用,提供WAL通知机制。大概的实现为:需要通知机制的数据会在client写入时添加标记,这些标记会被传到WAL层面,通过Kafka将WAL提供给 Argus Observer进行数据处理,处理方式是用户自定义的。

Pinterest基于开源Lily实现Ixia,用于实时构建HBase二级索引,同时整合了Muse,实现类SQL查询。大概的实现:写入HBase的数据会传到Replication Proxy,通过Kafka打到Indexer中,index manager会读取HBase数据的列,如果需要建索引,会将数据写入Muse中,Muse会根据数据的schema做检索,query会在Muse中查询,需要时会查询HBase

徐良鸿介绍了Argus和Ixia设计的好处:1、基于异步的复制机制,对写入的影响很小。2、与HBase系统独立,分开运行,可以很快的进行数据处理。

Track3-7 HBase at Tencent Cloud

PPT下载链接:http://t.cn/AijgOeGJ

来自腾讯的工程师陈龙为我们分享了HBase在腾讯云上的经验。

云上服务会遇到很多管理和用户相关的问题。陈龙说明了云服务的3个挑战:1、大量的技术咨询工作。2、紧急情况的处理。3、故障定位分析。并结合两个案例分析云服务的挑战。

腾讯云在监控方面,通过OpenTSDB收集table和region的metirc, 用户可以登录云监控,设置Qps到某一阈值后,做反向通知。

陈龙分析了云上的故障有4类原因:

1、外部因素,例如资源泄露,大量请求,coprocessor问题

2、硬件因素,磁盘、网络、CVM,资源

3、存储因素,块丢失、读写超时

4、配置因素,jvm、memstore、blockcache、flushsize

腾讯云通过提供文档,工具和监控等三个方式,解决在云上遇到的多种问题。陈龙最后分享了监控系统的架构。分享了云上管理服务的架构,比如需要快速的扩容或者缩容集群等。

转载请注明出处“小米云技术”