本次演讲首先给大家介绍一下平安科技使用 HBase 的现状, 以及给用户解决了哪些问题, 然后是如何保证 HBase 集群的高效以及它的稳定的.
平安科技 HBase 的使用现状
我们这边 HBase 的使用现状, 可以从以下两个方面来讲, 第一个是 HBase 的集群规模以及数据量. 第二个是它的应用场景. HBase 集群方面现在是由 300 多台物理机组成, 数据量大概有两个 P 两个 pb 左右.
解决了用户哪些问题
HBase 的应用上, 用户可能首先要面临的是海量数据的存储问题, 然后是对性能和可靠性的关注. 最后一个可能是数据的迁移问题.
从用户层面来讲, 他们在使用传统数据库的时候, 由于无法预估业务应用场景, 造成无法判断接下来会面临多大的数据量. 所以我们建议用户将数据接入到 HBase 集群里面, HBase 是支持在线扩容的, 即使后续使用的过程中, 某段时间数据出现爆炸式增长, 我们也可以通过 HBase 进行横向扩容来满足需求.
在使用传统的 DB 时候, 其实在维护和扩展方面都会遇到很多问题, 而如果迁移到 HBase 上, 进行扩容和维护就会很方便的.
客户端优化
性能和高可用问题也是用户关注的重点, 性能方面主要在于应用程序对 HBase 集群的调用.
先讲下客户端优化的方案, 上图列出了几个常见的优化点, 首先第一个是基于应用层面的 scan 操作, 此时客户端向 HBase 的请求后, 数据并不是一次性全部返回, 而是通过多次的 RPC 请求交互得到数据. 在这方面如果请求的数据量很大, 可以通过去调整一下参数来减少 RPC 的交互, 从而降低耗时.
另一个优化点是在 get 方面的, 在 HBase 既可以一次性 get 整个数据, 也可以进行批量的 get 操作. 我们一般建议批量的使用 get, 其原理主要是为了去减少用户 RPC 的交互次数.
接下来是列簇及列的优化. HBase 中相同的列簇数据是存在一个目录的, 不同列簇数据分开进行存储. 在有多个列簇的情况下进行检索, 如果只是用 key 检索, 而没有指定列簇, 索引是要独立去检索的. 这种情况相比指定列簇检索, 效率是比较低的, 也就是列簇越多影响就会越大.
第四个是禁止缓存, 我们在写数据的时候, 如果客户端突然加载了大量的数据, 而没有禁止缓存, 可能就会把热数据会挤压出去.
挤压出去的后果会导致其他业务检索 HBase 的时候, 需要到 HDFS 里面去重新的去加载, 这就造成了延时.
服务端层面优化
这里服务端层面也列举了几种比较常见的优化手段. 首先是均衡的优化, 在 HBase 中均衡操作有两种方式, 一种是通过 balance_switch, 它后面会跟一个参数, 如果是 true 的话, 就开启自动均衡. 如果指定为 false 的话, 就关闭当前的自动均衡.
另一种是使用 balancer, 这种方式可能需要去手动的执行, 比如 HBase 节点挂了之后重启了, 其中间隔的时间内 Region 又不均衡. 还有一种情况是扩容新的 HBase 节点后, Region 没有均衡. 此时如果开启 balance_switch 没有效果, 就要通过手动的方式, 强制的让它均衡.
第二个优化是在 Blockce, 在缓存命中率不高的时候, 可以开启对外内存, 然后来提高它的命中率, 同时该操作对 GC 也是有好处的.
第三个是 Compaction 的操作, 它可以保证的数据的本地性唯一. 在实际的应用的场景下, 我们会避免自动执行 Compaction 操作, 因为自动执行可能会影响集群的 IO, 从而对用户的应用读写产生影响. 所以我们需要改为手动的定义执行. 在周末或者访问量不是的时候, 执行 Compaction 操作.
执行 Compaction 操作的时候, 有两个属性是可以优化的. 由于默认情况下, 线程数是 1, 因此在数据量很大的时候, 耗时会长一些 . 我们可以根据集群的规模, 或者集群应用的影响度, 来适当的调整参数, 以提高 Compaction 执行的速度.
另外一个优化点可能是用户比较关心的可靠性. 因为 HBase 是高可用的集群, 可以做主备切换, 所以不用担心单点问题. master 挂了之后, 可以立即切换到 BackUpMaster, 然后 BackUpMaster 会将角色状态切换成可用并对外提供服务.
数据迁移
数据迁移有几种情况. 一种是 HBase 集群之间的迁移, 一种是将 Hive 数据迁移到 HBase.
首先分析第一种情况, 两个集群之间迁移的话, 由于它们的数据格式是一样, 所以可以直接使用 distcp 的方式来进行迁移. 这里因为要用到 mapreduce, 所以要指定队列名.
迁移过程当中需要注意以下四项.
开启 YARN,distcp 使用 Mapreduce 来传输数据, 因此迁移之前需要确保集群资源可用.
防火墙, 两个 HBase 集群之间端口要能正常访问 telnet, 例如 NN,DN 的端口.
使用 HBase Hbck 修复元数据信息
上图为跨集群迁移的一个案例, 产生这种问题的原因是 HDFS 中的文件没有关闭, 处于写状态, 而每次 distcp 时会校验文件长度, 如果文件处于关闭状态, 就会出现这种异常.
对于这种情况, 我们可以先检测文件的状态, 然后关闭该文件, 重新进行数据迁移. 在关闭的时候可能会出现异常导致关闭失败, 对此可以重复执行关闭操作直到成功,
将 Hive 的数据迁移到 HBase 有两种方案, 第一种方案不需要写代码, 直接在集群 A 中生成 HFile 文件, 然后使用 distcp 将 HFile 文件迁移到集群 B, 最后使用 HBase 的 BulkLoad 的方式将数据导入到 HBase 表.
另一种比较高级的方式, 使用 API 接口, 直接通过 BulkLoad 的方式进行数据迁移, 以应用程序的形式来实现数据迁移.
如何保证 HBase 集群的高效及稳定
要保证 HBase 集群的高效和稳定, 监控系统和修复机制是必不可少的, 在实质上还有一些特殊的处理.
首先来看一下监控系统. 只要将 HBase 的全部指标都采集到, 就相当于是掌握了整个 HBase 集群的健康状态. 我们可以通过 regionserver 提供的相应解码接口对 HBase 节点上的指标进行采集, 然后将核心的指标绘制出来.
关于修复机制这块, 需要监控系统和修复系统联合起来, 由监控系统发现问题并反馈问题, 然后再由修复系统去自动修复, 例如集群进程可用性, 存在性, 负载均衡修复等.
最后还有一些特殊处理, HBase 里遇到比较多的就是永久 RIT 的问题, 一般情况下, RIT 都是瞬时的, 但是有些情况会让其进入永久 RIT 状态, 所带来的不良后果就是管理员无法干预 Region 均衡操作, 从而影响集群的负载均衡.
对于如何解决这种问题, 我们先来看个案例. 在该案例中合并 Region 操作时, 发现 RIT 一直显示 MERGING NEW 状态, 查看 HBase JIRA 发现这是触发了 HBASE-17682 的 BUG, 需要打补丁进行修复.
我们来分析这种情况产生的原因, 首先客户端发起合并请求的命令, 然后由 master 组织一个 RegionServer 上面的两个 region 进行去合并, 在合并操作之前, 它会生成一个初始化的 MERGING NEW 的状态, 并存在 master 的内存里面.
这样我们就清楚了, 当前的 master 有 MERGING NEW 状态, 而 BackUpMaster 里没有该状态, 直接进行主备切换就可以解决问题.
来源: https://juejin.im/post/5bf6262ef265da616301b27b