spark如何处理同一位置的数据背后的广泛理念是：
如果您使用sparksession提供的工具来读取Dataframe（请参阅dataframereader文档），那么将创建一个执行图，它将尝试读取本地节点的数据。i、 e.每个spark执行器将读取驻留在分布式存储的本地执行器部分的数据：例如本地hdfs块。这要求您在数据存储上具有分区信息，并使用此信息创建dataframereader。这是将spark用于大数据的正确方法，因为它允许近乎任意的缩放。
里克·莫里扎在这里写的
有些用例中，数据与spark集群不在同一位置，spark必须找出将数据带给执行者的最佳方法。另一个用例正是您所说的，一个节点没有足够的资源来启动executor。对于所有这些用例，spark将按照以下一些规则处理问题：
数据局部性会对spark作业的性能产生重大影响。如果数据和操作它的代码在一起，那么计算往往很快。但是如果代码和数据是分开的，那么一个必须移到另一个。通常，将序列化代码从一个地方运送到另一个地方比运送一块数据要快，因为代码大小比数据小得多。spark围绕这个数据局部性的一般原则构建其调度。
数据局部性是指数据与处理数据的代码之间的距离。基于数据的当前位置，有几个层次的位置性。从最近到最远的顺序：
process\u local-数据与正在运行的代码位于同一个jvm中。这是可能的最佳地点
node\ u local-数据位于同一节点上。示例可能在同一节点上的hdfs中，或者在同一节点上的另一个executor中。这比process\u local慢一点，因为数据必须在进程之间传输
没有\u pref-数据从任何地方都可以同样快速地访问，并且没有位置首选项
机架\本地-数据位于同一个服务器机架上。数据在同一机架上的不同服务器上，因此需要通过网络发送，通常是通过单个交换机
任何-数据在网络的其他地方，而不是在同一机架中
spark倾向于将所有任务安排在最佳位置级别，但这并不总是可能的。在任何空闲执行器上都没有未处理的数据的情况下，spark将切换到较低的局部性级别。有两种选择：a）等待繁忙的cpu释放出来，在同一台服务器上的数据上启动任务，或b）立即在需要将数据移动到该服务器的较远位置启动新任务。
spark通常做的是等待一点，希望繁忙的cpu释放出来。一旦超时过期，它就开始将数据从很远的地方移动到空闲cpu。各层之间的回退等待超时可以单独配置，也可以在一个参数中一起配置；有关详细信息，请参阅配置页面上的spark.locality参数。如果您的任务很长并且位置不好，您应该增加这些设置，但是默认设置通常效果很好。
最好是本地数据排序的差异：process\u local>node\u local>no\u pref>rack\u local
从这里开始
如果数据与spark应用程序不在同一位置，例如从s3读取数据：
s3的主要问题是使用者不再具有数据局部性，所有读取都需要通过网络传输数据，而s3性能调整本身就是一个黑匣子。
当使用hdfs并获得完美的数据局部性时，可以在某些示例类型上获得~3gb/节点的本地读取吞吐量（例如i2.8xl，每个核心大约90mb/s）。dbio是我们的云i/o优化模块，它为s3提供了优化的连接器，可以在i2.8x1上维持约600mb/s的读取吞吐量（每个核心大约20mb/s）。
也就是说，在每个节点的基础上，hdfs可以产生比s3高6倍的读取吞吐量。因此，考虑到s3比hdfs便宜10倍，我们发现s3在每美元的性能上几乎是hdfs的2倍。
然而，s3的一大好处是我们可以将存储和计算分开，因此，我们可以在更短的时间内启动一个更大的集群，以提高吞吐量，达到允许的物理限制。这种计算和存储的分离还允许不同的spark应用程序（如数据工程etl作业和ad-hoc数据科学模型训练集群）在它们自己的集群上运行，从而防止影响多用户固定大小hadoop集群的并发问题。这种分离（以及对不同工作负载的灵活适应）不仅降低了成本，而且改善了用户体验。
从这里开始