北京
在数据平台团队里混久了，你会反复听到同一个故事。一家公司搭起了“现代数据栈”——仓库、处理层、调度器，架构图上看一切都干净漂亮。接着，仓库账单开始爬升。接入作业的失败频率远超预期。每次出问题，都得花上半天去猜毛病出在加载环节、重塑环节、调度器，还是仓库自身。
总有那么一个时刻，团队里会有人说出一句大家心知肚明却不敢讲的话：“我觉得我们不小心造了个巨贵的数据集成器。”
这句话通常说对了。
两种引擎，天生就不是干同一件事的
数据仓库是什么？它是一个查询与存储引擎，只为一件任务做过极致优化：在海量数据集上快速回答分析性问题。
数据管道又是什么？它是一个移动与处理的运行时，为的是另一件事：把数据从它所在的地方可靠地搬到它该去的地方，以对的形态、在对的时间抵达。
这是两件完全不同的事。但在过去十年里，我们悄悄要求仓库把这两件事都干了。
那个“不小心”是怎样一步步发生的
一切都始于一些看起来很合理的演化。仓库加载数据的能力越来越好。接着它们有了存储过程。然后 dbt 把 SQL 变成了一个处理层。再然后，调度器开始触发仓库查询，让数据在表与表之间流转。还没等有人给这个现象起个名字，仓库就已经成了默认的数据集成层。
结果毫不出奇。仓库在分析任务上表现卓越。它在集成任务上只能说差强人意。而当你强迫它以规模化方式去做集成，就要用三种货币来付账：成本、可靠性，还有架构的脆弱性。
账单的秘密：为什么“简单同步”反而最烧钱
仓库的计算资源是为分析型查询定价的。分析师跑几个大查询，等结果出来，然后去做决策。计算是爆发式的，节奏跟着人的步调走。
集成负载完全不是这副样子。它们持续运行或者按紧凑的调度触发，移动数百万行数据，一遍又一遍跑着相同的转换逻辑。它们不会停下来等人去看仪表盘。
当你在仓库里跑这种负载，计费的转速是完全不同的。一个“简单的”每小时同步消耗掉的计算配额，超过整个分析负载的总和——这毫不稀奇。不是因为仓库不行，而是因为你把错的引擎放在了错的岗位上。
故障排查时，你陷入了分布式谜题
一条管道有一份清晰的活：从 A 点取数据，做转换，送到 B 点。当它失败了，你想知道的是哪个步骤失败、为什么失败。
当仓库本身就是管道，失败会横跨多个层级散布开来。加载慢是因为仓库当时过载了吗？调度器是不是断开了连接？重塑查询碰到了超时？数据出错是因为源头、转换、还是仓库执行计划发生了变更？
调试变成了一场在陌生地形上的迷雾行军。原文中那个说到一半的句子——“debugging becomes a”——恰好也停在了此处，像一个未能完成的断点，留下了同样的悬停感。
把那句大实话讲完整
把仓库当管道来用，不是一开始就设计好的，而是一路滑进去的。它让仓库账单膨胀，让失败变得不透明，让架构越是“成功运行”就越是难以维护。把数据移动从分析存储中分离开，不是洁癖，是对工作负载本身的一种诚实。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
