1. 数仓之痛：单体架构的瓶颈与挑战
做数据平台这些年，我见过太多团队从零开始搭数仓，满怀信心地选了一体化方案。结果呢？半年后就开始头疼。数据孤岛、ETL 跑不动、业务方天天催……说白了，单体数仓的架构红利，在数据量小的时候确实香，但一旦规模上来，问题就全暴露了。
这一章，咱们就来聊聊单体架构到底痛在哪。我把自己踩过的坑、见过的案例，都揉碎了讲给你听。
1.1 数据孤岛：看似统一，实则割裂
很多公司一开始都只有一个数仓，所有数据往里灌。听起来很美好对吧？但实际用起来，你会发现每个部门都在偷偷建自己的“小仓库”。
为什么会这样？因为单体数仓的模型设计太死了。业务方等不及你慢慢建模，他们自己拉数据、自己算指标，久而久之就形成了无数个 Excel 表、Access 库、甚至 Python 脚本跑出来的临时文件。这些数据跟数仓里的正式数据对不上，口径也不一致。
我印象最深的一个项目：某电商公司，市场部说 GMV 是 1.2 亿，财务部说是 9800 万，两边吵了三天。最后发现，市场部把未支付的订单也算进去了。这就是数据孤岛的典型后果——口径不统一，没人说得清哪个是对的。
数据孤岛的三个典型表现：
- 口径冲突：同一个指标，不同部门定义不同
- 数据冗余：同一份数据被反复拷贝，占用大量存储
- 信任危机：业务方不再相信数仓的数据，自己另搞一套
你想想看，数据孤岛的本质不是技术问题，而是架构问题。单体数仓把所有数据集中管理，但业务逻辑的分散性决定了它根本管不住。
1.2 ETL 效率低下：跑一次要半天
ETL 慢，是单体数仓最直接的痛。我见过一个金融客户，每天凌晨 2 点开始跑 ETL，跑到早上 8 点还没跑完。业务方 9 点上班想看报表，数据还是昨天的。
为什么会这么慢？原因有三：
- 全量计算：很多 ETL 任务设计得粗糙，动不动就全表扫描。明明只变了 1% 的数据，却要重算 100%。
- 串行依赖：任务之间强耦合，一个环节卡住，后面全堵死。我记得有一次，一个上游表的分区策略改了，下游 30 多个任务全部失败。
- 资源争抢：所有 ETL 任务共享同一套计算资源。跑大任务的时候，小任务只能排队等着。
避坑指南：我曾经在一个项目中，把 ETL 从全量改为增量，调度时间从 6 小时降到了 40 分钟。但要注意，增量 ETL 对数据质量要求更高，脏数据会一直累积。所以，一定要做好数据质量监控。
这里我画了一张图，帮你直观理解单体数仓的 ETL 瓶颈：
1.3 存储与计算耦合：想扩容？先拆家
单体数仓最坑的地方，就是存储和计算绑在一起。你想扩容存储？对不起，计算节点也得跟着加。你想提升计算能力？存储也得跟着翻倍。
这种耦合带来的问题很现实：
| 场景 | 单体数仓的做法 | 实际后果 |
|---|---|---|
| 存储不够 | 加节点，计算资源跟着浪费 | 成本翻倍，利用率不到 40% |
| 计算不够 | 加节点，存储空间白白闲置 | 存储浪费，运维复杂 |
| 需要弹性 | 无法独立扩缩容 | 高峰期扛不住，低谷期资源空转 |
我亲身经历过一个案例：某互联网公司，双十一期间数据量暴增 5 倍。单体数仓扛不住，运维团队紧急加节点。结果呢？存储扩容了，但计算资源也翻倍了，成本直接飙升 300%。活动结束后，这些资源又闲置了，白白烧钱。
注意：存储与计算耦合，不只是成本问题。它还会导致运维复杂度飙升。每次扩容都要评估两个维度，出错的概率翻倍。我见过一个团队，扩容时配错了参数，导致整个集群挂了 3 天。
1.4 业务响应慢：改个指标要两周
单体数仓的模型设计，通常是自顶向下的。先建主题域，再建明细层，最后才是应用层。这套流程走下来，改一个指标至少需要：
- 需求评审：1-2 天
- 模型设计：2-3 天
- ETL 开发：3-5 天
- 测试验证：2-3 天
- 上线发布：1-2 天
加起来，最快也要两周。业务方等得起吗？等不起。所以他们自己搞，数据孤岛就这么来了。
为什么会这么慢？核心原因有两个：
- 模型耦合：底层模型改了，上层所有应用都得跟着改。牵一发而动全身。
- 流程僵化：所有变更都要走完整流程，没有快速迭代的通道。
一个真实的对比：
我服务过两家公司。A 公司用单体数仓，改一个指标平均 10 天。B 公司后来转型数据网格，同样的需求，2 天就能上线。差距在哪？不是技术，是架构思维。
1.5 小结：单体数仓的四大痛点
说了这么多，其实就四个字：不够灵活。数据孤岛、ETL 低效、存储计算耦合、业务响应慢，这些问题不是靠优化能解决的，是架构本身的问题。
你想想看，一个架构如果连独立扩缩容都做不到，连快速响应业务都做不到，那它迟早会被淘汰。下一章，咱们就来聊聊怎么打破这个困局。
嗯，先消化一下这些痛点。后面我会带你一步步看，数据网格是怎么解决这些问题的。