当我运行一个简单的distcp命令时：
hadoop distcp s3://src-bucket/src-dir s3://dest-bucket/dest-dir我得到一个在大小（字节）上的轻微差异 src-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我的问题是：
是什么导致了这种差异？我的dest dir的内容和原来的一样吗？
最重要的是-有没有参数我可以设置，以确保每个文件看起来完全一样，他们的src计数器部分（即相同的文件大小）？
2条答案
按热度按时间qlckcl4x1#
是什么导致了这种差异？我的dest dir的内容和原来的一样吗？
是否有可能在distcp运行的同时src dir中发生了并发写入活动？例如，是否有一个文件被其他应用程序打开以便在src dir中写入，并且应用程序在distcp运行时正在将内容写入该文件？
s3的最终一致性效果也可以发挥作用，特别是在现有对象的更新方面。如果一个应用程序覆盖了一个现有的对象，那么在随后的一个时间窗口中，读取该对象的应用程序可能会看到该对象的旧版本，也可能会看到新版本。有关这方面的更多详细信息，请参阅amazons3数据一致性模型的aws文档。
最重要的是-有没有参数我可以设置，以确保每个文件看起来完全一样，他们的src计数器部分（即相同的文件大小）？
一般来说，distcp将对每个源文件执行crc检查，以确认其复制是否正确。我注意到你使用的是s3文件系统而不是hdfs。对于s3，与许多替代文件系统一样，存在无法执行crc验证的限制。
作为补充说明
S3FileSystem（URI与s3://对于这个方案），实际上已经被弃用了，没有被apachehadoop社区维护，支持也很差。如果可能，我们建议用户迁移到S3AFileSystem（URI与s3a://对于方案），以改进功能、性能和支持。有更多的细节与amazonweb服务文档集成以获取更多细节。如果你找不到你所看到的行为的解释
s3://，那么可能有一个错误潜伏在那里，你可能会更好地尝试s3a://. (如果现有数据已使用s3://不过，您需要先为这些数据找出某种迁移方法，例如从s3://uri到等价项s3a://uri。）hpcdzsge2#
我的看法是，src和dst的压缩方式（或不压缩）是不同的。所以我想说：
1） 检查
.*compress.*任何创建src的设置2） 确保它们与
.*compress.*distcp作业的设置压缩算法——使用相同的设置——应该产生确定性输出。所以我怀疑源站的压缩和目标站的压缩（或不压缩）不匹配。