Spark on Kubernetes环境下数据本地性与存储选型相关问题

1. 运行Spark on Kubernetes是否需要使用HDFS或S3存储？ #

不需要。Spark on Kubernetes本身没有强制绑定HDFS、S3作为底层存储，二者只是官方适配成熟度较高的常用存储选项。你可以根据业务场景自由选择NFS、K8s原生PVC、计算节点本地磁盘、其他兼容S3协议的对象存储等多种存储介质，只要所有Spark Driver和Executor节点能正常访问目标存储路径即可。 #

2. 若仅采用NFS存储类型，数据本地性的效率能否保持较高水平？ #

绝大多数场景下无法保持较高水平。
Spark数据本地性的核心逻辑是优先将计算任务调度到离数据物理存储最近的节点执行，最大程度降低跨节点数据传输的带宽和延迟开销：

• NFS属于网络共享存储，所有数据读写都需要走网络请求，不存在「数据固定存在某一个计算节点本地」的属性，Spark的PROCESS_LOCAL、NODE_LOCAL级别的本地性调度完全无法生效，默认只能落到RACK_LOCAL甚至最差的ANY调度级别
• 仅两种极端场景下NFS对效率的影响可以忽略：一是你的任务属于计算量远大于数据读取量的计算密集型任务，网络传输开销在整体任务耗时中占比极低；二是NFS部署的集群网络带宽远高于任务的峰值数据读取需求，且存储本身IO延迟极低
  如果必须使用NFS，可以适当调大spark.locality.wait参数，给调度器预留更多时间尝试匹配更优的调度节点，不过该优化的实际收益通常比较有限。

3. 对Spark on Kubernetes的理解是否存在根本性偏差？ #

从你提出的前两个问题来看，不存在根本性偏差。这两个都是Spark on Kubernetes落地过程中非常典型的存储选型相关问题，刚好对应Spark核心调度特性和Kubernetes存储生态的结合痛点，属于技术调研阶段会遇到的共性疑问。 #

内容的提问来源于stack exchange，提问作者arminrock