什么是数据迁移？

数据迁移是指将数据从一个位置转移到另一个位置，从一种格式转换为另一种格式，或从一个应用程序移动到另一个应用程序的过程。数据迁移通常是为数据引入新系统或位置的结果。业务驱动因素通常是应用程序迁移或整合，在这种迁移或整合中，原有系统会被共享同一数据集的新应用程序所取代或增强。如今，随着企业从内部基础架构和应用程序迁移到基于云的存储和应用程序以优化或转变公司，数据迁移即开始。

简单来说是因为“数据引力”。尽管数据引力的概念已经存在一段时间了，但由于数据迁移到云基础架构，这一挑战变得日益严峻。简而言之，数据引力是一个比喻，它描述了：

• 数据在增长时如何吸引其他数据
• 如何将数据集成到业务中
• 数据如何随着时间的推移进行自定义

要将应用程序和数据迁移到更有利的环境， Gartner 建议将“解绑”数据与应用程序作为克服数据重力的一种手段。通过在项目之初抽出时间来整理数据和应用程序复杂性，企业可以完善他们的数据管理，让应用程序具有移动性，并促进数据治理。

主要问题在于，每个应用程序都会在数据管理层中引入应用程序逻辑元素，从而使数据管理变得更加复杂，但每个应用程序都不会考虑下一个数据使用情形。业务流程会单独使用数据，然后输出自己的格式，而将集成问题留给后面的流程。因此，应用程序设计、数据架构和业务流程必须相互响应，但往往其中的某个环节无法或不愿意更改。这迫使应用程序管理员不得不绕过理想而简单的工作流，导致设计欠佳。虽然某个解决方法可以解决一时的问题，但最终必须在数据迁移或集成项目期间解决这种技术问题。

鉴于这种复杂性，请考虑将数据迁移升级到“战略武器”状态，以使其获得适当的认知度和资源水平。为了确保项目获得所需的关注，请强调迁移过程中最具刺激作用的因素，即旧系统将关闭，这样您一定能得到重要利益相关方的关注。

升级系统或将数据中心扩展到云具有诸多业务优势。对于许多企业来说，这是一个非常自然的演变过程。使用云的企业希望他们能够将员工的精力集中在业务优先级上，推动顶线增长，提高灵活性，降低资本支出，以及按需付费。但是，迁移类型往往决定 IT 员工可以腾出多少时间来处理其他项目。

首先，我们来定义迁移类型：

• 存储迁移。将数据从现有阵列移至更现代化的阵列，以使其他系统能够访问数据的过程。可显著提高性能，提供更经济高效的扩展能力，同时实现克隆、快照以及备份和灾难恢复等预期数据管理功能。
• 云迁移。将数据、应用程序或其他业务要素从内部数据中心移动到云或从一个云移动到另一个云的过程。
• 应用程序迁移 将应用程序程序从一个环境移动到另一个环境的过程。可能包括将整个应用程序从内部 IT 中心移动到云，在云之间移动，或者只是将应用程序的底层数据移动到软件提供商托管的新形式的应用程序。

数据迁移包括 3 个基本步骤：

1. 提取数据
2. 转换数据
3. 加载数据

移动重要或敏感数据以及停用旧系统不免会让利益相关方神经紧张。制定可靠的计划是必不可少的；但是，您不必重新发明车轮。您可以在网络上找到许多数据迁移计划和检查清单示例。例如， Data Migration Pro，这是一个由数据迁移专家组成的社区，拥有一个概况了 7 阶段流程的全面的检查清单：

• 迁移前规划。评估要移动的数据以确保稳定性。
• 项目启动。识别并简要通报主要利益相关方。
• 环境分析。建立强大的数据质量规则管理流程，并向业务部门简要介绍项目目标，包括关闭原有系统。
• 解决方案设计。确定要移动的数据以及移动前后数据的质量。
• 构建和测试。对迁移逻辑进行编码，并使用生产环境的镜像测试迁移。
• 执行并验证。证明迁移符合要求，移动的数据可供业务使用。
• 停用和监控。关闭并处置旧系统。

这似乎是一项巨大的工作，但并非每次迁移都需要执行所有这些步骤。每种情况都是独一无二的，每家公司都以不同方式处理任务。

尽管几十年来数据迁移一直是 IT 生活中的平常事，但恐怖故事年年见诸报端。以下是企业在移动数据时面临的十大挑战：

1. 不联系主要利益相关方。无论迁移规模如何，总会有人关心着您所移动的数据。在开始执行任务之前，请先追踪到利益相关方，向其说明项目的必要性及项目影响。否则，您肯定会在某个阶段听到他们的声音，他们很可能会打乱您的时间表。

2. 不与业务部门沟通。向利益相关方说明项目后，请务必让他们了解您的进度。最好在每周的同一天提供状态报告，尤其是在情况偏离正常时。定期沟通对于与所有受影响的人建立信任有很大的帮助。

3. 缺乏数据监管。请确保您清楚知道谁有权在源系统中创建、批准、编辑或删除数据，并将这些信息以书面形式记录在项目计划中。

4. 专业知识匮乏。尽管这是一项简单的任务，但移动数据涉及到许多复杂性。拥有经验丰富的专业人员以及出色的参考资料，有助于顺利完成此过程。

5. 缺乏规划。平均而言，家庭在计划假期时花费 10 到 20 个小时，而 IT 团队在规划小型数据迁移时所花费的时间可能只有一半。耗时规划并不总是能保证迁移成功，但制定可靠的数据迁移计划确实可以在实际数据移动时节省时间。

6. 数据准备软件和技能不足。如果这是一次大规模迁移（数百万条记录或数百张表），请使用一流的数据质量软件，并考虑聘请一家专业公司来提供帮助。好消息：外部公司很可能会向您出租软件，帮助您节省成本。

7. 等待目标位置达到完美规格。如果实施团队正在整理设计标准，请开始执行步骤 2 和 3。目标位置就绪状态的重要性在项目后期才会显现，现在不要让它妨碍您。

8. 未经验证的迁移方法。进行一些研究，以确保数据移动过程对像您这样的其他公司行之有效。请勿草草接受供应商提供的通用过程。

9. 供应商和项目管理。必须管理供应商和项目。如果您还有其他日常工作，请确保您有时间管理项目以及任何相关的供应商。

10. 跨对象依赖关系。借助目前可用的数据管理工具的技术和功能，如果发现原始计划中未包含某个拥有依赖关系的数据集，仍会令人震惊。由于跨对象依赖关系往往要等到迁移过程中很晚的阶段才会发现，因此请务必构建一个相应的应急计划，以免无法满足整体交付日期要求。

数据迁移和数据转换这两个术语有时会在互联网上互换使用，因此让我们来澄清一下：它们的含义不同。如前文所述，数据迁移是指在不同位置，格式或系统之间移动数据的过程。数据迁移包括目标系统中的数据剖析，数据清理，数据验证以及持续的数据质量保证流程。在典型的数据迁移场景中，数据转换只是复杂过程中的第一步。

术语“数据转换”是指将数据从一种格式转换为另一种格式的过程。如果要将数据从原应用程序移动到同一应用程序的升级版本或具有新结构的完全不同的应用程序，则必须执行数据转化。要转换数据，必须根据一组要求从源系统提取数据，然后更改数据并将其加载到新的目标系统中。

有时与数据迁移相混淆的另一个术语是数据集成。数据集成是指将驻留在不同数据源的数据组合在一起，为用户提供所有数据的统一视图的过程。集成来自多个数据源的数据对于数据分析至关重要。数据集成的示例包括数据仓库、数据湖和 NetApp® FabricPools，后者可以在内部数据中心和云之间自动进行数据分层，或者在 AWS EBS 块存储和 AWS S3 对象存储之间自动分层数据。

迁移到 基础架构即服务 (IaaS)：

• 重新托管（提升和移动）。在 IaaS 上重新部署数据和应用程序，无需进行更改。
• 修改（重新设计）。修改或扩展现有应用程序代码以适应新的云环境。
• 更换。停用在内部环境中托管和管理的原有应用程序，使用在云中托管的同类应用程序（例如 Office365）取而代之。

迁移到平台即服务 (PaaS)：

• 重构。注入代码并在云端运行应用程序。
• 重建。丢弃现有应用程序的代码，并在云端重新构建应用程序。

要确保任何数据迁移都能顺利成功，并且性能、安全性和 ROI 可以创造业务价值，选择符合业务需求的部署模式至关重要。