58同城HBase平台建设实践

问题导读：
1.58同城HBase平台是如何建设的？
2.58同城HBase集群是如何进行迁移的？
3.58同城HBase集群是如何进行性能优化的？

一.HBase平台建设

1.简介

58大数据平台定位于服务数据开发分析人员，提高数据开发分析效率，提供便捷的开发分析流程，有效支持数据仓库及数据应用建设。其通用的基础能力包含数据存储、实时计算、数据查询分析等，是基于大家熟悉的Hadoop/HBase/Spark/Flink及相关OLAP等为主的大数据组件而建设的大数据基础能力平台。
58HBase平台是在58数据平台之上，致力于为集团提供稳定、高效、安全的海量数据存储、分析一站式服务。目前我们服务的业务比如58主站的帖子，用户画像、搜索推荐等业务场景，基本覆盖集团全部的业务场景，总体的规模14,000+张数据表，260个节点，800,000+QPS，3PB数据量。

2.HBase平台之数据接入-SCF网关

SCF是我们公司内部的微服务框架。我们通过使用这统一的服务为使用方提供HBase数据表的读写，而不是让用户直接拿着Zookeeper连接串直接操作HBase，这样做的好处是让我们的平台内聚和服务化，和最重要的对核心HBase集群的保护，补足HBase针对限流场景的不足，以及我们可以依托这一层的设计，能做到对异常流量调用的熔断，我们可以清晰的做到流量监控，也可以依托云设施的部署便利性，能做到比较不错的隔离、扩容，另外在这一层方便管理对Zookeeper集群的流量压力，而且还可以做跨集群数据高可用。当然它也会带来不足，我认为首要的不足就是我们提供接口的灵活性不足，不能覆盖全部的场景，比如有使用Filter这种协处理器的场景。

3.HBase平台之数据接入-通用导入导出

我们针对需要使用全量数据的业务场景，我们提供基于Snapshot的数据导出服务，和通用格式的Bulkload的服务，在便于支持业务使用的同时，还有效降低HBase集群压力，同时使用方开发成本降低，并且有这样的服务接口能增强平台内聚的同时还方便与其他平台打通。

4.HBase平台之Phoenix

Phoenix本身是一个开源成熟的SQL on HBase的解决方案，可以使用标准的JDBC API替代HBase 原生的Client API创建表，以及读写HBase数据。它有好多优秀的特性，支持二级索引；支持并行执行操作；计算移动到数据端；计算优化(谓词下推、semi-join)。
需要注意的地方：索引数量和形式这一方面需要去做好控制和管理，尤其需要注意全局构建索引的问题。

5.HBase平台之Kylin

我们这边离线的OLAP平台主要是基于Kylin实现，Kylin是一个开源、分布式的分析型数据仓库，提供Hadoop/Spark之上的SQL查询接口及多维分析OLAP能力可以支持超大规模数据，其插拔式的存储方式也支持HBase存储引擎。它优秀的特性比如亚秒级的查询响应，支持SQL，能够很好的支持和满足大部分的业务分析需求。到目前我们平台目前日常活跃构建的Cube大约450个，集群有20个节点，每天的数据输入量，大约在1.5T，平均的构建时间在30分钟。

在多租户的打通方面，默认的Kylin只能使用默认的用户去使用存储及计算资源，在支持多业务场景下，它就不能有效的资源隔离和成本核算，我们使用Hadoop UGI + Hadoop Proxy实现Kylin在58的多租户打通。

1.5版本的Kylin建设中做的优化工作，比如维度字典上传优化，HBase分区数据量预估优化;全局字典换进换出优化等。
2.6版本的Kylin建设中做的优化工作，动态用户加载 (KYLIN-4241); 为了便于灰度和测试，可选择任务构建节点(KYLIN-4249)，为了便于集群优雅的扩容，我们也开发了节点服务发现 (KYLIN-4256)，增加HTTP监控指标接口(KYLIN-4294)等。

6.HBase平台之时序数据库。

OpenTSDB是一个底层基于HBase的可伸缩、开源时序数据库，支持高达每秒百万级的写入能力，就是基于这种数据库我们为58大数据平台超过4000个的节点提供监控数据存储、查询服务，单表每天的监控数据量超过2亿。此外OpenTSDB还为58智能安全监控平台提供数据存储服务，当然还为一部分的独立业务，我们提供了独立的基于云的时序数据库集群。

二.HBase集群迁移实践及性能优化

1.项目背景

2019年公司滨海机房机位接近耗尽，无论是在线业务，还是数据离线业务，新的资源需求均满足面临极大压力。短时间内，在线业务跨机房架构改造，迁移等相关工作较多，风险大。基于大数据资源需求占比较大，业务场景相对可控，决定对TEG大数据集群进行整体迁移至新机房，满足未来需求，同时腾挪机位给在线业务，满足一定时间在线资源需求。另外针对当前大数据集群存在的多种痛点问题进行优化，解决相关问题。伴随着平台整体迁移的计划，HBase平台的一个集群需要参与到此次的迁移项目中，由原滨海机房迁移至武清机房。此次迁移的HBase集群概况是regionserver * 74 + hmaster * 2，数据表 * 96， region数 * 15000。

2.迁移方案

在迁移方案的制定中，我们将存储的数据表根据读写规律划分了非活跃数据和活跃数据。非活跃数据主要的特性有无读写或者存在较大的时间窗口无读写请求，但是数据需要保留。活跃数据的主要特征是存在读写请求并且可能存在多样的数据写入方式，比如实时写入和离线Bulkload同时存在。

非活跃数据的迁移方案
非活跃数据的迁移方案相对比较简单，直接进行原表复制，然后在新集群导入恢复即可，常用工具dictCp & bulkload。

活跃数据的迁移方案
活跃数据的迁移相对有些复杂，总体来说我们推荐双写方案：

第一阶段：历史数据迁移，采用clone-snapshot + major-compaction + distcp + bulkload的方式。

使用Dictcp进行数据迁移能够控制资源(任务数、带宽)占用，并且Bulkload历史数据时可以针对特定的表特征，比如分区平均大小、分区平均请求负载等，进行分区调整，避免分区数据量或者负载过大或者过小的问题。缺点：克隆快照生成历史数据会对原集群会造成数据猛增，但是由于我们此集群基于的HDFS容量比较大，可以适当予以低级考虑。

第二阶段：数据双写 + 追加在迁移时间窗口内的原集群增量数据。

至于第二阶段的数据迁移，我们准备了两种方案。

集群双写

数据双写的解决，鉴于我们在HBase平台层面建设了一层请求网关，接入此网关的数据表的实时写入，我们实现了基于注册中心的灵活多集群串行写入的特性。没有接入此网关的数据表的实时写入，我们都在推动其的使用接入。至于离线Bulkload的写入，可以采取双集群并行导入的方案。增量数据的追加可以使用CopyTable等工具实现特定时间段的数据拷贝。
双写方案的优点是：能够让使用方知晓其数据分布或者变化的发生；在实施双写、数据一致性验证、读切换等流程中比较自然。

通过HBase的Replication特性

针对实时写入的增量数据，HBase提供了基于WAL的Replication这个特性，能够实现跨机房异步数据迁移，如果需要同步离线Bulkload的数据，也可以通过Bulkload HFile Replication这个特性实现，在Apache HBase 1.3.0版本中已经添加了此功能，如果版本低于此可以通过移植此补丁去添加这项特性。
此方案的优点：这项功能主要对于数据备份、容灾，数据分为线上或者线下分析等。但是也存在相对的不足，比如：会造成越忙的节点越忙，异常不易排查等，并且对集群迁移来讲，上次读写都需要显示切换，使用Replication特性价值不是很高。附: Bulkload HFile Replication(https://issues.apache.org/jira/browse/HBASE-13153)
于是最终确定的首选方案是集群双写，下图是整体的流程图：

3.迁移过程

业务梳理

我们先根据平台统计数据将表划分。
联系对应负责人，与其明确读写规律，以免误迁、误停、遗漏使用方等问题。由于此集群属于历史集群，当时建设时管理尚不完善，需要额外根据ip、部门负责人、MR/Spark/Spark Streaming等任务线索排查其使用方。

确定迁移使用方案

针对单一数据表，多方沟通，确定迁移方案、迁移时间、校对方案、校对时间、使用方双写窗口时间、业务使用切换时间。

4.数据准确性校对

针对迁移后的表数据，我们进行了抽样校对与全表校对的两种方式。抽样校对的方案是基于原数据表每个分区的startkey、endkey为抽样基准，自定义抽样行数进行校对。全表校对，针对表数据量不是很大，但是对一致性要求比较高的使用方，特定时间范围内进行全表比对。

5.业务使用方迁移

由于我们在集群迁移中使用的是双写方案，所以使用方切换使用集群相对更好控制与业务使用更透明。对于已接入HBase网关服务进行读取的业务，我们可根据注册中心进行一键切换。对于Bulkload双写的任务，停掉之前向原集群导入的任务即可。

6.集群性能优化

架构修改

措施：隔离出独立的后端hdfs系统服务。
要点：减少其后端DN节点由于其他任务或者服务的资源抢占，降低业务高峰期的抖动与延迟。

资源硬件升级

措施：磁盘升级，SATA=>SSD(Hadoop2.6.0以后支持异构存储，如果成本有限，可以考虑仅支持一个WAL目录的SSD)；网卡升级，KM=>10KM。
要点：提高IO能力，抬高系统瓶颈。

进程参数修改

措施：减少HFile数量同时增加Compaction对应资源数避免堆积；增加工作线程数；调整GC方式。
要点：减少HBase遍历文件数；提高工作线程数，用以增加吞吐；调整GC方式，优化大内存GC回收带来的毛刺。

内部机制改进/升级

措施：Bucket Cache提高读性能；MSLAB提高写性能；Hedged Read降低读毛刺。
备注：HDFS-11303(Hadoop<=2.9.0)；短路读对于数据本地性比较好的集群提效较好；读写分离避免读写资源的抢占与饥饿。
要点：优化读写路径增加对缓存的使用和内存的管理；并发读降低HDFS毛刺以及坏节点带来的抖动；读写资源的隔离易于合理的资源分配。