1. 大数据计算优化概述

大数据计算优化，说白了就是让数据跑得更快、花得更少、系统更稳。我做了这么多年架构，见过太多团队一上来就堆机器，结果成本翻倍、性能却没提上去。其实优化的核心就三个字：找瓶颈。

1.1 大数据计算面临的挑战

先聊聊我们每天都会碰到的几个坑。你想想看，数据量从 TB 级涨到 PB 级，计算引擎从 MapReduce 换到 Spark、Flink，但问题还是那些老问题。

• 数据倾斜：这是最常见的性能杀手。我记得有一次做用户画像，某个 key 的数据量是其他 key 的 100 倍，结果一个 task 跑了 3 小时，其他 task 几分钟就结束了。整个作业就卡在那一个点上。
• Shuffle 瓶颈：数据在节点间传输，网络 IO 和磁盘 IO 经常成为短板。我见过一个 200 节点的集群，Shuffle 阶段网络带宽被打满，CPU 利用率却不到 20%。
• 资源争抢：多租户环境下，不同作业抢 CPU、内存、磁盘。我曾经遇到一个离线批处理作业把 YARN 队列占满，导致实时流作业延迟飙升。
• 小文件问题：HDFS 上存了上千万个小文件，NameNode 内存吃紧，任务调度也变慢。嗯，这个问题在数据湖场景里特别突出。
• GC 与内存管理：JVM 的 Full GC 在 Spark/Flink 作业里能让你怀疑人生。我调过最夸张的一个案例，GC 时间占了总运行时间的 40%。

1.2 优化目标：性能、成本、稳定性

优化不是盲目调参。我个人习惯把目标拆成三个维度，每个维度都有明确的衡量标准。

维度	核心指标	典型问题	优化方向
性能	作业执行时间、吞吐量、延迟	数据倾斜、Shuffle 慢、序列化开销大	并行度调优、数据分区、算子优化
成本	CPU/内存/磁盘/网络资源消耗	资源浪费、小文件多、存储冗余	资源弹性伸缩、数据压缩、存储格式选择
稳定性	作业成功率、故障恢复时间、GC 频率	OOM、节点故障、任务重试	容错机制、资源隔离、监控告警

这三个目标经常互相制约。比如你为了追求极致性能，把并行度调得特别高，结果资源开销暴增，成本上去了。或者你为了省钱，把内存压得很低，结果频繁 OOM，稳定性又崩了。我建议的做法是：先定一个核心目标，比如「作业必须在 30 分钟内完成」，然后在这个约束下最小化成本。

1.3 优化方法论总览

优化不是拍脑袋。我总结了一套方法论，分成四个阶段。下面这张图可以帮你快速建立全局认知。

这个方法论是闭环的。你从诊断开始，找到瓶颈后深入分析，然后实施优化，最后把经验固化下来。固化之后，新的问题出现，再走一遍循环。我带的团队一直用这套流程，效果很稳定。

1.3.1 诊断阶段

先别急着调参数。我习惯先看监控大盘：CPU 利用率、内存使用、磁盘 IO、网络流量、任务执行时间分布。重点关注那些「异常值」——比如某个 task 执行时间是平均值的 10 倍，或者某个节点的 GC 时间特别长。

1.3.2 分析阶段

找到异常后，深入分析根因。比如数据倾斜，我会看每个 partition 的数据量分布。如果是 Shuffle 慢，我会看网络传输量和序列化开销。这个阶段需要用到 Spark UI、Flink Dashboard、Grafana 这些工具。

1.3.3 优化阶段

根据分析结果，选择具体的优化手段。比如数据倾斜可以用加盐、两阶段聚合、调整分区键。Shuffle 慢可以调大缓冲区、用更高效的序列化方式（比如 Kryo）。内存问题可以调整 spark.memory.fraction 和 spark.memory.storageFraction。

1.3.4 固化阶段

优化完不是结束。我会把参数配置、代码模板、调优脚本都沉淀下来，做成标准化的优化包。这样下次遇到类似问题，直接套用就行。嗯，这一步很多人会忽略，但恰恰是长期提效的关键。