6.3 生态集成与复制：让 HBase 回到存储本职

6.3 生态集成与复制：让 HBase 回到存储本职

本节摘要：HBase 在大数据架构里的正确定位是"在线随机读写的存储层"：Kafka 做接入缓冲、HBase 做在线存取、Spark 做批量计算、搜索引擎做多条件检索。本节给出这条链路的组装方式（含 Spark 读写代码与 Bulk Load），并交代 Replication 异步复制与行级事务的边界，把此前略过的复制与事务话题一并收口。

一条典型数据链路

以用户行为数据为例，从产生到消费的完整分工：

客户端埋点 → Kafka（削峰 缓冲 可重放）
    → 消费服务（清洗 转行键）
        → HBase（在线存取 画像与明细）
        → Spark 批作业（离线聚合 回写画像表）
        → 搜索引擎索引（多条件检索圈选）
​

每个组件只干一件事：Kafka 吸收写入毛刺、提供重放；HBase 承接毫秒级点查与扫描；Spark 把算力横向铺开；搜索引擎补足 HBase 缺失的多维检索。让 HBase 去做聚合或检索，或让搜索引擎去抗在线点查，都是让部件离开本职，链路设计的第一原则。

写入集成：从消费到 Bulk Load

常规路径：消费服务调 Java API 的 BufferedMutator 批量写（4.1 节），行键按 5.1 的方法生成。日增十亿级以下都扛得住，注意 4.3 节的批量姿势即可。

超大批量导入用 Bulk Load：跳过写路径（WAL、MemStore 全免），直接在 HDFS 上生成 HFile 再"挂载"进表。三步流程：

// 1 生成 HFile：MapReduce 或 Spark 输出 HFileOutputFormat2
JavaPairRDD<ImmutableBytesWritable, KeyValue> kv = rows.mapToPair(...);
kv.saveAsNewAPIHadoopFile(
    "hdfs:///bulk/out",
    ImmutableBytesWritable.class, KeyValue.class,
    HFileOutputFormat2.class, hadoopConf);   // 自动按 Region 边界分区输出

// 2 完成装载
LoadIncrementalHFiles loader = new LoadIncrementalHFiles(hadoopConf);
loader.doBulkLoad(
    new Path("hdfs:///bulk/out"),
    conn.getAdmin(), TableName.valueOf("orders"),
    conn.getRegionLocator(TableName.valueOf("orders")),
    conn.getTable(TableName.valueOf("orders")));
​

Bulk Load 的输出必须按目标表当前的 Region 边界分区（HFileOutputFormat2 内部会读 Meta 拿边界——1.3 节寻址机制的又一次复用），然后只需在 Meta 登记文件路径，零写放大地瞬间入库。首次灌历史数据、周期性大批量回填是它的主场。

计算集成：Spark 读写 HBase

Spark 用普通 DataSource API 即可（经 phoenix 或 hbase-spark 连接器），概念上等价于把 Scan 并行化到每个 Region：

val df = spark.read
  .option("hbase.zookeeper.quorum", "vm1,vm2,vm3")
  .option("hbase.table.name", "orders")
  .option("hbase.columns.mapping",
    "rowkey STRING :key, status STRING cf:status, amount DOUBLE cf:amount")
  .format("hbase").load()

df.filter($"rowkey".startsWith("rev_u1001"))
  .groupBy("status").count().show()
​

要点两条：下推——尽量让过滤条件转成行键区间（连接器会翻译 STARTROW/STOPROW，原理回到 3.3 节）；并行的单位是 Region——Region 数即扫描并行度，3.1 节的预分区在计算侧又一次兑现。聚合结果常回写画像表（6.3 节开头链路的回环）。

检索侧的集成是"双写搜索引擎"：HBase 存全量与事实源，搜索引擎只放需要多条件组合查询的字段子集，这比给 HBase 硬造二级索引（第 5 章方案四）更常见。

Replication：异步复制与容灾

Replication 复用 2.1 节的 WAL：主集群把 WAL 中标记为 REPLICABLE 的条目异步推送到从集群重放，从集群只是"影子消费者"，不影响主集群写路径。要点：

• 异步：延迟秒级，主从间是最终一致；从库可服务读（延迟敏感的业务别依赖）；
• 单向：循环双向写会风暴，双向容灾要靠两组单向加主备切换；
• 粒度：按表/列族开启，REPLICATION_SCOPE 参数控制。

它适合异地容灾、在线到离线机房的数据分发。注意它不是备份——误删表会被忠实地复制到从库；真正的备份靠 Snapshot，那是第 7 章的内容。

事务边界：一句话收口

HBase 的原子性止步于单行内多列（4.1 节 checkAndPut 的单行 CAS）；跨行、跨表的一致性要么靠应用层两阶段式补偿（第 5 章双写的失败重试），要么靠把相关数据聚拢到同一行（宽表设计的隐性收益）。跨行事务（如转账）从一开始就不该指望 HBase——这是 1.1 节选型边界在机制层面的最终解释：没有跨 Region 锁，就没有跨行事务，而跨 Region 是分布式的天性。

⚠️ 常见坑：Bulk Load 时目标表发生 Region 分裂（3.1 节），预生成的 HFile 分区与新区间错位，装载失败。大批量导入前先确认 Region 边界稳定：关自动分裂或导入后再放开。

💡 关键直觉：生态集成的判断标准始终是"谁离数据近谁算"。在线点查离 HBase 近，批量聚合离 Spark 近，多条件检索离搜索引擎近——HBase 在其中扮演的是那个读写都快、但不爱思考的存储。

本节要点回顾

• 链路分工：Kafka 削峰、HBase 存取、Spark 计算、搜索引擎检索，各司其职是第一原则；
• Bulk Load 零写放大：直接产 HFile 按 Region 边界挂载，历史灌入与批量回填首选；
• Spark 并行度即 Region 数：下推转行键区间，预分区红利在计算侧复用；
• Replication 异步容灾不是备份：误操作会复制，备份靠 Snapshot；
• 事务止于单行：跨行一致性靠设计不靠引擎，回到 1.1 节的选型边界。

机制、API、设计、扩展都已齐备。最后一章进入机房：监控、调优、扩缩容、备份与故障排查，再用两个综合案例收束全册。