HBase@Taobao

毕玄

Agenda

Taobao HBase规模碰到的问题建议

Taobao HBase规模

基于 0.90.3； 10个独立集群，大约 300台机器；机器配置

16 core， 24G/48G， SATA 1T*12/SAS 300G *12；

大约 200k ops/sec， 70%写， 30%读。

碰到的问题

region数越来越多，写 TPS会疯狂下降 修改写操作时统计各 region memstore的办法；

解决此问题。

碰到的问题 (Cont.)

RegionServer OOM 太多版本；▪ rowKey设计问题；

通过 setMaxFileSize设置了一个巨大的region文件大小；

HBASE-3209 & 3290 provided by Facebook；

碰到的问题 (Cont.)

Master OOM region太多就会导致这个问题； HBASE-3906。

碰到的问题 (Cont.)

.meta.表空洞 我们碰到的原因▪ split失败，不仅造成了空洞，还造成了数据丢失；

HBASE-4562 & 4563 provided by TAOBAO

碰到的问题 (Cont.)

.meta.表中出现了两个 startKey/endKey相同的 region HBASE-3946 不过我们打上 patch后还是碰到了； 这个问题非常棘手 ...▪ 如何恢复？

碰到的问题 (Cont.)

master split hlog阶段失败会造成数据丢失 master以 128M为单位读 .logs，写入

recovered.edits，最后一个 128M读完，会先移动 .logs到 .oldlogs，此时如果写失败 ...

patch暂时未提交到官方； Facebook也正在处理这个 patch。

碰到的问题 (Cont.)

.meta.和 -root-重复分配 HBASE-3914 & HBASE-4590

碰到的问题 (Cont.)

如读取的数据量大，很容易造成写变慢 原因是目前 HBASE的 RPC机制 临时解决方案▪ 读写分开；▪ 对同一个 region server也建多个连接。

建议

Jothan Gray(Facebook) said: “HBase is a pre-1.0 DB”

适用场景 瞬间写入量很大，数据库不好支撑或需要很高成本支撑的场景；

数据需要长久保存，且量会持续增长到比较大的场景。

建议 (Cont.)

实践经验 合理设计 rowKey，非常重要； 数据最好是可恢复的 (Facebook也如此建议 )；

生产环境关闭 split， region数不要太多 (此建议来自 Facebook)。

Thanks!