如标题所料，我在将spark作业提交到运行在docker上的spark集群时遇到了一些问题。我在scala中编写了一个非常简单的spark作业，订阅了一个kafka服务器，安排了一些数据并将这些数据存储在elastichsearch数据库中。kafka和elasticsearch已经在docker中运行。如果我在我的开发环境(Windows/IntelliJ)中从我的Ide运行spark作业，一切都会完美运行。然后(我根本不是Java专家)，我按照以下说明添加了一个spark集群:https://github.com/big-data-europe/docker-spark在查看其仪表
我正在使用以下配置在YARN上提交spark应用程序conf.set("spark.executor.cores","3")conf.set("spark.executor.memory","14g")conf.set("spark.executor.instances","4")conf.set("spark.driver.cores","5")conf.set("spark.driver.memory","1g")但是，在YARN资源管理器UI上，它显示vCoresused=5，我预计vCores曾经是17((4x3)+5=17)即12执行人和5驱动程序。但它总是显示等于execu
假设我有一些数据都在同一个分区上(我之前在数据帧上执行了.coalesce(1))。我现在想对数据进行分组并对其进行聚合。如果我在数据框上使用.groupBy，这些组会被放置到不同的节点上吗？如果这是真的，我想避免这种情况，因为我想对这些组执行这些计算而不需要过多改组。 最佳答案 首先，coalesce(1)并不能保证你的所有数据都在一个节点中，要确保你必须使用repartition(1)，这将迫使您将所有数据统一在一个节点中。coalesce仅对同一节点中的分区进行分组，因此如果您的数据分布在5个节点中(每个节点中有多个分区)，它
我遇到了一个奇怪的问题，即Spark事件日志的长度没有正确更新。例如，我们将查看文件application_1551818805190_0006_1.inprogress。当我使用hdfsdfs-ls/var/log/spark/apps/时，我看到该文件只有309个字节:[hadoop~]$hdfsdfs-lshdfs:///var/log/spark/apps-rwxrwx---2hadoopspark1381803502019-03-0522:47hdfs:///var/log/spark/apps/application_1551818805190_0004_1-rwxrwx-
我在使用CTE(WITH子句)创建的Hive上有一个View，合并两个表，然后计算以仅显示每个ID的最新记录。在我的环境中，我有一个用于浏览配置单元数据库的工具(DBeaver，非数据湖开发人员必须浏览数据)。查看代码CREATEVIEWIFNOTEXISTSdb.test_cte_viewASwithcteas(select*fromdb.test_cteunionselect*fromdb.test_cte_2),tmpas(SELECTid,idate,ROW_NUMBER()over(PARTITIONBYidORDERBYidatedesc)ASrow_numfromcte)
是否有CLI命令可用于获取此图片中显示的指标，因为它们出现在8088上的HadoopWebUI中？ 最佳答案 yarntop会显示这个。它的工作方式类似于UNIX/Linux命令top。源代码位于https://github.com/apache/hadoop/blob/trunk/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-client/src/main/java/org/apache/hadoop/yarn/client/cli/TopCLI.java:
我使用的spark是2.3。我有这段代码片段，它读取'hdfspath'下的序列文件(这个路径下大约有20个文件，每个文件大约60MB)，SparkSessionspark=...;JavaSparkContextjsc=JavaSparkContext.fromSparkContext(spark.sparkContext());JavaPairRDDtemp=jsc.sequenceFile(hdfspath,BytesWritable.class,BytesWritable.class);temp.take(1);它给了我这个错误，19/04/0314:50:18INFOCode
我正在尝试通过在EMR上执行的spark应用程序读取s3目录中的所有文件。数据以典型格式存储，如“s3a://Some/path/yyyy/mm/dd/hh/blah.gz”如果我使用深度嵌套的通配符(例如“s3a://SomeBucket/SomeFolder/////*.gz”)，性能会很糟糕并且需要大约40分钟阅读几万个gzip压缩的小json文件。它可以工作，但是浪费40分钟来测试一些代码真的很糟糕。我的研究告诉我还有另外两种方法性能更高。使用hadoop.fs库(2.8.5)我尝试读取我提供的每个文件路径。privatedefgetEventDataHadoop(events
我有一个带有Spark的AWSEMR集群。我可以连接到它(spark):通过SSH连接到主节点后从主节点来自另一个AWSEMR集群但无法连接到它:从我的本地机器(macOSMojave)来自非emr机器，如Metabase和Redash我已阅读thisquestion的答案.我已经检查过所有节点上的文件夹权限和磁盘空间都没有问题。我的假设是我面临着类似的问题JamesWierzba在评论中提问。但是，我没有足够的声誉在那里添加评论。此外，考虑到它特定于AWSEMR，这可能是一个不同的问题。SSH连接到主节点后连接工作正常。#SSHedtomasternode$ssh-i~/identi
我们将spark与java结合使用，并创建了JavaRESTapi来调用我们的spark代码。在调用RESTurl时，我的java方法将创建SparkSession和Context以继续计算。这对于单个请求工作正常，但同时对于多个请求，我们收到与SparkContexts相关的问题:同一驱动程序JVM中的多个SparkContexts还尝试使用:conf.set("spark.driver.allowMultipleContexts","true");请建议如何管理同步spark请求的Spark上下文。或者任何其他处理这种情况的方法？ 最佳答案
