具有快速压缩的有效 ORC 文件的最小大小应该是多少答案

【问题标题】：What should be the minimum size of a valid ORC file with snappy compression具有快速压缩的有效 ORC 文件的最小大小应该是多少
【发布时间】：2021-09-26 20:25:42
【问题描述】：

我在这里处理的场景是每小时 10k orc 文件在 HDFS 中由 spark 流式处理 应用程序生成，并且在一个小时结束后，一个 spark 合并作业运行并将这些小文件合并到更大的块中，并将其写入配置单元登陆路径以供外部表拾取。有时，损坏的 ORC 文件会导致合并作业失败。工作是找出损坏的 ORC 文件并将其移动到 badrecordspath 中，然后让 spark 合并作业开始。通过 ORC 文件的理论，似乎一个有效的 ORC 文件将在文件末尾有 “ORC”（作为字符串）后跟另一个字节。我如何以优化的方式检查它，以便验证那些 10K orc 文件不会花费太多时间。我曾想过编写 bash shell 脚本，但似乎需要一些时间来验证 HDFS orc 文件。如果我知道有效 ORC 文件的最小大小，我的想法是缩小验证范围，因为我们的大多数损坏文件的大小都非常小（主要是 3 个字节）。所以如果我得到任何建议，那将非常有帮助。

PS：我不能使用 set spark.sql.files.ignoreCorruptFiles=true，因为我必须跟踪文件并将它们移动到不良记录路径。

【问题讨论】：

标签： bash apache-spark hdfs spark-streaming orc

【解决方案1】：

找到了解决办法。我们可以使用 set spark.sql.files.ignoreCorruptFiles=true 然后我们可以使用以下方法跟踪被忽略的文件：

    def trackIgnoreCorruptFiles(df: DataFrame): List[Path] = {

    val listOfFileAfterIgnore = df.withColumn("file_name", input_file_name)
      .select("file_name")
      .distinct()
      .collect()
      .map(x => new Path(x(0).toString))
      .toList

 
    listOfCompleteFiles.diff(listOfFileAfterIgnore)
  }

input_file_name 是一个内置的 spark udf，它返回文件的完整路径，我们将其作为该数据帧 df 中的列获取。此方法返回列表这些文件的路径在被火花忽略后仍然存在。列表差异将为您提供 spark 忽略的文件的实际列表。然后，您可以轻松地将这些文件列表移动到 badRecordsPath 以供将来分析。

【讨论】：