我被提供了JSON文本文件中的大型数据集，每行一个JSON对象。 我需要解析/转换的字段之一是纪元时间戳(到可读日期)。
因此，处理数据的第一步是加载并解析它。 如果我执行 rdd.map 操作，我可以：
- 在地图中创建一个简单的日期格式对象(将针对每条记录发生)。 创建
- 一个简单的日期格式对象并广播它，只创建一次。
我不太明白其中哪一个更适合这种大小的对象(我通常使用广播来计算驱动程序上计算的相当大的集合)。
谁能帮助我了解哪个选项更好，为什么？
您的问题似乎表明您想使用该数据集(您想知道它是否适合广播)将其与其他数据集连接起来。
如果是这样，我想你可能想阅读我的 Mastering Apache Spark 2 gitbook 关于广播连接(又名映射端连接)：
Spark SQL 使用广播联接(又名广播哈希联接)而不是散列联接来优化单端数据大小低于
spark.sql.autoBroadcastJoinThreshold时的联接查询。
因此，可以使用默认10M属性微调广播联接spark.sql.autoBroadcastJoinThreshold。
引用广播变量：
广播变量允许程序员在每台计算机上缓存只读变量，而不是随任务一起传送该变量的副本。例如，它们可用于以有效的方式为每个节点提供大型输入数据集的副本。Spark还尝试使用高效的广播算法来分发广播变量，以降低通信成本。
这并没有说明您的数据集应该有多大才能进行有效的广播。它确实取决于 Spark 应用程序的内存量。如果您有一个具有大量 RAM 的强大集群，则任何大小都可以使用。这是网络带宽和可用 RAM 之间的权衡。
我的建议是计算 Spark 应用程序所需的内存，并查看广播变量(每个执行程序)还剩下多少内存。然后，我会计算广播数据集的大小，看看它是否合适。如果是这样，我会给广播一个机会并监控性能。如果效果很好，我会去直播。
与Jacek Laskowski提供的答案相反(强调我的)：
如果您有一个具有大量 RAM 的强大集群，则任何大小都可以使用。这是网络带宽和可用 RAM 之间的权衡。
它比可用 RAM 量复杂得多。对于 N 个工作线程，广播数据集必须通过网络传输两次 N + 1 次：
- 一次收集到驱动程序的数据(在广播联接中透明地完成)。
- 从司机到工人的N次。
如果广播数据集大于其他数据集的 50%，则网络流量将大于随机播放两个数据集。
实际上，驱动程序网络造成的瓶颈和一些次要成本(最明显的是序列化和GC)使广播无用的速度要快得多。