我正在尝试运行简单查询假设使用spark.sql运行查询（＆＃34;查询＆＃34;）与Dataframes相比没有性能差异因为我使用Spark 2.1.0我有Catalyst Optimizer要小心优化部分＆amp;启用Tungsten。
这里我正在加入两个带有左外连接的表。我的第一张桌子是200 GB＆amp;是驾驶表（在左侧），第二个表是2GB，根据我们的业务要求，不得有过滤器。
配置我的群集。 由于这是共享群集，我有一个特定的队列，允许我使用3 TB的内存（是3 tera字节），但是VCORES的数量是480 。这意味着我只能运行480个并行任务。除了AT YARN LEVEL之外，我还有一个约束，即每个节点最多有8个内核。和MAX的16 GB容器内存限制。 因为我不能给我的Executor-Memory（每个节点）超过12 GB，因为我给予3-GB ExecutorMemoryOverhead更安全的一面，每个节点内存利用率为15 GB。
因此，在计算了每个节点限制为8个核心的480个允许的总数后，我的计算得到了480/8 = 60个节点。这就是60 * 15 = 900 GB的可用内存（我不知道为什么总队列内存被分配3 TB）而且这是最高的..如果我是唯一一个使用队列但是那个并非总是如此。
现在怀疑是Spark如何整个900 GB的内存。从数字＆amp;统计数据我可以清楚地说我的工作将没有任何问题，因为我试图处理的数据大小只有210-250 GB MaX＆amp;我有900 GB的可用内存。
但我不断收到容器被杀死错误消息。并且我无法增加YARN容器的大小，因为它处于YARN级别，整个集群将获得增加的容器大小，这不是正确的事情。我也尝试使用sparksession.config（属性）在我的代码中禁用vmem-check.enabled属性为FALSE，但这也没有帮助我可能不允许在YARN级别更改任何内容，因此可能忽略了
现在基于什么基础，火花分裂数据最初是基于在群集级别定义的块大小（假设128 MB）我在想这是因为当我的Job启动时，我看到我的Big Table大约200 GB有2000个任务所以基于什么基础Spark计算这2000个任务（分区）我认为可能是火花开始加载我的表时的默认分区大小是通过查看输入大小/记录和＆amp;＆amp;随机写入大小/记录在Spark UI的舞台选项卡下，这就是为什么我得到容器杀死错误＆amp;建议增加Executor内存开销，这也没有帮助。
我尝试将数据从10k分区重新分区到100k分区并尝试持久保存到MEMORY_ONLY，MEMORY_AND_DISK，DISK_ONLY但没有任何帮助。我的许多任务都失败了，并且在最后工作失败了。有时使用Container kill，Direct Buffer等。
现在这里有什么是持久/缓存的用法以及它的表现如何.. ????我正在做
val result = spark.sql("query big_table").repartition(10000, $<column name>).persist()
Repartition中的列是Joining键，因此它会被分发。要在JOIN之前做这个工作我正在做result.show（1）。因此执行操作并且数据在DISK上持久存在，Spark将读取持续存在于DISK上的数据以进行加入，并且内存上没有负载，因为它存储在磁盘上的小块中（我正确在这里... ??）< / p>
为什么在HIVE中使用相同的Big Table以及一些使用Left Join的其他表格完成相同的工作。虽然它需要时间但成功完成但它在Spark中失败了。??为什么？ Spark不是HIVE的完全替代品吗？?? Spill to Disk＆amp; amp;＆amp ;;使用DISK进行PERSISTING时将数据写入磁盘。
如果我们的容器大小较少但节点数量很多，纱线容器的大小是否起作用？
Spark是否结合了所有可用节点的内存（按容器大小每个节点15 GB）并将它们组合起来加载一个大分区.. ??