Question

当我运行一个简单的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

我的问题是：

有什么可以引入这种差异？我的目录的内容是否仍然与原始内容相同？
最重要的是 - 我可以设置参数以确保每个文件看起来与它们的src计数器部分完全相同（即相同的文件大小）吗？

Answer 1

有什么可以引入这种差异？我的目录的内容是否仍然与原始内容相同？

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

S3的最终一致性效果也可以发挥作用，特别是在现有对象的更新过程中。如果应用程序覆盖现有对象，那么之后会有一个时间窗口，其中读取该对象的应用程序可能会看到该对象的旧版本，或者他们可能会看到新版本。有关此内容的更多详细信息，请参阅Amazon S3 Data Consistency Model的AWS文档。

最重要的是 - 我可以设置参数以确保每个文件看起来与它们的src计数器部分完全相同（即相同的文件大小）吗？

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

作为补充说明，S3FileSystem（方案的s3://的URI）实际上已被弃用，不受Apache Hadoop社区维护且支持不足。如果可能，我们建议用户迁移到S3AFileSystem（方案为s3a://的URI），以改进功能，性能和支持。有关详细信息，请参阅更多详细信息Integration with Amazon Web Services。

如果您无法找到s3://所看到的行为的解释，那么可能存在潜伏的错误，您可能会更好地尝试s3a://。（如果您已经使用s3://编写了现有数据，那么您需要首先找出该数据的某种迁移，例如从s3:// URI复制到等效的s3a:// URI。）

Answer 2

我的观点是src的压缩方式和dst的压缩方式（或不压缩方式）有所不同。所以我会说：

1）检查创建src

的.*compress.*设置

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

压缩算法 - 使用相同的设置 - 应该产生确定性输出。所以我怀疑在目标中压缩原始压缩与压缩（或不压缩）不匹配。

Hadoop distcp -possible保持每个文件相同（保留文件大小）？

2 个答案: