深入 HBase 17 - Kerberos、RPC 保护与 ACL
HBase 安全不是一个开关。Kerberos 解决身份认证，RPC protection 解决传输层保护，ACL 解决 HBase 资源授权，HDFS 和 ZooKeeper 还要各自按安全模式配置。任何一层缺失，生产集群都会留下绕过路径。 本篇只抓一个核心问题：客户端身份、服务认证、传输保护和表权限如何衔接。 安全路径图 flowchart TD Client[Client principal] --> KDC[Kerberos KDC] RS[RegionServer principal] --> KDC Master[HMaster principal] --> KDC Client --> RPC[HBase RPC/SASL] RPC --> AuthN[authentication] AuthN --> Protection[hbase.rpc.protection] Protection --> ACL[AccessController ACL] ACL --> Region[Regi...
深入 HBase 16 - Coprocessor、Endpoint 与 Phoenix 边界
Coprocessor 把一部分逻辑放进 HBase 服务端进程执行。这个能力很强，也很危险：代码和 RegionServer 在同一个 JVM、同一套权限、同一条请求路径里运行。Endpoint 能做局部聚合和自定义 RPC，但它不是分布式 SQL 引擎；Phoenix 提供 SQL 层，但 Phoenix 和 HBase 的升级边界也不能混写。 本篇只抓一个核心问题：计算下推能做什么，何时会破坏隔离、升级和运维边界。 Coprocessor 路径图 flowchart TD Client[HBase Client] --> RPC[RegionServer RPC] RPC --> Observer[Observer hooks] Observer --> Region[Region] Region --> Store[Store/MemStore/HFile] Client --> Endpoint[Endpoint service] Endpoint --> Region Region --> WAL[...
深入 HBase 15 - BufferedMutator 与 Bulk Load
在线批量写和 Bulk Load 解决的是同一个输入问题：大量记录要进入同一张 HBase 表。二者的成本模型完全不同。BufferedMutator 仍然走 RegionServer 写入协议，写入进入 WAL、MemStore、flush 和 compaction；Bulk Load 先离线生成合法 HFile，再让运行中的 RegionServer 接管这些 StoreFile。 本篇只抓一个核心问题：什么时候该用在线批量写，什么时候该先生成 HFile；两条路径各自把 CPU、网络、WAL、MemStore 和 compaction 成本放在哪里。 两条批量写路径图 flowchart LR A[应用批量记录] --> B[BufferedMutator] B --> C[RegionServer RPC] C --> D[WAL] C --> E[MemStore] E --> F[flush] F --> G[HFile] A --> H[MapReduce/Spark 预排序] H -->...
深入 HBase 14 - Get、Scan、Filter 与分页
前置问题与边界 HBase 的读请求不是“把表读出来再过滤”。Get 直接定位单行；Scan 按 row-key range 顺序推进；Filter 可以减少返回给客户端的 Cell，也可能在服务端继续扫描大量数据。caching、batch、limit 和 reversed 影响 RPC 粒度、结果分片和遍历方向，但不会改变 HFile 的物理排序。 本篇回答一个核心问题：scan range、cache、batch、limit、reversed scan 如何影响 RPC 和结果语义。BlockCache、Bloom Filter 和 HFile block 在第 05、06 篇；row key 设计在第 03 篇；Coprocessor 和 Phoenix 边界在第 16 篇。 读取路径图 flowchart TD C[Client] --> O{Operation} O -->|Get row| G[Single row lookup] O -->|Scan range| S[Region scanner] ...
深入 HBase 13 - Snapshot、Backup 与恢复
前置问题与边界 HBase Snapshot 接近一次元数据操作，因为它主要记录某个时刻表的 Region、StoreFile 引用和相关描述，而不是把整张表的数据复制一遍。HFile 是不可变文件，这让 snapshot 可以通过引用既有 HFile 建立一致视图；后续 compaction、删除和清理要尊重这些引用。 本篇回答一个核心问题：Snapshot 为什么快，Backup 和跨集群恢复还需要什么。第 11 篇处理 WAL 恢复，第 12 篇处理 replication；本篇处理表级时间点视图、克隆、恢复和备份边界。 Snapshot 路径图 flowchart TD A[Table] --> B[Regions] B --> C[StoreFiles HFile] A --> D[Snapshot request] D --> E[Flush by default] E --> F[Snapshot manifest] F --> G[References to HFiles] ...
深入 HBase 12 - 跨集群 Replication
前置问题与边界 HBase 跨集群 Replication 复制的是 WAL edit。源集群的 RegionServer 把符合条件的 edit 放入复制队列，由 replication source 推送到 peer 集群。这个过程是异步的，常用于容灾、迁移、异地读和下游同步；它不把两个集群变成一个强一致数据库。 本篇回答一个核心问题：WAL edit 如何异步复制，顺序、延迟、冲突和故障切换的边界是什么。RegionServer 崩溃后的本地 WAL 恢复见第 11 篇；Snapshot 和 Backup 见第 13 篇。 复制路径图 flowchart LR A[Client write] --> B[Source RegionServer] B --> C[Source WAL] C --> D[Replication queue] D --> E[ReplicationSource] E --> F[Peer cluster RPC] F --> G[Sink RegionServer...
深入 HBase 11 - RegionServer 崩溃与 WAL 恢复
前置问题与边界 RegionServer 崩溃以后，HBase 要恢复的是由该 RegionServer 服务的 Region，而不是让 HDFS 自动懂得数据库事务。HDFS 负责保存 WAL 和 HFile；HBase 通过 procedure、assignment、WAL split 或 replay，把未 flush 的 edit 重新送到负责 Region 的服务进程。 本篇回答一个核心问题：ServerCrashProcedure、WAL split/replay 和 Region reassignment 如何把服务恢复到可读写状态。行级一致性边界见第 10 篇；复制链路见第 12 篇；Snapshot 和 Backup 见第 13 篇。 崩溃恢复路径图 flowchart TD A[RegionServer crash] --> B[Master detects dead server] B --> C[ServerCrashProcedure] C --> D[Mark affected regions unavaila...
深入 HBase 10 - 行级原子性与一致性边界
前置问题与边界 HBase 的一致性边界从 row key 开始。Put、Delete、Increment、Append、CheckAndMutate 都围绕单行建立语义；同一行内的多个 column family、qualifier 和版本可以在一次 mutation 中共同提交，但这个边界不会扩展成跨行事务、跨表事务或关系数据库里的多语句事务。 本篇只回答一个核心问题：这些单行操作能保证什么，跨行场景缺少什么。WAL、MemStore 和 MVCC 的写入细节在第 04 篇已经铺底；RegionServer 崩溃后的 WAL 恢复放到第 11 篇；异步复制的一致性边界放到第 12 篇。 HBase 是宽列模型，不是关系数据库。行级原子性不等于外键约束、唯一索引、二级索引事务，也不等于任意 SQL 事务。它的强项是把同一 row key 下的 mutation 收束到一个 RegionServer 的单行执行边界内。 操作路径图 flowchart TD C[Client] --> RS[RegionServer] RS --> R[Region b...
深入 HBase 09 - Client 路由与重试
前置问题与边界 本篇回答一个核心问题：Client 如何缓存 hbase:meta 路由，Region 移动后怎样重新定位。 HBase Client 不是把请求发给 Master 再由 Master 转发。普通 Get、Put 和 Scan 会通过客户端定位找到 RegionServer，然后直接访问对应 Region。hbase:meta 是路由目录，ZooKeeper 或 registry 是引导与协调入口，HDFS 是底层文件系统；三者不能混成一个“元数据中心”。 HBase 2.6.6 中，Connection 是重对象，承载 RPC、线程、缓存和定位相关状态；Table、Admin、RegionLocator 是从 Connection 派生出来的轻量使用入口，使用后应该关闭。频繁创建 Connection 会增加资源和定位成本。 路由路径图 sequenceDiagram participant App as Application participant Conn as HBase Connection participant Meta a...
深入 HBase 08 - Region 生命周期：split、merge 与 assignment
前置问题与边界 本篇回答一个核心问题：表如何扩展，Region 如何迁移，状态由谁推进。 Region 是 HBase 表按 row-key range 切分后的服务单位。它决定数据由哪个 RegionServer 接收，也决定客户端定位和负载均衡的粒度。split、merge 和 assignment 都是在改变 Region 与 RegionServer 的映射，不能把这些动作写成简单的 HDFS 文件移动。 HBase 2.6.6 使用 Procedure v2 和 AssignmentManager 推进 Region assignment。Region 持久状态与位置信息写入 hbase:meta；hbase:meta 自身的位置信息和可用性还涉及 ZooKeeper 或 registry 相关路径。ZooKeeper 不保存所有 HBase 元数据。 生命周期图 stateDiagram-v2 [*] --> CLOSED CLOSED --> OPENING: assign OPENING --> OPEN: RegionS...
