2026-05-13

新 Dashboard：从 4–6 周缩短到约 1 个工作日

在某知名时尚客户，C 团队的 DA 先用 notebook 开发，DE 再用 PySpark 重写并接入 Airflow。重构后，多数新 Dashboard 在约 1 个工作日内完成，日常数据也能在业务上班前准备好。

问题：新需求交付慢，现有 Dashboard 刷新也晚

痛点一：任何改动都要写两遍，故障却没人能独立闭环

工单看起来很普通：

“一些 Dashboard 的数字不对，你能修一下吗？”

表面问题是一组报表数字出现偏差。顺着数据链路往上查，我看到的是一套跨部门的重复开发流程。

这家客户的 DA 不属于 DE 团队。他们在具体的业务团队里工作，例如 C 团队。C 团队提出需求后，团队里的 DA 先用 notebook 开发业务逻辑。这个阶段在交付计划中通常占一个 sprint，但当时没有单独统计纯粹用于新增逻辑的时间，notebook 运行维护也混在其中。 Notebook 完成后再交接给 DE；DE 用 PySpark 工程文件重新开发一遍，接入由 Airflow 治理的 ETL，这一步还要一到两个 sprint。

C 团队 business requirement
→ C 团队 DA notebook：开发与维护阶段，排期约 1 个 sprint
→ 跨部门人工交接
→ DE PySpark 工程文件：运行版本，1–2 个 sprint
→ Airflow 治理的 ETL
→ Dashboard

同一条业务规则因此存在开发版本和运行版本。一个新 Dashboard 要依次经过两个团队的 backlog，整个交付周期通常是 4–6 周。

这套交接不区分需求大小。新增 Dashboard 要完整走一遍；debug、改一个 filter、修一个 bug，同样要由 DA 修改 notebook、向 DE 解释改动，再等 DE 修改 PySpark 工程文件。两边的数字不一致时，大家还要同时检查 notebook、PySpark 版本、源数据和 Dashboard 查询。开会对齐也成了 debugging 流程的一部分。

生产出问题时，责任边界也跟着变得模糊。DA 掌握业务逻辑，但看不懂 DE 重写后的 PySpark 运行代码，也无法直接修复生产版本。DE 可以修改 PySpark，却需要 DA 解释业务规则、确认预期结果，再完成一次交接。双方的判断各有依据：运行代码由 DE 维护，业务含义由 DA 负责。系统设计把解决一个问题所需的知识和权限切在了两个团队里，结果是任何一方都无法独立完成诊断、修改和验收。

速度实在太慢，C 团队的 DA 最后开始用 cron 调度 notebook，再把结果直接送进 BI。 Shadow pipeline 缩短了等待时间，也脱离了 DE 用 Airflow 治理的 ETL。测试、lineage、告警、监控和统一运维仍然存在于正式平台中，业务实际使用的数据却从另一条链路生产。

痛点二：业务早上看不到最新数据

我介入之前，每日 Dashboard 的刷新时间也很晚。团队无法稳定保证 business user 早上开始工作时已经看到最新数据，周一早上的问题尤其明显：周末后第一轮业务分析开始了，Dashboard 仍可能在等待上游数据或 notebook 运行完成。

根因：开发版本与运行版本分离，叠加跨部门手工交接

问题由两层结构叠加产生。Notebook 是 C 团队维护的开发版本，PySpark 工程文件是 DE 维护的运行版本；两份代码之间没有可执行的同步接口，只能通过工单、会议和人工解释跨部门传递。

1. 开发版本和运行版本各自演进

DA 在 notebook 里实现业务需求，DE 再根据 notebook 和交接说明维护 PySpark 版本。任何一边修改 filter、join、时间窗口或边界条件，另一边都不会自动更新。两份代码表达同一个业务意图，却由不同团队、不同 backlog 和不同发布节奏维护。

2. 每次修改都要穿过部门墙

C 团队的 DA 完成开发后，要把输入、输出、业务规则和预期结果交给 DE。DE 重新理解需求、排期、开发和验证。即使只修一个小 bug，这套 handoff 也不会缩短；修改规模很小，组织等待时间仍然可能占满一个或多个 sprint。

3. 正式链路的交付成本催生了 shadow pipeline

Airflow ETL 具备统一调度、测试、lineage、告警和运维能力，但每次需求都必须等待 DE 重写。Cron notebook 让 C 团队绕过排期并更快拿到数据，因此逐渐成为业务实际依赖的生产方式。正式治理链路和真实交付链路由此分开。

4. Shadow pipeline 无法可靠判断输入是否 ready

Cron notebook 缺少自动检查上游 table 刷新状态的能力。为了降低空跑或读到旧数据的风险，DA 只能把 schedule 设置得更晚。Notebook server 的计算能力也弱于 DE 的 cluster，实际运行更慢。多条 cron 任务分散运行后，DE 看不到完整 DAG 关系，也无法从全链路识别和优化 bottleneck。

这里还有一个组织边界。C 团队拥有 Dashboard，分析师拥有 notebook。第一次为这家客户工作时，我已经提出过这条重复实现链路，但当时 engineering 没有足够的授权和信任去改变另一个团队的工作方式。

第二次回到这个项目后，我先处理团队眼前的问题：报表错误、Spark 性能事故、IAM 权限混乱。几个月持续交付之后，双方有了足够的信任，可以借下一张报表错误工单试一套新的流程。

解决方案：让 DA 编写的 SQL 进入受治理的交付链路

我用一周时间，在现有生产流程旁边搭了一条并行链路，选择一个 Dashboard 做完整验证。新旧流程读取相同输入并产生相同输出，团队可以直接比较结果和交付过程。

DE 为这条通道定义了八项约束。DA 保留编写业务逻辑的速度，DE 继续控制数据边界、运行方式和最终发布。

1. Notebook 只允许 SQL

DA 的 notebook 中不允许使用 Python。SQL 已经能够覆盖所需的 transform，阅读门槛也更低；更重要的是，parser 和 lint 工具可以静态分析 SQL 的输入表、输出表和语句类型。DE 因此能够在代码运行前检查它会读什么、写什么以及采用哪种写入方式。

稳定运行后，大多数新增业务逻辑由 DA 在数小时到一天内完成。

2. 输入只能来自 Silver 和 Gold

DA 使用的数据必须来自 DE 已经治理的 Silver 或 Gold 表。这些表由 Airflow 管理，具备明确的 owner、调度和刷新状态。Notebook 不能直接读取未经治理的临时来源。

3. 输出只能写入 experiments data layer

DA 没有权限把 notebook 输出写回 DE 的 Silver 或 Gold 域。所有中间结果先进入专用的 experiments data layer。第二条和第三条共同形成单向数据流：受治理数据可以进入实验层，实验结果不能回写成为自己的上游，从结构上防止数据回环。

4. SQL 必须幂等

同一批输入重复执行时，结果必须保持一致。写入策略只允许 overwrite，禁止 append。 Airflow retry、手工重跑和历史补跑因此不会重复累积数据。

5. YAML 是每个 notebook 的交付合同

DE 用一份 YAML 文件登记所有 notebook，包括输入表、输出表和调度信息。整个 YAML 在 CI/CD 中接受静态检查；同一份配置也用于生成数据血缘、识别上下游关系并跟踪调度依赖。Notebook 和调度定义由此共享同一份机器可读合同。

6. Review 通过后自动提取 SQL，并通过 DQ 才能发布

Notebook 通过自动检查和 review 后，工具会按照 cell 顺序提取 SQL，生成一组顺序执行的 .sql 文件。SQL 先在 experiments layer 中运行。DE 管理最终 Gold table 的 schema 和写入权限，所以 DA 引入的 schema 变化只影响实验层。最终结果通过 DQ 校验后，才会 publish 到 DE 管理的 Gold table。

7. DAG factory 接管调度和依赖

DE 的 Airflow 使用 DAG factory 从 YAML 自动生成对应 DAG。代码根据 notebook 的输入输出关系分析 DAG dependency，并把上游表刷新作为运行门禁。输入 table 尚未刷新时，下游 notebook DAG 不会启动。DAG 因此可以提前 schedule，在输入 table 刷新完成后立即运行，无需预留一段固定的保守等待时间。

8. 公共组件由 DE 维护

DQ 检查、Gold promotion、向最终 BI 系统发布等公共能力由 DE 统一实现和维护。任务运行在能力更强的 DE cluster 上。Airflow 展示完整 DAG 运行图后，DE 也能识别跨任务 bottleneck，持续优化关键路径。DA 专注业务 SQL；安全边界、调度可靠性和生产集成由平台提供。

改造后的日常开发流程

DA 仍然在熟悉的 notebook 中开发、修改和 debug，并先把 experiments layer 的输出跑通。变化发生在后台：notebook 自动同步到 DE 管理的 repository，所有修改都有版本记录，DA 不需要操作 Git，也不用把业务逻辑重写成另一种语言。

结果确认后，DA 只需通知 DE 可以部署。DE 将同步后的 notebook 推到分支并发起 PR，通常需要 10–20 分钟。CI/CD 随后检查 SQL 类型、输入输出边界、幂等性、YAML 合同和依赖关系。检查通过，表示这次修改没有突破 DE 定义的限制；流水线会自动提取 SQL、构建 DAG，并在约 10 分钟内完成生产部署。DE review 的对象仍然是 DA 已经跑通的那份 notebook，不再重新实现业务逻辑。

PR 操作和流水线执行本身合计约 20–30 分钟；把通知、等待 review 和部署确认计算在内， SQL 完成后的生产接入通常落在 1–2 小时。

DA 在版本化 notebook 中开发或 debug
→ experiments 输出验证通过
→ DA 通知 DE 部署
→ DE 推送同步版本并发起 PR（10–20 分钟）
→ CI/CD 检查 DE guardrails
→ 自动构建 SQL 和 DAG，并部署生产（约 10 分钟）

故障处理也有了清晰路径。Airflow 发出告警后，DE 先检查受治理边界：上游输入是否缺失，最终输出 table 的 schema 是否偏离合同。输入、输出或平台运行问题由 DE 修复；如果边界正常，问题回到业务逻辑，DA 直接使用同一份 notebook 在 experiments layer 中 debug，修复后再走上述自动化流程。双方不再交接和翻译两份实现，只需要根据可观测结果判断问题落在哪一侧。

DA SQL notebook
→ CI/CD：SQL-only、幂等、受治理输入、experiments-only 输出
→ 自动提取顺序执行的 SQL 文件
→ YAML + DAG factory + 上游刷新门禁
→ experiments data layer
→ DQ validation
→ DE 管理的 Gold table
→ BI publish

并行验证让方案变得具体。业务方看到的是相同输入、相同输出，以及明显缩短的交付链路。工作样例提供了足够的证据，新的协作方式随后获得批准。

效果：业务、DA 和 DE 三赢

最终效果可以归纳为三点：

业务： 每日 Dashboard 数据在早上 5–7 点准备好，业务人员 9 点上班前就能看到最新结果。
DA： 从维护旧 notebook、处理运行故障和手工检查刷新中释放出来，重新聚焦于开发新需求。
DE： 省去用 PySpark 重复开发业务逻辑以及反复解释、交接和对齐的时间，把精力转向数据质量、性能和平台能力。

指标	改造前	改造后
DA 完成新增业务逻辑	没有稳定口径	通常数小时–1 天
SQL 完成后接入生产链路	1–2 个 sprint	1–2 小时
新 Dashboard 端到端 TTM	4–6 周	约 1 个工作日
DA 释放出来的团队容量	—	约 6–8 人日 / 周
DE 释放出来的时间	—	约 5 人日 / sprint
Dashboard 刷新就绪	10–11 AM	5–7 AM

改造没有直接缩短 DA 编写一条新业务逻辑所需的思考和开发时间。改造前也没有可靠的统计口径；新流程稳定后，大部分新逻辑可以在数小时到一天内完成。更明显的变化来自团队容量：DA 不再长期维护 cron notebook、处理运行失败和手工确认刷新结果，可用时间增加了，也能把更多精力用于新需求。SQL 完成后的生产接入只需 1–2 小时，新 Dashboard 的端到端交付通常在约 1 个工作日内完成。

按 8 小时工作日估算，4 位 DA 原来每周一要共同花 4 小时处理问题，相当于 16 个工时；此外，每位 DA 每周还要花 1–1.5 天处理自己负责的 notebook 故障，合计 32–48 个工时。在两部分时间不重叠的前提下，团队每周共有 48–64 个工时，也就是约 6–8 个人日，消耗在维持现有 notebook 运行上。改造后，这部分工作大幅减少，释放出的容量大部分可以用于开发新需求。

原来等待 DE 重写和排期的阶段被移除后，DE 每个 sprint 释放出约 5 个人日，开始处理长期积压的平台工作：源数据质量、性能瓶颈、lineage UI，以及计算和存储效率优化。

Dashboard 数据原来通常在上午 10–11 点准备好，改造后提前到 5–7 点。这个提升来自三个变化：

Airflow 自动检查输入 table 是否 ready，DAG 可以提前 schedule，并在上游刷新后立即运行。
SQL 运行在 DE 的 cluster 上，执行速度高于原来的 notebook server。
DE 能看到完整 DAG 运行图，找到跨任务 bottleneck，并持续优化关键路径。

业务用户因此能在早上开始工作时看到最新数据，周一早上的稳定性也得到改善。受治理的路径成为速度更快、结果更可预测的交付方式，DA 不再需要维护 cron shadow pipeline。

想聊聊？和我的助理辩一辩，或者给我留个言。