我正在尝试使用distcp和airbnb reair实用程序将文件从一个hadoop clutster同步到另一个hadoop clutster，但它们都没有按预期工作。
如果源和目标上的文件大小相同，则即使文件内容已更改（校验和也不同），它们也无法更新，除非未使用覆盖选项。
我需要保持约30tb的同步数据，所以每次加载完整的数据集是不可行的。
如果文件大小相同（源代码中的计数已更改）且校验和不同，请建议如何使两个数据集同步。
我正在尝试使用distcp和airbnb reair实用程序将文件从一个hadoop clutster同步到另一个hadoop clutster，但它们都没有按预期工作。
如果源和目标上的文件大小相同，则即使文件内容已更改（校验和也不同），它们也无法更新，除非未使用覆盖选项。
我需要保持约30tb的同步数据，所以每次加载完整的数据集是不可行的。
如果文件大小相同（源代码中的计数已更改）且校验和不同，请建议如何使两个数据集同步。
1条答案
按热度按时间h6my8fg21#
distcp处理大小相同但内容不同的文件之间同步的方式是通过比较其所谓的
FileChecksum. 这个FileChecksum最早是在hadoop-3981中引入的，主要是为了在distcp中使用。不幸的是，这有一个已知的缺点，即在不同的存储实现之间不兼容，甚至在具有不同内部块/区块设置的hdfs示例之间也不兼容。具体地说，该文件校验和烘焙的结构是，例如，每个块512字节，每个块128mb。由于gcs没有“chunks”或“blocks”的相同概念，因此它不可能有任何类似的filechecksum定义。hadoop常用的所有其他对象存储也是如此；distcp文档附录在“distcp和对象存储”下讨论了这一事实。
这就是说，有一个巧妙的技巧可以用来为hdfs文件定义一个很好的复合crc的标准化表示，它与现有的hdfs部署基本兼容；我已经提交了hdfs-13056和一个概念证明，试图将其添加到上游，在这之后，它应该是有可能的，使它的开箱即用对gcs，因为gcs还支持文件级crc32c。