概览：将数据仓库迁移到 BigQuery
本文档讨论了适用于任何数据仓储技术的一般概念，并介绍了可用于组织和构建 BigQuery 迁移的框架。
术语
我们在讨论数据仓库迁移时会使用以下术语：
- 使用场景
-
用例包括实现业务价值（例如跟踪某产品在一段时间内的销量）所需的所有数据集、数据处理以及系统和用户的交互。在数据仓储中，用例通常包括：
- 用于从各种数据源（例如客户关系管理 (CRM) 数据库）中提取原始数据的数据流水线。
- 存储在数据仓库中的数据。
- 用于操作以及进一步处理和分析数据的脚本和流程。
- 读取数据或与数据进行交互的业务应用。
- 工作负载
- 一组已连接且具有共同依赖项的用例。例如，用例可能具有以下关系和依赖关系：
- 购买报告可独立进行，有助于了解支出和请求折扣。
- 销售报告可独立使用，帮助计划营销活动。
- 但损益报告取决于购买和销售，帮助确定公司的价值。
- 业务应用
- 最终用户与之交互的系统，例如直观报告或信息中心。业务应用也可以采用运营数据流水线或反馈环的形式。例如，在计算或预测了产品价格变化之后，运营数据流水线可能会更新事务型数据库中的新产品价格。
- 上游过程
- 将数据加载到数据仓库中的源系统和数据流水线。
- 下游过程
- 用于处理、查询和直观呈现数据仓库中的数据的脚本、过程和业务应用。
- 分流迁移
- 一种迁移策略，旨在尽快让最终用户能够在新环境中运行用例，或者利用新环境中可用的额外容量。如需对用例进行分流，您可以执行以下操作：
- 复制并同步旧数据仓库中的架构和数据。
- 迁移下游脚本、流程和业务应用。
迁移分流会增加迁移数据流水线的复杂性和工作量。
- 完整迁移
- 一种与分流迁移类似的迁移方法，但该方法不复制和同步架构与数据，而是将数据从上游源系统直接注入到新的云数据仓库中。换句话说，此过程还会迁移用例所需的数据流水线。
- 企业数据仓库 (EDW)
- 一种数据仓库，不仅包含分析数据库，还包含多个关键分析组件和流程，例如完成组织工作负载所需的数据流水线、查询和业务应用。
- 云数据仓库 (CDW)
- 一种与 EDW 具有相同特征的数据仓库，但在云中的全托管式服务中运行，在此场景中为 BigQuery。
- 数据流水线
- 通过一系列执行各类数据转换的函数和任务连接数据系统的过程。如需了解详情，请参阅本系列中的什么是数据流水线？。
为什么要迁移到 BigQuery？
在过去的几十年中，组织已经掌握了数据仓储的知识，并逐渐提升了在大量存储数据中应用描述性分析的比例，从而深入了解其核心业务运营状况。 在过去，重点关注查询、报告和在线分析处理的传统商业智能 (BI) 或許是一个可产生差异化的因素，可能成就或者拖垮一个企业，但如今这一因素已不再具有同样的影响。
现在，组织不仅需要使用描述性分析来理解以往的事件，还需要运用到预测性分析。这些预测性分析通常使用机器学习 (ML) 提炼出数据模式并预测未来事件的概率。最终目标是开发规范分析，将过去的经验教训与对未来的预测相结合，以自动指导实时操作。
传统的数据仓库做法是从各种数据源捕获原始数据，这些数据源通常是联机事务处理 (OLTP) 系统。然后，批量提取一部分数据，基于定义的架构进行转换并将其加载到数据仓库中。由于传统数据仓库批量捕获一部分数据并基于严格的架构存储数据，因此它们不适合处理实时分析或响应自发式查询。Google 设计的 BigQuery 在某种程度上解决了这些固有的局限性。
使用和维护这些传统数据仓库的 IT 组织的规模和复杂性通常会减缓创新理念的实现。构建可扩缩、高度可用且安全的数据仓库架构可能需要花费数年时间和大量投资。BigQuery 提供了先进的软件即服务 (SaaS) 技术，可用于无服务器数据仓库运营。这使您可以专注于推进核心业务，同时将基础架构维护和平台开发委托给 Google Cloud。
借助 BigQuery，客户能够以可扩缩、灵活且经济实惠的方式访问结构化数据存储，并进行处理和分析。当数据量呈指数增长时，这些特征至关重要 - 客户可以根据需要获取存储和处理资源，并且从这些数据中获取价值。此外，对于刚涉足大数据分析和机器学习并希望避免本地大数据系统的潜在复杂性的组织，他们可以通过 BigQuery 以随用随付的方式试用托管式服务。
借助 BigQuery，您可以找到以前那些难以解决的问题的答案、应用机器学习来探索新兴的数据模式并测试新的假设。因此，您可以及时了解您业务的进展情况，以便修改流程以获得更好的结果。此外，从大数据分析中收集到的相关数据分析会丰富最终用户的体验，我们在本系列文章的后面部分会解释这点。
迁移的内容和方式：迁移框架
迁移可能是一项复杂而漫长的工作。因此，我们建议遵循一个框架，以分阶段组织和安排迁移工作：
准备和发现
在此初始阶段，重点是准备和发现。您和您的利益相关者可以借此提早发现现有用例，在开始阶段就加以关注。重要的是，您还可以围绕预期的益处展开初步分析。这些益处包括提升性能（例如，改善并发性）和降低总拥有成本 (TCO)。此阶段对于帮助您确立迁移价值至关重要。
数据仓库通常支持广泛的用例，并且具有包括从数据分析师到业务决策者在内的大量利益相关者。我们建议您让这些群体的代表参与其中，以充分了解存在哪些用例、这些用例是否表现良好，以及利益相关者是否正在计划新的用例。
发现阶段过程包括以下任务：
- 检查 BigQuery 的价值主张，并将其与旧数据仓库的价值主张进行比较。
- 执行初始 TCO 分析。
- 确定受迁移影响的用例。
- 对要迁移的基础数据集和数据流水线的特征进行建模，以确定依赖关系。
如需深入了解用例，您可以制作一个调查问卷，用于收集来自主题专家 (SME)、最终用户和利益相关者的信息。调查问卷应收集以下信息：
- 用例的目标是什么？企业价值是什么？
- 非功能性需求有哪些？数据新鲜度、并发使用等。
- 用例是否是更大工作负载的一部分？它是否取决于其他用例？
- 哪些数据集、表和架构支持用例？
- 您对馈入这些数据集的数据流水线有哪些了解？
- 当前使用了哪些 BI 工具、报告和信息中心？
- 运营需求、性能、身份验证和网络带宽的当前技术要求有哪些？
下图展示了迁移之前的旧架构概要。它说明了最终用户可以访问的可用数据源、旧数据流水线、旧运营流水线和反馈环以及旧 BI 报告和信息中心的目录。
方案
计划阶段是指收集准备和发现阶段各方的馈入，加以评估，并将其用于规划迁移。此阶段可以分为以下任务：
编写用例目录并确定优先级
我们建议您将迁移过程分解为多次迭代。 为现有用例和新用例编写目录，并指定其优先级。如需了解详情，请参阅本文档的使用迭代方法进行迁移和确定应用场景的优先级部分。
定义成功的标准
迁移之前，有必要明确定义成功的标准，例如关键绩效指标 (KPI)。您可以利用此标准在每次迭代时评估迁移是否成功，从而借此改善后续迭代中的迁移过程。
创建“完成”的定义
对于复杂的迁移，您不一定能明显看出在何时已完成指定用例的迁移。因此，您应概述预期结束状态的正式定义。此定义应足够通用，以便可以应用于要迁移的所有用例。 该定义应作为您判断用例已完整迁移的一组最低标准。该定义通常包括检查点，以确保用例已进行了集成、测试和记录。
设计并提出概念验证 (POC)、短期状态和理想结束状态
确定用例的优先顺序后，您可以开始着眼于整个迁移过程对其加以考虑。考虑将第一个用例迁移视为概念验证 (PoC)，以验证初始迁移方法。考虑作为短期状态，在最初几周至几个月内可以实现哪些目标。您的迁移计划对用户有什么样的影响？ 他们是否有一个混合解决方案，或者您是否可以先为一部分用户迁移某个完整的工作负载？
创建时间和费用估算
为了确保成功完成迁移项目，必须生成实际时间估算。为此，请与所有的利益相关者讨论他们可用于协助迁移的时间，并针对其在项目过程中的参与度取得共识。这将帮助您更加准确地估算人工成本。如需估算与预计的云资源使用相关的费用，请参阅 BigQuery 文档中的估算存储和查询费用和 BigQuery 费用控制简介。
确定并聘用迁移合作伙伴
BigQuery 文档介绍了可用于执行迁移的许多工具和资源。但是，如果您没有任何先前的经验或组织内部没有所有必需的技术专业知识，则独自执行大型、复杂的迁移可能比较困难。因此，我们建议您从一开始就确定并聘用迁移合作伙伴。如需了解详情，请参阅全球合作伙伴和咨询服务计划。
使用迭代方法进行迁移
在将大型数据仓储操作迁移到云时，最好采用迭代方法。因此，我们建议您采用迭代方法过渡到 BigQuery。将迁移工作划分为多次迭代会降低整个过程的难度，降低风险，并且在每次迭代后提供学习和改进的机会。
迭代包括在一段有限的时间内分流或完整迁移一个或多个相关应用场景所需的所有工作。您可以将迭代视为敏捷方法中的一个 sprint 周期，该周期包含一个或多个用户案例。
为了方便和易于跟踪，您可以考虑将单独的用例与一个或多个用户案例相关联。例如，请考虑以下用户故事：“作为价格分析师，我想分析过去一年中的产品价格变化，以便可以计算出未来的价格。”
相应的用例可能是：
- 从存储产品和价格的事务型数据库中提取数据。
- 将数据转换为每个产品的单个时间序列，并输入任何缺失的值。
- 将结果存储在数据仓库内的一个或多个表中。
- 通过 Python 笔记本（业务应用）提供这些结果。
该用例的业务价值是支持价格分析。
与大多数用例一样，该用例可能支持多个用户案例。
用例分流后，可能会进行后续迭代，以完整迁移该用例。否则，您可能仍依赖于现有的旧数据仓库，因为数据是从此处进行复制的。后续的完整迁移是分流与分流之前的完整迁移之间的增量 - 换句话说，是数据流水线的迁移，以提取、转换数据并将数据加载到数据仓库中。
确定用例优先顺序
您开始和结束迁移的位置取决于您的特定业务需求。 确定用例的迁移顺序非常重要，因为在迁移过程的早期取得成功对于继续采用云技术至关重要。 在早期阶段遭遇失败可能会严重阻碍整个迁移工作。您也许拥有 Google Cloud 和 BigQuery 带来的优势，但处理在旧数据仓库中为不同用例创建或管理的所有数据集和数据流水线却可能复杂而且耗时。
虽然没有一个放之四海而皆准的答案，但是在评估本地用例和业务应用时，可以使用一些最佳做法。 通过这种提前计划可以降低迁移过程的难度，并且有助于更平稳地过渡到 BigQuery。
以下部分探讨了用于确定用例优先顺序的可能方法。
方法：利用当前机会
寻找可以帮助您最大程度地提高特定用例的投资回报率的当前机会。如果您正面临证明迁移到云的业务价值的压力，则此方法尤其有用。此外，它还提供了一种收集其他数据点的机会，以帮助评估总体迁移费用。
下面是一些要询问的示例问题，可帮助您确定哪些用例需要优先考虑：
- 用例是否包括当前受旧版企业数据仓库限制的数据集或数据流水线？
- 您的现有企业数据仓库是否需要硬件更新，或者您是否打算扩充硬件？如果是，那么尽早将用例分流到 BigQuery 可能会更有吸引力。
发现迁移机会可以快速见效，为用户和企业带来切实的直接利益。
方法：首先迁移分析工作负载
请先迁移联机分析处理 (OLAP) 工作负载，再迁移联机事务处理 (OLTP) 工作负载。在组织中，通常只有在数据仓库才能找到用于创建组织运营的单个全局视图的所有数据。因此，组织通常具有一些反馈给事务系统以更新状态或触发流程的数据流水线，例如在产品库存不足时购买更多存货。与 OLAP 工作负载相比，OLTP 工作负载往往更加复杂并且具有更加严格的操作要求和服务等级协议 (SLA)，因此，先迁移 OLAP 工作负载也往往更加容易。
方法：以用户体验为中心
通过迁移特定的数据集并启用新类型的高级分析来发现增强用户体验的机会。例如，一种增强用户体验的方法是使用实时分析。当该方法与历史数据相结合后，您可以围绕实时数据流构建复杂的用户体验。例如：
- 一个后台员工通过移动应用收到低库存提醒。
- 一个在线客户可能会得知再花一美元就会升到下一个奖励等级。
- 一个护士通过患者的智能手表获得其生命体征的提醒，从而能够通过在平板电脑上提取患者的治疗记录以采取最佳治疗方案。
您还可以通过预测性分析和规范分析来增强用户体验。为此，您可以使用 BigQuery ML、Vertex AI AutoML 表格或 Google 的预训练模型进行图像分析、视频分析、语音识别、自然语言分析和翻译。 或者，您可以将 Vertex AI 用于根据您的业务需求量身定制的应用场景，从而提供自定义训练的模型。这可能涉及以下内容：
- 根据市场趋势和用户购买行为推荐产品。
- 预测航班延误。
- 检测欺诈活动。
- 标记不当内容。
- 其他可以使您的应用脱颖而出的创新理念。
方法：优先考虑风险最低的用例
IT 可能会提出许多问题，以帮助评估哪些用例具有最低迁移风险，从而使这些用例在迁移的早期阶段最具迁移吸引力。例如：
- 该用例的业务关键性是什么？
- 是否有大量员工或客户依赖于该用例？
- 用例的目标环境是什么（例如开发或生产）？
- 我们 IT 团队对用例有哪些理解？
- 用例具有多少依赖项和集成？
- 我们的 IT 团队是否具有关于用例的适当、最新、完整的文档？
- 用例的运营要求 (SLA) 有哪些？
- 用例的法律或政府合规要求有哪些？
- 访问底层数据集的停机时间和延迟时间敏感度如何？
- 是否有业务线所有者渴望并愿意尽早迁移其用例？
浏览此问题列表可帮助您将数据集和数据流水线从最低风险到最高风险进行排名。应首先迁移低风险资源，然后迁移高风险资源。
执行
在收集了有关旧系统的信息并且创建了用例的优先待办事项之后，您可以将用例划分为各工作负载组，然后采用迭代方法继续进行迁移。
一次迭代可以包含单个用例、几个单独的用例或属于单个工作负载的多个用例。您在其中为迭代选择哪些选项取决于用例的互连、任何共享依赖项以及您可用于该工作的资源。
迁移通常包括以下步骤：
以下各部分对这些步骤进行了更详细的说明。 您可能不需要在每次迭代中都经历所有这些步骤。例如，在某次迭代中，您可能决定侧重于将一些数据从旧数据仓库复制到 BigQuery。相反，在后续的迭代中，您可能侧重于修改从原始数据源直接到 BigQuery 的提取流水线。
1. 设置和数据治理
设置是用例在 Google Cloud 上运行所必需的基础工作。设置可以包括配置 Google Cloud 项目、网络、Virtual Private Cloud (VPC) 和数据治理。它还包括详细了解您现在的状态（哪些是有用的，哪些是无用的）。这可帮助您了解迁移工作的要求。您可以使用 BigQuery 迁移评估功能来帮助您完成此步骤。
数据治理是在数据生命周期（从获取、使用到处置）内对其进行管理的原则性方法。您的数据治理计划明确概括了围绕数据活动的政策、流程、职责和控制。该计划有助于确保信息的收集、维护、使用和传播均满足组织数据完整性和安全性需求。此外，它还有助于员工发现并充分利用数据。
数据治理文档可帮助您了解在将本地数据仓库迁移到 BigQuery 时所需的数据治理和控制。
2. 迁移架构和数据
数据仓库架构定义了数据的结构，并且定义了数据实体之间的关系。架构是数据设计的核心，会影响许多上游和下游的过程。
架构和数据转移文档提供了有关如何将数据移动到 BigQuery 的大量信息，以及有关更新架构以充分利用 BigQuery 功能的建议。
3. 转换查询
使用批量 SQL 转换来批量迁移 SQL 代码，或使用交互式 SQL 转换来转换临时查询。
一些旧式数据仓库包含 SQL 标准扩展，用于启用其产品相应的功能。BigQuery 则不支持这些专用扩展，而是遵循 ANSI/ISO SQL:2011 标准。这意味着，如果 SQL 转换器无法解释某些查询，则它们可能仍需要手动重构。
4. 迁移业务应用
业务应用可以采用多种形式：从信息中心到自定义应用，再到向事务系统提供反馈环的运营数据流水线。
如需详细了解使用 BigQuery 时可使用的分析选项，请参阅 BigQuery 分析概览。本主题简要介绍可用于从数据中获得令人信服的数据分析的报告和分析工具。
数据流水线文档中有关反馈环的部分介绍了如何使用数据流水线创建反馈环来预配上游系统。
5. 迁移数据流水线
数据流水线文档介绍了将旧版数据流水线迁移到 Google Cloud 的过程、模式和技术。该文档可帮助您了解什么是数据流水线、它可以采用哪些流程和模式，以及大型数据仓库迁移可使用哪些迁移选项和技术。
6. 优化性能
BigQuery 可同样有效地处理小型和 PB 级数据集的数据。借助 BigQuery，您应该可以顺利地执行数据分析作业，而无需在新迁移的数据仓库中进行修改。如果您发现在某些情况下查询性能不符合您的预期，请参阅优化查询性能简介以获取指导。
7. 验证和确认
在每次迭代结束时，通过验证是否已满足以下条件来验证用例迁移是否成功：
- 已完整迁移数据和架构。
- 已完全解决和测试数据治理问题。
- 已建立维护和监控的流程和自动化作业。
- 已正确转换查询。
- 迁移的数据流水线可按预期运行。
- 已正确配置业务应用以访问迁移的数据和查询。
您可以从数据验证工具开始，该工具是一个开源 Python CLI 工具，用于比较来自源环境和目标环境的数据以确保它们匹配。它支持多种连接类型以及多级验证功能。
您还可以衡量用例迁移在提高性能、降低费用、创造新的技术或业务机会等方面的影响。然后，您可以更准确地量化投资回报的价值，并将该价值与迭代的成功标准进行比较。
验证迭代之后，您可以将已迁移的用例发布到生产环境中，并为您的用户提供对已迁移数据集和业务应用的访问权限。
最后，做笔记并记录从此次迭代中学到的经验教训，以便能够在下一次迭代中应用这些经验教训并加速迁移。
总结迁移工作
如本文档中所述，在迁移期间，您既可以运行旧式数据仓库，也可以运行 BigQuery。下图中的参考架构突出显示了这两种数据仓库提供相似的功能和路径 - 两者都能从源系统中提取数据、与业务应用集成以及提供所需的用户访问权限。重要的是，该图还突出显示了数据已从数据仓库同步到 BigQuery。这样可以实现在整个迁移工作过程中对用例进行分流。
假设您打算从数据仓库完整迁移到 BigQuery，则迁移的结束状态如下所示：
后续步骤
详细了解迁移数据仓库的以下步骤：
您还可以了解如何从特定数据仓库技术迁移到 BigQuery：