使用 snappy 压缩的有效 ORC 文件的最小大小应该是多少

Question

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

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

Answer 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，其中 returns 文件的完整路径，我们将其作为该数据框 df.This 方法 returns 中的一列获取这些文件的路径列表在被 spark 忽略后仍然存在。列表差异将为您提供被 spark 忽略的实际文件列表。然后您可以轻松地将这些文件列表移动到 badRecordsPath 以供将来分析。

使用 snappy 压缩的有效 ORC 文件的最小大小应该是多少

What should be the minimum size of a valid ORC file with snappy compression

bash

hdfs

apache-spark

spark-streaming

orc