HBaseCon Asia 2019 Track 3 概要回顾

                           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能够有如下好处：一、开箱即用，二、类SQL文本语言支持，三、横向可扩张、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的设计：一、对于整合后的表，会加入一些控制字段，记录更新时间、删除仍是插入操做等。二、实时同步程序，按照表名或者统计字段作区分。

袁利鸥接着介绍了关于Phoenix的优化，把Phoenix的系统表作为一个分组，数据表放在另外一个分组中。客户端访问时，天天会拉去一次元数据，随后就不用去访问Phoenix 系统表，能够下降负载。基于HBase的一些优化包括：一、Region Balance By Table。 二、G1GC

三、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.北京移动的流量清单，好比手机使用流量，这个在掌上营业厅是能够查到的。二、DPI数据，主要是信令相关的，有一些网络优化的设计。三、监控和日志，包括小图片、用户标签、爬虫和市场营销等。

中国移动在实践中经过数据抽样解决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设计的好处：一、基于异步的复制机制，对写入的影响很小。二、与HBase系统独立，分开运行，能够很快的进行数据处理。

Track3-7 HBase at Tencent Cloud

PPT下载连接：http://t.cn/AijgOeGJ

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

云上服务会遇到不少管理和用户相关的问题。陈龙说明了云服务的3个挑战：一、大量的技术咨询工做。二、紧急状况的处理。三、故障定位分析。并结合两个案例分析云服务的挑战。

腾讯云在监控方面，经过OpenTSDB收集table和region的metirc, 用户能够登陆云监控，设置Qps到某一阈值后，作反向通知。

陈龙分析了云上的故障有4类缘由：

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

二、硬件因素，磁盘、网络、CVM，资源

三、存储因素，块丢失、读写超时

四、配置因素，jvm、memstore、blockcache、flushsize

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

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