如何处理不断增长的 _metadata 文件大小并避免 Amazon Redshift Spectrum Parquet Append 中的损坏

Question

背景： 我们的 Web 应用程序生成大量日志文件，这些文件到达 S3 存储桶中。 存储桶中的文件包含 JSON 字符串，文件格式为 .txt。我们每个循环以 200 个文件为一组处理这些文件，这涉及多个步骤，包括读取、提取数据、保存到 Amazon Redshift，以及将初始 DataFrame 以 Parquet 格式保存在另一个 S3 存储桶“spectrum_Data/api_logs/”中。

步骤：

1. 在 Python Pandas 中从 S3 存储桶读取 200 个文件。

2. 从初始 DataFrame 中提取所需数据并将其保存到 Amazon Redshift 表中。

3. 使用提供的代码以 Apache Parquet 格式保存初始 DataFrame，并按日期列进行分区：

   dataframe.to_parquet（路径=s3_spectrum_loc， 引擎='fastparquet', 索引=假， partition_cols=['log_date'], 次='int96', 追加=真）

4. 我们使用 Parquet 格式在链接到 S3 存储桶的 Amazon Redshift Spectrum 外部表中启用查询。

问题： 以 Parquet 格式保存数据时，问题出现在步骤 3 中。 “dataframe.to_parquet”函数在 S3 位置“_common_metadata”和“_metadata”中生成两个附加文件。 “_metadata”文件的大小不断增长，当超过 70 MB 时，它就会损坏。这会导致进程尝试读取损坏的文件的循环，从而阻止进一步的数据追加。

问题： 使用“dataframe.to_parquet”函数附加数据时，是否有解决方案来处理错误或限制“_metadata”文件的大小？或者，有没有办法跳过生成“_metadata”文件，同时仍然使用追加方法，确保现有数据不被替换？

任何解决此问题的见解、代码示例或建议将不胜感激。

谢谢， 阿卡什

Answer 1

我有兴趣知道文件损坏的原因或方式，这可能是可以修复的。

无论如何，_metadata 文件不是读取数据所必需的，并且可以删除 - 它只是在读取时提供可能的优化。例如，通过 dask 编写的 parquet 不再创建此文件（对于任何引擎）。 _common_metadata 文件要小得多，可能不会给您带来任何问题。

您可以尝试缓解当前问题的一个简单方法是将

stats=False

传递给

to_parquet

，这将在一定程度上减少元数据的大小。

另一个简单的修复方法是不使用append=True，而是将每个批次写入同一目录中的单独文件中。只要架构不改变，它也会很好地加载。