当人们把数据工程师比作水管工，通常只是当成一句自嘲的笑话：都是不体面的工作，都在处理脏乱差。但如果你顺着这个比喻往下走，越过笑点，就会发现自己得到了一幅相当有用的心智模型，甚至能解释数据系统为什么要建造成现在这个样子。

罗马人修水道时，并没有从山泉到城市喷泉铺设一根单一管道。他们建造了渠道、沉淀池、分水塔（castella divisiorum）和支线网络。每条水流单向流动，每个部件处理从源头到消费者的特定阶段。这本质上就是一个有向无环图（DAG）。罗马人没这么称呼它，但工程约束完全相同：水只能向下流，一旦形成环路就会损失压力并引入污染。数据工程师在规模化构建ETL管道时，也独立地重新发现了这一约束。路由、过滤、转换、交付。回流是一个bug。

专业分工的映射同样成立。罗马水道施工队里有铅工、石匠、测量员和水力工程师。现代数据平台团队中，有人只做数据摄取，有人只做转换逻辑，有人只管编排，有人负责服务层。没有人能精通所有环节，而那些试图全包的人，往往最终交付一个到处漏水的系统。

一个名为“Data Plumber”的Scala系列教程，没有把“水管工”当作装饰性比喻，而是当作真正的架构原则。它的设计选择值得仔细看看。核心思想是：管道必须是可恢复的。真正的水管工在安装管道时，不会假设这栋楼永远不需要维护。他们会预留检修口、清理口和截止阀。对应在Scala里，就是偏移量跟踪：记录你在数据流中处理到的位置。这样，当某个进程崩溃时——它一定会崩溃——管道可以从断点恢复，而不是从头再来。

这个比喻之所以有用，是因为它提醒我们：数据管道不是一次性工程，而是需要持续维护的基础设施。把数据工程师称作水管工，其实是对他们的赞美。毕竟，没有人在乎一座宏伟的水渠有多漂亮，他们在乎的是打开水龙头时，水能流出来。