HBase架构简介
HBase在完全分布式环境下，由Master进程负责管理RegionServers集群的负载均衡以及资源分配，ZooKeeper负责集群元数据的维护并且监控集群的状态以防止单点故障，每个RegionServer会负责具体数据块的读写，HBase所有的数据存储在HDSF系统上。
• 适合场景 （综合考虑）
– 表数据量大（至少亿级别以上）
– 日志append型业务，（比如定期保留10天数据等）
– 原则上：
• 能分库分表来用mysql就用mysql来解决
• mysql 单表一般500w，能使用mysql的场景
– 无跨行跨表事务要求
– 写入量大 (每天千万及以上)
– 读取量相对少 (读取:写入 <= 1/10)
– 读取场景简单、不经常变化
– 无正序、逆序的排序要求
– 类似dw等全量读取，不太合适。
– Rowkey不经常更新 （必须先删除再添加）?
建议
• 海量数据，rowkey范围和分布已知，建议进行预分配
• Rowkey一定要尽量短 （如：时间用时间戳整数表示、编
码压缩）
• CF设计：尽量少，建议CF数量在1-2个
• Rowkey设计：写入要分散；
• Autoflush参数设置为true；否则极端情况下会丢失数据
• Hbase client的重试次数为3次以上。否则会由于split导致region not onle；从而导致写入失败
– hbase.rpc.timeout 一次rpc的timeout；默认60秒
– hbase.client.pause 客户端的一次操作失败，到下次重试之间的等待时间
– hbase.client.retries.number 客户端重试的次数
– hbase.regionserver.lease.period 客户端租期超时阀值；scan量大时可以考虑增大；否则”Lease Exception: lease-70000000000000001 does not exist”
• ZK连接/HTable对象的使用注意
– Configure对象的使用
• 必须是static or singleton模式
– 默认：每台机器与zk直接的连接数不超过30个
– HTable的使用
• 线程不安全
• 使用HTableV2
• HTablePool (推荐的方式)
总结
• Hbase作为一个NOSQL存储，作为在线存储的一个重要组成
• 业务设计和选型尤为重要，依特性合理使用
• 容灾是走出Hbase存储使用更广阔的的前提
• 异常处理，先恢复服务，再深入排查