这是一个在每家采用 databricks 的公司都会上演的场景：
一位资深工程师将一个新的数据管道部署到生产环境。这是一个合并（MERGE）任务——从银层 Delta 表中读取数据，应用一些业务逻辑，然后向上插入或更新到为高管仪表板提供数据的金层表中。他们在开发环境中使用一个 40 GB 的样本进行了测试。运行耗时四分钟。输出干净无误。通过了代码审查。
但他们不知道的是：生产环境中的金层表大小为 3.8 TB，且在合并键上没有进行 Z 排序（Z-ordering）。也没有进行分区裁剪。因此，每次该任务运行时，databricks 都会扫描整个表——全部 3.8 TB——以查找需要更新的行。
任务仍然成功。退出代码为 0。工作流用户界面中显示绿色对勾。输出是正确的——只是生成成本高得灾难性。它每 30 分钟运行一次。没有人设置成本警报。
该管道运行了十一天，直到有人拉取每月的 databricks 单位（DBU）报告。计算费用为 2,300 美元。而这项任务本应只花费约 40 美元。
没有错误。没有失败。只是一种安静的、持续的消耗，而绿色的状态图标从未提及这一点。
使这种情况成为可能的假设
当大多数工程师成长为资深级别时，他们已经内化了一种无声的信念：如果它运行且未抛出异常，那么它可能做了正确的事情。
这合乎情理。你编写一个函数，运行它，它要么正常工作，要么报错。你编写测试——它们要么通过，要么失败。持续集成（CI）管道：绿色或红色。软件开发的整个反馈系统是二元的且即时的。成功是清晰可见的。
生产环境中的数据工程以特定的方式打破了这一模型。管道可能在所有技术指标上都成功——无异常、退出代码为 0、状态为绿色——但同时：
- 破坏数据完整性
- 使成本膨胀 50 倍
- 静默地丢弃记录
- 生成的结果几乎正确，但这种偏差需要数周才能被发现
绿色对勾并没有欺骗你。它告诉你管道已运行。但它对于管道是否执行了你的意图只字未提。
生产环境中实际发生的变化
故障面更大，反馈循环更长。仅此而已。这就是全部的区别。
规模暴露了假设。在 40 GB 样本上运行的代码可能在 3.8 TB 的数据上严重失败——不是因为逻辑错误，而是因为关于数据分布、基数和空值率的假设在大规模下不再成立。根据定义，开发环境的数据几乎不能代表生产环境的数据。你无法仅通过测试来摆脱这个问题。
失败很少是大张旗鼓的。在应用工程中，出问题通常看起来就是出问题了。服务宕机，用户抱怨，异常浮现。在数据工程中，错误的结果看起来像正确的结果。一个丢弃了 15% 记录的连接操作不会自我宣告。一个写入过时数据的管道不会触发警报。你必须主动去寻找问题，这意味着你必须知道要寻找什么。
成本是一个首要关注点。在开发环境中，你启动一个集群，运行你的笔记本，然后关闭它。成本是事后才考虑的事。在生产环境中，管道的成本概况是其正确性的一部分。一个得出正确答案但成本高出必要水平 50 倍的管道并不是成功——它是一个设计缺陷。那个花费 2,300 美元的合并任务并非异常现象。这只是寻常的一个星期二。
服务等级协议（SLA）是真实存在的。没人关心你的开发笔记本何时完成。在生产环境中，仪表板有刷新时间表。报告会在早上 7 点到达收件箱。当你的管道运行时间比预期长 3 倍时，这不仅意味着缓慢——还意味着其下游的所有内容也可能失败。延迟是伪装下的正确性问题。
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
