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

【问题标题】：pyspark spark 2.4 on EMR 5.27 - cluster stop processing after listing filesEMR 5.27 上的 pyspark spark 2.4 - 列出文件后集群停止处理
【发布时间】：2020-02-12 04:30:45
【问题描述】：

给定一个应用程序将 csv 转换为 parquet（从和到 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)

我在使用 spark EMR 时遇到了困难。

在本地使用 spark 提交，运行没有困难（140MB 数据）并且速度非常快。但在 EMR 上，情况就另当别论了。

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

我浏览了 EMR 提供的 spark 作业 UI，我注意到一旦完成此任务：

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

Spark 杀死所有执行者：

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 工作正常，但是一旦完成，我看到执行程序被删除并且集群处于空闲状态，该步骤没有完成。

所以我的问题还是一样。

【问题讨论】：

您尝试写入的确切 s3 路径是什么？
path = "s3a://{0}/{1}/{2}".format(S3_DESTINATION_RAW_BUCKET, S3_PROCESSED_ADWORDS_PATH, adwords_table)
stackoverflow.com/questions/39513505/…
您是否尝试过单独运行它们而不是循环运行

标签： apache-spark hadoop amazon-emr

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

令人惊讶的是，它不会显示在 UI 上，并且给人一种空闲的印象。

无论我做什么（重新分区（1）、更大的集群等），写作都需要几个小时。

这里的主要问题是 saveAsTable，我不知道它在做什么需要这么长时间或写这么慢。

因此，我在集群上本地查找 write.parquet("hdfs:///tmp_loc")，然后处理以使用从 hdfs 到 s3 文件夹的 aws s3-dist-cp。

性能非常出色，我从 saveAsTable（写入 17k 行/120MB 需要 3 到 5 个小时）缩短到 3 分钟。

由于数据/架构可能在某些时候发生变化，我只是从 sql 请求中执行胶水保存。

【讨论】：