数据量过亿之后，很多业务系统会同时遇到几个问题：关系型数据库的单表越来越大，写入吞吐跟不上，历史数据堆在主库里，查询也越来越慢。HBase 构建在 HDFS 之上，适合海量稀疏数据的随机读写。但自建集群需要有人持续盯着扩容、备份和故障恢复。阿里云 HBase 把这些运维工作交给云平台，团队可以把时间花在数据模型和查询设计上。
阿里云 HBase 提供哪些能力
阿里云 HBase 兼容开源 HBase 的主流 API，现有客户端代码和大部分生态组件通常可以直接迁移。除此之外，有几项能力对生产环境比较实用：
- 弹性扩缩容：节点和存储可以按需调整。业务高峰前扩容，低谷期释放，避免长期按峰值付费。
- 高可用与备份：底层多副本存储配合自动故障切换，支持定时备份和按时间点恢复。误删数据时，可以恢复到出事前的时间点。
- 二级索引：可以通过 Phoenix 等方式建立二级索引，解决只能按 RowKey 查询的限制。
- 监控告警：控制台提供 CPU、内存、磁盘、读写延迟等指标，便于定位热点 Region 和慢查询。
- 网络与安全：支持 VPC 内网访问、IP 白名单和传输加密，满足企业对数据隔离的基本要求。
两个场景里的做法
电商订单历史数据归档
某电商平台的订单表三年内积累了数十亿条记录。主库查询历史订单经常超时，用户中心页面跟着变慢。团队把超过半年的订单迁到阿里云 HBase，RowKey 采用“用户 ID 反转加订单创建时间戳”的形式。同一用户的订单在存储中相邻，按用户分页时只需要一次范围扫描。
迁移后，用户中心历史订单接口的平均响应时间从几百毫秒降到二三十毫秒，主库的存储压力也明显下降。这里有个坑：如果 RowKey 直接以递增的时间戳开头，新写入会集中在少数 Region 上，形成写入热点。团队后来加了哈希前缀，把写入分散到各个 Region。
物联网设备时序数据
一家智能设备厂商每天接收的上报数据超过十亿条，原来用关系型数据库存储，写入吞吐很快成了瓶颈。改用阿里云 HBase 后，RowKey 采用设备 ID 加时间戳，查询某台设备的最近数据可以做到毫秒级返回。按天或按小时的聚合统计放到离线侧：Spark 读取 HBase 数据生成报表，线上库只负责实时读写。
这个方案成立的前提是数据用途划得清楚。HBase 擅长按主键快速读写，不擅长复杂的多表关联。如果把它当通用数据库用，查询体验通常会很差。
选规格前先算四笔账
写入压力大的业务，选规格时不要只看当前数据量。可以按下面几点估算：
- 数据规模与增长速度：单表预期超过千万级，并且还在持续增长，HBase 的优势才会明显。数据量不大时，关系型数据库加索引可能更省事。
- 访问模式：以主键或前缀范围查询为主，适合 HBase。如果经常有多条件组合查询，就要配合二级索引，或者把分析类查询交给其他存储。
- RowKey 设计：散列方式和字段顺序要在上线前定好。这一步直接决定性能，上线后再改，迁移数据的代价很高。
- 总成本：比较按量付费与包年包月的费用，同时把备份、二级索引和流量算进去。只看节点单价，容易低估实际支出。
写入压力大时先看哪些指标
写入压力上来时，控制台的指标很多，不必逐个盯。下面几项最能说明问题，建议按这个顺序看：
- 热点 Region：如果少数 Region 的读写明显高于其他 Region，多半是 RowKey 设计有问题，先检查前缀是不是单调递增。这类问题扩节点通常解决不了。
- 读写延迟：延迟抖动一般比超时更早出现，适合作为预警信号。延迟持续升高时，先确认是哪一类请求变慢。
- CPU 与内存：CPU 长期接近满载，说明节点处理能力不够，可以考虑扩节点。内存紧张也要留意，否则会影响读写。
- 磁盘：磁盘使用率增长快时，结合数据增长速度判断扩容时机。写入高峰时如果磁盘 I/O 跟不上，写入会直接变慢。
- 慢查询：找出耗时最长的查询，看它是不是在做大范围扫描。大范围扫描往往占用大量资源，会拖累其他请求。
上线前用真实写入模式压测
规格够不够，最好用接近真实业务的写入模式压测一次。按预期高峰写入量打压，并留出余量，同时观察上面几项指标。压测结果出来后再决定节点规格和扩容策略，比凭经验拍板更稳妥。
阿里云 HBase 把开源 HBase 的能力包装成可直接使用的云服务，适合数据量大、访问模式清楚的业务。它不能代替数据建模。RowKey 设计、写入分布和查询路径是否和业务匹配，决定了最终效果。建议先用一个小规模业务做压测，验证通过后再逐步扩大范围。
