使用Spark多集群改进SQL查询

Question

我在试验是否使用多个集群的星火可以改善缓慢的SQL查询。我为师父创造了两个工人，他们是在当地的星火上独立运行的。是的，我把内存和核心数量减半，以便在本地机器上创建工作人员。我为sqlContext指定了分区，使用了partitionColumn、lowerBound、UpperBound和numberPartitions，这样任务(或分区)就可以分布在工人上了。我将它们描述如下(partitionColumn是唯一的)：

df = sqlContext.read.format("jdbc").options(
    url = "jdbc:sqlserver://localhost;databasename=AdventureWorks2014;integratedSecurity=true;", 
    driver = "com.microsoft.sqlserver.jdbc.SQLServerDriver",  
    dbtable = query,
    partitionColumn = "RowId",
    lowerBound = 1,
    upperBound = 10000000,
    numPartitions = 4).load()

在指定选项之后，我在主程序上运行了脚本，但是在没有集群的星星之火上运行时，我无法获得任何性能改进。我知道我不应该为了实验的完整性而把记忆减半。但我想知道，如果不是这样的话，情况是否可能是这样，或者有什么原因。任何想法都欢迎。非常感谢。

Answer 1

这里有多个因素发挥作用，尽管每个因素的权重可能因情况而异。

• 正如nicely pointed out by mtoto所说，增加一台机器上的工人数量，不太可能带来任何性能上的提高。 一台机器上的多个工作人员可以访问相同的固定资源池。因为worker不参与处理本身，所以您只需要使用这个池的更高一部分来进行管理。 当我们选择更多的执行器JVM时，会出现合法的情况，但这与增加工作人员(前者是应用程序资源，后者是集群资源)不一样。
• 目前还不清楚是否使用相同数量的核心用于基线和多工作人员配置，但是核心并不是您必须考虑使用Spark的唯一资源。典型的星火作业是IO (大部分是网络和磁盘)绑定的。增加单个节点上的线程数量，而不确保有足够的磁盘和网络配置，只会使它们等待数据。 单独增加核心只对CPU受限的作业有用(这些作业通常在一台机器上扩展得更好)。
• 如果外部资源跟不上请求，摆弄星火资源不会对你有帮助。从一个没有复制的数据库中读取大量并发批处理只会扼杀服务器。 在这种情况下，如果在与Spark相同的节点上运行数据库服务器，情况就更糟了。它有一些优点(所有流量都可以通过回送)，但是除非数据库和Spark使用不同的磁盘集，否则它们将竞争磁盘IO (以及其他资源)。

Note

还不清楚什么是query，但是如果它在直接针对数据库执行时很慢，那么从Spark获取它会更慢。您可能应该首先更仔细地查看查询和/或数据库结构和配置。