HBase RowKey 怎么设计？
面试怎么回答
HBase RowKey 我会先根据点查、前缀查和范围扫描定义访问模式，再平衡唯一性、局部性、长度和写入分散。递增 Key 容易形成热点，可用 Salting、稳定 Hash、反转和预分区，但都会牺牲部分范围查询能力，桶也不是越多越好。设计后要用真实 Key 分布验证 Region 负载、扫描范围和 Compaction，必要时用不同表服务不同访问路径。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
“RowKey 加个随机前缀，就能解决热点。”
这句话只说对了一半。随机前缀能打散写入，却可能让原本一次范围扫描变成多路扫描；如果查询模式没想清楚，写热点解决了，读性能又失控。
RowKey 设计的本质，是在唯一定位、数据局部性、写入分散和查询方式之间做取舍。必须先从访问模式出发，而不是先套盐值、哈希或反转模板。
为什么 RowKey 决定性能？
HBase 中行按 RowKey 字典序排列，连续 Key 会落在相邻区域。这让前缀和范围扫描很高效，也意味着持续递增的时间戳、订单号可能把新写入集中到当前最后一个 Region，形成热点。
RowKey 还参与每个 Cell 的存储和索引，过长会增加内存、磁盘和网络开销。因此它既要包含必要定位信息，也不能把大量可变描述字段拼进去。
先列出查询模式
例如设备时序数据常见需求是：按设备查询一段时间、查询某条记录、批量写入全量设备。
可以设计为：
bucket + device_id + reverse_timestamp设备 ID 提供局部性，反转时间让最新记录靠前，Bucket 打散热门设备或连续写入。但如果主要查询是“按区域扫描当天全部设备”，这套 Key 可能并不合适。
常见打散方法怎么选？
- Salting：随机或轮询前缀，写入分散，但范围查询要扫描多个桶
- Hash 前缀：同一业务键可稳定计算前缀，点查方便，仍会破坏自然范围
- 反转：把变化最快的低位放前面，适合连续数字，代价是顺序语义改变
- 预分区：按已知前缀提前创建 Region，避免初始阶段集中写单 Region
桶数量不是越多越好。桶越多，并行写能力可能提高，但一次逻辑范围查询要合并更多分区，Region 数和管理成本也会上升。
唯一性和长度也要控制
组合 Key 要避免歧义。user_id + timestamp 直接字符串拼接可能发生边界冲突，应使用固定宽度、可靠分隔符或二进制编码。
热点不只来自时间递增。少数超级用户、固定租户前缀或状态字段放在最前，也会让流量集中。设计后应使用真实 Key 分布估算每个前缀的写入量，而不是只看基数。
怎么验证？
上线前构造代表性写入和查询，观察 Region 分布、单 Region QPS、StoreFile 大小、Split、Compaction 和扫描范围。上线后监控 RegionServer 负载倾斜和热点 Key。
当访问模式差异很大时，不要强迫一个 RowKey 满足所有查询。可以建立二级索引、冗余表或为不同查询路径设计不同表，但要评估写放大和一致性成本。