如何避免数据迁移陷阱.docxVIP

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