希望实现数据基础设施的现代化并将Hadoop迁移到云平台中吗?以下是组织在数据迁移之前需要问的五个问题：
1.迁移的数据量是多少?
组织有几种方法可以将少量数据传输到云平台，特别是在数据是静态并且不变的情况下。其面临的风险在于认为同样的方法也适用于大量数据，尤其是当这些数据在迁移到云中时发生变化时。如果数据集很大并且是静态的，则组织需要在开始迁移之前了解是否有足够的时间和带宽，或者是否有足够的时间将其加载到批量传输设备上(如AWS Snowball或Azure data Box)，将设备运送到云计算服务提供商那里进行上传。
当迁移大量不断变化的数据时，可能会出现真正的挑战。在这种情况下，适用于小型数据集的方法不会有效，可能面临系统停机，从而导致严重的业务中断和数据迁移项目失败。选择通过网络传输大量数据的组织，通常无法考虑为其他业务流程共享这一网络资源。即使有专用的网络通道也需要考虑到这一点，因为组织通常不会在影响其他用户和进程的情况下使用所有带宽进行数据迁移。
组织需要确保有适当的机制来确保充分控制数据，以免对业务造成不良影响。在许多情况下，没有进行控制就开始移动数据的组织最终会影响其他业务的运行，因此不得不停止迁移，并在工作日结束时重新启动数据迁移。
2.在迁移过程中，如何在数据源和目的地之间保持一致的数据?
当组织需要迁移不断变化的数据时(无论是接收新数据还是更新或删除现有数据)，都可以进行选择。组织可以在数据源冻结数据直到迁移完成，或者允许数据在目的地继续更改。在这种情况下，需要弄清楚如何考虑这些更改，以便在迁移完成后不会获得已经严重过时的副本。
为了防止数据源和目的地之间的数据不一致，需要找到一种方法来识别和迁移可能发生的任何更改。典型的方法是执行多次迭代以重新扫描数据集，并捕获自从上次迭代以来的更改。这种方法使组织可以迭代到一致状态。但是，如果组织有足够大的数据量并且经常变化，则可能永远无法赶上更改的步伐。这是一个相当复杂的问题，组织很多时候并没有真正预料到这将对其资源和业务产生全面的影响。
另一种选择是在数据源冻结数据，以防止发生任何更改。这无疑使迁移任务变得简单得多。使用这种方法，无论是通过网络连接还是通过批量传输设备上传到新位置的数据副本，都与数据源中存在的数据一致，因为在迁移过程中不允许进行任何更改。
这种方法的问题在于，它可能导致系统停机并且业务可能中断。这些系统是对业务至关重要的，而依赖它们的业务流程通常无法尝试将其关闭或冻结很长时间。使用批量传输设备，可能需要几天到几周的时间才能完成传输。如果通过专用网络连接传输数据，则取决于可用的网络带宽。为了在1GB的网络链路上移动1PB的数据，则需要90天以上的时间。对于绝大多数组织来说，数天、数周或数月的停机时间和业务中断是无法接受的。
3.将如何处理迁移过程的人工处理或任何中断?
如果组织停止了数据迁移或发生了中断，如何确定要从中恢复的点，以确切地知道已经正确迁移了多少数据。根据所使用的工具，是否有可能从那时开始恢复工作，或者组织是否必须从头开始有效地重新开始该过程?这是一个复杂的问题，如果组织不得不意外中断并继续进行迁移，则采用人工处理流程会带来巨大的风险和成本。人工同步处理数据的任何尝试都会占用大量资源，成本高昂且容易出错。尝试在两个环境中人工执行这一操作都很困难，如果尝试在多个环境中执行这一操作，则要复杂得多。
在Hadoop中拥有深厚技术专长的组织将采用DistCp(分布式副本)，并且希望利用这一免费开源工具来开发自己的自定义迁移脚本。然而，DistCp是为集群间/集群内复制而设计的，而不是为大规模数据迁移而设计的。DistCp只支持特定时间点的单向数据复制。它不能适应不断变化的数据，并且需要对数据源进行多次扫描以获取每次运行之间所做的更改。这些限制带来了许多复杂的问题。组织最好使用新的云计算环境，将其资源用于开发和创新，而不是构建自己的迁移解决方案。
4.是否需要一个同时支持数据源和目标更改的混合云环境?
混合云的部署越来越受欢迎。这可能需要将公共云与私有云或组织的内部部署基础设施一起使用。对于真正的混合云方案，更改必须能够在任何位置发生，并且其更改需要传递到其他系统。而只考虑单向数据迁移的方法不支持真正的混合云方案，因为它们需要数据源和目的地的联系。
当组织在超出两个端点迁移数据时，这将变得更加复杂。人们看到越来越多的分布式环境中不仅有一个数据源和一个目的地，而且有多个云计算区域用于冗余目的，甚至采用多个云计算提供商的服务。为了避免将锁定在单点解决方案中，组织需要能够跨多个端点管理实时数据。在这种情况下需要一个解决方案，该解决方案可以跨多个环境复制更改，并解决任何潜在的数据更改冲突(最好在冲突发生之前解决)。
5.存在哪些导致数据引力驱动的应用程序依赖关系?
数据引力是指数据吸引应用程序、服务和其他数据的能力。数据量越大，吸引更多应用程序和服务所需要的引力就越大。数据引力通常还会驱动应用程序之间的依赖关系。
例如，可能有一个应用程序将另一个应用程序的输出作为输入，进而可以向更下游的其他应用程序提供数据。设计给定应用程序的业务部门或用户将知道他们的输入是什么，但他们可能并不知道每个人都在使用他们创建的数据。错过这种依赖关系变得非常容易。当应用程序移至云平台中时，其生成的结果数据将不会同步遣返回内部部署环境，并且其他工作流中的其他应用程序可能突然无法获取当前的数据。
许多组织在尝试将其数据迁移到云平台时遭遇失败。回答以上这五个问题可以在成功迁移或陷入数据迁移陷阱(可能会浪费组织的时间和资金，并影响业务运营)之间进行区分。
