3

当我运行一个简单的 distcp 命令时：

hadoop distcp s3://src-bucket/src-dir s3://dest-bucket/dest-dir

src-dir我对dest-dir的大小（以字节为单位）略有不同

>aws s3 --summarize s3://dest-bucket/dest-dir/
...
Total Objects: 12290
   Total Size: 64911104881181

>aws s3 --summarize s3://dest-bucket/dest-dir/
...
Total Objects: 12290
   Total Size: 64901040284124

我的问题是：

  1. 是什么导致了这种差异？我的 dest 目录的内容是否仍然与原始目录相同？
  2. 最重要的是 - 我是否可以设置参数以确保每个文件看起来与其 src 对应部分完全相同（即相同的文件大小）？
4

2 回答 2

0
  1. 是什么导致了这种差异？我的 dest 目录的内容是否仍然与原始目录相同？

在 DistCp 运行的同时，是否有可能在 src-dir 中发生并发写入活动？例如，是否有其他应用程序在 src-dir 中打开了一个文件以供写入，并且该应用程序在 DistCp 运行时将内容写入文件？

S3 中的最终一致性效果也可以发挥作用，尤其是在现有对象的更新方面。如果应用程序覆盖了现有对象，那么之后有一个时间窗口，读取该对象的应用程序可能会看到该对象的旧版本，或者他们可能会看到新版本。有关这方面的更多详细信息，请参阅Amazon S3 数据一致性模型的 AWS 文档。

  1. 最重要的是 - 我是否可以设置参数以确保每个文件看起来与其 src 对应部分完全相同（即相同的文件大小）？

通常，DistCp 将对每个源文件在目的地的新副本执行 CRC 检查，以确认它被正确复制。我注意到您使用的是 S3 文件系统而不是 HDFS。对于 S3，与许多替代文件系统一样，存在无法执行此 CRC 验证的限制。

作为补充说明，S3FileSystem（用于该方案的 URI s3://）已被有效弃用，Apache Hadoop 社区未对其进行维护，并且支持不佳。如果可能，我们建议用户迁移到S3AFileSystem（s3a://用于方案的 URI）以改进功能、性能和支持。有更多详细信息与 Amazon Web Services文档集成以获取更多详细信息。

如果你找不到你所看到的行为的解释s3://，那么可能有一个 bug 潜伏在那里，你最好尝试一下s3a://。（如果您有已经使用写入的现有数据s3://，那么您需要首先为该数据找出某种迁移，例如通过从s3://URI 复制到等效的s3a://URI。）

于 2017-06-19T17:25:11.777 回答
0

我的看法是 src 的压缩方式和 dst 的压缩方式（或不压缩）是有区别的。所以我想说：

1）检查.*compress.*任何创建 src 的设置

2) 确保它们与.*compress.*distcp 作业的设置相匹配

压缩算法——使用相同的设置——应该产生确定性的输出。因此，我怀疑原始压缩与目的地压缩（或不压缩）不匹配。

于 2017-06-22T18:38:38.840 回答