补数据最危险的做法，是改一个业务日期参数，然后把它当普通调度实例再跑一遍。页面上只有一个绿色的“成功”，实际发生的事情可能是：旧分区被覆盖了一半、下游提前启动、失败重试又写出一份重复数据，最后谁也说不清当前结果来自哪版代码。

我更愿意把补数据看成一类独立运行，而不是正常调度的快捷入口。它至少要回答四个时间：处理哪段业务数据、何时提出请求、何时真正执行、哪一刻把结果发布给下游。再加一个独立的 run_id，这件事才有可追踪的起点。

数据平台做成本治理，最容易拿到的是部门每月用了多少机器，最难回答的是：哪条任务、哪个业务日期、哪次失败重试花了这些钱。没有实例级归因，平台只能要求所有团队统一降资源，真正浪费的作业反而躲在平均数里。

我会先做一份可追溯的成本账本，把 project -> job -> instance -> attempt -> engine application/pod 串起来，再谈优化。成本治理不是给资源账单换一套图表，而是能从一笔费用追到真实运行证据，也能从一次重跑预估它会增加多少资源和存储开销。

开发和生产都存在 sales.orders 时，最危险的不是用户查错表，而是一个带生产凭证的测试任务真的把生产 metadata pointer 提交成功。SQL 语句、表名和 schema 全都合法，事故不会在 parser 或 type checker 阶段被拦住。

多环境 Catalog 隔离不能只靠名称前缀。dev_catalog 和 prod_catalog 如果背后连的是同一个 Metastore、同一个 warehouse，并且作业拿到同一套写凭证，前缀只是提醒，不是安全边界。我要求名称、控制面、存储位置和执行身份四层同时隔离。

Iceberg 表能被 Spark 和 Flink 正常读写，只能证明接入完成，不能证明可以长期运行。流式任务每天产生几百个 snapshots，小批写入不断增加 data files，失败任务留下 orphan files，time travel 保留策略又阻止旧文件回收。三个月后，表仍能查，但规划越来越慢，存储账单一直涨，维护脚本谁也不敢改。

我认为平台真正要补的是表级运维闭环：从 metadata tables 读取健康信号，按每张表的负载和 SLA 选择维护动作，记录提交与删除证据，再验证查询和成本是否改善。它不是几条全局 cron，而是和写入一样正式的生产链路。

数据契约一旦被理解成“上游不许改字段”，很快就会失效。业务一定会增加状态、调整口径、拆分字段，平台不可能靠审批把变化冻结。真正需要禁止的是未经识别、没有迁移窗口、出了问题无法回滚的变化。

我把契约看成生产者与消费者之间的变更协议。Schema 是其中可机器检查的一层，除此之外还要写清字段含义、主键、时间语义、空值、质量阈值、交付时效、owner 和弃用期限。契约的目标不是少改，而是让每次修改都有证据链。

ClickHouse 和 Apache Doris 放在一起比较时，很容易变成架构名词和 Benchmark 数字的拉锯。一个强调 MergeTree 和本地执行，一个强调 MPP、FE/BE 和标准 SQL。对业务真正有影响的差别，往往更早发生在 CREATE TABLE：同一业务键来了两条数据，最终保留两条、替换一条还是聚合成一条？这个结果在什么阶段完成？

我不会先问哪个引擎快，而会先把数据分成追加明细、主键状态、可结合指标三类，再看各自的数据模型把成本放在写入、后台合并还是查询阶段。模型选错以后，硬件和参数只能缓解，无法改正语义。

OLAP 选型会上最没用的一张表，是把十几个引擎放在列上，把实时写入、向量化、物化视图、Join、扩缩容逐项打勾。功能都支持，不代表对同一份业务负载有相同代价。

我更关心现有查询到底长什么样：多少 SQL 只查近一天，多少会扫一年；过滤条件是否命中排序键；是高并发点查，还是低并发大聚合；Join 的小表到底多小；数据更新后允许几秒、几分钟还是第二天可见。没有这份查询画像，Benchmark 很容易变成谁更会调参数。

把 Iceberg 表的 format-version 从 1 改成 2，看起来只是一条表属性更新。真正危险的是，这张表往往同时被 Spark、Flink、Trino、离线维护脚本和自研 SDK 访问。创建表的人确认自己的引擎能读 v2，并不能证明整条生产链路已经兼容。

格式版本升级与普通依赖升级不同。旧 reader 遇到自己不理解的新表特性，正确行为应该是拒绝读取；更糟的实现可能加载成功，却没有应用 delete files，悄悄把已删除的行读出来。上线前必须把“有哪些访问者、每个访问者执行什么动作”展开成矩阵。