湖仓表“每天数据都写成功”，不代表它运行健康。流式任务持续产生小文件，快照和 manifest 逐渐膨胀，失败作业留下未引用文件。查询开始变慢、Catalog 元数据增大时，团队才临时跑一次全表 compaction。

这种做法把表维护当清洁脚本，实际上它和写入、查询一样是持续服务。维护延迟会积累运行负债，维护过猛又会抢资源、制造提交冲突甚至误删在途文件。它需要自己的 SLI、SLO、容量和变更治理。

知识库页面显示“今天更新”，不代表用户现在问问题能检索到今天的内容。源文档变更后，要经过事件发现、抓取、解析、embedding、索引发布、复制与缓存失效。任何一段积压，答案都可能继续引用旧版本。

我把新鲜度定义为 query-visible time - source event time，再拆成各阶段延迟预算。没有源事件时间时，只能报告“平台最近一次成功观测”，不能把抓取时间冒充内容真实更新时间。

给数据团队分 YARN 配额时，一个常见算法是统计上个月平均使用率，再按比例切队列。A 部门平均用了 40%，就给 40% capacity；B 部门平均 20%，就给 20%。报表看起来有数据依据，到了每天凌晨，两个部门的关键任务一起跑，队列还是排满。

平均值描述长期资源消耗，不描述任务在 SLA 窗口内是否碰到一起。一个队列每天只忙两小时，平均使用率很低；这两小时如果正好承担日结、报表和下游出数，它需要的保证容量可能比全天平滑运行的队列更高。

CapacityScheduler 的 capacity 本来就不是一堵静态资源墙。它给队列保证一部分容量，空闲资源可以被其他队列借用，maximum-capacity 再限制弹性上界。配额设计的重点应该是关键时间窗口内的并发需求、可等待时间和资源回收速度，而不是把集群按月均比例永久切开。