除非你在一家初创公司，否则你很少会从零开始构建一个数据平台。相反，你将通过从传统系统中迁移数据构建一个新的数据平台。在这一章中，让我们审视迁移过程------在迁移到新数据平台时应该做的所有事情。我们将首先提出一个概念模型和可能的框架，供你在现代化数据平台时遵循。然后，我们将讨论一个组织如何估算解决方案的总体成本。我们将探讨如何确保在迁移进行的同时安全性和数据治理得到落实。最后，我们将讨论模式、数据和管道迁移。你还将了解有关区域容量、网络和数据传输约束的选项。

现代化数据工作流

在开始制定迁移计划之前，您应该全面了解为何进行迁移以及您要迁移到何处的愿景。

整体视角

数据现代化转型应该被全面考虑。从俯瞰的角度看，我们可以确定三个主要支柱：

业务成果
- 关注正在现代化的工作流，并确定这些工作流驱动的业务成果。这对于确定差距和机会所在至关重要。在做出任何技术决策之前，将迁移限制在与领导层确定的业务目标一致的用例中（通常在两到三年的时间范围内）。
利益相关方
- 确定可能访问数据的个人或角色（其中一些团队可能尚不存在）。数据现代化的目标是使数据访问民主化。因此，这些团队将需要在数据现代化的最终状态技术中使用的任何工具（SQL、Python、仪表板）上变得数据有素，并能熟练运用。
技术
- 您将不得不根据业务战略和团队能力来定义、实施和部署数据架构、建模、存储、安全、集成、可操作性、文档、参考数据、质量和治理。

确保您不将迁移视为纯粹的IT或数据科学项目，而是作为技术方面只是更大范围的组织变革的子集。

现代化工作流

当你考虑进行现代化项目时，你的思维自然会偏向于你目前使用的工具所带来的困扰。你决定要升级你的数据库，并使其在全球范围内保持一致和可伸缩，所以你将其现代化为Spanner或CockroachDB。你决定要升级你的流处理引擎，并使其更具弹性和更易于运行，所以你选择了Flink或Dataflow。你决定不再调整数据仓库中的集群和查询，所以你将其现代化为BigQuery或Snowflake。

这些都是不错的举措。在可能的情况下，无论何时你都应该升级到更易于使用、更易于运行、更具可伸缩性和更具弹性的工具。然而，如果你只是进行一对一的工具更改，你最终只会取得渐进式的改进。你将无法从这些升级中获得变革性的改变。

为了避免这种陷阱，在你开始数据现代化之旅时，强迫自己思考工作流程，而不是技术。现代化数据工作流程意味着什么？考虑最终用户想要完成的整体任务。也许他们想要识别高价值客户。也许他们想要运行一项营销活动。也许他们想要识别欺诈行为。现在，从整体上考虑这个工作流程以及如何以尽可能便宜和简单的方式实现它。

接下来，从第一原则出发，以你现代化的工具集实现这样的工作流程。在这样做时，大量依赖自动化：

自动化数据摄取
- 不要编写定制的ELT流水线。使用现成的ELT工具，如Datastream或Fivetran，将数据导入数据仓库。实时转换数据并在物化视图中捕获常见的转换要比为每个可能的下游任务编写ETL流水线要容易得多。此外，许多SaaS系统将自动导出到S3、Snowflake、BigQuery等。
默认使用流处理
- 将数据存储在一个结合了批处理和流处理存储的系统中，以便所有SQL查询都反映最新的数据（受一些延迟的影响）。任何分析工具都应该使用相同的框架处理流处理和批处理。在我们的示例中，生命周期价值计算可以是一个SQL查询。出于重用的目的，将其作为物化视图。这样，所有计算都是自动的，数据始终是最新的。
自动扩展
- 任何期望你预先指定机器数量、仓库大小等的系统都将要求你关注系统而不是要完成的工作。你希望扩展是自动的，这样你就可以关注工作流程而不是工具。
查询重写、融合阶段等
- 你希望能够专注于要完成的工作并将其分解为可理解的步骤。你不想调整查询、重写查询、融合转换等。让内置于数据堆栈中的现代优化器处理这些事务。
评估
- 你不想为评估ML模型的性能编写定制的数据处理流水线。你只想能够指定采样率和评估查询，并收到有关特征漂移、数据漂移和模型漂移的通知。所有这些功能都应该内置到已部署的端点中。
重新训练
- 如果遇到模型漂移，你应该重新训练模型的可能性为10次中有9次。这也应该是自动的。现代ML流水线将提供一个可调用的挂接，你可以直接将其与你的自动评估流水线相关联，以便你也可以自动进行重新训练。
持续培训
- 模型漂移不是需要重新训练的唯一原因。当你有更多的数据时，可能需要重新训练。也许是当新数据着陆在存储桶中时。或者是在代码检入时。同样，这也可以自动化。

一旦你确认需要一个完全自动化的数据工作流，你将看到一个相当模板化的设置，包括连接器、数据仓库和ML流水线。所有这些都可以是无服务器的，因此你基本上只需要配置，而不是集群管理。

当然，你还将编写一些具体的代码：

SQL中的数据准备
TensorFlow或PyTorch等框架中的ML模型
用于连续评估的评估查询

我们能够将每个工作流程简化到这样一个简单的设置，这就解释了为什么一个集成的数据和AI平台是如此重要。

改变工作流本身

你可以通过使用现代数据堆栈使工作流程本身更加高效，使其更加自动化。但在这样做之前，你应该问自己一个关键问题："这个工作流程是否有必要由数据工程师预先计算？"因为每当你构建一个数据流水线时，你都在进行预计算。这只是一种优化，不再多。

在许多情况下，如果你可以使工作流程成为自助式和自发的，你就不必使用数据工程资源构建它。由于许多工作都是自动化的，你可以提供在完整历史交易记录上运行任何聚合（不仅仅是生命周期价值）的能力。将生命周期价值计算移到声明性语义层，用户可以在其中添加自己的计算。例如，Looker这样的工具就可以做到这一点。一旦这样做，你将获得整个组织中一致的关键绩效指标（KPIs）和用户有权构建常见度量库的好处。创建新指标的能力现在掌握在业务团队手中，这本来就是其所属的地方。

四步迁移框架

可以对构建数据平台的过程中可能遇到的许多情况应用一种标准化的方法。这种方法在很大程度上独立于数据平台的规模和深度------我们既用于现代化小公司的数据仓库，也用于为跨国企业开发全新的数据架构。

该方法基于图4-1中显示的四个主要步骤：

准备和发现： 所有利益相关方都应进行初步分析，以确定需要迁移的工作负载列表和当前的痛点（例如，无法扩展、处理引擎无法更新、不需要的依赖关系等）。
评估和规划： 评估在前一阶段收集的信息，定义成功的关键指标，并计划每个组件的迁移。
执行： 对于每个确定的用例，决定是停用、完全迁移（数据、模式、下游和上游应用程序）还是卸载它（通过将下游应用程序迁移到不同的源）。然后，测试和验证所做的任何迁移。
优化： 一旦过程开始，可以通过持续迭代来扩展和改进它。首次现代化的步骤可以仅关注核心功能。

让我们依次详细介绍每个步骤。

准备与发现

第一步是准备与发现。这涉及定义迁移的范围，并收集与将要迁移的工作负载/用例相关的所有信息。这包括分析来自企业各个利益相关方的广泛输入，如业务、财务和IT。请这些利益相关方：

列出所有与迁移相关的用例和工作负载，附有它们的相关优先级，确保其中包括合规要求、延迟敏感性等相关信息。
解释他们可以通过新系统获得的预期好处（例如查询性能、能够处理的数据量、流处理能力等）。
提出市场上可能满足业务需求的解决方案。
进行初步的总体成本拥有分析，以估算迁移的价值。
辨认培训和招聘方面的需求，以建立一支有能力的团队。

您可以使用问卷调查从应用程序所有者、数据所有者和选定的最终用户那里收集这些见解。

评估与规划

评估与规划包括以下活动：

1. 当前状态的评估： 分析每个应用程序、工作流或工具的当前技术架构，通过收集和分析服务器配置、日志、作业活动、数据流映射、容量统计、查询和集群等信息。随着旧系统规模的增加，这项工作可能会变得耗时且容易出错。因此，请寻找可以自动化整个过程的工具（例如SnowConvert、CompilerWorks、AWS Schema Conversion Tool、Azure Database Migration Service、Datametica Raven等）。这些工具可以提供工作负载拆分、依赖关系映射、复杂性分析、资源利用率、容量分析、SLA分析、端到端数据血统以及各种优化建议。

2. 工作负载分类： 利用在"准备与发现"步骤中使用的问卷收集的信息，结合评估阶段的深入见解，将所有已识别的工作负载分类并选择一种适当的迁移方法：

Retire（退役）： 工作负载最初将保留在本地，最终将被停用。
Retain（保留）： 由于技术限制（例如运行在专用硬件上）或出于业务原因，工作负载将保留在本地。这可能是暂时的，直到工作负载可以进行重构，或者可能被移到协作设施，其中数据中心需要关闭，而服务不能被移动。
Rehost（重新托管）： 工作负载将迁移到云环境中，利用其基础设施即服务（IaaS）功能。这通常被称为"搬迁和提升"。
Replatform（重新平台化）： 工作负载（或其中的一部分）将进行部分更改，以提高性能或降低成本，然后迁移到IaaS。这通常被称为"搬迁和改进"。在进行搬迁和提升后进行优化，通常从容器化开始。
Refactor（重构）： 工作负载（或其中的一部分）将迁移到一个或多个云完全托管的平台即服务（PaaS）解决方案（例如BigQuery、Redshift、Synapse）。
Replace（替换）： 工作负载将被第三方现成的或SaaS解决方案完全替代。
Rebuild（重建）： 工作负载将被完全重新设计，使用云完全托管的解决方案，并从头开始实施。这是重新思考应用程序并计划如何充分利用云原生服务的阶段。

3. 工作负载群集化： 将那些不会被退役/重建的工作负载分组成一系列基于其相对业务价值和迁移所需工作的群组。这有助于在迁移过程中确定可以遵循的优先级。例如：

Group 1（第一组）： 高业务价值，低迁移工作量（优先级0---快速成功）
Group 2（第二组）： 高业务价值，高迁移工作量（优先级1）
Group 3（第三组）： 低业务价值，低迁移工作量（优先级2）
Group 4（第四组）： 低业务价值，高迁移工作量（优先级3）

在图4-2中，您可以看到一个群集化示例，其中工作负载根据所描述的优先级标准被划分为各个组。在每个组中，工作负载可能有不同的迁移方法。

在整个过程中，我们建议您遵循以下实践：

使过程可衡量。 确保利益相关方同意并能够使用一些业务关键绩效指标（KPI）评估现代化的结果。

从最小可行产品（MVP）或概念验证（PoC）开始。 将大型任务分解为较小的任务，并确保存在任何即将进行的工作的标准模板。如果没有，请进行概念验证，并将其用作以后的模板。寻找可以作为其他转换示例的快速成功案例（优先级0工作负载），同时也可以向领导层展示这种现代化可能引入的影响。

估算完成所有活动所需的总时间。 创建一个整体项目计划（在必要时与供应商或顾问合作），以定义工作负载转换所需的时间、成本和人员。

在关键阶段进行过度沟通。 确保利益相关方了解计划、需要多长时间以及关键组件是什么。确保在完成云项目的过程中提供价值，并通过组织中实际可用的项目建立信心。尽量确定关键时刻，并发送即时通信，总结已完成的工作的详细信息。

既然您对准备进行下一次迁移的任务有了很好的了解，让我们看看您应该如何着手进行。

执行

对于每个工作负载，您现在都有一个计划。具体而言，您知道将迁移什么（整个工作负载还是其中的一部分），将在何处迁移（IaaS、PaaS或SaaS），您将如何迁移（rehost、replatform、rebuild等），您将如何衡量成功，您将遵循什么模板，需要多长时间，以及将在哪些里程碑上进行沟通。为了将计划变为现实，我们建议您建立一个着陆区（landing zone），迁移到该区域，并验证已迁移的任务。

着陆区（Landing Zone）

首先，您需要构建所谓的着陆区（landing zone）- 所有工作负载将驻留的目标环境。这个活动根据您当前的配置可以具有不同的复杂性，但至少您将需要：

定义目标项目及相关组织（例如，Google Cloud组织层次结构）
设置新的身份管理解决方案或与传统或第三方解决方案集成（例如，Azure Active Directory或Okta）
配置授权（例如，AWS IAM）和审计系统（例如，Azure安全日志记录和审计）
定义并设置网络拓扑及相关配置

一旦着陆区准备好，就是开始迁移的时候了。

迁移

通常建议将迁移分为多个阶段或迭代，除非您要迁移的工作负载数量非常小。这将使您能够在一次迁移一部分工作负载的情况下，积累经验和信心，处理挑战和错误。

对于每个工作负载，您可能需要考虑以下事项：

模式和数据迁移： 根据用例，您可能需要翻译数据模型或仅传输数据。
查询转译： 在某些情况下，您可能需要将查询从源系统翻译到目标系统。如果目标系统不支持所有扩展，您可能需要重构查询。您可以利用诸如Datametica Raven或生成式人工智能等工具来减少手动工作的量。
数据流水线迁移： 数据流水线是准备数据进行分析的数据工作负载的核心部分。我们将在"模式、流水线和数据迁移"中看到处理此类迁移的可能方法。
业务应用程序迁移： 一旦迁移了数据，您需要迁移使用户能够与数据交互的应用程序。
性能调优： 如果迁移的工作负载性能不如预期，您必须进行故障排除和修复。也许目标解决方案没有正确配置，您定义的数据模型不允许利用目标平台的所有功能，或者在转译过程中存在问题。

使用基础设施即代码工具如Ansible或Terraform是至关重要的，因为它们可以自动化尽可能多的部署基础设施管理，加快每个迭代的测试和执行。

验证

一旦工作负载完成迁移，您需要仔细检查是否一切都已成功完成。验证工作负载的性能、运行成本、访问数据的时间等是否都符合您确定的关键绩效指标（KPI）。验证您获得的所有结果是否符合期望（例如，查询结果是否与传统环境中的相同）。一旦确保结果符合您的需求，就可以转移到第二个用例，然后是第三个，直到您将所有内容都迁移完毕。如果可能的话，尽量并行处理后续迭代，以加快整个过程。

在每个工作负载结束时，记录可能遇到的问题、完成所有活动所需的时间以及相关的经验教训，以改进后续工作负载的过程是一个不错的主意。

优化

框架的最后一步是优化。在这里，您不会专注于每个单独迁移组件的性能。相反，您将把新系统作为一个整体来考虑，并确定引入潜在新用例以使其更加灵活和强大。您应该反思迁移所获得的成果（例如，无限的可扩展性、增强的安全性、增加的可见性等）以及作为下一步潜在的操作（例如，扩展数据收集的边界，与供应商建立更好的协同关系，开始将数据变现等）。您可以从"准备和发现"阶段收集的信息开始，了解自己在理想旅程中的位置，并考虑额外的下一步。这是一个永无止境的故事，因为创新，如商业一样，永远不会停歇，它将帮助组织在理解和利用其数据方面变得越来越好。

现在您对如何利用四步迁移框架来处理迁移有了更好的理解，让我们深入了解如何估算解决方案的总体成本。

估算解决方案的总体成本

你刚刚看到了一个通用的迁移框架，可以帮助组织定义现代化数据平台所需执行的一系列活动。CTO、CEO或CFO可能会问的第一个问题是："我们需要为此预算多少总成本？"在本节中，我们将审查组织通常如何应对这一挑战以及它们如何构建工作结构，以从供应商和第三方供应商那里获取报价。始终牢记，这不仅涉及技术成本，总是需要考虑人员和流程成本。

现有基础设施的审计

正如您所见，一切都始于对现有环境的评估。如果您对当前的基础设施状况没有清晰的了解，那么在正确评估下一代现代数据平台的定价方面肯定会面临挑战。这项工作可以通过以下三种方式之一进行：

由内部IT/基础设施团队手动进行： 许多组织维护配置管理数据库（CMDB），它可以是一个文件或包含组织内使用的所有关键硬件和软件组件信息的标准数据库。这是组织内当前运行情况的一种快照，涵盖了甚至是组件之间的关系。CMDB可以更好地了解所有应用程序的运行成本，并帮助关闭不必要或多余的资源。
由内部IT/基础设施团队自动进行： 目标与前一点中描述的完全相同，但旨在利用能够以自动方式收集信息的软件（与硬件相关的数据、在服务器上运行的应用程序、系统之间的关系等）。这些类型的工具（例如 StratoZone、Cloudamize、CloudPhysics 等）通常会生成与最常见的云超大规模供应商（例如 AWS、Google Cloud 和 Azure）相关的建议，例如机器的大小以及优化选项（例如每天应该运行多少小时才能执行其任务）。
利用第三方参与者： 咨询公司和云供应商拥有经验丰富的人员和自动化工具，可以执行生成CMDB和前两个选项中描述的详细报告的所有活动。如果您的组织通常将IT项目外包给咨询公司，我们建议选择这种方式。

接收信息/提案和报

虽然这可能是您进行的唯一一次迁移，因此您必须边学边做，但咨询公司专门从事此类工作，通常更擅长处理迁移项目。当然，要验证分配给您的团队是否具有必要的经验。一些服务提供商甚至可能会执行评估并提供成本估算，如果他们看到未来的机会。

确定在现代化过程中合作的最佳合作伙伴或供应商可能是一项艰巨的任务。有许多变量需要考虑（知识、能力、成本、经验），如果不以严格的方式执行，可能会变得非常复杂。这就是为什么组织通常利用三种类型的问卷调查从潜在的服务提供商那里收集信息的原因：

信息请求（RFI）： 用于收集有关供应商/潜在合作伙伴解决方案和服务的详细信息的问卷。它具有教育目的。
提案请求（RFP）： 用于收集关于供应商/合作伙伴将如何利用其产品和服务解决特定组织问题的详细信息的问卷（在这种情况下，是现代数据平台的实施）。它用于比较结果。
报价请求（RFQ）： 用于根据特定要求收集有关不同供应商/潜在合作伙伴定价的详细信息的问卷。它用于定量和标准化定价，以便未来进行比较。

您的组织可能有关于如何执行此操作的政策和模板。与您的法务或采购部门进行沟通。否则，要求供应商向您展示他们通常使用的工具。

一旦您收到所有供应商/潜在合作伙伴的回复，您应该获得选择最佳路径前进的所有信息。在某些情况下，特别是在要解决的问题可能非常模糊（例如，实时分析可能在一天内甚至一天内有多个峰值），即使对于供应商/潜在合作伙伴来说，提供有关成本的清晰详细信息也是具有挑战性的。这就是为什么有时供应商会要求进行概念验证（PoC）或最小可行产品（MVP），以更好地了解解决方案在实际用例场景中的工作方式并促使最终定价的定义。

概念验证（PoC）/最小可行产品（MVP）

新数据平台的设计和开发可能具有挑战性，因为大多数组织希望利用数据平台迁移的机会，不仅仅是进行简单的搬迁，而是要添加在旧世界中不可用的新功能和能力。由于这对他们来说是新的，组织（因此也包括供应商）可能无法完全理解最终行为，尤其是平台将产生的最终成本。

为了解决这一挑战，组织通常要求精选的供应商或潜在合作伙伴在分析了RFP响应之后，实施最终解决方案的初始模拟（或具有有限功能的实际工作解决方案）作为第一步。这个模拟允许利益相关者体验最终解决方案的行为，以便他们可以确定是否需要任何范围的更改。模拟还使成本估算变得更加容易，尽管重要的是要注意，我们总是在谈论估算，而不是具体的定价。在采用云模型时，尤其是如果您想利用弹性，几乎不可能有清晰和最终定义的定价。弹性是云的主要优势之一，只有在生产中才能体验到。

有三种方法来处理模拟的想法：

概念验证（Proof of Concept，PoC）： 构建解决方案的一小部分，以验证可行性、可集成性、可用性和潜在弱点。这有助于估算最终价格。目标不是触及平台的每个功能，而是验证可能需要重新设计的事物。例如，在处理流水线时，通过随机变化要处理的数据量，创建一个PoC是一个良好的实践。这将让您看到系统如何扩展，并为您提供更好的数据，以估算最终生产成本。
最小可行产品（Minimum Viable Product，MVP）： MVP的目标是开发一个具有非常明确定义的范围的产品，所有功能都已实施并且像一个真正的、完整的产品一样在生产环境中部署（例如，在新的DWH上实施的数据集市，连接到新的业务智能工具，以解决一个非常具体的用例）。MVP的主要优势是能够迅速从实际用户那里获得反馈，这有助于团队改进产品并产生更好的估算。
混合方法： 最初，团队将以更广泛的范围开发一个通用的PoC，但深度有限（例如，端到端的数据流水线，以收集训练图像分类ML算法所需的数据），然后，基于第一轮结果和成本评估，焦点将转向开发MVP，可以看作是实施完整解决方案的第一步。

现在您了解了如何估算成本，让我们深入研究迁移的第一部分------设置安全性和数据治理。

建立安全性和数据治理

即使数据的所有权和控制权移交给业务部门，安全性和治理仍然是大多数组织中的中心关注点。这是因为在角色定义、数据安全和活动日志记录方面需要保持一致性。在缺乏这种一致性的情况下，要遵守《被遗忘权》等法规是非常困难的，根据这些法规，客户可以要求删除与他们有关的所有记录。

在本节中，我们将讨论这种中心化数据治理框架中需要具备哪些能力。然后，我们将讨论中心团队需要维护的工件以及它们在数据生命周期中如何结合在一起。

框架

安全性和治理试图解决的三个风险因素是：

未经授权的数据访问在将数据存储在公共云基础设施中时，有必要防止对敏感数据的未经授权访问，无论是公司机密信息还是法律保护的个人身份信息（PII）。
法规合规诸如《通用数据保护条例》（GDPR）和法律实体标识符（LEI）等法律限制了数据分析的地点、类型和方法。
可见性了解组织中存在哪些类型的数据，目前谁在使用这些数据，以及他们如何使用可能是供应组织数据的人所需的。这需要及时的数据和一个功能齐全的目录。

鉴于这些风险因素，有必要建立一个全面的数据治理框架，涵盖数据的整个生命周期：数据摄取、编目、存储、保留、共享、归档、备份、恢复、防丢失和删除。这样的框架需要具备以下能力：

数据血缘组织需要能够识别数据资产并记录应用于创建每个数据资产的转换。
数据分类我们需要能够对敏感数据进行概要和分类，以确定每个数据资产或其部分需要应用哪些治理政策和程序。
数据目录我们需要维护一个包含结构元数据、血缘和分类的数据目录，并允许搜索和发现。
数据质量管理需要有一个过程来记录、监测和报告数据质量，以便为分析提供可信赖的数据。
访问管理这通常将与云 IAM 一起工作，以定义角色、指定访问权限并管理访问密钥。
审计组织和其他组织的授权个人（如监管机构）需要能够监控、审计和跟踪法律或行业规定所要求的细粒度活动。
数据保护需要能够加密数据、对其进行掩码或永久删除。

要使数据治理实现运营化，您将需要建立一个允许进行这些活动的框架。云工具（如Google Cloud上的Dataplex和Azure上的Purview）提供了统一的数据治理解决方案，以管理数据资产，无论数据位于何处（即单一云、混合云或多云）。Collibra和Informatica是云不可知的解决方案，提供记录血缘、进行数据分类等功能。根据我们的经验，这些工具中的任何一个都可以使用，但数据治理的艰苦工作并不在于工具本身，而是在于其运营化。建立一个运营模型------数据治理的流程和程序，以及一个负责确保业务团队遵守这些流程的委员会是非常重要的。该委员会还需要负责制定分类法和本体论，以确保组织内部的一致性。理想情况下，您的组织应参与并与行业标准机构保持一致。最好的组织还会定期进行持续的教育和培训活动，以确保遵守数据治理实践。既然我们已经讨论了集中化数据治理框架中需要具备哪些能力，让我们列举中央团队需要维护的工件。

Artifacts

为了向组织提供上述功能，中央数据治理团队需要维护以下工件：

企业词典（Enterprise Dictionary）： 这可以是一个简单的纸质文档，也可以是一个自动化（并执行）某些政策的工具。企业词典是组织使用的信息类型的存储库。例如，与各种医疗程序相关的代码或有关任何财务交易必须收集的必要信息都是企业词典的一部分。中央团队可以提供验证服务，以确保满足这些条件。许多读者熟悉的一个简单示例是由美国邮政服务提供的地址验证和标准化 API。企业经常使用这些 API 来确保组织内任何数据库中存储的地址都是标准的。
数据类别（Data Classes）： 企业词典中的各种信息类型可以分组为数据类别，并可以以一致的方式定义与每个数据类别相关的政策。例如，与客户地址相关的数据政策可能是邮政编码对一类员工可见，但对于仅在处理该客户的工单时主动参与的客户支持人员可见的更详细信息可能是可见的。
政策手册（Policy Book）： 政策手册列出了组织中使用的数据类别，每个数据类别的处理方式，数据的保留期限，可以存储数据的位置，需要控制对数据的访问方式等。
用例政策（Use Case Policies）： 通常，围绕数据类别的政策取决于用例。一个简单的例子是，客户的地址可能由履行客户订单的发货部门使用，但不会被销售部门使用。用例可能更加微妙：例如，客户的地址可能用于确定特定商店驾驶距离内的客户数量，但不用于确定特定客户是否在驾驶距离内的特定商店。
数据目录（Data Catalog）： 这是一个管理与数据相关的结构元数据、血缘、数据质量等的工具。数据目录充当高效的搜索和发现工具。

除了上述与数据相关的工件外，中央组织还需要维护单一身份验证 (SSO) 能力，以在整个组织中提供唯一的身份验证机制。由于许多自动化服务和 API 通过密钥访问，并且这些密钥不应以明文形式存储，因此密钥管理服务通常也是中央团队的额外职责。

作为现代化过程的一部分，重要的是要启动这些工件并将其放置在适当的位置，以便随着数据转移到云中，它成为强大数据治理框架的一部分。不要将数据治理推迟到云迁移之后，因为这样做的组织往往会迅速失去对其数据的控制。

现在，让我们看看框架的能力和工件如何在数据的生命周期内相互关联。

数据的生命周期内的治理

数据治理涉及整合人员、流程和技术，贯穿数据的整个生命周期。数据的生命周期包括以下阶段：

数据创建： 这是创建/捕获数据的阶段。在此阶段，应确保同时捕获元数据。例如，在捕获图像时，同时记录照片的时间和位置是很重要的。同样，在捕获点击流时，需要注意用户的会话ID、他们所在的页面、页面的布局（如果是根据用户个性化的），等等。
数据处理： 在捕获数据后，通常需要对其进行清理、丰富，并将其加载到数据仓库中。作为数据血缘的一部分，捕获这些步骤是重要的。除了血缘关系，还需要记录数据的质量属性。
数据存储： 通常将数据和元数据存储在持久存储中，如对象存储（S3、GCS等），数据库（Postgres、Aurora、AlloyDB等），文档数据库（DynamoDB、Spanner、Cosmos DB等），或数据仓库（BigQuery、Redshift、Snowflake等）。在这一阶段，需要确定行和列的安全性要求，以及是否需要在保存之前对任何字段进行加密。在数据治理团队的思考中，数据保护是至关重要的。
数据目录： 需要将持久化的数据输入到企业数据目录中，并启用发现 API 以进行搜索。必须记录数据及其用法的详细信息。
数据归档： 可以从生产环境中归档较旧的数据。如果是这样，请记得更新目录。必须注意是否法律要求进行此类归档。理想情况下，应根据适用于整个数据类别的策略自动执行归档方法。
数据销毁： 可以删除已经超过法定保留期的所有数据。这也需要包含在企业的策略手册中。

对于这些阶段，您必须制定数据治理政策。执行这些阶段的人员需要具备一定的访问权限。同一人在数据生命周期的不同阶段可能会有不同的职责和关注点，因此以"角色"而非"职责"来思考会更有帮助：

法务： 确保数据使用符合合同要求和政府/行业法规。
数据监管员： 数据的所有者，为特定数据项设置政策的人。
数据管理者： 为数据类别制定政策，并确定特定数据项属于哪个类别的人。
隐私专员： 确保用例不会泄露个人身份信息。
数据用户： 通常是使用数据进行业务决策的数据分析师或数据科学家。

既然我们已经了解了可能的迁移、安全和治理框架，让我们深入研究如何开始执行迁移。

架构、流水线和数据迁移

在本节中，我们将更详细地探讨可用于架构和流水线迁移的模式以及在数据传输过程中可能面临的挑战。

架构迁移

在将旧有应用程序迁移到新的目标系统时，你可能需要演进你的模式，以利用目标系统提供的所有功能。首先将模型按原样迁移到目标系统，连接上游（数据源和传输数据的流水线）和下游（用于处理、查询和可视化数据的脚本、过程和业务应用程序）流程，然后利用目标环境的处理引擎执行所有更改，是最佳实践。这种方法有助于确保您的解决方案在新环境中正常工作，最小化停机风险，并允许您在第二阶段进行更改。

在这里，通常可以应用外观模式------一种设计方法，通过一组视图向下游流程公开隐藏底层表的视图，以隐藏最终所需更改的复杂性。然后，这些视图可以描述一个新的模式，有助于利用临时目标系统功能，而不干扰由此抽象层"保护"的上游和下游流程。如果无法采用这种方法，数据必须在进入新系统之前进行转换和转换。这些活动通常由迁移范围内的数据转换流水线执行。

流水线迁移

在将传统系统迁移到云中时，有两种不同的策略可以采用：

卸载工作负载： 在这种情况下，保留供给源系统的上游数据流水线，并将数据的增量副本放入目标系统。最后，更新下游流程以从目标系统读取数据。然后，您可以继续卸载下一个工作负载，直到完成。完成后，可以开始完全迁移数据流水线。
完全迁移工作负载： 在这种情况下，必须将所有内容都迁移到新系统（与数据流水线一起），然后淘汰相应的传统表。

供给工作负载的数据需要进行迁移。它可以来自各种数据源，并且可能需要特定的转换或连接操作以使其可用。一般来说，有四种不同的数据流水线模式：

ETL（抽取-转换-加载）： 所有转换活动，以及数据收集和数据摄入，将由一个特定的系统执行，该系统具有适当的基础设施和适当的编程语言（该工具通常可以使用标准编程语言进行编程）。
ELT（抽取-加载-转换）： 与ETL类似，但有一个区别，所有转换将由数据将被摄入的处理引擎执行（正如我们在前面的章节中看到的，这是处理现代云解决方案时的首选方法）。
提取和加载（EL）： 这是最简单的情况，数据已经准备好，不需要进一步的转换。
变更数据捕获（CDC）： 这是一种用于跟踪源系统中数据更改并在目标系统中反映这些更改的模式。它通常与ETL解决方案一起工作，因为它在对下游流程进行任何更改之前存储原始记录。

正如您在前一节中看到的，您可以为不同的工作负载迁移识别不同的方法。相同的方法论可以应用于数据流水线：

退役（Retire）： 数据流水线解决方案不再使用，因为它与旧用例相关或已被新解决方案取代。
保留（Retain）： 数据流水线解决方案仍然留在传统系统中，因为它可能很快就可以退役，因此启动迁移项目不是经济上可行的。也可能存在一些法规要求，禁止在公司边界之外移动数据。
重托（Rehost）： 数据流水线解决方案被提升并移到云环境中，利用IaaS范式。在这种情况下，除了在连接级别进行一些修改之外，您不会引入任何大的修改，其中可能需要设置专用网络配置（通常是虚拟专用网络或VPN）以启用云环境和本地环境之间的通信。如果上游流程在公司边界之外（例如，第三方提供商、其他云环境等），可能不需要VPN，因为可以使用其他技术（例如经过身份验证的REST API）以安全的方式建立通信。在继续之前，有必要向云供应商验证底层系统中是否存在任何技术限制，以防止解决方案的正确执行，并仔细检查可能的许可证限制。
重平台（Replatform）： 在此情况下，数据流水线解决方案的一部分在迁移之前进行了转换，以便利用云的功能，例如PaaS数据库或容器化技术。在"重托"描述中突出显示的连接方面的考虑仍然有效。
重构（Refactor）： 流水线解决方案将迁移到一个或多个云完全托管的PaaS解决方案（例如，Amazon EMR、Azure HDInsight、Google Cloud Dataproc、Databricks）。在采用此方法时，最好采用与整个迁移相同的迭代方法：
- 准备并发现要迁移的作业，可能按复杂性组织它们。
- 计划和评估可能要迁移的MVP。
- 执行迁移并根据定义的KPI评估结果。
- 对所有其他作业进行迭代，直到结束。
在"重托"部分突出显示的连接方面的注意事项仍然有效。
替代（Replace）： 流水线解决方案将被第三方现成或SaaS解决方案（例如，Fivetran、Xplenty、Informatica等）完全替换。在"重托"部分突出显示的连接方面的注意事项仍然有效。
重建（Rebuild）： 流水线解决方案将使用云完全托管的解决方案（例如，AWS Glue、Azure Data Factory、Google Cloud Dataflow）进行完全重建。在"重托"部分突出显示的连接方面的注意事项仍然有效。

在迁移阶段，特别是与目标系统集成时，您可能会发现您的数据流水线解决方案与确定的目标云解决方案并不完全兼容。您可能需要一个连接器（通常称为接收器），它能够在数据流水线解决方案（例如ETL系统）与目标环境之间进行通信。如果该解决方案的接收器不存在，您可能能够生成一个文件作为过程的输出，然后在以下步骤中摄入数据。虽然这种方法会引入额外的复杂性，但在紧急情况下（等待供应商提供连接器时）是一种可行的临时解决方案。

数据迁移

现在您已经准备好新的模式和流水线，您可以开始迁移所有数据了。您应该着重考虑如何处理数据传输。您可能希望将所有本地数据迁移到云中，甚至是陈旧的老磁带（也许将来某天会有人要求这些数据）。您可能会面临一个事实，即在周末通过单个FTP连接完成任务可能是不够的。

计划

数据迁移需要计划。您需要确定并牵涉到：技术负责人能够提供执行迁移所需资源访问权限的人员（例如存储、IT、网络等）。

批准者能够为您提供所需批准以获取数据访问权限并启动迁移的人员（例如数据所有者、法律顾问、安全管理员等）。

交付迁移团队。如果可用，可以是组织内部的人员，或者是属于第三方系统集成商的人员。

然后，您需要收集尽可能多的信息，以充分了解您需要做什么，以及以什么顺序进行（例如，也许您的迁移团队需要获准访问包含要迁移的数据的特定网络存储区域），以及可能会遇到的阻碍。以下是一些问题（不是详尽无遗的），在继续之前您应该能够回答这些问题：

您需要迁移哪些数据集？
基础数据在组织中的位置在哪里？
您被允许迁移哪些数据集？
是否有任何特定的法规要求您必须遵守？
数据将落地在哪里（例如对象存储与DWH存储）？
目的地区域是什么（例如欧洲、中东和非洲、英国、美国等）？
是否需要在传输之前执行任何转换？
您想要应用哪些数据访问策略？
这是否是一次性的传输，还是您需要定期迁移数据？
数据传输的资源有哪些？
分配的预算是多少？
您是否有足够的带宽来完成传输，以及是否足够的时间？
您是否需要利用脱机解决方案（例如Amazon Snowball、Azure Data Box、Google Transfer Appliance）？
完成整个数据迁移需要多长时间？

一旦了解了正在迁移的数据的属性，您需要考虑影响迁移的可靠性和性能的两个关键因素：容量和网络。

区域性容量和连接到云的网络

在处理云数据迁移时，通常需要仔细考虑两个元素：区域性容量和连接到云的网络质量。

区域性容量：

云环境并非无限可扩展。事实上，硬件需要由云提供商在区域位置购买、准备和配置。一旦确定了目标架构和处理数据平台所需的资源，你还应该向选定的超大规模提供商提交一个区域容量计划，以确保数据平台将拥有满足平台使用和未来增长需求的所有所需硬件。通常，他们希望了解迁移数据的数量，以及在云中生成的数据量，您需要用来处理数据的计算量，以及与其他系统进行交互的次数。所有这些组成部分将作为输入提供给超大规模，以确保底层基础设施将从第一天开始准备好为所有工作负载提供服务。在出现缺货的情况下（如果您的用例涉及GPU，则这种情况很常见），您可能需要在其他地区选择相同的服务（如果没有合规性/技术影响），或者利用其他计算类型服务（例如，IaaS与PaaS相比）。

连接到云的网络：

即使网络现在被视为大宗商品，在每个云基础设施中仍起着至关重要的作用：如果网络速度慢或无法访问，组织的某些部分可能会完全与其业务数据断开连接（即使在利用本地环境时也是如此）。在设计云平台时，你需要首先考虑以下一些问题：我的组织将如何连接到云？我将利用哪个合作伙伴来建立连接？我是利用标准互联网连接（可能在其上使用VPN），还是想要支付额外的专用连接费用以确保更好的可靠性？所有这些主题通常都在RFI/RFP问卷中讨论，但它们也应该是与你选择设计和实施平台的供应商/合作伙伴进行的最初的研讨会之一的一部分。

连接到云的主要方式有三种：

公共互联网连接： 利用公共互联网网络。在这种情况下，组织通常在公共互联网协议之上利用VPN来保护其数据，并确保适当的可靠性水平。性能与组织能否靠近所选云超大规模的最近点有关。
合作伙伴互联： 这是组织可能用于其生产工作负载的典型连接之一，特别是当他们需要具有高吞吐量的性能保证时。这种连接是组织与选定合作伙伴之间的连接，然后该合作伙伴负责与选定的超大规模建立连接。通过利用电信服务提供商的普遍性，组织可以建立高性能的连接，而价格又适中。
直接互联： 这是可能的最佳连接，其中组织直接（物理上）与云提供商的网络连接。（当双方都在同一物理位置拥有路由器时，这是可能的。）可靠性、吞吐量和一般性能是最佳的，并且定价可以直接与所选的超大规模进行讨论。

有关如何配置这三种连接选项的更多详细信息，请参阅Azure、AWS和Google Cloud的文档。

通常在PoC/MVP阶段，选择公共互联网连接选项，因为设置速度更快。在生产中，合作伙伴互联是最常见的，特别是当组织希望利用多云方法时。

转移选项

选择将数据传输到云端的方式时，请考虑以下因素：

成本考虑数据传输可能涉及的以下潜在成本：

网络在进行数据传输之前，您可能需要提升网络连接性。也许您的带宽不足以支持迁移，您需要与供应商协商以增加额外的线路。

云服务提供商向云服务提供商上传数据通常是免费的，但如果您不仅从本地环境导出数据，还从另一个超级规模云提供商导出数据，可能会收取出口费用（通常每导出1GB收费），还可能收取读取费用。

产品您可能需要购买或租赁存储设备以加速数据传输。

人员执行迁移的团队。

时间了解您需要传输的数据量和您可用的带宽是重要的。一旦了解了这些，您将能够确定传输数据所需的时间。例如，如果您需要传输200TB的数据，而您只有10Gbps的带宽可用，您将需要大约两天的时间来完成传输。这假定带宽完全可用于数据传输，这可能并非总是如此。如果在分析过程中发现需要更多带宽，您可能需要与互联网服务提供商（ISP）合作，请求增加带宽或确定一天中带宽可用的时间。这也可能是与云供应商合作实施直连的正确时机。这可以防止您的数据通过公共互联网传输，并且可以为大规模数据传输提供更一致的吞吐量（例如，AWS Direct Connect，Azure ExpressRoute，Google Cloud Direct Interconnect）。

离线与在线传输在某些情况下，在线传输可能不可行，因为它会花费太长时间。在这种情况下，选择使用离线处理并利用存储硬件。云供应商提供这种服务（例如，Amazon Snowball数据传输，Azure Data Box，Google Transfer Appliance），特别适用于数百TB到PB级别的数据传输。您可以从云供应商那里订购一个物理设备，必须连接到您的网络。然后，您将复制数据，数据将默认加密，然后请求发货到最近可用的供应商设施。一旦交付，数据将被复制到云中的适当服务（例如，AWS S3，Azure Blob Storage，Google Cloud Storage），并且可以随时使用。

可用工具一旦清理了所有网络动态，您应该决定如何处理数据上传。根据您可能要定位的系统（例如，blob存储，DWH解决方案，数据库，第三方应用程序等），通常您可以选择以下选项：

命令行工具工具（例如，AWS CLI，Azure Cloud Shell或Google Cloud SDK）允许您与云提供商的所有服务进行交互。您可以自动化和编排上传数据到所需目的地所需的所有流程。根据最终的工具，您可能需要在上传数据到最终目的地之前通过中间系统（例如，首先通过blob存储再将数据传入DWH），但由于各种工具的灵活性，您应该能够轻松实施工作流程，例如利用bash或PowerShell脚本。

REST API 这将允许您将服务与您可能想要开发的任何应用程序集成，例如，您已经实施和利用的内部迁移工具或您可能想要为特定目的开发的全新应用程序。

物理解决方案如前述离线与在线传输的描述中所讨论的，用于离线迁移的工具。

第三方商业现成解决方案这些解决方案可能提供更多功能，如网络节流，自定义高级数据传输协议，高级编排和管理功能以及数据完整性检查。

迁移步骤

您的迁移将包括六个阶段（参见图4-3）：

上游过程被修改以供应当前的遗留数据解决方案，以满足目标环境的需求。
下游过程从遗留环境中读取的方式被修改为从目标环境中读取。
历史数据以批量方式迁移到目标环境。在这一阶段，上游过程也被迁移到写入目标环境。
下游过程现在连接到目标环境。
利用CDC（Change Data Capture）管道，在遗留环境完全被废弃之前，可以在遗留和目标环境之间保持数据同步。
下游过程变得完全操作，利用目标环境。

有一些最终检查你应该执行，以确保不会遇到瓶颈或数据传输问题：

执行功能测试。您需要执行一个测试来验证整个数据传输迁移是否正常工作。理想情况下，在执行MVP期间执行此测试，选择大量数据，充分利用可能在整个迁移过程中使用的所有工具。这一步的目标主要是验证您可以正确操作数据传输，同时发现潜在的可能导致项目停滞的问题，例如无法使用工具（例如，您的工作人员未经培训，或者您没有系统集成商的充分支持）或网络问题（例如，网络路由）。

执行性能测试。您需要验证当前基础架构是否能够处理大规模迁移。为此，您应该选择一个数据的大样本（通常在3%到5%之间）进行迁移，以确认您的迁移基础设施和解决方案是否正确根据迁移需求进行扩展，并且不会出现特定的瓶颈（例如，源存储系统速度慢）。

执行数据完整性检查。在数据迁移过程中可能遇到的最关键问题之一是，由于错误而删除了迁移到目标系统的数据，或者数据损坏且无法使用。有一些方法可以保护数据免受这种风险：

在目标位置启用版本控制和备份，以减轻意外删除的影响。

在删除源数据之前验证您的数据。

如果您使用标准工具执行迁移（例如，命令行界面或REST API），则必须自己管理所有这些活动。但是，如果您采用第三方应用程序，如Signiant Media Shuttle或IBM Aspera on Cloud，很可能已经默认实施了多种检查。（我们建议在选择解决方案之前仔细阅读应用程序说明中的可用功能。）

总结

在本章中，您已经看到了数据现代化旅程的实际方法，并审查了一个通用的技术迁移框架，可应用于从传统环境到现代云架构的任何迁移。主要要点如下：

着重于现代化数据工作流，而不仅仅是升级单个工具。选择适合特定工作的正确工具将帮助您降低成本，充分发挥工具的潜力，并提高效率。
可以在四个步骤中实施可能的数据迁移框架：准备和发现、评估和规划、执行和优化。
准备和发现是一个关键的步骤，您在其中专注于定义迁移的范围，然后收集与已确定要迁移的各种工作负载/用例相关的所有信息。
评估和规划是一个步骤，您在其中定义和计划完成已确定目标所需的所有活动（例如，对要迁移的工作负载进行分类和聚类，定义关键绩效指标，定义可能的MVP，以及定义与相关里程碑有关的迁移计划）。
执行是一个步骤，在该步骤中，您迭代执行迁移，每次迭代都改善整个过程。
优化是一个步骤，在该步骤中，您将整个新系统视为一个整体，并确定引入的可能新用例，使其更加灵活和强大。
了解当前情况以及最终解决方案的总成本是一个复杂的步骤，可能涉及多个参与者。组织通常利用RFI、RFP和RFQ从供应商/潜在合作伙伴那里获取更多信息。
治理和安全问题仍然是大多数组织的集中关注。这是因为在角色定义、数据安全和活动记录方面需要一致性。
迁移框架必须与一个非常明确定义的治理框架相一致，这对数据的整个生命周期至关重要。
在迁移数据架构时，可能有助于利用类似外观模式的模式，使目标解决方案功能的采用变得更容易。
当使用云解决方案时，连接性和保障区域容量是至关重要的。网络配置、带宽可用性、成本、人员、工具、性能和数据完整性是必须为每个工作负载澄清的主要要点。

在前面的四章中，您已经了解了为什么要构建数据平台，达到目标的策略，如何提升员工技能，以及如何进行迁移。在接下来的几章中，我们将深入探讨架构细节，首先从如何构建现代数据湖开始。

《Architecting Data and Machine Learning Platforms》第四章：迁移框架