云上百万大数据任务的成本优化实践
如果无法正常显示，请先停止浏览器的去广告插件。
1. 杨少华
2. 目录
3.
4. 需求侧优化 供给侧优化
• 运营手段 • 商务手段：折扣
➢ 梳理下线无效、低效任务
• 技术手段
➢ 业务逻辑优化
➢ 资源优化：RightSizing &
HBO
• 技术手段：弹性资源池
➢ 存算分离
➢ 多类型实例综合使用
◼ 包年/包月实例
◼ 按量/Spot实例
◼ 多云实例
5. 优化
效果
稳定性
实施
成本
✓ 降低任务总时长、基线完成时间 大数据任务异常 ✓ 低侵入性，业务无感
✓ 降低资源使用量（内存/CPU） 大数据服务或主机异常 ✓ 全自动优化
✓ 收益要够大（如 > 30%）
✓ 实施周期短
6. RightSizing & HBO
• 任务参数动态调优
• 稳定性保障
7. 问题
➢ 高峰时段任务繁忙，YARN资源分满状态
典型案例
主机CPU/内存利用率
➢ 高峰时段YARN资源排队严重
➢ 主机CPU/内存利用率不高
解决方法：RightSizing
➢ 任务的实际资源使用与申请量匹配，减少浪费
YARN Vcore/内存分配
➢ 难点：任务数量多，调优门槛高，工作量巨大
解决方法：HBO （History Based
Optimization）
➢ 通过对任务的历史运行数据进行分析，为每个任务计算更优的
运行参数，并在任务提交时自动运用，从而实现任务的资源
RightSizing
YARN Pending容器数量
8. 数据采集
优化手段：任务动态参数调优
➢ HistoryServer数据
➢ 数据质量，基于 javaagent 和 listener 运行时采集，
资源控制，避免过多影响
优化策略
➢ 使用动态历史时间窗口
调度侧
优化 引擎侧
优化
（合理申请资
源） （高效使用资
源）
➢ 自适应优化算法
➢ 预估模型：不同并行度预估运行时长变化 • 资源不足/空闲 -> 调大/调小
➢ 各种边界处理，参数之间的联动依赖 • 并行度、预启动、数据本地性等
• ...
自动优化
➢ 基于javaagent技术的Hook注入机制
9. 技术挑战：覆盖和适配各种场景
Hive on MR/Tez/Spark
➢ 通过字节码注入的方式 开源主流版本
➢ 抽象优化参数注入方式 CDH&TDH等定制版
技术挑战：任务归一化
➢ 可编程方式，方便定制
×
Spark Application
本 Flink
云厂商EMR版本 StarRocks/Doris
➢ 典型归一化信息：job/application name, 命令行信息，SQL ...
➢ 新任务发现和优化
Native MR Job
10. 效果指标：任务运行总时长、CPU/内存使用量
方案与效果
• 参数自动调优：为每个任务自
动设定最佳运行资源参数，无
需改动任务代码
• 任务总时长减少 28%，产出
时间提前2小时
• 任务排队峰值降低 50%，业
务反馈任务卡顿显著好转
11. 第一轮优化：可以看到在开启优化的前后时间段，PendingMB
曲线面积有明显下降
第二轮优化： 不断完善优化策略，PendingMB曲线面积较
优化前降低更为明显，曲线峰值约12M降至1M，整体可减
少40%左右的离线计算资源
12. 灰度机制
异常重试
失败隔离
故障隔离
13. 弹性资源池与混部
14. 弹性资源池 ElasticPool
已有的云资源
多云资源组合
Spot/竞价/抢占式实例
通过不同优先级任务混部实现
价格最低可到：按量机型1/10，包月机型
典范是Google Borg，通过混部，计算型
资源的平均利用率拉升到50%+，节省超过
30%机器
对于计算数据量小，或依赖的数
1/6
据在多家云上都有，可临时根据各
国外像Cast.ai、Kubecost、BreezeML、
家云目前的spot instance等情况，
Skypilot这些公司基本都是这个方向
对基础设施要求很高：不同优先级任务通
常至少要部署在同城机房、带宽>100G、
来构建一个最佳的资源池，可以是
国外云在Spot Instance上的成熟度和供应
上比国内好很多
单云构成的，甚至是跨多云构成的
存算分离、操作系统要具备不同优先级任务
QoS能力
规格名称 规格 系统盘 按量
包月 抢占式
阿里云 ecs.c6.xlarge 4核8G 40G 0.744元/时
356.6元/月 0.26元/小时 187.2元/月
华为云 c6s.xlarge.2 4核8G 40G 0.6988元/时 503.136元/月 346.6元/月 0.29元/小时 208.8元/月
腾讯云 S5.LARGE8 4核8G 50G 0.65元/时 356.2元/月 0.17元/小时 122.4元/月
535.68元/月
468元/月
15. ElasticPool-
问题
➢ 业务和大数据离线作业的错峰，集群利用率不高
➢ 大量的容器OOM 300+w次/周
➢ 1%的夯机率
➢ 每周hung task 28.8%
难点
➢ 资源利用率提升达到瓶颈
➢ 单机的资源隔离能力
解决思路
➢ 稳定性：资源面的边界压力感知，单机资源健康度保障
➢ 利用率：复用已有机器，构建新的大数据集群
16. ElasticPool-
轻量的接入方式
1. 大数据存算分离架构
2. 部署新大数据集群控制器
3. 混部节点部署内核隔离能力
4. 混部节点部署lcc-agent
5. 将任务从老集群迁移到新集群
6. 原集群逐渐释放
17. ElasticPool-
Latency/压力/边界感知
18. ElasticPool-
内存健康度保障
19. 湖仓数据存储治理
• 表数据分析：小文件/数据冷热/压缩格式等
• 数据压缩归档治理
20. 问题：存储效率低，水位高
方案：四步治理流程
现状： 1. 存储水位长期超80% • 表大小、格式、压缩率 → 预估收益
根因： • 基于HDFS审计日志分析冷热数据
• 文本格式未压缩 2.
• 列式存储（ORC/Parquet）使用 •
低效压缩算法（如Snappy）
•
冷数据未治理，占用高成本存储
•
分析评估
压缩优化
文本数据 → ORC/Parquet + Zstd/Zlib压
效果：显著降本与长期稳定
容量优化：存储水位从87%降至
60%+（已维持1年）
性能提升：
查询速度提升（列式存储+高效
压缩）
存储资源成本下降20%+
缩（压缩率提升10倍） 自动化能力：冷热分析+定时任务，
列式数据：低效压缩 → 升级至Zstd/Zlib 减少人工干预
（节省30-50%空间）
3. 优先级策略：冷数据优先，空闲自动治理
4. 安全执行：治理前后数据一致性校验
21. 问题：小文件过多引发性能瓶颈
痛点：
•
初始文件数：6亿+ → NameNode性
方案：合并治理流程
1.
•
能压力巨大
精准分析
扫描小文件分布，按大小/热度分类 → 预
估收益
• 性能影响：任务运行时间慢 2. 无感治理
• 资源浪费：大量小文件占用存储块， • 时段规避：选择业务低峰期自动触发任务
利用率不足 • 资源隔离：限制治理任务资源，避免影响
线上业务
• 热表保护：实时监控，跳过活跃表治理
3. 安全执行：治理前后数据一致性校验
效果：性能与效率双提升
文件量级：6亿 → 8000万（减少
86.7%）
性能提升：
NameNode元数据负载降低80%
任务平均运行时间缩短
自动化能力：定时任务，减少人工干
预
22.
23. 客户案例：优化后节省1/3云账单
1、项目背景：资源申请普遍过大，集群资源利用率较低，云成本高
• 百台集群规模，主要为 Spark SQL 任务，集群资源平均利用率40%左右
• 任务资源申请普遍较大，缺乏有效的管控机制，人工优化成本高
2、解决方案与项目效果
• 参数自动调优：为每个任务
自动设定合理的运行资源参
数，减少资源浪费
• 任务总时长减少 25%，
YARN NM节点减少 48%
• 每月离线计算资源云账单节
省 36%
24. 客户案例：千级规模集群，减缓扩容
• 规模：千级服务器，万级Vcores规模，公有云，Spark任务
• 效果：资源全天用满状态(优化前) -> 有较多富余(优化后)，优化后排队几乎完全消除
25. 客户案例：核心任务提效、OOM治理
• 降低核心队列运行时间，让最重要的任务跑的更快
• 提升任务运行稳定性，降低运维人员的起夜率
26. 优化挑战： 收益要高、确保稳定、实施成本要低
优化方案
• 需求侧优化（Rightsizing/HBO）
• 供给侧优化（ElasticPool）
• 存储治理：存储压缩优化 + 小文件治理
需求侧优化
• 大数据Rightsizing ：基于作业历史优化 + 自动优化机制
供给侧优化
• 已有资源复用：混部
• AutoScaler：spot实例->按量付费->多云调度
27.
28. 云上百万大数据任务的成本优化实践