我知道设置为true时的“spark.deploy.spreadout”对hdfs有好处，但是对于s3，设置为false会比true有好处吗？
ctrmrzij1#
这取决于你的工作量。如果您的s3访问量很大，并且受到示例网络io的限制，那么设置spark.deploy.spreadown=true会有所帮助，因为它会将其分布到更多示例上，从而增加应用程序可用的总网络带宽。但对于大多数工作负载来说，这没有什么区别。“spark.deploy.spreadout”参数也有成本考虑。如果你的Spark处理是大规模的，你可能会使用多个AZ。默认值“spark.deploy.spreadout”=true将导致工作进程在数据洗牌时生成更多网络流量，从而导致az间流量。aws上的内部az流量可能会非常昂贵如果网络流量足够大。因此，我们通过spark.deploy.spreadbout“=false对应用程序进行紧密的集群，而不是因为成本问题而进行分散。
ar7v8xwq2#
如果您正在运行hadoop和hdfs，那么使用该属性适用的spark独立调度器对您没有好处。相反，您应该运行yarn，由resourcemanager确定执行器的分布方式如果您在ec2中运行独立调度器，那么设置该属性将有所帮助，默认值为true。换句话说，这里读取数据的位置不是决定因素，主服务器的部署模式是更好的性能优势来自于您试图读取的文件的数量，以及您存储数据的格式
2条答案
按热度按时间ctrmrzij1#
这取决于你的工作量。
如果您的s3访问量很大，并且受到示例网络io的限制，那么设置spark.deploy.spreadown=true会有所帮助，因为它会将其分布到更多示例上，从而增加应用程序可用的总网络带宽。
但对于大多数工作负载来说，这没有什么区别。
“spark.deploy.spreadout”参数也有成本考虑。
如果你的Spark处理是大规模的，你可能会使用多个AZ。默认值“spark.deploy.spreadout”=true将导致工作进程在数据洗牌时生成更多网络流量，从而导致az间流量。
aws上的内部az流量可能会非常昂贵
如果网络流量足够大。因此，我们通过spark.deploy.spreadbout“=false对应用程序进行紧密的集群，而不是因为成本问题而进行分散。
ar7v8xwq2#
如果您正在运行hadoop和hdfs，那么使用该属性适用的spark独立调度器对您没有好处。相反，您应该运行yarn，由resourcemanager确定执行器的分布方式
如果您在ec2中运行独立调度器，那么设置该属性将有所帮助，默认值为true。
换句话说，这里读取数据的位置不是决定因素，主服务器的部署模式是
更好的性能优势来自于您试图读取的文件的数量，以及您存储数据的格式