用DataFrame还是用RDD？为什么现在几乎没人用RDD了？
先说结论
99%的场景用DataFrame/Spark SQL，因为Catalyst优化器 + Tungsten执行引擎让它比手写RDD快很多。只有极少数场景才需要RDD。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
这道题看起来简单，但很多人答得很浅，只说“DataFrame有优化”就停了。面试官想听的是你能说清楚“优化在哪里”和“什么场景仍然需要RDD”。
DataFrame快在哪里？
① Catalyst优化器： 自动优化执行计划。包括谓词下推（把WHERE条件推到数据源层面）、列裁剪（只读取需要的列）、常量折叠、Join重排序等。你写的SQL再烂，Catalyst都能帮你优化。
② Tungsten执行引擎： 用自定义的二进制内存格式代替Java对象，避免了Java对象的内存开销和GC压力。并且生成专门的字节码执行（Whole-Stage Code Generation），比通用的迭代器快很多。
③ 数据源优化： 读Parquet/ORC时可以利用列式存储的特性做列裁剪和谓词下推，大幅减少IO。RDD做不到这一点。
一个直观的性能对比
// 同样的逻辑：按国家统计订单金额
// RDD写法（手动优化，慢）
rdd.map(order => (order.country, order.amount))
.reduceByKey(_ + _) // 比groupByKey快，但你得自己知道用reduceByKey
// DataFrame写法（自动优化，快）
df.groupBy("country").agg(sum("amount"))
// Catalyst自动做了：列裁剪、谓词下推、局部聚合、代码生成我在出海硬件公司迁移到Databricks时，把一批老的RDD代码改写成DataFrame，同样的逻辑执行时间平均减少50%。原因就是Catalyst + Tungsten的优化。
什么场景仍然需要RDD？
很少，但有：
• 需要精确控制分区逻辑（自定义Partitioner）
• 非结构化数据处理（图计算、自定义二进制格式）
• 第三方库只支持RDD API
我做了9年，生产环境用RDD的场景可能不超过5次。
总结
| 维度 | DataFrame / Spark SQL | RDD |
|---|---|---|
| 优化器 | Catalyst自动优化 | 无，全靠手动 |
| 执行引擎 | Tungsten二进制+代码生成 | Java对象，GC压力大 |
| 数据源优化 | 列裁剪/谓词下推 | 无 |
| 易用性 | SQL语法，门槛低 | 函数式编程，门槛高 |
| 生产推荐 | 默认选择 | 极少数场景 |
记住一句话：99%用DataFrame，只有非结构化数据或需要精确控制分区时才考虑RDD。面试时能说清楚Catalyst + Tungsten的具体优化点，就很有深度。
下一篇聊一个运维场景：Spark作业提交后迟迟不开始跑，YARN资源分配怎么排查？
你们项目里还有用RDD的场景吗？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长