《代志远：HBase系统故障恢复的优化实践分享.pdf》由会员分享，可在线阅读，更多相关《代志远：HBase系统故障恢复的优化实践分享.pdf（32页珍藏版）》请在三一文库上搜索。
1、支付宝HBase系统故障恢复的优化实 践分享 支付宝支付宝-数据平台架构师数据平台架构师-代志远代志远 自我介绍 支付宝-数据平台-架构组-代志远 (网名：国宝) 从事过分布式文件系统、MapReduce框架研发 后加入支付宝后从事海量计算工作，主导分布式存储、搜 索、计算系统的研发和架构工作，开发和维护支付宝 Hadoop集群与HBase集群，分布式搜索集群 HBase权威指南译者 简要介绍 HBase系统中存在的可用性风险 存储容灾但RegionServer服务不容灾。 Failover流程复杂，消耗时间长 HDFS的NameNode存在单点故障 监控不完善，监控粒度太粗 对以上问题我们进
2、行了针对性优化。 我们以支付宝的消费记录项目为技术优化切入点来跟大家分享这些经验。 大纲 支付宝消费记录背景-HBase RegionServer宕机恢复的关键流程 RegionServer宕机failover的优化 HDFS NameNode的HA优化 监控优化 支付宝消费记录项目背景-HBase 2011 2012 一期上线0.90.x版本， 解决解决海量数据的在 线实时查询问题。 二期规划上线，使用 HBase0.92 -coprocessors 解决解决online count与sum 的需求 支付宝消费记录背景-HBase 业务规模业务规模 技术要求技术要求 选择选择 HBase 业
3、务系统现状业务系统现状 数百亿条数据， 近百T存储空间（压缩后，并且不算冗余三份） 索引表数千亿条数据 数据增长高速（随支付宝业务高速增长而高速成 长） 支付宝消费记录背景-HBase 业务规模业务规模 技术要求技术要求 选择选择 HBase 业务系统现状业务系统现状 用户按时间范围顺序查询占据90%以上的查询 要求相应延时较低 面向用户在线查询 支付宝消费记录背景-HBase 业务规模业务规模 技术要求技术要求 选择选择 HBase 业务系统现状业务系统现状 之前MySQL集群存在高频率人为分库、扩容性较差 等问题。（MySQL是传统集中式数据库的典型代表） HBase 水平拓展能力强 满足
4、强一致性读写 可pre-sharding 满足实时读写，吞吐量大，支持海量数据存储 Rowkey排序 支付宝消费记录背景-HBase 业务规模业务规模 技术要求技术要求 选择选择 HBase 业务系统现状业务系统现状 5W个Region Rowkey设计：userid 0 timestamp 0 tradetype 0 tradeno HBase基于版本0.90.1 读延时：20ms/request RegionServer宕机恢复的关键流程 Regionserver宕机后 - 完整的故障处理流 程有哪几步 1) 等待ZNode失效 2) 重做Edit Log恢复数据（Split Hlog）
5、3) 扫描元数据表 4) 宕机服务器的Region再次上线 3 min + 5 min + 2-6 min + 1 min + 15 min HBase RegionServer宕机恢复的优化 优化强依赖ZooKeeper的宕机超时判断 已申请专利。 Mirror Process（每台RegionServer启动镜像监控进 程） 1）Check PID（检查进程是否存在 - loop） 2）PING （Ping服务端口是否可用） 3）Delete ZNode （删除对应的ZNode） HBase RegionServer宕机恢复的优化 优化强依赖ZooKeeper的宕机超时判断 RegionS
6、erver的启动流程 RS 自身的逻 辑 启动一个 ServerSocket 判断zk上是否 有关于本机的 监控节点 主动向该节 点发送pid数 据。 是 否 结束结束 注册zk HBase RegionServer宕机恢复的优化 优化强依赖ZooKeeper的宕机超时判断 监控进程的启动流程 启动 ServerSocket 判断zk上是否 有本机的RS节 点 等待RS传pid 过来 是 是 删掉zk上该pid 对应的RS节点 否 关掉HDFS句柄 主动去RS拉 去pid 否 注册zk 检查RS的ipc服务是否关 掉，以确定RS已经挂掉 接到pid，放到本 地内存 检查该pid是否存在 于本机
7、。 是 否 HBase RegionServer宕机恢复的优化 优化强依赖ZooKeeper的宕机超时判断-结 构图。 HBase RegionServer宕机恢复的优化 优化强依赖ZooKeeper的宕机超时判断 我们的Patch： https:/issues.apache.org/jira/browse/HBASE- 5075 社区的Patch： https:/issues.apache.org/jira/browse/HBASE- 5844 HBase RegionServer宕机恢复的优化 小结 当前的方案只能解决进程级的服务监控，不能 解决进程内OOM或其他阻塞的场景。 HBase
8、RegionServer宕机恢复的优化 Split HLog时间过长优化 0.90.x系列，WAL重做是单进程单线程 我们使用的解决方案是，并行Split Hlog（多进程并行） 社区Patch： https:/issues.apache.org/jira/browse/HBASE- 1364 注意：不要直接使用社区的Patch，需要与HBase trunk中的Split HLog逻辑进行代码同步 HBase RegionServer宕机恢复的优化 扫描元数据表时间过长的优化 注意：当前场景与实际的生产中元数据的大小有关， 元数据越大这个问题就越凸显，我们的恢复时间是基 于我们当前系统的元数据
9、量得来（读者自测时请参考 自己的实际情况） 1) HBase RPC Client tcpNoDelay 默认设置更改为true （该过程只针对部分场景有效） 2) 扫描META表时设置caching为100（默认为1） HBase RegionServer宕机恢复的优化 宕机服务器的Region再次上线过程的优化 注意：二次上线的Region消耗的时间与实际宕机服务 的Region数量成线性关系，当前数值以我们实际生产 环境的Region为准（读者可自测），单台服务 Region数量1000+。 现有版本单线程串行上线Region 解决方法：并行批量上线这些Region 见：Bulk ass
10、ign HBase RegionServer宕机恢复的优化 单体效果 等待ZNode失效，耗时：3min - 0s split log；32个log files，耗时：5min - 10s 扫描整张meta表（5w个region），耗时：6分-10s 分配region；1000个region；耗时：1分钟-5s 总体效果 15分钟-20+ s HBase RegionServer宕机恢复的优化 效果对比 0 100 200 300 400 500 600 700 800 900 1000 对比 1 对比 2 对比 3 优化前 系优化后 HDFS NameNode的HA优化 为什么要优化Name
11、Node HA？ - 不停机服务 为什么不做无状态分布式NameNode? - HBase依赖的NameNode性能无压力 - 难度较高 我们的HA与社区的关系？ - 我们是踩在巨人的肩膀上前进，社区提供了非常多的优秀解 决方案，如AvatarNode，Backup Node，BooKeeper等。 但出于考虑有的需要依赖硬件，有的则是成熟度不够，再则是 出于人工干涉不能自动运行。我们集合了社区的力量做了代码 整合，吸收了AvatarNode和社区HA重试机制优点和代码，做 了代码合并。 HDFS NameNode的HA优化 目标 热备 热切 自动热切 HBase不停机服务 HDFS Name
12、Node的HA优化 架构图-整体结构 HDFS NameNode的HA优化 架构图 NameNode Active Standby HDFS NameNode的HA优化 要点 Active NameNode将editlog写入NFS某块磁盘， Standby读取NFS的该磁盘editlog数据消费重做到内 存中 Active Node与Standby Node通过ZooKeeper选举 确定状态 DataNode blockReport、heartbeat同时到Active与 standby Node DFSClient具有RPC重试invoke，用于切换访问Active 与Standby N
13、ode HDFS NameNode的HA优化 社区相关 Avatar Node HDFS-1623 对比与关系 吸收了Avatar Node消费editlog与datanode双心跳 汇报的优点（基于AvatarNode） Avatar Node需要VIP（需要硬件支持），我们采用 ZooKeeper选举策略决定Active与Standby，并吸收 HDFS-1623中的HA NameNode RPC 的retryInvoke （基于HDFS-1623 ） 监控优化 监控优化 显示单个region的wps与qps以及每秒写入量（单位字 节）与每秒读取量（单位字节） 显示单个regionserver的wps与qps（排除meta的请 求访问） 显示单个regionserver的每秒写入量（单位字节）与 每秒读取量（单位字节） 显示某张表的每秒写入量（单位字节）与每秒读取量 （单位字节） 显示某张表的wps与qps 监控优化 监控优化 Region细粒度监控示例图 监控优化 监控优化 集群细粒度监控示例图 Q&AQ&A 谢谢 谢谢 ！