深入 HBase 07 - Compaction、TTL、版本与 Delete
前置问题与边界 本篇回答一个核心问题：不可变 HFile 如何合并，旧值和 tombstone 何时真正消失。 HBase 的写入路径把 mutation 写入 WAL 和 MemStore，flush 后形成新的 HFile。HFile 不原地修改，因此旧版本、Delete 标记和过期数据会散落在多个 StoreFile 中。Compaction 通过重写新文件来减少 StoreFile 数量，并在可见性规则允许时丢弃不再需要的 Cell。 本篇不讨论跨行事务，也不把 Delete 写成“立即删除磁盘数据”。HBase 的 Delete 是写入一个或多个 tombstone；旧数据是否在物理文件里消失，取决于 compaction 类型、版本策略、TTL、快照引用、最小保留时间和扫描可见性。 对象路径图 flowchart TD P[Put/Delete] --> WAL[WAL] P --> MS[MemStore] MS --> FL[Flush] FL --> H1[HFile A] FL --> H2...
深入 HBase 06 - HFile 内部结构
前置问题与边界 本篇回答一个核心问题：data block、index、file info、Bloom metadata 如何支持 HBase 在不可变文件里做有序查找。 HFile 是 HBase flush 和 compaction 之后写到 HDFS 的 StoreFile 格式。它不是关系数据库页文件，也不是面向分析扫描的列存文件。它保存按 Cell key 排序的记录，并携带索引、元信息、Bloom 相关数据和 trailer，供 RegionServer 在读路径中缩小访问范围。 基线仍是 HBase 2.6.6。HBase 2.6.6 的代码支持 HFile format version 3，不能把当前实现误写成“只支持 HFile v2”。HFile v2 的文档解释了多级索引、Bloom 和 trailer 等关键结构；写作时要把格式演进和当前版本能力分开。 文件结构图 flowchart TD H[HFile StoreFile] --> DB[Data Blocks: sorted Cells] H --> LB[Leaf Ind...
深入 HBase 05 - 读取路径：BlockCache、Bloom Filter 与 HFile block
前置问题与边界 本篇回答一个核心问题：Get 如何减少磁盘读取，并把 MemStore、BlockCache 与多个 HFile 的结果合成同一行的可见 Cell。 HBase 读路径不是 HDFS 随机读能力的直接暴露。客户端先定位 row key 所属 Region，再把请求发到对应 RegionServer；RegionServer 在 Store 内部合并内存数据和不可变 StoreFile。HDFS 提供文件读取和副本，HBase 提供 row-key 定位、HFile 索引、Bloom Filter、BlockCache 和版本可见性。 本篇基线是 HBase 2.6.6、Hadoop 3.4.3、JDK 17。HBase 3.0.0 的集中变化只放在第 19 篇。 读取路径图 flowchart TD C[Client Get row key] --> M[Region location from cache or hbase:meta] M --> RS[RegionServer] RS --> R[Region] ...
深入 HBase 04 - 写入路径：WAL、MVCC、MemStore 与 flush
前置问题与边界 一次 Put 从客户端发出后，不会直接变成 HFile。HBase 写路径先把 mutation 交给目标 RegionServer，在 Region 内完成行锁、WAL、MVCC、MemStore 更新和返回协议；随后由 flush 把 MemStore snapshot 写成 HDFS 上的 HFile。HFile 之后还会被 compaction 合并。 本篇回答一个核心问题：Put 从客户端到 HFile 经历哪些状态，何时对读取可见。BlockCache 和 HFile 读路径放到第 05、06 篇；compaction 清理旧版本和 Delete 放到第 07 篇；RegionServer 崩溃恢复放到第 11 篇。 HBase 2.6 的实现细节需要谨慎表述。WAL 是否同步、何时返回，受 mutation durability 和表配置影响。flush policy 可以选择哪些 Store 需要 flush，不能笼统写成任何 flush 都必然把 Region 内所有 column family 同时刷盘。 写入路径图 sequenceDiagr...
深入 HBase 03 - Schema 与 row key 设计
前置问题与边界 HBase schema 设计首先是 row key 设计，其次才是 column family 和 qualifier 的组织。row key 决定排序、Region 分布、范围 scan 和热点形态。column family 决定物理 Store、缓存、压缩、版本和 TTL 边界。qualifier 提供稀疏属性表达能力，但不替代 row key 的排序能力。 本篇回答一个核心问题：排序、前缀、salt、反转和时间桶如何影响热点与扫描。写入路径的 WAL/MemStore 状态放到第 04 篇；读取路径的 BlockCache、Bloom Filter 和 HFile block 放到第 05、06 篇；Region split 和 assignment 放到第 08 篇。 schema-less 不是没有 schema。HBase 不强制预定义 qualifier，但 row key 编码、family 数量、版本数、TTL、压缩、Bloom Filter 和访问模式都属于 schema 决策。 RowKey 决策图 flowchart TD Q[主要...
深入 HBase 02 - 集群架构：HMaster、RegionServer、ZooKeeper 与 hbase:meta
前置问题与边界 HBase 集群架构最容易被写成一张“Master 管所有、ZooKeeper 存所有、RegionServer 干活”的粗图。这个粗图会误导读写路径。普通数据读写的主路径是 Client 定位 Region 后直连 RegionServer；HMaster 负责表和 Region 的控制面操作；ZooKeeper 保存协调和服务发现所需的短状态；hbase:meta 是 HBase 系统表，保存 Region 路由元数据。 本篇回答一个核心问题：控制面、数据面、协调状态和路由元数据如何分工。Region split、merge 和 assignment 的状态推进放到第 08 篇；客户端缓存、重试和重新定位放到第 09 篇；ServerCrashProcedure 和 WAL 恢复放到第 11 篇。 基础版本仍是 HBase 2.6.6。HBase 2.x 客户端实现存在 ConnectionRegistry 等路径，不能把“客户端总是直接从 ZooKeeper 找全部 Region”写成唯一机制。更稳妥的表述是：客户端通过 registry/元数据定位 hba...
深入 HBase 01 - 数据模型：Cell、Column Family 与版本
前置问题与边界 HBase 的一个值不是由“第几行第几列”定位，而是由 (row, family, qualifier, timestamp) 这组坐标定位。row 是 uninterpreted bytes，按字典序排序；family 在建表时定义，是存储、压缩、缓存、版本数和 TTL 等配置的边界；qualifier 是 family 之内的列限定符，可以动态出现；timestamp 是版本维度。 本篇回答一个核心问题：(row, family, qualifier, timestamp) 如何唯一定位一个值。写入路径、MVCC、WAL 和 flush 放到第 04 篇；Delete tombstone 在 compaction 中真正清理的条件放到第 07 篇；行级原子性放到第 10 篇。 HBase 的“宽列”容易被误写成两种东西。它不是关系数据库里的稀疏宽表，因为 qualifier 不需要全表预定义，也不存在空列占位。它也不是分析型列存，因为物理按 column family 组织 Store，目标是按 row key 的在线读写和范围 scan。 Cell 坐标图 ...
深入 HBase 00 - 导读：row key 决定数据位置
前置问题与边界 HBase 能在 HDFS 上提供随机读写，不是因为 HDFS 获得了原地随机修改能力。HBase 把随机写接在 RegionServer 服务层：mutation 先经过 WAL 和 MemStore，随后 flush 成 HDFS 上不可变的 HFile。随机读也不是对 HDFS 文件做逐字节定位；客户端先定位 row key 所属 Region，再直连负责该 Region 的 RegionServer，由 RegionServer 合并 MemStore、BlockCache 和 HFile 中的结果。 本篇回答一个核心问题：HBase 为什么能在面向大文件的 HDFS 之上提供在线随机读写，代价落在哪里。row key 的 salt、反转和时间桶放到第 03 篇；WAL、MVCC、MemStore 与 flush 的时序放到第 04 篇；BlockCache、Bloom Filter 和 HFile 放到第 05、06 篇；Compaction、恢复、复制和运维会在后续篇目展开。 基础机制以 HBase 2.6.6、Hadoop 3.4.3、JDK 17 ...
OpenAI Codex Harness 源码解剖：它与 Codex CLI 到底是什么关系
OpenAI 最近开始频繁使用一个容易引起误解的词：Codex harness。 它不是一个需要单独安装的新产品，也不是 Codex CLI 改了名字。OpenAI 给出的最小定义是：harness 是围绕模型运行的执行系统，负责保存会话状态、组织工具循环、执行命令、施加 sandbox 与 approval 策略，并把过程事件交给上层界面。Codex CLI 则是这套系统最早、最直接的终端产品形态，同时也是它的发行入口和源码宿主。 因此，两者最准确的关系不是“同一个东西”，也不是“前端和后端”这么简单，而是： Codex CLI 包含并暴露 Codex harness；harness 可以脱离 TUI，被 codex exec、App Server、SDK 和其他 Codex 客户端复用。 这个判断可以同时解释几个看似矛盾的事实：为什么 OpenAI 会说 harness “通过 Codex CLI 暴露”，又说它驱动 Codex App、IDE 与 Web；为什么开源仓库叫 openai/codex，官方文档却称其中一部分为 Codex Core；为什么 TypeScri...
DeepSeek Harness：为什么插件机制比流程编排更像运行时
DeepSeek Harness（dsh）最值得研究的，不是它又接入了多少模型、工具或界面，而是它改变了 Harness 的架构主语。 传统工作流把任务图放在中心：节点做什么，边通向哪里，失败后重试还是补偿。许多 Coding Harness 也有插件、Hook、MCP 和扩展包，但 Agent Loop、会话状态与工具分发通常仍由一个固定运行时掌握。 DeepSeek Harness 选择了另一条路。模型适配器、工具注册表、Session Log、Agent Loop、Workflow Engine、沙箱、存储和 UI 都进入同一套插件装配与生命周期机制。Workflow 没有消失，它只是从架构中心降为一项可选能力。 这形成了一个很实用的判断： 流程图回答“下一步执行什么”，插件树回答“运行时由什么组成”。 两张图可以叠在一起，却不能互相替代。 本文资料核对至 2026-08-26；官方 master 仍指向 2026-08-21 的源码快照 b150a55。项目仍标注为 developer preview，公开 API 和插件边界可能继续发生破坏性变化。 先把两张图分开...
