9.2 自定义扩展与加密压缩

9.2 自定义扩展与加密压缩：改造车间的安全守则

本节摘要：参数调不出业务语义，引擎在三个语义锚点上开放了行为编程：压缩过滤器裁决数据去留、合并算子定义多版本的业务聚合、文件分区器组织物理布局。本节讲清三个锚点各自的契约纪律与典型用法，再补上车间里的另外两台设备——分级压缩与加密环境，如何接管空间账与信任账的定制需求。

开放判断，锁死结构

改造车间有一条总章程：开放判断，锁死结构。 调度器不许重写、文件格式不许私改、内存不许裸碰——这些是引擎确定性的底盘。开放的只有三类「判断」：一条数据该不该留着、同一键的多个版本该怎么解释、一批数据该怎么组织物理布局。三类判断各对应一个接口，共用同一条纪律：幂等、只读、快速。幂等，因为压缩可能因崩溃重试，你的逻辑会被重复调用，同一输入必须永远同一输出；只读，因为回调里拿到的是数据的只读视图，你输出一个结果，写入由引擎原子完成；快速，因为回调跑在压缩的关键路径上，慢回调拖垮的是整个后台。

这三条纪律不是风格建议，是安全边界。一个有副作用的过滤器会在重试时重复副作用；一个贪快的合并算子里的慢操作会把压缩线程拖到停顿。第 5 章说压缩过滤器「按删库代码的标准评审」，本节把它推广到全部三个锚点。

压缩过滤器：清理逻辑免费搭车

第一个锚点管「留不留」。归并逐条裁决时，每个键值对递给你的回调过目：留、不留、或就地改写。它最典型的三类用法在第 5 章见过：会话过期、合规删除、业务时效清理——这些语义写在业务里，引擎本来看不见，过滤器把它们翻译给引擎。

它的账目魅力在于「免费搭车」：数据反正要被读出来归并，顺手过滤不增加任何额外读取；一次全量的历史清理，就这样摊进了日常压缩的成本里。它的账目风险在于「延迟生效」：过滤器只在数据被压缩碰到时才执行——一个键如果常年躺在最底层不再被归并，过滤器就永远轮不到它说话。需要强时效保证的清理，要配合定期压缩或存活期选项一起用，逼着数据定期过筛。就地改写的能力也要慎用：改写值意味着同一份数据在不同文件里形态不同，排查问题时多一层心智负担，能用「不留」解决的就不要「改写」。

合并算子：多版本的业务解释权

第二个锚点管「怎么算」。计数器场景的经典困境：同一键每秒被更新几十次，逐次覆盖写入，写放大与版本堆积齐飞。合并算子换个思路——更新不再是「覆盖」，而是「操作」：写入端只提交「加一」这样的增量指令，引擎把它们记为待折叠的操作；读取与压缩时，由你的回调把一串操作折叠成最终值。

收益立竿见影：写入端从「读改写三步」变成「追加一步」，高频更新不再互相等待；折叠发生在后台，前台路径最短。购物车、计数器、排行榜、状态机，都适合这个范式。契约细节要记两条：折叠回调必须处理「从零开始」的情形——操作序列前面可能没有任何存量值；相邻操作要尽量支持两两预先合并——引擎会在压缩时先把长操作串折叠成短串，不支持预合并的算子会让全量折叠推迟到最后一步，压力集中爆发。

文件分区器：物理布局的建议权

第三个锚点最小众，但思路最妙：批量导入外部文件时，文件怎么切、键范围怎么组织，可以交给你的回调建议。时序数据按时间窗口切，查询最近一小时就不必打开更大的文件；地理数据按区域前缀切，范围扫描的局部性直接改善。它只影响物理布局、不碰逻辑语义，是三个锚点里风险最低的一个——建议不当，代价不过是布局不够优。

分级压缩：空间账的精装修

说完三个锚点，补两台设备。第一台是分级压缩：不同层级用不同压缩算法。浅层数据新、很快会被重写，压缩编解码是白花的功夫，用最快的算法甚至不压缩；深层数据老、基本不再动，值得用高压缩比算法慢慢抠空间。再进一步，最深层可以单独指定算法——它是全库空间的大头，也是唯一值得为省空间多付 CPU 的地方。这一台设备的本质是把压缩开销按「数据还会不会被重写」来分配，空间账与 CPU 账的分界从此有了显式刻度。

落进配置是几行：

// 浅层求快：L0 到 L2 用快速算法
options.compression_per_level[two] = kNoCompression;
// 深层抠空间：最底层单独指定高压缩比算法
options.bottommost_compression = kZSTD;
// 校验和按块启用：静默损坏的最后一道防线
table_options.checksum = kxxHash;
​

加密环境：信任账的入口

第二台设备管信任账。合规要求落盘字节必须密文时，引擎的做法不是在各处散布加密调用，而是在文件访问环境这一层做整体包装：所有落盘读写在包装层统一过一遍加密解密，引擎内部其余代码对加密无感。这个设计的账目优点是「一处设防、全库生效」——数据块、账本、日志全走同一个包装层，不会出现「忘了某处加密」的漏洞；代价是密钥管理成了你的责任：密钥的存放、轮换、销毁都要有明确方案，密钥丢了数据就永远是乱码，密钥弱了加密就是装饰。

性能账也要算清：加密是纯 CPU 开销，吞吐敏感的负载要实测加密后的写放大与延迟变化；有硬件加速指令的介质与机型优先选上，让密语的开销降到最低。信任账的预算与空间账一样，是按业务合规等级采购的——不是所有库都需要，需要的库不能省。

三个锚点的适用对照

三个锚点常被问「该用哪个」，其实它们管的账不同，多数场景是搭配而非互斥。给一张对照速查：

对照表之外补一句组合技：合并算子与过滤器常一起上——算子把高频更新折叠成带时间戳的状态，过滤器顺手清掉过期的状态项，一折一清，状态类负载的全套治理就齐了。分区器则更多出现在数据工程链路的尽头：外部批量生成的文件按查询模式组织好再导入，属于「一次规划、长期受益」的一次性动作。

本节要点

• 改造车间总章程：开放判断、锁死结构；三条纪律幂等、只读、快速是所有回调的安全边界；
• 压缩过滤器管去留，清理免费搭车但延迟生效，强时效要配定期压缩逼数据过筛；
• 合并算子管聚合，高频更新从读改写三步变追加一步，预合并支持决定折叠压力的分布；
• 分区器只建议物理布局不碰语义，时序按窗口、地理按前缀，风险最低收益直接；
• 分级压缩按重写概率分配压缩开销，加密环境一处设防全库生效——两台设备分别接管空间账与信任账。