HBase 是一个分布式的、面向列的开源数据库，构建在 Hadoop 文件系统（HDFS）之上，是 Google Bigtable 的开源实现

HBase 是一个分布式的、面向列的开源数据库，构建在 Hadoop 文件系统（HDFS）之上，是 Google Bigtable 的开源实现。它专为海量结构化或半结构化数据的随机、实时读写而设计，具备高可靠性、高扩展性和强一致性（单行事务）特性。

核心特点包括：

• 稀疏、多维、排序的映射表：数据按行键（Row Key）字典序存储，支持列族（Column Family）组织，列可动态添加；
• 基于 HDFS 的持久化与容错：底层依赖 HDFS 提供数据冗余和故障恢复；
• RegionServer + HMaster 架构：数据按行键范围切分为 Region，由 RegionServer 管理；HMaster 负责元数据管理、负载均衡与故障转移；
• 强一致性模型：单行操作（如 put/delete）是原子且强一致的，但跨行事务不原生支持（需借助协处理器或外部框架）；
• 与 Hadoop 生态深度集成：支持 MapReduce、Spark、Flink 等计算引擎直接访问，也提供 Thrift/REST 接口供非 Java 应用调用。

典型适用场景：实时消息推送、用户画像存储、时序数据（如监控指标）、推荐系统特征库等需要低延迟随机访问海量数据的场景。

# 示例：HBase Shell 基本操作create'users','info','profile'# 创建表，含两个列族put'users','user1001','info:name','Alice'put'users','user1001','info:age','28'get'users','user1001'# 按行键查询scan'users',{LIMIT=>10}# 全表扫描前10行

HBase 中Row Key 是唯一主键，也是数据在 HBase 中唯一排序和定位的依据，其设计直接决定数据分布、读写性能、负载均衡与查询效率。由于 HBase 没有传统数据库的索引机制（除行键外无内置二级索引），所有查询几乎都依赖 Row Key 的前缀匹配或全量扫描，因此 Row Key 设计是 HBase 应用成败的关键。

✅ Row Key 设计核心原则：

1. 唯一性（Uniqueness）
   每条记录必须有全局唯一的 Row Key，避免覆盖写入。

2. 散列性 / 避免单调递增（Avoid Monotonic Keys）
   ❌ 错误示例：1, 2, 3, ..., 1000000或20240101000001, 20240101000002, ...
   → 导致所有新写入集中到最后一个 Region（热点 Region），严重破坏水平扩展性。
   ✅ 改进：对业务 ID 做哈希/取模/反转（如手机号13812345678→ 反转为87654321831；或MD5(uid).substring(0,8) + "_" + uid）。

3. 长度适中（Compactness）
   Row Key 会重复出现在每个 Cell 的存储元信息中（含列族、列限定符、时间戳等），过长显著增加存储开销与网络传输负担。建议控制在10–100 字节内，优先使用二进制编码（如Bytes.toBytes(long)）而非字符串。

4. 可读性与可维护性（适度兼顾）
   虽不强制可读，但关键业务字段（如租户ID、时间戳片段）可嵌入 Row Key 实现范围查询，需权衡“可查性”与“散列性”。例如：
   ✅tenant_id + reverse_timestamp + seq_id→ 支持按租户+时间倒序查最新 N 条；
   ❌ 纯 UUID（无序但不可查）→ 仅支持随机点查，无法范围扫描。

5. 支持预期查询模式（Query-Driven Design）

   • 若常按「用户ID + 时间范围」查询 → Row Key =user_id + reverse_timestamp（时间倒序便于 scan 最新数据）；
   • 若需按「地区+日期」统计 → 可设计为region_code + date + hash_suffix，使同一地区数据物理聚集。

⚠️ 为什么 Row Key 对性能影响极大？

💡 类比：Row Key 就是 HBase 的“索引+分区键+聚簇键”三位一体——它既是查询入口，也是数据物理分布的唯一依据。