使用DistCp将Hadoop进行云迁移时注意事项

Distributed copy (DistCp) 似乎是 Hadoop 到云迁移工具的首选，因为它是免费的，而且大多数 Hadoop 管理员都熟悉它用于集群间复制。但这是否意味着 DistCp 是 Hadoop 到云迁移的最佳选择？
云架构师正在为云迁移而苦苦挣扎，通常面临着紧迫的过渡期限。可能是由于数据中心的关闭、现有设备接近其生命周期的终点、数据中心租约退出或各种软件事件。无论出于何种原因，架构师都在寻找解决方案，而且通常立即可用的答案是分布式副本，通常称为 DistCp。
这个免费工具最初与 Hadoop 捆绑在一起，用于在单个时间点传输数据的大型集群间和集群内数据复制。随着组织着手将其数据和基础架构迁移到云中，DistCp 开始被视为迁移项目的一部分。
问题是 DistCp 从未被设计用于大规模 Hadoop 到云的迁移。
需要明确的是，DistCp 有其用途，但也有非常明显的局限性。让我们来看看 DistCp 有什么好处，它对云迁移有什么问题，以及使用它将海量数据集迁移到云中的风险。
 
DistCp 对 Hadoop 到云迁移的好处
DistCp 是一种可行的解决方案，用于复制在 Hadoop 集群之间不经常更改的相对较少量的数据。DistCp 适用于数据量相对较小（例如小于 100 TB）且迁移期间数据更改最少的情况。如果要移动的数据集在迁移过程中没有发生快速变化（例如每秒少于 50-100 个事件），那么 DistCp 可以是一种具有成本效益的数据迁移技术。DistCp 非常适合在迁移完全不变的历史数据时使用。
 
使用 DistCp 进行 Hadoop 到云迁移的缺点
在使 DistCp 成为基于云的迁移的首选解决方案时，公司会陷入三个常见的数据陷阱。

1. 在迁移方面，公司错误地认为小数据和大数据是相同的。公司错误地假设用于小数据的方法同样适用于大量数据。如果数据集是静态的，那么问题是是否有足够的带宽来迁移数据，或者是否有足够的时间将其加载到批量传输设备上，例如 AWS Snowball 或 Azure Data Box，并将该设备运送到云服务提供商，然后上传。这类解决方案很少实用，因为大多数大型数据集都在不断变化，而且公司很少承担关闭运营的费用，即使是很短的一段时间。
2. 迁移开始后，公司错过了对源数据进行的更新。在迁移正在发生变化的数据时，一种解决方案是让数据在源头继续变化，在这种情况下，需要考虑所有这些变化，以确保在迁移完成时，没有复制到已经严重过时的云中。为了防止源和目标之间的数据不一致，需要有一种方法来识别和迁移可能发生的任何更改。典型的方法是执行多次迭代，重新扫描数据集，并捕获自上次迭代以来的变化。这种方法允许架构师迭代地接近一致的状态。但是，如果有大量数据频繁更改，则可能无法完全赶上对源数据所做的更改。
3. 公司错误地选择了需要在源头冻结数据的迁移方法，从而导致业务中断另一种选择是在源处冻结数据以防止发生任何更改。这使迁移任务变得更加简单，因为管理员可以确信上传到新位置的数据副本与源中存在的数据副本是一致的，因为在迁移过程中不允许进行任何更改。这种方法的问题是系统需要关闭，导致业务中断的时间不可接受。通过 1 Gb 的链路移动 PB 的数据需要 90 多天，而且对于绝大多数组织来说，数天、数周或数月的停机时间是不可接受的。