Track 3：Application
Track3是关于HBase应用的分享，来自腾讯、快手、滴滴、Pinterest、中国移动、中国人寿等多家公司的工程师为我们分享了HBase在应用和实践中遇到的问题和经验。
来自腾讯的工程师程广旭为我们带来了 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在快手的应用和实践。
为了提高 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在中国移动的实践
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
腾讯云通过提供文档，工具和监控等三个方式，解决在云上遇到的多种问题。陈龙最后分享了监控系统的架构。分享了云上管理服务的架构，比如需要快速的扩容或者缩容集群等。
转载请注明出处“小米云技术”
