1. 成本优化总览：为什么数据流水线成本会失控？

大家好，我是你们这堂课的老朋友。咱们开门见山——数据流水线的成本，为什么总是像个无底洞？

我见过太多团队，月初预算充足，月底一看账单直接傻眼。说白了，成本失控不是一天造成的，而是从一开始就没想清楚钱花在了哪儿。

这一章，咱们先把全景图铺开。你只有知道钱从哪流走，才能知道怎么堵住漏洞。

1.1 成本失控的三大典型场景

先聊聊我亲身经历的几个案例。你听听看，是不是似曾相识？

• 场景一：一夜爆单，账单翻倍
  我记得有一次，业务部门临时上线了一个促销活动，数据量瞬间暴涨 5 倍。结果呢？Spark 集群自动扩容，一夜之间计算费用从 2000 块飙到 12000 块。没人设置上限，没人做限流。
• 场景二：存储只增不减
  我曾经接手过一个数据湖项目，发现 70% 的 Parquet 文件在过去 90 天里没被读过一次。但团队每个月还在为这些“冷数据”付着热存储的钱。
• 场景三：数据重复搬运
  有个团队，每天从 Kafka 消费数据，写入 HDFS，再用 Spark 读一遍做 ETL，最后又写回 HDFS。同一个数据，在集群里被搬了三次。网络带宽和磁盘 IO 就这么白白浪费了。

1.2 成本构成全景图

咱们把成本拆开来看。我习惯把它分成四大块：计算、存储、网络、人力。你想想看，是不是每一块都有优化的空间？

成本维度	主要来源	典型失控原因	优化空间
计算	Spark、Flink、Hive、K8s Pod	无限制自动扩缩容、低效 SQL、数据倾斜	★★★★★
存储	HDFS、S3、OSS、HBase	冷热数据不分层、冗余副本、小文件过多	★★★★☆
网络	跨 AZ 流量、跨 Region 同步、API 调用	数据搬运次数过多、未使用内网 Endpoint	★★★☆☆
人力	排查问题、维护脚本、沟通协调	自动化程度低、告警噪音大、文档缺失	★★★★☆

1.3 计算成本：为什么总是超支？

计算成本，说白了就是 CPU 和内存的钱。我见过最离谱的一次，一个 Spark 任务跑了 8 小时，结果发现是数据倾斜导致一个 executor 在单打独斗，其他都在空转。

常见的坑有这几个：

• SQL 写得烂——笛卡尔积、不加分区过滤、大量 Shuffle
• 资源配得高——默认给 100 个 executor，实际 20 个就够
• 任务调度乱——高峰期抢资源，低峰期空转

1.4 存储成本：数据越存越多，钱越花越狠

存储成本是温水煮青蛙。一开始觉得没多少钱，等数据量到了 PB 级，才发现每个月存储费比计算费还高。

我建议你关注三个指标：

1. 数据生命周期——有没有自动过期策略？
2. 压缩率——Parquet 的 Snappy 压缩比是多少？有没有用 ZSTD？
3. 小文件数量——HDFS 上有没有大量小于 128MB 的文件？

举个例子，我曾经优化过一个 Hive 表，把存储格式从 TextFile 改成 Parquet，压缩率从 1:1 提升到 1:5。存储成本直接降了 80%。

1.5 网络成本：看不见的隐形杀手

网络成本容易被忽略，因为它不直接体现在计算或存储账单里。但跨 AZ 的流量费，有时候比计算费还贵。

我遇到过最典型的情况：

• 数据从 Kafka 消费后，写入 S3，再被另一个 Region 的 Spark 集群读取。每次跨 Region 读数据，都要付高昂的出站流量费。
• 解决方案很简单：把计算集群搬到数据所在的 Region，或者用 S3 的跨 Region 复制功能。

1.6 人力成本：最容易被低估的隐性支出

人力成本不是工资，而是时间成本。一个数据工程师花 3 小时排查一个慢查询，这 3 小时就是成本。

我见过太多团队，把大量时间花在：

• 手动重跑失败的任务
• 排查数据不一致的问题
• 写重复的 ETL 脚本

这些时间，如果用来做自动化监控、做成本看板、做自助分析平台，长期来看能省下几倍的人力。

1.7 成本全景图：一张图看懂所有

下面这张图，是我自己画的一个成本全景框架。你把它存下来，每次做成本优化的时候拿出来对照一下。

1.8 本章小结：从哪开始？

好了，全景图看完了。你可能会问：这么多维度，我该从哪下手？

我的建议是：先抓大头。打开你的账单，看看计算和存储哪个占比最高。通常来说，计算成本是最大的优化空间，因为它跟你的代码质量、资源配置直接相关。

下一章，咱们就深入聊聊计算成本优化的具体手段。不过在那之前，我建议你先做一件事：拉一张你当前流水线的成本构成表，看看哪一块最需要动刀。