EMR 5.27上的pyspark spark 2.4-列出文件后集群停止处理

时间:2019-10-15 13:11:42

标签: apache-spark hadoop amazon-emr

给出一个几乎不做任何转换即可将csv转换为木地板(从and到S3)的应用程序:

for table in tables:
    df_table = spark.read.format('csv') \
            .option("header", "true") \
            .option("escape", "\"") \
            .load(path)

    df_one_seven_thirty_days = df_table \
            .filter(
                (df_table['date'] == fn.to_date(fn.lit(one_day))) \
                    | (df_table['date'] == fn.to_date(fn.lit(seven_days))) \
                    | (df_table['date'] == fn.to_date(fn.lit(thirty_days)))
            )

    for i in df_one_seven_thirty_days.schema.names:
        df_one_seven_thirty_days = df_one_seven_thirty_days.withColumnRenamed(i, colrename(i).lower())
    df_one_seven_thirty_days.createOrReplaceTempView(table)

   df_sql = spark.sql("SELECT * FROM "+table)
   df_sql.write \
        .mode("overwrite").format('parquet') \
        .partitionBy("customer_id", "date") \
        .option("path", path) \
        .saveAsTable(adwords_table)

我在使用火花EMR时遇到困难。

在具有spark提交的本地系统上,这运行起来没有困难(140MB数据),并且运行速度非常快。 但是在EMR上,这是另一个故事。

第一个“ adwords_table”将被毫无问题地转换,但是第二个保持空闲状态。

我已经遍历了EMR提供的spark作业UI,我注意到完成此任务后:

  

列出187个路径的叶文件和目录:

Spark杀死了所有执行者: enter image description here

20分钟后,再也没有发生任何事情。所有任务都在“已完成”上,并且没有新任务开始。 我正在等待saveAsTable启动。

我的本​​地计算机是8核15GB,群集由10个节点组成r3.4xlarge:  32 vCore,122 GiB内存,320 SSD GB存储EBS存储:200 GiB

配置使用maximizeResourceAllocation true,我只将--num-executors / --executor-cores更改为5

有人知道为什么集群进入“空闲”状态而不完成任务吗? (它最终会在3小时后崩溃且没有错误)

编辑: 通过删除所有胶目录连接+降级hadoop的使用,我取得了一些进展:hadoop-aws:2.7.3

现在saveAsTable可以正常工作,但是一旦完成,我将看到执行程序被删除并且集群处于空闲状态,该步骤将无法完成。

所以我的问题还是一样。

2 个答案:

答案 0 :(得分:0)

经过多次尝试和头痛之后,我发现群集仍在运行/正在处理。 它实际上是在尝试写入数据,但只能从主节点进行。

令人惊讶的是,它不会在用户界面上显示,给人的感觉是空闲。

无论我做什么(repartition(1),更大的集群等),写作都需要花费几个小时。

这里的主要问题是saveAsTable,我不知道它正在做什么,这花费了很长时间或使编写变得如此缓慢。

因此,我在群集上本地访问了write.parquet(“ hdfs:/// tmp_loc”),然后进行了处理以使用aws s3-dist-cp从hdfs到s3文件夹。

性能非常出色,我从saveAsTable(花费3到5个小时来写入17,000行/ 120MB)到3min。

由于数据/架构有时可能会发生变化,所以我只是从sql请求中执行粘合保存。

答案 1 :(得分:0)

我也面临着同样的问题,该问题与EMR 5.27的新版本有关吗? 对我来说,一个执行者的工作也被卡住了很长时间。它完成了所有99%的执行者,这是在读取文件时发生的。