玩楞一下HBase，要让这玩意儿在大数据量下跑得顺，索引和优化可都是实打实的硬活。
先说索引这块。HBase就认RowKey这个主索引，所有数据都按它排得明明白白。平时查数据，只要RowKey设计得好，直接就能定位到对应的Region，速度快得很。但RowKey要是拍脑袋瞎写，比如全按时间戳排序，那准得出大问题------数据全往一个Region挤，妥妥的热点，集群直接卡住。所以设计RowKey时，我一般会用哈希打散，再拼上业务ID或者时间戳，让数据均匀分布在各个RegionServer上。
遇到按其他字段查数据的需求，HBase可没现成的方案，得自己动手搞二级索引。简单点的办法是建个索引表，把要查的字段和RowKey对应起来存好，查的时候先扫索引表捞RowKey，再去主表捞数据。要是业务场景允许，也能把索引字段直接塞到主表的列族里，在单Region内快速查，不过这种方法扩展性差点。
再说说优化。数据存进HBase，列族划分得讲究。把常用的列扔到一个列族，查询时I/O开销能小一大截。存储这块，我一般会开Snappy压缩，压缩比和性能都过得去，磁盘空间能省下不少。Region这块门道也多，建表时就得根据数据量和访问模式提前分好区，比如按日期、按ID区间，避免后期数据倾斜。线上跑着跑着，要是发现某个RegionServer负载太高，Master会自动迁移Region，但有时候也得手动干预，做些调优。
缓存这块也是重点。BlockCache专门存热数据，MemStore负责写缓存。调参数时，我一般会根据服务器内存和读写比例，把BlockCache设成堆内存的30% - 40%，MemStore的刷盘阈值也得根据写入频率微调，刷得太勤影响性能，攒太多又怕宕机丢数据。
最后是查询优化。线上用Filter用得特别多，比如查某个用户的所有数据，直接用PrefixFilter按RowKey前缀筛，数据都不用全拉到客户端。遇到复杂计算，我会写协处理器扔到RegionServer上算，减少网络传输压力。总之，HBase这玩意儿得边用边调，才能让大数据跑得又快又稳！