报表的痛，根子在团队合作方式

工单

“一些 dashboard 数字不对——你能修一下吗？”

工单就这一句。理论上是标准的 data engineering 活：花一下午找到坏的 join，发个 fix，下班。

工单只是症状

把破数字这一层揭开，下面的实际样子是：PVH 的数据团队已经分裂成 两半，两边几乎读不懂对方的代码——

• DA（分析师）在 notebook 里出业务逻辑——能 SQL 的写 SQL， 不能的写 Python。
• DE（工程师）拿到这套逻辑后用 PySpark 重写一遍，丢上 Spark 生产、Airflow 调度、对接 BI。

每个 dashboard 都要写两遍。排查一个数字差异要开一次会。出一个 新 dashboard，DA 在 notebook 上花约 2 周，再等 DE 排 1–2 个 sprint 来重写。

DE 成了肉眼可见的瓶颈。于是 DA 悄悄放弃了平台——他们手动跑 notebook，把结果直接灌进 BI。版本管理、测试、lineage、告警、 监控：全部没了。DE 辛苦搭起来”保证数字正确”的那一整套，全在 真实交付链路的上游，碰不到真正的链路。

“数字不对”只是那条 shadow pipeline 最显眼的症状，不是病因。

难的是拿批准

看见这个问题并不难。我第一次在 PVH 的时候就已经 flag 过这个 rework 循环，也尝试推动过改革。没推得动——这也可以理解。 dashboard 归 CRM 所有，notebook 归他们家分析师所有，让他们仅 因为一个走了又回来的 contractor 一句话就改变工作方式，这不是 engineering 单方面能 mandate 的事。信任还没建立。

所以第二次 engagement 头几个月，我就埋头修活。数字不对的工单、 Spark 性能事故、IAM 一团乱麻——一个一个接，一个一个解。这换来 的信用，是讲道理换不来的。

下一次机会，还是一张”数字不对”的工单。这次我没只是打 patch， 而是花了一周时间，在 prod 边上搭了一套并行环境，把新的协作方式 端到端跑了一遍：一份 DA 写法的 SQL notebook、commit 时的 lint 钩子、YAML catalog、DQ gate、同一个 dashboard 从新链路拉出来。 跟 prod 并排，同样的输入，同样的输出。

这样就够了。

真正改的是什么

不是”修 dashboard”。也不是”再招几个 DE”。而是改 DA 和 DE 之间 的协作方式。

• DA 只写 SQL，不写 PySpark。 理由很机械：sqlfluff 这类 静态分析器能把 SQL 一路解析到 IO 关系层，于是 lint 钩子可以 机械地知道一个 notebook 读了哪些表、写了哪些表，并据此卡门。 PySpark 在业务层没法做同样的静态分析——想知道它到底干了什么， 只能靠人读。
• Notebook 在 commit 时统一 lint。 输入必须来自 DE 治理的 表。输出必须 idempotent。违反则 git commit 直接失败——DA 第一时间就知道，而不是三天后的 standup 上才听说。
• 一份 YAML 登记所有 notebook。 输入表、输出表、调度、特殊 运行时需求。这份 YAML 就是 Airflow 调度的唯一可信来源，同时 白送 lineage 和上游就绪检查。
• DE 一次性包揽 boilerplate。 上游检查、catalog 交互、IAM、 BI 投递，以及把 DA 自助表里通过校验的行提升到 DE 同名生产表的 DQ gate。DA 只负责 transform 逻辑本身。

四件事，没有一件是 dashboard。

数字

指标	改造前	改造后
新 dashboard TTM	4–6 周	1–2 小时
DE 释放出来的时间	—	约 5 人日 / sprint
Dashboard 刷新就绪	10–11 AM	5–7 AM

释放出来的这些人日，DE 拿去做真正的平台事：源数据质量、性能瓶颈、 lineage UI、计算/存储效率优化——他们写了一堆工单但一直没空做的 东西。

经验总结

大多数工程问题，本质都不是”我们不知道怎么造 X”。本质是”我们其实 不知道自己在造什么，于是在用复杂度去补偿”。dashboard 没坏，坏的 是两个团队之间的交接，组织在这个坏交接外面又搭了一条平行的 shadow pipeline，只为继续把活交付出去。

每个系统都在朝更高的熵漂。值得问的是你改什么、让它有一阵子朝 反方向漂。通常要改的是协作方式，不是一段代码。