HBase 配了 TTL 为什么数据还占空间？TTL 和多版本怎么配合？
本文目录
面试怎么回答
我会把读可见性和物理空间分开。HBase TTL 基于 Cell 时间戳，版本上下限也参与保留规则，所以先核对时间戳和列族配置。正常读取看不到过期数据，不代表旧 HFile 立即释放；还要看文件清理、Compaction 和快照引用。回灌旧时间戳可能很快过期，不能直接当写入失败。修改后分别验证读结果、版本与存储，不能只看磁盘曲线。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
列族已经设置 TTL，过期记录也查不到了，磁盘曲线却没有马上下降。是配置没生效，还是 HBase 没有删数据？这道题要先拆开三个问题：现在能读到什么、规则要求保留什么、旧文件什么时候真正释放。
逻辑可见性、版本保留和物理回收是不同层次；TTL 要结合 Cell 时间戳、版本规则和存储引用检查。
TTL 看的是 Cell 时间戳
HBase 的版本由时间戳区分，TTL 判断与这个时间维度有关，并不是简单从“最近一次客户端读取”开始倒计时。
如果写入时主动指定 Cell 时间戳，就需要理解它同时影响版本排序与保留。时间戳最大的值不一定是最后一次到达的写入；回灌历史数据时尤其容易混淆。
业务发生时间可以单独保存为属性，不一定非要写进 Cell 版本时间戳。选择哪种设计，要结合历史读取和保留需求，而不是看到一个 timestamp 参数就直接填业务日期。
多版本规则会一起参与
列族的 VERSIONS 限制最多保留的版本数，MIN_VERSIONS 可以保留一定数量的版本，即使它们已经越过 TTL 的时间范围。具体配置要结合部署版本核对。
因此，“TTL 设置七天，任何情况下都只能读到七天内的数据”不是无条件结论。最少版本保留、时间戳异常与访问方式，都应一并检查。
反过来，设置最多三个版本，也不是保证能读到三个。实际写入数、TTL 和删除等因素都可能让可见版本更少；普通 Get 默认只取最新版本，客户端读取请求同样影响观察结果。
查不到了，为什么文件还在？
读取过程可以依据过期与删除规则过滤数据，而旧 HFile 的物理回收需要后续文件清理流程。不能拿普通查询结果与磁盘占用做一对一即时比较。
过期数据的清理不应被简化成“只能等 Major Compaction”。包含全部过期数据的 StoreFile，在满足配置和版本规则等条件时，可以通过相应清理机制移除；混合有效与过期数据的文件则有不同处理成本。
删除标记与普通 TTL 过期也不是同一个机制。排查需要区分数据为何不可见，再检查相应文件、Compaction 和清理条件。
如果快照或其他引用仍需这些 HFile，文件可能进入归档保留，而没有立即释放底层空间。只有活跃表大小下降，不能证明整套存储的字节已经回收。
一个典型场景：刚回灌的数据立刻查不到
比如导入一批历史记录后，客户端返回成功，正常读取却找不到部分数据。最初怀疑写入丢失或 Region 切换问题。
检查发现，导入程序将很早的业务时间设为 Cell 时间戳，而列族开启了较短 TTL。在默认不保留最少版本的设定下，这批值写入后就符合过期条件。
旧测试使用当前时间生成记录，所以没有触发问题。根因是版本时间与业务时间混用，并非只凭查询缺行就能断言存储失败。
改进应明确时间戳策略，必要时把业务时间单独存字段，并测试老时间、未来时间和正常当前时间。不能为了让旧数据可见，就未经评估把整个列族 TTL 取消。
TTL 的单位也要认真核对
列族 TTL 以秒配置，Cell 级 TTL 接口使用毫秒；两处同样写一个数字，可能代表完全不同的时长。
Cell 级 TTL 也不能用来把数据寿命延长到超出列族 TTL 的有效限制。使用前要核对客户端接口与服务端支持，不把两个配置看成简单覆盖关系。
我会把测试固定在明确的时间条件下，检查到期前后及版本组合。边界测试应考虑时钟偏差和执行延迟，不要用一次刚好卡点的读取作为唯一证据。
不要为降空间盲目触发重操作
强制大规模 Compaction 会消耗磁盘读写与计算资源，未必符合当前业务窗口；若空间受快照引用影响，单纯合并文件也不能解决根因。
先确认占用来自活跃文件、归档文件还是其他路径，再决定清理动作。保留策略调整涉及恢复能力，不能将所有看起来“旧”的文件直接删除。
验收应分三层记录
第一层记录正常读能看到哪些版本，以及 Cell 时间戳和保留配置。第二层核对活跃文件与清理进度。第三层检查快照、归档引用与实际存储占用。
TTL 是留存机制，不是对所有备份和外部副本的自动清除承诺。面试回答能把这三层拆开，就不会落入“没查到就是彻底删了”或“空间没降就是没生效”的误区。