RDD、DataFrame、Dataset 怎么选

先说结论

• 大多数生产任务优先考虑 DataFrame
• 需要更强类型表达且主要用 Scala 时，可以考虑 Dataset
• 只有在非常底层、很自由的算子控制场景下，才更值得回到 RDD

一、三者最大的差别是什么

1. RDD

RDD 是最底层的数据抽象。
它的特点是：

• 转换灵活
• 算子原始
• 开发自由度高

但代价是：

• 优化器帮得少
• 写起来更偏底层
• 很多 SQL / 列式优化吃不到

2. DataFrame

DataFrame 更像“带 schema 的表结构数据”。

它最大的优势在于：

• 更贴近 SQL
• Catalyst 优化器能参与优化
• Tungsten 执行优化更容易发挥

所以它通常是最通用、最稳的生产选择。

3. Dataset

Dataset 可以理解成“带类型语义的 DataFrame”，主要在 Scala 生态里更有价值。

它的优点是：

• 类型更强
• 业务对象表达更自然

但实际项目里，如果团队主要写 PySpark 或 SQL，Dataset 的存在感就没那么强。

二、为什么很多场景都推荐 DataFrame

因为大部分生产任务真正看重的是：

• 执行计划可优化
• SQL 语义清晰
• 与 Spark SQL、Hive、Catalog 生态兼容

而这些恰好都是 DataFrame 的强项。

换句话说：
如果不是有非常明确的理由，大多数任务不需要先从 RDD 开始。

三、什么时候还会回到 RDD

更常见于：

• 需要非常底层的算子控制
• 处理一些结构不稳定或特别原始的数据
• 做教学、原理验证或特殊算法逻辑

但要注意，一旦回到 RDD，就意味着你放弃了一部分 Spark SQL 优化能力。

四、最容易踩的坑

1. 以为越底层越强

RDD 更底层不代表更适合生产。很多场景下，底层只是意味着你自己要管更多细节。

2. 小任务也强上 Dataset

如果团队主要不是 Scala，Dataset 往往会让协作成本更高。

3. 把选择问题只看成“API 喜好”

真正要看的是：

• 是否需要优化器
• 是否依赖类型表达
• 团队主要语言和生态是什么

总结

RDD、DataFrame、Dataset 的选择，本质上不是“谁更先进”，而是“你更需要底层控制、执行优化，还是类型语义”。大多数生产任务优先 DataFrame，Scala 强类型场景再考虑 Dataset，底层特殊处理再回到 RDD，会更稳。