我已经运行了两次相同的应用程序，一次使用社区版（只有6GB内存，我们西部），一次使用一个驱动程序和一个工作程序（60 GB内存，eu-central），在社区版本中的应用程序运行得更快读取和写入数据到S3。
我没有找到任何解释这个糟糕的结果，因为我们的集群比社区版更强大，我甚至尝试了一个驱动程序，一个工人（最多60个），它将比社区版需要更多。我们在我们的应用程序中使用S3作为数据源，我们读取了900万行.csv文件，对其进行了一些分析并再次在S3上写入结果，因为我们已经将桶安装到bdfs。
df=sqlContext.read.format('com.databricks.spark.csv').options(delimiter=',',header='true',inferschema='true').load("dbfs:/mnt/mount1/2016/rrdb_succesful_sales/*")
我用来写s3的代码：
top_profit_product.coalesce(1).write.csv("dbfs:/mnt/mount2/tappalytics/profitability_report/weekly/top_profit_product",mode='overwrite',header=True)
我不认为我的代码会有任何问题，是吗？有什么建议吗？
答案 0 :(得分：1)
这是databricks文件系统，而不是OSS Apache S3客户端或Amazon EMR驱动程序，因此您必须使用它们。
对于ASF代码，s3a客户端延迟来自：HTTP请求数;带宽到s3，在HDD上寻找时间。 HTTPS请求设置/拆解费用昂贵;虽然您必须为您的数据源选择正确的选项，但最新的s3a客户搜索的次数要少得多。
如果您在与VM不同的站点上使用s3存储桶，那将是您的瓶颈。您将受带宽限制，按MB计费，最好跳过500K数据，而不是通过中止活动HTTP GET并设置新TCP流来寻找新位置。
提示：s3a：//landsat-pds/scene_list.gz提供了一个很好的20MB测试源;在美国东部托管，AWS为您的下载付费。 Spark 2还添加了自己的CSV阅读器。