面试官问'你们怎么做成本控制'——大数据不是烧钱比赛
先说结论
大数据的成本主要分三类：计算成本、存储成本、运维成本。计算成本占大头（集群/实例费用），存储成本次之（S3/HDFS空间），运维成本最隐蔽但也很高（人力维护集群的时间）。面试时按这三类讲你做了什么优化，条理清晰。
最有效的降本手段不是'砍功能'而是'提效率'：同样的作业跑更快就用更少的资源，不需要的数据及时清理就节省存储，用托管服务替代自建就节省运维人力。降本≠降质。
成本意识要贯穿开发全流程：不是等到成本高了才去优化，而是在写SQL时就考虑——这个SELECT *有必要吗？这个JOIN能不能改成Broadcast？这份历史数据还需要保留吗？
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
成本控制是近两年面试的新热点。以前公司不差钱，数据团队随便开集群。现在不一样了——每家公司都在降本增效，面试官也开始关注你有没有成本意识。很多人被问到成本控制就蒙了，因为平时只管写SQL不管花多少钱。但其实，成本控制能力是区分'高级数据开发'和'普通数据开发'的重要标志。你不仅要能做出来，还要能做得省钱。我在某知名出海硬件品牌通过一系列优化实现了存储成本降低35%，今天把成本控制的思路系统地讲一遍。
大数据成本的三个大头
| 成本类型 | 典型占比 | 主要构成 | 优化方向 |
|---|---|---|---|
| 计算成本 | 50-60% | 云服务器实例、Spark/Flink集群、按需计算费用 | 优化SQL减少资源消耗、合理配置集群规模、用竞价实例 |
| 存储成本 | 20-30% | S3/HDFS存储空间、数据备份、日志存储 | 数据分层存储、定期归档冷数据、清理无用数据 |
| 运维成本 | 10-20% | 人力运维集群、故障处理、版本升级 | 用托管服务、自动化运维、减少故障率 |
计算成本优化：我怎么做的
计算成本是大头，优化空间也最大。我在某出海硬件品牌做了三件事：
第一：SQL优化减少资源消耗。前面讲过的SELECT *改列裁剪、调大Broadcast阈值避免Shuffle，这些不仅提升了性能，也直接减少了计算资源的使用。ETL执行时间减少40%意味着集群的工作时间减少了40%——如果用的是按需付费的模式，这就是实打实的省钱。
// 计算成本优化的三个抓手
// ① SQL优化 → 减少计算量
// SELECT * 改列裁剪 → Shuffle数据量减少45%
// 调大Broadcast阈值 → 多个JOIN避免了Shuffle
// ETL执行时间整体减少40%
// ② 集群规模优化 → 减少闲置
// 分析作业的执行时间分布，发现：
// 凌晨2-4点：满负荷（ETL执行窗口）
// 白天10-18点：50%负荷（临时查询+开发测试）
// 晚上20-02点：10%负荷（几乎空闲）
// 方案：开启auto-scaling，低峰期自动缩容
// ③ 竞价实例 → 降低单价
// ETL用竞价实例（Spot Instance），价格约为按需的30-40%
// 关键配置：设置fallback到按需实例，防止竞价中断影响SLA第二：集群auto-scaling。原来的集群是固定8台机器24小时运行，但实际上凌晨ETL时间只需要2小时满负荷。我配置了auto-scaling策略，低峰期自动缩到3台，高峰期扩到10台。按月算下来节省了约30%的集群费用。
第三：竞价实例（Spot Instance）。ETL作业对延迟容忍度较高——晚几分钟跑完问题不大。利用这一点，我把ETL的Worker节点改成了竞价实例，价格只有按需实例的30-40%。同时设置了fallback——如果竞价实例被回收，自动切换到按需实例，保证SLA不受影响。
存储成本优化：冷热分层+数据清理
存储成本的优化核心是'该留的留，该删的删，该降级的降级'：
-- 存储成本优化方案
-- ① 冷热数据分层
-- 热数据（最近90天）：保留在高性能存储（S3 Standard）
-- 冷数据（90天以上）：迁移到低价存储（S3 Glacier）
-- 效果：冷数据存储成本降低约60%
-- 自动归档脚本（每月执行一次）
-- aws s3 mv s3://hot-bucket/dt=2023-01-*
-- s3://cold-bucket/dt=2023-01-*
-- --storage-class GLACIER
-- ② 清理无用数据
-- 定期扫描所有表，找出无下游依赖的表
SELECT table_name, last_access_time
FROM information_schema.tables
WHERE last_access_time < DATE_SUB(CURRENT_DATE, 90)
ORDER BY total_size DESC;
-- 超过90天没被查询的表，确认后归档或删除
-- ③ 优化存储格式
-- 从CSV/JSON改成Parquet/Delta Lake
-- 压缩率提升3-5倍我在某出海硬件品牌做了一次存储清理，发现有30%的存储空间被已经废弃的历史表占用。清理后加上冷热分层，存储成本降低了35%。
运维成本优化：从自建到托管
运维成本最容易被忽视。我在某出海硬件品牌经历过从自建EMR到托管Databricks的转变，运维成本的变化是最直观的：
| 运维项 | 自建EMR | 托管Databricks | 节省 |
|---|---|---|---|
| 集群维护 | 每周花半天处理集群问题 | 全托管，基本不需要维护 | ~2人天/月 |
| 版本升级 | 每次升级要提前测试+灰度，约2天 | 平台自动升级，透明 | ~4人天/季度 |
| 故障处理 | 月均2次集群故障，每次2-4小时 | 月均0次（用了1年多没遇到集群故障） | ~8人时/月 |
| 监控搭建 | 自己搭Prometheus+Grafana | 自带监控和告警 | 初始搭建3天+持续维护 |
算下来，虽然Databricks的软件费用比自建EMR高约20%，但省下来的运维人力远超这个差价。对于小团队来说，用托管服务几乎总是更划算的。面试时讲这个成本对比分析，展示你的商业思维。
面试高频追问
追问一：你怎么说服老板投钱做降本项目？
这考的是你的商业沟通能力。'我用了一个简单的ROI计算：列出当前每月的总成本（计算+存储+人力），然后列出优化后的预期成本，计算每月节省多少。再算优化需要的投入（人力×天数）。拿出海硬件品牌的例子，迁移Databricks投入2人×8周的人力，每月节省约35%的综合成本，4个月回本。老板看到这个ROI数字，当天就批了。重点是：用老板能理解的语言——不讲技术细节，只讲花多少钱、省多少钱、多久回本。'
追问二：降本和性能之间怎么平衡？
'不是所有降本都会牺牲性能，很多降本措施同时提升了性能。比如SQL优化减少Shuffle，既省资源又跑得快。但确实有些场景需要取舍——比如用竞价实例可能偶尔被中断，需要重跑。我的原则是：核心SLA作业不牺牲性能，非核心作业可以接受轻微的性能降级来换取更低的成本。具体来说，核心ETL链路用按需实例保障SLA，开发测试环境和非核心分析用竞价实例。'
追问三：你们有没有做过成本分摊或成本可见化？
'我们做了简单的成本可见化。按业务线拆分计算和存储成本——设备分析占多少、用户分析占多少、广告分析占多少。每个月出一份成本报告给各业务方的负责人。做这个的好处是：当某个业务方需要加新的大数据需求时，他们能看到成本，做出更理性的判断。不是'免费的数据'想加就加，而是知道每个需求背后有计算和存储成本。这个做法推动了几次不必要需求的砍掉，也帮我们优先级排序提供了依据。'
实战踩坑
我踩过一个降本'过度优化'的坑。在清理无用表的时候，我按'90天没有查询记录'的标准筛选出了一批表，经过简单确认后就归档了。
结果第二个月做年度回顾分析时，分析师需要用到去年同期的数据——那些表就在被我归档的列表里。从S3 Glacier恢复数据需要3-5个小时，而且恢复请求本身也要收费。业务方等不及，只能先用其他数据源做近似分析。
// 过度清理的教训
// 错误：用'最近90天无查询'作为唯一归档标准
// 遗漏了：有些表只在年度/季度分析时使用
// 改进后的归档策略：
// 1. 90天无查询 → 先标记为'待归档'
// 2. 发通知给相关的数据分析师确认
// 3. 确认后先软归档（移到低频存储但仍可查询）
// 4. 180天后如果仍然没有查询，再硬归档到Glacier
// 另外增加了一条规则：
// 年度/季度汇总表永不自动归档，需要手动审批教训：降本不能一刀切。清理数据前要充分确认使用模式——有些数据虽然不是每天用，但在特定时间（年度分析、审计）是关键的。归档策略要有'软归档'过渡期，给使用方留出反应时间。
总结
大数据成本控制从三个维度着手：计算成本（SQL优化+auto-scaling+竞价实例）、存储成本（冷热分层+清理无用数据+优化格式）、运维成本（托管服务替代自建）。面试时要准备好具体数字——优化前后的成本对比、节省了多少百分比。最关键的是展示你的'商业思维'——知道每个技术决策背后的成本影响，能用ROI语言和老板沟通。这是高级数据开发区别于普通开发的核心能力之一。
下一篇聊一个3年以上经验必考的话题：面试官问'你怎么带新人/做代码Review'——怎么展示你的团队影响力？
你们团队的大数据每月花多少钱？做过什么降本措施？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长