数据和机器学习平台架构指南-全-

数据和机器学习平台架构指南（全）

原文：zh.annas-archive.org/md5/792a4241c7cfa5106b8e17d358f63c34

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

什么是数据平台？为什么你需要它？建立数据和机器学习（ML）平台涉及什么？为什么你应该在云上构建你的数据平台？本书从回答这些在处理数据和 ML 项目时常见的问题开始。然后我们提出了我们建议你在业务中建立数据和 ML 能力的战略旅程，向你展示如何执行每个步骤的策略，并将所有概念包装在一个现代化数据改造案例中。

为什么你需要云数据平台？

假设你公司的首席技术官（CTO）想要建立一个新的手机友好的电子商务网站。“我们正在失去业务”，他声称，“因为我们的网站没有针对移动设备进行优化，尤其是在亚洲语言上。”

首席执行官（CEO）相信首席技术官（CTO）说当前网站的移动用户体验并不好，但她想知道通过手机访问平台的客户是否构成人口的一个有利可图的部分。她打电话给亚洲运营主管，并问：“通过手机访问我们电子商务网站的客户的收入和利润率是多少？如果我们增加在移动设备上进行购买的人数，我们的总收入将如何在接下来的一年内变化？”

亚洲地区领导者如何回答这个问题？这需要能够关联客户访问（以确定 HTTP 请求的来源）、客户购买（以了解他们购买了什么）和采购信息（以确定这些物品的成本）。这还需要能够预测市场不同部分的增长。区域领导者是否需要联系信息技术（IT）部门，并要求他们从所有这些不同来源汇集必要的信息，并编写一个程序来计算这些统计数据？IT 部门是否有足够的带宽来回答这个问题，并具备进行预测分析的技能？

如果组织拥有一个数据平台会好多少？在这种情况下，所有数据都已经被收集和清理，并且可以在整个组织中进行分析和综合。数据分析团队可以简单地运行交互式的特定查询。他们还可以利用内置的人工智能（AI）能力轻松地创建或检索收入和流量模式的预测，并允许基于数据驱动的决策来回应 CTO 投资于新的手机友好网站的请求。

回答 CEO 问题的一个可能方法是采购和部署真实用户监控（RUM）工具。有很多专门的工具可供选择，比如这种单一决策。拥有数据平台使组织能够回答许多这类单一问题，而无需采购和安装这些特定的解决方案。

现代组织越来越希望基于数据做出决策。我们的例子集中在一次性决策上。然而，在许多情况下，组织希望重复地、自动化地做出决策，例如，组织可能希望确定购物车是否有被放弃的危险，并立即向客户显示可以添加到购物车以达到免费运输最低限额的低成本商品选项。这些商品应该吸引个体购物者，因此需要强大的分析和 ML 能力。

为了基于数据做出决策，组织需要一个数据和 ML 平台，简化以下几点：

• 获取数据访问权限

• 运行交互式的即席查询

• 创建报告

• 基于数据做出自动化决策

• 业务服务的个性化

正如你将在本书中看到的，基于云的数据平台降低了所有这些功能的技术门槛：可以从任何地方访问数据，甚至在边缘设备上进行快速的大规模查询，并利用提供许多分析和 AI 能力的服务。然而，能够部署实现所有这些构建块有时可能是一段复杂的旅程。本书的目标是帮助读者更好地理解建立现代云数据平台所需的主要概念、架构模式和工具，以便他们可以更好地监控和控制企业数据，从而做出更有意义和自动化的业务决策。

我们，本书的作者，是具有多年经验的工程师，帮助各行各业的企业在各种地理位置建立数据和 ML 平台。这些企业希望从他们的数据中获取洞察，但通常面临许多挑战，即如何以可以快速分析的形式获取所有所需的数据。因此，他们发现自己不得不构建现代数据和 ML 平台。

本书适合谁？

本书适合希望通过使用公共云技术创建数据和 ML 平台来支持业务数据驱动决策的架构师。数据工程师、数据分析师、数据科学家和 ML 工程师将发现本书对于获取系统的概念设计视角是有用的。

数字原生公司已经做了几年了。

早在 2016 年，Twitter 解释称，他们的数据平台团队维护着“用于支持和管理多种业务目的的数据生产和消费系统，包括公开报告的指标、推荐、A/B 测试、广告定位等。” 到 2016 年，这涉及维护全球最大的 Hadoop 集群之一。到 2019 年，这一情况正在改变，包括支持使用云原生数据仓库解决方案。

以 Etsy 为例，他们说他们的 ML 平台“通过开发和维护 Etsy 的 ML 从业者依赖的技术基础设施来支持 ML 实验”。

Twitter 和 Etsy 都建立了现代化的数据和 ML 平台。这两家公司的平台是不同的，以支持平台需要支持的不同类型的数据、人员和业务用例，但其基本方法是相似的。在本书中，我们将向您展示如何设计一个能够让您业务中的工程师使用的现代化数据和 ML 平台的架构：

• 从各种来源收集数据，例如操作数据库、客户点击流、物联网（IoT）设备、软件即服务（SaaS）应用等。

• 打破组织内不同部门之间的孤立。

• 处理数据时，在加载数据后或正在摄取数据时，需确保数据质量和治理的适当流程。

• 定期或临时分析数据。

• 使用预建的 AI 模型丰富数据。

• 构建 ML 模型进行预测分析。

• 定期或响应触发事件或阈值对数据采取行动。

• 传播洞见并嵌入分析。

如果您在企业中处理数据和 ML 模型，这本书对于引导您在由您的数据或 ML 平台团队构建的平台上进行工作具有架构考虑是一个很好的介绍。因此，如果您是数据工程师、数据分析师、数据科学家或 ML 工程师，您将发现本书有助于获取高层次的系统设计视图。

即使我们主要在 Google Cloud 上有经验，我们努力保持对构建架构的云不可知服务的愿景，引入但不限于来自三大云提供商（即 Amazon Web Services [AWS]、Microsoft Azure 和 Google Cloud）的例子。

本书的组织结构

本书分为 12 章，这些章节对应于通过数据创新的战略步骤，将在第二章中详细解释。本书最后还展示了一个模型用例场景，展示了组织可能如何进行现代化之旅。

书籍流程的视觉表达见图 P-1。

第一章讨论了组织应该建立数据平台的原因。它还涵盖了数据平台中的方法、技术趋势和核心原则。

在第 2 和 3 章中，我们深入探讨如何规划旅程，识别创新的战略步骤以及如何实现变革。在这里，我们将讨论诸如降低总体拥有成本（TCO）、消除数据孤岛以及如何利用 AI 解锁创新等概念。我们还分析数据生命周期的构建模块，讨论如何设计您的数据团队，并推荐采用计划。在第 Chapter 4 中，我们将这些整合为迁移框架。

图 P-1. 书籍流程图

在第 5、6 和 7 章中，我们讨论了数据平台的三种常见架构 — 数据湖（第五章）、数据仓库（第六章）和湖仓（第七章）。我们展示了湖仓可以从数据湖或数据仓库逐步发展到这种架构的两种方式，并讨论如何在这两条道路之间进行选择。

在第 8 和 9 章中，我们讨论基本湖仓模式的两种常见扩展。我们展示如何通过引入流模式在上下文中更快地实时做出决策，以及如何通过扩展到边缘来支持混合架构。

第 10 和 11 章涵盖如何在企业环境中构建和使用 AI/ML，以及如何设计架构来设计、构建、提供和编排创新模型。这些章节包括预测性 ML 模型和生成性 ML 模型。

最后，在第 Chapter 12 中，我们将关注模型数据现代化案例旅程，重点介绍如何从传统架构迁移到新架构，解释组织如何选择特定解决方案的过程。

如果您是一名云架构师，负责为您的业务构建数据和 ML 平台，请按顺序阅读本书的所有章节。

如果您是一名数据分析师，负责创建报告、仪表板和嵌入式分析，请阅读第 1、4 至 7 章，并阅读第十章。

如果您是构建数据流水线的数据工程师，请阅读第五章至第九章。浏览剩余章节，并在需要特定类型应用时将其作为参考。

如果您是负责构建机器学习模型的数据科学家，请阅读第七章、第八章、第十章和第十一章。

如果您是对将机器学习模型操作化感兴趣的机器学习工程师，请快速浏览第一章至第九章，并仔细研读第十章和第十一章。

本书使用的约定

本书使用以下印刷约定：

斜体

表示新术语、网址、电子邮件地址、文件名和文件扩展名。

等宽字体

用于程序列表以及段落内引用程序元素（如变量或函数名、数据库、数据类型、环境变量、语句和关键字）。

注意

此元素表示一般提示或提示。

致谢

写这样一本书是有回报的，因为你不仅在分享知识，还在分享经验的成果，而这些经验是在与许多人一起战斗中获得的。写这本书让我们想起了所有那些我们有幸与之共事、学习和庆祝的人们。要想不违反保密条款地提到每一个人是不可能的，所以我们只想向数据分析、数据工程和数据科学社区致以最诚挚的感谢。

我们深表感谢我们了不起的技术审稿人员——Sami Akbay，Mike Dahlin，Kevin George，Jonathan Gerhard，Noah Gift，Sanjay Ramchandani，Joseph Reis 和 Vicki Reyzelman——对草稿手稿进行审阅，并为我们提供宝贵的反馈和建议。

O’Reilly 是技术书籍的首选出版商，我们团队的专业素养证明了这一点。Megan Laddusaw 在创建引人入胜的大纲过程中给予了我们指导。Virginia Wilson 和 Melissa Potter 勤奋地管理整个内容的开发。Gregory Hyman 在打造精彩的最终手稿产品过程中给予了我们支持，甚至在所有图表设计中帮助了我们。感谢你们的所有帮助！

Marco: 我要感谢我的美丽妻子 Lara Maria Gessica，她是我的指路明灯，在整个旅程中一直给予我极大的支持。还要感谢我的可爱儿子 Walter 和 Nicholas，他们让我的生活每一天都变得美好而令人难以置信。

Lak: 非常感谢 Abirami 给予我的 25 年爱与陪伴。抗议现在已经变得有点稀薄了，但我会尽量不让空巢导致更多的写作承诺！

Firat**: 我把这本书献给了继续塑造我的生活并使一切成为可能的三位女士。献给我的女儿 Evre，因为她的好奇心和快乐。献给我的妻子 Yontem，因为她的坚韧不拔。以及献给我的母亲 Emine Ayla，因为她对我的信念和自信从未间断。

我们三人将这本书的所有版税捐赠给Girls Who Code，这个组织的使命是培养未来的女性工程师人才。数据在商业的许多方面变得越来越核心，这就使得建设数据的工作力量变得多样化和包容性更为重要。

第一章：现代化您的数据平台：简介概述

数据是一项宝贵的资产，可以帮助您的公司做出更好的决策，发现新的机会并改善运营。2013 年，谷歌进行了一项战略性项目，通过提高经理质量来增加员工保留率。甚至像管理技能这样宽泛的事物也可以以数据驱动的方式进行研究。谷歌通过分析 1 万份绩效评审，识别高绩效经理的共同行为，并创建培训计划，将管理偏好从 83%提高到 88%。亚马逊也进行了一项战略性数据项目，实施了基于客户行为的推荐系统，该系统在 2017 年驱动了 35%的购买。旧金山勇士篮球队是另一个例子；他们实施了一个分析程序，帮助他们在联盟中跻身顶级。所有这些——员工保留、产品推荐、提高胜率——都是通过现代数据分析实现的商业目标。

要成为一家数据驱动型公司，您需要建立一个数据分析、处理和洞察生态系统。这是因为有许多不同类型的应用程序（网站、仪表板、移动应用、机器学习模型、分布式设备等）会生成和消耗数据。您公司内部也有许多不同部门（财务、销售、营销、运营、物流等），它们需要数据驱动的洞察。由于整个公司都是您的客户群体，构建数据平台不仅仅是一个 IT 项目。

本章介绍了数据平台、其需求以及传统数据架构为何不足以满足要求。它还讨论了数据分析和人工智能的技术趋势，以及如何利用公共云构建未来的数据平台。本章概述了本书其余部分详细讨论的核心主题。

数据生命周期

数据平台的目的是支持组织从原始数据到见解信息所需的步骤。了解数据生命周期的步骤（收集、存储、处理、可视化、激活）是有帮助的，因为它们几乎可以直接映射到数据架构，从而创建一个统一的分析平台。

智慧之旅

数据帮助公司开发更智能的产品，接触更多客户，并增加他们的投资回报率（ROI）。数据还可以用于衡量客户满意度、盈利能力和成本。但是单靠数据本身是不够的。数据是原材料，需要经过一系列阶段才能用于生成洞见和知识。这一系列阶段就是我们所说的数据生命周期。文献中有许多不同的定义，但从一般的角度来看，我们可以确定现代数据平台架构中的五个主要阶段：

1. 收集

数据必须被获取并注入到目标系统中（例如，手动数据输入、批量加载、流式摄取等）。

2. 存储

数据需要以持久的方式存储，并且能够在将来轻松访问（例如，文件存储系统、数据库）。

3. 处理/转换

数据必须经过处理以使其对后续步骤有用（例如，清洗、整理、转换）。

4. 分析/可视化

需要研究数据，通过手动详细描述（例如，查询、切片和切块）或自动处理（例如，使用 ML 应用程序接口进行增强）来推导业务洞见。

5. 激活

将数据洞见表现在一种形式和位置上，以便做出决策（例如，通知作为特定手动操作的触发器、在满足特定条件时执行自动作业、ML 模型向设备发送反馈）。

每个阶段都与下一个阶段相互关联，类似于水通过一组管道的流动。

水管类比

要更好地理解数据生命周期，可以将其视为简化的水管系统。水从水道开始，然后通过一系列管道进行转移和转换，直到到达一组房屋。数据生命周期类似，数据在被收集、存储、处理/转换和分析之前，需经历这些阶段，然后才能用于决策（见图 1-1）。

图 1-1. 水循环，为数据生命周期中的五个步骤提供类比。

你可以看到管道世界与数据世界之间的一些相似之处。管道工程师就像数据工程师，他们设计并建造使数据可用的系统。分析水样本的人就像数据分析师和数据科学家，他们分析数据以找到洞见。当然，这只是一个简化。公司中有许多其他使用数据的角色，如高管、开发人员、业务用户和安全管理员。但是这种类比可以帮助你记住主要的概念。

在经典的数据生命周期中，如图 1-2 所示，数据工程师会在分析存储中收集和存储数据。然后使用各种工具处理存储的数据。如果工具涉及编程，处理通常由数据工程师完成。如果工具是声明性的，处理通常由数据分析师完成。处理后的数据然后由业务用户和数据科学家进行分析。业务用户利用这些洞察力做出决策，例如推出营销活动或发放退款。数据科学家利用数据训练机器学习模型，这些模型可以用于自动化任务或进行预测。

图 1-2. 简化数据生命周期

现实世界可能与前述现代数据平台架构和角色应如何工作的理想化描述不同。阶段可能会合并（例如存储和处理）或重新排序（例如处理在存储之前，如 ETL [抽取-转换-加载]，而不是存储在处理之前，如 ELT [抽取-加载-转换]）。然而，这些变化有其权衡之处。例如，将存储和处理合并为单个阶段会导致耦合，从而导致资源浪费（如果数据大小增长，您将需要扩展存储和计算）和可扩展性问题（如果您的基础设施无法处理额外负载，您将受阻）。

现在我们已经定义了数据生命周期并总结了数据从原始数据收集到激活的各个阶段的旅程，让我们依次过一遍数据生命周期的五个阶段。

收集

设计过程中的第一步是摄取。摄取是将数据从源头（可以是任何地方，例如本地、设备、另一个云等）传输到目标系统的过程，在目标系统中可以进一步进行分析。这是考虑大数据的 3V 的第一个机会：

体积

数据的大小是多少？通常在处理大数据时，这意味着数据量是以 TB（terabyte）或 PB（petabyte）为单位。

速度

数据进入的速度是多少？一般来说，这是以 MB/秒（megabyte/second）或 TB/天（terabyte/day）计算的。这通常被称为吞吐量。

多样性

数据的格式是什么？表格、扁平文件、图像、声音、文本等等。

确定要收集的数据类型（结构化、半结构化、非结构化）、格式和生成频率（连续或特定间隔）。根据数据的速度和数据平台处理结果的体积和多样性的能力，选择批处理摄取、流式摄取或两者混合。

由于组织的不同部分可能对不同的数据源感兴趣，请设计此阶段尽可能灵活。有几种商业和开源解决方案可供选择，每种解决方案都专门用于前面提到的特定数据类型/方法。您的数据平台将需要全面支持所需的所有数据摄入平台所需的各种数据量、速度和多样性。您可以使用简单的工具定期在文件传输协议（FTP）服务器之间传输文件，或者您可以使用复杂的系统，甚至在地理上分布，实时从物联网设备收集数据。

存储

在此步骤中，存储您在上一步中收集的原始数据。您不改变数据，只是存储它。这很重要，因为您可能希望以不同的方式重新处理数据，而您需要原始数据来完成这一操作。

数据有许多不同的形式和大小。存储数据的方式将取决于您的技术和商业需求。一些常见的选项包括对象存储系统、关系数据库管理系统（RDBMS）、数据仓库（DWH）和数据湖。您的选择在某种程度上将受到底层硬件、软件和工件是否能够满足您所需的可扩展性、成本、可用性、耐久性和开放性需求的驱动。

可扩展性

可扩展性是以一种能够处理增加需求的方式进行增长和管理的能力。实现可扩展性有两种主要方式：

垂直扩展

这涉及向同一节点添加额外的扩展单元，以增加存储系统的容量。

水平扩展

这涉及添加一个或多个附加节点，而不是向单个节点添加新的扩展单元。这种分布式存储类型管理更复杂，但可以实现更好的性能和效率。

极为重要的是，底层系统能够应对现代解决方案所需的体积和速度，这些解决方案必须在数据不断增长且性质从批处理向实时转变的环境中运行：我们生活在一个大多数人持续生成并要求访问信息的世界，他们利用智能设备；组织需要能够为其用户（内部和外部）提供能够对各种请求提供实时响应的解决方案。

性能与成本比较

确定您需要管理的不同类型的数据，并根据数据的业务重要性、访问频率以及数据使用者期望的延迟类型创建一个层次结构。

将最重要和最频繁访问的数据（热数据）存储在高性能存储系统中，例如数据仓库的原生存储。将较不重要的数据（冷数据）存储在成本较低的存储系统中，例如云存储（本身有多个层级）。如果需要更高的性能，例如用于交互式使用情景，可以使用缓存技术将热数据的有意义部分加载到易失性存储层。

高可用性

高可用性 意味着在请求时能够操作并提供对数据的访问。通常通过硬件冗余来应对可能的物理故障/停机。在云中，通过在至少三个可用区存储数据来实现。这些区域可能不是物理上分离的（即它们可能位于同一“校园”），但通常会有不同的电源来源等。硬件冗余通常被称为系统的正常运行时间，现代系统通常提供四个 9 或更多的运行时间保证。

耐久性

耐久性 是指在长期存储数据时不会出现数据降解、损坏或直接丢失的能力。通常通过在物理上分离的多个位置存储数据的多个副本来实现。在云中，通过在至少两个区域（例如伦敦和法兰克福）存储数据来实现数据冗余。这在面对自然灾害时非常重要：如果底层存储系统具有较高的耐久性（现代系统通常提供 11 个 9），则除非发生灾难性事件，否则所有数据都可以毫无问题地恢复，即使物理上分离的数据中心也可以。

开放性

尽可能使用非专有格式，并避免出现锁定情况。理想情况下，应能够使用多种处理引擎查询数据，而无需生成数据副本或将其从一个系统移动到另一个系统。尽管如此，使用具有专有或原生存储格式的系统也是可以接受的，只要它们提供简单的导出功能。

和大多数技术决策一样，开放性是一种权衡，专有技术的投资回报率可能足够高，以至于您愿意承担封闭式技术的代价。毕竟，选择云的一个原因是降低运营成本——在完全托管/无服务器系统中，这些成本优势往往比托管开源系统更高。例如，如果您的数据使用情况需要事务处理，使用类似于 Parquet 的准开放存储格式 Delta Lake 的 Databricks 可能比 Amazon EMR 或 Google Dataproc（分别在 S3 或 Google Cloud Storage [GCS]上存储数据的标准 Parquet）具有更低的运营成本——Databricks 在 Delta Lake 中提供的 ACID（原子性、一致性、隔离性、持久性）事务在 EMR 或 Dataproc 上实现和维护成本昂贵。如果您需要迁移离开 Databricks，可以将数据导出为标准 Parquet 格式。单纯的开放性并不是拒绝更适合的技术的理由。

过程/转换

这就是魔力发生的地方：原始数据被转换为进一步分析所需的有用信息。这是数据工程师构建数据管道的阶段，以使数据以有意义的方式对非技术用户可访问。这一阶段包括准备数据进行分析和使用的活动。数据集成涉及将来自多个源的数据合并为单一视图。可能需要进行数据清洗以删除数据中的重复项和错误。更广义上，数据整理、处理和转换是为了将数据组织成标准格式而进行的活动。

有几种框架可供选择，每种框架都有自己的功能，这些功能取决于您在上一步选择的存储方法。总的来说，允许您使用纯 SQL 命令查询和转换数据的引擎（例如 AWS Athena、Google BigQuery、Azure DWH 和 Snowflake）是最高效、成本效益最好，¹ 也是最易于使用的。然而，与基于现代编程语言（通常是 Java、Scala 或 Python）的引擎相比，它们提供的功能有限（例如在 Amazon EMR、Google Cloud Dataproc/Dataflow、Azure HDInsight 和 Databricks 上运行的 Apache Spark、Apache Flink 或 Apache Beam）。基于代码的数据处理引擎不仅可以实现更复杂的批处理和实时转换以及机器学习，还可以利用其他重要功能，例如适当的单元测试和集成测试。

在选择适当的引擎时，另一个考虑因素是组织中通常更普遍的 SQL 技能而不是编程技能。在组织内建立数据文化的程度越高，您就越应该倾向于使用 SQL 进行数据处理。如果处理步骤（如数据清洗或转换）需要领域知识，这尤为重要。

这个阶段可能还会采用数据虚拟化解决方案，该解决方案将多个数据源和相关逻辑抽象出来，以便直接提供给最终用户进行分析。我们不会在本书中进一步讨论虚拟化，因为它往往是建立一个完全灵活平台的过渡性解决方案。关于数据虚拟化的更多信息，请参阅 Sandeep Uttamchandani（O'Reilly）的书籍《The Self-Service Data Roadmap》第十章。

分析/可视化

一旦你到达这个阶段，数据最终开始有了自身的价值——你可以把它视为信息。用户可以利用多种工具深入挖掘数据内容，提取有用的见解，识别当前的趋势，并预测新的结果。在这个阶段，可视化工具和技术发挥着重要作用，允许用户以图形方式表示信息和数据（例如图表、图形、地图、热力图等），因为它们提供了一种简单的方式来发现和评估趋势、异常值、模式和行为。

数据的可视化和分析可以由多种类型的用户执行。一方面是对理解业务数据感兴趣并希望利用图形工具执行常见分析（如切片和切块汇总和假设分析）的人。另一方面，可能有更高级的用户（“权力用户”），他们希望利用 SQL 等查询语言执行更精细和定制的分析。此外，可能还有数据科学家，他们可以利用 ML 技术实施从数据中提取有意义见解、发现模式和相关性、改进客户理解和定位，并最终增加企业的收入、增长和市场地位。

激活

这一步是最终用户能够基于数据分析和 ML 预测做出决策的阶段，从提取或预测的见解中，现在是采取一些行动的时候了。

可执行的行动可以分为三类：

自动操作

自动化系统可以利用推荐系统的结果向客户提供定制建议。这可以通过增加销售来帮助企业的收入。

SaaS 集成

通过与第三方服务集成来执行操作。例如，一家公司可能实施市场营销活动，试图减少客户流失。他们可以分析数据并实施倾向模型，以识别可能对新商业提议积极响应的客户。然后，客户电子邮件地址列表可以自动发送给营销工具以启动活动。

警报

您可以创建实时监控数据并在满足特定条件时发送个性化消息的应用程序。例如，当商品列表页的流量超过某个阈值时，定价团队可以收到主动通知，从而可以检查商品的定价是否正确。

这三种情况的技术堆栈是不同的。对于自动化操作，“训练”ML 模型通常通过调度端到端的 ML 管道定期进行（这将在第十一章中介绍）。预测本身通过调用部署为 Web 服务的 ML 模型实现，使用像 AWS SageMaker、Google Cloud Vertex AI 或 Azure Machine Learning 这样的工具。SaaS 集成通常在功能特定的工作流工具的背景下进行，这些工具允许人员控制检索信息的方式、信息如何转换以及激活信息的方式。此外，利用大型语言模型（LLMs）及其生成能力（我们将在第十章中深入探讨这些概念）可以通过与核心系统紧密集成来帮助自动化重复任务。通过像 Apache Airflow 这样的编排工具、像 Google Eventarc 这样的事件系统或像 AWS Lambda 这样的无服务器函数实现警报。

在本节中，我们已经看到现代数据平台需要支持的活动。接下来，让我们研究实施分析和 AI 平台的传统方法，以更好地理解技术的发展以及为什么云方法可以产生重大差异。

传统方法的局限性

传统上，组织的数据生态系统由用于提供不同数据服务的独立解决方案组成。不幸的是，这种特定任务的数据存储，有时可能会扩展到重要规模，可能会导致组织内部的信息孤岛的创建。结果产生的信息孤岛系统作为独立解决方案运行，而不是以高效的方式协同工作。信息孤岛数据就是被沉默的数据 ——从中难以提取见解的数据。要扩展和统一企业智能，安全地跨业务部门共享数据至关重要。

如果大多数解决方案都是定制化构建的，那么处理可扩展性、业务连续性和灾难恢复（DR）就会变得困难。如果组织的每个部分选择在不同的环境中构建其解决方案，复杂性就会变得令人不堪重负。在这种情况下，很难确保隐私或审计数据的变更。

其中一个解决方案是开发一个统一的数据平台，更确切地说是一个云数据平台（请注意，统一并不一定意味着集中化，稍后将会讨论）。数据平台的目的是允许在一个组织的所有数据上以一致、可扩展和可靠的方式进行分析和机器学习。在此过程中，您应尽可能充分利用托管服务，以便组织能够专注于业务需求而不是运营基础设施。基础设施的运维应完全委托给底层的云平台。在本书中，我们将探讨开发统一平台时需要做出的核心决策，以在可扩展和可靠的环境中整合业务单元之间的数据。

反模式：通过 ETL 打破孤岛

对于组织来说，很难对其数据拥有统一的视图，因为它们倾向于使用多种解决方案进行管理。组织通常通过使用数据移动工具来解决这个问题。ETL 应用程序允许在不同系统之间转换和传输数据，以创建一个数据的单一真实来源。然而，依赖 ETL 存在问题，在现代平台上有更好的解决方案。

ETL 工具通常被设计用来定期从事务性数据库中提取最新的交易数据，并将其存储在分析存储中，以便仪表板访问。这些数据会被标准化处理。为了能够在不每次都访问源系统的情况下进行分析，每个需要进行分析的数据库表都会创建相应的 ETL 工具（见图 1-3）。

图 1-3. ETL 工具可以帮助打破数据孤岛

跨组织捕获所有数据的中心分析存储库，根据使用的技术，被称为DWH或数据湖。这两种方法之间的高级区别基于数据存储在系统内的方式：如果分析存储支持 SQL 并包含经过管理和质量控制的数据，则称为DWH。如果支持 Apache 生态系统工具（如 Apache Spark）并包含原始数据，则称为数据湖。用于指代介于这两种方法之间的分析存储（如管理的原始数据或未管理的质量控制数据）的术语因组织而异——有些组织称之为数据湖，而其他组织称之为 DWH。正如本书后面将会看到的，这种混淆的词汇不是问题，因为数据湖（第五章）和 DWH（第六章）的方法正在融合为所谓的数据湖仓（第七章）。

依赖数据移动工具尝试构建数据一致视图有一些缺点：

数据质量

ETL 工具通常由数据消费者编写，他们往往不如数据所有者理解数据。这意味着经常提取的数据并不是正确的数据。

延迟

ETL 工具引入延迟。例如，如果 ETL 工具每小时运行一次以提取最近的交易，并且运行需要 15 分钟，那么分析存储中的数据可能会滞后多达 75 分钟。通过流式 ETL 可以解决这个问题，其中事件在发生时即被处理。

瓶颈

ETL 工具通常需要编程技能。因此，组织设立定制数据工程团队来为 ETL 编写代码。随着组织内数据的多样性增加，需要编写的 ETL 工具数量不断增加。数据工程团队成为组织利用数据能力的瓶颈。

维护

系统管理员需要定期运行和排除 ETL 工具的故障。底层基础设施系统需要持续更新以应对增加的计算和存储容量，并保证可靠性。

变更管理

输入表模式的更改需要更改 ETL 工具的提取代码。这要么使得更改难以实现，要么导致 ETL 工具被上游更改破坏。

数据缺失

很可能需要将许多错误升级到数据所有者、ETL 工具的创建者或数据使用者。这增加了维护开销，而且工具停机也是非常频繁的。由于这个原因，数据记录中经常存在较大的空白。

治理

随着 ETL 流程的增加，同样的处理很可能由不同的流程执行，导致同一信息的多源性。随着时间的推移，这些流程通常会分歧以满足不同的需求，导致用于不同决策的数据不一致。

效率和环境影响

支持这些类型转换的基础设施是一个关注点，因为它通常是 24/7 运行，会产生重大成本并增加碳足迹的影响。

在前述列表中的第一个要点（数据质量）经常被忽视，但随着时间推移，它往往是最重要的。通常需要在数据能够“信任”投入生产之前对其进行预处理。来自上游系统的数据通常被认为是原始的，如果没有经过适当的清理和转换，可能会包含噪声或甚至错误信息。例如，电子商务网站日志可能需要在使用之前进行转换，例如从 URL 中提取产品代码或过滤掉机器人生成的虚假交易。数据处理工具必须专门为手头的任务构建。并不存在用于处理质量问题的全局数据质量解决方案或通用框架。

虽然在逐个考虑数据源时这种情况是合理的，但整体收集（参见图 1-4）导致混乱。

图 1-4. 数据生态系统与挑战

存储系统的增加，以及为满足不同下游应用程序需求而开发的定制数据管理解决方案的增多，导致分析领导者和首席信息官（CIO）面临以下挑战：

• 他们的 DWH/数据湖无法跟上不断增长的业务需求。

• 越来越多地，数字化倡议（以及与数字原住民的竞争）已经使业务转变为一个大规模数据量涌入系统的业务。

• 为不同的数据科学任务创建单独的数据湖、DWH 和特殊存储的需求最终导致了多个数据孤岛的产生。

• 数据访问需要受限或受限制，由于性能、安全性和治理挑战。

• 续订许可证和支付昂贵的支持资源变得具有挑战性。

显而易见，这种方法无法扩展以满足新的业务需求，不仅因为技术复杂性，还因为这种模型所需的安全性和治理要求。

反模式：控制的集中化

为了尝试解决通过专门的数据处理解决方案管理的孤立、分散和分布式数据的问题，一些组织试图将一切集中在由 IT 部门控制的单一的、单块的平台中。如图 1-5 所示，技术解决方案本质上并未改变，而是通过将问题分配给单一组织来使其更易于解决。

图 1-5. IT 集中控制数据系统的数据生态系统和挑战

由唯一部门进行的这种集中控制带来了其自身的挑战和权衡。所有业务单位（BU）——IT 本身、数据分析以及业务用户——当 IT 控制所有数据系统时，都会面临困难：

IT

IT 部门面临的挑战是这些数据孤岛涉及的各种技术集合。IT 部门很少具备管理所有这些系统所需的所有技能。数据存储在本地和云中的多个存储系统中，管理数据仓库、数据湖和数据集市成本高昂。如何在不同来源之间定义安全性、治理、审计等问题也并不总是明确。此外，获取数据存在扩展性问题：IT 需要进行的工作量随源系统和目标系统的增加而线性增加，因为这必然会增加所有相关利益相关者/业务用户的数据访问请求。

分析

有效分析过程中的一个主要问题是没有获取到正确的数据。当存在多个系统时，将数据移动到/从一个单块数据系统变得成本高昂，导致不必要的 ETL 任务等等。此外，预先准备和随时可用的数据可能没有最新的来源，或者可能存在其他版本的数据，提供更深入和更广泛的信息，例如拥有更多列或更细粒度记录。由于数据治理和运营问题，不可能让你的分析团队自由发挥，每个人都可以访问所有数据。组织往往最终限制数据访问，以牺牲分析灵活性为代价。

业务

获取业务可信赖的数据和分析结果非常困难。围绕限制向业务提供数据的问题存在着，以确保最高质量。替代方法是为业务用户开放他们所需的所有数据访问权限，即使这意味着牺牲质量。然后，挑战变成了在数据质量和可信数据量之间的平衡。通常情况下，IT 部门没有足够的合格业务代表来推动优先事项和需求。这很快会成为组织内部创新过程的瓶颈。

尽管存在诸多挑战，多个组织多年来采用了这种方法，导致业务用户在获取所需数据以完成任务时延迟，从而产生了挫败和紧张情绪。受挫的业务部门经常通过另一种反模式来应对——即影子 IT——整个部门开发和部署有用的解决方案，以规避这些限制，但最终加剧了数据孤岛问题。

有时会采用一种称为数据布局的技术方法。这仍然依赖于集中化，但是与物理移动数据不同，数据布局是一个虚拟层，用于提供统一的数据访问。问题在于，这样的标准化可能会给组织范围内的数据访问带来沉重的负担和延迟。然而，数据布局对于试图访问客户专有数据的 SaaS 产品来说是一种可行的方法——集成专家提供必要的从客户架构到 SaaS 工具期望的架构的转换。

反模式：数据集市和 Hadoop

围绕着孤立的集中管理系统存在的挑战给 IT 带来了巨大的紧张和开销。为了解决这个问题，一些企业采纳了另外两种反模式：数据集市和无治理数据湖。

在第一种方法中，数据被提取到本地的关系型和分析型数据库中。然而，尽管被称为数据仓库，但实际上这些产品是数据集市（企业数据的子集，适用于特定工作负载）由于可扩展性限制。数据集市允许业务用户设计和部署他们自己的业务数据到结构化数据模型中（例如在零售、医疗保健、银行、保险等领域）。这使得他们可以轻松获取有关当前和历史业务的信息（例如上个季度的收入金额、上周播放过你最新发布的游戏的用户数量、你的网站帮助中心花费的时间与过去六个月收到的工单数量之间的相关性等）。多年来，组织一直在使用各种技术（例如 Oracle、Teradata、Vertica）开发数据集市解决方案，并在其上实施多个应用程序。然而，这些本地技术在容量方面严重受限。IT 团队和数据利益相关者面临的挑战包括扩展基础设施（纵向）、寻找关键人才、降低成本，并最终满足提供有价值洞察的增长预期。此外，随着数据量的增长，这些解决方案往往成本高昂，因为你需要获取更多计算能力来处理它。

由于可扩展性和成本问题，基于 Apache Hadoop 生态系统的大数据解决方案被创建。Hadoop 引入了使用低成本通用服务器的分布式数据处理（横向扩展），使得以前只能用高端（和非常昂贵）专用硬件实现的用例成为可能。在 Hadoop 上运行的每个应用程序都设计为容忍节点故障，使其成为一些传统数据仓库工作负载的经济有效替代方案。这导致了一个新概念的发展，称为数据湖，它迅速成为数据管理的核心支柱之一，与数据仓库并列。

思路是，尽管核心运营技术部门继续执行例行任务，但所有数据都被导出到一个集中的数据湖中进行分析。这个数据湖的目的是作为分析工作负载和业务用户的中心存储库。数据湖已经从仅仅是原始数据的存储设施发展为能够在大量数据上进行高级分析和数据科学的平台。这使得整个组织能够进行自助式分析，但需要对高级 Hadoop 和工程流程有广泛的工作知识才能访问数据。与企业数据的指数级增长相对应，Hadoop 开源软件（Hadoop OSS）生态系统在数据系统和处理框架（如 HBase、Hive、Spark、Pig、Presto、SparkML 等）方面也有所发展，但这增加了额外的复杂性和维护成本。此外，数据湖变成了一团无政府状态的数据，很少有潜在的数据使用者能够理解。技能差距和数据质量问题的结合意味着企业很难从本地数据湖中获得良好的投资回报率。

现在您已经看到了几个反模式，让我们专注于如何设计一个数据平台，提供对整个生命周期内数据的统一视图。

创建统一的分析平台

数据市场和数据湖技术使 IT 能够构建数据平台的第一个迭代版本，以打破数据孤岛，并使组织能够从其所有数据资产中获取洞察。数据平台使数据分析师、数据工程师、数据科学家、业务用户、架构师和安全工程师能够获取更好的实时洞察，并预测他们的业务随时间如何发展。

云而非本地部署

DWH 和数据湖是现代数据平台的核心。数据仓库支持结构化数据和 SQL，而数据湖支持原始数据和 Apache 生态系统中的编程框架。

然而，在本地环境中运行数据仓库（DWH）和数据湖也存在一些固有的挑战，如扩展和运营成本。这促使组织重新考虑他们的方法，并开始将云（尤其是公共版本）视为这样一个平台的首选环境。为什么？因为这使得他们能够：

• 通过利用新的定价模型（按使用付费模型）来降低成本。

• 通过利用最佳技术加快创新速度

• 使用“突发”方法扩展本地资源规模。

• 通过在多个区域和地区存储数据来规划业务连续性和灾难恢复

• 使用完全托管的服务自动管理灾难恢复

当用户不再受到基础设施容量的限制时，组织可以在全公司范围内民主化数据，并释放洞察力。云支持组织进行现代化改造，因为它通过卸载管理、低价值任务来最小化麻烦和摩擦。云数据平台承诺提供一个环境，您不再需要妥协，可以构建一个全面的数据生态系统，覆盖从数据收集到服务的端到端数据管理和数据处理阶段。您可以使用云数据平台以不牺牲延迟的方式存储大量不同格式的数据。

云数据平台承诺：

• 集中式治理和访问管理

• 增加生产力和降低运营成本

• 组织内部数据共享增加

• 不同角色的扩展访问权限

• 减少访问数据的延迟

在公共云环境中，数据仓库（DWH）和数据湖技术之间的界限变得模糊，因为云基础设施（特别是计算和存储的分离）使得在本地环境中不可能实现的融合成为可能。今天可以将 SQL 应用于存储在数据湖中的数据，并且可以在存储在数据仓库中的数据上运行传统的 Hadoop 技术（例如 Spark）。在本节中，我们将为您介绍此融合如何运作以及如何成为革新组织数据观察方式的基础；在第五章至第七章中，您将获得更多详细信息。

数据集市（Data Marts）和数据湖（Data Lakes）的缺点

在过去的 40 年里，IT 部门意识到数据仓库（实际上是数据集市）难以管理，成本高昂。在过去表现良好的传统系统（如本地的 Teradata 和 Netezza 设备）已被证明难以扩展、成本昂贵，并带来了与数据新鲜度相关的一系列挑战。此外，它们不能轻松地提供现代能力，如接入 AI/ML 或实时功能，而不是事后添加该功能。

数据仓库用户通常是嵌入在特定业务单位中的分析师。他们可能对额外的数据集、分析、数据处理和商业智能功能有想法，这些对他们的工作非常有益。然而，在传统公司中，他们经常无法直接访问数据所有者，也无法轻易影响决定数据集和工具的技术决策者。此外，由于他们无法访问原始数据，他们无法测试假设或深入理解底层数据。

数据湖并非像它们看起来那么简单或成本效益。虽然从理论上讲它们可以很容易地扩展，但组织通常面临规划和配置足够存储空间的挑战，特别是如果它们产生高度变化的数据量。此外，为高峰期配置计算能力可能会很昂贵，导致不同业务单位之间竞争稀缺资源。

在场数据湖可能会很脆弱，并且需要耗费时间的维护。那些本可以开发新功能的工程师经常被安排维护数据集群和为业务单位安排任务。对于许多企业来说，总体拥有成本往往比预期的要高。简而言之，数据湖并没有创造价值，许多企业发现投资回报率为负。

对于数据湖来说，治理并不容易解决，特别是当组织的不同部分使用不同的安全模型时。然后，数据湖变得分割和分段，使得跨团队分享数据和模型变得困难。

数据湖的用户通常更接近原始数据源，并且需要使用数据湖工具和能力的编程技能，即使只是用于探索数据。在传统的组织中，这些用户倾向于专注于数据本身，并经常与业务的其他部门保持一定距离。另一方面，业务用户没有从数据湖中获取洞察力所需的编程技能。这种断开意味着业务部门错失了推动其业务目标提高收入、降低成本、降低风险和开发新机会的洞察力。

数据仓库（DWH）与数据湖的融合

面对这些权衡，许多公司最终采取了混合方法，其中数据湖被建立用于向数据仓库（DWH）输出一些数据，或者数据仓库旁边设有数据湖用于额外的测试和分析。然而，由于多个团队根据各自的需求构建自己的数据架构，对于中央 IT 团队来说，数据共享和数据的准确性变得更加复杂。

不再有各自目标的独立团队——一个探索业务，另一个了解业务——你可以将这些功能及其数据系统联合起来，创造一个良性循环，在这个循环中，对业务的深入理解推动了探索，而探索则推动了对业务的更深理解。

从这个原则出发，数据行业已经开始转向一个新的方法，即lakehouse和数据网格，它们之间可以很好地配合，因为它们帮助解决组织内的两个不同挑战：

• Lakehouse 允许具有不同技能集（数据分析师和数据工程师）的用户使用不同的技术访问数据。

• 数据网格允许企业创建统一的数据平台，而不是将所有数据集中在 IT 中，这样不同的业务单位可以拥有自己的数据，但允许其他业务单位以高效、可扩展的方式访问。

作为附加好处，这种架构组合还带来了更严格的数据治理，这是数据湖通常缺乏的。数据网格赋予人们避免被一个团队成为瓶颈的能力，从而使整个数据堆栈能够实现更高效的、可扩展的方式。它在一种架构中将隔离成较小的组织单元提供了对数据的联邦式访问。

湖屋

数据湖屋架构结合了数据湖和数据仓库的关键优势（见图 1-6）。它提供了一种低成本存储格式，可被各种处理引擎访问，例如数据仓库的 SQL 引擎，同时还提供强大的管理和优化功能。

图 1-6. DWH、数据湖和湖屋模式

Databricks 支持湖屋架构，因为它基于 Spark 的创始，并需要支持非程序员的业务用户。因此，Databricks 中的数据存储在数据湖中，但业务用户可以使用 SQL 访问它。然而，湖屋架构并不局限于 Databricks。

运行在 Google Cloud BigQuery、Snowflake 或 Azure Synapse 等云解决方案中的 DWH，可以创建基于列存储的湖屋架构，这种架构针对 SQL 分析进行了优化：它允许您将 DWH 视为数据湖，同时允许在并行 Hadoop 环境中运行的 Spark 作业利用底层存储系统上存储的数据，而不需要单独的 ETL 过程或存储层。

湖屋模式相对传统方法提供了几个优势：

• 解耦存储和计算，实现：

  • 价格低廉、几乎无限制和无缝扩展的存储

  • 无状态、弹性计算

  • ACID 兼容的存储操作

  • 逻辑数据库存储模型，而非物理模型

• 数据治理（例如，数据访问限制和模式演变）

• 通过与商业智能工具的本地集成支持数据分析

• 原生支持数据湖方法的典型多版本方法（即铜、银和金）

• 数据存储和管理通过开放格式如 Apache Parquet 和 Iceberg

• 支持结构化或非结构化格式中的不同数据类型

• 流式能力，能够处理数据的实时分析

• 支持多种应用，从商业智能到机器学习不等

然而，数据湖屋是一种技术上的妥协。在云存储中使用标准格式限制了数据仓库多年来完善的存储优化和查询并发性。因此，与本地数据仓库（即需要更多资源并且成本更高）相比，数据湖屋技术支持的 SQL 不那么高效。此外，SQL 支持往往有限，例如地理空间查询、机器学习和数据操作等功能要么不可用要么效率低下。同样，数据仓库提供的 Spark 支持也有限，并且性能不如数据湖供应商提供的本地 Spark 支持。

数据湖屋方法使组织能够实施支持任何工作负载类型的极度多样化数据平台的核心支柱。但是对于在其之上的组织呢？用户如何利用平台的最佳部分来执行他们的任务？在这种情况下，出现了一种新的运营模式，即数据网格。

数据网格

数据网格是一种技术、人员和流程的分散化运营模式，用于解决分析中最常见的挑战——在数据所有权必然分布的环境中，对控制集中化的渴望，如图 1-7 所示。从另一个角度来看，数据网格介绍了一种将数据视为自包含产品而不是 ETL 流水线产品的方法。

图 1-7. 数据网格统一了公司内的数据访问，同时保留了分布领域中数据的所有权

在这种方法中，分布式团队拥有数据生产，并通过明确定义的数据模式为内部/外部消费者提供服务。总体而言，数据网格建立在数据仓库和数据湖跨界创新的悠久历史之上，结合了公共云中数据仓库技术的可扩展性、按消费模式付费、自服务 API 以及紧密集成的特点。

通过这种方法，您可以有效地创建按需数据解决方案。数据网格将数据所有权分散到域数据所有者中，每个所有者都负责以标准方式提供其数据作为产品（参见图 1-8）。数据网格还能够促进组织各部分之间的沟通，以在不同位置分发数据集。

在数据网格中，从数据中生成价值的责任被委托给最了解数据的人；换句话说，创建数据或将其引入组织的人必须负责从他们创建的数据中创建可消费的数据资产作为产品。在许多组织中，由于在组织中多次提取和转换数据而没有明确的数据所有权责任，建立“真相的单一来源”或“权威数据来源”是棘手的。在数据网格中，权威数据来源是由源域发布的数据产品，并有明确定义的数据所有者和监护人负责该数据。

图 1-8. 数据作为产品

从技术视角（数据湖）和组织视角（数据网格）获得这种统一视图，意味着人们和系统以最适合其需求的方式获取数据。在某些情况下，这种架构必须跨越多个环境，有时产生非常复杂的架构。让我们看看公司如何应对这一挑战。

注意

关于数据网格的更多信息，我们建议您阅读 Zhamak Dehghani 的书籍数据网格：规模交付数据驱动价值（O’Reilly）。

混合云

在设计云数据平台时，可能会发现一个单一环境无法完全管理工作负载。这可能是因为监管限制（例如，您无法将数据移入组织边界之外的环境），或者是因为成本原因（例如，组织对未达到寿命终结的基础设施进行了一些投资），或者是因为您需要的特定技术在云中不可用。在这种情况下，采用混合模式可能是一个可行的方法。混合模式是指应用程序在各种环境的组合中运行的模式。混合模式的最常见例子是将私有计算环境（如现场数据中心）与公共云计算环境结合在一起。在本节中，我们将解释这种方法如何在企业中运作。

混合模式的必要原因

混合云方法被广泛采用，因为现今几乎没有一个大型企业完全依赖公共云。在过去几十年中，许多组织已经投入了数百万美元和数千小时在现场基础设施上。几乎所有组织都在运行一些传统架构和业务关键应用程序，它们可能无法迁移至公共云。他们可能还有一些敏感数据，由于监管或组织约束，无法存储在公共云中。

允许工作负载在公共和私有云环境之间过渡提供了更高的灵活性和数据部署的附加选项。有几个原因推动混合（即跨越本地、公共云和边缘的架构）和多云（即跨越多个公共云供应商如 AWS、Microsoft Azure 和 Google Cloud Platform [GCP]等的架构）的采用。

以下是选择混合和/或多云的一些关键业务原因：

数据驻地法规

有些人可能永远不会完全迁移到公共云，可能是因为他们处于金融或医疗保健行业，需要遵循严格的行业法规，规定数据存储的位置。在没有公共云存在和数据驻留要求的国家，工作负载也是如此。

传统投资

一些客户希望保护其像 SAP、Oracle 或 Informatica 等遗留工作负载在本地运行，但希望利用公共云创新技术，例如 Databricks 和 Snowflake。

过渡

大型企业通常需要经过多年的旅程，将其现代化为云原生应用和架构。他们必须在数年间接受混合架构作为中间状态。

云爆发

有些客户主要在本地运营，并且没有迁移到公共云的意愿。然而，由于临时大批作业、繁忙时段的尖峰流量或大规模的机器学习训练作业，他们在满足业务服务级别协议（SLA）方面存在挑战。他们希望利用公共云中可扩展的容量或自定义硬件，并避免在本地基础设施上进行扩展的成本。像 MotherDuck 这样采用“本地优先”计算方法的解决方案正在变得流行。

最优品种

一些组织选择在不同的公共云提供商之间进行不同任务的选择，这是一种有意识的策略，选择最适合其需求的技术。例如，Uber 使用 AWS来提供其 Web 应用程序，但在其履行平台上 使用 Google Cloud 上的 Cloud Spanner。Twitter 在 AWS 上运行其新闻订阅，但 在 Google Cloud 上运行其数据平台。

现在您了解了选择混合解决方案的原因，让我们来看看在使用这种模式时可能会面临的主要挑战；这些挑战是为什么混合应该被视为一种例外的原因，而目标应该是云原生。

混合云挑战

企业在实施混合或多云架构时面临几个挑战：

治理

在多个环境中应用一致的治理政策是困难的。例如，本地和公共云之间的合规安全政策通常有不同的处理方式。通常，数据的部分副本分布在本地和云中。想象一下，您的组织正在运行财务报告——如果数据在多个平台上存在多个副本，如何确保使用的数据是最新更新的副本？

访问控制

用户访问控制和策略在本地和公共云环境之间有所不同。云服务提供商为其提供的服务有其自己的用户访问控制（称为身份和访问管理，或 IAM），而本地则使用诸如本地目录访问协议（LDAP）或 Kerberos 等技术。如何保持它们同步或在不同环境中拥有单一控制平台？

工作负载互操作性

在跨多个系统时，不可避免地会有需要管理的不一致的运行时环境。

数据迁移

如果本地和云应用程序都需要访问某些数据，则这两个数据集必须同步。在多个系统之间移动数据成本高昂——创建和管理管道有人力成本，可能由于使用的软件而产生许可成本，最后但同样重要的是，它消耗了计算、网络和存储资源。您的组织如何处理来自多个环境的成本？如何连接在各种环境中分散的异构数据？作为连接过程的结果，您最终将在何处复制数据？

技能集

拥有两个云（或本地和云端）意味着团队必须了解并建立两个环境的专业知识。由于公共云是一个快速变化的环境，要提升和维护员工在一个云中的技能已经带来了显著的开销，更不用说两个了。技能集也可能对雇佣系统集成商（SIs）构成挑战——尽管大多数大型 SIs 都有每个主要云平台的实践，但很少有团队了解两个或更多的云平台。随着时间的推移，我们预计将越来越难雇佣愿意学习专有本地技术的人员。

经济学

数据分布在两个环境之间可能带来意想不到的成本：也许您在一个云中有数据，并希望将其提供给另一个云，这将产生数据流出成本。

尽管存在这些挑战，混合设置确实可行。我们将在下一小节中详细探讨如何做到。

为什么混合设置可以运作

云服务提供商意识到这些需求和挑战。因此，他们为混合环境提供了一些支持。这些支持可以分为三个方面：

选择

云服务提供商通常会大量贡献开源技术。例如，尽管 Kubernetes 和 TensorFlow 是在 Google 开发的，但它们是开源的，因此在所有主要云中都存在其托管执行环境，并且甚至可以在本地环境中利用它们。

灵活性

类似 Databricks 和 Snowflake 的框架允许您在任何主要公共云平台上运行相同的软件。因此，团队可以学习一组能够在任何地方工作的技能。请注意，多云环境下工作的工具所提供的灵活性并不意味着您已经摆脱了锁定。您将不得不在以下两者之间做出选择：（1）在框架级别锁定和在云级别灵活性（由 Databricks 或 Snowflake 等技术提供）之间；（2）在云级别锁定和在框架级别灵活性（由原生云工具提供）之间。

开放性

即使工具是专有的，由于采纳了开放标准和导入/导出机制，其代码也是以可移植的方式编写的。因此，例如，即使 Redshift 只能在 AWS 上运行，查询也是用标准 SQL 编写的，并且有多种导入和导出机制。这些能力共同使得 Redshift、BigQuery 和 Synapse 成为开放平台。这种开放性允许像 Teads 这样的用例，数据使用 Kafka 在 AWS 上收集，使用 Google Cloud 上的 Dataflow 和 BigQuery 进行聚合，然后写回 AWS Redshift（参见图 1-9）。

图 1-9. Teads 的混合分析管道（基于 Alban Perillat-Merceroz 的一篇文章，发表在 Teads 工程）

云服务提供商通过重视投资开源项目来承诺选择性、灵活性和开放性，这有助于客户在多个云中使用。因此，多云数据仓库或混合数据处理框架正在成为现实。因此，您可以按照您希望的方式构建混合和多云部署，以更好地生产、发布和管理云软件，而不是供应商强加的方式。

边缘计算

另一个混合模式的例子是当你可能希望计算能力跨越常规数据平台的边界，也许是直接与某些连接设备交互。在这种情况下，我们谈论的是边缘计算。边缘计算将计算和数据存储靠近生成数据并需要处理数据的系统。边缘计算的目标是提高响应时间并节省带宽。边缘计算可以解锁许多用例，并加速数字转型。它在许多应用领域有广泛的应用，例如安全、机器人技术、预测性维护、智能车辆等。

随着边缘计算的采纳和普及，对于各行各业都存在许多潜在优势：

更快的响应时间

在边缘计算中，数据存储和计算能力被分布并提供在需要做出决策的地点。不需要往返云端将减少延迟，并使响应速度更快。在预防性维护中，这将有助于阻止关键机器操作的故障或危险事件的发生。在活动游戏中，边缘计算可以提供所需的毫秒级响应时间。在欺诈预防和安全场景中，它可以防止隐私泄露和拒绝服务攻击。

断断续续的连接

在石油井、农场水泵、太阳能场或风车等偏远资产存在不可靠的互联网连接性，这可能导致对这些资产的监控变得困难。边缘设备能够在本地存储和处理数据，确保在互联网连接受限的情况下不会丢失数据或操作失败。

安全和合规性

边缘计算可以消除设备与云之间大量的数据传输。可以在本地过滤敏感信息，仅将关键数据模型构建信息传输到云端。例如，使用智能设备时，诸如监听“OK Google”或“Alexa”之类的关键词处理可以在设备本身上进行。潜在的私人数据不需要被收集或发送到云端。这使用户能够构建适当的安全性和合规性框架，对于企业的安全性和审核至关重要。

成本有效的解决方案

在物联网采用中的一个实际关注点是由于网络带宽、数据存储和计算能力而产生的前期成本。边缘计算可以在本地执行大量数据计算，使企业能够决定哪些服务在本地运行，哪些发送到云端，从而降低整体物联网解决方案的最终成本。这就是嵌入式模型以低内存二进制部署的地方，在现代编译语言如 Rust 或 Go 中构建的格式（如开放神经网络交换 ONNX）可以表现出色的地方。

互操作性

边缘设备可以作为传统和现代设备之间通信的联络人。这使得传统工业设备能够连接到现代设备或物联网解决方案，并立即从传统或现代设备中捕获见解的好处。

所有这些概念使架构师在定义他们的数据平台时极为灵活。在第九章中，我们将深入探讨这些概念，看看这种模式如何成为标准。

应用人工智能

许多组织因需要采用 AI 技术而被迫设计云数据平台——在设计数据平台时，重要的是确保它能够未来证明其能力以支持 AI 用例。考虑到 AI 对社会的巨大影响以及它在企业环境中的扩散，让我们快速深入地看一下它如何在企业环境中实施。您可以在第十章和第十一章中找到更深入的讨论。

机器学习

现在，一种名为监督式机器学习的 AI 分支已经取得了巨大成功，以至于术语AI更经常被用作这一分支的总称。监督式 ML 通过展示计算机程序许多已知正确答案（称为标签）的示例来工作。ML 模型是一个标准算法（即完全相同的代码），具有可调参数，可以“学习”如何从提供的输入到标签。这样一个学习的模型随后被部署来对不知道正确答案的输入做出决策。

与专家系统不同，不需要明确编程 AI 模型的规则来做出决策。因为许多现实世界的领域涉及到专家判断，而专家往往难以表达他们的逻辑，所以让专家简单地标记输入示例比捕捉他们的逻辑要可行得多。

现代象棋算法和医疗诊断工具使用 ML。象棋算法从人类过去玩过的游戏记录中学习[²]，而医疗诊断系统则从专家医生标记的诊断数据中学习。

生成式 AI，这是 AI/ML 的一个分支，最近变得非常强大，不仅能够理解图像和文本，还能生成逼真的图像和文本。除了能够在营销等应用中创建新内容外，生成式 AI 还简化了机器与用户之间的交互。用户能够用自然语言提问并使用英语或其他语言自动化许多操作，而不必了解编程语言。

为了使这些 ML 方法运行，它们需要大量的训练数据和现成的定制硬件。因此，采用 AI 的组织首先建立了一个云数据/ML 平台。

ML 的用途

有几个关键原因导致了工业界对 ML 的惊人采纳：

数据更容易。

收集标记数据比捕捉逻辑更容易。人类推理的每一部分都有例外情况，随着时间的推移会被编码。让一组眼科医生标记一千张图像比让他们描述如何识别血管出血要容易得多。

重新培训更容易。

当机器学习用于系统，例如向用户推荐物品或运行营销活动时，用户行为迅速适应变化。继续训练模型非常重要。这在机器学习中是可能的，但用代码实现则更为困难。

更好的用户界面。

深度学习 这类机器学习已被证明能够被训练，即使是在像图像、视频和自然语言文本这样的非结构化数据上。这些类型的输入通常很难编程。这使得你可以将真实世界的数据作为输入——考虑一下当你可以简单地拍摄支票照片而不必把所有信息都输入到网页表单时，存款支票界面会变得更好多少。

自动化。

机器学习模型理解非结构化数据的能力使得许多业务流程的自动化成为可能。表单可以轻松数字化，仪表盘读数可以更轻松，工厂车间可以更轻松地监控，因为可以自动处理自然语言文本、图像或视频。

成本效益。

机器学习 API 使得机器能够理解和创建文本、图像、音乐和视频，每次调用的成本仅为几分之一美分，而雇佣人类执行同样的任务则成本高出数个数量级。这使得技术在诸如推荐等情境中的应用成为可能，而雇佣个人购物助手则成本过高。

援助。

生成式人工智能可以赋予开发者、营销人员和其他白领工作者更高的生产力。编码助手和工作流合作者能够简化许多公司功能的部分，如发送定制销售邮件。

鉴于这些优势，不足为奇，哈佛商业评论文章发现，人工智能通常支持三个主要的业务需求：

• 自动化业务流程——通常是自动化后勤行政和财务任务

• 通过数据分析获得洞见

• 与顾客和员工互动

机器学习通过使用数据示例增加了解决问题的可扩展性，而无需为每件事情都编写自定义代码。然后，诸如深度学习之类的机器学习解决方案使得即使在处理像图像、语音、视频和自然语言文本等非结构化信息时也能解决这些问题。

为什么选择云来支持人工智能？

设计云数据平台的一个关键动机可能是组织正在快速采用深度学习等人工智能技术。为了使这些方法能够运作，它们需要大量的训练数据。因此，计划构建机器学习模型的组织需要建立一个数据平台，以组织并使数据可供其数据科学团队使用。这些机器学习模型本身非常复杂，训练这些模型需要大量的专用硬件，称为图形处理单元（GPUs）。此外，语音转录、机器翻译和视频智能等人工智能技术通常作为云端的 SaaS 软件提供。此外，云平台提供关键的功能，如民主化、更轻松的操作和跟上技术发展的能力。

云基础设施

关键是高质量的人工智能需要大量的数据——一篇著名的论文标题为“深度学习扩展是可预测的，经验性的”发现，为了在自然语言模型中获得 5%的改进，需要训练两倍于用于获得第一个结果的数据量。最优秀的机器学习模型并非最先进的那些——而是那些在足够高质量数据上训练的模型。原因在于，越来越复杂的模型需要更多的数据，而即使是简单的模型，如果在足够大的数据集上训练，也会提高性能。

要了解现代机器学习模型训练所需的数据量，可以举例说明，图像分类模型通常在一百万张图片上进行训练，而主要的语言模型则是在多个 TB 的数据上进行训练。

如图 1-10 所示，这种数据量需要大量高效的定制计算——通过加速器如 GPU 和定制的应用特定集成电路（ASICs）称为张量处理单元（TPUs）——来利用这些数据并理解它。

许多最近的人工智能进展可以归因于数据规模和计算能力的增加。云中大数据集和推动它的众多计算机之间的协同作用已经实现了机器学习的巨大突破。这些突破包括通过降低语音识别中的词误差率30%，超过传统方法的最大进展已达 20 年之久。

图 1-10. 随着内存增加、处理器增多以及使用 TPUs 和 GPUs，机器学习性能显著提高（来自AVP 项目的图表）

民主化

设计 ML 模型，特别是在复杂领域如时间序列处理或自然语言处理（NLP）中，需要掌握 ML 理论。使用 PyTorch、Keras 或 TensorFlow 等框架编写 ML 模型训练代码需要掌握 Python 编程和线性代数知识。此外，为 ML 进行数据准备通常需要数据工程专业知识，并且评估 ML 模型需要高级统计学知识。部署 ML 模型并监控它们需要 DevOps 和软件工程知识（通常称为 MLOps）。不用说，每个组织中都很少具备所有这些技能。考虑到这一点，利用 ML 解决业务问题对传统企业来说可能是困难的。

云技术提供了几种选项来使 ML 的使用民主化：

ML API

云服务提供商提供预构建的 ML 模型，可以通过 API 调用。此时，开发人员可以像使用任何其他 Web 服务一样使用 ML 模型。他们所需的只是能够针对表述状态转移（REST）Web 服务进行编程的能力。这些 ML API 的示例包括 Google 翻译、Azure 文本分析和亚马逊 Lex —— 这些 API 可以在不需要任何 NLP 知识的情况下使用。云服务提供商提供文本和图像生成的生成模型作为 API，其中输入只是一个文本提示。

可定制的 ML 模型

一些公共云提供了“AutoML”，这些是端到端的 ML 流水线，可以通过点击鼠标进行训练和部署。AutoML 模型通过“神经架构搜索”来自动进行 ML 模型的架构设计。虽然与人类专家选择有效模型相比，训练时间较长，但 AutoML 系统可以满足那些无法自行设计模型的业务线需求。请注意，并非所有的 AutoML 都相同 —— 有时所谓的 AutoML 只是参数调优。确保您获得的是定制的架构而不仅仅是预构建模型的选择，双重检查是否有多个可以自动化的步骤（例如特征工程、特征提取、特征选择、模型选择、参数调优、问题检查等）。

更简单的 ML

在写作时，一些数据仓库（例如 BigQuery 和 Redshift）提供了使用 SQL 在结构化数据上训练 ML 模型的能力。Redshift 和 BigQuery 支持通过委派给 Vertex AI 和 SageMaker 实现复杂模型。像 DataRobot 和 Dataiku 这样的工具提供了用于训练 ML 模型的点对点界面。与其它方式相比，云平台使生成模型的微调变得更加容易。

ML 解决方案

一些应用程序如此常见，以至于可以购买和部署端到端的机器学习解决方案。Google Cloud 上的产品发现提供了零售商的端到端搜索和排名体验。Amazon Connect 提供了由机器学习驱动的即插即用的联系中心。Azure Knowledge Mining 提供了一种挖掘各种内容类型的方式。此外，像 Quantum Metric 和 C3 AI 这样的公司为多个行业常见的问题提供基于云的解决方案。

机器学习构建块

即使整个机器学习工作流程没有解决方案，部分工作也可以利用构建块。例如，推荐系统需要能够匹配项目和产品。Google Cloud 提供了一种名为two-tower encoders的通用匹配算法。虽然没有端到端的后台自动化机器学习模型，但您可以利用表单解析器来帮助更快地实现该工作流程。

这些能力使企业即使没有深入的专业知识也可以采用人工智能，从而使人工智能更广泛地可用。

即使企业具有人工智能的专业知识，这些能力也非常有用，因为您仍然需要决定是购买还是构建机器学习系统。通常情况下，机器学习的机会比解决它们的人员多。因此，允许使用预构建的工具和解决方案来执行非核心功能具有优势。这些即插即用的解决方案可以立即提供大量价值，而无需编写定制应用程序。例如，通过 API 调用将自然语言文本的数据传递给预构建模型以进行文本翻译。这不仅减少了构建应用程序的工作量，还使非机器学习专家能够使用人工智能。在另一端，问题可能需要定制解决方案。例如，零售商经常构建机器学习模型来预测需求，以便知道需要存货的量。这些模型从公司的历史销售数据和内部专家直觉中学习购买模式。

另一种常见模式是使用预构建的即插即用模型进行快速实验，一旦机器学习解决方案证明其价值，数据科学团队可以以定制方式构建它，以获得更高的准确性，并希望在竞争中获得更多差异化优势。

实时

ML 基础设施必须与现代数据平台集成，因为实时个性化 ML 才有价值。因此，分析速度变得非常重要，因为数据平台必须能够实时摄取、处理和提供数据，否则就会错失机会。这还要加上行动速度。ML 提供基于客户背景的个性化服务，但必须在客户背景切换之前提供推断——对于大多数商业交易，ML 模型在客户采取行动之前必须提供客户进行选择的选项。为了实现这一点，需要使 ML 模型的结果实时到达行动点。

能够实时向 ML 模型提供数据并在实时获得 ML 预测，这是防范欺诈和发现欺诈的区别。为了防范欺诈，必须实时摄取所有付款和客户信息，运行 ML 预测，并将 ML 模型的结果实时返回到付款网站，以便如果怀疑有欺诈，则可以拒绝付款。

在客户服务和购物车放弃等情况下，实时处理节省了很多钱。在呼叫中心捕捉客户的沮丧，并立即升级情况，是提供有效服务的重要因素——与重新获得失去的客户相比，提供良好的服务成本要高得多。同样，如果购物车有被丢弃的风险，提供例如 5% 折扣或免费运输的诱因，成本可能低于重新吸引客户回到网站所需的大幅促销活动。

在其他情况下，批处理不是一个有效的选择。Google 地图需要实时交通数据和实时导航模型，以允许驾驶员避开交通。

正如您将在 第八章 中看到的，云服务的弹性和自动缩放能力在本地实现起来很困难。因此，实时 ML 最好在云中进行。

MLOps

公共云中 ML 更好的另一个原因是 ML 的操作化很难。有效和成功的 ML 项目需要操作化数据和代码。观察、编排和执行 ML 生命周期被称为MLOps。

在生产中构建、部署和运行 ML 应用程序涉及几个阶段，如 图 1-11 所示。所有这些步骤都需要编排和监控；例如，如果检测到数据漂移，则可能需要自动重新训练模型。必须定期对模型进行重新训练并部署，确保它们可以安全部署。对于传入数据，必须执行数据预处理和验证，确保没有数据质量问题，然后进行特征工程，接着是模型训练，最后进行超参数调整。

图 1-11. 一个 ML 工作流程的阶段

除了讨论的监控数据特定方面之外，你还需要对任何运行服务所必需的监控和操作化进行监控。生产应用通常是持续运行的，每天 24 小时/7 天/365 天，新数据定期进入。因此，你需要能够轻松编排和管理这些多阶段 ML 工作流，并可靠地和重复地运行它们的工具。

云 AI 平台如 Google 的 Vertex AI，微软的 Azure 机器学习和亚马逊的 SageMaker 提供整个 ML 工作流程的托管服务。在本地进行这些操作需要你将底层技术拼凑在一起并自行管理集成。

在撰写本书时，MLOps 能力正在以极快的速度添加到各种云平台。这提出了一个相关的观点，即随着 ML 领域的快速变化，将构建和维护 ML 基础设施和工具委托给第三方，专注于与核心业务相关的数据和洞察力会更好。

总之，基于云的数据和 AI 平台可以帮助解决数据孤岛、治理和容量方面的传统挑战，同时使组织能够为 AI 能力变得更加重要的未来做好准备。

核心原则

设计数据平台时，设定关键设计原则和希望分配给每个原则的权重可能会有所帮助。很可能需要在这些原则之间做出权衡，拥有所有利益相关者都同意的预先确定的评分卡可以帮助你在不必回到第一原则或被最强烈的需求左右的情况下做出决策。

这里是我们建议的数据分析堆栈的五个关键设计原则，尽管相对权重会因组织而异：

提供无服务器分析，而非基础设施。

设计分析解决方案，避免尽可能地使用搬迁和移移方法。专注于现代无服务器架构，让你的数据科学家（我们广泛使用此术语来指数据工程师、数据分析师和 ML 工程师）专注于分析，远离基础设施考虑。例如，使用自动化数据传输从系统中提取数据，并提供跨任何服务的联邦查询共享数据环境。这消除了维护自定义框架和数据管道的必要性。

嵌入端到端机器学习。

允许您的组织全面实现机器学习的运作。不可能为组织需要的每个机器学习模型构建一个模型，因此请确保您构建的平台能够嵌入民主化的机器学习选择，例如预构建的机器学习模型、机器学习构建块和更易于使用的框架。确保在需要自定义训练时，有权访问强大的加速器和可定制的模型。确保支持 MLOps，以确保部署的机器学习模型不会漂移并且不再适合用途。简化整个堆栈上的机器学习生命周期，以便组织能够更快地从其机器学习倡议中获取价值。

在整个数据生命周期中赋予分析能力。

数据分析平台应提供一套全面的核心数据分析工作负载。确保您的数据平台提供数据存储、数据仓库、流数据分析、数据准备、大数据处理、数据共享与商业化、商业智能（BI）和机器学习。避免购买需要集成和管理的一次性解决方案。更全面地审视分析栈将有助于打破数据孤岛，为应用程序提供实时数据支持，添加只读数据集，并使查询结果对任何人都可访问。

启用开源软件（OSS）技术。

在任何可能的情况下，确保开源技术是您平台的核心。您希望确保您编写的任何代码都使用标准的开源软件标准，如标准 SQL、Apache Spark、TensorFlow 等。通过启用最佳的开源技术，您将能够在数据分析项目中提供灵活性和选择性。

为增长而构建。

确保您构建的数据平台能够适应您的组织预期面临的数据规模、吞吐量和并发用户数。有时，这将涉及选择不同的技术（例如，某些用例使用 SQL，而其他用例使用 NoSQL）。如果这样做，请确保您选择的两种技术能够互操作。利用已被全球最具创新力公司证明和使用的解决方案和框架来运行其关键任务的分析应用程序。

总体而言，这些因素按照我们通常推荐的顺序列出。由于企业选择进行云迁移的两个主要动机是成本和创新，我们建议您优先考虑无服务器架构（以节省成本并解放员工免于例行工作）和端到端机器学习（因其支持的广泛创新）。

在某些情况下，您可能希望优先考虑某些因素。对于初创公司，我们通常建议最重要的因素是无服务器、增长和端到端 ML。全面性和开放性可以为速度而牺牲。高度监管的企业可能会偏向于全面性、开放性和增长，而不是无服务器和 ML（即监管者可能需要在本地进行）。对于数字原生企业，我们建议依次是端到端 ML、无服务器、增长、开放性和全面性。

总结

这是关于数据平台现代化的高层介绍。从数据生命周期的定义开始，我们看了数据处理的演变，传统方法的局限性，以及如何在云上创建统一的分析平台。我们还看了如何扩展云数据平台成为混合平台，并支持 AI/ML。本章的关键要点如下：

• 数据生命周期有五个阶段：收集、存储、处理、分析/可视化和激活。这些需要由数据和 ML 平台支持。

• 传统上，组织的数据生态系统由独立的解决方案组成，导致组织内部形成孤立。

• 数据移动工具可以打破数据孤立，但它们带来一些缺点：延迟、数据工程资源瓶颈、维护开销、变更管理和数据间隙。

• 在 IT 内集中控制数据会导致组织挑战。IT 部门缺乏必要的技能，分析团队获取到的数据质量差，业务团队不信任结果。

• 组织需要构建一个云数据平台来获得最佳架构，处理业务单位之间的整合，扩展本地资源，并规划业务连续性。

• 云数据平台利用现代方法，旨在通过重新平台化数据、打破孤立、民主化数据、强化数据治理、实现实时决策并使用位置信息，从描述性分析顺畅过渡到预测性和规范性分析，从而促进数据驱动的创新。

• 所有数据可以从运营系统导出到集中式数据湖进行分析。数据湖作为分析工作负载和业务用户的中央存储库。然而，其缺点是业务用户没有编程对接数据湖的技能。

• 数据仓库是支持 SQL 的集中式分析存储，这是业务用户熟悉的内容。

• 数据湖室建立在这样一个理念基础上，即所有用户，无论其技术技能如何，都可以并且应该能够使用数据。通过提供一个集中的底层框架来使数据可访问，可以在湖室顶部使用不同的工具，以满足每个用户的需求。

• 数据网格引入了一种将数据视为自包含产品的方式。在这种方法中，分布式团队拥有数据的生产，并通过明确定义的数据模式为内部/外部消费者提供服务。

• 混合云环境是满足企业世界现实的实用方法，例如收购、本地法律和延迟要求。

• 公共云提供了管理大型数据集和按需提供 GPU 的方式，使其对所有形式的 ML 都不可或缺，特别是深度学习和生成 AI。此外，云平台还提供了民主化、更容易的操作和跟上最新技术的能力。

• 云数据平台的五个核心原则是优先考虑无服务器分析、端到端 ML、全面性、开放性和增长性。这些相对权重会因组织而异。

现在你知道自己想要达到的目标位置后，在下一章中，我们将讨论达到目标的策略。

¹ 这里的成本不仅包括技术或许可证费用，还包括人力成本，而 SQL 技能往往对组织的成本影响比 Java 或 Python 技能低。

² 最近的 ML 系统，例如AlphaGo，通过观察机器之间玩的游戏来学习：这是一种称为强化学习的高级 ML 类型，但大多数工业用途的 ML 属于更简单的监督学习类型。

第二章：利用数据进行创新的战略步骤

您的领导之所以为您建立数据平台提供资金，很可能是因为他们希望组织进行创新。他们希望组织发现新的运营领域，创造业务运营的更好方式，或向更多客户提供更高质量的产品。这种形式的创新通常是通过更好地理解客户、产品或市场来实现的。无论您的组织是否希望减少用户流失，获取新用户，预测产品的维修周期，还是确定低成本替代品是否受欢迎，任务始于数据收集和分析。需要数据来分析业务的当前状态，识别缺陷或机会，实施改进现状的方式，并衡量这些变化的影响。通常，必须将特定于业务单元的数据与其他数据（既来自整个组织，又来自供应商和市场的数据）结合起来进行分析。在构建数据平台时，重要的是有意识地并将最终的“为什么”（促进创新）牢牢记在心中。

在本章中，您将学习到构建促进创新平台的七个战略步骤，为什么这些步骤至关重要，以及如何利用现代云技术实现这些步骤。将这些步骤看作是一个金字塔（如图 2-1 所示），其中每一步都作为后续步骤的基础。

在本章中，我们将阐明贯穿所有步骤的概念，但将其实施细节推迟到后续章节。例如，虽然我们将在本章描述打破业务隔离的概念，但我们将在第 5、6 和 7 章节中描述分析中心或数据网格方法的架构。

图 2-1 我们建议构建云数据和 AI 平台的七步旅程

第一步：战略与规划

要使最后六个步骤成功，首先需要制定战略计划，在这个计划中，您需要确定三个主要组成部分：

目标

在利用数据做出最佳利用时，组织的雄心是什么？深入挖掘并确定超越成本节约的目标至关重要。具体来说，重要的是确定将使用数据做出的决策以及可以通过哪些指标来知道转型是否成功。

利益相关者

谁在组织中有权支持和推动更深层次的转型？确保你汇聚所有这些利益相关者非常重要——根据我们的经验，IT 项目往往资源不足，并且总是面临失败的风险，而业务驱动的项目则拥有长期的高级管理支持和资金支持。业务项目还具有更高的投资回报率。

变革管理过程

如何有效地向整个组织传播并沟通方法，以获得最终用户的支持？

这种战略规划需要定期重新审视。目标是否依然相同？是否有新的利益相关者需要简报？是否在内部积聚不满情绪？

让我们逐个来看这三个组成部分。

战略目标

在构建数据和 AI/ML 平台时，你应该对自己的目标有清晰的认识。利益相关者经常会将目标框定为当前平台的限制。例如，如果你当前最痛苦的问题是报告工作量导致连锁性故障，那么目标可能会表述为“我们希望能在三小时内为我们三百万客户创建月度结算单”。然而，在构建平台的目标时，你不希望目标被单一用例所狭隘定义。相反，你希望从对你想要实现的战略目标的清晰视角出发。

根据企业的战略方向设计你的系统。对于为新购买提供信息的期望交付时间是多少？客户数量的预期增长是多少？通过移动设备与通过经纪人到达的客户比例会随时间而改变吗？IT 团队的预期人数是多少？企业是否希望使现场人员能够做出更多决策？你希望发送月度结算单，还是希望根据需求动态生成历史活动报告？我们计划通过这些报告赚钱吗？我们是否会根据这些结果改变业务实践？报告需要提供什么支持我们当前的业务在现场？当前平台无法支持这些需求将自然地从这些战略问题中出现，但这使你能够全面地构建系统需求，而不是被单一用例和旧有思维所束缚。这也有助于你向非技术性高管传达对系统的需求。

如果可能的话，获取未来两到三年这些战略业务目标的数值估计，以帮助您做出成本效益的决策。例如，简单地说“查询应尽可能快速运行”可能会导致建立一个过度工程化和昂贵的系统。相反，如果您知道在峰值时会有 1500 个并发查询，每个查询处理 100 GB 的数据，需要在 10 秒内完成，那么您可以选择能够实现目标而不至于倾家荡产的技术。这也适用于反向情况。知道业务以 60%的年增长率获取客户，可能清楚地了解到点击流数据集可能每天将达到 1 TB 的规模。这将防止您做出短视的决策，需要撤销。

这通常受到您可以预见业务增长的时间范围的限制。它也受现实世界事件的影响。例如，2020 年的 COVID-19 大流行颠覆了许多企业的计划，并加速了向数字和全渠道体验的转变。有时，您可能构建一个必须被废弃并重建的系统，但通过广泛考虑备用方案，可以减少这种情况发生的频率。

尽管细节可能有所不同，但我们发现大多数组织在其数据平台上最终需要实现以下战略目标：

降低运营数据和 AI 平台的成本。

特别是，随着数据集大小的增长，IT 成本呈线性增长可能变得不可持续。

通过加快从新项目中获取价值的时间来增加创新速度。

在新想法上进行实验不应面临数月的延迟，如获取机器、安装软件、获取数据集访问权限等。

民主化数据洞察。

使领域专家和领域内人员能够直接与数据互动并获得洞察。

将预测分析纳入决策制定，而不仅仅是描述性分析。

例如，不仅仅是测量上周使用的材料量，而是根据最近使用的量预测下周所需的材料量。

相对优先级因企业而异（正常情况下应如此）。许多初创企业和数字原住民强调创新速度和灵活性的增长，而许多成熟企业则强调成本优先于灵活性。例如，一家初创企业可能会使用 PB 级数据仓库，即使其数据规模很小，因为它预计每年增长 10 倍。而一家更成熟的企业可能会选择批处理，因为它比流处理更便宜。这些不同的起点会影响可能的创新和增长类型——PB 级数据仓库可以让初创企业基于每笔支付交易实时推荐，而更成熟的企业可能仅在每天发送推荐电子邮件，并且仅针对进行大笔订单的客户。

确定利益相关者。

一个坚实的战略定义始于正确的需求收集。要成功做到这一点，识别组织内能够理解需求并有效跨所有不同业务单位合作以减少选择错误方法和解决方案风险的合适人员至关重要。但是，谁才是合适的人呢？

我们是在讨论来自业务方面的人（例如，首席执行官或首席财务官[CFO]），还是依靠 IT 团队（例如，首席信息官[CIO]，首席技术官[CTO]，首席数据官[CDO]等）？嗯，这实际上取决于组织的情况。我们看到了许多不同的方法，但一个共同的主题是：当直接由业务支持时，这种转型旅程通常拥有最高的成功率。为什么？很多时候，IT 组织可能只被授权保持事务运行并每年降低成本。如果您的利益相关者仅来自 IT 部门，他们的激励与如果您的利益相关者包括需要开发新产品、吸引更多客户或从根本上改变业务的 BU 中的人是非常不同的。

通过将新数据平台的定义提升至不仅仅是一个纯粹的 IT 活动，您可以提高转型的可见度，并确保新平台使组织能够解决以前无法解决的许多业务问题（例如实时分析）。

即使在支持该倡议的公司部门内部，也极为关键地需要来自所有参与者的全力支持。但这些人可能非常忙，没有足够的时间和专业知识来投入到这个转型项目中。因此，另一个关键问题是：公司是否拥有足够内部人员（具备正确技能和经验）来支持该倡议？还是需要从公司外部找人来引导项目朝正确方向发展？这不仅仅是技术知识的问题，还涉及领导力和管理，以确保数据平台的设计和实施成功，业务成果积极。

变更管理

一旦确定了目标和应该朝向目标努力的人员，接下来您必须为变更管理定义一项策略。组织可以拥有最具野心的目标，由最有影响力的人支持，但如果没有明确的使命来有效地沿链路传递消息，实施项目将非常困难。

当接受像数据驱动转型这样的项目时，我们看到很多公司忽视了转型的文化方面，将其仅仅视为一个技术项目。业务用户和一般将利用数据平台的员工，应准备好接受这种变革，而这只能通过适当的流程和正确的技能来实现。

如图 Figure 2-2 所示，变更管理是人、技术和过程的交汇点：

人与技术

对于组织内新资源的全面培训计划至关重要，以使员工能够有效利用这些资源。这可以由公司自行实施（内部交付），也可以由合作伙伴实施（外部交付）。组织越重视提升员工技能，就越能成功地实现其整体业务目标。

人与过程

这始终是领导力的问题。公司内的领导必须推动整体信息传递；当人们受到领导激励时（这也与利益相关者的重要性有关！），采纳程度就会提高。我们看到很多项目因启动方未能提供适当支持而失败。领导必须通过多个内部活动来正确传播信息，帮助员工接受变革。一些常见问题包括：团队结构如何？是否得到高层赞助？云项目的预算、治理和评估如何进行？

过程与技术

这与组织利用云原生服务进行扩展的能力相关。一些常见问题是：组织在多大程度上通过托管和无服务器云服务来抽象基础设施？自动化流程的实施水平以及运行其中的可编程基础设施代码如何？自动化对成功至关重要，因为它不仅减少了人力投入，同时有助于进行低风险且频繁的变更，这是创新的关键要素之一。

成功需要这三个要素紧密协同工作。许多组织通过建立一个名为“卓越中心”（CoE）的专门团队来实现这一点，该团队的目标是在人、过程和技术的和谐方向上设定方向并推动公司发展。我们将在 第十二章 中通过一个具体的例子重新讨论这个概念。

图 2-2. 人、过程和技术共同努力实现成功

第二步：通过采用云方法降低总拥有成本

对于大多数企业来说，制定战略后的第一步是定义（并找到）预算。将企业的数据仓库和数据湖迁移到云端可以大大节省传统实施成本。让我们看看其中的原因以及如何实现最大的节省。

为何云端成本更低

将数据迁移到云端可以通过几个因素节省费用：

减少运营成本

在企业内部，您的公司承担了操作系统的全部成本，并且大部分维护工作是手动完成的。另一方面，云服务提供商（我们称之为超大规模云服务提供商）已经建立了非常高效的方式来管理大型机群。例如，亚马逊通过运行世界上最大且最可靠的网站之一，并且在非常低的利润率业务中提供云基础设施，积累了丰富的经验。同样，谷歌运行了九项服务，这些服务必须非常高效地运行，因为每项服务（如搜索、Gmail 和 YouTube）每天有超过十亿用户免费使用。公共云的用户因云服务操作中内置的高度自动化而受益于低成本。由于大多数活动（如硬件维护、安全检查、软件包更新等）在幕后自动管理，大多数云服务无需维护。

计算和存储的合适规模化

与购买符合预期峰值使用的设备不同，云服务提供商允许根据需求和使用量扩展计算资源。例如，您可以从小规模系统开始，并随着报告数量的增加逐步增加机器数量。这一优势不仅适用于来自云服务提供商（如 Amazon EMR、Google Cloud Dataproc 和 Azure HDInsight）的服务，还适用于在云基础设施上运行的第三方工具，如 Databricks 或 Teradata Vantage。

工作负载的自动扩展

许多云服务（例如 Azure Cosmos DB、AWS Aurora、Google Cloud Composer、Snowflake 和 Actian Avalanche）允许您在高峰时段分配更多机器，在低峰时段减少机器数量。请注意，我们说的是减少机器数量，而不是降至零。尽管在低峰时段完全关闭服务可能很诱人，但请考虑您是否真的希望保留传统的实体模型。希望您公司的网站不会在夜间关闭。您的后端系统也不应如此。在夜间保留处理偶尔紧急请求的能力通常能带来显著的回报。

无服务器工作负载

一些现代云服务（例如 Google Cloud 平台上的 BigQuery，AWS 上的 Athena，Azure Functions）是无服务器的——您只需提交代码，系统会为您执行。将无服务器系统视为一个共享给所有超级承载商客户的自动扩展集群。因此，无服务器系统带来了操作云基础设施的成本优势，全面提升了栈。由于劳动力往往是 IT 预算中最昂贵的项目，无服务器云服务导致了最具成本效益的解决方案。请注意，许多供应商将其自动扩展服务定位为“无服务器”，因此您应验证所涉服务是否真正无服务器——只有在它是多租户的情况下，您才能获得无服务器的成本优势。如果集群属于您，您将需要管理该集群（例如，了解谁在集群上运行什么作业及何时运行），因此您将无法获得无服务器解决方案所带来的劳动力成本优势。

现在您对为何云端成本较低有了更好的理解，让我们来看看如何估算您可能实现的节省金额。

节省了多少？

在图 2-3 中，我们展示了我们在一个真实数据湖上进行的概念验证（PoC）的结果。我们首先将工作负载不加修改地移到了云端，然后放在了自动扩展基础设施上，并最终进行了现代化。我们测量了云端成本会是多少。因为这是一个概念验证，系统在这些配置下运行的时间不足以测量运营这些系统的人员成本。

图 2-3. 操作 100 节点数据湖的月度成本（以 USD 计），不包括运营系统的人员成本

实际节省金额会有所不同，当然，这取决于您平台和工作负载的具体细节。粗略估计，将工作负载不加修改地迁移到云端通常能节省约 10%的成本。添加适当规模调整通常可以额外节省 5%。自动扩展通常能节省 40%，而无服务器方案则额外增加 30%的节省。如果您利用了所有这些节省方式——例如，将在本地使用 Hive 的工作负载改为在云端使用无服务器解决方案——成本节省可能高达 95%。在迁移工作负载到云端之前，分析源工作负载是至关重要的。在某些情况下，纯粹的提升和迁移可能并不划算，因为工作负载是为了利用本地环境的特定硬件功能而开发的。在这些情况下，评估更新代码（如果可能的话）以现代化工作负载，并使其能够利用自动扩展和无服务器功能，变得尤为重要。

云服务何时有助于成本节省？

所有这些都加剧了基本的云经济学。忽略定价折扣的影响，同样的成本用于在 10 台机器上运行 10 小时的作业，与在 100 台机器上运行 1 小时的作业或在 1,000 台机器上运行 6 分钟的作业是相同的，或者在多租户集群中为您提供 6 分钟内访问 1,000 个“热”实例的能力是使无服务器如此具有成本效益的原因。当然，这不仅仅是成本问题——今天需要 10 小时才能完成的操作，结果在 6 分钟内就可以得到，这带来的商业价值往往远远超过计算成本的增加。

什么样的工作负载不会从整体迁移到云上受益？从一般的角度来看，任何类型的工作负载都可以成为云环境的潜在目标，以获取前面提到的所有好处。在某些情况下可能会更适合混合方法（例如，在本地环境中的一部分工作负载和其余部分在云中），我们将在第九章深入探讨：让我们考虑一种一致的工作负载（即不需要增长且没有峰值），大规模且非常特定，例如全球范围的数值天气预报模型。在这种情况下，有一部分工作负载需要专用硬件（例如共享内存、高速互联），这消除了云的即时硬件成本优势，以及需要理解天气模型的专业操作人员，并且它几乎每天经历相同的负载。这部分可以保留在本地，同时可以立即从云采纳中受益的其他配套元素（例如数据备份）。

短暂和峰值工作负载往往最能从云迁移中受益，主要通过减少耗费宝贵时间进行资源配置的需求。短暂和峰值工作负载还将从自动缩放和按需支付的云经济学中受益。因此，在基于成本的云迁移优先考虑时，首先考虑短暂和峰值工作负载。

此外，与云计算相关联的员工流失风险也减少了，因为技术栈是众所周知的，企业支持是可用的。另一方面，使用定制数据中心，您的 IT 部门可能会被网络电缆所困扰！

步骤 3：打破信息孤岛

一旦您将所有数据迁移到云上，您可以开始考虑如何从中获得更多价值。从数据中获得价值的最佳方法之一是打破数据孤岛。换句话说，避免拥有多个、不连贯的、有时不可见的数据集。我们现在处于图 2-1 金字塔的第三层。

打破数据孤岛涉及在分散化和价值之间取得适当的平衡。分散化是好的，因为数据质量随着数据远离领域专家而降低。因此，您必须让领域专家对数据有控制权。不要将数据集中在 IT 部门。与此同时，请记住，通过组合您在整个组织中甚至合作伙伴共享的数据，您可以获得最大的 AI/ML 价值。打破组织不同部分之间的壁垒至关重要。

如何解决这个难题？如何让组织的不同部分保持对其数据的控制，同时允许任何有权限的人访问数据？我们在接下来的部分探讨如何做到这一点。

统一数据访问

不会起作用的方法是让每个团队将其数据放在一个集群上，然后管理对该集群的访问。相反，请将数据集中存储在云上。请注意，集中存储位置并不意味着集中所有权结构。例如，数据可以存储在 Azure Blob Storage 上，但每个部门都可以将“他们的”数据放在“他们的”存储桶中。

访问数据应通过云服务提供商的 IAM 进行管理。避免使用像 LDAP 或 Kerberos 这样的本地认证机制转移到云端的诱惑。如果需要维护混合基础设施，则将本地 Kerberos 角色映射到云 IAM。如果使用需要自己的认证机制的软件（例如 MySQL），请使用认证代理以避免登录机制的扩散。避免使用既不提供 IAM 也不提供 IAM 代理的软件。长期来看，无论软件的近期好处如何，数据和见解锁定都会给您带来很多痛苦。

如果您正在使用多云解决方案，请确保标准化 SaaS 单点登录（SSO）认证机制，如 Okta，然后将 Okta 认证映射到每个云的 IAM。另一种方法是，如果您有一个“主要”云端，可以将该云端的 IAM 与其他云端进行联合：例如，如果 Azure 是您的主要云端，但您希望在 Google Cloud 上执行一些数据工作负载，您可以将 Google Cloud Identity 联合到 Azure Active Directory 上。

确保根据实际用户提出请求进行数据访问审计，而不是通过破坏与个人用户之间联系的服务帐户。由于隐私和政府对数据访问的监管规定持续变得更加严格，请避免使用任何以其自己的云项目运行或以不透明方式读取数据的软件。

这意味着每个部门都会管理和分类他们的数据。例如，他们可以将数据仓库中的某些列标记为包含财务数据。数据治理政策可能规定只有会计部门的人员和副总裁及以上人员才能查看财务数据。这一政策由 IT 部门（而非数据所有者）通过云 IAM 实施。

不要陷入集中控制数据以打破孤立的诱惑中。数据质量与您离开领域专家越远就会降低。您需要确保领域专家创建数据集并拥有桶。这允许本地控制，但通过 Cloud IAM 角色和权限控制对这些数据集的访问。即使数据准确性的责任属于领域团队，使用加密、访问透明度和掩码/动态技术可以帮助确保组织范围的安全性。

选择存储

您应该将数据存储在哪里？

在优化了 SQL 分析的位置存储结构化和半结构化数据。Google BigQuery，AWS Redshift，Azure Synapse，Actian Avalanche，Snowflake 等都是不错的选择。这些工具允许您集中数据，仍然由不同团队管理不同数据集，但作为同一大型 DWH 的一部分。

另一种选择是将结构化或半结构化数据存储在像 Parquet 这样的开放格式中，使用像 Apache Iceberg 或 Databricks Delta Lake 这样的分布式表格式，放在 AWS S3 这样的云块存储之上。虽然在 SQL 分析中，将数据存储在这些开放格式中可能会导致性能有所下降（与像 BigQuery 中的本机存储机制 Capacitor 相比），但存储成本较低以及支持非 SQL 分析（如 ML）的灵活性可能会使这成为一种值得的权衡选择。

非结构化数据应存储在优化了从各种计算引擎（如 Spark、Beam、TensorFlow、PyTorch 等）读取的格式和位置。目标是使用标准的云友好格式，如 Parquet、Avro、TensorFlow Records 和 Zarr，并将文件存储在 Google Cloud Storage、Azure Blob Storage 或 AWS S3 上。逗号分隔值（CSV）和 JavaScript 对象表示法（JSON）易于阅读并且相对易于处理，因此也有它们的位置。

注意

如果数据由完全托管的服务持有，请确保您可以直接、实时访问数据，而无需经过其查询接口。例如，在使用 Databricks 时，您可以选择将数据存储为任何云存储上的 Apache Parquet 文件。另一个例子是 BigQuery，它提供了一个 Storage API，可以直接读取列式数据，而不需要经过其查询接口或导出数据。

根据数据类型选择存储层的建议可能会让人感到意外。您应该将“原始”数据存储在数据湖中，将“清洁”数据存储在 DWH 中吗？正如在第一章中提到的，数据湖和 DWH 正在融合，将它们分开处理不再有意义。相反，您需要考虑数据的特性以及您将要在数据上执行的处理类型。如果您的“原始”数据是结构化的，则将位于 Redshift/BigQuery 中，如果是非结构化的，则将驻留在 blob 存储服务中。

通常，每个分析数据集或存储桶都位于单个云区域（或多个区域，例如欧盟或美国）。我们将这样的存储层称为分布式数据层，以避免陷入湖库辩论。

鼓励团队广泛访问其数据集（“默认开放”）。数据所有者控制访问权限，并负责对符合组织范围数据治理政策的数据进行分类。专业团队还可以标记数据集（用于隐私等）。数据集的权限由数据所有者管理。提升您的工作人员技能，使他们可以发现和标记数据集，并构建集成管道，持续扩展您的分布式数据层的广度和覆盖范围。

语义层

当您建立民主化的数据文化时，可能会出现一个副作用，即可能开始出现分析孤立。同一个变量在组织的不同部分可能会被称为不同的列名。每次计算关键绩效指标（KPI）都是计算错误或不一致的又一机会。因此，鼓励数据分析团队建立语义层¹（以标准化词汇并在其他地方重复使用 KPI 计算）并通过其施加治理 — 见 图 2-4。

图 2-4. 跨不同领域确保统一 KPI 和定义的全局逻辑语义层

类似 Looker、Informatica、Collibra、AtScale 和 Cube 这样的工具可以帮助定义和标准化语义层。使用这些工具的优势是可以在多云和本地环境之间跨越。因此，您可以在所有环境中标准化数据治理。在云中，通过底层数据仓库执行实际查询，因此在使用这些工具创建仪表板时不会有数据重复。

不要复制数据。提取和复制会增加安全风险，使数据依赖关系难以追踪，并降低分析的及时性。建立轻量级语义层，并将计算带到单一数据源。

注意

无论您将数据存储在何处，都应将计算资源带到数据中。例如，您可以将数据存储在 Azure Blob Storage 中的 Parquet 文件中，并使用 Databricks 或 HDInsight 使用 Spark 处理数据。将计算与存储分开，并根据工作负载进行混合匹配。例如，您的结构化数据可以在 BigQuery 中，但您可以选择使用 BigQuery 中的 SQL 进行处理，云数据流中的 Java/Python Apache Beam，或者在 Cloud Dataproc 上使用 Spark。

还有一个趋势是在不同环境中提供一致的控制面板。例如，Google 的 BigQuery Omni 允许您在 AWS S3 存储桶、Azure Blob 存储和 MySQL 中处理数据，都通过 BigQuery 界面。像 Informatica、Collibra、Looker 等工具为不同云和本地环境中的数据提供了一致的界面。

正如您所见，消除信息孤岛是解锁数据力量的关键步骤，因为它能提升可见性并促进团队更好的协作。现在让我们看看如何进入下一步，以更快的方式利用您手头的大量数据。

步骤 4：更快地在上下文中做决策

业务决策的价值随着延迟和距离的增加而降低。例如，假设您能在一分钟或一天内批准贷款。一分钟批准远比一天回转更有价值。同样，如果您能做出考虑到空间上下文的决策（无论是基于用户当前居住地还是当前访问地），那么这种决策比没有空间上下文的决策更有价值。因此，您的平台的一个重要现代化目标应该是能够在不复制数据的情况下进行地理信息系统（GIS）、流媒体和机器学习（ML）。前面部分的原则，即将计算带到数据中，也应适用于 GIS、流媒体和 ML。

从批处理到流处理

在我们合作的许多组织中，数据的大小每年增加 30%至 100%不等。由于复利的力量，这意味着在未来五年内需要规划 4 倍至 32 倍的数据增长。

在数据量显著增加的情况下，一个反直觉的方面是，随着数据量的增加，更频繁地处理数据开始变得有意义。例如，假设一个企业基于其网站流量创建每日报告，并且这份报告需要两小时才能生成。如果网站流量增长了 4 倍，那么生成报告将需要八个小时，除非企业将工作机器的数量增加四倍。与此相反，一个使报告更及时的方法是每天四次计算六小时的数据统计，并汇总这些报告以创建每日报告，如图 2-5 所示。这两种方法的计算成本几乎相同，但第二种方法能带来显著的商业利益。延伸这种方法，有一个不断更新的仪表板是合理的——您可以看到最新的 24 小时汇总数据。随着数据量的增加，许多企业进行这种对话，并从批量数据处理转向流数据处理。

图 2-5。扩展处理可以降低延迟、减少峰值和减少计算开销

上下文信息

加速决策的另一个关键因素是自动化。随着数据质量的提高，或者企业将焦点转向长尾客户，减少用户体验中的摩擦变得越来越重要。经常使用您产品的专业用户可以容忍比偶尔使用的不那么复杂的用户更多的问题。能够捕捉到沮丧的用户并为他们提供上下文帮助变得重要。

实时、基于位置的可视化越来越成为决策的方式。在许多情况下，这些可视化是内置到用户正在使用的应用程序中的。例如，Shopify 为供应商提供显示其店铺表现的图表和图形。为了以规模做到这一点，这些图形实际上是嵌入到网站中，而不是作为独立的仪表板产品。确保位置信息成为数据模式的一部分是最佳实践，无论是店铺的位置还是交付卡车的位置。因此，如果您的模式包括地址，请确保模式要求地址进行地理编码并以规范形式呈现。在数据集中事后添加干净的地理信息非常困难。

成本管理

虽然很少有技术高管会对上述观点提出异议，但流处理被认为在实施、监控和长期维护上成本高昂²。如何在不超出预算的情况下实现实时决策？

首先，不要构建两个系统，一个用于批处理，另一个用于流处理。相反，将批处理视为流处理的特殊情况。像 Apache Flink 和 Apache Beam（甚至是 Spark Structured Streaming）这样的软件工具使这成为可能。其次，不要自定义构建监控、可观察性、延迟到达、扩展等功能。Flink 和 Beam 是开源技术，但要执行它们，应该利用 AWS 上的 Kinesis 数据分析或 GCP 上的 Cloud Dataflow 等全面托管的服务——这是因为管理和故障排除流处理基础设施的技能相当罕见。

另一种方法是将流处理视为批处理的特殊情况（或反之，正如 Flink 的理念所述）。这些做法试图通过尽快处理微小数据块来进行微批处理。当需要非常新鲜的数据，但不一定是实时的时候，这种方法是有效的。这意味着不能等待一小时或一天才运行批处理，但同时也不重要知道过去几秒钟发生了什么。

接下来，将实时数据传送到支持大规模处理的 DWH 或存储层，为读者提供最新信息。换句话说，只要能实时传送数据，所有对数据的分析都将反映最新信息，而无需进一步努力。

现在你已经看到了如何利用最新和与上下文相关的信息，让我们看看如何融入人工智能/机器学习来更好地理解数据。

第 5 步：利用封装的人工智能解决方案实现跨越式发展

在 2010 年代技术领域最激动人心的发展之一是深度学习的崛起，这是人工智能的一个分支。人工智能包括那些需要计算机作为决策工具的问题类别。通常情况下，人工智能系统是通过编程让计算机像人类一样思考或行动来构建的。为此，专家的思维过程必须被精确地编码为计算机可以遵循的规则。由于人类经常无法准确解释他们的判断，这样的专家系统很少表现得非常出色。

机器学习是一类人工智能技术，它不再捕捉人类的逻辑，而是向机器学习“模型”展示大量正确的决策，并期望该模型推断如何在未来做出正确的决策。因为收集数据比捕捉逻辑更容易，机器学习能够解决各种问题。然而，数据通常必须是结构化数据，类似于关系数据库中保存的数据。在 2010 年代中期，一组称为深度学习的技术开始占据主导地位。这些技术使用“深度神经网络”，能够理解图像、语音、视频、自然语言文本等非结构化数据。这反过来促成了像谷歌相册（即使用自然语言查询搜索图片的能力）或亚历克斯（即通过自然语言处理进行交互）等技术的发展。在企业中，深度学习还使组织能够从产品目录和用户评价等非结构化数据中提取信息。预建的生成式人工智能解决方案正在逐渐为企业使用情景（如内容创作、客户体验、编程协作伴侣和其他工作流辅助工具）所接受。

由于人工智能变得更加成熟，你不再需要在组织中投入大量工程时间来构建人工智能能力。相反，你可以通过购买或定制许多人工智能解决方案来利用人工智能的好处。这些解决方案可以分为几类：预测分析、数据理解与生成、个性化以及封装的解决方案。

预测分析

ML 模型是从正确决策的示例中进行训练的。企业数据仓库通常是这类训练示例的重要来源。例如，假设您从事购买二手车、修复并销售的业务。您希望创建一个系统来估算在拍卖会上购买的车辆维修成本。显然，您的业务历史数据是对您购买和修复车辆的实际维修成本的良好来源。换句话说，您的数据仓库中存在历史数据的正确答案（见图 2-6），可以用来训练 ML 模型。训练好的 ML 模型随后可以用于预测随后拍卖的车辆的维修成本。

图 2-6. 企业数据仓库是 ML 模型训练示例的来源

如检测欺诈交易或估计机器故障时间、广告点击率、销售商品数量、顾客购买意愿等问题，都属于预测分析问题的例子。这些问题可以通过训练模型，使其基于已捕获的其他因素来预测历史记录中的一个值。

理解影响维修成本的因素，并将组织中与此估算相关的所有数据引入数据仓库，是成功进行预测分析的先决条件。一旦建立了企业数据仓库（DWH），就可以使用大量预先构建的预测解决方案来创建必要的模型。事实上，像 AWS Redshift 和 Google BigQuery 这样的数据仓库提供了在不将数据移出数据仓库的情况下训练自定义 ML 模型的能力，分别通过连接 AWS SageMaker 和 Google Cloud Vertex AI 实现。

理解和生成非结构化数据

如从视网膜图像识别眼病、从交通摄像头检测非法左转、从视频中转录文本以及从评论中识别滥用语言等问题，都是利用 ML 模型来解释非结构化数据（图像、视频或自然语言）的例子。

深度学习彻底改变了对非结构化数据的理解，每一代模型的进步都将错误率降低到产品如 Google Home 中的问答、Gmail 中的智能回复以及 Google Photos 中的照片检索极其准确的程度。

与预测分析不同，理解非结构化数据很少需要创建和训练模型。相反，可以直接使用像 Azure Vision API、Google Video Intelligence API 和 AWS Comprehend 这样的预构建模型。使用这些 API 来丰富你的数据。例如，即使没有机器学习知识，开发者也可以使用 Google 的 NLP API 提取评论的情感，并将情感作为额外列添加到你的数据仓库中。

如果这些预构建模型提供的标签不足以满足你的用例怎么办？也许图像识别 API 返回的响应表明图像中有一个螺丝，但你希望 API 返回的是你的目录中的项目编号#BD-342-AC。即使在这种情况下，也不需要从头开始训练模型。像 Google Cloud、Azure、H2O.ai、DataRobot 等提供的 AutoML 模型（即针对某个问题领域（如图像识别）的标准机器学习模型，可以用自定义数据进行训练）只需在自己的数据上进行微调，就可以进行定制，通常只需几十个样本即可。AutoML 模型适用于图像、视频和自然语言。利用它们，可以获得高质量的定制 API，满足你的问题需求。

除了解释非结构化数据外，人工智能技术还有生成数据的能力。称为生成式人工智能（我们将在第十章进一步讨论），它可以用于生成文本、图像、语音、音乐和视频。在这里，也存在预构建的（“基础”）模型，这些模型已经能够解决各种问题（称为零样本学习）。这些模型通过云供应商（Azure OpenAI、Vertex AI）和独立供应商（如 OpenAI、Anthropic、Midjourney、Cohere 等）的 API 提供。

在许 在许多企业用例中，将数据和机器学习平台与生成式人工智能模型集成是必要的，以便将模型“嵌入”到现实中。例如，只需通过传入一些示例（称为少样本学习）和制作适当的输入（称为提示），就可以定制基础生成式人工智能模型的行为。这些示例可以从数据平台获取。像 Hugging Face 和 LangChain 这样的框架提供了开源解决方案，解决诸如基于企业文档的问答等特定问题。这涉及从数据平台通过向量相似度搜索检索适当的文档，然后在机器学习平台上运行链条。有时，这些服务在云上作为完全托管的解决方案（例如，Google 企业搜索）提供。最后，可以针对特定任务（称为有监督的微调）对这些基础模型进行微调，云服务提供商通过他们的机器学习平台提供此功能。

个性化

机器学习不同于为所有用户提供完全相同的产品，它提供了提供更为个性化体验的机会。例如，客户细分、定位和产品推荐等问题属于个性化范畴。

个性化是由您客户的历史行为驱动的。例如，如果您是零售商，您可以基于其他人的行为（“购买此商品的人还购买了…”）、基于他们自己的购买历史或基于商品相似性向用户推荐产品。所有这些信息都包含在您的企业数据仓库中（或至少可以）。因此，您可以基于存储引擎为推荐引擎提供动力。

Google BigQuery ML 确实有一个推荐模块，Google 的推荐 AI 则基于 BigQuery 数据运行。同样，Azure Machine Learning 中的推荐模块则基于 Azure Synapse 运行。

在本节考虑的所有三类 AI 中，都可以在几小时到几天内快速建立原型。模型已经存在；数据需求并不繁琐，您可以通过一次点击或单个 SQL 查询训练 ML 模型。

封装解决方案

除了前面讨论的个别 ML 模型和技术之外，还应该注意解决特定领域问题的封装解决方案。

例如，通过自然语言进行交互的对话 AI 能够准确处理常见的例行问题，如查询营业时间或预订餐厅。对话 AI 现在能够向呼叫中心支持代理人的屏幕推荐答案。这类解决方案可以轻松集成到企业的电话系统中。

例如订单到现金、库存管理、货架出库识别等解决方案，都可以直接集成到您的业务中。毫无疑问，在您阅读此文时，会有更多的封装和即插即用解决方案可用。我们鼓励您通过采纳这些封装解决方案，跨越当前技术堆栈能实现的限制。

步骤 6：操作化 AI 驱动的工作流程

您的数据平台战略的最后阶段是超越简单的预测和决策，实现端到端工作流程的自动化。您希望能够以完全自动化和自主的方式解决业务问题。例如，您不仅仅希望预测下一次机器故障的时间；您希望在机器故障之前安排维护。事实上，您希望以最佳方式进行，以降低运营成本，延长机器寿命，并确保维修设施不会不堪重负。要实现所有这些目标，首先必须明确您组织内希望拥有的自动化水平（例如，完全自动化还是仅辅助？），然后需要专注于建立数据文化，为实现您的 AI 愿景铺平道路。最后但同样重要的是，您需要加强数据科学家团队，他们是实现您 AI 愿望的动力源泉。

确定自动化和辅助之间的合理平衡

根据我们的经验，许多组织通常以一种临时的方式做出许多决策。如果他们采用数据驱动的方法，并投资于更系统地做出这些数据驱动决策，他们将获得丰厚的回报。

这样的系统自动化是打破信息孤岛、获得数据整合视图并做出建议的一个原因——正如图 2-7 所示，这是数据转型旅程的逻辑终点。随着企业数据成熟度的提升，领导层需要鼓励企业从一个阶段向下一个阶段迈进。

图 2-7. 企业数据成熟度提升

要实现这种增长的成熟度，高管和员工都需要明确最终目标是什么。是决策的全面自动化吗？是 AI 引导的决策吗？换句话说，人类是否完全不参与？还是他们处于“上级”地位？

例如，考虑谷歌地图生成导航指令与您国家的空中交通管制系统生成导航指令的差异。前者是无人参与的例子。它是完全自动化的。在空中交通管制的情况下，系统提供指导，但最终导航指令是由人类发出的。当然，在两种情况下，人类都会接收并执行导航指令。

自动化与辅助之间的正确平衡通常需要组织进行相当多的实验后才能确定。它因行业和组织而异。相对混合通常是同行业不同企业竞争的方式之一。因此，产品管理通常主导此过程，而非工程。

建立数据文化

组织需要建立应用程序和系统来实现最终目标，无论目标是完全自动化还是为专家提供帮助。构建这样的系统将需要组织内树立数据文化。

仅仅建立分析数据平台是不够的。还需要将组织的文化转变为数据驱动的实验成为常态，并且成功的实验得到操作和扩展。

构建数据文化 对于释放创新至关重要，因为这将增强组织内的数据素养，传播处理数据所需的知识。仅仅因为您建立了一个能够打破数据孤岛的平台，并不意味着它们会被打破。仅仅因为可以以数据驱动的方式做出决策，并不意味着旧的经验法则会轻易被抛弃。

成功的组织进行转型计划，涉及向其整个创意人才提供数据工具培训（如商业智能仪表板和嵌入式分析）。他们试图改变员工的奖励方式，鼓励承担风险和创业精神。他们试图建立衡量业务重要指标的方法。最后，他们试图为员工提供数据工具，以便他们能够促成变革。

建设您的数据科学团队

您的组织需要通过数据平台来实现其数据和人工智能投资的价值，因此需要启用几种角色：数据工程师、数据科学家、机器学习工程师、开发人员和领域专家。除非所有这些群体都在您的数据平台上积极合作，否则无法说您已经建立了一个未来准备好的数据平台。

数据工程师负责数据的摄取、准备和转换。他们使用 ETL 工具将数据落地到数据仓库（DWH）。他们监控数据管道，确保管道正常运行且不会破坏数据源。

数据科学家进行数据分析，帮助决策者了解业务的表现情况，回答假设问题，建模结果，并创建创新模型。在这里，产品管理团队是一个关键的决策者。数据科学团队进行分析，帮助产品经理评估产品路线图上不同项目的投资回报率。例如，农业技术公司的数据科学家可能回答有关不同种子每英亩产量以及它们如何依赖土壤类型的问题。他们可能回答假设问题，例如如果商店的产品组合改变为某种种子比另一种更多，预期利润会是多少。他们还可能建模回答如何提高小型店铺供应能力的问题的答案。最后，数据科学家可能会分解业务策略，例如创建个性化的收获计划，并构建组成模型。

一旦模型创建完成，需要定期运行。ML 工程师将整个工作流封装在 ML 管道中，并确保以可监控的方式执行。模型在弹性（模型是否在运行？是否处理所有请求预测的用户？）和准确性（结果是否正确？）方面进行监控。模型随时间漂移。有时这是因为环境本身发生变化（新类型的害虫开始影响某种类型的种子，因此其产量估计不再有效），有时是因为用户适应了模型（农民开始根据对应种子品种价格变化调整种植大豆而非玉米，从而改变了对某些类型肥料的需求）。ML 工程师寻找这种漂移并用新数据重新训练模型。这被称为 MLOps。

部署的模型可作为 API 提供。开发人员调用模型，并将其结果展示在最终用户使用的应用程序中。

领域专家，也称为业务分析师，利用预测分析来实现数据驱动的决策。数据科学家观察专家们的决策，并寻找加快决策过程的方法，通过打破阻碍数据常规访问的数据孤岛来实现。他们使用打包的 AI 解决方案来丰富数据，从而继续数据驱动创新的循环。

第 7 步：数据的产品管理

要最大化从数据中获得的影响力，请应用产品管理原则。³ 几年前，许多高管所说的“将数据视为产品”的意思是，他们希望直接变现他们的数据，例如通过在数据市场上出售。然而，如今这样的市场主要包含由专门整合多来源数据的公司创建的数据（例如零售流量、信用卡收据、产品评论）。很少有公司成功变现其第一方数据。

那么，当今一家典型企业希望将数据视为产品时，这意味着什么？

将产品管理原则应用于数据

我们推荐的思考方式是将期望的结果与实现这一结果的过程结合起来。期望的结果是，通过将数据视为产品来最大化组织从数据中获取的影响力，而上述定义中突出的特征（有用性、标准化、治理）在此非常重要。我们对数据产品的看法是广义的——数据集是符合条件的，但数据管道、仪表板、依赖数据的应用程序和 ML 模型也是如此。

期望结果仅在伴随着实现路径时才有价值。要将数据视为产品，在构思和构建数据产品时应用产品管理原则。什么产品管理原则？（1）有产品战略，（2）以客户为中心，（3）进行轻量级产品发现，以及（4）专注于找到市场适配度。我们建议采用 10 种数据实践（参见图 2-8），与这些原则保持一致。

图 2-8. 产品管理数据

1. 理解并维护企业数据流图

产品经理的一个关键工作是简化。将数据视为产品意味着数据产品团队维护业务中数据流的高级模型，可供发现时轻松传达。您需要在多个粒度级别维护此映射。

假设你有一个电子商务网站。在电子商务网站的最高层次上，它可能是：

• 网络流量

• 产品目录

• Web 内容

• 订单

• 库存

• 客户调查

在更精细的层次上，Web 流量可能会被分解为会话数据、页面数据等。捕获每个数据集是如何收集的，它是如何处理的，可以访问它的角色是谁，以及如何访问，是否包含个人可识别信息（PII）或其他属性，做了什么质量保证等。还要捕获每个数据集的生产使用案例。随着从更高层次到更低层次的转变，映射开始包括数据平台实施的细节。它开始成为数据目录。

2. 确定关键指标

数据目录只是当前存在的记录。它不包括为何数据重要或数据是否适合特定目的（除非您利用临时标签来做到这一点）。它不告诉您需要改进什么。您的数据产品战略的重要部分是在企业中对关键指标达成一致——您将如何测量它们，以及该指标的目标数字是什么（目标会随时间而变化）。您跟踪的指标宇宙应包括：

业务关键绩效指标（KPIs）

数据需要通过何种业务结果来启用？

SLA

数据的可用性如何？数据质量如何？刷新频率如何？

参与度

公司内部数据的广泛使用频率如何？

满意度

客户对可用数据的满意度如何，以及使用起来有多容易（可能是内部客户）？

对于在前一步介绍的假设电子商务网站，业务结果可能涉及增加客户生命周期价值、增加免费版转化率等。向内部采购人员展示的库存的服务级别协议可能是，其可用性为 99.99%，每小时刷新一次，并维持在下周预测销售额之上。您可能希望库存预测不仅被内部采购使用，还被物流团队使用，并纳入仪表板中。您可能还需要衡量预测的库存量被覆盖的频率。

3. 同意的标准、承诺的路线图和有远见的产品积压清单

数据目录是当前存在内容的记录。度量指标捕获您的目标是什么。但这两者都没有解释接下来的方向。

根据客户反馈、利益相关者意见和市场条件，随着时间推移调整产品愿景非常重要。在此期间，您的利益相关者会要求您提供功能和时间表，并期望您信守承诺。为了处理变更和用户反馈，您需要三样东西：

• 优先级标准是利益相关者事先同意的内容，这有助于在产品路线图上实现透明度和买入。

• 产品路线图本身是通过产品发现过程得出的，以便团队避免在没有信息和原型的情况下同意时间表。

• 您认为重要但尚未在路线图上的事项将被纳入产品积压清单中。通常，产品积压清单包括需要解决的客户问题（而非必须构建的功能）。在许多方面，积压清单（而不是路线图）构成了您较长期的产品愿景。组织积压清单以讲述一个清晰的故事。

路线图需要高度的承诺 —— 您应该能够承诺在路线图上的时间表和功能。实现这一目标的好方法是达成优先级标准的一致意见，进行产品发现，并维护产品积压清单。⁴

请回想一下我们的一个假设数据产品（参见前一步），即下周的库存预测，我们需要就如何衡量预测效果达成一致。是罕见出现缺货？是尽量减少采购和存储物品的成本？是仓库级别的缺货？还是公司级别的？这些构成了优先级标准。如果有人要求您定制易腐产品的库存模型，是否值得？您将首先将其添加到产品积压清单中。然后，您将进行产品发现，以确定此类项目的投资回报率 —— 这将包括例如增加/减少仓库制冷成本等成本。只有在您了解其价值后，才会将其添加到产品路线图中。

4. 为您拥有的客户构建

数据团队往往会陷入技术口号中：他们只提供 API，或者坚持所有人将数据发布到他们的企业数据仓库中，或者期望符合单一词典的规范。

借鉴产品管理的经验，深入了解您的客户是非常重要的。他们在构建什么？一个移动应用程序还是一个月度报告？他们了解什么？SQL 还是 Java？他们使用什么工具？仪表板还是 TensorFlow？他们是否需要在数据变更时接收警报？他们是否需要实时数据的移动平均值？他们是否关心测试覆盖率？

然后，以目标客户可以使用的方式提供数据服务。例如，您可以将数据提供给数据仓库（供数据分析师使用），通过 API 可访问（供开发人员使用），发布到特征存储中（供数据科学家使用），或提供可在仪表板中使用的语义层（供业务用户使用）。

如果我们用作示例的假设性库存预测数据产品将由内部购买者（即业务用户）利用，那么预测结果将需要在用于订购补货的应用程序中提供。因此，预测结果可能需要通过 API 让应用程序开发人员使用。

5. 不要转嫁变更管理的负担

变更和冲突是不可避免的。数据的供应商会改变格式；数据的消费者会有新的需求；数据速度会发生变化；同样的数据可能会通过多个渠道提供；由于成本，您的客户可能会转向其他供应商。这些问题不仅仅是变更团队或数据使用团队的问题。

将数据视为产品的重要部分是确保数据用户不要被困在变更管理责任中。尽可能确保演变模式和服务，以便变更对下游用户是透明的。

当不可避免地发生向后不兼容的变更时，对变更进行版本化，并与相关利益相关者合作，将它们从旧版本的数据移至新版本。这可能涉及创建一个迁移团队，其任务是将企业从一个版本迁移到下一个版本。

变更管理的真理也适用于安全性。确保为个人身份识别信息（PII）和合规性构建保障措施，而不是将这一责任转嫁给您的数据产品的用户。

假设我们的假设性库存预测数据产品定制为包括易腐商品的预测。如果这涉及请求关于所售商品的额外信息，您将需要承担确保所有现有商品的商品目录得到增强的责任。这些数据工程工作是项目范围的一部分，它对项目的投资回报率是否值得进行的评估起到了支持作用。

6. 采访客户，发现他们的数据需求

你如何演变产品积压，优先需求，并添加到路线图中？一个重要的原则是确保你不断与客户交流，并发现他们需要解决的问题所需的数据是什么。当前数据产品的哪些问题他们必须解决？这些问题反馈到你的产品积压中，供你优先解决。

在任何新数据产品概念进入产品路线图之前，重要的是通过潜在的（内部或外部）客户验证产品的需求。按规格构建（“构建它，他们就会来”）非常冒险。更安全的做法是构建已经得到客户验证的想法的实现。

你怎么做到这一点？

7. 大量使用白板和原型

与希望获取数据产品的客户一起用白板设计。这样可以确保你在数据平台上达成的内容能够满足他们在质量、完整性、延迟等方面的需求。在构建任何数据管道或转换之前，先与他们一起讨论数据的潜在用途。

其中一个最好的工具是原型。许多数据用例可以通过构建一个最小可行原型来验证。我们是什么意思？如果销售团队认为构建客户数据平台将有助于他们交叉销售产品，请通过从各个产品的销售管道中提取一组记录，手动匹配，并尝试交叉销售所得客户来验证这一点。

我们建议使用原型，以及与最终产品的潜在用户进行的访谈，来界定问题的范围：

• 需要构建的内容：识别一切，从数据管道到项目成功所需的用户界面

• 业务关键绩效指标方面你可以期待的投资回报率

在编写任何代码之前先做这些。只有当你清楚知道需要构建什么以及预期的投资回报率时，才应将项目添加到你的路线图中。在此之前，请将问题保留在你的积压工作中。

对于我们假设的库存预测数据产品，你将通过验证输入模式及其如何与主要产品用户使用预测，检查冷藏仓库可以容纳多少等来做到这一点。你会在编写任何代码之前做这些，也许通过在电子表格中进行预测，并为各种产品的一整套情景进行游戏化处理。

8. 只构建即将立即使用的内容

优先快速投入生产，而不是构建所有必要的功能。这意味着你应该使用敏捷、迭代的过程，只构建立即需要的数据集、数据管道、分析等。不要专注于开发太多没有重大影响的功能：你投入的努力将不值得。

利用产品待办事项捕捉未来需求。仅在确定将使用这些功能的客户并能在白板/原型会议上给您反馈后构建这些能力。

9. 标准化常见实体和关键绩效指标

为常见实体和关键绩效指标提供规范化、丰富的数据集，这些将在业务中标准化。通常，这些丰富的实体支持大量高回报投资用例（例如客户数据平台、内容管理平台）或用于监管/合规目的（例如计算税收的方法）。

通常，您只会有少数这些标准化的数据集和指标，因为这种丰富需要跨业务单元的大量协作，并减少其发布速度。

10. 在您的数据平台中提供自助服务能力

您需要在符合组织的方式中平衡灵活性和标准化。不要在上述标准化步骤中过度。不要构建每个人都可能需要的中心化数据集。相反，使团队能够自给自足。这是将微服务原则应用于数据的方式。

实现这种平衡的一种方式是提供小型、自包含的数据集，客户可以通过与领域特定的其他数据集联接来进行定制。通常，这被实现为数据网格，每个业务单元负责其发布到共享分析中心的数据集的质量。

概要

在本章中，您已经更多了解了组织应该建立的创新数据流程。本章的主要收获如下：

• 通过确定关键业务目标、收集正确的利益相关者，并在整个企业中实施变更管理来创建战略计划。确保您的利益相关者组包括如果采用数据平台将最受益的业务单元。

• 通过迁移到云端来降低总体拥有成本。在这样做时，不要试图复制您在本地环境中做出的技术选择。相反，选择能够自动扩展、分离计算与存储、拥抱无运维操作（NoOps），并且能够支持各种应用程序而无需数据移动的技术。

• 打破数据孤岛，使得整个组织的数据可以被联合起来。确保每个部门都控制其数据并对其质量负责非常重要。然而，所有数据都可以在统一平台上获取，以便实现跨组织访问。

• 通过将数据实时流入数据仓库（DWH）并确保数据访问始终反映最新数据，从而更快地在上下文中做出决策。数据表应在适当的情况下包含上下文元数据，例如位置信息。

• 利用可定制和适应性强的 AI 模型，您无需建立定制的 AI 模型。这些模型有助于预测分析、理解非结构化数据或个性化需求。预测分析和个性化可以从您的数据平台驱动。通过使用预构建的 AI 模型处理，可以将非结构化数据添加到您的数据平台中。

• 扩展至自动化整个工作流程，而非仅限于一次性机器学习模型。这一步骤通常由产品管理团队主导，并且这里的分析常常为产品路线图提供信息。

• 通过雇佣和配置由数据工程师、数据科学家、机器学习工程师、开发人员和业务分析师组成的团队，建立创新文化。

• 使用产品管理原则制定您的数据产品战略：以客户为中心，通过白板绘制和原型设计发现产品，并在标准化与灵活性之间找到合适的平衡点。

在本章中，我们讨论了构建创新数据组织的策略。在下一章中，我们将专注于设计数据分析平台时需要考虑的一个关键方面：现有员工目前具备或将需要掌握的技能。

¹ 提供一种抽象层，为理解数据提供一种统一的方式。它将复杂信息转换为熟悉的业务术语，例如产品、客户或收入，以提供组织内数据的统一和整合视图。

² 请注意，从批处理转换到流处理未必更加昂贵。事实上，长远来看，这可能会为您节省开支，因为您无需通过多次批处理运行多次重新处理相同的数据。您可以选择实时处理。

³ 本节基于 LinkedIn 文章“如何将数据视为产品”，该文章由本书的一位作者撰写。

⁴ 请注意，产品路线图是一个动态的文件，根据市场和业务需求可能会有所变化。

第三章：设计您的数据团队

在设计数据平台时，有几个技术方面需要考虑：性能、成本、运营开销、运营卓越、整合新的分析和机器学习方法等。然而，如果不解决公司文化——新技术需要员工愿意改变他们的心智模型和工作方式——这些技术方面将会被忽视。另一个要牢记的关键方面是现有员工目前拥有的技能以及他们需要掌握的技能。在某些情况下，学习新技能并改变工作方式的员工最终可能会进入不同于数据平台建立前所处角色的新角色。

在本章中，我们探讨了组织如何规划和编排这些关于心智模型、工作流、技术技能和角色的变革。每个组织都是独特的，因此构建数据平台将涉及为每个部门和员工制定细致的计划。在本章中，我们描述了这样一个细致计划在不同类型的组织中可能是什么样子。

数据处理组织的分类

组织可以通过采用基于其人才的不同策略来取得成功。没有普遍适用的“最佳”方法。一个具有强大防守的体育团队应该发挥其优势，专注于防守，而不是试图复制拥有技术攻击手的球队的进攻。同样，如果您的组织拥有强大的数据分析团队，它应该专注于其人员，而不是试图转变为一个充满数据工程师的组织。

根据您的员工技能和使用案例的复杂性，决定您的组织的最佳策略。您是否需要一小部分高能力（并且昂贵）的数据工程师？或者应该利用大量已经存在的数据分析师团队来丰富和转换可以采取行动的数据？这些工作者需要多少领域知识？培训当前工作人员以执行更高价值的工作是否现实？还是应该投资于生成式 AI 或无代码工具，并使这些基础性技术对更大规模的工作人员可用？

技术方法的最佳选择在组织内部也会有所不同——工作人员的构成在销售团队和工厂生产线之间会有所不同。因此，细致计划包括为每个业务单元详细说明最佳的技术方法。从技术上讲，该计划还将在基于标准 ETL（需要 ETL 工具的硬技能）和基于 ELT（需要更普遍 SQL 技能）的方法之间进行选择。

请考虑如图 3-1 所示的传统人物价值链。您可以看到组织中的每个数据用户都拥有一小部分专业技能。如果一个组织希望扩展其数据分析团队的范围，它还必须扩展其数据工程和数据科学团队的规模，以确保有足够的人拥有正确的技术技能来支持数据分析师。

图 3-1. 数据处理：传统人物价值链

公共云提供的新范式为数据处理、数据分析和算法开发打开了新的可能性。云技术使得现在能够采用新的工作方式——分析师可以执行以前由数据工程师管理的批处理或实时数据处理任务，并尝试使用现成的数据科学解决方案。此外，每个人物的潜在范围——他们的技能和职责——也有所增加。随着数据技术变得更加易于访问，数据工作者能够承担新任务并在没有传统人物价值链瓶颈的情况下处理数据价值链。这导致角色技能的融合，使得现有团队更容易扩展到额外的责任。数据分析师专注于使用 ELT 方法和 SQL 代码解决问题，而数据工程师/数据科学家更倾向于 ETL 方法和通用代码（如 Python、Java、Scala 等），二者之间的区别变得不那么明显。混合方法（如图 3-2 所示）变得更为普遍，因为它们可以充分利用 ETL 和 ELT 模式的优势。今天我们看到的大多数组织都属于这种混合模型，尽管角色的平衡和数据处理的 ETL 或 ELT 方式的比例因组织类型而异。

图 3-2. 数据处理：人物框架

简单来说，数据工作者现在能够更高效地利用他们手头的数据。这是因为技术更易于获取，也因为数据工作者能够将他们的技能与其他数据专业人士的技能相结合。这导致了一种更有效率和有效的数据处理方式。

组织可以广泛分类为三种类型：数据分析驱动、数据工程驱动和数据科学驱动。在接下来的几节中，我们将讨论为每种类型建立数据处理组织的理想方式。事实上，公司将包括不同的部门或业务单位，这些部门或单位属于这些类别，因此它们将发现自己应用所有这些策略。一些团队将结合多种角色，因此转型将涉及混合方法。在考虑您的数据团队中将成为不同类型用户时，请记住您在第二章学到的内容：“为了最大化从数据中获得的影响，请应用产品管理原则。”您应始终使用产品管理原则来制定您的数据产品战略，以客户为中心，通过白板绘图和原型制作发现产品，并在标准化与灵活性之间找到合适的平衡。

数据分析驱动的组织

数据分析驱动的组织是一种数据分析师在决策制定中扮演核心角色的组织。需要注意的是，一个组织是否以分析为驱动力不是非黑即白的问题，而是一系列重叠特征的谱系：

成熟的行业

这些组织是知名的、成熟的企业，拥有已经建立（可能是过时的）系统。它们所处的行业通常是成熟且稳定的。主要工作涉及对各种产品或情况进行人工分析。典型的以数据分析驱动为例的组织包括零售商的商品销售部门（例如沃尔玛）和大型银行的商业贷款处理部门（例如摩根大通）。

企业数据仓库（EDW）和批量 ETL

在技术术语上，中央信息枢纽是一种随时间建立起来的企业数据仓库，具有高度的技术债务和遗留技术。在数据仓库内部的数据转换通过诸如夜间批处理等定期 ETL 过程来完成。这种批处理过程增加了数据服务的延迟。

商业智能

组织中的大多数数据专业人员习惯于通过在集中式数据仓库运行 SQL 查询来回答业务问题，使用 BI 工具创建报告和仪表板，并使用电子表格访问类似的数据。因此，内部人才库最熟悉 SQL、BI 工具和电子表格。

注意，即使在零售和金融等成熟行业中，新兴的数字化组织（电子商务和金融科技）可能会寻求捕捉增长最快的数字领域和潜力最大的客户群体。这些数字原住民可能与成熟的参与者（例如 Etsy 与沃尔玛；Paytm 与摩根大通）有不同的工作人员构成；我们不会将数字原住民归类为成熟的参与者。

现在，你对我们所说的以分析驱动的组织有了更清晰的认识，让我们讨论转型的主要杠杆。

视野

要在以分析驱动的组织中民主化使用云数据平台，分析师应能够通过熟悉的界面（如电子表格、SQL 和 BI 工具）进行高级分析。这意味着提供易于使用的工具，将数据带入目标系统，并无缝连接到分析和可视化工具。

这曾经是传统数据仓库的常见做法。使用 SQL 对数据进行丰富化、转换和清洗，使用 ETL 工具来编排流程。同样，物化视图和用户定义函数可以用来在现代数据仓库中丰富、转换和清洗数据。

然而，这假设分析师已经可以访问所有数据源。创建复杂的摄取管道曾经是昂贵且经常令人费力的。因此，由于资源和成本限制，数据管道在数据仓库之外进行管理。

这在新的云数据仓库中已不再适用。摄取的角色现在仅仅是将数据接近云端，转换和处理部分移回到云端数据仓库。这导致数据被暂存到存储桶或消息系统中，然后再被摄取到云端数据仓库中。

所有这些不仅可以减少使数据可用所需的时间，还可以释放数据分析师专注于使用他们习惯的工具和界面寻找数据洞察。因此，在新世界中，应该使用 ELT 取代 ETL 工具——数据分析师可以使用 SQL 编排工具如 dbt 或 Dataform 来串联 SQL 语句执行 ELT。直接从源或暂存区摄取数据允许分析师利用他们关键的 SQL 技能，并提高他们接收数据的及时性。他们不需要等待被淹没的数据工程团队实施 ETL 管道。

总之，扩展云数据平台的最佳方式是为分析师提供易于使用的工具（如 dbt）和界面（如 Excel 或 Tableau），他们可以轻松掌握。这将使他们能够进行高级分析，而不必等待数据工程团队实施复杂的 ETL 管道。

一旦数据在云端数据仓库中可用，就是开始分析的时候了。过去，许多数据分析是通过电子表格完成的，但电子表格往往难以处理新世界中需要分析的大量数据。尽管 Google Sheets 和 Excel 具有连接实时到数据仓库的能力，但仍显得有些笨拙。我们建议分析师可以访问现代 BI 工具来创建可处理大数据集的可视化和报告（例如 Power BI、Tableau 或 Looker）。

人物角色

分析驱动型组织中数据部门的主要角色包括数据分析师、业务分析师和数据工程师。

数据分析师

数据分析师接收、理解并完成来自业务的请求，并理解相关数据。数据分析师旨在满足组织的信息需求。他们负责数据的逻辑设计和维护。他们的一些任务可能包括创建表的布局和设计以满足业务流程，以及重新组织和转换数据源。此外，他们还负责生成有效传达业务请求的趋势、模式或预测的报告和洞察。

要建立面向分析驱动型组织的任务，有必要以两种方式扩展数据分析师社区的经验和技能集。首先，促进数据分析师学习业务的趋势至关重要。数据分析师需要深入了解业务领域。其次，数据分析师需要获取分析和描述数据的技术技能，无论数据的容量或大小如何，使用 SQL 和 BI 工具现在都是可能的。数据分析师的技能扩展到业务和大数据领域在图 3-3 中有所体现。

图 3-3. 数据分析师领域扩展，用于数据驱动策略的开发

业务分析师

业务分析师是使用数据来执行分析洞察的领域专家。

云数据仓库（Cloud-based DWHs）和无服务器技术已将业务分析师的责任扩展到传统上领域专家的范围之外。这是因为分析师现在可以专注于通过分析数据为业务增加价值，而不是浪费时间在行政和技术管理任务上。此外，可以存储在数据仓库中的数据的数量和类型不再是限制因素，因此分析师现在可以更深入地挖掘业务，寻找洞察。

数据仓库既可以作为数据的登陆区域，也可以作为结构化和半结构化数据的记录系统。这意味着业务分析师可以在一个地方获取所有需要分析的数据。总体而言，云数据仓库和无服务器技术使得业务分析师能够更加高效，并为业务增加更多的价值。

尽管业务分析师可以进行无代码和低代码的机器学习模型，但他们在涉及机器学习或自然语言文本的更复杂工作流程中可能会遇到困难。他们也没有实施复杂的数据科学算法（例如排名或推荐）的技能。因此，如果您的激活需求更复杂，仍然需要一个数据科学团队。

数据工程师

数据工程师 专注于下游数据管道和数据转换的最初阶段，如加载和集成新来源。他们还管理数据治理和数据质量流程。

在一个以分析为驱动的组织中，数据工程师的人数将会很少，因为数据分析团队基本上可以自给自足，能够构建简单的数据管道和机器学习模型。分析驱动的组织采用 ELT 而非传统的 ETL 的概念。主要区别在于，常见的数据处理任务在数据加载到数据仓库后处理。ELT 大量使用 SQL 逻辑来增强、清洗、规范化、精炼和整合数据，使其准备好进行分析。这种方法有几个好处：缩短行动时间，数据立即加载，并可同时提供给多个用户使用。因此，这样的组织的变更管理策略必须关注 SQL、视图、函数、调度等方面。

即使在一个以分析为驱动的组织中，数据工程团队通常控制从源系统提取数据的过程。虽然可以通过使用基于 SQL 的工具来简化这一过程，使数据分析师能够完成部分工作，但你仍然需要一个强大的数据工程团队。还有一些批处理作业仍然需要创建数据管道，更适合使用 ETL。例如，将数据从主机到数据仓库需要额外的处理步骤：需要映射数据类型，需要转换 COBOL 书籍等等。

此外，对于实时分析等用例，数据工程团队将配置流数据源，如 Pub/Sub 或 Kafka 主题或 Kinesis 数据流。处理通用任务的方式仍然相同——可以将它们编写为通用的 ETL 管道，然后由分析师重新配置。例如，从各种源数据集应用数据质量验证检查到目标环境将遵循数据工程师设置的模板。

技术框架

一个以分析为驱动的组织的高级参考架构有三个基本原则：

SQL 作为标准

技术应根据当前的组织文化进行定制。无论数据处理流程中的位置如何，都应优先考虑提供 SQL 接口的组件。

从 EDW/数据湖到结构化数据湖

信息系统基础设施及其数据应该集成，以扩展对新的和多样化数据源的分析处理的可能性。这可能涉及将传统的数据仓库与数据湖合并，以消除数据孤岛（有关 lakehouse 架构的更多信息，请参见第七章）。

先读后模式（Schema-on-read）

由于存储成本低廉，您的组织在数据接收前不再需要强加严格的数据结构规则。从写入模式的模式转变为读取模式的模式允许实时访问数据。数据可以保留其原始形式，然后转换为最有用的模式。此外，数据平台可以管理保持这些副本同步的过程（例如，使用物化视图、变更数据捕获等）。因此，请放心保留多份相同数据资产的副本。

结合这些原则，我们可以定义一个高层架构，类似于图 3-4 所示的架构。此信息架构满足上述三个原则，并支持几种关键的数据分析模式：

• “传统”的 BI 工作负载，例如创建仪表板或报告

• 一种临时分析接口，允许通过 SQL（ELT）管理数据流水线。

• 使用 ML 技术启用数据科学用例

• 将数据实时流入 DWH 并处理实时事件

图 3-4. 用于分析驱动型组织的高层信息架构

前两种模式与传统的 SQL 数据仓库世界非常相似，但后两种则以 SQL 抽象的形式提供了更先进的分析模式创新。在 ML 领域，Redshift ML 或 BigQuery ML 允许数据分析师在 DWH 中存储的数据上执行 ML 模型，使用标准 SQL 查询。诸如 Dataflow 和 KSQL 之类的 SQL 流扩展使得能够聚合数据流，与无边界、实时源（如 Pub/Sub 或 Kafka）一起。这项技术使得即使无需投资于新的概要文件和/或角色，也能实现许多可能性。

在为分析驱动型组织选择 ELT 和 ETL 时，数据准备和转换是关键考虑因素。尽可能使用 ELT，因为它允许使用 SQL 在结构化数据湖中进行数据转换。此方法提供了与广泛的数据集成套件相同的功能，但无需牺牲数据质量或操作监控。像 dbt 这样的产品为数据建模和构建数据工作流程带来了软件工程方法；dbt 有效地允许构建类似于代码构建的 ETL 工作流程的 ELT 工作流程，但是使用 SQL 而不是系统程序员。这使得数据分析师（不是系统程序员）能够进行可靠和复杂的数据转换。

简单来说，对于分析驱动型组织，ELT 比 ETL 更好，因为它允许更灵活和控制数据转换。此外，dbt 为数据建模和构建数据工作流程提供了软件工程方法，有助于提高数据转换的可靠性和复杂性。

数据工程驱动的组织

以工程为驱动的组织专注于数据集成。有些公司（例如金融科技领域的 Plaid）的业务就是为整个行业构建集成管道。更常见的情况是这是一个大型企业的一部分。例如，投资公司可能有一个团队，负责从大量供应商那里发现、重新格式化和摄取财务（例如股票市场、公司的 SEC 报告等）和替代（例如信用卡消费、电子收据、零售店客流等）数据。

视野

当您的数据转换需求复杂时，您需要数据工程师在公司的数据战略中扮演核心角色，以确保能够经济有效地构建可靠的系统。数据工程师处于数据所有者和数据消费者之间的交叉点。

业务数据所有者是业务团队的指定联系点，了解业务并为数据架构提供数据。数据消费者专注于从架构中的不同数据中提取洞察力。在这里，您通常会找到数据科学团队、数据分析师、BI 团队等。这些团队有时会将来自不同业务单位的数据合并，并生成成果物（机器学习模型、交互式仪表板、报告等）。在部署时，他们需要数据工程团队的帮助，以确保数据一致和可信任。

数据工程师有以下职责：

• 在建立分析系统和操作系统之间的集成时，传输数据并丰富数据（例如实时使用案例）。

• 从业务单位和外部供应商那里解析和转换杂乱的数据，使其成为有意义且干净的数据，并记录元数据。

• 应用数据运营（DataOps），即将业务的功能知识与应用于数据生命周期的软件工程方法相结合。这包括监控和维护数据源。

• 部署机器学习模型和其他数据科学成果来分析或消费数据。

构建复杂的数据工程管道是昂贵的，但可以增强能力：

Enrichment

数据工程师创建流程，从不同来源收集数据并将其组合以创建更有价值的数据集。这些数据随后可以用于做出更好的决策。

训练数据集

机器学习模型的质量很大程度上取决于用于训练这些模型的数据。通过从多个来源获取数据并统一到准备用于训练机器学习模型的数据集中，数据工程师可以提高数据科学团队的生产力。

非结构化数据

当机器学习模型需要使用非结构化数据（例如评论文本或图像）时，会面临特殊挑战。这类数据通常不像传统的数据仓库使用的严格模式那样遵循严格的模式。此外，它需要清除个人身份信息（例如聊天记录中的电话号码）和不适合工作的内容（特别是图像），并进行转换（例如使用嵌入）。

Productionization

数据工程工作也需要将临时数据科学工作进行产品化，并从中获取价值。没有数据工程支持，数据科学家将被困在实验和针对特定用例制作的应用程序中，这些应用程序很少能够进行产品化或泛化。

实时分析

异常检测和欺诈预防等应用需要立即响应。在这些用例中，数据消费者需要在数据即时到达时进行处理。他们必须在低延迟下执行。这种实时分析需要在目标数据仓库之外进行转换。

前面提到的所有内容通常需要定制应用程序或最先进的工具。实际上，很少有组织的工程能力能够达到真正的工程组织水平。许多组织处于我们所说的混合组织中（见图 3-2）。

人物角色

数据工程师开发和优化所有需要获取数据以及执行相关分析并生成报告的过程。

知识

数据工程角色需要对数据库和编程语言有深入理解，同时具备跨部门工作所需的某些业务技能。无论他们所在的组织规模如何，数据工程师都需要具备某些标准技能才能成功。最有价值的知识包括：

数据仓库和数据湖解决方案

Cloudera 数据平台、Oracle Exadata、Amazon RedShift、Azure Synapse、Google BigQuery、Snowflake、Databricks、Hadoop 生态系统等，数据工程师可以处理海量数据。

数据库系统

像 SQL 和 NoSQL 这样的数据库系统。他们应该知道如何在和操作关系数据库管理系统以进行信息存储和检索。

ETL 工具

传统工具如 Informatica 和 Ab Initio，以及现代框架如 Apache Beam、Spark 和 Kafka。

编程语言

Python、Java、Scala。

数据结构与算法

数据结构与算法允许组织和存储数据以便于访问和操作，这对数据工程师来说是一项至关重要的技能。

自动化与脚本编写

数据工程师应该能够编写脚本来自动化重复的任务，因为他们必须处理如此庞大的数据量（例如，bash、PowerShell、HashiCorp Terraform、Ansible 等）。

容器技术

将数据项目移至生产的事实标准。在本地机器上开发的项目可以“发布”到分级和生产集群（通常）而无需问题。数据管道和 ML 模型可复制，并可以在任何地方以相同的方式运行。

编排平台

由于需要集成的解决方案和工具的激增，像 Apache Airflow 这样的编排工具已成为必需品。

认证衡量数据工程师的知识和熟练程度，与供应商和/或行业标准进行比较，确认个人具备必要的专业知识，能够为企业的数据战略做出贡献。例如，AWS 认证数据分析师、Cloudera 认证专业（CCP）数据工程师、Google 专业数据工程师和 Microsoft 认证：Azure 数据工程师助理。

职责

数据工程师负责确保由不同业务部门生成和需要的数据被摄入到架构中。这项工作需要两种不同的技能：功能知识和数据工程/软件开发技能。这种技能组合通常被称为DataOps（它源自过去几十年内开发的 DevOps 方法论，但应用于数据工程实践中）。

数据工程师还有另一个责任。他们必须帮助部署由数据消费者生成的产品。通常，数据消费者没有深厚的技术技能和知识来单独负责其产品的部署。这对高度复杂的数据科学团队同样适用。因此，数据工程师必须掌握其他技能，如机器学习和业务智能平台知识。让我们澄清这一点：我们不指望数据工程师成为机器学习工程师。机器学习工程是将数据科学家开发的机器学习模型部署到实时生产系统的过程。另一方面，数据工程师建立的基础设施是供他人处理数据使用的，比如数据存储和数据传输。数据工程师需要理解机器学习，以确保传递给模型的第一层数据（输入）是正确的。在推断路径中，当数据工程技能如规模化和高可用性真正需要发挥作用时，他们也将成为关键。

通过负责解析和转换来自各业务部门的混乱数据，或者实时摄入，数据工程师让数据消费者能够专注于创造价值。数据科学家和其他类型的数据消费者不需要关注数据编码、大文件、传统系统和复杂的消息队列配置以进行流处理。将这种知识集中在高技能的数据工程团队中的好处是显而易见的，尽管其他团队（业务部门和消费者）也可能有他们的数据工程师作为与其他团队交互的接口。最近，我们甚至看到创建了由业务单元成员（数据产品负责人）、数据工程师、数据科学家和其他角色组成的小组。这有效地创建了完整团队，拥有从传入数据到影响业务的数据驱动决策的全权负责权。

技术框架

数据工程团队已经需要广泛的技能。不要让他们的工作变得更加困难，期望他们还能维护运行数据管道的基础设施。数据工程师应该专注于如何清理、转换、增强和准备数据，而不是关注他们的解决方案可能需要多少内存或多少核心。

参考架构

摄取层由 Kinesis、Event Hubs 或 Pub/Sub 处理实时数据，而 S3、Azure 数据湖或 Cloud Storage 处理批量数据（参见图 3-5、3-6 和 3-7）。它不需要任何预分配的基础设施。所有这些解决方案都可以用于各种情况，因为它们可以自动扩展以满足输入工作负载的需求。

图 3-5. Google Cloud 上的示例数据工程驱动架构

图 3-6. AWS 上的示例数据工程驱动架构

图 3-7. Azure 上的示例数据工程驱动架构

一旦数据被收集，我们提议的架构遵循传统的提取、转换和加载（ETL）三步流程。对于某些类型的文件，也可以采用直接加载到 Redshift、Synapse 或 BigQuery（使用 ELT 方法）的方式。

在转换层，我们主要推荐 Apache Beam 作为数据处理组件，因为其批处理和流处理的统一模型。Apache Beam 的执行器包括 GCP 上的 Cloud Dataflow，以及其他超大规模服务商上任何托管的 Flink 或 Spark 实现。

在这种架构中，Dataflow 的替代方案是使用基于 Spark 的解决方案，如 Amazon EMR、Databricks、Azure HDInsight 或 Google Dataproc。然而，这些解决方案并非无服务器，运行闲置的 Spark 集群是一笔主要成本。话虽如此，也有提供作为 AWS SageMaker/Glue 的一部分和 GCP 无服务器 Spark 服务的无服务器 Spark 替代方案。主要用例是那些已经在 Spark 或 Hadoop 中拥有大量代码的团队。这些 Spark 解决方案使得直接通向云的路径成为可能，而无需审查所有这些管道。

另一个数据处理的选择是使用无代码环境来创建数据管道，例如由 AWS Glue、Azure Data Factory 或 GCP Data Fusion 提供的拖放界面。传统的 ETL 工具如 Informatica、Ab Initio 和 Talend 也在云中以无服务器模式运行，底层使用 Kubernetes 集群。其中一些工具使用 Hadoop/Spark 解决方案或类似的专有计算引擎，因此我们之前提到的所有内容也适用于 ETL 工具的情况。如果您的团队希望创建数据管道而无需编写任何代码，图形化 ETL 工具是正确的选择。

参考架构的优点

Figures 3-5，3-6，和 3-7 中呈现的参考架构基于对无服务器 NoOps 技术和流式管道的偏好。

通过使用无服务器技术，您可以将数据工程团队的维护负担减少，并为执行复杂和/或大型作业提供必要的灵活性和可扩展性。例如，在零售商的黑色星期五期间规划交通高峰时，可伸缩性是至关重要的。使用无服务器解决方案允许零售商查看他们在一天中的表现。他们不再需要担心处理白天产生的大量数据所需的资源。

参考架构使数据工程团队有可能为数据管道编写完全自定义的代码。这可能是因为解析要求可能很复杂，没有现成的解决方案可能适用。在流式处理中，团队可能希望以低延迟实施复杂的业务逻辑。但是，团队应通过创建可重用库和使用 Dataflow 模板等技术来尝试重用代码。这既带来了两者的最佳（重用和重写），同时节省了宝贵的时间，可以用于高影响代码而不是常见的 I/O 任务。

呈现的参考架构还具有另一个重要特征：将现有的批处理管道转换为流式处理的可能性。

数据科学驱动的组织

数据科学驱动的组织是一种最大化从可用数据中获得价值以创造可持续竞争优势的实体。为此，组织依赖于通常（但并非总是！）采用 ML 的自动化算法。与依赖一次性报告和分析的分析驱动型组织不同，科学驱动型组织试图以自动化的方式做出决策。例如，一个以数据分析驱动的银行会让数据分析师评估每个商业贷款机会，建立投资案例，并由高管签署。另一方面，一个数据科学驱动的金融科技公司将建立一个贷款批准系统，该系统使用某种自动化算法来对大多数贷款做出决策。

愿景

数据科学驱动的组织是从其数据中提取最大价值，并利用 ML 和分析获得可持续竞争优势的组织。在构建这样的数据科学团队时，应遵循一些原则：

适应性

平台必须具有足够的灵活性，以适应所有类型的用户。例如，虽然一些数据科学家/分析师更倾向于创建自己的模型，但其他人可能更喜欢使用无代码解决方案或在 SQL 中进行分析。这还包括提供各种机器学习和数据科学工具，如 TensorFlow、R、PyTorch、Beam 或 Spark。平台还应该足够开放，以在多云和本地环境中运行，同时在可能时支持开源技术，以避免锁定效应。最后，资源永远不应成为瓶颈，因为平台必须能够快速扩展以满足组织的需求。

标准化

标准化通过使代码和技术成果更易于共享来提高平台的效率。这提升了团队之间的沟通，增强了他们的表现和创造力。标准化还使数据科学和机器学习团队能够以模块化的方式工作，这对于高效的开发至关重要。通过使用标准连接器连接到源/目标系统可以实现标准化。这避免了在机器学习和数据科学工作流中常见的“技术债务”问题。

责任

数据科学和机器学习用例通常涉及敏感主题，如欺诈检测、医学影像或风险计算。因此，数据科学和机器学习平台必须帮助尽可能使这些工作流程透明、可解释和安全。开放性与运营卓越性息息相关。在数据科学和机器学习工作流程的所有阶段收集和监控元数据对于创建允许您提出诸如以下问题的“纸迹”至关重要：

• 用于训练模型的数据是哪些？

• 使用了哪些超参数？

• 模型在生产中的表现如何？

• 在上个时期内是否发生了任何形式的数据漂移或模型偏移？

此外，以科学为驱动的组织必须对其模型有深入的理解。虽然传统统计方法的这个问题较少，但机器学习模型（如深度神经网络）则更加不透明。平台必须提供简单的工具来分析这些模型，以便放心使用。最后，成熟的数据科学平台必须提供所有安全措施，以保护数据和成果，并在粒度级别管理资源使用。

商业影响

根据麦肯锡，许多数据科学项目未能超越试点或概念验证阶段。因此，更重要的是预期或衡量新举措的商业影响，并选择回报率，而不是追求最新的时髦解决方案。因此，关键是确定何时购买、构建或定制机器学习模型，并将它们连接到单一集成堆栈中。例如，在数月的开发后，通过调用 API 使用现成的解决方案而不是构建模型，将帮助您实现更高的回报率并展示更大的价值。

激活

将分析嵌入到最终用户使用的工具中以操作化模型的能力对于实现向广泛用户群提供服务的扩展至关重要。能够将小批量数据发送到服务中，并在响应中返回预测结果的能力，使得具有较少数据科学专业知识的开发人员也能使用模型。此外，促进边缘推理和灵活 API 的自动化过程的无缝部署和监控非常重要。这使您能够在私有和公共云基础设施、本地数据中心和边缘设备上分布人工智能。

建立以科学驱动为基础的组织面临着几个社会技术挑战。通常，组织的基础设施不够灵活，无法应对快速变化的技术环境。平台还需要提供足够的标准化，以促进团队之间的沟通，并建立技术上的“共通语言”。这一点对于允许团队之间的模块化工作流程和建立运营卓越至关重要。此外，安全地监控复杂的数据科学和机器学习工作流通常过于不透明。

基于技术开放性高度可适应的技术平台构建以科学驱动的组织至关重要。因此，关键是要使广泛的角色得到启用，并以灵活和无服务器的方式提供技术资源。是购买还是构建解决方案是实现组织投资回报率的主要驱动因素之一，这将定义任何 AI 解决方案可能产生的业务影响。同时，启用广泛的用户能够激活更多用例。最后，平台需要提供工具和资源，使数据科学和机器学习工作流程开放、解释性和安全，以提供最大形式的问责制。

人物角色

数据科学驱动的组织中的团队由具有不同技能和经验的各种人员组成。然而，大多数团队包括四个核心角色：数据工程师、ML 工程师、数据科学家和分析师。需要注意的是，这些角色并不总是清晰定义的，并且在某种程度上可能存在重叠。有效的组织结构将允许协作和充分利用所有团队成员的技能：

数据工程师

数据工程师负责开发数据流水线，确保数据符合所有质量标准。这包括从多个来源清理、合并和丰富数据，将其转化为可用于下游分析的信息。

ML 工程师

ML 工程师负责创建和监督完整的 ML 模型。虽然 ML 工程师是四个角色中最稀缺的，但一旦组织打算在生产中运行关键业务工作流程，他们就变得至关重要。

数据科学家

数据科学家是数据与 ML 工程师之间的桥梁。他们与业务利益相关者一起，将业务需求转化为可测试的假设，确保从 ML 工作负载中获取价值，并创建报告以展示数据的价值。

数据分析师

数据分析师提供业务洞见，并确保实施企业正在寻求的基于数据驱动的解决方案。他们回答临时问题，并提供分析历史和最新数据的定期报告。

公司是否应该建立集中化或分散化的数据科学团队存在各种争论。还有混合模型，例如数据科学家嵌入到中央组织的联邦组织。因此，更重要的是专注于如何使用前面描述的原则解决这些社会技术挑战。

技术框架

我们强烈建议您在公共云提供商的 ML 流水线基础设施上进行标准化（例如，在 Google Cloud 上的 Vertex AI、AWS 上的 SageMaker 或 Azure 上的 Azure Machine Learning），而不是将单次培训和部署解决方案拼凑在一起。参考架构（见图 3-8）包括一个 ML 流水线，用于自动化实验和训练。训练过的模型被部署在一个通过容器化重复许多训练步骤的流水线中。当特征过于昂贵或需要在服务器端注入时，请使用特征存储。将模型部署到端点。

图 3-8. 使用公共云中提供的 ML 流水线产品使数据科学实验可重复且部署健壮

摘要

在本章中，您已经看到了设计数据团队的不同方式，以确保其在您所在的组织中取得成功。最佳方法是找到合适的技能和经验组合，这将补充您现有的团队，并帮助您实现业务目标。主要收获如下：

• 云技术促进了新的工作方式的实现。任何给定角色的潜在作用范围已经扩大。数据工作者现在能够更有效地利用他们手头的数据。

• 无论您的组织主要由数据分析师、数据工程师还是数据科学家组成，都可以构建数据文化。然而，通向数据文化的路径以及每种组织类型所需的技术是不同的。

• 确定哪种组织分类适合您，然后开始建立与之支持相关的愿景、具备相关技能的人物角色以及技术框架。

• 数据平台应该做什么的愿景也各不相同。在分析驱动型组织中，它应该民主化数据访问。在工程驱动型组织中，它关乎以成本效益的方式确保可靠性。在科学驱动型组织中，它应该通过业务影响力提供竞争优势。

• 分析驱动型组织应专注于 SQL 技能，工程驱动型组织应专注于 ETL 和 DataOps 能力，而科学驱动型组织则应专注于 MLOps 和 AI 能力。

• 分析驱动型组织的推荐架构是数据仓库（或建立在数据仓库基础上的湖仓）；对于工程驱动型组织来说，是数据湖（或建立在数据湖基础上的湖仓）；对于科学驱动型组织来说，是与湖仓连接的 ML 流水线架构。这些内容将在第五章至第七章详细讨论。

接下来的章节将为您提供一个通用的技术迁移框架，您可以应用它从传统环境迁移到现代化的云架构。

第四章：迁移框架

除非您在一家初创公司，否则很少会从零开始构建数据平台。相反，您将通过从遗留系统迁移事物来搭建一个新的数据平台。在本章中，让我们来审视迁移的过程——当您启程进入新数据平台时应该做的一切。我们将首先提出一个概念模型和可能的框架，您在现代化数据平台时应该遵循它们。然后，我们将审查组织如何估算解决方案的总体成本。我们将讨论如何确保在迁移过程中即使数据安全和数据治理也能就位。最后，我们将讨论模式、数据和管道迁移。您还将了解有关区域容量、网络和数据传输约束的选项。

现代化数据工作流程

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

全面视角

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

业务成果

专注于您正在现代化的工作流程，并确定这些工作流程驱动的业务成果。这对于确定差距和机会所在至关重要。在做出任何技术决策之前，限制迁移到与领导层确定的业务目标一致的用例（通常在两到三年的时间范围内）。

利益相关者

确定可能会访问数据的人员或角色（其中一些团队可能尚不存在）。您在数据现代化中的目标是使数据访问民主化。因此，这些团队需要掌握数据读写能力，并熟练使用现代化最终状态技术所期望的任何工具（如 SQL、Python、仪表盘）。

技术

您必须根据业务策略和团队能力定义、实施和部署数据架构、建模、存储、安全、集成、可操作性、文档、参考数据、质量和治理。

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

现代化工作流程

当您考虑现代化程序时，您的注意力自然会转向您使用的工具所带来的痛苦。您决定要升级您的数据库，并使其在全球范围内保持一致和可扩展性，因此您将其现代化为 Spanner 或 CockroachDB。您决定要升级您的流处理引擎，并使其更具弹性和更易于运行，因此您选择 Flink 或 Dataflow。您决定不再调整数据仓库集群和查询，因此您将其现代化为 BigQuery 或 Snowflake。

这些都是很好的进步。每当可能时，您确实应该升级到更易于使用、更易于运行、更具可扩展性和更具韧性的工具。然而，如果您只进行类似于类似工具的更换，您最终只会得到渐进性的改进，而不会得到转型性的变化。

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

接下来，从头开始考虑工作流程。识别高价值客户的方法是根据交易历史记录为每个用户计算总购买量。找出如何通过您现代化的工具集实现这样的工作流程。在这样做时，大量依赖自动化：

自动化数据摄入

不要编写定制的 ELT 流水线。使用诸如 Datastream 或 Fivetran 之类的现成 ELT 工具将数据导入 DWH（数据仓库）中更为简便。在飞行中进行转换并捕获常见转换结果，要比为每个可能的下游任务编写 ETL 流水线容易得多。此外，许多 SaaS 系统将自动导出至 S3、Snowflake、BigQuery 等。

默认流式处理

将数据存入既结合批处理又结合流式存储的系统中，以便所有 SQL 查询反映最新数据（受某些延迟影响）。同样，任何分析都应寻找能够使用同一框架处理流式和批处理的数据处理工具。在我们的例子中，生命周期价值计算可以是一个 SQL 查询。为了重复使用，将其制作成一个材料化视图。这样，所有计算都是自动的，并且数据始终是最新的。

默认自动缩放

任何期望您预先指定机器数量、仓库大小等的系统，都将要求您专注于系统而非要完成的工作。您希望自动缩放，以便能够专注于工作流程而不是工具。

查询重写、合并阶段等

您希望能够专注于要完成的工作，并将其分解为可理解的步骤。您不希望调整查询、重写查询、合并转换等。让内置于数据堆栈中的现代优化器处理这些事务。

评估

您不希望为评估 ML 模型性能编写定制的数据处理流水线。您只需能够指定采样率和评估查询，并得到关于特征漂移、数据漂移和模型漂移的通知即可。所有这些功能应内置于部署的端点中。

重新训练

如果您遇到模型漂移，您应该在十次中有九次重新训练模型。这也应该是自动化的。现代机器学习流水线将提供可调用的钩子，您可以直接将其绑定到自动化评估流水线，以便您也可以自动化重新训练。

持续培训

模型漂移并不是您可能需要重新训练的唯一原因。当您拥有更多数据时，可能需要重新训练。也许是当新数据落入存储桶时，或者当您有代码提交时。同样，这可以自动化。

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

当然，您将会编写一些具体的代码片段：

• 在 SQL 中的数据准备

• 在 TensorFlow 或 PyTorch 等框架中的机器学习模型

• 连续评估的评估查询

我们可以看出，每个工作流程都能简化设置，这就解释了集成数据和人工智能平台的重要性。

转换工作流本身

您可以通过使用现代数据堆栈使工作流程本身更加高效和自动化。但在这样做之前，您应该问自己一个关键问题：“这个工作流程是否需要由数据工程师预先计算？”

因为这就是您构建数据管道时所做的事情——您正在预先计算。这只是一种优化，不过如此。

在许多情况下，如果您能使工作流程成为自助式和临时的，您就不必依赖数据工程资源来构建它。因为自动化程度很高，您可以提供运行任何聚合（不仅仅是生命周期价值）的能力，应用于完整的历史交易记录。将生命周期价值计算移到声明性语义层，用户可以在其中添加自己的计算。这就是例如 Looker 这样的工具允许您做的事情。一旦您这样做了，您就能获得整个组织中一致的关键绩效指标和授权用户构建常见措施库的好处。现在创建新指标的能力在业务团队，也就是其本应所在之处。

一个四步迁移框架

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

这种方法基于所示的四个主要步骤图 4-1。

1. 准备和发现。

所有利益相关者应进行初步分析，以确定需要迁移的工作负载清单和当前的痛点（例如，无法扩展、处理引擎无法更新、不需要的依赖关系等）。

2. 评估和计划。

评估前阶段收集的信息，定义成功的关键指标，并计划每个组件的迁移。

3. 执行。

对于每个确定的用例，决定是停用、完全迁移（数据、模式、下游和上游应用程序），还是卸载它（通过将下游应用程序迁移到不同的源）。之后，测试和验证任何已进行的迁移。

4. 优化。

一旦流程开始，可以通过持续迭代来扩展和改进它。首次现代化步骤可以仅关注核心能力。

图 4-1. 四步迁移框架

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

准备和发现

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

• 列出所有相关于迁移的用例和工作负载，并附有它们的优先级。确保包括合规要求、延迟敏感性和其他相关信息。

• 解释他们可以通过新系统获得的预期好处（例如，查询性能、处理能力、流式处理能力等）。

• 建议市场上可满足业务需求的解决方案。

• 进行初步的总体成本分析，以估算迁移的价值。

• 确定培训和招聘需求，以建立一个能力强大的工作人员。

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

评估和计划

第二步是评估收集到的数据，并计划完成实现确定目标所需的所有活动。这涉及：

1. 当前状态的评估

通过收集和分析服务器配置、日志、作业活动、数据流映射、数据量、查询和集群来分析每个应用程序、工作流或工具的当前技术印记。随着遗留印记的增加，这项活动可能变得非常耗时且容易出错。因此，寻找可以自动化整个过程的工具（例如 SnowConvert、CompilerWorks、AWS 模式转换工具、Azure 数据库迁移服务、Datametica Raven 等）。这些工具可以提供工作负载分解、依赖关系映射、复杂性分析、资源利用分析、容量分析、SLA 分析、端到端数据血统以及各种优化建议。

2. 工作负载分类

利用“准备和发现”阶段问卷收集的信息，结合评估阶段的深入洞察，对所有已识别的工作负载选择并分类为以下选项之一：

退役

工作负载最初将保留在本地环境中，并最终将被废除。

保留

工作负载将保留在本地环境中，由于技术约束（例如，它运行在专用硬件上）或出于业务原因。这可能是暂时的，直到工作负载可以重构，或者可能移动到协作设施，其中数据中心需要关闭且服务无法迁移。

迁移

工作负载将迁移到云环境中，利用其基础设施即服务（IaaS）能力。这通常被称为“搬迁和升级”。

重建

工作负载（或其中一部分）将部分更改以提高其性能或减少成本，然后迁移到 IaaS；这通常被称为“迁移和改进”。在进行搬迁和升级体验后进行优化，通常从容器化开始。

重构

工作负载（或其中一部分）将迁移到一个或多个云完全托管的平台即服务（PaaS）解决方案（例如，BigQuery、Redshift、Synapse）。

替换

工作负载将完全被第三方现成的或 SaaS 解决方案替代。

重建

使用云完全托管解决方案完全重新架构工作负载，并从头开始重新实施。这是重新思考应用程序并计划如何利用云原生服务的地方。

3. 工作负载集群化

将不会退役/重建的工作负载分组集群，根据它们的相对商业价值和迁移所需的努力。这将有助于在迁移过程中确定一种优先顺序。例如：

• 第一组：高商业价值，迁移成本低（优先级 0 - 快速胜利）

• 第二组：高商业价值，迁移成本高（优先级 1）

• 第三组：低商业价值，迁移成本低（优先级 2）

• 第四组：低商业价值，迁移成本高（优先级 3）

在 Figure 4-2 中，您可以看到一个集群化示例，在此示例中，工作负载根据描述的优先级标准分组。在每个组中，工作负载可能采用不同的迁移方法。

图 4-2. 工作负载分类和集群化示例

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

使过程可衡量。

确保利益相关者已经达成一致，并能够使用一些业务关键绩效指标来评估现代化的结果。

从最小可行产品（MVP）或概念验证（PoC）开始。

将大型任务细分为较小的任务，并确保为即将进行的任何工作存在标准模板。如果没有，请进行概念验证，并将其用作以后的模板。寻找可以快速获得成功的项目（优先级为 0 的工作负载），不仅可以作为其他转换的示例，还可以向领导展示此类现代化可能带来的影响。

估算完成所有活动所需的总时间。

创建一个全面的项目计划（如有必要，与供应商或顾问合作），以定义工作负载转换所需的时间、成本和人力资源。

在里程碑上过度沟通。

确保利益相关者了解计划的时间长短及其关键组成部分。确保通过已完成的云项目传递价值，并在整个过程中建立信心，使组织中的人们可以实际开始使用。尝试识别里程碑，并发送临时通信，总结已完成的工作的详细信息。

现在，您对准备进行下一次迁移所需完成的任务有了很好的了解，让我们看看您应该如何去做。

执行

对于每个工作负载，您现在有一个计划。具体来说，您知道将要迁移什么（整个工作负载还是部分工作负载）、将其迁移到何处（IaaS、PaaS 或 SaaS）、如何进行迁移（重新托管、重新平台化、重建等）、如何衡量成功、要遵循哪些模板、需要多少时间以及将要在何处通信里程碑。为了将计划变成现实，我们建议您设置一个着陆区，迁移到该区域，并验证迁移的任务。

着陆区

首先，您必须构建所谓的着陆区——所有工作负载将驻留的目标环境。这项活动可以根据您当前的配置复杂程度而有所不同，但至少您需要：

• 定义目标项目及相关组织（例如，Google Cloud 组织结构）。

• 设置新的身份管理解决方案或与旧有或第三方解决方案集成（例如 Azure Active Directory 或 Okta）。

• 配置授权（例如 AWS IAM）和审计系统（例如 Azure 安全日志记录和审计）

• 定义和设置网络拓扑及相关配置

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

迁移

通常建议将迁移分为多个阶段或迭代，除非您需要迁移的工作负载数量非常少。这样可以让您在迁移一部分工作负载时积累经验和信心，并处理挑战和错误。

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

模式和数据迁移

根据使用情况，您可能需要转换数据模型或仅简单地转移数据。

查询转译

在某些情况下，您可能需要将来自源系统的查询转换为目标系统的查询。如果目标系统不支持所有扩展功能，则可能需要重构查询。您可以利用工具如 Datametica Raven 或生成式人工智能来减少手动工作量。

数据管道迁移

数据管道是准备数据进行分析的数据工作负载的核心部分。我们将在“模式、管道和数据迁移”中看到处理此类迁移的可能方法。

业务应用程序迁移

一旦迁移数据完成，您需要迁移能使用户与数据交互的应用程序。

性能调优

如果迁移后的工作负载表现不如预期，您需要进行故障排除并修复。可能目标解决方案未正确配置，您定义的数据模型无法充分利用目标平台的所有功能，或者在转译过程中存在问题。

使用像 Ansible 或 Terraform 这样的基础架构即代码工具是非常重要的，因为它们可以尽可能自动化部署基础架构管理工作，加快每个迭代的测试和执行。

验证

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

在每个工作负载结束时，记录可能出现的问题及完成所有活动所需的时间以及相关的经验教训，以便在后续工作负载中改进流程是个明智的做法。

优化

框架的最后一步是优化。在这里，你不会专注于每个单独迁移的组件的性能。相反，你将把新系统作为一个整体来考虑，并确定引入潜在新用例的可能性，使其更加灵活和强大。你应该反思从迁移中得到了什么（例如，无限扩展性、增强安全性、增加可见性等），以及你可能会采取的下一步措施（例如，将数据收集的边界扩展到边缘、与供应商建立更好的协同关系、开始对正确的数据进行货币化等）。你可以从“准备和发现”步骤收集到的信息开始，弄清你在理想旅程中的位置，并考虑额外的下一步措施。这是一个永无止境的故事，因为创新像业务一样永不停歇，它将帮助组织越来越好地理解和利用他们的数据。

现在你已经通过利用四步迁移框架更好地理解了如何进行迁移的方法，让我们深入了解如何估算解决方案的总成本。

估算解决方案的总成本

刚才你看到了一个通用的迁移框架，可以帮助组织定义必须执行以现代化数据平台的一组活动。首席技术官（CTO）、首席执行官（CEO）或首席财务官（CFO）可能会问的第一个问题是：“我们需要为此预算多少总成本？”在本节中，我们将审视组织通常如何应对这一挑战，以及他们如何组织他们的工作以从供应商和第三方供应商那里获取报价。永远记住，这不仅仅是技术成本的问题——始终需要考虑到人员和流程成本。

现有基础设施的审计

正如你所见，一切都始于对现有环境的评估。如果你对当前的现状没有清晰的认识，那么你在正确评估下一代现代数据平台的定价时肯定会遇到挑战。这项活动可以通过以下三种方式之一来执行：

内部 IT/基础设施团队手动执行

许多组织维护配置管理数据库（CMDB），它可以是文件或标准数据库，包含组织内使用的所有硬件和软件组件的关键信息。它是当前组织内运行情况的一种快照，以及相关的基础设施，甚至突出显示了组件之间的关系。CMDB 可以更好地理解所有应用程序的运行成本，并帮助关闭不必要或冗余的资源。

内部 IT/基础设施团队自动执行

目标与前一点描述的完全相同，但旨在利用能够自动收集信息的软件（与硬件相关的数据，运行在服务器上的应用程序，系统之间的关系等）。这些类型的工具（例如，StratoZone，Cloudamize，CloudPhysics 等）通常会生成与最常见的目标云超大规模供应商（例如 AWS，Google Cloud 和 Azure）相关的建议，例如机器的大小和优化选项（例如，系统每天应运行多少小时来执行其任务）。

利用第三方参与者

咨询公司和云供应商拥有经验丰富的人员和自动化工具来执行生成 CMDB 和详细报告的所有活动，这是我们建议的，如果您的组织通常将 IT 项目外包给咨询公司。

信息/提议和报价请求

虽然这可能是您要做的唯一迁移，因此您必须边做边学，但咨询公司专业从事此类工作，通常在处理迁移项目时效率更高。当然，请验证分配给您的团队是否具有必要的经验。一些 SI 甚至可能会执行评估并提供成本估算作为未来机会的投资。

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

信息请求（RFI）

用于收集供应商/潜在合作伙伴解决方案和服务详细信息的问卷。它有一个教育目的。

提案请求（RFP）

用于收集供应商/合作伙伴如何利用其产品和服务来解决特定组织问题的详细信息的问卷（在本例中是现代数据平台的实施）。它用于比较结果。

报价请求（RFQ）

用于基于特定要求收集不同供应商/潜在合作伙伴定价详细信息的问卷。它用于量化和标准化定价，以便未来进行比较。

您的组织可能有关于如何执行此操作的政策和模板。请与您的法律或采购部门联系。否则，请询问供应商展示他们通常使用的内容。

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

概念验证/最小可行产品

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

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

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

概念验证

构建解决方案的一小部分，以验证可行性、集成性、可用性和潜在弱点。这有助于估算最终价格。目标不是触及平台的每个单一功能，而是验证可能需要重新设计的事物。例如，在处理流式管道时，随机变化要处理的数据量是一个很好的实践。这将让您看到系统如何扩展，并为估算最终生产成本提供更好的数据。

最小可行产品

MVP 的目标是开发一个带有非常明确定义的边界的产品，所有功能都已实施并像真实完整的产品一样运行，可以部署在生产环境中（例如，在新的数据仓库上实施的数据市场，并连接到新的商业智能工具，以解决非常特定的用例）。 MVP 的主要优势在于能够快速从真实用户那里获得反馈，这有助于团队改进产品并进行更好的估算。

混合

最初，团队将开发一个具有更广泛边界但深度有限的一般 PoC（例如，端到端数据管道，用于收集用于训练图像分类 ML 算法所需的数据），然后根据第一次结果和成本评估，重点将转移到开发 MVP，可以视为实施完整解决方案的第一步。

现在您知道如何估算成本了，让我们深入探讨迁移的第一部分——设置安全性和数据治理。

设置安全性和数据治理

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

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

框架

存在三个风险因素，安全和治理试图解决：

未经授权的数据访问

在公共云基础设施中存储数据时，有必要防止对敏感数据的未经授权访问，无论是公司机密信息还是法律保护的个人身份信息（PII）。

法规合规

诸如《通用数据保护条例》（GDPR）和法律实体标识符（LEI）等法律限制了数据分析的位置、类型和方法。

可见性

了解组织中存在哪些类型的数据，目前谁在使用这些数据以及他们如何使用这些数据可能是向向您的组织供应数据的人员要求的。这需要最新的数据和一个功能性的目录。

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

数据谱系

组织需要能够识别数据资产，并记录已应用的转换以创建每个数据资产。

数据分类

我们需要能够对敏感数据进行分析和分类，以确定每个数据资产或其部分需要适用哪些治理政策和程序。

数据目录

我们需要维护一个包含结构化元数据、血统和分类信息，并支持搜索和发现的数据目录。

数据质量管理

需要有一个过程来记录、监测和报告数据质量，以便为分析提供可信的数据。

访问管理

通常情况下，这将与云 IAM 一起工作，以定义角色、指定访问权限和管理访问密钥。

审计

组织及其他机构授权的个人，例如监管机构，需要能够监测、审计和跟踪符合法律或行业惯例所需的粒度级别的活动。

数据保护

需要能够加密数据、对数据进行遮蔽或永久删除数据。

要实施数据治理，您需要建立一个框架，使这些活动能够进行。例如，Google Cloud 上的 Dataplex 和 Azure 上的 Purview 提供统一的数据治理解决方案，用于管理数据资产，无论数据存储在单一云、混合云还是多云中。Collibra 和 Informatica 是云不可知的解决方案，提供记录血统、数据分类等功能。

根据我们的经验，任何这些工具都可以使用，但数据治理的重要工作不在于工具本身，而在于其操作化。建立运营模型——数据治理的流程和程序是至关重要的，还需要设立一个委员会，负责监督各业务团队遵守这些流程。该委员会还需要负责开发分类体系和本体论，以确保组织内部的一致性。理想情况下，您的组织应参与并符合行业标准组织的要求。最好的组织还应定期进行教育和培训，以确保遵循数据治理实践。

现在我们已经讨论了中央数据治理框架需要具备的能力，让我们列举中央团队需要维护的文档。

文档

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

企业词典

这可以是从简单的纸质文档到自动化（和强制执行）某些策略的工具。企业字典是组织使用的信息类型的存储库。例如，与各种医疗程序相关联的代码或者必须收集的任何财务交易信息都是企业字典的一部分。中央团队可以提供验证服务，以确保符合这些条件。许多读者熟悉的一个简单示例是美国邮政服务提供的地址验证和标准化 API。这些 API 通常被企业用来确保组织内任何数据库中存储的任何地址都是标准化的形式。

数据类

企业字典中的各种信息类型可以分组为数据类，并可以以一致的方式定义与每个数据类相关的政策。例如，与客户地址相关的数据政策可能是邮政编码对一类员工可见，但更精细的信息仅对积极处理该客户问题单的客服人员可见。

策略手册

策略手册列出了组织中使用的数据类，每个数据类如何处理，数据保留多长时间，可以存储在哪里，访问数据的方式需要如何控制等。

使用案例策略

通常，围绕数据类的政策取决于使用案例。举个简单例子，客户的地址可能会被送货部门用来履行客户订单，但不会被销售部门使用。使用案例可能更加微妙：例如，客户的地址可能被用来确定离某个特定店铺有驾驶距离的客户数量，但不用于确定某个特定客户是否在驾驶距离内的目的。

数据目录

这是一个管理结构化元数据、血统、数据质量等的工具。数据目录作为一个高效的搜索和发现工具。

除了上述列出的与数据相关的工件之外，中央组织还需要维护单点登录（SSO）能力，以在整个组织中提供独特的认证机制。因为许多自动化服务和 API 是通过密钥访问的，这些密钥不应以明文形式存储，因此密钥管理服务通常也是中央团队的额外责任。

作为现代化之旅的一部分，同样重要的是开始使用这些工件并将其放置在适当位置，以便将数据迁移到云端时，它们成为强大数据治理框架的一部分。不要推迟数据治理直到云迁移之后 — 这样做的组织往往很快失去对数据的控制。

现在让我们看看在数据生命周期内框架能力和工件如何联系在一起。

数据生命周期的治理

数据治理涉及在数据生命周期内整合人员、流程和技术。

数据生命周期包括以下阶段：

1. 数据创建

这是创建/捕获数据的阶段。在此阶段，应确保还捕获了元数据。例如，捕获图像时，还重要记录照片的时间和位置。类似地，捕获点击流时，重要注意用户的会话 ID、所在页面、页面布局（如果是根据用户个性化的），等等。

2. 数据处理

在捕获数据时，通常需要清理、增强并加载到数据仓库（DWH）中。重要的是将这些步骤作为数据血统的一部分进行捕获。除了血统，还需要记录数据的质量属性。

3. 数据存储

通常将数据和元数据存储在持久化存储中，如 blob 存储（S3、GCS 等）、数据库（Postgres、Aurora、AlloyDB 等）、文档数据库（DynamoDB、Spanner、Cosmos DB 等）或数据仓库（BigQuery、Redshift、Snowflake 等）。在这一点上，您需要确定行和列的安全要求，以及在保存之前是否需要加密任何字段。这是数据保护在数据治理团队思想中的核心阶段。

4. 数据目录

您需要在转换的各个阶段将持久化数据输入企业数据目录，并启用发现 API 进行搜索。必须记录数据及其用途。

5. 数据存档

您可以从生产环境中移除较旧的数据。如果是这样，请记得更新目录。您必须注意是否法律要求进行此类归档。理想情况下，应根据适用于整个数据类别的政策自动化归档方法。

6. 数据销毁

您可以删除所有已超过法定保留期的数据。这也需要包含在企业的政策手册中。

您必须为每个阶段创建数据治理政策。

人们将执行这些阶段，这些人需要具有特定的访问权限。同一个人在数据生命周期的不同部分可能有不同的责任和关注点，因此以“角色”而非“角色”思考会更有帮助：

法务

确保数据使用符合合同要求和政府/行业法规

数据监护人

数据的所有者，为特定数据项设定策略

数据治理者

设定数据类别政策，并确定特定数据项属于哪个类别

隐私专员

确保用例不会泄露个人身份信息

数据使用者

通常是数据分析师或数据科学家，他们使用数据来做出业务决策。

现在我们已经看到了可能的迁移和安全治理框架，让我们深入了解如何开始执行迁移。

Schema, Pipeline, and Data Migration

在本节中，我们将更详细地讨论可以用于模式和管道迁移的模式，以及在数据传输时需要面对的挑战。

模式迁移

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

在这里，通常可以应用外观模式——一种设计方法，用于向下游进程展示一组视图，这些视图掩盖了底层表格，隐藏了最终所需变更的复杂性。这些视图可以描述一个新的模式，有助于利用临时目标系统的特性，而不会打断上游和下游进程，这些进程由此抽象层“保护”着。如果不能采用这种方法，那么在将数据摄入到新系统之前，必须对数据进行转换和转换。这些活动通常由迁移范围内的数据转换管道执行。

管道迁移

在从旧系统迁移到云端时，有两种不同的策略可以遵循：

您正在卸载工作负载。

在这种情况下，您保留了供给源系统的上游数据管道，并将数据的增量副本放入目标系统。最后，您更新下游进程以从目标系统读取数据。然后，您可以继续卸载下一个工作负载，直到达到结束。完成后，您可以开始完全迁移数据管道。

您正在完全迁移工作负载。

在这种情况下，您必须将所有内容迁移到新系统中（与数据管道一起），然后停用相应的旧表。

需要迁移的工作负载数据。它可以来自各种数据源，并且可能需要特定的转换或连接才能使其可用。通常有四种不同的数据管道模式：

ETL

所有转换活动以及数据收集和数据摄入将由一个临时系统执行，该系统配备了适当的基础设施和适当的编程语言（该工具可以使接口与可用的标准编程语言编程化，无论如何）。

ELT

与 ETL 类似，但需注意的是所有转换将由处理引擎执行，数据将在其中摄取（正如我们在前几章中所见，处理现代云解决方案时，这是首选方法）。

提取和加载（EL）

这是最简单的情况，其中数据已经准备好，并且不需要任何进一步的转换。

变更数据捕获（CDC）

这是用于跟踪源系统中数据更改并在目标系统中反映这些更改的模式。通常与 ETL 解决方案一起使用，因为它在向下游过程进行任何更改之前存储原始记录。

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

淘汰

数据管道解决方案不再使用，因为它适用于旧的用例或已被新的用例取代。

保留

数据管道解决方案仍留在传统系统中，因为可能很快就可以淘汰，因此着手进行迁移项目在财务上不可行。还可能存在一些法规要求，禁止在公司边界之外移动数据。

重新托管

数据管道解决方案被提升并迁移到云环境中，利用 IaaS 范式。在这种情况下，除了在连接级别引入临时网络配置（通常是虚拟专用网络，或 VPN）外，您没有引入任何大的修改，这可能需要设置以便在云环境和本地环境之间进行通信。如果上游过程在企业边界之外（例如，第三方提供商，其他云环境等），可能不需要 VPN，因为可以利用其他技术（例如经过身份验证的 REST API）以安全方式建立通信。在继续之前，有必要与云供应商验证底层系统中是否存在任何技术限制，以防止解决方案的正确执行，并仔细检查可能的许可限制。

重新平台化

在这种情况下，部分数据管道解决方案在迁移之前进行转换，以便从云的功能中获益，例如 PaaS 数据库或容器化技术。在“重新托管”描述中突出显示的连接方面的考虑仍然有效。

重构

管道解决方案将迁移到一个或多个云完全托管的平台即服务解决方案（例如，Amazon EMR，Azure HDInsight，Google Cloud Dataproc，Databricks）。在采用这种方法时，最佳实践是重新采用您用于整个迁移过程的相同迭代方法：

• 准备并发现作业，并根据复杂性进行可能的组织。

• 计划并评估可能需要迁移的最小可行产品（MVP）。

• 执行迁移并根据您定义的关键绩效指标（KPI）评估结果。

• 与所有其他作业一起迭代直到结束。

请注意，在前述“重新主机化”描述中突出显示的连接方面的考虑仍然有效。

替换

管道解决方案将完全替换为第三方现成或软件即服务解决方案（例如，Fivetran，Xplenty，Informatica 等）。请注意，在“重新主机化”部分突出显示的连接方面的考虑仍然有效。

重建

管道解决方案完全重新设计，采用云完全托管的解决方案（例如 AWS Glue，Azure Data Factory，Google Cloud Dataflow）。请注意，在“重新主机化”部分突出显示的连接方面的考虑仍然有效。

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

数据迁移

现在您已经准备好新的架构和管道，可以开始迁移所有数据。您应该考虑如何处理数据传输的问题。您可能希望将所有本地数据迁移到云中，即使是古老的尘封磁带（也许有一天某人会要求这些数据）。您可能面临一个现实，即一个周末的单个 FTP 连接并不足以完成您的任务。

计划

数据传输需要计划。您需要识别并涉及：

技术所有者

能够提供访问您执行迁移所需资源（例如存储、IT、网络等）的人员。

批准者

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

交付

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

然后，您需要收集尽可能多的信息，全面了解您需要完成的工作、顺序（例如，也许您的迁移团队需要被允许访问包含您想要迁移的数据的特定网络存储区域），以及可能遇到的阻碍因素。以下是您在继续之前应该能够回答的问题示例（并非穷尽）：

• 您需要迁移的数据集是什么？

• 组织内部数据位于何处？

• 您被允许移动的数据集是什么？

• 是否有任何特定的法规要求您必须遵守？

• 数据将落在何处（例如，对象存储与数据仓库存储）？

• 目的地区域是哪里（例如，欧洲、中东和非洲、英国、美国等）？

• 在传输之前是否需要执行任何转换？

• 您希望应用的数据访问策略是什么？

• 这是一次性的传输，还是需要定期移动数据？

• 数据传输的可用资源是什么？

• 分配的预算是多少？

• 您是否有足够的带宽来完成传输，并且足够长的时间？

• 您是否需要利用离线解决方案（例如，Amazon Snowball、Azure Data Box、Google Transfer Appliance）？

• 完成整个数据迁移所需的时间是多少？

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

区域容量和云网络

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

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

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

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

公共互联网连接

利用公共互联网网络。在这种情况下，组织通常利用公共互联网协议上的 VPN 来保护其数据并确保足够的可靠性水平。性能严格依赖于组织接近所选云超级扩展商的最近出现点的能力。

合作伙伴互联

这是组织可能为其生产工作负载利用的典型连接之一，特别是当它们需要具有高吞吐量的保证性能时。此连接是组织与选定合作伙伴之间的连接，然后由后者负责与选定的超级扩展商的连接。利用电信服务提供商的普及性，组织可以建立高性能连接，并以合理的价格提供。

直接互连

这是可能的最佳连接方式，其中组织直接（物理上）与云服务提供商的网络相连。（只要两方都在同一物理位置上有路由器，这就是可能的。）可靠性、吞吐量和整体性能都是最佳的，而定价可以直接与选择的虚拟化平台供应商讨论。

欲了解如何配置这三种连接选项的详细信息，请参阅Azure，AWS和Google Cloud的文档。

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

传输选项

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

成本

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

网络

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

云提供商

将数据上传到云提供商通常是免费的，但如果您不仅从您的本地环境，而且从另一个超大规模供应商导出数据，则可能会收取出站费用（通常每导出 1GB 收费）以及可能的读取费用。

产品

您可能需要购买或租用存储设备以加快数据传输速度。

人员

进行迁移的团队。

时间

了解需要传输的数据量和您可用的带宽非常重要。一旦您知道了这些，您将能够确定传输数据所需的时间。例如，如果您需要传输 200 TB 的数据，并且您只有 10 Gbps 的带宽可用，那么您将需要大约两天的时间来完成传输。¹ 这假设带宽完全可用于数据传输，但这可能并非总是如此。如果在分析过程中发现需要更多带宽，您可能需要与您的互联网服务提供商（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

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

物理解决方案

如前所述的离线与在线传输的描述中讨论的离线迁移工具。

第三方商业现成解决方案（COTS）

这些工具可能提供更多功能，如网络限速、自定义高级数据传输协议、高级编排和管理功能以及数据完整性检查。

迁移阶段

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

1. 修改上游流程，将当前遗留数据解决方案的数据提供给目标环境。

2. 修改从遗留环境读取的下游流程，改为从目标环境读取。

3. 历史数据大量迁移到目标环境。此时，上游流程也已迁移到写入目标环境。

4. 下游流程现已连接到目标环境。

5. 可以在遗留环境和目标环境之间保持数据同步，利用 CDC 管道直到旧环境完全淘汰。

6. 下游流程完全运作，利用目标环境。

图 4-3. 数据迁移策略

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

执行功能测试。

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

执行性能测试。

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

执行数据完整性检查。

在数据迁移过程中可能遇到的最关键问题之一是，由于错误而将迁移至目标系统的数据删除，或者数据损坏且无法使用。有一些方法可以保护你的数据免受此类风险的影响：

• 在目标地点启用版本控制和备份，以限制意外删除的损害。

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

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

摘要

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

• 焦点是现代化你的数据工作流程，而不仅仅是升级单个工具。选择合适的工具来完成合适的工作将有助于降低成本，充分利用你的工具，并提高效率。

• 可能的数据迁移框架可以分为四个步骤：准备与发现，评估与计划，执行和优化。

• 准备与发现是一个关键步骤，您在其中专注于定义迁移的边界，然后收集与已确定需要迁移的各种工作负载/用例相关的所有信息。

• 评估与计划是您定义和计划完成已确定目标所需的所有活动的步骤（例如，对需迁移的工作负载进行分类和聚类，定义关键绩效指标，定义可能的 MVP 以及制定与相关里程碑相关的迁移计划）。

• 执行是迭代进行迁移的步骤，每次迭代都改进整体过程。

• 优化是考虑整个新系统，并识别引入潜在新用例以使其更加灵活和强大的步骤。

• 理解当前足迹及最终解决方案的总成本是一个复杂的步骤，可能涉及多个参与者。组织通常利用 RFI、RFP 和 RFQ 从供应商/潜在合作伙伴获取更多信息。

• 治理和安全始终是大多数组织的中心关注点。这是因为需要在角色定义方式、数据安全和活动日志记录方面保持一致性。

• 迁移框架必须符合一个非常明确定义的治理框架，这在数据整个生命周期中至关重要。

• 在迁移数据架构时，利用类似外观模式的模式可能会有助于更轻松地采纳目标解决方案的特性。

• 在使用云解决方案时，连接性和确保区域容量至关重要。网络配置、带宽可用性、成本、人员、工具、性能和数据完整性是必须为每个工作负载明确的主要要点。

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

¹ 在网上有几种免费的服务可帮助您进行此估算工作，例如 Calculator.net 的带宽计算器。

第五章：架构设计数据湖

数据湖是数据平台的一部分，从整个组织中捕获原始、未经管理的数据，并支持 Apache 生态系统中的计算工具。在本章中，我们将详细讨论这个概念，这在设计现代数据平台时非常重要。云计算可以为其上可实现的各种用例提供支持，这一点将贯穿本章始终。

我们将从为何希望存储仅支持基本计算的原始、未经管理数据开始进行回顾。然后，我们讨论云中的架构设计和实施细节。尽管最初数据湖仅用于基本数据处理，现在可以通过 API 和连接器与其他解决方案集成，仅使用数据湖就可以民主化数据访问和报告——因为数据湖中的数据可以更适合特定目的。最后，我们将从鸟瞰视角看待通过利用数据科学笔记本在组织内加速分析和实验的一种非常普遍的方法。

数据湖与云——完美的结合

数据帮助组织更快做出更好的决策。它是一切应用程序和安全性的中心，更多的数据意味着需要更多的处理能力，而云解决方案可以提供这种能力。

本地数据湖的挑战

组织需要一个地方来存储各种类型的数据，包括非结构化数据（图片、视频、文本、日志、二进制文件、网页内容）。这是企业采用数据湖的主要原因。最初，企业认为数据湖只是纯粹的原始存储。

业务部门希望从 IT 部门存储的数据中提取洞察和价值，而不仅仅是存储数据。多亏了 Hadoop 生态系统的演进，数据湖使得能够进行大数据分析的组织能够超越存储卸载的概念。数据湖带来了先进的分析和机器学习能力。在 2010 年代，Hadoop 及相关技术推动了数据湖的大规模采用。

然而，公司在获取数据湖成效方面面临着挑战，因为在总拥有成本（TCO）、可伸缩性、治理和敏捷性等方面存在缺陷。管理本地数据湖的资源利用率和总体成本可能变得难以管理。资源密集型的数据和分析处理经常导致未能达到服务级别协议。数据治理和安全问题可能引发合规性问题。由于资源配置所需的时间，分析实验速度变慢。

据估计，到 2025 年，80% 的组织数据将为非结构化数据，本地环境已不再能够以可承受的价格提供充足的环境。如您在第二章中所见，云解决方案使组织能够首先降低 TCO，然后构建创新平台，因为公司内部的人员可以专注于业务价值而不是硬件管理。

云数据湖的好处

云计算范式对数据湖非常有益，因为：

• 不必将所有数据存储在昂贵的、始终开启的 Hadoop 分布式文件系统（HDFS）集群中。对象存储解决方案（例如 AWS S3、Azure Blob 存储或 Google Cloud Storage）是完全托管的、无限可扩展的，成本仅为传统方案的一小部分。

• Hadoop 集群不仅提供存储能力，还能够在短时间内按需创建处理计算能力（几分钟或几秒钟），由于无需始终开启，这带来了立即的成本节约。这些 Hadoop 集群可以直接从对象存储读取/写入数据，尽管这种数据访问速度比读取/写入 HDFS 要慢，但通过使用临时集群带来的成本节约可能使整体折衷更为合理。

• 超大规模云服务提供商通常提供利用更便宜的虚拟机（称为竞价实例或抢先实例）作为工作节点的能力。这些虚拟机的缺点是它们可能随时被系统驱逐（通常提前 30 到 60 秒通知），但由于底层的 Hadoop 技术具有工作节点故障容忍性，因此可以轻松地用新的替换。这种方法带来了额外的成本节约。

• 现在，超大规模云服务提供商上提供的大多数 Hadoop 服务都是完全托管的，并以平台即服务（PaaS）模式提供（尽管您可以通过纯 IaaS 服务构建自己的 Hadoop 集群）。PaaS 意味着您无需自行管理所有需要的主节点和工作节点的虚拟机，而是可以专注于构建处理流程以从数据中提取价值。

• 本地的 Hadoop 集群往往在组织内部产生数据孤岛，因为 HDFS 池并未设计为易于数据共享。云计算中，存储（例如，任意 HDFS 集群中可注入的对象存储中的数据）和计算（例如，按需创建的虚拟机）能够有效分离，使组织在处理数据治理挑战时拥有更大的灵活性。

云计算是数据湖的理想栖息地，因为它解决了所有本地数据湖的挑战：总体成本拥有（TCO）、可伸缩性、弹性和一致的数据治理。

市场强烈投资于数据湖，特别是基于云的数据湖。亚马逊 EMR、Azure 数据湖和谷歌云 Dataproc 可在超大规模计算机上使用。Databricks（开源 Spark 引擎的开发者，是所有主要 Hadoop 分发的一部分）构建了一个完整的多云数据平台，不仅提供存储和计算，还提供处理整个数据生命周期所需的全部功能。

接下来，让我们看看云上数据湖的设计与实施细节。

设计与实施

数据湖的设计取决于是否需要流处理，如何进行数据治理，使用哪些 Hadoop 功能，以及构建在哪个超大规模计算机上。让我们一一讨论这些问题。

批处理和流处理

在分析数据工作负载时，首要问题是要回答要处理的数据的年龄：它是存储已久的数据，还是刚刚到达系统的数据？根据答案，选择数据处理的两种主要方法之一：批处理和流处理。批处理在过去 20 年中一直是主流方法，但随着云计算的出现，流处理在近年来日益流行。流处理更适合实时处理大量数据，而批处理更适合离线处理大量数据。

无论是批处理还是流处理，在数据湖中有四个存储区域：

原始/落地/青铜

数据从源系统直接收集和摄取。

暂存/开发/银

更高级用户（如数据工程师、数据科学家）处理数据，为最终用户准备数据。

生产/黄金

用于生产系统使用的最终数据存储位置。

敏感（可选）

敏感数据所在之处。它连接到所有其他阶段，并促进数据访问治理，以确保符合公司和政府规定。

2014 年，提出了两种新的架构，以允许规模化的批处理和流处理：Lambda（由 Nathan Marz 提出）和 Kappa（由 Jay Kreps 提出）。Lambda 架构（见图 5-1）使用独立的技术堆栈，用于批处理层（涵盖所有（历史）事实）和用于实时数据的速度层。

图 5-1. Lambda 架构

新数据进入系统后，同时存储在持久数据集（批处理层）和易失缓存（速度层）。第一个随后被索引，并可供批处理视图的服务层使用，而第二个通过速度层提供实时视图。这两个数据集（持久和易失）可以并行或不交叉查询以回答所需问题。这种架构通常部署在 Hadoop 环境中，其中可以利用 HDFS 作为批处理层，而像 Spark、Storm 或 Beam 这样的技术可以用于速度层。例如，Hive 最终可以成为服务层实现的解决方案。

在 Kappa 架构（显示在 图 5-2 中），您可以使用单一技术堆栈（例如，Beam/Spark）同时进行实时和批处理。核心是流式架构。首先，事件流平台存储传入数据。从那里，流处理引擎实时处理数据，使数据可用于实时视图。在此阶段，数据可以持久化到数据库，以便在需要时执行批量分析并利用相同的技术堆栈。

图 5-2. Kappa 架构

数据目录

数据分散在多个站点，包括数据库、数据仓库、文件系统和 Blob 存储。此外，数据可能存储在数据湖的不同区域：原始、暂存、生产或敏感。这使得数据科学家难以找到所需的数据，业务用户难以访问最新数据。我们需要一个解决方案来使所有这些数据源可发现和可访问。

数据目录是描述组织数据集所有元数据的存储库，将帮助数据科学家、数据工程师、业务分析师及其他用户找到通向所需数据集的路径。在 图 5-3 中，您可以看到一个可能的高级架构，描述了数据目录如何连接数据湖和数据平台的其他解决方案。

图 5-3. 数据目录支持数据处理

如果数据分布在多个数据存储库中（其中一个是数据湖），但处理引擎和用于分析工作负载的 Gold 存储库位于数据湖内，请确保数据目录是全面的，并且数据没有重复。确保元数据包含有关数据集级别的信息（例如，主数据或副本）。

在将主数据集引入和转换到数据湖时，可能需要在计算后进行同步。在 图 5-3 中，您可以看到这种与数据处理的数据目录高级集成：

1. 元数据目录的履行。

2. 搜索所需的数据资产。

3. 如果数据资产尚未存储在数据湖中，则将其复制到 Bronze 存储区域。

4. 在复制的数据资产上执行所需的转换。

5. 根据需要更新原始数据资产。

数据目录可以帮助理清组织可能拥有的各种数据集，因为它可以帮助找到重复的、未使用的或类似的数据集，并根据需要删除、废弃或合并它们。数据目录可以帮助组织专注于对它们最相关的数据，并避免使用资源来存储和处理无用的数据，这可能会带来成本节约。

当数据在组织内共享时，拥有关联的数据合约是有益的。数据合约通常是捕获数据生产者和消费者之间协议的 JSON/YAML 文件，涵盖数据的模式、摄取/发布频率、所有权以及数据访问级别，包括匿名化和数据屏蔽。

Hadoop 景观

Hadoop 仍然是数据湖在本地和云上的事实标准。数据湖的概念始于 MapReduce 和 Hadoop 技术（参见 “反模式：数据集市与 Hadoop”）。Hadoop 的流行已经持续了 15 年，为数据摄取、存储、处理和可视化创建了丰富的项目生态系统。这导致像 IBM 和 Cloudera 这样的公司开发了商业发行版。Databricks 提供了多云 Hadoop 能力。在 Table 5-1 中，我们列出了框架中一些常用工具按用例划分。

在 Table 5-1 中列出的解决方案可以部署在本地环境中，但也可以通过 IaaS 方法轻松部署在云中。超大规模云计算服务商将这些热门产品转化为完全托管的解决方案，以减轻用户在供应和基础设施管理方面的负担，增加固有的可伸缩性和弹性，并降低成本。 Table 5-1 还概述了云中提供的最流行解决方案，以促进流行的本地 Hadoop 技术的云迁移和采用。

Table 5-1. Hadoop 环境下的解决方案

用例	本地部署、Databricks	AWS	Azure	Google Cloud Platform
工作流	Airflow, Oozie	Data Pipeline, Airflow on EC2, EMR	HDInsight, Data Factory	Cloud Composer, Cloud Dataproc
流式摄取	Apache Kafka, MapR Streams	Kinesis, Kinesis Data Streams, Managed Kafka	Event Hubs	Cloud Pub/Sub, Confluent Apache Kafka
流计算	Beam, Storm	Beam on Flink, Kinesis Data Streams	Beam on HDInsight, Stream Analytics	Cloud Dataflow
SQL	Drill, Hive, Impala	Athena, Redshift	Synapse, HDInsight	BigQuery
NoSQL	HBase, Cassandra	DynamoDB	Cosmos DB	Cloud Bigtable
文件系统	HDFS, Iceberg, Delta Lake	EMR	HDInsight, 数据湖存储	云 Dataproc
安全性	Sentry, Ranger, Knox	AWS IAM	Azure IAM	云 IAM, Dataplex
批量计算	Spark	EMR	HDInsight, Databricks	云 Dataproc, 无服务器 Spark

在我们审查三大主要云服务提供商的数据湖参考架构时，请参阅表格。

云数据湖参考架构

在本节中，我们将审查在公共云中利用三大主要超级扩展者的服务实施数据湖的一些参考架构。与任何云架构一样，没有 一刀切 的设计。始终会有几种不同的选择可供选择，可能适合您特定的需求。

亚马逊网络服务

AWS 的托管 Hadoop 服务是 Amazon Elastic MapReduce (EMR)。然而，这仅提供分析数据处理。AWS 建议我们更全面地考虑数据湖，并考虑使用 Amazon Athena 或 Amazon Redshift 更好地进行结构化数据的分析。此外，原始数据可能尚未存在于云存储 (Amazon S3) 中，需要进行摄入。因此，在 AWS 上实现数据湖的推荐方式是利用 AWS Lake Formation。这是一个完全托管的服务，可以实现数据收集、数据清洗/处理和数据移动的自动化，以便为分析和机器学习工作负载提供数据。它配备了一个权限服务，扩展了 AWS IAM 的能力，并允许更好地进行数据治理和安全管理（例如，细粒度策略、列级和行级访问控制等）。查看图 5-4 中的架构，我们可以识别以下主要组件：

• 数据源，本例中为 Amazon S3、关系数据库和 NoSQL 数据库

• 存储区域位于 Amazon S3 存储桶之上

• 由 AWS Lake Formation 协调的数据目录、数据治理、安全性和流程引擎

• 分析服务，例如 Amazon Athena、Amazon RedShift 和 Amazon EMR，以提供对数据的访问

图 5-4. AWS 数据湖架构

此架构适用于管理结构化、半结构化和非结构化数据的任何用例。一旦数据准备和转换完成，即使对于数据湖之外的解决方案（如 Databricks 或 Snowflake），也可以通过 AWS S3 服务的广泛性轻松提供数据，后者可能与平台上的任何其他服务连接。

微软 Azure

在 Azure 平台上，有几种实现数据湖的方法，因为有不同的解决方案可以帮助设计可能的目标架构。通常情况下，我们会看到图 5-5，在此架构中，我们可以识别以下主要组件：

Azure 数据湖存储 Gen2 (ADLSG2)

针对大量数据进行优化的对象存储，与 HDFS 完全兼容，并且通常由用户实现数据湖的所有数据区域

Azure Data Factory

无服务器解决方案，用于摄取、转换和操作数据

Azure Purview

提供治理的解决方案，用于在数据范围内查找、分类、定义和执行策略和标准

Azure Synapse Analytics

用于针对存储在 ADLSG2 中的数据发出 SQL 查询的分析服务

Databricks

基于 Spark 处理引擎的完整分析和 ML 解决方案

Power BI

业务智能（BI）报告和可视化工具

图 5-5. Azure 数据湖架构

需要注意的是，Azure Databricks 可以与 Azure HDInsight 互换使用。两者的主要区别在于，Databricks 是基于 Apache Spark 的分析平台，经过优化以适配 Microsoft Azure 云服务平台，而 HDInsight 是一个托管的完整 Apache Hadoop 分发版（即不仅限于 Spark 工具，但对 Azure 的适配程度较低）。如果您想使用标准的 Hadoop 生态系统解决方案，应选择 HDInsight；而如果您倾向于利用基于 Spark 的完整分析和 ML 解决方案，应选择 Databricks。

注意

尽管 Databricks 可在所有主要云提供商上使用，但其与 Azure 的本地紧密集成使其独特之处在于，它可以被视为一种第一方服务，而不是第三方服务。

Google Cloud Platform

在 Google Cloud Platform（见图 5-6），各个无服务器和完全托管的组件通过 API 相互通信。我们可以识别出以下主要组件：

Data Fusion

一种用于批处理和流处理数据摄取和转换的解决方案

Pub/Sub

用于集成从 Data Fusion 输入的输入和由 Dataproc 交付的 Hadoop 集群的消息中间件

Dataproc

提供按需 Apache Hadoop 集群，提供 HDFS、Spark 和非 Spark 能力

云存储

实现数据区域的对象存储解决方案

Bigtable 和 BigQuery

分析和实时数据处理引擎

Looker/Looker Studio

BI 和可视化解决方案

Dataplex

一个统一的界面，用于处理数据治理、数据目录和安全性

Composer

基于 Apache Airflow 的数据工作流编排服务，使用户能够编写、调度和监控管道

图 5-6. Google Cloud Platform 数据湖架构

根据您的使用案例，Hadoop 或 HDFS 集群可能并不总是最合适的选择。将数据存储在云存储中使您能够根据手头工作选择合适的工具，而不是仅限于 HDFS 集群上可用的工具和计算资源。例如，许多临时 Hive SQL 查询可以轻松迁移到 BigQuery，后者可以使用其本地存储或直接从云存储读取/查询。类似地，流式应用程序可能更适合于 Apache Beam 流水线，这些可以在 Dataflow 上运行，Dataflow 是一个完全托管的流式分析服务，通过自动缩放和批处理大大减少了延迟、处理时间和成本。

注

在选择云供应商时，您还应考虑其提供的本地数据集。例如，在市场营销或广告领域，利用这些数据集实施业务解决方案可能会产生非常大的影响。一些数据集的例子包括 AWS 上的开放数据、Google Cloud 的公共数据集和 Azure 的开放数据集。如果您在 Google 上进行广告投放或在亚马逊上销售产品，这些公司不同部门之间及其各自云平台之间的现成集成可能特别有帮助。

现在您已经熟悉了云数据湖的参考架构，让我们深入探讨如何通过第三方解决方案扩展数据湖。

集成数据湖：真正的超能力

数据湖技术因其能够处理任何类型的数据而变得流行，从结构化的表格格式到文本或图像等非结构化文件。这使得许多以前不可能的用例得以实现，例如通过对发票进行文本分析来分析供应商、识别电影场景中的演员，或实现实时仪表盘以监控电子商务网站上的销售情况。数据湖的超能力在于它能够将数据与无限数量的处理引擎连接起来，从而激活您可能有的任何用例。

扩展湖的 API

在数据湖中，数据摄取过程始于原始数据被导入到登陆区。数据摄取后，必须进行处理（可能涉及多次传递），然后才能进行可视化和激活。每个步骤可能涉及数据湖本身或云中托管的各种引擎，或者在某些情况下是本地第三方产品。

为了使位于混合环境中的不同系统能够通信和交换数据，可以使用 API。API 是允许两个或更多系统通过共享的协议（例如 HTTPS 和 gRPC）进行通信的软件组件。大多数现代应用程序使用 API 来集成服务和交换数据。即使存在特定连接器，它们通常也是构建在 API 之上的。您可以将 API 视为数据可以从一个系统流向另一个系统的高速公路。用于保护数据流量的安全措施是收费站，速率限制则是速度限制。由于这些高速公路，数据可以在多个系统之间流动，并且可以由任何类型的处理引擎处理，从标准 ETL 到现代 ML 框架如 TensorFlow 或 PyTorch。

组织可以通过 API 将其数据湖演化到所需的外部服务。API 还可用于监视、配置、调整、自动化，当然还包括访问和查询湖本身。

使用 Apache Iceberg、Apache Hudi 和 Delta Lake 推动数据湖的演进

将数据湖与其他技术集成的主要目标是扩展其能力，超越 Hadoop 框架提供的开箱即用功能。在考虑标准的 Hadoop 堆栈时，通常有一个缺失的元素，这通常由其他技术（例如在线事务处理[OLTP]数据库）处理：ACID 事务管理。Apache Iceberg、Apache Hudi 和 Delta Lake 是构建在 HDFS 之上的开源存储层，专门解决了这一关键方面。虽然它们各自具有一系列不同的功能（例如，Apache Iceberg 支持比 Apache Hudi 和 Delta Lake 更多的文件格式），但也有一些共同的元素：

• 符合 ACID 标准，确保用户查询的信息一致性

• 克服 HDFS 在文件大小方面的固有限制——使用这种方法，即使是小文件也可以完美运作

• 记录对数据所做的每一次更改，确保在必要时进行完整审计，并支持时间旅行查询

• 处理批处理和流式输入和处理没有差别

• 与 Spark 引擎完全兼容

• 基于 Parquet 格式的存储，能够实现高水平的压缩

• 支持流处理

• 能够将对象存储视为数据库

• 在行和列级别应用治理

这些存储解决方案可以启用通常由其他技术处理的几个用例（例如数据仓库，我们将在第六章中详细研究），主要是因为能够防止数据损坏、以非常快的模式执行查询并频繁更新数据。这些新的启用存储的事务特性非常特定，发挥着至关重要的作用——这些特性与 GDPR 和加利福尼亚消费者隐私法案（CCPA）相关。根据这些法规，组织被迫具备根据特定请求清除特定用户相关个人信息的能力。在标准 HDFS 环境中执行此操作可能是耗时且资源消耗大的，因为必须识别、摄入、过滤和写入新文件，并删除原始文件中与请求的个人数据相关的所有文件。这些新的 HDFS 扩展简化了这些操作，使其易于快速执行，更重要的是，可靠性高。

这些开源项目已被社区广泛采用，并且社区正在大力投资它们的开发。例如，Netflix 广泛使用 Apache Iceberg，而 Uber 的数据平台则由 Apache Hudi 驱动。尽管 Delta Lake 是 Linux 基金会的项目，但其主要贡献者是 Databricks，这是开发和商业化了整个基于供应商专有版本的 Spark 和 Delta Lake 的大数据工作负载处理套件的 Spark 引擎背后的公司。

除了 ACID 之外，还有两个功能正在改变用户在数据湖中处理数据的方式：

分区演化

这是更新文件（即表格）上的分区定义的能力。分区是允许文件系统将文件内容分割为多个块的信息，以避免在检索信息时完成全面扫描（例如，提取 2022 年第一季度的销售数据时，您应该能够仅查询属于该年度第一季度的数据，而不是查询整个数据集然后过滤掉您不需要的数据）。考虑到文件中分区的定义可能因业务需求（例如，我们想要收集洞察力的设备的工作时间）而演变，因此具有能够以透明且快速的方式处理这些变化的文件系统至关重要。从逻辑角度来看，HDFS（通过 Hive）可以实现这一点，但所需的计算工作使其实际上难以实现。请注意，在撰写本文时，此功能仅由 Apache Iceberg 提供。

模式演化

就像分区一样，模式可能需要随时间更新。您可能希望在表中添加、删除或更新列，而文件系统应能够在不重新转换数据（即无需 ELT/ETL 方法）的情况下大规模执行此操作。请注意，尽管在撰写本文时，只有 Apache Iceberg 完全支持此功能，但所有解决方案都能够在利用 Apache Spark 作为引擎时处理模式演化。

现在您已经看到如何扩展数据湖的能力并丰富可以用它们解决的广泛用例集，让我们看看如何实际与数据湖进行交互。

使用笔记本进行交互式分析

处理数据时最重要的一点是能够以非常简单且快速的方式交互式地访问数据并执行分析。在利用数据湖时，数据工程师、数据科学家和业务用户可以利用大量服务（如 Spark、Pig、Hive、Presto 等）处理数据。在几个社区中，尤其是在数据科学家中，一种大受欢迎的解决方案被认为是组织在数据分析中可以利用的最佳瑞士军刀：Jupyter Notebook。

Jupyter Notebook 是一个开源应用程序，用于编写包含文本、待执行代码、绘图和图表的实时文档。它可以被视为一个实时书籍，在您使用类似 Markdown 的标记语言编写文本的同时，还有执行一些数据操作（例如查询、转换等）的代码，并最终绘制一些结果，生成图表或表格。

从架构角度来看，您可以将 Jupyter Notebook 视为在数据湖顶层运行的三个不同组件，如图 5-7 左侧所示。HDFS 是存储，内核是处理引擎，而 Jupyter 是利用处理引擎访问数据，并通过浏览器为用户提供笔记本内容编写和执行的服务器的界面。有几种内核可供利用（例如机器学习常用的 PyTorch），但数据工程中最常见的选择是 Spark，可以通过 Python 编程语言编写的 PySpark 访问（如图 5-7 右侧所示）。

图 5-7. Jupyter 通用笔记本架构和基于 Spark 的内核

一旦正确配置，您可以立即在笔记本中直接编写文本和代码，并与数据集进行交互，就像在利用 Spark 命令行界面时那样。您可以使用笔记本开发和与组织内的其他人员共享代码，执行快速测试和分析，或快速可视化数据以获取额外的洞察。需要强调的是结果不是 静态 的，因为它们是 活动 文档：这意味着如果底层数据集发生变化或代码段变更，当与笔记本共享的人重新执行笔记本时，结果将不同。分析完成后，通常有两条不同的路径可供选择：

• 与其他数据科学家、数据工程师、开发人员或任何希望贡献的人分享笔记本的源代码（Jupyter Notebook 生成 .ipynb 文件）。他们可以在其环境中加载文件并重新运行代码（当然需要具备对底层存储系统及通过 API 集成的任何其他解决方案的正确访问权限）。

• 通过生成 HTML 页面或 PDF 文档使结果静态化，可以与更广泛的用户群共享。

笔记本已经成为互动数据分析、测试和实验的事实标准解决方案，这是因为它们极其灵活，无论是在可以利用的编程语言（多亏了众多可用的内核），还是在可以进行的活动方面（例如，您可以从数据湖中的数据生成图表，或者在将复杂的机器学习算法应用于数据的小子集之前进行训练）。

我们与几家组织合作时看到的情况是，笔记本方法 是推动 数据民主化之旅 的第一步（我们将在下一节讨论），因为它允许技术上更有能力的人立即和标准化地访问数据，促进协作方式。虽然数据科学家是笔记本使用的先驱，但数据工程师和分析工程师也在继续采用它们。我们甚至看到一些公司开发了自定义库，以便包含在 笔记本模板 中，旨在促进与多种其他解决方案（现成或自定义开发的）的集成，将标准化提升到另一个层次，并减少最终用户（甚至是痛苦的）学习曲线。由于容器技术的存在，这种标准化甚至已经扩展到计算层面：每当公司内的用户启动笔记本时，实际上是在后台启动一个具有适当数量计算资源和一组工具的容器，这些工具立即可供其用于数据分析。

云超大规模供应商正在提供一些解决方案的托管版本，如 AWS SageMaker、Azure ML Studio 和 Google Cloud Vertex AI Workbench，这些解决方案可以帮助消除与基础架构管理相关的头疼问题，因为它们是完全托管的。

现在你更好地理解了如何利用 Jupyter Notebook 扩展数据湖，我们将把注意力转向帮助你理解组织内部如何处理从数据摄入到数据可视化报告的数据，从完全的 IT 模式转向更为民主的方法。

数据处理和报告民主化

数据为组织提供的最大价值在于它使决策者和普通用户能够做出知情决策。为此，任何授权的个人都应能够访问和使用数据，而无需临时专业知识和专长。即使从技术角度来看实现数据访问的民主化在公司内是可能的，但仅专注于技术是不够的。组织还需要实施数据目录和治理操作。拥有描述正确数据集的良好元数据将使用户能够找到他们所需的正确信息，并激活正确的数据处理和报告。在本节中，我们将探讨关键技术，帮助组织从完全由 IT 驱动的方法转向更为民主化的方法，建设云数据湖。

在数据中建立信任

当这本书的一位作者几年前为一家重要的零售客户担任顾问时，他努力开发解决方案，自动从销售数据库中提取数据以生成报告，供业务用户利用。每当决策者有以下问题时，他都需要随时可用：

• 你从哪里获取这些数据的？

• 你是如何转换这些数据的？

• 在生成报告之前，你进行了哪些操作？

一旦他被分配到另一个客户那里，组织的 IT 团队接管了整个端到端的过程。虽然他们可以修复错误并监控报告生成，但他们无法说服决策者数据和报告是可信的，因为他们没有足够的知识水平来回答这些问题。

这种信任显然是一个瓶颈，通过使最终用户能够自主地挖掘数据并从摄入到最终报告的值进行审计，这个瓶颈可以消除。过去这种方法可能是不现实的，但现在人们更加数字化经验丰富，有助于转变这种方法。

如图 5-8 所示，从左边代表的旧世界向右边代表的新世界，责任和所有权的明显转变。尽管大部分工作过去由 IT 部门完成，但如今最终用户手中拥有能够处理从数据编目到数据可视化的大部分活动的工具，具备很高的自治权。

图 5-8. 数据访问方法（集中管理 versus 民主数据访问）

工具如 Atlan、Collibra、Informatica、AWS Glue、Azure Purview 和 Google Dataplex 正在使元数据收集过程变得更加简单和快速。一方面，已经构建了大量自动化功能，以实现自动化数据爬取，特别是通过与多个数据库和存储引擎集成（例如 AWS Redshift 和 Athena、Azure Synapse、Google BigQuery、Snowflake 等），另一方面，通过使用丰富且易于使用的用户界面促进数据录入活动，让业务人员能够执行大部分工作。

向上走一步，我们发现即使是数据处理、准备、清洗和整理步骤，这些步骤通常是专为专业用户（即数据工程师）设计的，现在也可以直接由最终用户处理。当然，数据处理的一部分仍然可能需要数据工程师/数据科学家利用像 Spark 这样的先进流程引擎来完成。对于需要主题专家（SMEs）参与的活动，开发和提供的工具如 Talend Data Preparation 或 Trifacta Dataprep 旨在支持非数据工程师/数据科学家用户：探索、转换和过滤只是可以实现的几个活动，利用非常直观的界面将处理委托给底层引擎（例如 Beam），该引擎可以对大型数据集应用所有变更。这种方法甚至强调了访问基础数据的事实，这些数据位于 HDFS 集群上或直接存储在像 AWS S3、Azure Data Lake 或 Google Cloud Storage 这样的对象存储上，可以通过多种不同的工具实现，这些工具提供了广泛的功能和控制。这意味着不同类型的用户可以利用不同类型的工具处理数据。例如，数据工程师可以利用 Spark 开发其数据转换管道；数据科学家可以使用 scikit-learn、TensorFlow 或 PyTorch 实施机器学习算法；业务分析师可以使用 Hive 或 PrestoSQL 使用 SQL 查询执行假设分析。

最后一步是数据可视化/报告，通常是企业用户自行执行的最简单步骤。在这里，有许多解决方案可以利用（例如，Microsoft Power BI、Looker、Tableau 和 Qlik，仅举几例），这些解决方案为用户提供了所需的灵活性。用户在这个阶段往往自然而然地独立进行，因为这些工具在某种程度上与他们在 Excel 中所熟悉的方法相似，所以用户不需要很陡的学习曲线即可精通。数据可视化、商业智能和假设情景分析是企业用户通常可以轻松执行的分析工作。

即使原始数据始终由 IT 部门管理，但在与第三方服务集成的某些情况下，企业用户可以自主将数据摄入数据湖。因此，对数据内容的信任以及不同业务单位摄入的数据集的质量和正确性的相关需求正在增长。管理数据资产以确保企业用户可以访问高质量、一致且易于访问的数据的过程，即“管理”，正在成为解决这一问题的关键因素的组合。

• 及时识别具有正确信息的关键利益相关者。

• 保护数据免受任何内部和外部的外泄，重点放在人员方面。

• 与公司内外的其他人合作，解锁数据的价值。

在许多公司中我们所看到的是，管理并不一定是人们被分配的角色，而更多是由于他们与工具的互动以及他们提供给内部社区的信息质量而获得的头衔。事实上，有几种工具（例如 Informatica Data Catalog）允许用户像亚马逊上的买家评价卖家一样评价数据管理者。

现在，您已经看到了将组织引向更现代和民主方法的各种选择，让我们讨论这个过程中仍然主要由 IT 团队掌控的部分：数据摄入。

数据摄入仍然是 IT 事务

在数据湖中，最关键和重要的步骤之一是数据摄取过程。如果规划不当，数据湖可能会变成“数据沼泽”，积累大量未被使用的数据。这通常发生在组织倾向于将各种原始数据加载到数据湖中，即使他们并没有完全理解为什么要加载这些数据，或者如何利用这些数据。这种方法会导致大量未被使用的数据堆积，这些数据大部分时间都不会被使用。但即使未被使用的数据仍然留在湖中，并占用本应为其他活动所空闲的空间。陈旧的数据也往往存在缺失和不一致性，并在最终被使用时引发难以解决的错误。因此，在摄取过程中遵循以下最佳实践非常重要，您可以在摄取过程中利用这些实践：

文件格式

有几种文件格式可以利用，各有优缺点。如果主要目标是可读性，则 CSV、JSON 和 XML 是最常见的格式。如果性能是最重要的目标，则 Avro、Parquet 或优化行列（ORC）更为合适：

• 当需要强大的 I/O 和低延迟操作时（例如基于事件的源、流式仪表盘），Avro（基于行的格式）表现更好。

• Parquet 和 ORC（基于列的格式）更适合查询使用情况。

文件大小

通常在 Hadoop 世界中，越大越好。文件通常具有数十 GB 的大小，当处理非常小的文件（例如 IoT 使用场景）时，利用流引擎（如 Apache Beam 或 Spark Streaming）将数据合并为少量大文件是一个好主意。

数据压缩

数据压缩对于节省空间非常重要，特别是在每天可能摄取 PB 级数据的数据湖中。此外，为了保证性能，选择一个能够在运行时快速压缩/解压数据的压缩算法至关重要，从而节省大量空间。标准的 ZIP 压缩算法通常不适合此类应用，我们看到组织倾向于利用由 Google 开发的 Snappy，这是一个开源算法，提供与数据湖需求对齐的性能。

目录结构

这是一个非常重要的话题，因为根据用例和要利用的处理引擎，你的目录结构可能会有很大变化。举个例子，通过 HBase 处理的物联网用例：假设你正在全球各地的设备中收集数据，并且想要从特定位置的设备生成的消息中提取特定日期的信息。一个好的目录结构示例可能是/country/city/device_id/year/month/day/hours/minute/second。如果用例是批处理操作，将输入数据放入名为 IN 的文件夹中，并将输出数据放入名为 OUT 的文件夹中可能会很有用（当然，必须用最佳前缀标识以避免误解和数据重复）。

根据数据的性质（批处理与流处理）和数据的目标（如 AWS S3、Azure Data Lake Storage、Google Cloud Storage），可以利用多种解决方案：用户可以使用脚本（例如 PowerShell 或 bash）加载数据，也可以使用 API 或本地连接器直接将数据摄入。用户可以将数据直接流入平台（如 AWS Kinesis、Azure Event Hub 或 Google Pub/Sub），或者将其作为原始文件上传到 HDFS 以供将来处理。IT 部门通常管理这些活动，因为它们可能涉及大量自动化以及需要专门技能的集成/数据处理。然而，像 Fivetran 这样的解决方案正在简化用户配置数据摄入到云端的方式。对于这样的解决方案，甚至较少技术技能的人（例如业务用户）也可能加载数据到数据湖中，扩展我们之前讨论过的民主化概念。

现在你已经了解了如何使数据访问民主化，让我们从高层次来看看数据湖如何促进机器学习算法的训练和预测。你将在第十一章中了解更多相关内容。

数据湖中的机器学习

正如我们之前讨论过的，数据湖可以存储任何类型的数据以其原始格式存在，这与数据仓库不同，数据仓库中的数据需要结构化或半结构化。特别是，可以存储非结构化数据（图片、视频、自然语言等）以其典型格式（JPEG、MPEG、PDF 等）存储。这使得将各种类型的数据引入数据湖变得非常方便，然后可以用于开发、训练和预测机器学习算法，特别是基于深度学习的算法（参见“应用 AI”）。

基于原始数据的训练

您将使用的典型 ML 框架取决于数据的类型。对于结构化数据，可以利用类似 Spark、XGBoost 和 LightGBM 的库。这些框架可以直接读取和处理 CSV 文件中的数据，而这些文件可以原样存储在数据湖中。对于非结构化数据，最常用的 ML 框架是 TensorFlow 和 PyTorch。这些框架可以以其原生形式读取大多数图像和视频格式，而原始数据也将以这种形式存储。因此，在 图 5-9 中，我们详细介绍了 ML 模型训练步骤时，准备的数据可以与收集和存储的数据完全相同，标签可以作为数据的一部分——可以是 CSV 文件中的一列，也可以基于图像/视频的组织方式（例如，所有螺丝图像可以存储在名为 screws 的文件夹中）。这使得在数据湖上训练 ML 模型变得非常简单。

图 5-9. ML 模型训练步骤

然而，还需要考虑一些效率问题——直接读取 JPEG 或 MPEG 文件将导致 ML 训练程序受到 I/O 限制。因此，数据通常会被提取并以 TensorFlow Records 等格式存储在数据湖中。这些格式优化了从云存储中读取时的吞吐量，有助于最大化 GPU 利用率。GPU 制造商还提供了能力，可以直接从云存储读取常见格式，如 Apache Arrow，到 GPU 内存中，从而加速 ML 过程。

在数据湖中进行预测

因为 ML 框架直接支持原始格式数据的读取，因此在原始数据上调用模型也非常简单。例如，在 图 5-10 中，我们展示了在 AWS 上的图像分类工作流程。请注意图像原封不动地被摄入到云存储桶中，并且 ML 模型在上传的图像上被调用。类似的功能也在 GCP 和 Azure 中提供，我们将在 第十一章 中更详细地讨论。

图 5-10. 在 AWS 上上传到数据湖中的图像进行的 ML 推断

如果选择数据湖作为主要平台，还应考虑使用开源项目 MLflow 来实现端到端的 ML 工作流程。数据存储在数据湖中，通常使用 Spark 进行分布式训练，尽管也存在与 TensorFlow 和 PyTorch 的集成。除了训练和部署外，MLflow 还支持高级功能，如模型注册表和特征存储。在 ML 框架中直接处理原始数据的能力是数据湖的一个引人注目的优势之一。

总结

在本章中，您更详细地了解了真实数据湖的概念，挑战以及可以采用的模式，使其成为组织数据平台的核心支柱。关键点如下：

• 数据在每个组织中发挥关键作用，以帮助在短时间内做出健壮的决策，可能是实时的。

• 数据湖比数据仓库更灵活，因为它允许用户处理任何类型的数据（即结构化、半结构化甚至非结构化数据），并利用来自开源生态系统的各种解决方案和工具。

• 组织在旧的本地环境中管理数据湖时遇到了困难。云环境是组织存储数据、降低 TCO 并专注于业务价值而非硬件管理的良好解决方案。

• 云采用的主要优势包括：（1）通过节省存储和计算成本来降低 TCO；（2）通过利用超大规模的扩展性来获得可扩展性；（3）采用快速失败的方法，通过利用底层平台的弹性加快实验速度；以及（4）通过平台上一致的数据治理方法从多个产品中获益，以符合安全性和控制要求。

• 在数据湖中有描述组织数据集的所有元数据存储库，这将帮助数据科学家、数据工程师、业务分析师以及任何可能需要利用数据找到所需数据集路径的用户。

• 数据湖实现了批处理和流处理操作，并促进了 Lambda/Kappa 模式的实施。

• 市场正在大力投资于数据湖，特别是基于云的数据湖。因此，可以通过利用 API 或与第三方解决方案集成来扩展数据湖。

• 一个常见的集成是在 HDFS 顶部采用 Iceberg 或 Delta Lake，使存储符合 ACID，并启用其他类型的用例（主要是那些要求数据强一致性的用例）。

• Jupyter Notebook 是在组织内实现数据分析、实验和基于测试方法的最常见途径。

• 数据湖促进了组织内数据民主化的访问，因为大部分活动可以基于自助服务进行。

• 因为数据在数据湖中以原生格式存储，并且因为 ML 框架支持读取这些格式，所以数据湖可以在没有任何特殊钩子的情况下促进 ML。

在接下来的章节中，我们将探讨数据湖的替代方案，即数据仓库。

第六章：通过企业数据仓库进行创新

在第三章中，您了解到选择作为云数据平台中心组件的数据湖或数据仓库的选择取决于您的组织是以工程/科学为先（选择数据湖）还是以分析为先（选择数据仓库）。在第五章中，我们专注于将数据湖作为数据平台设计的中心要素的概念。在本章中，您将学习如何使用现代数据仓库作为中心要素来解决成本、民主化、灵活性和治理等问题。

我们将从快速回顾构建数据平台所解决的问题开始，并讨论使云数据仓库成为一个吸引人解决方案的技术趋势。然后我们将深入探讨现代数据仓库架构的外观以及如何有效地使用它来启用数据分析师和数据科学家。

现代数据平台

每当你开始一个大型技术项目时，你应该首先问自己，你试图实现什么业务目标，你当前的技术挑战是什么，你想利用什么技术趋势。在本节中，我们将重点帮助您理解在构建现代数据平台时如何解决这些问题，以及企业数据仓库方法如何引导您的数据平台设计。这些概念在前几章中已经被提及，但在这里重新框架它们是有用的，因为它将帮助您将现代数据仓库的设计与架构解决的问题联系起来。

组织目标

在我们的客户访谈中，CTO 们反复提到这些组织目标是非常重要的：

无信息孤岛

数据必须在整个企业中激活，因为业务的一个部分的用户需要访问其他部门创建的数据。例如，确定如何设计明年产品的产品经理可能需要访问由零售运营团队创建和管理的交易数据。

民主化

数据平台必须支持领域专家和其他非技术用户，他们可以直接访问数据，而无需通过技术中介，但应该能够依赖数据的质量和一致性。

可发现性

数据平台必须支持数据工程师和其他需要在不同处理阶段访问数据的技术用户。例如，如果我们有一个数据集，其中原始的传入交易已经被对账，数据科学家需要能够获取对账后的数据集。如果他们找不到它，他们将重建一个对账例程。因此，应该能够发现所有这些“中间”数据集，以确保处理步骤不会在整个组织中重复。

管理

数据集应该由了解其内容的团队控制。例如，财务数据应该由财务部门控制，而不是由 IT 部门控制。

单一数据源

数据应该在原地读取。尽量减少数据的复制和提取。

安全性和合规性

IT 部门应作为数据的经纪人，确保只有具有正确权限的人可以访问数据。必须实施符合法规要求的所有合规性检查（例如 GDPR、CCPA、格拉姆-利奇-布莱利法案）。确保实施将数据分类为敏感/受限数据与开放或行业特定数据的解决方案。

使用便捷性

让报告更容易，因为有数百分析师在创建支持各种功能的报告。

数据科学

提高数据科学团队的生产力，因为这些角色往往成本高且难以招聘。

敏捷性

让决策者更快地获得洞见。

虽然这些目标的相对顺序在组织之间有所不同，但我们与每个组织交谈时所有这些目标都以某种方式存在。因此，现代数据平台应该使 CTO 们能够实现这些目标。

技术挑战

CTO 们在组织内部已经部署的技术中实现这些目标有什么阻碍？CTO 们往往会提到以下技术挑战：

规模和规模

组织收集的数据量随时间急剧增加，并预计将继续增加。他们当前的系统无法扩展，并且无法在业务的速度和成本约束内保持，导致妥协，如对进入的数据进行抽样或大量优先考虑新数据项目。

复杂的数据和使用案例

越来越多的数据是非结构化数据——图片、视频和自然语言文本。他们当前管理结构化和非结构化数据的系统没有交集。然而，在推荐等使用案例中，使用结构化数据（例如产品目录详细信息）和非结构化数据（例如目录图片、用户评论）的需求越来越多。

集成

随着时间的推移，我们看到技术领域出现了许多新的数据源和数据接收端，组织应该和希望利用这些数据。例如，他们希望在 Salesforce 中管理销售信息，在 Adobe 中管理广告活动，在 Google Analytics 中管理网站流量。需要同时分析和决策所有这些数据。

实时性

大部分新数据是实时收集的，能够在数据到达时处理并做出决策具有竞争优势。然而，组织缺乏无缝支持流式处理的数据平台。

当然，这些只是传统大数据挑战的更细化版本：数据量、数据和系统的多样性以及数据的速度。

技术趋势和工具

为了帮助组织实现这些业务和技术目标，云架构师可以利用前面章节中描述的趋势和工具。为方便起见，我们在此处对它们进行了总结：

计算与存储分离

公共云提供者允许您在 Blob 存储上存储数据，并从临时计算资源中访问它。这些计算资源包括 Google BigQuery、AWS Redshift、Snowflake、Amazon EMR、Google Dataproc、Cloud Dataflow 或 Databricks 等软件，这些软件是定制或适应了这种计算与数据处理分离的优势，并将数据处理分布到多个工作节点上。它们涵盖结构化和非结构化数据。

多租户

云计算资源被设计成允许多个租户使用。因此，组织无需为每个部门创建单独的集群或存储阵列。因此，两个不同的部门可以将它们的数据存储在单个数据仓库中，并从它们各自支付的计算资源中访问对方的数据，每个团队可以在共享的常用数据集上启动自己的分析。类似地，组织可以利用自己的计算资源访问多个组织的数据，并对联合数据集进行分析。与传统的 Hadoop 集群不同，不需要在数据的同一位置运行计算工作负载。

认证与授权分离

云 IAM 解决方案可以确保中央 IT 团队安全管理身份，同时数据所有者控制访问权限。实际上，通过提供对组的访问权限，允许访问组织管理成员资格，而数据所有者仅管理指定团队的业务逻辑以提供访问权限。

分析中心

无服务器数据仓库（以及我们在前一章节中看到的数据湖）允许架构师在组织边界之外打破数据孤岛。数据所有者支付存储费用，而数据使用者支付查询费用。此外，数据所有者决定哪些组有权限访问，而组的成员资格可以由数据使用者管理。因此，合作伙伴和供应商可以共享数据，而无需担心查询成本或组成员资格。

多云语义层

诸如 Informatica 或 Looker 的工具使得可以创建跨超大规模云（如 AWS、GCP 或 Azure）、多云数据平台（如 Snowflake 或 Databricks）以及本地环境的语义层。语义层可以即时重写查询，提供一致和连贯的数据字典。（请注意，语义层将在本章后面更详细地介绍。）

一致的管理界面

数据布局解决方案在公共云上提供一致的管理体验，无论数据存储在数据仓库还是数据湖格式（如 Blob 存储上的 Parquet 文件）中。

跨云控制面板

诸如 BigQuery Omni 这样的工具提供了一个一致的控制面板和查询层，无论您的组织使用哪个超大规模云平台（AWS、GCP 或 Azure）存储数据。这些工具在确保可以不受特定数据集存储在哪个超大规模云存储中影响时非常有用。但这也增加了对 GCP 控制面板的依赖性。

多云平台

Snowflake、Confluent 和 Databricks 提供了在任何超大规模云上运行相同软件的能力。然而，与上述不同的是，不同云上的运行时仍然是独立的。这些工具在确保能够从一个超大规模云平台迁移到另一个平台时非常有用。但这也增加了对单一软件供应商的依赖性。

数据湖与数据仓库的融合

使用联合查询和外部查询可以在数据仓库（DWH）中运行 Spark 作业，并在数据湖中运行 SQL 查询。我们将在下一章节中详细讨论这个主题。

内置机器学习

企业数据仓库如 AWS Redshift 和 Google BigQuery 提供了在不移出数据的情况下训练和运行机器学习的能力。Spark 拥有 ML 库（Spark MLlib），而像 TensorFlow 这样的 ML 框架也受到 Hadoop 系统的支持。因此，可以在数据平台上执行机器学习，而不必将数据提取到单独的 ML 平台。

流式摄取

工具如 Kafka、AWS Kinesis、Azure Event Hub 和 Google Cloud Pub/Sub 支持实时将数据落入超大规模云数据平台。AWS Lambda、Azure Functions、Google Cloud Run 和 Google Cloud Dataflow 等工具还支持在数据到达时进行数据转换，以进行质量控制、聚合或语义修正后再写出。

流式分析

数据仓库支持流式 SQL，因此只要数据实时落入数据仓库，查询就反映最新数据。

变更数据捕获

工具如 Qlik、AWS 数据库迁移服务 和 Google Datastream 提供捕获操作关系数据库（如运行在 AWS 关系数据库服务 [RDS] 上的 Postgres 或运行在 Google Cloud SQL 上的 MySQL）变更并实时流式传输到数据仓库的能力。

嵌入式分析

可以使用现代可视化工具如 Power BI 将分析嵌入到最终用户使用的工具（手机或网站）中——不需要让最终用户操作仪表板。

中心集线架构 提供了实现 CTO 所期望目标并利用上述技术能力的可靠方法。

中心集线架构

在设计以现代云数据平台为中心的 DWH 时，集线器和辐式架构是理想的架构。在这种架构中，DWH 充当了收集业务分析所需所有数据的集线器。辐是定制应用程序、仪表盘、ML 模型、推荐系统等，通过标准接口（即 API）与 DWH 交互。工具如 Sigma Computing、SourceTable 和 Connected Sheets 甚至提供了一种电子表格界面，模拟在 DWH 顶部运行的 Excel。所有这些辐可以直接从 DWH 访问数据，而无需复制。

我们建议这种方法适用于没有遗留技术需要适应的初创公司，希望进行全面重建以实现全面转型的组织，甚至是大型企业，因为它具有可扩展性、灵活性和弹性。

它具有可扩展性，因为新的（现代的）DWH 可以轻松集成新的数据源和用例到现有的基础设施，而无需重新配置整个系统。它灵活，因为可以根据企业的特定需求定制整体架构（例如启用流式处理）。而且它具有弹性，因为它可以承受比其他架构更多的故障。

现代云原生企业 DWH 形成集线器和辐式架构的集线器，辐是数据提供者和数据消费者，如图 6-1 所示。请在阅读以下段落时参考图表的组成部分。

图 6-1. 集线器和辐式架构；现代企业 DWH 形成集线器

一个以分析为先的数据和 ML 能力包括将原始数据加载到企业数据仓库（企业数据仓库），然后根据需要进行转换以支持各种需求。由于计算和存储分离，数据只有一个唯一的副本。不同的计算工作负载，如查询（查询 API）、报告/交互式仪表板（商业智能报告工具）和 ML（数据科学和 ML 工具），都可以在这些数据之上进行操作，这些数据位于数据仓库中。由于可以利用 SQL 进行所有转换，您可以使用视图和物化视图来进行详细说明，从而使 ETL 管道变得不必要。这些视图可以调用外部函数，因此可以使用 ML API 和模型丰富数据仓库中的数据。在某些情况下，甚至可以仅使用 SQL 语法训练 ML 模型，并且可以通过简单的 SQL 命令调度复杂的批处理管道。现代数据仓库支持直接摄取（加载 API）甚至流数据（流式 API），因此您必须在需要对数据进行低延迟、窗口聚合分析时利用流式管道。始终记住评估您解决方案的最终成本，并将其与您将获得的收益进行比较。有时一个策略（批处理）可能比另一个策略（流处理）更好，反之亦然。

轮毂和辐条结构背后的关键思想是尽可能高效地将所有数据落入企业数据仓库。当数据来自 SaaS 软件（例如 Salesforce）时，您可以通过计划的自动导出机制加载它。而当数据来自像 PostgreSQL 这样的运营数据库时，您可以通过 CDC 工具实时地将其落入数据仓库。同时，实时数据源预期在发生新事件时向数据仓库发布新数据。某些数据源是联邦的（联邦数据集），这意味着您可以动态查询并将它们视为数据仓库的一部分。现在所有企业数据都逻辑上属于数据仓库，数据科学和报告工具可以对数据进行操作（存储 API/查询 API）。

如果你没有需要迁移的预先存在的 ETL 管道，或者需要支持的预先存在的最终用户的工具选择，那么轮毂和辐条结构就是简单、强大、快速和经济高效的选择。在 Google Cloud 上的一个示例展示了这种架构，如 图 6-2 所示。其他超大规模云服务提供商提供更多选项（例如 AWS 上的 Athena、Redshift、Snowflake）；我们将在 第 7 章 中涵盖这些变化。

图 6-2. 在 Google Cloud 上展现的轮毂和辐条结构

在其完全自动化的形式中，集线器和轮辐对于没有强大工程技能的企业以及进行影子 IT 的小部门是一个很好的选择，因为在数据摄入时几乎没有代码需要维护。此外，您只需具备 SQL 知识就可以完成数据科学和报告活动。

要注意的是，使分析优先的数据仓库（DWH）具备这些能力都是最近的发展。计算和存储的分离是公共云带来的：之前，大数据范式主要由需要将数据分片到本地存储的 MapReduce 主导。分析工作负载要求构建业务特定的数据集市。由于性能限制，需要在将数据加载到这些数据集市之前进行转换（即 ETL）。存储过程是数据仓库，而不是外部函数，它们本身依赖于自动缩放、无状态微服务的发展。机器学习部署需要打包和分发库，而不是无状态机器学习 API。机器学习工作流基于自包含的训练代码，而不是由容器化组件构成的机器学习流水线。流处理涉及单独的代码库，而不是统一的批处理和流处理。

现在您已经了解了集线器和轮辐架构的基本概念，请深入了解其主要组成部分：摄入、业务智能、转换和机器学习。

数据摄入

集线器和轮辐架构中的一个集轮辐（围绕企业 DWH 的盒子在图 6-1 中）对应于将数据（或摄入）导入 DWH 的各种方式。有三种摄入机制：预构建连接器、实时数据捕获和联合查询。我们将在本节分别讨论每一种。

预构建连接器

当利用流行的 SaaS 平台时，将数据着陆到 DWH 可能非常简单，因为它们提供可以通过几次点击自动摄入数据的连接器。每个云原生 DWH（Google BigQuery、AWS Redshift、Snowflake、Azure Synapse 等）通常支持 Salesforce、Google 营销平台和 Marketo 等 SaaS 软件。如果您使用的软件不受您选择的 DWH 支持，请查看软件供应商是否提供连接器以将数据导入所需的 DWH——例如，Firebase（一种移动应用平台）可以直接将移动应用程序的崩溃报告导出到 BigQuery 进行分析（“崩溃分析”）。

您可以设置这些 SaaS 服务，将数据推送到通用的数据仓库（例如，Salesforce 将自动将数据推送到 Snowflake），或者使用 BigQuery 数据传输服务将这些数据集导入到数据仓库。这通常被称为零 ETL——正如无服务器并不意味着没有服务器，只是服务器由他人管理一样，零 ETL 意味着 ETL 过程由您的 SaaS 供应商或您的 DWH 供应商管理。

第三种选择是使用像 Fivetran 这样的第三方连接器提供商。它们预构建的连接器提供了一种即插即用的能力，可以整合来自营销、产品、销售、财务等应用的数据（见图 6-3）。

图 6-3. 像 Fivetran 这样的第三方供应商可以自动处理从各种来源到云数据仓库（如 BigQuery、Redshift 或 Snowflake）的数据着陆

在云提供商的传输服务、支持云连接器的软件供应商以及第三方连接器提供商之间，你可以购买（而不是构建）定期从你的 SaaS 系统导出数据并将其加载到企业数据仓库的能力。

实时数据

如果你希望你的数据仓库能够反映数据发生变化的情况，你需要利用一组被称为 CDC 工具的小型工具集。操作数据库（Oracle、MySQL、Postgres）通常是支持的一部分，企业资源计划（ERP）工具如 SAP 也是如此。确保这些工具使用数据仓库的流式 API 以近乎实时的方式加载数据。在 Google Cloud 上，Datastream 是推荐的 CDC 工具，在 AWS 上则是数据库迁移服务（DMS）。

如果你有实时数据源，比如点击流数据或来自物联网设备的数据，请寻找一种能够在事件发生时即时发布事件的能力，使用数据仓库的流式 API。由于流式 API 可以通过 HTTPS 访问，你只需一种方法来在每次事件发生时调用一个 HTTPS 服务。

如果你的物联网设备供应商不支持推送通知，那么寻找一种将事件发布到消息队列的方法是一个好办法（例如使用消息队列遥测传输或 MQTT），并使用流处理器（GCP 上的 Dataflow、AWS 上的 Kinesis）将这些事件写入数据仓库（见图 6-4）。

图 6-4. 将来自物联网设备的实时数据着陆到数据仓库

联合数据

你甚至可能无需将数据着陆到数据仓库中来使用它。现代云数据仓库能够对标准格式的数据集（如 Avro、CSV、Parquet 和 JSONL）运行查询，而无需将数据移动到数据仓库中。这些被称为federated查询，通常要求数据格式是自描述的，或者模式是预先指定的。例如，让 Google BigQuery 对 Avro 文件执行 federated 查询，一个自描述的格式，需要三个步骤：

1. 使用bq mkdef --source_format=AVRO gs://filename创建表定义文件，并根据需要编辑默认设置。例如，你可能会将 Avro 格式中的整数字段更改为处理为实数字段。

2. 使用生成的表定义文件使用bq mk --external_table_definition mydataset.mytablename创建 BigQuery 数据集。

3. 使用 SQL 正常查询数据集。

注意数据保留在云存储中以 Avro 格式。这是使其成为联合查询的原因。如果数据格式不是自描述的，则mkdef命令允许您指定模式。

甚至可以结合这些步骤，并应用按读模式读取，使得模式定义仅在查询持续期间有效。例如，要使 Azure Synapse 查询 Azure 数据湖中的 Parquet 文件，可以如下查询：

SELECT ... FROM
  OPENROWSET(
     BULK 'https://....dfs.core.windows.net/mydata/*.parquet',
     FORMAT='PARQUET'
  ) AS Tbl

在联合查询的情况下，查询引擎是数据仓库。也可以使用外部查询引擎（如 PostgreSQL 关系数据库）执行查询。这些查询称为外部查询（参见图 6-5）。例如，要让 Amazon Redshift 查询 Postgres 数据库，按以下三个步骤操作：

1. 确保您的 RDS PostgreSQL 实例可以接受来自 Amazon Redshift 集群的连接。为此，您需要设置物理网络，并确保为 Redshift 集群分配了在 PostgreSQL 实例中授权的 IAM 角色。

2. 在 Redshift 中，使用CREATE EXTERNAL SCHEMA FROM POSTGRES创建外部模式，传入数据库、模式、主机、IAM 和秘密信息。

3. 正常查询模式下查询架构。

图 6-5。联合查询与外部查询方法示例，这两种方法在 AWS 和 GCP 中都可用。

在所有这些情况下，需要注意的关键是数据保持在原地并从那里查询 - 不会加载到数据仓库中。因为数据保持在原地时（不能进行分区、聚集等），优化机会更有限，联合和外部查询往往比本地查询更慢。

鉴于联合查询和外部查询较慢，为什么要使用它们？为什么不简单地将数据加载到数据仓库并将数据仓库视为事实源？有一些情况下避免数据移动可能是有利的：

• 在某些情况下，数据仓库内部的存储比外部存储更昂贵。对于很少查询的数据，保持在联合数据源中可能更具成本效益。当需要最佳性能时，请使用数据仓库解决方案提供的本地存储系统。如果灵活性更为重要，则尝试利用联合数据源。

• 如果关系数据库中的数据经常更新，将关系数据库视为黄金源可能是有利的。从操作数据库到数据仓库的 CDC 可能会引入不可接受的延迟。

• 数据可能由工作负载（例如 Spark）创建或需要。因此，可能需要维护 Parquet 文件。使用联合/外部查询限制了数据的移动。当您已经有一个数据湖时，这是最常见的用例。

• 数据可能属于与查询它的组织不同的组织。联合查询巧妙地解决了这个问题。然而，如果您使用的是完全无服务器的 DWH，如 Google BigQuery，并非基于集群，那么甚至可以直接访问合作伙伴和供应商的原生存储。

最后一种情况是我们推荐使用完全无服务器的 DWH 的原因之一，它不期望您将数据移动到集群，创建数据提取或向数据提供特定应用（而不是特定用户）的访问权限。

现在，您对数据摄取的可用选项有了更好的了解，让我们深入探讨如何通过查看我们可以在 BI 方面开发的各种能力，使数据发挥作用。

商业智能

数据分析师需要能够快速从数据中获得洞见。他们用于此目的的工具需要支持自助服务，支持临时分析，并对使用的数据提供一定程度的信任（业务和智能报告工具在轮毂与辐条结构中）。它需要提供多种能力：SQL 分析、数据可视化、嵌入式分析和语义层，我们将在本节中涵盖所有这些内容。

SQL 分析

正如前几节所强调的，SQL 是查询 DWH 时的主要语言。SQL 是组织内数据分析师和业务分析师的通用语言。这些分析师通常会对 DWH 执行临时查询，以帮助回答出现的问题（例如，“罗马尼亚在最近的热浪期间卖了多少升冰淇淋？”）。但在许多情况下，这些问题变得常规化，用户会利用诸如 Power BI 或 Looker 等的临时工具将其操作化为报告的形式。

这些报告工具，通常称为 BI 工具，旨在通过连接到 DWH（业务和智能报告工具在图 6-1 中的轮毂与辐条结构）提供对组织整个数据资产的视图，以便分析师可以做出数据驱动的决策。

考虑到不实际期望分析师在需要时收集、清洗和加载某些数据，数据需要已经存在。这就是为什么以中央企业 DWH 为中心的轮毂与辐条模型如此受欢迎的原因。

但是，你应确保 BI 工具具备云端就绪，并能处理大量快速到达的数据。早期的 BI 工具会要求将数据提取到在线分析处理（OLAP）立方体中以提升性能（参见图 6-6）。这种方法不可取，因为它会导致陈旧的导出数据的增加或者为支持各种用例而维护庞大的 OLAP 立方体带来巨大的负担。你希望 BI 工具能够透明地将查询委托给 DWH 并检索结果。这是充分利用 DWH 规模和其流式接口及时性的最佳方式。企业 DWH 中的 SQL 引擎已经升级到能够处理多个并行查询或在内存中维护大量数据的水平，这使得组织能够摆脱 OLAP 方法。

图 6-6. 确保 BI 工具将所有查询推送到企业 DWH，而不是在 OLAP 立方体上执行（数据库/DWH 的提取）

可视化

你的 SQL 查询将生成表格。然而，仅凭原始表格往往难以获得理解和洞察力。因此，你通常会将结果绘制为图形、图表或地图。将 SQL 查询结果可视化通常是洞察力的来源。

在探索性数据分析中，可视化是临时的。然而，可视化必须通过常见的图表元素帮助解答常见问题。这是像 Tableau、Looker、Power BI 和 Looker Studio 这样的仪表板工具的职责所在。

优秀的仪表板考虑受众并讲述故事。它们既可以作为当前状态的高级概览，也可以作为进一步互动分析的起点。它们使用适当的图表形式显示上下文相关的重要指标。

嵌入式分析

如果你希望与少数内部人员分享分析结果，则通过传统的仪表板工具进行可视化已足够。这些用户将欣赏仪表板提供的丰富控制和互动性。但如果你是一个手工艺品市场或电信运营商，并且希望每位艺术家或每个亭子都能访问其店铺性能的近实时图表，会怎样呢？

当你为成千上万的用户提供定制报告时，你不希望为最终用户提供一个功能丰富的仪表板界面，这会使支持和维护变得困难。相反，你需要的是一个轻量级的图形可视化层，可以嵌入到用户已经在使用的工具中。通常将分析嵌入到艺术家访问以列出销售物品或亭子运营访问以订购新物品的网站或移动应用程序中是很常见的。

提供其商店表现的一致性、实时指标可以显著增强艺术家和经营者在您的市场中赚钱的能力。还可以更好地连接工作流程——例如，使用分析工具，卖家可能能够轻松地更改经常缺货商品的价格。提供预测产品需求等 ML 功能还可能为市场带来新的收入流。

语义层

自助分析和一致性之间存在紧张关系。在您的公司中，赋予每位业务分析师快速创建仪表板的能力非常重要，而不必等待中央 IT 团队。同时，保持仪表板计算方式的一致性至关重要（例如，所有仪表板中的运输成本必须采用相同的计算方式）。尽管业务分析师能够自行构建复杂的仪表板至关重要，但尽可能地重用现有的可视化也很重要。提供一致性和重用的传统方法是将计算和基础功能集中在 IT 部门内。然而，在数据驱动环境中，这种中央化的 IT 中心化解决方案通常过于脆弱和过慢，无法满足业务用户的需求。

像 Looker 或 MicroStrategy 这样的现代 BI 工具提供语义层（参见第二章），帮助解决这种紧张关系。语义层是一个额外的层，允许您使用常见的业务术语，促进最终用户自主访问数据；它通过表创建者采用的命名方式与业务用户采用的名称之间的解耦来工作。Looker 称其为语义模型层的 LookML 是基于 SQL 的数据语言（参见示例 6-1）。它为数据管理员提供了创建可重用维度或度量的能力，业务分析师可以重用和扩展这些定义。这些定义在数据字典中可供轻松发现和管理。

示例 6-1. 语义层由指标和维度的集中定义组成；Looker 的这个示例显示了一个指标（总体健康评分）。

dimension: overall_health_score {
    view_label: "Daily Account Health Scores"
    description: "Weighted average of Usage, User, Support and CSAT Scores"
    Type: number
    Sql: (${usage_score}*2+${user_score}*2+${support_score}+${csat_score})/6 ;;
    Value_format_name: decimal_1
}

这些语义层本身作为 BI 数据源进行功能。例如，Tableau 可以连接到 Looker 的语义层，而不是直接连接到数据仓库。

尽管业务用户通常不会直接看到或与类似 LookML 的工具进行交互，他们可以构建使用定义的维度和指标的仪表板。这有助于促进重用，使每个分析师无需为每个使用的维度或指标从基础表列定义。集中定义指标还能减少人为错误的可能性，并提供更新定义的单一点。这种集中定义存在于文本文件中，便于版本控制。

您已经看到如何借助 BI 工具深入数据，并通过语义层使业务用户自行管理数据。有时这种方法还不够，您需要在将数据摄入数据仓库之前准备数据。在接下来的部分，我们将专注于这个主题。

转换

假设您从 ERP 系统将原始数据加载到数据仓库中。如果 ERP 是 SAP，列名很可能是德语，并反映应用状态，而不是我们认为有用以保持的数据。我们不希望所有用户每次需要数据时都必须将数据转换为可用形式。那么转换应该在哪里进行呢？

一种选项是在 BI 工具的语义层中定义列转换的方式，如前一节所讨论的。然而，这限制了定义为维度和度量，并且从非 BI 工具访问这些定义将会很困难。

更好的方法是在 SQL 中定义转换并创建视图、表格或物化视图。在本节中，我们将看一下数据仓库内处理转换的常见选项。这也是轮式结构的另一个优点：当数据转换在数据仓库中实现时，其结果立即对所有需要它们的用例可用。

第三种方法是利用超大规模应用开发平台。使用事件机制（Eventarc、EventBridge、Event Grid）在创建新表分区时启动无服务器函数（Lambda、Cloud Functions）。然后，函数可以转换并通过调用其 API 将修改后的数据“推送”到后端系统，从而启动业务操作（如发货通知）。这被称为反向 ETL，因为数据流的方向远离数据仓库。

带视图的 ELT

与 ETL 不同，可以将数据加载到数据仓库中并在通过视图读取时即时转换（见示例 6-2）。因为视图在数据加载到数据仓库后即时进行转换（在加载之前不进行转换），这通常称为提取-加载-转换（ELT）工作流的常见方式。

示例 6-2. 在 Azure Synapse Analytics 中的此示例中，SQL 代码通过连接两个表格创建视图。

CREATE VIEW view1
AS
SELECT fis.CustomerKey, fis.ProductKey, fis.OrderDateKey,
    fis.SalesTerritoryKey, dst.SalesTerritoryRegion
FROM FactInternetSales AS fis
LEFT OUTER JOIN DimSalesTerritory AS dst
ON (fis.SalesTerritoryKey=dst.SalesTerritoryKey);

而不是查询原始表格，用户查询视图。创建视图的 SQL 可以选择特定列，对列应用操作（如掩码），并连接多个表格。因此，ELT 为业务用户提供了一致且受控的原始数据视图。因为最终查询在进一步聚合或选择之前运行视图查询，所以所有查询都基于数据仓库中存在的数据反映最新信息。

然而，视图可能在计算资源、时间和/或金钱方面变得非常昂贵。例如，考虑到在 例子 6-2 中显示的视图，该视图将销售订单表与销售地域表进行连接。该视图会查询企业整个生命周期内所有地域的所有销售订单。即使分析人员只对特定年份或地区感兴趣（在这种情况下，过滤掉不相关的数据再执行连接操作是非常有意义的）。

计划查询

如果表格的更新频率较低，则周期性地将数据提取到表格中可能会更加高效。例如，在 Google BigQuery 中，如 例子 6-3 所述，我们指定目标表、查询频率和查询内容。

例 6-3. 在这个 Google BigQuery 的示例中，从订单表中提取原始数据并进行聚合，然后将聚合结果存储在目标表中，每 24 小时执行一次

bq query ...
    --destination_table=Orders_elt.lifetime_value \
    --schedule='every 24 hours' \
    --replace=true \
    'SELECT
 customer_id,
 COUNT(*) AS num_purchases,
 SUM(total_amount) AS lifetime_value
 FROM Orders.all_orders
 GROUP BY customer_id'

在示例中，原始表每 24 小时只查询一次。虽然与目标表格相关的存储成本会增加，但存储成本通常比计算成本便宜几个数量级。因此，创建目标表的成本是相当可控的。

计划查询的关键优势在于分析人员查询的是目标表而不是原始数据。因此，分析人员的查询相对较为廉价。

计划查询的缺点是返回给分析人员的结果可能落后于最多 24 小时。可以通过更频繁地运行计划查询来减少查询落后的程度。当然，如果调度查询的频率越高，成本优势就越容易消失。计划查询的另一个缺点是，如果生成的目标表从未被查询过，那么这些查询可能会造成浪费。

材料化视图

很明显，在第一次请求视图时，将原始数据提取到目标表中是平衡过时数据与成本的最有效方法。随后的查询可以很快，因为可以直接从目标表中检索数据，无需再进行提取操作。与此同时，系统需要监控底层表，并在原始表更改时重新提取数据。可以通过向目标表添加新的原始数据行来使系统更加高效，而不是重新查询整个表格。

尽管你可以构建一个数据工程管道来处理所有这些问题，现代化的云数据仓库（DWHs）支持开箱即用的全面管理的物化视图。在这些系统中创建物化视图类似于创建实时视图（见示例 6-4），你可以像查询任何其他视图一样查询它。数据仓库负责确保查询返回最新数据。数据仓库供应商会为管理物化视图收取一些费用。

示例 6-4. 在 Snowflake 中创建自动数据更新的物化视图

create materialized view vulnerable_pipes
(segment_id, installation_year, rated_pressure)
as
select segment_id, installation_year, rated_pressure
from pipeline_segments
where material = "cast iron" and installation_year < "1980"::date;

但要小心——某些数据仓库系统（例如，撰写时的 Amazon Redshift）并不会自动为您管理物化视图；你需要设置一个调度或触发器来REFRESH物化视图。从这个意义上说，他们所谓的物化视图实际上只是一个表的提取。

Google BigQuery、Snowflake、Databricks 和 Azure Synapse 会透明地维护物化视图内容。视图内容会随着数据添加到底层表中而自动更新。

安全性和血统

数据治理的最佳实践是确保组织跟踪从数据摄取到使用的所有数据转换过程。

一个需要考虑的重要方面是与资源标识相关的问题（例如，整个数据集或表中的某些字段），这些资源必须被视为敏感，并且需要通过设计进行保护。不仅仅是防止公司内应视为机密的信息的访问，还需要在正确管理数据方面做好准备，以符合某些情况下变得越来越严格的政府法规（例如，欧洲的 GDPR，美国的健康保险可携带性和责任法案或 HIPAA 等）。需要注意的是，在谈论安全性和合规性时，你的关注点不应仅限于谁访问了什么（这可以通过细粒度的访问控制列表[ACL]策略管理方法和数据加密/伪装技术通常解决）；它还应该关注：

• 数据的起源

• 在其消费之前应用的不同转换

• 当前物理数据位置（例如，德国的数据湖或英国的数据仓库）

数据血统追踪这种元数据的方式有助于确保使用准确、完整和可信任的数据来支持业务决策。查看数据血统在需要保证数据位置的情况下也是有帮助的（例如，德国的电信元数据）：如果你能追踪数据在其生命周期中的位置，那么你可以采取自动化措施，防止未达到最低要求的人员访问、使用和移动这些信息。

正如您所见，元数据在帮助公司组织其数据并管理其访问方面发挥着核心作用。它也对评估所收集数据的质量（如准确性、完整性、一致性和新鲜度）至关重要：低质量的数据可能导致错误的业务决策和潜在的安全问题。有几种技术和相关工具可以支持数据质量活动，但最常见的是：

标准化

将来自不同来源的数据放入一致的格式中的过程（例如，修正大小写不一致、字符、错误字段中的数据格式等）

去重

识别重复记录（利用相似度分数），然后删除重复值的过程。

匹配

查找数据集之间的相似性或链接，以发现潜在的依赖关系的过程

分析和监控

识别一系列数据值（例如，最小值、最大值、均值），揭示可能暗示需要数据修复或模式演变的异常和异常值的过程

如果您使用云供应商的原生托管服务，在进行数据转换时，工具通常会管理并携带元数据。因此，例如在 Google Cloud 上使用 Data Fusion、视图、物化视图等，Data Catalog 会得到更新并保持血统。如果您使用 Dataflow 构建转换管道，则应更新 Data Catalog。类似地，在 AWS 上，爬虫会自动更新 Data Catalog，但如果您实施自己的转换，则需要调用 Glue API 将其添加到目录中。

您已经看到了 DWH（我们架构中的中心）如何驱动数据转换，使其可以供您希望实现的所有用例使用，并同时跟踪您需要维护的所有元数据，以保持强大的所有加工的血统。现在让我们看看如何设计组织结构来匹配枢纽和辐条架构。

组织结构

在许多组织中，商业分析师比工程师多得多。通常，这个比例是 100:1。枢纽和辐条架构非常适合希望构建主要服务于商业分析师的数据和机器学习平台的组织。因为枢纽和辐条架构假定商业分析师能够编写临时 SQL 查询和构建仪表板，可能需要进行一些培训。

在以分析师为先导的系统中，中心数据工程团队负责（见图 6-7 中的填充形状）：

• 将来自各种来源的原始数据着陆到 DWH 中。许多源可以配置为直接发布到现代 DWH。

• 确保数据治理，包括语义层和个人身份信息（PII）的保护。

• 跨业务单元的工作负载（例如激活），涉及跨业务单元的数据（例如身份解析），或需要专业工程技能（例如 ML）。

• 常见的工件存储库，例如数据目录，源代码存储库，秘密存储，特征存储和模型注册表。

业务单元负责（参见图 6-7 中的未填充形状）：

• 将来自特定业务源的数据引入 DWH

• 将原始数据转换为可供下游分析使用的形式

• 用业务特定工件填充治理目录和工件注册表

• 报告，特定分析和用于业务决策的仪表板

图 6-7. 中央数据工程团队负责填充的形状，而业务单元负责未填充的形状

图 6-7 显示 Google Analytics，Finance 和 Salesforce 作为数据源的示例。在我们的例子中，Google Analytics 数据可能需要跨多个业务单元使用，因此由中央数据工程团队摄入。Finance 和 Salesforce 数据仅需要特定的业务单元使用，因此由该业务单元摄入。

每个业务单元都管理其自己的部署。将数据引入业务团队使用的 DWH 是中央团队的责任。这通常意味着中央团队使用的软件需要在不同云之间可移植，并且由管道生成的数据格式是可移植的格式。因此，Apache Spark 和 Parquet 是构建 ETL 管道的常见选择。

如果两个业务单元选择使用相同的 DWH 技术，那么这两个业务单元之间的数据共享变得更简单，因此在可能的情况下，我们建议整个组织使用相同的 DWH 技术（BigQuery，Snowflake，Redshift 等）。但是，在通过收购进行业务增长的公司中，这并不总是可行的。根据我们的经验，最好为您的 DWH 使用单一的云技术，以充分利用其在所有部门中的能力，即使您采用多云战略也是如此。我们曾与利用两种甚至更多技术的组织合作过，他们在维护所有系统之间的一致性方面付出的努力并不值得其带来的好处。

在本节中，您已经了解了如何通过实施轮毂和辐条架构来现代化您的数据平台，将您的 DWH 置于中心位置。您已经了解到多个辐条可以围绕中心轮毂——您的现代 DWH——旋转，以实现您想要实现的任何用例，无论是批处理还是流处理，都可以利用纯 SQL 语言，并符合数据治理要求。在下一节中，我们将讨论 DWH 如何使数据科学家能够开展他们的活动。

DWH 以支持数据科学家

数据分析师通过对数据进行即席分析创建报告，并通过 BI 将报告操作化，支持数据驱动决策。数据科学家旨在使用统计学、机器学习和人工智能自动化和扩展数据驱动决策。现代云 DWH 需要从数据科学家和数据科学工具中获得什么？正如您在 Figure 6-1 中所看到的那样，他们需要以各种方式与 DWH 交互，执行查询或仅仅获取低级别数据访问。在本节中，我们将看看他们可以利用的最常见的工具，以实现这一目标。

如前一章所示，数据科学家需要进行实验，尝试不同形式的自动化，并了解这些自动化在历史数据的各个切片上的工作方式。正如我们之前看到的那样，数据科学家主要使用的开发工具是笔记本。因此，他们需要有效地访问 DWH 中的数据。这不仅限于通过 DWH 的查询界面进行探索性数据分析，还包括通过 DWH 的存储界面进行操作化（请参考 Figure 6-1）。确保您的云 DWH 支持这两种机制非常重要。让我们看看这些机制是如何运作的。

查询界面

在自动化决策之前，数据科学家需要进行大量的探索性数据分析和实验。这需要以交互方式进行。因此，需要一种快速的方法从笔记本中调用 SQL 查询。

Jupyter 魔法（例如在 Figure 6-8 中单元格中的%%bigquery行）提供了一种从笔记本中调用 SQL 查询的方法，无需样板代码。结果作为本地 Python 对象返回，称为 DataFrame，可以使用数据分析函数库 pandas 进行操作。

图 6-8. 从笔记本中，您可以调用 DWH 上的 SQL 查询，无需样板代码，并将结果返回为易于处理的对象；在此示例中，我们正在调用 BigQuery

需要注意的是，这是在不创建数据的内存提取的情况下完成的。云 DWH 以分布式方式执行 SQL 查询。笔记本服务器无需运行在与 DWH 相同的计算基础设施上。

使用 DWH 后端进行大规模数据处理，并结合笔记本前端的编程和可视化能力，对于数据科学家来说是强大且必要的。

存储 API

尽管笔记本-DWH 连接的交互能力对于探索和实验很重要，但对于自动化而言，数据访问速度至关重要。ML 框架应该能够绕过查询 API，直接访问 DWH 的存储层。存储访问应支持从多个后台线程并行读取，因为常见情况是在 ML 加速器（GPU 或 TPU）对前一批数据进行大量计算时读取下一批数据。

因此，不再使用查询 API，而是使用 ML 框架支持的存储 API 从 DWH 高效并行地读取数据。使用 Spark 和 TensorFlow 从 Google BigQuery 读取数据的存储 API 的示例见示例 6-5。

示例 6-5. 直接使用 Spark（顶部）或 TensorFlow（底部）从 Google BigQuery 读取数据，而无需经过查询层。

df = spark.read \
  .format("bigquery") \
  .load("bigquery-public-data.samples.shakespeare")
def read_bigquery():
  tensorflow_io_bigquery_client = BigQueryClient()
  read_session = tensorflow_io_bigquery_client.read_session(
      "projects/" + PROJECT_ID,
      "bigquery-public-data", "samples", "shakespeare",
      ...,
      requested_streams=2)

  dataset = read_session.parallel_read_rows()
  transformed_ds = dataset.map(transform_row)
  return transformed_ds

查询接口和存储 API 是数据科学家用来访问 DWH 中数据以进行分析的两种方法。现在有一个新趋势需要考虑——在 DWH 中直接实现、训练和使用 ML 算法，而无需提取数据。在下一节中，我们将看看它是如何工作的。

不移动数据的 ML

在撰写本文时，一些现代化的云 DWH（如 BigQuery 和 Redshift）还支持在 DWH 中训练 ML 模型，而无需首先提取数据。它们通过在 SQL 中训练简单模型，并通过 Vertex AI 和 SageMaker 分别委托任务来训练更复杂的模型。让我们看看如何直接从您的 DWH 中利用训练和服务（称为 激活）您的 ML 算法。

训练 ML 模型

假设您想要训练一个 ML 模型，以预测用户是否会流失，给定账户的特征和账户上的费用：可以利用历史数据完成所有操作，如示例 6-6 所示。训练的模型类型可以非常复杂。

示例 6-6. 在 AWS RedShift 中开发和训练分类 ML 模型，利用您已有的 DWH 中的历史数据。

CREATE MODEL customer_churn_auto_model FROM (SELECT state,
             account_length,
             area_code,
             total_charge/account_length AS average_daily_spend,
             cust_serv_calls/account_length AS average_daily_cases,
             churn
      FROM customer_activity
      WHERE  record_date < '2020-01-01'
     )
TARGET churn FUNCTION ml_fn_customer_churn_auto
IAM_ROLE 'arn:aws:iam::XXXXXXXXXXXX:role/Redshift-ML'SETTINGS (
  S3_BUCKET 'your-bucket'
);

您可以使用访客实际购买的历史数据训练推荐系统，如示例 6-7 所示。

示例 6-7. 在 Google BigQuery 中开发和训练推荐 ML 模型，利用您已有的 DWH 中的历史数据

CREATE OR REPLACE MODEL bqml_tutorial.my_implicit_mf_model
OPTIONS
 (model_type='matrix_factorization',
  feedback_type='implicit',
  user_col='visitorId',
  item_col='contentId',
  rating_col='rating',
  l2_reg=30,
  num_factors=15) AS
SELECT
 visitorId,
 contentId,
 0.3 * (1 + (session_duration - 57937) / 57937) AS rating
FROM bqml_tutorial.analytics_session_data

示例 6-8 展示了使用仅两条 SQL 语句编写的异常检测系统。

示例 6-8. 在 BigQuery 中用 SQL 开发的异常检测模型

CREATE OR REPLACE MODEL ch09eu.bicycle_daily_trips
OPTIONS(
    model_type='arima_plus',
    TIME_SERIES_DATA_COL='num_trips',
    TIME_SERIES_TIMESTAMP_COL='start_date',
    DECOMPOSE_TIME_SERIES=TRUE
)
AS (
    SELECT
        EXTRACT(date from start_date) AS start_date,
        COUNT(*) AS num_trips
    FROM `bigquery-public-data.london_bicycles.cycle_hire`
    GROUP BY start_date
);

SELECT *
FROM ML.DETECT_ANOMALIES(
    MODEL ch09eu.bicycle_daily_trips,
    STRUCT (0.95 AS anomaly_prob_threshold))
ORDER BY anomaly_probability DESC

仅使用 SQL 就能进行 ML，而不必设置数据移动，使得更多组织能够进行预测分析。这使得 ML 民主化，因为利用典型的 BI 工具的数据分析师现在可以实现预测。这也极大地提高了生产力—如果仅需两行 SQL 就能识别异常活动，那么组织更有可能实现这一目标，而不是依赖熟练掌握 TensorFlow 或 PyTorch 的数据科学家进行为期六个月的项目。

ML 训练和服务

ML 训练不是现代 DWH 支持的唯一 ML 活动。它们还支持以下能力：

• 将训练好的 ML 模型导出为标准 ML 格式，以在其他地方部署

• 将 ML 训练整合到 DWH 中作为更大 ML 工作流的一部分

• 作为外部函数调用 ML 模型

• 直接将 ML 模型加载到 DWH 中，以分布式方式有效调用 ML 预测

让我们一起看看这四种活动，它们为何如此重要，以及现代 DWH 如何支持它们。

导出训练好的 ML 模型

在 DWH 中训练的 ML 模型可以使用 ML.PREDICT 批处理模式直接调用历史数据。然而，对于需要实时结果的现代应用来说（例如基于连接用户的电子商务应用，需要决定在页面中显示哪些广告），这样的能力是不够的。必须能够在线调用模型—也就是作为同步请求的一部分，用于单个输入或少量输入。

您可以通过允许模型部署到 SageMaker 端点来在 Redshift 中完成此操作，并在 Google Cloud 中以 SavedModel 格式导出模型。从那里，您可以将其部署到支持此标准 ML 格式的任何环境。当然，支持 Vertex AI 端点，但也支持 SageMaker、Kubeflow Pipelines、iOS 和 Android 手机以及 Coral Edge TPUs。Vertex AI 和 SageMaker 支持部署为微服务，通常用于包括网站在内的服务器应用程序。部署到管道支持流数据处理、自动交易和监控等用例。部署到 iOS 和 Android 支持移动电话，部署到 Edge TPU 支持自定义设备，例如汽车和亭子的仪表板。

在 ML 流水线中使用您的训练模型

很少有数据科学家的实验仅涉及训练一个 ML 模型。通常，一个实验包括一些数据准备、训练多个 ML 模型、测试和评估、选择最佳模型、创建模型的新版本、在一小部分流量上设置 A/B 测试以及监控结果。这些操作中只有少数在数据仓库中完成。因此，数据仓库中完成的步骤必须是较大 ML 工作流的一部分。

ML 实验及其工作流程都被记录在 ML 管道中。这些管道包含多个容器化步骤，其中少数步骤会涉及数据仓库（DWH）。因此，数据准备、模型训练、模型评估等在成为 ML 管道的一部分时，必须作为容器调用。

管道框架提供了方便的函数来在云数据仓库上调用操作。例如，要从 Kubeflow Pipelines 中作为容器化操作调用 BigQuery，可以使用 BigQuery 运算符。

调用外部 ML 模型

当今，ML 是处理非结构化数据（例如图像、视频和自然语言文本）的常见方法。在许多情况下，已存在许多种类非结构化内容和用例的预训练 ML 模型——例如，可以使用预训练 ML 模型来检测某些评论文本是否含有有毒言论。您无需训练自己的有毒言论检测模型。因此，如果您的数据集包含非结构化数据，能够调用 ML 模型对其进行处理非常重要。

在 Snowflake 中，例如，可以使用 EXTERNAL FUNCTION 调用 Google Cloud 的 Translate API。您可以通过通过网关创建 API 集成，然后按照示例 Example 6-9 配置 Snowflake 来实现这一点。

示例 6-9. Snowflake 第三方 API 集成示例

create or replace api integration external_api_integration
    api_provider = google_api_gateway
    google_audience = '<google_audience_claim>'
    api_allowed_prefixes = ('<your-google-cloud-api-gateway-base-url>')
    enabled = true;
create or replace external function translate_en_french(input string)
    returns variant
    api_integration = external_api_integration
as 'https://<your-google-cloud-api-gateway-base-url>/<path-suffix>’;

鉴于此，可以在 SELECT 语句中对列调用 Translate API 是可能的：

SELECT msg, translate_en_french(msg) FROM ...

加载预训练的 ML 模型

使用外部函数调用 ML 模型可能效率低，因为计算没有充分利用数据仓库的分布式特性。更好的方法是加载已训练的 ML 模型，并在其自身的计算环境中让数据仓库调用模型。

在 BigQuery 中，您可以通过首先加载 TensorFlow 模型，然后在 SELECT 语句中使用 ML.PREDICT 来调用它，如 Example 6-10 所示。

示例 6-10. 在 BigQuery 中加载存储在 Google Cloud Storage 中的 TensorFlow 模型并预测结果

CREATE OR REPLACE MODEL
  example_dataset.imported_tf_model
OPTIONS
  (MODEL_TYPE='TENSORFLOW',
    MODEL_PATH='gs://cloud-training-demos/txtclass/export/exporter/1549825580/*')
SELECT *
FROM ML.PREDICT(
  MODEL tensorflow_sample.imported_tf_model,
  (SELECT title AS input FROM `bigquery-public-data.hacker_news.stories`))

因为 ML.PREDICT 不需要数据仓库从已部署的模型服务中进行外部调用，通常速度更快。它也更安全，因为模型已加载且无法被篡改。

总结

在本章中，我们专注于描述数据仓库如何成为现代数据平台的核心，分析如何利用中枢和辐射架构来实现数据分析和机器学习的培训和激活。主要收获如下：

• 现代数据平台需要支持更快地将洞察力提供给决策者。

• 对于没有遗留技术需要适应的组织来说，中枢和辐射架构是理想的架构。所有数据以尽可能自动化的方式落入企业数据仓库。

• 可以使用预构建的连接器摄取大量 SaaS 软件的数据。

• 使用 CDC 工具可以使数据仓库反映在 OLTP 数据库或 ERP 系统中所做的更改。

• 可以联合数据源，如 blob 存储，确保某些数据无需移到数据仓库。

• 可以在支持 SQL 的关系数据库上运行外部查询。

• 为了支持业务分析，投资于一个将操作推送到数据库而不是依赖提取 OLAP 立方体的 SQL 工具。

• 当您有数千到数百万客户时，更可扩展的方式是提供一个轻量级的图形可视化层，可以嵌入用户已经使用的工具内。

• 建立语义层来捕获关键绩效指标、度量和维度，促进一致性和重复利用。

• 视图提供了一种使落入数据仓库的原始数据更易用的方法。定期查询以将视图内容提取到表格可能更具成本效益。物化视图集成了两者的优点。

• 数据治理和安全性变得更加重要，因为数据爆炸，架构变得更加复杂，访问和利用数据的用户数量增加，立法者正在引入更严格的规则来处理数据。

• 数据科学家需要能够从笔记本交互式地访问数据仓库，运行无样板代码的查询，并直接从仓库存储中批量访问数据。

• 能够在不移动任何数据的情况下进行机器学习，并使生成的机器学习模型在多个环境中可用，有助于推动业务各个部分的 AI 使用。

• 组织上，一些数据工程和治理功能是集中管理的，但不同的业务部门以不同方式转换数据，只在需要时才进行。

在下一章中，我们将讨论数据湖和数据仓库世界的融合，并看看现代平台如何利用两种范式的优势，为最终用户提供最大的灵活性和性能。

第七章：走向湖仓

正如你现在所知，组织在设计其数据平台时可以采取两种主要方法：遵循数据湖或数据仓库范式。这两种方法各有利弊，但问题是：是否可能使这两种技术共存以实现收敛架构？在本章中，我们将探讨这个主题，从这个想法的简要动机开始，然后分析收敛架构的两个广泛变体——即所谓的湖仓架构——并帮助您决定如何在它们之间做出选择。

湖仓（Lakehouse）概念因其在规模化处理结构化、半结构化和非结构化数据方面的灵活性和可扩展性而日益流行。湖仓可以以一种治理的方式处理整个结构化和非结构化数据的生命周期，结合了前两章中学到的数据湖和数据仓库方法的优点。本章末尾，我们将描述如何向湖仓架构演进。

需要独特架构

数据湖和数据仓库（Data Warehouse, DWH）应运而生，以满足不同用户的需求。一个同时拥有这两种类型用户的组织面临一个不那么吸引人的选择。

用户角色

正如您在之前的章节中所学到的，数据湖和数据仓库之间一些关键差异与能够摄取的数据类型及将未处理（原始）数据落入通用位置的能力有关。因此，这两种范式的典型用户是不同的。

传统的数据仓库用户是商业智能（BI）分析师，更接近业务，专注于从数据中提取洞察。数据通常由 ETL 工具根据数据分析师的要求准备。这些用户通常使用数据来回答问题。他们通常精通 SQL。

数据湖的用户除了分析师外，还包括数据工程师和数据科学家。他们更接近原始数据，拥有探索和挖掘数据的工具和能力。他们不仅仅是将数据转换为业务可访问的形式（即可传输到数据仓库的数据），还会对数据进行实验，并用于训练机器学习模型和进行人工智能处理。这些用户不仅仅在数据中找到答案，还能找到对业务相关的问题，并准备数据使其对其他用户有用。他们通常精通 Python、Java 或 Scala 等编程语言。

反模式：断开的系统

由于这些不同的需求，我们经常看到不同的 IT 部门或团队管理数据仓库和数据湖。然而，这种分裂式方法有一个机会成本：组织将资源花费在运营方面，而不是专注于业务洞察。因此，他们无法将资源分配到专注于关键业务驱动因素或允许他们获得竞争优势的挑战上。

另外，维护两个分离的系统，它们都有提供从数据中获取可操作洞见的相同最终目标，可能会导致数据质量和一致性问题。从一个系统转换数据以便与另一个系统中的数据一起使用所需的额外努力可能完全阻止最终用户。这也可能导致整个企业存在数据水坑，即存储在个人机器上的数据集，既造成安全风险又浪费数据效率。

反模式：重复数据

为什么不简单地通过平台团队同步连接这两个系统？你可能最终会得到如 Figue 7-1 所示的架构，数据湖和数据仓库共存，以支持自助式分析和 ML 环境。

请注意，在此架构中，由平台集中管理的数据就是驻留在数据湖中的数据。所有其他数据（例如数据仓库、BI/报告工具、笔记本等）可以被视为原始数据的重复/转换版本，一方面有助于提高性能和便于分析（例如物化视图），但正如前几章所见，这也会带来许多缺点，因为它导致数据孤立现象。

图 7-1. 数据湖与数据仓库共存

让我们来看看数据旅程的主要构建模块：

1. 来自各种来源的数据（批处理和/或流式）被收集并转换/整理/准备（甚至实时处理），以便存储在数据湖中，数据会经过不同的阶段（铜、银和金）。从一开始，数据就会经历安全性、数据质量和数据治理检查。

2. 现在数据可以通过分析引擎解决方案（例如 Spark）进行处理，与 SQL 客户端、批量报告和笔记本交互。

3. 同时，数据可以并行转换并纳入数据仓库中的业务特定段，即数据集市，以处理 BI 工作负载。维护数据集市是一项复杂且昂贵的活动，因为它需要大量的 ETL 工程，并且保持所有必要的数据更新是具有挑战性的。而且，这必须是一个持续不断的过程。此外，所有数据治理活动必须在数据仓库中重复执行。

4. 数据仓库驱动 BI 工具和 SQL 客户端，但有时无法提供最终用户要求的充分性能水平，因此人们倾向于下载数据，创建本地副本并进行处理。

5. ML 解决方案（例如 scikit-learn、TensorFlow、Keras），通常通过笔记本处理，可以利用来自数据湖的数据，同时可以与数据仓库和分析引擎连接。

这样的架构通常包括一系列缺点：

数据的扩散

数据以各种形式存在，甚至可能在平台边界之外（即本地笔记本电脑），这可能会引起安全合规风险，数据新鲜度问题或数据版本问题。

时间到市场放缓

组织可能需要花费多达两周的时间来实施对管理报告的较小更改，因为他们必须首先请求数据工程师修改 ETL 以访问完成任务所需的数据。

数据大小的限制

用户可能无法访问他们进行分析所需的所有数据，因为例如，数据仓库中的数据集市可能仅包含由于性能需求而不全面的信息子集。

基础设施和运营成本

由于需要实施的 ETL 的复杂性，这些可能会增加。

拥有重复/转换的数据是不良实践，您应该尽可能将其最小化。理想情况下，您将消除重复数据和自管理数据，以便将所有数据置于平台管理模式中，所有参与者均可进行分析（即在图 7-1 中所示的架构图的右侧）。

到此时，您可能会问自己为什么组织要利用这种架构。这个原因非常明显：因为直到 2018 年，这是为了给许多不同的用户提供满足其需求的所有解决方案的唯一途径。

技术不断发展，特别是得益于云的出现，已经开发出新的解决方案，以提供更好的数据处理可能性。让我们看看如何改进这种组合架构。

融合架构

到此时，显而易见，数据湖与数据仓库的完全融合可以帮助最终用户充分利用其平台，从而充分利用其数据。但是，这种最终状态的架构是什么，以及达到这种状态的路径是什么？

两种形式

汇合湖架构的关键因素在于数据仓库（DWH）和数据湖共享共同存储。两种不同的计算引擎——SQL 引擎（用于数据仓库用例）和分布式编程引擎（用于数据湖用例）——读取和处理数据而无需移动数据。

此共同存储可以采用两种形式之一：

• 数据存储在云存储中以开源格式（Parquet，Avro 等），您可以利用 Spark 来处理它。同时，您可以使用 Spark SQL 提供交互式查询功能（Databricks 解决方案）。此外，数据仓库技术（例如 BigQuery，Athena，DuckDB，Snowflake 等）可以支持您直接在数据集上运行 SQL，无需任何数据复制或移动。您可以结合使用开源格式和 Delta Lake 或 Apache Iceberg 这样的技术来提升底层性能。

• 或者，通用存储可以是高度优化的 DWH 格式（例如 BigQuery、Snowflake 等内置格式），在这些 DWH 上，您当然可以原生地利用 SQL。此外，这些 DWH 支持直接在原生数据上使用诸如 Spark 之类的计算引擎。

这两者都是妥协。支持其他类型的工作负载并不意味着其性能相等。在 SQL 工作负载上，数据湖比数据仓库更慢/更昂贵。而在 Spark 和 ML 工作负载上，数据仓库比数据湖更慢/更昂贵。

根据用户技能选择

我们建议根据主要用户类型进行选择。在云存储上运行 SQL 引擎（第一种选择）会失去许多使 DWH 互动并适合即席查询的优化。运行 SQL 的数据湖（第二种选择）会失去使数据湖如此灵活的无模式数据处理能力。因此，请根据要很好地支持的用户类型和工作负载以及要以折衷方式支持的用户类型选择混合架构的形式。

在非常高的层面上，第一种选择适合熟练的程序员用户。如果你的大多数用户是那些在代码中进行大量数据处理（例如编写 ETL 管道和训练 ML 模型）的程序员，那么建立一个以数据湖（即云存储）为存储的湖屋是最好的选择。数据湖的主要优势在于它允许程序员进行灵活的数据处理。第二种选择适合希望与数据交互以从中获取洞察的用户。如果你的大多数用户是分析师而不是程序员，也就是说他们可以编写 SQL 或使用类似 Tableau、Power BI 或 Looker 这样的仪表板工具来生成 SQL，那么建立一个以 DWH 作为存储的湖屋是最好的选择。数据仓库的主要优势在于它允许商业用户进行自助式、即席查询。

完成评估标准

到目前为止，我们只是初步尝试确定您组织的正确方法。其他因素包括要摄入的数据量、是否需要流处理、数据中有多少是结构化或半结构化的，以及您是否在需要严格数据治理的受监管行业工作。

您应该列出在第五章和第六章讨论的数据湖和 DWH 方法的所有特性，并制作一个评估矩阵，为每个元素分配从 0 到 5 的分数（0 表示不重要，5 表示必须）。这将帮助您更全面地理解您的需求，并为您的湖屋方案做出正确选择。

现在，您对实施湖屋的不同选择有了更好的理解，让我们更近距离地了解这两个选项，以更好地理解它们在幕后的工作原理。

云存储上的湖仓

计算与存储的分离为数据湖与 DWH 的融合提供了理想的环境。云服务提供商能够通过将计算带到存储中为交互式查询启用分布式应用程序。这允许云服务提供商独立地为组织的作业分配存储和计算资源，这在本地环境中很难做到，因为机器需要提前数月采购。数据量和分析所需的计算能够从热池的计算集群动态扩展。当存储与计算解耦时，您可以将其用于许多不同的用例。曾经作为结构化数据文件型数据湖的同一存储现在可以作为 DWH 的存储和数据。这种关键的融合使您可以仅存储一次数据，利用视图为每个特定用例准备数据。

让我们来看看这种架构的基础要素，如何达到这个目标，以及为什么这是一种能够为未来需求做好准备的东西。

参考架构

我们利用云存储（如 AWS S3、Google Cloud Storage 或 Azure Blob Storage）同时为 Spark 集群使用的数据和为 BI 报告服务的 DWH。这使得数据湖团队花费多年完善的 Spark 代码可以在连接到始终可用存储的短暂计算集群上运行。它允许计算移到数据上，而不是数据必须在本地磁盘之间进行洗牌（如使用 HDFS 时）。云存储的高吞吐量提升了速度和性能。Databricks 和超大规模云服务提供商都提供 Spark 集群作为托管服务，进一步抽象化了基础设施的管理要求。

数据湖与 DWH（见图 7-2）的融合是为了简化和统一数据的摄取与存储，并利用适合特定问题的正确计算框架。对于结构化和半结构化数据，使用 CDC 工具将所有数据流入表格，用户可以使用简单的 SQL 转换数据，并构建逻辑视图以按照业务用例查询信息。由于视图在这种模式中被广泛利用，可以进行列消除、分区和逻辑以优化查询速度，同时保持流入表格的数据的历史分类帐。

图 7-2. 数据湖仓库参考架构 — 云存储方法

相反，通过批处理管道摄取的数据可以使用类似的方法，所有数据都写入表格，并使用 SQL 创建具有每条记录最新版本的视图。与流数据类似，原始表中维护历史账本，允许数据科学家使用所有数据构建和测试 ML 模型。在这种架构中，用户可以利用定期查询或基于事件的 Lambda 架构进行数据摄入。

与 图 7-1 中具有两个不同引擎（即分析引擎和内部 DWH SQL 引擎）的架构相比，图 7-2 中的参考架构具有单一的分析引擎，可以访问数据湖和数据仓库数据。这一点很重要，因为它可以实现更流畅高效的数据分析过程。

数据湖仓库解决方案，如 Dremio 和 Databricks，主要目标是在数据湖存储上直接支持高性能数据处理、分析和商业智能。它们通常提供语义层，允许您抽象底层数据，并向分析引擎提供数据视图，实现快速查询处理，无需实现数据集市。

项目的 生产/黄金 层（参见 第 5 章）可以是经过管理和专门构建的业务驱动视图或物化表格。底层逻辑和存储为终端用户和应用程序提供访问，允许您在 Hadoop、Spark、分析和 ML 上使用融合数据平台。

现在，数据存储在数据仓库（DWH）内部还是自由浮动的云存储桶中已不再重要。在幕后，它是相似的分布式存储架构，但数据结构不同。例如，数据湖将数据从 HDFS 移动到集群外的同一对象存储中。这与云环境数据仓库（EDW）作为存储系统骨干的使用方式相同。因此，数据可以在一个地方轻松访问和管理，同时由数据湖和数据仓库架构管理。因此，组织现在可以应用数据湖内数据和数据仓库访问的治理规则。由此，您不仅可以通过将数据放入中央存储库来打破信息孤岛，还可以通过使处理和查询引擎能够移动到数据所在的任何位置来实现。如 图 7-3 所述。这导致了数据仓库和数据湖的融合，使它们能够使用相同的元数据存储和治理，并使数据工程师、数据科学家和数据分析师能够共同协作，而不是在信息孤岛系统中。

数据工程师、数据科学家甚至业务用户都能够在可能拥有的任何数据类型上执行自服务查询，利用一个单一的访问点。甚至在开发方面，工作也将更容易，因为只需与一个系统互动，而不是众多不同的工具。这种方法的另一个优点是通过消除自我管理数据副本来加强安全和治理的集中化。

图 7-3. DWH、数据湖和基于存储的数据湖仓库方法

迁移

从图 7-1 中的架构到图 7-2 中的架构是一个迭代过程，保留了数据湖但迁移了数据仓库。首先引入一个连接到数据湖存储的单一分析引擎，来处理所有数据处理工作，如图 7-4 所示。然后，通过各种子步骤逐步迁移 DWH SQL 引擎，遵循第四章中描述的过程。

由于这个过程可能需要多次重复，因此首先要识别一个快速获胜的用例（如第四章中所述），这可以展示新解决方案的好处，以在组织内部形成共识。从那里开始，将可能继续扩展新解决方案的足迹，直到它成为整个平台的“事实上的”分析引擎。一个非常好的开始通常是交互式查询的数据探索世界：用户可以通过新引擎与数据湖和 DWH 跨越各种数据进行数据分析交互。他们可以直接使用新工具进行查询，也可以通过与 BI 和报告解决方案集成来执行查询。一旦变革的好处变得具体化，旧的 DWH 引擎就可以逐步停用以节省成本、减少复杂性，并且限制因离线数据加工而需下载数据的需求，因为根据组织的数据治理规则，用户现在将有权访问公司的所有数据。当然，新的工作负载应该只通过利用新的分析引擎来实现。

图 7-4. 数据湖仓库之旅——中央分析引擎

未来证明

一旦完全部署，与数据湖和数据仓库（仅限策划的数据）中的数据集的交互将是双向的：这意味着分析引擎能够直接在通常以开放格式如 Apache Parquet 或 Apache Avro 存储数据的底层存储系统上读取和写入。这是一个巨大的好处，因为底层技术可以被视为跨不同类型存储系统的一致和共同媒介。分析引擎将足够灵活，可以采用类似数据湖模式的按需模式读取（schema-on-read）或像基于 SQL 的更结构化的方法。采用湖仓架构时的另一个重要好处是易于流式数据采纳。

正如你将在下一章看到的，对数据的实时访问对于各种类型的业务越来越重要，而你能够将流数据像处理标准存储数据一样对待，这无疑能带来额外的价值。事实上，在这种架构中，流数据管道能够实时读写数据，知道底层技术（例如 Apache Iceberg、Apache Hudi 或 Delta Lake，请参考“Apache Iceberg、Apache Hudi 和 Delta Lake 的数据湖演变”）能确保完整的 ACID 事务，在系统内带来一致性，并且始终处理最新和最新的数据。你可以在 EMR、Dataproc 等平台上以专有（例如 Databricks）或开源方式使用这些技术。选择哪种适合你的组织的最终决定取决于你。要考虑的关键因素是灵活性、维护和支持。

SQL-First Lakehouse

SQL-First 湖仓解决方案的主要目标是在数据仓库存储上直接使用 Spark 实现高性能分析和 BI，同时支持灵活的数据处理。这种架构的优势在于业务用户可以进行编排和机器学习。

让我们来检视这种架构的基本要素，如何实现它，以及为什么将来它对你会有益。

参考架构

当将数据仓库作为数据湖使用时，需要确保数据仓库解决方案不仅能处理表格上的标准 SQL 查询，还能与基于 Spark 的环境、ML 功能和流处理功能进行本地集成。像 BigQuery、Athena、Synapse 和 Snowflake 这样的现代数据仓库在不同程度上支持这些功能，这些功能在您阅读本文时肯定已经得到了改进。在图 7-5 中，您可以看到一个参考架构，其中数据仓库充当平台的中央分析引擎点。从图中可以看出，数据从原始来源（以各种形式和速度）流经数据湖和本地数据仓库存储。从这里，您可以识别出四个主要的存储区域：

• 数据湖存储与前一节中所见相同

• 数据仓库存储分为三个维度：

  原始

  来自各种来源（批处理或流处理）的原始数据。

  增强的

  具有第一层转换的原始数据

  精心策划的

  准备进行最终转换的增强数据

Spark（ETL）或 SQL（ELT）可以执行所有的转换。

图 7-5. 数据湖仓库—SQL 优先方法

在构建数据湖仓库的这种方法中，使用 SQL 是处理和转换数据的首选方法。SQL 优先方法利用数据仓库的高度优化的交互式查询能力来降低成本，并将数据驱动的决策扩展给业务用户。

当您需要处理更高级的数据处理时，您可能可以利用像 Spark 这样的结构化编程语言。特别是在处理 ML 算法时，无论是结构化数据（例如提升树回归/分类）还是非结构化数据（例如 NLP），这一点尤为明显。这是因为这些操作在 SQL 中实现起来不够灵活（虽然不灵活，但并非不可能：BigQuery 和 Redshift SQL 在撰写本文时已经具备了一些 ML 功能，其他数据仓库很快也会支持）。利用 Spark 还可以避免重新编写可能已在 Spark 中编写的遗留数据处理作业。

现代数据仓库解决方案具备直接从其引擎执行 Python、Spark 甚至无服务器函数的能力，而且最重要的是，无需将数据移动或复制到数据存储之外。例如，BigQuery 通过提供在 Spark 中编写存储过程、在即席 Serverless Spark 环境中执行这些过程，并在 SQL 语句中调用它们的能力来实现这一点。Snowflake 提供 Snowpark，一个内置的 Python 引擎，能够运行 Spark（及其他编程语言）。Athena 通过使用 Parquet 等标准格式文件在管理的 Hadoop 环境（如 EMR）中操作，从而实现了这一点。此外，数据湖技术（如 Databricks）通过优化的批量 API（如 BigQuery Storage API）直接读取和写入本地仓库存储。

数据湖仓库范式的关键优势之一是，它促使供应商（以及整个行业）开发越来越强大的数据仓库，使多种复杂解决方案对广泛用户群体变得易于使用。这在机器学习领域尤为明显。业务用户可以利用标准 SQL 代码训练和部署机器学习模型，并可以利用开源解决方案（如 dbt）轻松自动化和生产化数据准备。如今，很常见看到例如能够独立预测客户需求并实现高精度的商业分析师，以便有效进行库存管理或根据历史数据预测最佳价格。

尽管 SQL 对机器学习的支持很棒，但与 ML 技术相关的大多数任务都掌握在更倾向于利用他们更熟悉的 Python 框架的数据工程师和数据科学家手中。特别是在处理非结构化数据上开发深度学习模型时，您需要利用开源语言处理海量数据集，以训练必须提供给最终用户的模型。这就是为什么各种数据源之间的本地集成发挥着关键作用：利用 Spark 支持的能力是给用户提供高自由度的范式的一个关键特性。

随着机器学习模型开发的普及，平台还必须处理另一类运营：机器学习运维（MLOps）。在 MLOps 中，用户希望通过与软件开发相同的方法（即 DevOps）来跟踪数据版本、数据血缘（特别是出于审计目的）和模型更新。诸如 Databricks MLflow、Google Vertex AI 或 Amazon SageMaker 等解决方案与现代数据仓库天然连接，使最终用户在处理机器学习模型生命周期时有统一的体验。

迁移

与基于云存储的湖仓库方法类似，向 SQL 优先的湖仓库转型是一个迭代过程，需要多个步骤才能完全投入运行，如图 7-6 所示。第一步是直接将数据摄入到 DWH 中：数据源不仅要直接连接到数据湖，尤其是要连接到三种 DWH 存储（即原始、丰富和策划）。一旦数据完全被批处理和流式处理摄入到中央数据存储库中，就是时候剔除外部分析引擎，将 DWH 的 SQL 引擎提升为主要引擎。在这里，关键是注意如何将数据湖的工作负载转移到 DWH 中，利用内置的编程语言模块（如 Python 或 Spark 引擎/连接器）直接在原生存储格式上操作。最后一个迭代过程中，初始时仍在 DWH 外部处理的 ML 工作负载将被内部化处理。

图 7-6. 走向数据湖仓库——以 SQL 为先的方法

在迁移的各个阶段中，遵循 SQL 优先的方法，组织将发现大量数据管道需要用 SQL 编写。

在这种架构中，通过 SQL 实现数据处理更为高效（尽管 Spark 中的 ETL 仍然是一种可能性）。这通常需要组织内一种新的技能类型，称为分析工程。您可能很容易在组织内找到具备分析工程技能的员工（参考“数据分析驱动组织”），因为 SQL 是一种广泛使用的语言（比 Spark 或其他编程语言更为广泛），可以迅速学习。事实上，这是民主化的一个优点，因为采用这种范式将使大量员工更容易访问数据。

数据分析工程师将负责大部分数据丰富和策划工作，并且他们能够运用他们的领域知识，只需具备 SQL 技能。不同类型的数据集（原始数据、丰富数据和策划数据）可能会被不同类型的用户使用。总体而言，大多数最终用户、分析团队和应用程序将利用策划数据，而数据工程师和数据科学家可能更倾向于访问原始数据或数据湖和丰富数据。

在这种情况下，重要的是注意到流式处理和机器学习能力包含在分析引擎中：这意味着它们对每个人都是本地可用的，即使是那些在使用 TensorFlow、PyTorch、Keras 或 scikit-learn 编写代码方面不那么高级的人也是如此。这是在促进数据民主化和工具访问方面取得的重大成就，使得组织内的员工能够更多地利用他们的数据。最后，需要注意的是数据治理以联邦和横向的方式进行处理，创建了一个统一和集中的管理、监控和治理数据的场所，使其能够被多种用户和工具访问。

未来保障

一旦迁移完成，并且组织已经根据图 7-6 中的架构进行了开发，大部分交互将基于 SQL。在 SQL 困难或可用现成库的用例中，可以利用其他编程语言，使非 SQL 选项更具吸引力。

采用 SQL 优先湖仓架构的好处非常大，因为它提供了一个统一的数据存储位置，并通过一个广泛使用的标准编程语言（SQL）——由许多商业用户使用的工具支持——来民主化访问数据。与基于云存储的数据湖仓相比，其主要优势在于能够让更广泛的用户接近数据并允许他们创建创新解决方案（即机器学习）——能够使用数据的人越多（以受控的方式），你的组织就会看到更多创新。

融合的好处

如果你是创业公司或者幸运地进行绿地开发，根据你的使用案例和技能集，可以选择纯数据湖或纯数据仓库（见第三章）。对于其他所有人，我们建议采用湖仓架构。无论你选择湖仓存储还是 SQL 优先湖仓，选择湖仓架构都带来以下好处：

上市时间

你可以直接摄取和使用数据，无论是来自批处理还是实时数据源。不再使用复杂的 ETL 管道处理数据，数据直接“分阶段”存储在消息总线或对象存储中，然后在融合的数据仓库/数据湖中进行转换，使用户能够在收到数据时立即行动。

减少风险

你可以继续利用现有的工具和应用程序而无需重写它们。这降低了变更带来的风险和成本。

预测分析

从传统的数据集市和数据挖掘的观点转向使用新鲜数据进行实时决策，增加了业务价值。这只有因为围绕数据仓库的治理和严格要求已经降低，减少了进入门槛，才变得可能。

数据共享

收敛环境现在是所有用户类型（即数据分析师、数据工程师和数据科学家）的一站式购物平台。他们可以在需要时访问同一管理环境，获取不同数据阶段的访问权限。同时，不同角色可以通过不同层次访问相同数据，这由平台范围内的访问权限管理。这不仅增加了数据治理，还简化了数据生态系统中的访问管理和审计。

ACID 事务

在典型的数据仓库中，保持数据完整性，多个用户读写数据时看到的是一致的数据副本。虽然 ACID 是大多数数据库的关键特性，但传统上在基于传统 HDFS 的数据湖中提供相同的保证相当困难。有诸如 Delta Lake 和 Apache Iceberg 之类的方案试图保持 ACID 语义（参见“Apache Iceberg、Apache Hudi 和 Delta Lake 的数据湖演进”）。它们存储事务日志，旨在跟踪对数据源的所有提交。

多模态数据支持

半结构化和结构化数据是数据仓库和数据湖的关键区别。半结构化数据具有一些组织属性，如语义标签或元数据，使其更容易组织，但数据仍不符合严格的模式。在收敛的世界中，通过扩展的半结构化数据支持可以容纳这些数据。另一方面，对于非结构化的用例，仍然需要数据湖，除了边缘情况。

统一环境

传统上，不同的工具和环境通常由 ETL 协调管理数据捕获、摄入、存储、处理和服务。此外，如 Spark、Storm、Beam 等处理框架提供内置 ETL 模板，使组织能够构建 ETL 管道。然而，通过功能强大的云数据仓库和集成云工具，现在可以通过单一环境处理所有这些管道。ELT 执行大部分传统 ETL 任务，如数据清理、去重、连接和增强。这在 DWH 中的数据湖实施的不同阶段变得可能。此外，借助核心数据仓库的支持，您可以通过统一环境访问存储过程、脚本和物化视图等概念。

架构和治理

实际上，业务需求和挑战随时间而演变。因此，相关数据会随之改变和累积，无论是通过适应新数据还是引入新维度。随着数据的变化，应用数据质量规则变得更具挑战性，并需要模式强制执行和演进。此外，随着新数据源的添加，PII 数据治理变得更加重要。组织需要一个数据治理解决方案，能够全面了解其数据环境。此外，对于不同目的和角色，识别和掩码 PII 数据至关重要。

流处理分析

实时分析能够实现即时响应，存在特定的用例需要运行极低延迟的异常检测应用程序。换言之，业务需求要求在数据即时到达时立即采取行动。处理此类数据或应用程序需要在数据仓库之外完成转换。

拥有一个管理单一系统简化了企业数据基础设施，并允许用户更高效地工作。

总结

在本章中，我们专注于描述如何在一种全新的混合架构——湖屋中混合数据湖和数据仓库技术。我们介绍了两种最常见的架构以及如何实现这一目标。主要收获如下：

• 在设计其数据平台时，组织通常遵循两种主要方法：数据湖或数据仓库范式。

• 这两种方法各有利弊，但有一个新的选择：湖屋形式的融合，使您能够兼顾两者的优点。

• 在选择湖屋时，有两种可能的方法。根据开发人员的主要技能集选择其中一种。

• 一种湖屋的方法是将数据湖和数据仓库合并，使用云存储中的相同数据。Spark 作业将从云中读取，而不再使用 HDFS。使用基于 Spark 的 SQL 引擎。随着时间的推移，这将导致数据仓库引擎的停用。

• 第二个湖屋选项是将数据湖工作负载移至数据仓库，并使用内置的 Python 引擎或 Spark 连接器直接操作原生存储格式。

• 湖屋方法有几个好处：缩短上市时间，轻松实施预测分析并打破孤立和 ETL 管道，模式和治理以及流处理分析仅是其中几个。

目前，我们已经涵盖了主干数据平台架构（数据湖、数据仓库和数据湖屋）。在接下来的两章中，您将学习如何将流处理和边缘/混合要求纳入此架构。

第八章：流式架构

在本章中，您将了解到为什么行业趋势不可逆转地从批处理向流处理发展。我们将讨论不同的流式架构及其选择方式。我们还将深入探讨两种架构——微批处理和流水线——以及如何在这两种架构中支持实时的即席查询。最后，有时进行流处理的原因是在特定事件发生时自动采取某些行动，我们将讨论如何设计这样的自动化系统。

流处理的价值

从数字原住民到传统公司，涵盖多个行业的企业意识到做出更快决策的价值日益增加。例如，考虑企业 A，需要三天才能批准车辆贷款。另一方面，企业 B 可以在几分钟内批准或拒绝贷款。这种增加的便利性将使企业 B 具有竞争优势。

比更快的决策更好的是能够在上下文中做出决策。能够在事件进行时做出决策（见图 8-1）比稍后几分钟做出决策更有价值。例如，如果您能够在持卡人使用欺诈信用卡进行支付时检测到并拒绝该交易，您就可以避免昂贵的追索流程。

图 8-1. 决策的价值随时间的推移而下降；流处理允许组织实时做出决策。

行业应用案例

无论是欺诈检测、交易结算、智能设备还是在线游戏，一个接一个的行业已经开始采用流处理。

在医疗保健领域，我们看到流处理被用于实时患者监测，在摔倒或自伤时发出警报，利用物联网医疗设备提供个性化护理，以及优化医院的药品和供应品库存。

在金融服务领域，我们看到流处理被用于检测和防止欺诈、预测和分析风险、识别违反合规法规的交易，并向客户提供个性化的优惠。

在零售领域，我们看到流处理被用于个性化营销网站，提供跨多个渠道（网站、移动应用、实体店）的实时库存信息，处理订单履行问题，动态定价，产品推荐以及全渠道客户可见性。

在媒体和娱乐业中，我们看到流媒体被用于生成个性化内容，传递定向广告，减少客户流失，以及防止订阅者欺诈行为。在电信行业中，我们看到类似的用例围绕客户流失和订阅者欺诈。此外，流媒体还用于提高网络可靠性和优化网络容量规划。

流使用案例

将流视为对无界数据集进行数据处理。技术上，流处理的挑战是双重的。一是数据集是无限的，永远不会完成。因此，所有聚合（例如极值）只能在时间窗口内定义。另一个挑战是数据在运动中并且存储在临时存储中。这使得应用传统编程技术和概念（如文件句柄）来读取和处理数据变得困难。由于这种复杂性，将流使用案例分为四种复杂度和价值递增的类别有巨大好处：

1. 流摄入

当您只关心跟上数据流并将其落入持久存储时。

2. 实时仪表板

当您希望在数据到达时可视化数据时非常有用。您可能还对数据的时间窗口聚合的统计数据和图表感兴趣。

3. 流分析

当您希望在数据到达时对数据进行计算时。通常情况下，这是为了向人工操作员报警超过阈值或异常模式。

4. 持续智能

自动化流分析，以便无需任何人工干预即可采取行动。

在接下来的章节中，我们将查看每个使用案例的架构。您将看到架构非常模块化，您可以建立简单的系统，并在需要时添加复杂性。不必建立最终、最复杂的自主系统来从流处理中获得价值。但是，这假设您在像 Apache Beam 这样的框架中进行数据处理，这将允许您无缝地从批处理转换为流处理。尽管 Beam 由 Google 创建为其托管的 Cloud Dataflow 服务的 API，但 Apache Flink 和 Apache Spark 都支持 Beam。因此，您可以在其他超级托管商上使用托管的 Flink 和 Spark 实现来运行 Beam 管道。

这些类别相互构建，因此第一个类别对所有四种用例都至关重要。为了更快地做出决策，您需要几乎实时地摄入数据，即事件发生时。这称为流摄入，我们将在下面详细介绍。

流摄入

流摄入可以通过两种方式进行：

• 您可以聚合事件并仅将聚合数据（例如小时平均值）写入持久存储。这称为流式 ETL，因为聚合是转换（ETL 中的T），位于抽取和加载到持久存储之间。

• 或者，您可以直接将数据摄入（加载）到数据湖或数据仓库，并期望客户在分析时转换数据。这称为流式 ELT。

让我们在以下小节中详细看看这两种方法。

流式 ETL

如果您的目标是向业务提供更及时的数据，则流式摄入就足够了。首先，您需要关注数据在云中摄入的位置，因为这非常重要。您需要将数据存储在可以访问以进行处理或查询的位置。对于查询，确保结果反映最新数据非常重要。

因此，要实现实时洞察的目标，数据摄入必须发生在允许实时摄入和查询的系统中。现代数据仓库（例如 Google BigQuery、AWS Redshift 和 Snowflake）具有此功能。因此，通常情况下，您会进行流式 ETL 进入这样的数据仓库，如 图 8-2 中所述。

图 8-2. 日志数据的流式 ETL 有两种选项：微批处理（用虚线表示）或流水线（用实线表示）

因此，流式 ETL 的目标通常是将数据落入数据仓库。多个应用程序写入的日志数据由本地代理读取，负责使日志数据在实时监控和查询中可用。您可以通过重新定义数据类型和使用适当的本地代理，将相同的架构应用于其他类型的实时数据，无论是来自物联网设备还是在线游戏。

本地代理可以通过以下两种方式之一实现实时查询数据的可用性（见 图 8-2）：

微批处理

例如，过去五分钟的数据被写入到云存储的文件中。云存储中出现新文件会触发加载功能（如 Google Cloud Functions、Google Cloud Run、AWS Lambda、Azure Functions 等）。该功能可以处理数据，然后将文件加载到最终目标中。微批处理涉及一些延迟。

流水线

本地代理可以针对每个日志事件发布一个事件到消息队列（例如 Kafka）或主题（例如 Cloud Pub/Sub）。这些事件被推送到流水线（例如 AWS Glue 或 Google Cloud Dataflow），处理这些事件并将其插入到最终目标中。这使得事件可以立即用于查询。

加载函数或流水线的角色是处理数据，使其对下游用户和应用程序更加可用。通常，您会利用数据处理来：

• 将事件数据转换为数据仓库表格所需的模式

• 过滤事件记录，仅保留业务部门操作数据仓库的特定数据

• 插值或以其他方式填充事件中的缺失值（例如，您将使用最近有效的值）

• 连接跨时间的事件（例如，您将利用身份解析方法将事件连接成用户会话，甚至跨会话连接）

• 将事件聚合成更易消费的块，例如，编写时间平均值（例如，过去一分钟的总页面访问次数，而不是每次页面访问）或每个会话值（例如，一个记录指出会话中单击的按钮，而不是单独的按钮单击事件）

• 用其他来源丰富数据（例如，货币转换）

• 掩码、加密或以其他方式保护敏感字段

如果不需要执行上述任何活动，并且加载功能只是一个简单的穿越，请考虑在下一节中是否可以使用流式 ELT 方法。

在利用微批处理方法时，了解延迟来源是很有帮助的。在我们的例子中，加载到 DWH 的数据可能会有五分钟的延迟。但这通常不是大问题。如果 5 分钟的延迟是不可接受的，您可以降低到 30 秒。真正的问题是 DWH 加载作业排队，因此它们可能不会立即发生。检查您的 DWH 的 SLA，了解可能的延迟是什么。通常，这种加载延迟是使微批处理在许多用例中不可接受的原因。但是，如果批次包含例如每日数据，并且加载的小时延迟是可接受的，则这是一个有效的架构。

微批处理方法通常比流水线方法便宜。一些 DWH（特别是 Google BigQuery）具有加载数据免费的定价层。即使在像 Snowflake 这样既收费加载又收费插入的 DWH 中，插入的费用更高且需要更高的层级。此外，只有在函数运行时才需支付加载的计算成本。特别是如果您每天只加载一次数据，则微批处理的计算成本可能非常低。AWS Glue 和 Cloud Dataflow 的自动缩放在微批处理频率增加时也能够缩小差距。

我们已经介绍了前面提到的两种方法中的第一种。现在让我们继续讨论第二种：流式 ELT。

流式 ELT

以前学习的流式 ETL 方法假设你可以预测数据消费者需要进行哪种清理、聚合或增强操作。毕竟，在将原始数据写入 DWH 之前，你正在转换原始数据。这可能是一个有损的操作。随着数据消费者数量的增加，以及不可能预测不同消费者需要的转换类型，许多组织将他们的数据流水线从流式 ETL 转换为流式 ELT。如果转换需要业务特定的知识，并且最好由业务用户而不是程序员执行，流式 ELT 也比流式 ETL 更合适。

在流式 ELT 中（见图 8-3），本地代理直接加载或插入原始数据到 DWH 中。数据的消费者可以应用他们需要的任何转换。在某些情况下，你可以提供数据的逻辑或实现视图，以便于数据消费者使用。

图 8-3。流式 ELT 也可以作为微批次（虚线）或事件发生时（实线）来执行。

流式 ELT 的一个显著缺点是写入 DWH 的数据量可能很大——在许多 ELT 流水线中，转换步骤显著减少数据量，并仅向 DWH 写入聚合数据。因此，流式 ETL 与 ELT 的选择非常依赖于基于业务价值和云成本的决策。

令人费解的是，数据量越大，流式 ELT 的成本竞争优势越明显。随着数据量的增加，更频繁地处理数据变得更有意义。要了解原因，想象一下，一个企业根据其网站流量创建每日报告，需要两小时。现在假设网站流量增长了四倍。现在报告需要八小时才能创建完毕。如何回到两小时？幸运的是，这些问题都是可并行化的。因此，将作业扩展到四倍的机器数量。如果考虑一种使报告更及时的方法呢？

• 每天四次计算六小时数据的统计信息。

• 将这六个小时报告汇总成每日报告。

• 现在你可以每天四次更新你的“每日”报告了。

• 报告中的数据现在只有六小时的历史了。

当然，这就是微批处理的概念。这两种方法的计算成本几乎相同。然而，第二种方法降低了延迟，增加了频率，分散了负载，并更好地处理了突发情况。此外，组织得到了更及时、不陈旧的报告，这几乎没有额外成本，但能为业务带来巨大的好处。数据量越大，从每六小时报告到每小时更新，再到分钟级更新，甚至实时更新，就越合理。一旦需要向多个消费者提供几乎实时的更新，流式 ELT 就成为一个非常有吸引力的选择。

流式插入

在图 8-2 和 8-3 中，我们假设需要一个本地代理来查看可用数据，并将数据加载或插入到持久存储中。其实，并不一定需要这个中介——如果 DWH 提供了流式 API，云原生应用可以绕过本地代理，使用云客户端库自行进行插入操作（见图 8-4）。

图 8-4. 在云原生应用中进行流式 ELT 可利用客户端库直接插入数据。

例如，在 BigQuery 中，流式插入涉及使用 REST API 调用，并可以在 Python 中完成。Snowpipe Streaming 在 Snowflake 中提供了这种功能，但在 Redshift 中，您必须使用 Kinesis 中的传递转换步骤。

一些消息系统（例如 Google Pub/Sub）还提供特定的订阅类型，可以将事件加载到数据仓库中，以便应用程序可以简单地将事件发布到消息主题或队列，并使事件实时显示在数据仓库中。

边缘设备（IoT）的流式传输

在 图 8-2 中，我们假设流式 ETL 中的事件将从自定义本地代理发布到诸如 Kafka 等通用消息队列。

在物联网（IoT）的情况下，云服务提供商通常有更具针对性的解决方案（见 图 8-5）。Azure 提供了 IoT Devkit 用于边缘软件和 IoT Hub 用于远程云组件。在 AWS 上，本地代理将使用预构建的 AWS IoT Greengrass 组件，远程队列将由 AWS IoT Core 管理。在 Google 云平台上，边缘组件可能包括 Coral 设备和 TensorFlow Lite 软件，而远程云组件可能是 Clearblade IoT Core。

图 8-5. 用于从 IoT 设备边缘流式传输数据时，利用 IoT 特定功能。

您可以使用提供的边缘软件开发工具包（SDK）和设备进行本地处理、数据管理、ML 推理等。利用提供的远程云组件，您可以激活定制功能，如设备管理，并且可以透明地处理网络不稳定、设备重新启动等情况。

无论云服务提供商如何，边缘 SDK 都将支持标准协议，如 MQTT，以及专有协议。选择标准协议可确保您能够在不同云上部署软件，尤其是在边缘设备的情况下，通常需要支持其他云的设备或处理软件，因为涉及合作和收购。例如，在 AWS 上使用 Greengrass 时，可能考虑使用 MQTT 代理 Moquette 以确保可移植性。

流式汇聚

在 8-2 和 8-3 图中，我们假设需要将流数据导入数据仓库以支持交互式查询。但并非总是如此。有两个例外情况：非结构化数据和高吞吐流。

如果您正在流式传输视频，则可以忽略上述所有内容并使用专为视频设计的框架。在边缘上，您的视频摄像机将支持实时流传输协议，如实时流传输协议（RTSP）或 WebRTC。使用这些协议将实时视频传送到云端。在 Google Cloud 上，Cloud Video Intelligence 将从实时流传输协议转换为可解码的视频流，并将流写入云存储文件中。在 AWS 上，Kinesis Video Streams 与 AWS SageMaker 提供类似的集成，并将 ML 推断结果发布到 Kinesis Data Streams。类似地，Azure Video Indexer 允许您从视频中提取洞察信息。

DWH 是持久存储和交互式即席查询的通用解决方案。但是，DWH 对于高吞吐量和/或低延迟的情况并不是一个好的选择。DWH 支持的典型吞吐量约为每秒 1GB，并且典型的延迟约为几秒钟。如果您希望每秒流传输数 TB 数据或希望毫秒级延迟，则 DWH 不是一个好的选择。而是使用 Google Cloud 上的 Cloud Bigtable 或 AWS 上的 DynamoDB。当然，这些都是 NoSQL 数据库，因此您正在权衡 SQL 的便利性与实时摄取和查询的权衡。相反，如果您的规模或性能需求未达到这些水平，则不要选择 Bigtable 或 DynamoDB：SQL 解决方案将在基础设施和所需技能方面更加经济实惠。

如果立即查询不是问题，或者您的架构纯粹是数据湖而不是数据湖仓（参见第七章），则也可以将流式数据流式传输到云 Blob 存储文件中。例如，Apache Beam 可用于将非结构化或半结构化数据存储在 Google Cloud Storage 上。在这样做时，重要的是决定如何分片文件——流处理框架将在文件达到一定大小后自动分片文件，但这些基本上是基于时间戳的（因为记录正在流出），这可能不适合您的需求。

实时仪表盘

无论您是存储聚合数据还是将实时数据着陆到数据仓库（DWH），您可能希望为决策者提供在数据进入时可视化数据的能力。您可以通过实时仪表盘来实现这一点。

实时查询

仪表板工具定期查询 DWH 以确定着陆的事件，并更新其图形。此架构要求仪表板将查询推送到云 DWH（参见图 8-6）。换句话说，所有查询都是“实时的”，并反映 DWH 中的最新数据。

图 8-6. 仪表板定期使用 SQL 查询 DWH

早期的方法如数据立方体和数据集市——它们涉及将用于图形的 DWH 数据的子集或聚合物化——已不再必要。尽管像 Tableau 这样的仪表板工具具有创建和维护提取的功能，但最好直接查询 DWH live——现代云 DWH 可以处理。

如果您的数据仓库提供了面向仪表板的便利或性能特性（例如将数据集缓存在内存中、查询的时间限定缓存、优化以在数据未更改时返回先前的查询结果等），您应该启用它们。例如，在 Google BigQuery 中，启用 BI 引擎。在 AWS Redshift 中，使用密集计算节点，因为这些节点专为仪表板所需的较重计算而设计。

物化一些视图

最好不在仪表板工具中使用复杂的 SQL 查询代码。创建检索所需数据的视图，并通过用户定义的 SQL 函数在视图之间重用查询逻辑。

如果您发现某些视图经常被访问，请将视图转换为物化视图（参见图 8-7）。这样做可以在不增加额外治理负担的情况下提供仪表板维护的数据库提取的性能优势。

图 8-7. 为频繁请求的提取使用物化视图

但是不要过火：引用 Knuth 的话，过早优化仍然是许多问题的根源。最小化使用物化视图，并允许大多数查询实时进行。物化视图会增加存储成本，如果特定提取很少显示，则会增加许多不必要的开支。

流分析

在实施仪表板时，您可能需要超越仅仅显示数据。您可能需要显示基于自动提取的见解和预测的对决策者有用的警报。这被称为流分析。您可以通过事件基础或基于时间的时间表计算分析来确定是否需要警报。实时处理事件比较好，为此，您需要一个流水线。如果选择基于时间表进行处理，微批处理就足够了。

流分析在以下情况下很有用：

时间序列分析

用于跟踪资产、预测事件影响和进行预测性维护

点击流分析

用于实时提供优惠、创建动态网站和优化客户旅程

异常检测

用于预测设备故障、防止欺诈和监控系统健康

我们将在本节中分别讨论这些情况。这些情况的架构可以作为其他流式分析用例的模板，你可以像时间序列分析那样写入两个主题和仪表板，使用点击流分析中的回填管道，或使用异常检测中的多个时间窗口。

时间序列分析

流式分析最常见的应用是周期性验证数据值或计算基于时间的平均值。

例如，假设一个物理资产（如交付车辆）将其位置流式传输到云端，我们希望分析资产的位置，并在以下情况下发出警报：

• 该资产移动出某个预定的地理区域。

• 该资产的速度超过了它所在位置的某个预定限值。

此用例的架构如图 8-8 所示。

图 8-8. 时间序列分析架构

你可以通过 ETL 管道实时将位置数据加载到 DWH 中，该管道从事件流（Kafka，Pub/Sub 等）中推送新的位置信息。流式处理管道（使用 AWS Glue、Google Cloud Dataflow、Apache Flink 等技术实现）处理实时流，验证位置，并将警报写入一个特殊主题。然后，当有新的事件到达此主题时，会触发一个激活函数，负责通过电子邮件、短信等方式将警报发送给相关方。

流处理器能够对传入的事件流应用时间窗口，计算平均速度等统计数据。它还能够从数据库中获取静态值（如特定位置的限速）。因此，它还能够进行第二次计算并对其发出警报。

编写 编写警报消息时，最佳实践是将其写入警报主题和 EDW。为了让用户控制他们收到的警报，最好不要让流式处理管道直接发送电子邮件或短信。这样的职责分离还允许你建立仪表板，展示这些警报的频率，并允许用户探索这些警报，进而识别模式。

点击流分析

点击流由访问者在应用或网站内执行的事件序列（如按钮点击、页面浏览等）组成。为了收集这些数据，组织在其网站上安装了仪器，以便用户活动触发 Web 动作，进而最终进入 DWH。随着大量业务转移到在线，组织能够基于点击流洞察客户行为。

虽然可以为此类工具编写自定义 JavaScript 代码进行仪表化，并在自定义流式处理管道中收集和处理数据，但更常见的是使用预构建工具，如 Google Marketing Platform 或 Salesforce Marketing Cloud。Google Marketing Platform 包括 Google Tag Manager（用于仪表化您的网站）和 Google Analytics（收集此信息并提供一种将点击流数据导出到 Google BigQuery 的方式，从那里可以将其转移到任何其他 DWH）。您可以使用像 Fivetran 这样的公司的连接器，类似地将数据从 Salesforce Marketing Cloud 导出到所需的 DWH。还需检查您的 SaaS 软件是否提供将其内部数据与 DWH 同步的功能。例如，Salesforce 为 Snowflake 和 BigQuery 提供了这样的功能。

一旦数据位于 DWH 中，您可以使用 SQL 进行分析。点击流数据用于 A/B 测试、跟踪商品流行度变化和识别销售摩擦。您可以通过适当编写的 SQL 完成所有这些任务。但是，处理代码将处理以下情况：

• 用户从一个设备开始，然后在另一个设备上完成交易。自动会话跟踪可能不会捕获这种情况，除非客户在两台设备上都登录。总体而言，用户识别是一个挑战，因为只有少数用户会登录。其他机制（如 Cookie、设备 ID、IP 地址等）经常失败，并且如果有更多数据，可以进行改进。通过跨所有渠道使用所有可用数据将可能是同一用户的数据集合起来，称为身份拼接。存储包含一组唯一用户 ID 和相应属性的湖畔被称为客户数据平台（CDP）。

• 隐私合规性通常要求适当对收集的数据进行匿名化处理，并以不能识别个体行动的方式聚合用户数据。经常需要从用户填写的文本字段中删除信息。

• 自动代理（如蜘蛛搜索机器人）和寻找安全漏洞的恶意行为的活动。

这种处理在 SQL 中很难完成。因此，即使使用像 Segment 或 Bloomreach 这样的预构建 CDP，也通常需要构建后处理的“补充”管道来处理组织内特有的情况（见图 8-9）。这种流式处理管道可能能更好地完成身份拼接、隐私聚合和机器人检测等任务，超过预构建工具提供的更为通用的代码。同时，该管道可能会根据组织内的其他数据源（如关于客户、产品、价格、库存水平等的信息）来丰富点击流。正是这些补充后处理的数据，可以用于进一步的分析。

如果您使用点击流数据来构建个性化或推荐系统，则在客户访问网站时也必须采取行动。这将属于我们稍后在本章中讨论的连续智能用例。

图 8-9. 使用回填管道来丰富点击流数据，改进身份拼接、隐私削减和机器人检测

异常检测

异常检测涉及在数据到达时识别异常模式。在任何“正常”行为的数据丰富的情况下，但很难编写关于异常活动具体规则的情况下（因为恶意行为者不断改变攻击机制或环境易受变化），异常检测非常有用。异常检测用于检测定价错误的商品（某种商品的人气突然上升），过载设备，在线游戏中的机器人活动，安全威胁等。

许多组织使用基于签名的模式作为识别病毒和其他网络安全威胁的主要技术。在基于签名的模式中，系统利用过去检测到的病毒的存储库来对抗新的威胁。然而，使用这种技术很难检测到新的攻击，因为没有可用的模式或签名。当使用异常检测时，通常会对过去三天内的传入数据进行聚类（见图 8-10）。任何远离现有聚类的事件都被认为是可疑的。这允许环境进行适应（因为聚类仅在最近三天的数据上进行），并且允许您识别异常模式，只要它们不是已经过于普遍。

图 8-10. 异常检测涉及两个流式管道：一个用于计算滑动窗口内的聚类，另一个用于将传入事件与这些聚类进行比较

弹性流式处理

当摄取和处理流数据时，您会收到格式不正确的数据或者您不知道如何处理的意外数据值。

在批处理中，通常会简单地抛出异常，然后期望程序员找到逻辑错误，修复它，并重新运行批处理作业。然而，在流处理中，管道需要继续运行。同时，您也不希望简单地忽略错误。

因此，每个流式分析作业设置一个死信队列来存储无法处理的事件非常关键。您可以定期检查这些死信队列并（与批处理作业一样）修复逻辑错误。

一旦修复了逻辑错误，就必须在当前运行的流式处理流水线上更新，而不会丢失任何数据。像 Cloud Dataflow 这样的工具提供了在原地更新运行中的流水线或排空事件队列并无缝转移处理到新流水线的能力。

更新正在运行的流水线会保留正在进行的数据，并在新流水线内恢复处理。为此，它重用旧流水线的持久存储来更新流水线。因此，两个流式处理流水线必须满足某些兼容性要求。如果处于保持兼容性的情况下，应该遵循这种方法，因为可以实现一次精确处理语义。事件将被精确处理一次（即旧的或新的），并且聚合将是准确的。

如果流水线不兼容（也许是因为修复了 bug 改变了步骤之间传输的数据），下一个最佳方法是在启动新流水线之前排空现有流水线。现有作业停止从其输入源拉取数据，并完成所有正在进行和缓冲数据的处理，导致触发器发射开放窗口的内容，并将新事件发送到新的流水线。排空流水线对于确保至少一次处理语义至关重要——虽然不及一次精确处理好，但比简单取消运行中的流水线和丢弃数据要好。

通过 ML 实现持续智能

不需要有人在环路中进行决策。随着数据量的增长，通常会转向人类在环上的系统。在这种情况下，根据实时洞察、警报和预测自动执行操作。人类监督员可以覆盖否则会自动应用的操作，但系统设计为在没有任何人类干预的情况下自动运行。这被称为持续智能。

要使系统能够自动运行，您需要自动化以下操作：

• 在历史数据上训练 ML 模型，并根据需要在随后的数据上重新训练模型。

• 在事件到来时调用经过训练的 ML 模型。这称为推断。

• 根据 ML 模型的预测采取行动。

让我们看看每个步骤的一些考虑事项。

在流数据上训练模型

ML 模型是根据历史数据训练的。应该在多少数据上训练模型？这取决于手头的问题。一般的建议是，只在与投入生产后可能遇到的数据类似的数据上训练模型。此外，几年前的数据通常来自完全不同的背景，可能捕捉到今天不相关的趋势和关系。

因此，在对流数据进行 ML 模型训练时，您不太可能对整个历史存档进行训练。相反，您感兴趣的是在最近的数据上进行训练，“最近”是指具有与即将接收到的数据相同特征的数据。在这种情况下，“最近”可以是过去三天（如我们异常检测示例中显示的情况，见图 8-10）或在稳定环境中过去三年的数据。

窗口化训练

如果您经常进行训练，并且训练数据包含相对较小的时间段，您可以像在图 8-11 中一样使用滑动窗口流水线。在仅基于历史需求周期进行需求预测等时间序列外推时，这是非常常见的。

图 8-11. 在滑动时间窗口内训练事件

您需要的是：

• 使用流水线创建在时间窗口内的数据集。

• 在 Google Cloud Vertex AI、AWS SageMaker、Azure Machine Learning 等平台上的自动化训练流水线，以从何处获取训练数据为参数化。（训练流水线还将模型部署到端点，正如我们将在“流式 ML 推断”中讨论的那样。）

注意，“流水线”一词在这里指的是不同的内容。流式处理管道涉及处理动态数据，而训练管道包括 ML 操作（数据预处理、模型训练、模型评估、模型部署等）。我们将在第十一章详细讨论 ML 流水线。

定时训练

对于模型将有效一段较长时间（大约几天到几周）的情况，您可以使用定时作业启动训练，如图 8-12 中所述。训练作业将从 DWH 或其他持久存储中检索过去一个月的数据，例如。

图 8-12. 定时训练

您可以使用 Google Cloud Scheduler 在 Google Cloud 上安排 Vertex AI ML 训练流水线。在 AWS 上，调度 SageMaker 流水线是 AWS EventBridge 支持的目标之一。在 Azure 上，Azure Machine Learning 流水线支持调度触发器（作为流水线设置），因此不需要外部调度程序来调用它们。

我们强烈建议不要让模型在流水线中保持超过几周而不更改。如果您相信模型将继续有效，请通过持续评估模型并在必要时重新训练来验证您的直觉。我们将在下一节讨论这个问题。

持续评估和重新训练

最复杂的情况是在确定模型不再适合目的之前使用模型。要确定模型在性能上是否漂移，你需要使用持续评估。例如，如果你有一个用于预测用户是否购买物品的模型，你可以在几天后验证用户是否购买了相关物品。然后，基于两周前的预测进行每周一次的模型评估，并且现在可以获取真实答案。当评估指标低于预设阈值时，可以重新训练模型（参见图 8-13）。

图 8-13. 自动启动重新训练的持续评估

你还可以扩展持续评估方法来检测特征漂移——如果任何输入到机器学习模型的分布发生变化（例如，如果重复购买次数占所有购买的 10%，现在增加到 20%），你可能希望重新训练模型。

截至目前，仅有 Vertex AI 支持设置持续评估查询和在部署模型上检测特征漂移。要在 Vertex AI 中设置这一功能，你需要定义一个评估查询，并启用部署模型将特征样本及相应预测写入数据仓库的能力。定期运行评估查询，并使用得到的指标来决定是否需要触发流水线。

请查阅你的云服务提供商文档，确认当前是否支持这一场景。如果支持，其机制可能会有些类似。如果不支持，你将需要按照自定义方式构建相应的流水线和能力。

流式机器学习推断

通常情况下，当事件发生时，你会调用训练过的机器学习模型，并获取这些事件的机器学习预测结果。

可以将模型对象加载到流式处理流水线中，并调用模型的预测签名。这通常是调用机器学习预测的最高效方式。但是，它在小型模型和项目之外并不具备可扩展性。

例如，机器学习预测可能需要非 Python 代码和在没有 GPU 的硬件上运行的程序（例如，考虑一个工业机器，需要自动识别装配线上物品是否有缺陷，或者一个需要拒绝有毒评论的 Web 服务器）。为处理这些情况，通常会将模型部署到一个端点，以便作为微服务调用。然后通过向其发送 HTTP 请求来调用模型，并将输入传递给机器学习模型。

ML 推断如果一次调用一个事件是不高效的。因为现代 ML 框架基于矩阵运算，如果你传入一小批事件进行推断，效率会高得多。这就是在图 8-14 中所示的内容。

图 8-14. 流推断通常涉及积累一批事件并将它们发送到部署的模型进行推断

自动化操作

如果只需要人类用户查看 ML 模型的预测并做出决策，将预测落到 DWH 中就足够了，如图 8-15 所示。但是，如果需要系统根据 ML 模型的预测自动执行某些操作怎么办？你可以使用 ML 模型来执行需要自动化的任务，比如自动向可能放弃购物车的人发放优惠券，或者创建一个更换即将损坏零件的工单。你可以通过 Lambda、Fargate、Google Cloud Functions、Google Cloud Run 或 Azure Functions 以无服务器方式调用这些操作。为了支持这一点，你需要将满足告警条件的一部分增强事件写入一个地方，从中触发云函数（参见图 8-15）。

图 8-15. 支持自动化操作—这张图是图 8-14 的延续

我们已经看过许多流式使用案例和场景，以及如何使用云原生技术进行架构设计和实施。根据你的需求，为自己的流式解决方案构建架构。例如，如果你将在流数据上进行 ML，可以选择图 8-11、图 8-12 和图 8-13 中的训练架构之一，并将其与图 8-14 或图 8-15 的推断架构结合起来。如果仅进行分析，不要复杂化架构—看看是否可以通过图 8-8 解决，并仅在必要时添加后填充架构（图 8-9）。

总结

本章重点介绍了云原生流式架构，你了解到它们高度模块化，可以从小处开始，仅在必要时添加功能。主要要点如下：

• 在许多行业中，能够在事件进行时做出决策比稍后几分钟做出决策更有价值。

• 流媒体架构非常模块化，您可以设计简单的系统，并在需要时逐步增加复杂性。

• 如果目标是为业务提供更及时的数据，流式数据摄取已经足够了。

• 微批处理通常比流水线成本更低，但是流水线可以使事件立即可用于查询，而微批处理则会存在延迟（大于分块频率）。

• 随着数据消费者数量的增加，以及不可能预测不同消费者所需转换类型的情况，许多组织将数据管道从流式 ETL 切换到流式 ELT。

• 如果数据仓库提供流媒体 API，云原生应用程序可以去除本地代理，并使用云客户端库来进行插入。

• 对于从物联网设备边缘流式传输数据，利用物联网特定功能，如边缘 SDK 和边缘硬件设备。

• 数据仓库在高吞吐量和/或低延迟情况下并不是一个好的解决方案。在这种情况下，应使用诸如 Cloud Bigtable 或 DynamoDB 等 NoSQL 分析存储。

• 使您的仪表板工具将查询推送到云数据仓库，创建可重用视图，并将一些视图实体化以优化性能/成本。

• 在时间序列分析中，将警报写入警报主题和数据仓库，以支持自主操作和人工探索。

• 使用预建工具进行点击流分析，但补充一个回填管道来丰富点击流数据，并改进身份拼接、隐私保护和机器人检测。

• 异常检测涉及两个流媒体管道：一个用于长时间段内的计算聚类，另一个用于比较传入事件与最近的聚类并触发警报。

• 为了保证流媒体的弹性，确保更新正在运行的管道。如果无法更新，要排空它们。不要简单地取消正在运行的生产管道。

• 如果您正在进行频繁的训练，并且训练数据由相对较小的时间段组成，请使用滑动窗口流水线向机器学习训练管道提供训练数据。

• 对于模型将有效数天到数周的情况，可以使用定时作业来启动训练。

• 要确定部署的模型在性能上是否出现漂移，您需要进行持续评估。

• 因为现代机器学习框架基于矩阵运算，如果向推断传入小批量事件，则效率更高。

• 要支持自主操作，您需要将满足警报条件的增强事件子集（事件 + 预测）写入一个主题，触发云函数。

在接下来的章节中，您将看到关于分布式架构方法和技术的概述，重点是边缘计算，这是一种可以减少延迟、增强安全性并降低成本的模式。

第九章：使用混合和边缘扩展数据平台

到目前为止，在本书中，我们已经讨论了如何利用公共云的能力来规划、设计和实施数据平台。然而，有许多情况下单一公共云将不足够，因为数据在产生、处理或存储时有时候需要位于其他位置——这可以是本地、多个超大规模云提供商，或连接的智能设备如智能手机或传感器。在这些情况下，需要解决一个新的挑战：如何提供平台的整体视图，以便用户可以有效地混合和联接分布在不同位置的数据？在本章中，您将学习处理这类分布式架构时，组织可以采取的方法、技术和架构模式。

此外，还有其他一些情况需要使您的数据在部分连接或断开的模式环境中工作。在本章中，您将学习如何利用一种新的方法——称为边缘计算，可以将部分存储和计算资源从云中移出，靠近产生或使用数据的主体。

为什么要多云？

作为数据领导者，您的组织希望您不断寻找方法来提高业务成果，同时尽量减少技术成本。在数据平台方面，您被期望通过采用市场上最佳的解决方案或至少最适合业务需求的解决方案来管理整个数据生命周期。

单一云更简单且具有成本效益

将整个软件架构整合到单一云提供商上在多方面都非常有吸引力：

简单性

当使用单一云提供商时，所得到的技术堆栈要简单得多，更加流畅。在云内部服务通常是本地集成的。例如，在 Google Cloud 上，DWH 工具（BigQuery）可以直接从托管的关系数据库（Cloud SQL）读取数据，无需数据移动。在 AWS 上的 Redshift 和 Aurora 之间以及在 Azure SQL Data Warehouse 和 Azure SQL Database 之间（通过 Azure Synapse Link）也有类似的零 ETL 集成。

学习曲线

当您只有一个云时，员工在组织内部移动变得更加容易。新员工的入职变得更加简单，员工使用在组织其他部分构建的工具也变得更加容易。

成本

使用单一的云提供商使得从安全到合同都更加简单。仅在 IT 和法律服务上的成本节省就足以使单一云成为最佳选择。由于云提供商根据使用量提供折扣，通过将所有技术支出整合在一个提供商处，可以获得更大的折扣。

出于这些原因，我们建议中小型企业选择一个单一的云提供商，并使用该超大规模提供商提供的完全托管服务设计其架构。

多云是不可避免的

我们发现许多组织可能希望使用单一云，但最终却在混合或多云环境中结束。为什么呢？

收购

即使您的组织最初只使用一个云，您可能会收购一家在另一个云上运行其整个技术堆栈的公司。现在，您成为了一个多云的商店。这是最常见的情况，因为重新平台化的成本可能非常高，并且可能不值得为业务带来拖累。

最佳云

在不同超大规模供应商上可用的功能存在差异。如果您真的喜欢 BigQuery 或 DynamoDB 或 Azure OpenAI，并认为它们是最优秀的，并围绕这些能力构建了您的应用程序，那么您将希望该应用程序在 Google Cloud、AWS 或 Azure 上运行，即使其余的技术基础设施位于其他地方。使用最佳/最熟悉工具可获得的生产力差异，仅需信用卡即可启动影子 IT 倡议的能力，以及不愿重写正在运行的内容，意味着许多组织慢慢进化成为事实上的多云系统。

支持客户

如果您正在构建在客户环境中运行的软件，您将需要支持所有主要的云，因为您将有客户使用三个云。这就是为什么例如 SAP 或 Teradata 可以在 AWS、Azure 和 Google Cloud 上使用的原因。

面对这些必然性时，重要的是要认识到没有理由成为阻碍。不再需要绑定在一个单一供应商上，并围绕单一技术构建整个数据堆栈。与传统的本地技术相比，云技术要开放得多，企业现在可以创建依赖于多个互联环境的复杂架构，这些环境运行着来自多个供应商的各种解决方案或完全开源软件（例如，有些公司将其主站点部署在一个云提供商上，而灾难恢复站点部署在另一个云提供商上，以减少对单一超大规模供应商的依赖风险）。当然，这种自由程度带来了不同的成本（在技术和人员方面），这需要额外的治理和管理。例如，如果您正在使用多个虚拟化技术，您将需要处理可能需要不同技能的不同平台，并且您还将有更多的合同需要管理，这将增加管理负担。然而，正如稍后将看到的那样，由于它可以提供的优势，这种方法正在变得越来越受欢迎。

多云可能是战略性的

在与大型企业的 IT 高管交谈中，我们经常听到他们正在进行包括多云战略在内的数字转型之旅。已有多个大型组织采用多云方法，例如，苹果为其 iCloud 服务利用了三大公共超大规模云服务商；Twitter（在最近的收购之前）使用 Google Cloud 平台进行其数据平台的支持，但是为其新闻提供了AWS 的动力支持；或者汇丰银行，将工作负载分担在 Google Cloud 和 AWS 之间，并将一些传统服务迁移到 Azure。

当正确执行时，多云可以通过在不同环境中部署的最佳解决方案相结合，为业务增加价值。实际上，这是一个全新的互联服务生态系统的开发，成为公司所有解决方案的着陆区。

采用多云环境的主要驱动因素是什么？最重要的是：

担心被锁定

这是组织面临的最大关注之一，因为他们不希望陷入单一提供商的“专制”之下。这不是技术问题（因为无论是对云还是对多云软件供应商，都无法摆脱锁定），而更多是一种业务战略问题。

退出策略

在出现失败情况（甚至可能是合同违约）时离开服务提供商的能力。

利用

管理层可能希望通过维持两个或更多的云服务提供商来保留与超大规模云服务供应商的谈判筹码。

商业

可能您的组织使用微软的企业软件，在亚马逊上销售，并在谷歌上进行广告宣传。可能存在一个更大的商业需求，在多个公共云上留下印记。

法规要求

也许某个提供商在特定地区提供的服务不合适，或者在该地区提供的服务集不够充足（例如，灾难恢复）。

可持续性

公司希望选择最佳的可持续云，因为这对满足未来环境、社会和公司治理战略的趋势至关重要。

创新

采用解决方案，没有成本、商业方面或功能方面的障碍。

知识

提供一个无障碍的环境，让员工能够成功，并且人们可以利用他们在职业生涯中已经获得的技能或者获得新技能是至关重要的。

可移植性

超大规模云服务商专有的解决方案在运行位置方面往往受限，而在多云上运行的开源解决方案通常也可以在本地和边缘设备上使用。

现在，您对于为您的业务考虑多云战略的原因有了更好的理解，让我们来看看一些可以用来实现这一战略的架构模式。

多云架构模式

多云架构可以使用不同的模式来连接数据，并允许用户与所有需要分析的解决方案进行交互。在本节中，您将了解与这些范式一起工作时可能遇到的最常见模式。

单一视图

最大的挑战之一是开发解决方案，使得能够跨多个由不同供应商管理的各种位置的数据孤岛进行数据分析。为了实现这一目标，利用那些从本质上讲是云无关的开放式解决方案，并且能够在需要时与多个不同的数据源连接和混合数据是至关重要的。在这里可以利用主要有两种不同的方法：

• 基于 BI 工具的方法，如图 9-1

• 基于处理引擎的方法，如图 9-2

图 9-1. 利用 BI 解决方案的单一视图

图 9-2. 利用分布式处理引擎解决方案的单一视图

在第一种方法中，您委托 BI 工具（例如 Looker 或 Power BI）连接多个稀疏数据源、检索相关信息、远程执行查询并最终聚合结果的任务。在第二种方法中，您将处理引擎（例如 PrestoSQL、BigQuery Omni）与位于不同环境中的各种数据源连接起来。在这种情况下可能存在两种不同的方法：

• 利用跨多个超大规模环境的分布式环境（例如，BigQuery Omni），为最终用户提供与解决方案交互的单一视图

• 利用连接器（例如 Java 数据库连接[JDBC]）来跨多个系统查询和混合数据

一次编写，多处运行

获得云选择性的常见方法是使用可以直接在不同超大规模平台上运行的软件。有几种可能的方法来实现这种模式：

管理的开源软件

您可以使用 Apache Airflow（一种开源工具）来进行工作流编排，但通过使用 Amazon Managed Workflows for Apache Airflow（MWAA）、Google Cloud 的 Cloud Composer 或 Azure 的 Azure Data Factory 来避免管理的开销。这样，开发人员编写的代码可以在各种云上进行移植，同时仍能获得托管服务的好处，除了初始设置中的一些小差异。在不同超大规模上使用开源与不同托管服务的模式，例如 Presto、Spark、PyTorch 和 TensorFlow，在许多其他情况下同样适用。

多云产品

工具如 Snowflake、Confluent Kafka 和 Databricks 在主要超级云平台上提供完全托管的服务。因此，可以将由 Snowflake SQL、Snowpark 等组成的 Snowflake 工作负载在 AWS 上运行，并且几乎原封不动地在 Azure 或 GCP 上运行。需要注意的是，不同超级云平台上软件版本的可用性通常会有一些滞后。

多个跑步者

Google Cloud 将用于编写 Cloud Dataflow 流水线的软件 API 开源为 Apache Beam。因为 Apache Flink 和 Apache Spark 现在提供 Apache Beam 的运行器实现，所以可以在托管的 Flink 服务（如 Amazon Kinesis Data Analytics）上几乎不经过大量更改地运行 Apache Beam 流水线。

IaaS 的开源软件抽象层

不是通过 Azure OpenAI 或 Google Cloud Vertex AI 提供的提示 API 调用 LLM，而是选择通过 LangChain 访问模型，LangChain 提供一致的接口。这样可以在不同的 LLM 提供商之间保持软件工作负载的可移植性（尽管您需要验证相关提示是否可以互换使用）。

IaaS 上的开源软件

诸如 Dask、Modin、RAPIDS 等的开源软件可以在从超级云平台租用的虚拟机或集群上运行。除非您具有管理 IaaS 上软件成本效益高的使用规模，否则应尽量避免这种情况。

从本地突发到云端

这是一种旨在支持在本地拥有大型数据湖并希望扩展到云端但尚未完全迁移的组织的模式。混合工作负载可以帮助解决他们的直接痛点，并作为未来迁移的铺路石，展示采用和使用云技术是多么简单。

采用云方法开始的最简单方式是将本地 Hadoop 工作负载突发。对于在硬件和与 Hadoop 相关的堆栈上都有重大投资且受容量限制的组织来说，突发非常适合。突发的主要应用场景包括大型一次性作业，例如需要大型集群处理数据的月度报告。突发在那些可以针对上传到 blob 存储服务（例如 AWS S3、Google Cloud Storage、Azure Blob Storage）的数据运行多个作业，并且处理所用数据可以进行增量更新的情况下效果非常好。这种解决方案的主要优势之一是，同样的 Spark 或 Hive 作业既可以在本地运行，也可以在 PaaS 集群（例如 Amazon EMR、Google Cloud Dataproc、Azure HDInsight）上运行。这与重视开源解决方案并且偏好不绑定供应商的组织非常契合。重要的是，这里所有的数据湖中数据摄入的上游流程保持不变。所有这些显著降低了重新执行和重新测试现有流程的风险，并缩短了首次部署时间。

它实际上是如何工作的？这种方法使用 Hadoop 的分布式复制工具，也称为DistCp，从您的本地 HDFS 移动数据到目标云 Blob 存储。数据传输完成后，会创建一个 PaaS 集群，可以在该集群上运行 Spark 作业。作业完成后，集群被销毁，作业结果被保存，如果不计划运行其他作业，则可以销毁 Blob 存储桶。可以利用像 Airflow 这样的开源解决方案来协调突发工作负载，该解决方案可以在本地和云端工作（例如，通过 Google Cloud Composer 也可以在 PaaS 模式下使用），如图 9-3 所示。

图 9-3. 在本地 Hadoop 工作负载中突发

这种模式涵盖的其他用例包括：

• 组织测试版本升级的能力。在云中启动特定 Spark 版本的 PaaS 集群并验证作业在部分本地数据上是否正常工作，通常比完全迁移更少风险和成本高昂。

• 实验和测试新技术（例如直接在 Spark 作业中集成第三方服务）。

突发是我们在多个组织中多次看到的常见模式；让我们看看如何扩展它。

从本地到云端的直通

这种模式可以视为前一个模式的补充。在前一个场景中，我们展示了如何使用 Hadoop 原生工具 DistCp 将部分本地数据湖移动到云 Blob 存储桶。一旦数据到位，组织可以利用其他处理引擎的工具（如 AWS Redshift、Google BigQuery、Azure Synapse）来处理数据，如图 9-4 中描述。

利用云处理引擎可以启用多个工作负载：

• 处理 ORC、Parquet 或 Avro 文件，包括 Hive 分区数据，利用联合查询。

• 将本地数据与云中数据联接：一个很好的例子是将组织的事务数据（位于本地）与从营销工具（如 Adobe 或 Google Analytics）加载的数据联接。

• 基于本地数据构建模型，利用 AI/ML 工具。

• 在本地数据上运行规模化的批量预测。

图 9-4. Hadoop 通过启用云中的过程数据

使用这种方法，重要的是注意一些关键点：

• 与完全迁移相比，无需更改任何供给或使用本地数据湖的系统。

• 除了 Hadoop 工具外，还可以通过云处理引擎进行数据分析。

• 数据一旦传输到云存储桶中，通过选择的处理引擎访问联合数据时无需额外延迟或处理。

• 将相同的数据传输到云存储桶，可以由在本地运行的相同 Spark 作业进行处理。

• 像 Informatica、Talend、TIBCO 或 MuleSoft 这样的集成平台即服务（iPaaS）解决方案可以用来促进数据源的集成并保持同步。

流式数据集成

组织之间存在数据库和应用程序之间的障碍，无论是在本地还是在云端。处理过程是批处理的，因此不支持企业需要的快速运营决策。服务通常是自我管理的、遗留的，不适合云环境，并且运行和维护成本高昂。这导致了昂贵、缓慢和碎片化的系统架构。

变更流是将数据更改作为它们发生的移动，从（通常是数据库）源到目标的过程。由 CDC 支持，变更流已成为关键的数据架构构建块。全球公司正在要求 CDC 提供跨不同数据源的复制能力，并为实时分析和业务运营提供实时流式数据源。

那么 CDC 是什么呢？CDC 是一种数据集成方法，使组织能够更快地集成和分析数据，同时使用更少的系统资源。它是一种从数据源中仅拉取最新更改（更新、插入或删除）的方法，通常通过读取数据源保留的变更日志来实现。CDC 对于将新数据加载到操作数据存储和数据仓库时减少对源系统影响非常有效，它消除了批量加载更新和不便的批处理窗口的需要，通过使增量加载或实时流式数据更改进入数据目标成为可能。CDC 可以在许多从数据实时变化中获取价值的使用案例中使用；按照常见程度排序，最常见的使用案例如下：

分析

通过集成 CDC 以将数据加载到数据仓库中，组织可以例如获取源数据的最新物化视图。组织可以使用这些持续更新的数据来构建最新的仪表板，用于监视系统并获取关于业务状态的最新洞察，如图 9-5 所述。在数据新鲜度对业务影响和收集处理成本之间必须权衡考虑。

图 9-5. 启用分析的 CDC 架构

数据库复制和同步场景

通过集成 CDC 来将数据加载到 SQL 数据库，组织可以在这些数据库中获得其源数据的最新材料化视图。组织可以在目标数据库中使用这些持续更新的数据，以实现从源到目标的低停机时间数据库迁移，或者用于多/混合云配置，其中源和目标位于不同的托管环境中，正如您可以在图 9-6 中看到的。

图 9-6. 用于实现数据库复制和同步的 CDC 架构

事件驱动架构

现代基于微服务的架构依赖于数据的中心化数据中心，这些数据中心持续不断地从整个组织中更新事件以实现事件驱动。通过持续写入到云 blob 存储等目的地，组织可以构建基于消费来自这些目的地的事件数据的事件驱动架构，如图 9-7 所述。

图 9-7. 用于实现事件驱动架构的 CDC 架构

现在，您对允许构建多云数据能力的可能模式有了更好的理解，让我们看看如何采纳全面的多云战略。

采纳多云

采纳多云范式是战略的一部分，应该随后转化为 IT 架构。

框架

要将多云战略转化为多云 IT 架构，企业架构师利用像 TOGAF（开放组织架构框架）这样的常见框架来识别业务需求，定义支持过程所需的数据以及应用程序如何处理这些数据（架构开发模型[ADM]过程），如图 9-8 所示。完成后，可以确定技术需求，为整合架构带来视野，而多云范式为组织提供了高度的灵活性和自由度。

图 9-8. 根据TOGAF 框架的 ADM 周期

能够访问广泛的服务当然是一个机会，但是重要的是要小心管理，以避免失去焦点。识别能够帮助您按照战略和组织规则实现业务目标的服务至关重要，特别是在合规方面。随着组织越来越多地将 IT 功能重新(内)部署以拥有其软件和解决方案的所有权和控制权，这一点尤为重要。

让我们以金融服务行业为例。我们可以看到，大量投资已经用于转变传统环境（主要基于主机解决方案）成为现代化解决方案，特别是在数据方面。诈骗检测系统基于实时分析，了解客户流程依靠先进的 ML 算法工作，反洗钱需要处理大量数据。如果仅依赖于单一提供商，则很难获得这种特定的解决方案/工作负载；因此，组织正在考虑采用多云方法以获取最佳解决方案以满足其需求。

时间尺度

确定采用多云的时间尺度非常重要。具体来说：

• 一些组织可能永远不会完全迁移到公共云，可能是因为它们属于金融或医疗行业，需要遵守严格的行业规定以及数据存储方式。对于它们来说，“数据驻留”非常重要。有些企业可能希望保护其类似 SAP、Oracle 或 Informatica 的本地工作负载，但同时也希望利用公共云创新技术，如全面管理的数据仓库。

• 其他大型企业则致力于他们多年的与本地公共云现代化之旅：他们将不得不在多年内采用多云架构作为最终状态。

• 最后，有些组织尚未准备好迁移到公共云，但由于临时大批处理作业的挑战，无法满足业务 SLA：他们希望利用公共云的可扩展能力，并避免增加本地基础设施的成本。

在前述概念的基础上，如何形成多云架构？让我们深入探讨。

定义目标多云架构

您可以采用与之前章节讨论的相同方法（处理单个（公共或私有）云供应商时），但您需要（1）为每个涉及的供应商重复该方法，并且（2）在总体目标架构的背景下执行此操作。

以下步骤将帮助您定义和采纳目标云架构：

1. 制定您的策略。

在采用多云战略之前，您需要清楚地了解自己的目标。这些目标可能与业务、战略或技术相关。一旦确定了您的目标，您需要识别推动您采用多云战略的驱动因素。这些驱动因素可能是成本、功能缺失、开放性或法规合规性。例如，如果您采用多云策略是为了利用优势，您可能会将最易迁移的工作负载（例如 Hadoop 或 Kafka）放在次要云上。一旦您清楚了解了您的目标和驱动因素，您就可以继续您多云旅程中的下一步骤。

2. 发展团队。

谈到云时，所需的技能可能非常丰富。身份、安全性、网络、编程等只是云工程师应该掌握的一些主题。处理多云架构时，这套技能变得更加庞大，因为即使这些主题在高层面上是可以互换的，但工程师们必须具备深入和特定平台相关的知识。通常情况下，你需要建立一个云卓越中心，如“第 1 步：战略与规划”所述，以便将所有所需技能聚集在一个“单一的帽子”下，成为整个项目的参考基础。

3. 评估。

要识别候选目标解决方案，有必要更好地了解当前的运作情况。这部分至关重要，因为它完全可以改变接下来步骤的方法。你是否将执行搬迁和转移以维护组织已有的解决方案，还是最好采取基于重新平台化/重新开发的方法来充分利用云提供商的优势？通常，在此步骤中有一些工具可以简化发现，收集多种数据片段，这些数据可以用来定义迁移计划。使用云原生工具过渡到完全无服务器架构往往是最佳解决方案，但在短期内使用你手头拥有的资源可能并不可行。

4. 设计架构。

一旦业务目标明确，你有足够的知识使一切成为现实，开始将需求转化为技术架构。定义组件如何相互通信，如何交换信息，以及如何共同执行定义的任务。架构师的目标是确定最佳解决方案，为最终用户提供更大的灵活性，保证最高水平的安全性和性能，同时关注整体成本。

5. 准备迁移计划。

一旦你收集到关于从哪里开始和要去哪里的所有信息，你必须确定如何到达目的地：模式、时间表、所需工作量和里程碑。了解不同活动/环境之间的关系以及可能的依赖关系也很重要。

6. 构建着陆区。

一切始于着陆区的定义（如在第四章中所读到的），这是工作负载将被部署的基础环境：身份和访问管理、网络连接、安全性、监控和成本管理只是这个阶段需要考虑的一些元素。这个阶段对于准备接收根据上一步定义的模型传输数据的目标环境至关重要。

7. 迁移和转换。

基于前面步骤中定义的所有内容，现在是将解决方案迁移到新架构的时候了。在这最后一步中，我们将把我们的应用程序转移到新的环境中，应用新的服务，或者完全重建应用程序以利用原生服务。

现在您对如何处理多云架构有了更好的理解，让我们深入探讨另一种混合范式：边缘计算。

为什么要进行边缘计算？

边缘计算 简而言之是促进数据处理在数据生成的地方执行的架构模式，即使它是在架构的边缘。

边缘计算是云计算范式的补充。云计算使组织能够通过集中化方法获得无限可扩展的计算和存储资源的访问权，而边缘计算旨在应对不同的挑战。边缘计算帮助组织处理需要在原地处理数据（或者需要非常低延迟）的工作负载，或者当与网络断开连接时需要继续运行的活动。云计算更倾向于将业务推向全球规模，而边缘计算更专注于将能力带到决策点附近（例如工厂、销售点等）。

带宽、延迟和不稳定的连接

来自工厂部署的设备的数据已经允许制造公司分析其仪器的使用情况，并预测维护的需求并限制潜在的损害。电信公司已能更好地了解其网络的拥塞情况，并采取适当措施以减轻可能出现的问题。

问题是您无法在云上进行此类分析。为什么？

想象自己是一个制造公司的首席信息官。首席执行官要求您找到一种加快目前手动进行的生产装配线产品质量检查的方法。您的团队已开发了基于机器学习的图像识别解决方案，以将装配线上的物品与完美产品进行比较，快速识别缺陷。您决定进行的概念验证证明了该解决方案的强大性能—它以自动方式识别了 98%的缺陷，现在您准备投入生产。您该如何做到这一点？最佳操作方法是什么？概念验证过程非常简单：

• 收集代表完美物品的图片

• 收集代表带损坏/瑕疵物品的图片

• 为每张图片分配特定标签（良好物品、有缺陷物品）

• 开发和训练图像识别模型以识别两类物体的聚类

• 部署模型并通过 API 使其可用

• 对装配线上每个物品执行以下步骤：

  • 用相机拍摄物品的照片。

  • 将图片作为 API 调用开发模型的输入负载上传到云环境中。

  • 根据模型输出，决定是否继续（物品良好）或停止流程（有缺陷物品）。

这种方法对于测试目的很好，但有些注意事项使得在生产场景中部署它不切实际：

带宽

系统需要拍摄高分辨率的照片才能有效；每张需要上传到云端的照片都很大。考虑到每天需要检查的每个装配线上的物品数量，需要传输的数据量非常庞大，这需要大量带宽。

延迟

要有效和可扩展，您需要在拍摄照片后几毫秒内获得结果（物品良好与有缺陷物品）。即使有高速连接，要使其快速到足以跟上装配线仍然很困难。

脱机

工厂通常位于偏远地区，维持稳定网络连接很困难。因此，即使脱机，这些解决方案也至关重要。

所有这些注意事项都与单点故障相关联：需要与云环境连接的需求。但如果能够将更多智能带到物理设备/传感器附近，并使其能够在几乎无感知的延迟甚至脱机情况下运行和做出智能决策，那会是非常有益的。边缘计算的目标正是这样做的：将一部分存储和计算资源从云端带到生成/使用数据的主体附近。

应用案例

存在多种情况下，集中式云环境无法工作而边缘部署可以带来好处。以下是一些例子，这并不是详尽的清单，但它应该让您了解到可能性：

自动光学检测

使用深度学习模型进行图像分析的应用案例，以识别与期望状态不符的情况，例如自动检查装配线上物品的质量或加快检查车辆部件磨损水平的解决方案。

提高安全性

使用摄像头和其他传感器监控特定位置（如工厂、工作场所或危险场所）以确保人员安全的应用场景。这可能包括热成像摄像头用于识别危险场所或靠近危险机械的人员，或者传感器检测是否有人摔倒需要帮助。

农业

使用传感器监测植物的健康、生长和吸收的营养水平。收集的数据可以实时分析，以验证是否缺少或超过某些营养物质。

医疗保健

分析实时患者数据以提取更多洞察，例如磁共振图像、超声波、葡萄糖监测器、健康工具和其他传感器。

内容传送网络（CDN）

为了改善浏览体验，通过互联网传输数据的内容提供商（例如，音乐、视频流、网页等）通常会在边缘缓存信息，以减少检索时的延迟。选择缓存什么可以通过实时算法大大改进。

沉浸式互动

实时 实时、快速的反馈对于提高 VR 头显（例如增强现实、游戏等）沉浸式体验的真实性非常重要。

智慧城市

旨在使城市更加智能，避免能源和资源浪费的应用，例如由传感器实现的自动照明系统，这些传感器监控和控制单个灯光或一组灯光，以最大化效率同时保持安全。

交通管理系统

借助摄像头和传感器，可以实时调整交通信号灯或管理交通车道的开闭，以避免拥堵。当自动驾驶汽车变得更加普遍时，这一案例的重要性将进一步增加。

你现在熟悉了可能采用此模式的用例；现在让我们专注于你可能获得的好处。

好处

边缘计算的作用是扩展集中式基础设施，将更多的计算能力带到架构的边界附近。这使得连接（或断开连接）设备能够执行需要非常低延迟和本地计算的任务（例如，机器学习推断）。这种模式解决了一些基础设施挑战，如带宽限制和网络拥塞。其他好处包括以下几点：

可靠性

大多数物联网架构包含在像办公室或家里这样不完全连接的环境中不存在的元素。有相当常见的情况，在这种情况下，几乎不可能保持与世界的恒定可靠连接，且延迟低且稳定。想一想那些电信公司没有投资高速有线连接的农村工业场所，或者在海中使用旧式连接（2G/3G）的风力涡轮机，或者需要在决策时使用微秒级延迟的自动驾驶汽车（如果你的车需要刹车以避免事故，你肯定不希望等待来自云端的响应）。所有这些用例，要有效，都需要能够本地存储和处理数据，并且能够在临时连接中断时处理，而不会影响其功能的设备。

法律/合规

在某些行业（例如金融服务和保险）中特定国家有严格的规定，关于存储、处理和披露数据（想想 GDPR 规定）。能够本地转换和使用数据，并可能将修改后的版本（例如，去标识化、加密等）发送回云端，将提高组织采用现代架构的能力，同时保持合规。

安全

数据外泄、分布式拒绝服务（DDoS）攻击防护和数据保护是一些场景，边缘计算可以显著降低风险，因为设备可以完全脱机工作，甚至可以通过加固网关强制与外部世界连接，从而实施额外的数据保护层，例如临时加密。

现在让我们将注意力转向处理边缘计算范式时可能遇到的挑战。

挑战

除了这种新模式可以为组织带来的好处外，还有一些缺点需要解决，例如：

计算和存储能力的限制

部署在边缘的设备通常具有有限的硬件，可以非常好地执行定义的操作（例如收集温度数据的传感器等）。因此，设备往往是超专业化的，不适合进行通用任务。即使设备能够执行一些通用任务，例如本地运行机器学习模型，但安装的设备配置版本可能没有必要的功能。

设备管理/远程控制

正如我们之前所概述的，由于连接性或严格的访问政策，云与这些设备之间的连接可能会很棘手。您可能需要物理访问每个设备来检查状态，最终可能需要应用所需的更新/补丁。如果某些位置环境恶劣或设备部署在无法访问的位置，则可能并不简单。

备份和恢复

由于这些设备大部分时间可能处于离线状态，您可能需要实施额外的本地物理基础设施（例如智能网关加网络区域存储）来进行备份和恢复，这会增加总体成本。

如果您的使用情况中存在任何这些挑战，您需要评估它们是否是阻碍因素，或者是否存在有效的解决方案来缓解这些问题。

边缘计算架构模式

与云计算类似，在定义边缘计算架构时有清晰的策略非常重要：可能存在所有设备由中央（可能是由云应用程序）集中管理的情况，而也可能存在节点完全断开连接或部分连接仅通过本地网络（用于彼此或与本地网关通信）的其他情况。

从广义上讲，边缘计算架构可以分为两种类型：一种是设备智能化，另一种是在边缘添加智能网关。无论是智能设备还是智能网关，机器学习的激活方式都类似。我们来看看这两种模式。

智能设备

智能设备是实施边缘计算架构的一种直接（尽管昂贵）方式。在我们的示例场景中，用于生产必须通过质量检查的物品的机器都需要具备执行 ML 算法的硬件，能够识别图片中的缺陷。负责执行逻辑的设备可以简单地称为“节点”，它们的硬件可以根据它们需要解决的用例而异：它们可以配备通用 CPU 或专用硬件来执行特定任务。

配备能够直接执行复杂逻辑的非平凡硬件的智能设备（例如树莓派、珊瑚传感器等），如图 9-9 所示，提供了极大的灵活性，但需要大量的管理工作（例如软件更新、安全补丁等）和增加的硬件成本。

图 9-9. 带智能设备的边缘架构

智能网关

通过电线或无线连接到智能网关的“愚蠢”设备/传感器，可以代表它们执行逻辑，如图 9-10 所示，是处理同一地点（例如工厂内）大量传感器的首选方法，因为它可以减少管理（一个单一的智能设备代替n个）及相关成本。然而，这也在架构中引入了一些安全挑战，因为它可能成为单点故障（SPOF）。

图 9-10. 带智能网关的边缘架构

ML 激活

我们之前讨论过一个 PoC 场景，在这个场景中，机器与云环境完全连接，持续地发送和接收数据，以便决定如何处理流水线上的物品（接受或拒绝）。那么您已经看到，使这种架构能够在生产中部署的唯一方法是扩展它，使设备能够在边缘直接执行该逻辑。

在边缘设备上执行的代码可能因情况而异，但可以概括为一个 ML 模型，用于处理一些输入（在本例中是图片），以获得所需的输出（在我们的例子中是对物品的最终决策）。在前几章中，讨论现代数据云架构时，您已经看到云的主要好处之一是其能够大规模收集和处理数据，使开发人员能够轻松实现最先进的 ML 算法。

让我们来看看开发 ML 算法过程的不同步骤（见图 9-11）以及为此，让我们利用之前的例子：

1. 数据收集

一切都始于作为处理输入数据的数据。在我们的场景中，我们需要开发一个能够从图片开始识别物品信息和特征的模型，因此拥有大量良好项目和带有缺陷项目的图片访问权限非常重要。（请注意，你可以创建任意数量的状态，但为简单起见，我们将仅考虑两个状态：良好项目和通用缺陷项目。）

2. 数据分析

前一步骤收集的数据需要进行精炼（例如清洗、转换、丰富）以便利用。在这个具体的例子中，我们需要验证所有拍摄的质量（例如焦点、对齐、噪声等），然后针对每张图片，我们需要应用一个标签，指示图片中报告的内容，以生成两个分离的集合：良好项目和带有缺陷的项目。

3. ML 模型开发、训练和测试

是时候开发算法了；有很多工具和技术可供使用（例如 scikit-learn、TensorFlow、PyTorch），甚至有自动化解决方案可使生活更轻松（例如在特征工程、模型选择和参数调优中提供支持）。在我们的例子中，我们可以使用迁移学习技术开发一个深度学习模型来识别图片。

4. ML 模型部署

模型已准备好用于预测。它可以作为 API 服务部署在云端或直接部署在边缘节点。

5. 反馈数据收集

为了提高模型质量，可以收集来自边缘的数据，然后重新开始交互式过程，旨在使预测结果更好。在我们的案例中，边缘节点将返回（例如批处理过程）预测结果和分析过的图片。

图 9-11. 边缘规模上的 ML 开发/部署

很明显，这些 ML 建模步骤对边缘架构施加了一定的要求：

1. 数据收集需要能够长时间存储收集的图片，以便可以更换硬盘并将其移至网络连接更好的地方，并将数据上传到云端。

2. 数据分析可以在云端进行。

3. ML 模型开发也可以在云端进行。然而，测试需要能够在云端模拟边缘环境。

4. 部署要求在开发 ML 模型时考虑边缘硬件的特性。将 ML 模型部署到边缘可能需要升级硬件组件，以包括如 Google Coral Edge TPU 或 NVIDIA Jetson Nano 的 ML 推断芯片。

5. 反馈数据收集要求实施一个应用程序，以跟踪人工操作员在 ML 算法建议的决策上覆盖的情况。

现在您对边缘计算范式的理论有了更多了解，让我们看看您如何采用它。

采用边缘计算

让我们看看采用这种范 paradigm 可以为模范组织带来更大的可见性和更高的效率。

初始背景

MagiCan 是一家专门生产饮料罐头的（虚构）制造公司，为世界上最具标志性的品牌提供服务。该公司在全球各地设有多个生产工厂，每个工厂都有多台机器全年无休地运行。该公司的战略一直是在城市外地区建厂，并且在某些地点，当地电信公司提供了基于旧无线技术（例如，3G 运营商）的互联网连接。

公司的核心价值之一是“高质量产品是必须的，无论付出多大努力”，并且一直投入大量资金确保端到端生产周期的质量（例如，维护机械设备和对生产物品进行质量检查）。

MagiCan 发现需要处理的几个问题：多台机器存在过多故障，导致多个生产点多次停工；产品存在缺陷，导致罚款；难以全面查看生产厂的状态。因此，董事会决定启动一个新项目，改善其收集和处理工厂数据的方式，以解决所有这些问题。

项目

该组织已经利用云计算解决方案处理多个工作负载（例如，DWH、网站、SAP 等），并决定扩展当前架构，投资于直接连接到其机械设备的设备：目标不仅是直接从工厂收集数据，实时查看机器运行情况，还允许用户操作某些参数/组件（例如，执行器、装配线等），以修复问题或校正不准确之处，提高生产过程的整体质量。

该组织在物联网项目专业的第三方合作伙伴的帮助下，定义了一个三步旅程：

1. 通过开发所需架构从工厂收集数据并构建近实时监控系统来提高整体系统的可观察性。

2. 开发自动化以调整执行器的功能。

3. 通过开发预测模型优化机械设备的维护。

让我们深入探讨这次旅程的三个步骤。

提高整体系统的可观察性

考虑到 MagiCan 在全球多个地点设有工厂，并且大部分工厂无法与云世界稳定连接，因此无法基于流式模式开发实时架构。公司决定将问题分为两个不同的部分：

• 本地架构（在工厂级别），所有机器实时连接，并且所有信息可以立即被中央但本地的应用程序看到

• 集中式架构 利用云系统，从工厂收集的信息每天多次以批处理方式处理

目标是在每个工厂开发一种标准的监控机器的方法，并在工厂脱机时保持数据可用。中央云脑必须收集来自不同工厂的所有数据，然后让数据科学家能够研究这些数据，以便能够提取更多的见解，并利用云的力量，如图 9-12 所示。

在每个工厂，部署了带传感器的设备到各种机器上，以收集来自不同执行器（如速度、转速、温度等）的数据。这些设备通过智能网关与本地连接，能够实时收集所有数据，并通过自定义开发的可视化工具提供用户一种对工厂状态进行连续快照的方式。每隔 x 分钟，数据被压缩并发送到云端进行进一步分析，然后与其他工厂的数据聚合。如果网络出现问题，批处理将排队，并在下一批次中发送数据以提升。

图 9-12. 高级物联网平台架构

开发自动化流程

一旦云端收集到来自所有工厂的数据，就是开始有些有趣的时候了！可用的大量信息使团队能够获得关于多个方面的可见性，例如：

• 工人如何与机器互动

• 油罐上执行器配置与缺陷之间的相关性

• 由于机械问题导致的平均无活动时间

• 在使用特定原材料时的理想机器配置

考虑到设备与云之间通过智能网关的双向连接，可以发送反馈并使机器接收到更新信息以调整它们的操作方式。公司开发了一个几乎实时的过程，用于处理来自工厂的所有数据，了解与理想目标操作模式的差异，并发送更新配置以立即调整执行器行为。通过这种集中管理的流程，可以根据它们正在运行的当前情况为机器提供定制配置。

优化维护

最后一步是解决一个相当难以处理的问题：机器的维护。在获得机器运行的统一概览之前，维护是通过两种不同的方式进行的：

通过计划的干预进行计划维护

根据机器型号、历史记录和操作方式，定期检查机器。

通过临时干预进行的非计划维护

由于某些事件，如组件损坏或操作人员错误导致的故障，机器被有目的地检查。

考虑到维护操作可能使机器停机数小时甚至数天，尽量减少非计划停机时间非常重要。利用来自工厂的数据（在初始投入使用后几个月后才可能进行分析，因为需要足够的历史数据量），开发了预测机器学习模型算法，用于计算机器故障的概率：当百分比超过一定阈值时，会向工厂经理发送警报，他必须决定如何处理（即，安排一次非计划维护操作或等待下一次计划维护操作）。

最终成果和下一步计划

整个端到端项目花费超过一年时间才完成，但最重要部分的第一版发布（即在各个工厂统一视图开发）相对较快地实现了（不到六个月）。由于这种分布式架构，公司能够提高在工厂和公司级别的可观察性，利用了一种通用、标准化和统一的流程。同时，它能够提高整个生产链的效率。MagiCan 现在正在专注于一个全新的项目，旨在降低质量检查的成本，在过程中尽可能自动化。与本节开头介绍的类似，该组织希望扩展已经建立的架构，实施一个能够自动识别装配线上缺陷的流程：为实现这一目标，将利用具有基于机器学习模型逻辑执行能力的新摄像设备。其目标是将目前执行质量检查的大部分人力资源重新分配到其他活动中去。

概要

本章为您提供了如何处理混合和多云架构的高层次理解，当单一云服务提供商无法满足所有业务分析需求时。它向您介绍了处理这类架构时需要考虑的各种因素，以及一些常见的实施模式。最后，它向您介绍了边缘计算及其使用方式。主要收获如下：

• 将整个软件架构统一在单一云服务提供商上非常具有吸引力，因为整体架构简单，学习和采用容易，而且总体成本低廉。

• 小型和中型企业应选择单一的云服务提供商，并利用该超大规模提供商提供的完全托管服务设计其架构。

• 由于收购或希望使用在某个云上可用的服务的愿望，多云架构可能变得不可避免。

• 当组织担心被锁定、需要实施退出策略、有严格的监管要求或希望增加工作负载可移植性、创新、知识和可持续性水平时，必须考虑多云战略。

• 采用多云战略是一个旅程，需要明确定义要遵循的战略，并扩展团队的技能。

• 处理多云架构时，可以利用各种架构模式，如开发单一玻璃窗口、在本地工作负载中突破 Hadoop、使用 Hadoop 直通以在云中进行数据处理以及改变流以实现数据集成。

• 边缘计算是一种旨在将部分存储和计算资源从云端带到生成/使用数据的主体附近的范式。

• 带宽限制、网络拥塞、可靠性、法律合规性和安全性只是边缘计算范式可能带来的一些好处。

• 边缘计算的主要挑战包括计算和存储能力的限制、管理/远程控制以及备份和恢复。

• 利用这种边缘计算范式的主要用例包括自动光学检测、改进的安全性、农业、医疗保健、内容分发网络（CDN）、沉浸式互动、智能城市和交通管理系统。

• 在选择边缘架构时，智能设备比使用智能网关更简单但更昂贵。在任何情况下，ML 激活都涉及添加诸如设备存储和 ML 推理芯片等能力。

下一章中，您将学习在人工智能和机器学习中应该做出的关于架构和框架的高层次决策。

第十章：AI 应用架构

在本章中，您将了解在构建 AI 和 ML 应用程序时应该做出的架构和框架的高级决策。我们首先考虑 AI/ML 擅长解决哪些问题以及如何负责地开发和部署 AI。一旦您确定 ML 适合解决某个问题，您将不得不继续决定您采取的企业方法：您是购买、适应还是构建？我们看看每种情况的例子以及如果选择采用这些方法时的考虑因素。如果您正在构建，有几种架构选择，选择取决于正在解决的问题类型。

本章涵盖了应用层面上 AI 架构的考虑因素和决策标准。数据科学家和 ML 工程师将在第十一章中讨论开发和部署这些应用程序的平台。不要跳过这一章直接进入下一章的技术细节——作为云架构师，您需要为每个应用团队提供建议，以便在您的平台上为其构建的每个应用选择正确的购买、适应或构建以及 AI 架构的选择。

注意

本章和接下来的一章的目的是向您展示如何使用云技术架构 ML 平台。就像我们在数据仓库章节中没有涵盖 SQL 一样，在这些章节中我们也不涵盖 TensorFlow。如果您希望学习如何进行 ML，我们诚挚推荐 Aurélien Géron（O'Reilly）的书籍Hands-on Machine Learning with Scikit-Learn, Keras, and TensorFlow: Concepts, Tools, and Techniques to Build Intelligent Systems。

这是一个 AI/ML 问题吗？

要了解机器学习可以解决哪些问题，让我们从我们在第一章中简要提到的一些基础知识开始。我们将从一些定义开始，然后考虑 ML 作为解决方案通常适合的问题类型。

AI 的子领域

AI 是通过让计算机像人类一样思考和行动来解决问题的研究领域。在 AI 的历史上，曾经尝试过几种方法。一种方法是编写明确告诉计算机在每种可能情况下该做什么的代码。即使今天，许多机器人设备如制造机器人和家用吸尘器仍然是这样工作的。问题在于编写这些规则很困难。另一种方法是采访或观察专家，并使用他们的行为来编写规则。像批准病人参与实验性药物试验的 AI 模型就是这样工作的。但是即使是专家也不能告诉你他们为什么这样做。人类决策背后有很多直觉，而且一个人越是专家，他们跳过的中间步骤就越多。这些方法的困难导致了所谓的“AI 冬季”，即 AI 陷入停滞的时期（大致在 1985 年至 2014 年之间）。

ML 是 AI 的一个子领域（参见图 10-1），它使用数据而不是定制逻辑来解决 AI 问题。当您无法表达逻辑或者逻辑编码为计算机程序过于困难时，ML 就显得尤为有用。例如，ML 系统不是捕捉钉子和螺钉之间所有的区别，而是向它展示数百个钉子并告诉它它们是钉子，展示数百个螺钉并告诉它它们是螺钉。然后 ML 模型通过调整一个内部非常通用的数学函数来学会如何区分它们。ML 已有数十年历史，但直到大约 2014 年之前，它只能处理可以存储在数据库中的结构化数据。

深度学习是机器学习的一个子领域，在 2010 年代末开始受到广泛关注。它使用高度复杂的函数（这些函数在图形表示中增加了“深度”，因此得名）。深度学习已成功应用于理解语音、图像、视频和自然语言等非结构化数据。深度学习是为什么您在过去几年看到智能音箱（Google Assistant、Alexa、Siri 等）、图像搜索（Google Photos）、自动翻译和即时视频精彩片段（在体育节目中）如此流行的原因。深度学习非常强大，但在创建 ML 模型时需要大量的数据。

图 10-1. AI、ML、深度学习和生成 AI 之间的关系

生成 AI

传统上，ML 涉及解决分类和回归问题。现在，有一种越来越强大的第三种 AI 形式：生成 AI。生成 AI 是一种深度学习，早在 2020 年代初就引起了人们的关注。在这里，模型的输出可以是文本、图像、音乐、视频等。例如，像 ChatGPT 这样的 LLM 通过向模型展示大量的自然语言文本来训练，使其能够根据前文预测最有可能的下一个词语。LLM 用于生成一组初始词语，然后根据这些初始词语和提示以可能的方式完成序列。类似地，图像生成模型被训练以预测像素值，语音模型可以生成音频频率和振幅值。生成 AI 最初的应用是在句子完成（例如 Gmail 中的智能写作）和代码完成（例如 Tabnine、GitHub Copilot）方面，但现在，越来越复杂的产品使用生成 AI 来生成销售、营销等领域的邮件和文章的初稿。

它是如何工作的

ChatGPT、Bard、LLaMa 等都是被训练用于以多种风格和不同目的生成文本的 LLM，同时保持高精度和详细程度。在最基本的层面上，这类 ML 模型已经被训练能够完成句子。想象一下，您开始写如下内容：

我们正在漂浮

模型将提出一些进行句子进展的方式。例如：

... 在河流上 [80%]

... 在空间中 [15%]

语言模型已经展示了大量的出版例子——演讲、文章、书籍、评论等——使其能够理解哪些词语最有可能跟随其他词语。

但是，如果您将包含“火箭”或“夏季”等词语的先前短语传递给模型，那么后续出现的词语的相对概率将会改变。基于广泛的训练数据集，模型似乎能够适应上下文，并生成看似准确、详细和一致的响应。在其训练阶段，语言模型已经学会了哪些词语或短语需要特别关注。此外，在 LLM 的训练过程中，还使用人类反馈，以便它更倾向于人类最喜欢的词语延续。

像 GPT-4（ChatGPT 背后）和 PaLM（Bard 背后）这样的基础 LLM，是为涉及常见语言问题的通用任务而训练的，包括文本分类、问答、文档摘要和跨行业的文本生成。这些模型提供了一种互动方式来总结大量的知识和信息。这可以是多模态的，即以不同的非结构化格式，如文本、图像，甚至视频。即使只有少量特定领域的训练数据，这些模型也能取得令人满意的结果。

细调 LLM 超越了全球知识的范围，专注于特定的任务和领域。例如，专注于医疗保健的 LLM，如 Med-PaLM，经过特定的标记数据集训练，以适应在医疗保健领域内执行特定任务的模型。这些标记的数据集对于训练模型准确识别医疗实体、撰写医疗护理说明书以及执行其他与医疗保健相关的任务至关重要。

优势和局限性

此技术仍处于起步阶段，并带来了许多承诺，但也需要考虑到几个限制，特别是在企业规模上的采用。让我们看一下需要考虑的最重要因素。

LLM 是否记忆或概括？

尽管 LLM 看起来似乎能够处理任何类型的上下文，因为它们已经在包含数十亿参数的大规模数据集上进行了训练，但它们实际上不能存储地球上所有可用的数字信息。因为它们无法记住所有可能的单词序列在上下文中的位置，所以它们会在可能的单词和上下文之间进行插值。然后在可比较的上下文中选择类似的延续。

这是否意味着 LLM 能够超越其训练文本进行概括？有争议。模型可能生成与给定上下文一致的文本，但这并不一定意味着它真正理解了真实世界。需要进行更多研究来确定像这样的模型是否能够真正超越它们训练的文本范围。

然而，这个领域正在快速变化。在撰写时，可以使 LLM 利用外部数据集和服务来“基于”LLM 或告诉它推理。毫无疑问，LLM 的能力将继续变得更好。

LLM 幻觉

当前 LLM 最显著的限制之一是它们可以“幻觉”，这意味着它们可能生成在语法上正确但逻辑不合或不真实的文本。在这种情况下，我们称该模型显然产生了幻觉。

这是必须仔细解决的重要约束条件。考虑到大多数读者会快速浏览他们阅读的某些部分，可能并非所有人都能够识别出文本中存在幻觉的情况。在撰写时，需要考虑到检查准确性所需的人工工作量，这是计划采用这项技术时需要考虑的事项之一。

需要人类反馈

为了减少产生无意义文本的数量，通常在培训面向消费者的 LLM 时通常会添加额外步骤。这称为通过人类反馈进行的强化学习（RLHF），涉及训练模型根据人类评级选择生成的文本文档之间。

此外，人类帮助训练模型创建特定格式的文档（例如电子邮件、博客文章、项目符号等），并引导模型远离有害文本。

弱点

现在您了解了 LLM 的训练方式，显然它们会有一定的局限性：

• 如果任何输入源错误，那个错误的延续将成为可能的延续集的一部分。因此，LLM 可能会复制错误信息和/或过时的概念。

• 该模型在数字格式发布的大量文本存在的领域中表现更佳。因此，在编码和政治等领域，LLM 将更为出色，但在人类学等领域则较差。

• 难以标记不寻常的数字和名称（LLM 使用子词标记）。因此，您应始终仔细检查 LLM 生成的事实信息，如数字、文章作者等。

• 像所有 ML 模型一样，LLM 不应在期望确定性结果的情况下使用。

在构建依赖生成式人工智能的应用程序时，牢记这些限制是很重要的。

使用案例

这些限制并不意味着 LLM 没有用处。我们已经看到它们的各种良好应用：

领域特定助手

LLM 是根据您组织的数据进行训练的，以回答需要您的员工阅读大量文档的特定问题。例如，LLM 可以回答有关内部规定的问题。这可以节省员工的时间并提高效率。

代码片段

生成模型可以编写代码片段或审查现有代码（如自动对等编程员），以加快开发或文档编写的速度。但是，生成的代码可能不会按您的意愿执行，因此您应该逐步测试和编辑生成的代码。

文档摘要

LLM 可以帮助总结长文档，以提取相关信息（例如财务数据的资产负债表）。这也可以是提高工作流效率的一部分。

内容生成

大规模内容生成（例如个性化营销或销售）是由生成式人工智能解锁的。

一些 LLM 的生产使用案例包括 Gmail 的智能撰写、Jasper AI 的营销文案生成、Salesforce 的个性化销售电子邮件编写能力以及 GitHub Copilot 的代码生成能力。我们看到许多组织正在利用生成式人工智能为员工提供更好的访问私有知识库的途径，通过自然语言问答机器人。另一个广泛和成功的使用案例涉及使用图像生成算法来提高市场广告的差异化水平。然而，不要低估在创建这类产品时遇到的困难，其中生成的文本或图像解决了人类的痛点，准确无误，并符合人类标准。

适合机器学习的问题

您可以用机器学习解决什么样的问题？在许多这些条件同时存在时，ML 最具有说服力的应用案例发生：

重复决策

您有一个简单的“大脑”任务，必须重复执行多次，以至于人类执行起来非常昂贵或不可能。如果您是一家医疗保险公司，每天收到数千份报销请求，让人类查看报销请求并确定是否需要进行该程序非常昂贵。如果您能让计算机识别可疑的索赔，那将为您节省大量资金。相反，对于罕见的决策自动化并没有太多的商业利益。然而，数据科学家却常常陷入试图将 ML 应用于每年仅需解决几次的问题的情况中，这令人惊讶。

标记数据

当您能通过展示正确决策示例来教授 ML 系统时，ML 就会起作用。聚类数据并寻找异常值的异常检测是一个例外。然而，绝大多数 ML 问题需要您提供具有正确答案的示例。

容错使用案例

因为没有哪个 ML 算法是完美的，所以您不应在错误对生命或财产有致命影响的情况下使用 ML。您必须考虑 ML 系统出错的后果，并愿意承担后果。在错误影响重大的情况下，常见的做法是让人类参与决策过程或设立止损条款。

难以表达的逻辑

一些逻辑越难以表达，ML 在处理它时就越好。请注意，编写如何计算多边形面积的逻辑是相当容易的。这不是 ML 擅长的问题类型。当捕捉逻辑容易时，应使用传统编程方法。将 ML 保留给人类难以掌握的情况（例如，从照片中计算房间面积）。

非结构化数据

对于处理结构化数据，传统规则通常效果很好，但对于非结构化数据，则需要 ML。如果您收到一个 HTTP 响应，其中包含用户在网站上点击的按钮信息，并且您想知道他们是否购买了某个商品，那么检查购买按钮是否是他们点击的按钮之一就很简单。另一方面，如果他们在表单中输入了一些评论文本，并且您希望知道评论是否提到了运输问题，则需要处理非结构化数据（评论文本）。

现在您更好地掌握了 ML 是什么以及何时使用它，让我们来看看采用它的最佳方式。

购买、适应还是构建？

一旦确定您需要某些 AI 能力，问题就转向是否可以购买现成的解决方案或者是否必须自定义构建。AI 云架构师越来越需要选择在哪些领域购买现成的解决方案更为合适，以及在哪些领域可以构建更好、更具差异化的能力。这个决定可能还受限于优先考虑稀缺的数据科学家资源的需求。

让我们看看决策过程以及某些场景和能力，其中一个或另一个方法更好。

数据考虑

一般来说，机器学习模型的质量会随着用于训练它的数据量和质量的提高而提高。数据规模的增加推动了机器学习性能和准确性的显著改善。此外，机器学习系统需要针对新情况进行重新训练。例如，如果你有一个推荐系统用于费用类别，并且你想为酒店住宿提供推荐，那么你不能使用同样的推荐模型。你必须在第二种情况下训练它，即在出差目的地被其他员工选择的酒店上进行训练。因此，即使模型代码可能相同，你也必须为新情况使用新数据重新训练模型。

综合考虑这两个概念（当你拥有更多数据时，你会得到一个更好的机器学习模型；而一个机器学习模型通常需要为新情况重新训练），你会得到一个策略，可以告诉你是买还是自建：

• 确定可购买模型是否解决了与你想解决的同样问题。它是否已经在相同的输入和类似的标签上进行了训练？假设你想进行产品搜索，而模型已经在目录图片上进行了训练。但你想基于用户手机拍摄的产品照片进行产品搜索。那么在目录图片上训练的模型将无法处理你的手机照片，你将不得不建立一个新模型。但假设你正在考虑一个供应商的翻译模型，该模型是在欧洲议会的演讲中进行训练的。如果你想翻译类似的演讲，该模型会很好地工作，因为它使用了相同类型的数据。

• 供应商是否拥有比你更多的数据？如果供应商在欧洲议会的演讲上训练了他们的模型，但你比他们拥有更多的演讲数据，那么你应该自建。如果他们拥有更多的数据，那么购买他们的模型就合适。

简而言之，如果供应商有一个解决你想解决问题的解决方案，并且他们有更多/更好的数据，那么你应该购买它。如果没有，那就自建。越来越多的选择是：调整一个预构建模型。让我们分别看看这三种情况中的架构和其他考虑因素。

何时购买

当一个可信的服务提供商提供适合你的问题的即插即用服务或 API 时，你应该认真评估购买该服务。它几乎总是比你可以自己构建的东西更便宜和更易维护——请记住，一个流行的服务可以在数百用户中分摊其开发预算，而你必须自己支付所有改进的费用。

此外，应用市场的存在意味着该能力对你的业务不是核心。另外，你的团队可以做一些比实施可购买的东西更具独特性和差异性的事情。

当其他云或可信第三方提供了替代方案时，您可以对自己的工作负载进行评估，并选择最适合的解决方案。购买 ML 能力是一个您无需担心使用哪个云的地方——在许多情况下，这些只是 API，无论您的应用程序在哪个云上运行，都可以调用它们。例如，您可以在 AWS 上运行您的网站，但它可能会调用 Google 的 Translate API 来处理评论文本。

您可以购买 AI 能力的三个抽象级别：

SaaS

一些 AI 能力通过即插即用的 API 提供。例如，来自 Google Cloud 的 Retail Search 是一个即插即用的服务，任何企业都可以使用它来提供其电子商务网站内的 ML 支持搜索。Amazon Connect 是一个即插即用的服务，提供联系中心能力。Azure 的计算机视觉 API 可以通过发送图像来调用，并获取图像中包含的信息。所有这些都是通过 API 直接用于与您的应用程序集成的服务示例。这些模型经过多种数据集的训练，可能比您可以自行组合的任何东西更准确和更强大。

基础构件

有时，可以购买的能力并不构成完整的业务用例。尽管如此，您可能希望将该 AI 能力作为应用程序中的基础构件使用。例如，您可以在 NLP 管道中使用 Google DocAI 的实体提取或表单解析功能。在将这些图像导入系统之前，Azure 计算机视觉可以用于预扫描图像中的成人内容。Amazon Rekognition 可用于识别入职系统中的人员。

企业应用程序

有时，能力过于定制化，无法作为 SaaS 购买，也太复杂而无法作为基础构件提供。在这种情况下，您仍然可能购买组合产品和服务的能力。供应商在您的行业中实施该能力的经验，并可以重复使用其较早的工作来为您构建能力。可重用代码与现场代码的相对比例因供应商和用例而异。例如，C3 AI 将根据您的第一方数据构建反洗钱解决方案，但利用其在其他金融公司构建类似解决方案的经验。

此类能力的来源不仅限于主要的云提供商。Google Cloud、AWS 和 Azure 的市场都有来自各种供应商的广泛选择的 SaaS 能力。系统集成商（如 Accenture 和 Wipro）和 AI 应用提供商（如C3 AI、SpringML 和 Brightloom）提供 AI 解决方案，以改善客户参与、定价、数字营销、收入智能、产量优化等方面。

您可以购买什么？

一个正在采用人工智能的公司的云架构师必须熟悉供应商选择和供应商管理。了解像 TensorFlow 这样的 ML 框架和像 SageMaker 和 Vertex AI 这样的 MLOps 平台的知识是不够的。

随着基于人工智能的初创公司的爆炸性增长以及全球和地区系统集成商增加 AI 实践，可以购买而不是构建的能力数量继续大幅扩展。我们在本节写的任何内容几个月后都将过时，因此我们将以大致的概述进行讨论，并鼓励您进行研究、要求演示，并做出明智的决定。通过选择合适的供应商，您可以节省数月的努力，并显著降低失败风险。

这里是一些 2023 年初存在的能力：

更好的客户服务

有许多 AI 解决方案可以改善客户服务链的每一个步骤，从自动处理电话、创建聊天记录到提高呼叫中心代理效率和获取产品见解。这些解决方案通常是全渠道的，可以支持语音、聊天和电子邮件。还存在生成式 AI 解决方案，可以搜索您的文档存档并为用户查询提供答案。

工作流辅助

编码助手可以提高软件工程的生产力。工作流合作者可以简化许多企业功能，如审查法律合同和处理发票。

提升营销支出

数字用户活动提供了大量信号，数字营销的影响是可衡量的。这导致了许多围绕隐私安全营销分析、品牌测量、相似受众和提高活动表现的 AI 解决方案。

编写销售和市场营销内容

存在生成式 AI 解决方案来制作广告活动并帮助撰写文案。它们还可以使用替代数据集和第一方数据来为 RFP、个性化发票、销售电子邮件等提供响应。

推荐

产品和下一步行动建议已经广泛存在，这些能力作为行业特定的、易于部署的解决方案提供。

公开可用或可收集的数据

基于公开可用或可收集的数据（如社交媒体帖子、天气、网络图像、股市交易等）的能力通常可供购买。

零售

从货架管理到全渠道营销归因、需求预测和价格优化，各种能力都可以购买。

制造业

虽然设备可能各不相同，但预防/预测性维护、产量优化和质量控制等能力可供选择，并可定制。

供应链管理

从阅读海关表单到库存管理和司机路线管理等许多能力都可以购买。

医疗保健

许多阶段的制药研究，检测许多疾病和医疗条件以及医疗提供者设施的最佳利用具有相应的能力。

媒体和娱乐

许多能力，如在冰球比赛中跟踪冰球，估计高得分足球比赛的可能性，创建图像缩略图和视频亮点等，已经可用。

后勤运营

许多后勤操作可以通过自动化工作来改进。从保险申请处理到分类发票，无所不在的机器人流程自动化（RPA）解决方案。生成 AI 解决方案存在，可以使用第一方数据自动填写表单并通过 API 调用后端代理。

金融服务

多种能力，如客户互动的个性化，嵌入式金融解决方案，风险价值和“假设”分析，以及实时欺诈分析，都是可用的。

我们避免命名上述能力的示例提供者，因为在您阅读本文时，肯定会有更多选项。无论如何，在决定构建之前，请查明现成解决方案在解决您问题方面的效果如何。您可能会感到惊讶。

适应工作原理

训练最先进的图像分类模型（SOTA）需要超过 1000 万张图像。您感兴趣的用例可能没有这样大规模的数据集。

解决方案是采用在与您的类似的适当大规模数据集上训练的 SOTA 模型（通常称为预训练模型或基础模型），然后调整该 SOTA 模型以适应您的数据。您的数据可以仅为 10 张图像，包括正面和负面示例，尽管您拥有的（高质量）数据越多，模型的表现就越好。

适应是在购买和构建之间的中间选择。您既可以享受供应商的大数据集带来的好处，又可以根据自己的数据进行定制。

有两种方法可以进行这种适应：

迁移学习

这保留了原始模型的 99%以上，并调整了剩余的权重以适应您的数据。具体来说，它保留了模型中的 99%，该模型已经学会如何从数据中提取信息，然后训练剩余的 1%的模型，该模型操作提取的信息来得出结果。

微调

这保留了整个原始模型，并调整了整个模型以适应您的数据，但保持了权重更新的幅度足够小，以便原始学习的信息不会完全丢失。与直接修改权重不同，一些“低秩”生成 AI 微调方法会训练一个辅助模型，该模型调整基础模型的权重。

您可以在 TensorFlow Hub, PyTorch Hub, 和 Hugging Face 等网站上找到预训练模型，这些模型通常是用于构建像图像分类、光学字符识别和语音转文本等功能的开源模型。使用自己的数据来进行模型的微调或迁移学习。

预训练的核心 LLM（如 OpenAI GPT 和 PaLM）是为解决跨行业常见语言问题而训练的。可以对这些模型进行微调以执行特定任务，例如创建医疗程序检查单。然而，在生成式 AI 的情况下，要向模型教授新信息，需要在该行业数据上重新训练（而不仅仅是适应）模型。标记的行业特定数据集对于训练模型以准确识别医疗实体或分类医疗文本至关重要。

超大规模机器学习平台提供完全托管的体验，以适应预训练模型。例如，AutoML Translate 提供了一种方法，可以使用自己的短语对自适应谷歌翻译 API，例如行业特定语言。生成的模型可以执行谷歌翻译 API 所能做的所有翻译，同时了解您添加的行业特定术语。其他超大规模云提供商也提供类似的选项。

因此，完整的决策标准变成了：如果供应商的解决方案在同一问题上进行了训练，并且可以访问比您更多的数据，则购买供应商的解决方案。然后，考虑如果您有自己的独特数据，是否可以调整（从供应商那里学习迁移或微调）供应商的解决方案，以便执行定制任务。与将外部创建的工件整合到软件中的任何情况一样，您必须确保供应商符合您的法律要求。

您可以从云服务提供商和合作伙伴购买、适应或构建的事例总结在 Table 10-1 中。即使在撰写时这已经是一个不完整的列表，阅读时无疑会增长。在 Table 10-1 中包含技术（例如 Azure ML 计算机视觉或 AWS Lex）并不意味着对其他云中类似服务（例如 AWS Rekognition、GCP Vision API、Azure ML NLP、GCP DocAI 等）的认可。

Table 10-1. 可以购买、适应或构建的示例云能力

策略	示例 ML 能力	原因
购买 SaaS

• Amazon Forecast

• Amazon Connect

• Azure ML 计算机视觉

• GCP 零售搜索

• GCP 翻译 API

• Google 企业搜索

可以轻松集成的即插即用服务或 API。这些模型是在多样化数据集上训练的，可能比您可以组合的任何东西都要好。

购买构建块

• AWS Lex

• Amazon Polly

• AWS 上的 Hugging Face

• Azure OpenAI GPT

• GCP DocAI 表单解析器

• GCP NLP 实体提取

用作您的 ML 应用程序的构建块。为非核心业务功能重新发明轮子是不必要的吗？此外，您很少会有足够的数据来训练更好的模型。

购买企业应用程序

• AWS 预防性维护

• Azure 价格优化

• GCP 联系中心 AI

• GCP 推荐 AI

• GCP Med-PaLM

• C3 AI 收益优化

• Symphony Retail

结合产品和服务来部署和配置应用程序，以满足您组织的需求。

适应

• AWS 快速入门

• Azure OpenAI Studio

• GCP AutoML 视觉

• GCP AutoML 视频智能

• Vertex AI 微调 PaLM

在自己的任务上微调 AI 模型。在您拥有非常大的数据集之前，这些模型很可能优于仅基于您数据构建的定制模型。

构建

• AWS SageMaker

• Azure 机器学习

• GCP Vertex AI

• GCP Dialogflow

管理框架用于构建端到端的 ML 模型。这在 Chapter 11 中有详细介绍。

Table 10-1 中的策略专为不同技术技能集定制。前三种方法需要系统集成能力，而最后两种则需要数据科学家。

接下来，让我们看看一旦确定您需要的 AI 能力必须由您的团队构建时需要考虑的事项。

AI 架构

总的来说，目前有七种成功的 AI 应用类型：

理解非结构化数据

例如，您可能有一张设备的照片，并希望 ML 模型能够识别型号编号。理解图像、视频、语音和自然语言文本的内容属于这类应用的范畴。

生成非结构化数据

您可能在诉讼中接收一组文件作为“发现”，并可能需要总结收到的信息。或者您可能希望基于客户的最后五次购买创建个性化广告，将它们编织成一个故事。现在可以使用 AI 生成文本、图像、音乐和视频。

预测结果

例如，您了解购物车中物品的信息以及购物者的购买历史，希望确定购物车是否可能在没有发生购买的情况下被放弃。预测事件的发生可能性或程度属于这类应用的范畴。

预测数值

例如，您可能希望预测特定类别的商品在未来一周内在特定商店的销售数量。预测未来时间点的库存水平等时间变化数量属于这一类。预测结果与预测值的区别并不总是清晰的。在预测结果中，其他属性是事件发生的主要决定因素。在预测中，时间变化的模式是最重要的因素。有些问题您可能需要尝试两种方法。

异常检测

在许多情况下，目标是识别不寻常的事件或行为。例如，在游戏场景中，可以使用异常检测来识别作弊事件。

个性化

您可能希望基于用户和其他用户（像这个用户）过去喜欢的内容来推荐产品或制定体验。

自动化

这就是您采用机器学习来替代部分或全部目前效率低下的流程的地方。

在本节中，我们将分别讨论这些问题的经典架构和技术选择。所有这些架构都将建立在下一章讨论的平台之上。

理解非结构化数据

深度学习理解图像、视频、语音和自然语言文本内容的能力随着时间的推移而不断提高。

就在几年前，语音识别模型的能力远远落后于人类。现在，虽然不完美，语音转文本模型常用于对上传的视频和现场演讲进行字幕。所有其他类型的非结构化数据也看到了同样的改进。

深度学习不需要传统机器学习方法通常需要的特征工程步骤。因此，您可以以非常通用的方式构建深度学习系统。用于区分螺钉和钉子的 ML 模型架构也将适用于需要区分骨折骨头和完整骨头的情况。请注意，我们说的是相同的架构，而不是相同的模型。这是因为第一个示例中的模型将训练于螺钉和钉子的图像，而第二个示例中的模型将训练于断裂和完整骨头的图像。虽然架构相同，但权重会不同。

研究界已经为图像、视频、语音和文本分析中的标准问题开发并发布了模型架构。与在购买人工智能部分讨论的预构建模型不同，这些模型未经过大型数据集的训练，或者即使经过了训练，它们所训练的数据集特征与您的数据有很大不同——您将需要使用自己的数据从头开始训练这些模型。

因此，在涉及非结构化数据的问题时，通常不必设计自己的模型架构。只需选择一个最先进或接近最先进的模型，并在您的数据上进行训练。所有主要的云服务提供商都提供了便捷的机制来实现这一点。它们通常从存储在 AWS S3、Google Cloud Storage 或 Azure Blob Storage 中的非结构化数据开始。然后使用无代码或低代码服务，如 Vertex AI AutoML 来训练和部署模型（参见 图 10-2）。

图 10-2. 对于非结构化数据，使用无代码、端到端的机器学习服务，如 Google Cloud Vertex AI 中的 AutoML 或 AWS SageMaker

最困难的事情可能是为训练数据的 AutoML 模型提供标签—标签是正确答案。这可能涉及人工标注。您可以使用类似于 Amazon Mechanical Turk、SageMaker Ground Truth 或第三方提供的等效服务的众包计算服务，以避免自己进行标注的单调工作。

生成非结构化数据

生成式人工智能是一种可以创建新内容（如文本、图像、音乐和视频）的人工智能类型。它通过学习现有数据的结构（例如哪些英语单词倾向于跟随其他英语单词）然后利用这些统计知识生成逼真的新内容。在本书出版时（2023 年 10 月），生成式人工智能的架构正在快速发展中。毫无疑问，在您阅读本书时，选择会更加广泛和/或更加精简。

在撰写本文时，大多数生成式 AI 的用例涉及通过接受文本提示作为输入的 API 调用预训练模型。这被称为零样本学习。例如，通过向像 Azure OpenAI 上的 DALL-E、GCP 上的 Imagen、AWS SageMaker Jumpstart 上的 Stable Diffusion 或 Midjourney 提供文本提示，可以生成图像。同样地，您可以通过向 Vertex AI 上的 PaLM、Azure OpenAI 上的 GPT-4、AWS Bedrock 上的 Cohere 等发送自然语言请求，要求生成一篇新文章的大纲。通过不同的超大规模计算提供商（GitHub Copilot 在 Azure 上，Codey 在 Google Cloud 上，CodeWhisperer 在 AWS 上）以及像 Tabnine 和 Replit 这样的独立开发者支持，可以根据生成的代码的自然语言描述进行代码补全和代码生成。制定提示语的语言很重要，这导致提示工程成为一个实验和开发框架。在混合架构中，使用由 Perplexity AI 和 Ryax 等初创公司提供的托管 LLM。使用微服务架构来构建采用零样本学习的产品，LLM 是其中之一。虽然提示工程对于原型设计很有帮助，但模型的版本更改可能导致现有提示失败。大多数从业者通过在其控制下微调模型以用于生产用例来防范这种情况。

可以在公共云平台上使用它们的平台来对 LLM 进行微调。通常情况下，这是为了指导调优（教 LLM 新任务），以便 LLM 可以回应它目前不知道如何处理或处理得不太好的提示，或者防止断裂变化。微调是通过使用监督的参数高效方法（如 PEFT 或 SFT）对 LLM 进行几个 epochs 的训练来完成的，例如 Quantized Low-Rank Adaptation（QLoRA）。您可以通过它们提供的服务对专有模型进行微调，例如 OpenAI GPT-4 和 Google Cloud PaLM，以及在 PaaS ML 平台（如 SageMaker、Databricks 和 Vertex AI）上对开放性 LLM（如 Falcon、Dolly 和 Llama 2）进行微调。¹ 开源模型中心（如 Hugging Face）越来越受欢迎，作为抽象出必要代码的一种方式。部署微调的 LLM 作为 ML 平台上的 API，就像您处理任何其他 ML 模型一样。

调节指令可以教会模型新的任务，但不能教会新的知识（在撰写本文时，这需要从头开始重新训练模型，使用新数据）。为了便宜地教导 LLM 学习新知识，通常会利用一些模式，这些模式利用 LLM 在少量示例（few-shot learning）中解决新任务的能力，利用嵌入到提示中的信息（retrieval-augmented generation），或者生成结构化数据以供传递到外部 API（agents）。例如，要回答问题，会将问题或其假设答案的嵌入搜索到文档块的向量数据库中，以找到相关文档，并要求 LLM 总结这些文档块来回答提出的问题（参见 图 10-3）。开源抽象层（如 LangChain）正变得流行，用来实现这些模式。在这样的设计中，每个链条步骤都是 ML 管道中的一个容器。容器化的 ML 管道将在下一章讨论。

图 10-3. 检索增强生成架构，用于使用 LLM 回答问题的模式

预测结果

将作为预测结果的历史数据通常存在于日志数据和交易数据库中。例如，如果您想预测购物车是否会被放弃，您必须获取所有网站活动的历史记录—这些信息通常存在于日志数据中。您可能选择包括商品价格、优惠信息以及客户是否实际支付商品等信息。虽然这些数据的一部分或全部也可能从网站日志中检索，但从数据库中查询可能更为简单。因此，在这种情况下，历史数据也包含标签（参见 图 10-4）。

图 10-4. 预测结果模型通常涉及训练模型，根据 DWH 中其他列的值预测其中一列的值

因此，该架构（参见图 10-5）涉及使用复制机制和连接器将所有必要的数据引入数据仓库。然后可以直接在数据仓库上训练回归或分类 ML 模型——Amazon Redshift 和 Google BigQuery 都支持直接从 SQL 训练模型，并将更复杂的模型推迟到 SageMaker 和 Vertex AI 的底层。一旦训练完成，模型可以导出并部署到两个云上的托管预测服务中。通常，所有预测结果或至少其中一部分将存储回数据仓库，以支持持续评估和漂移检测。

图 10-5. 建模、部署和监控结果预测模型的架构

只要有足够的新数据或者连续评估确定模型或其特征已漂移，就会重新启动训练。此评估通过将预测与事后获得的真实值进行比较来进行。例如，可以将预测的购物车是否被放弃与一天后实际放弃的购物车进行比较。评估查询定期通过调度程序执行。

预测数值

大多数 ML 模型进行推理——它们基于其他因素“预测”未观察到的值。例如，ML 模型可能根据交易金额和信用卡使用地点等因素预测交易是否欺诈。关键在于输入因素不包括要预测的事物（欺诈）的过去值（见图 10-6）。

相反，在预测问题中，ML 模型的输入之一是要预测的事物的先前值。例如，如果您试图预测未来 3 天将销售的三明治数量，则其中一个输入可能是过去 28 天中每天销售的三明治数量。

图 10-6. 推理与时间序列预测

请注意，在本质上，预测问题要求您反馈过去预测的实际情况。这种实时反馈循环使得数据工程架构变得更加复杂。一个方法如图 10-7 所示。在这里，训练是在数据仓库中的历史数据上进行的，使用 SQL 中的窗口收集数据。这些查询将数据分区为包含当前行和一定数量前导行的段：

WINDOW fourweek_window AS
    (PARTITION BY store_id, sandwich_id
    ORDER BY purchase_date ASC ROWS 27 PRECEDING)

图 10-7. 具有分离批处理和流处理管道的时间序列分析架构

然而，在实时情况下，时间窗口需要在流式处理管道中进行。流处理管道提取过去 28 天的数据并将其发送到预测模型进行预测。它还负责保持数据仓库的更新，以便下一次训练运行基于最新的数据。这种方法的问题在于需要维护两个数据管道：一个基于历史数据进行训练的批处理管道和一个基于实时数据进行预测的流处理管道。

更好的方法是使用数据管道框架（如 Apache Beam），它提供了在批处理和流处理数据集上执行相同代码的方式。这限制了由于训练与预测时的不同预处理步骤导致的训练服务偏差。这样的架构如 图 10-8 所示。

图 10-8. 使用数据管道技术（例如支持批处理和流处理的 Apache Beam）的架构

异常检测

在时变数据的异常检测中，有两个时间窗口。较长的时间窗口（比如一个月）内的数据被聚类。然后，较短时间窗口内的数据与这些聚类进行比较。如果较短时间窗口内的数据与较大数据（即新数据与聚类之间的距离较大）不同，则会标记异常。

此处的架构与 图 10-8 中描绘的预测情况类似，只是需要维护两个时间窗口。确保所选择的流处理管道基础设施（如 Cloud Dataflow、AWS Kinesis、Apache Flink 或 Confluent Kafka）能够满足您需要的时间窗口长度要求。

在个体事件的异常检测中，原则是相同的，只是第二个（较短时间）窗口由单个事件或用户会话组成。因此，过去一个月内的事件被聚合以学习正常事件的模式。从分布中的离群值被视为异常。例如，如果目标是识别多人游戏中的机器人，将收集和聚合玩家的典型行为（移动间隔时间、重复移动的可能性、后续移动涉及不同手的可能性等）。任何明显偏离整体分布的玩家都会被标记。

个性化

机器学习最常见的用途之一是根据个体的需求定制体验（如游戏）、产品（如音乐播放列表）、服务（如垃圾邮件过滤器）或通讯（如销售外呼）。在尊重用户隐私的前提下进行此类操作需要对数据保密性和安全性做一些基本保证，包括信息是否会从一个用户泄露到另一个用户。

这种定制需要了解不仅特定个体的偏好，还有像进行个性化的用户一样的个体的偏好（例如，营销漏斗中下一步最佳行动）。定制还将尝试突出显示与该个体过去喜欢或积极反应的项目类似的项目。因此，个体的人口统计信息（表现为客户细分，例如“单身，20 多岁，城市，非订阅者”）和项目的特征（例如价格，发布日期等）是个性化机器学习模型的关键特征（见图 10-9）。给定一个人-项目对，个性化模型计算个体对该项目的兴趣程度得分。从候选项目列表开始（例如所有符合用户搜索查询的项目或所有正在进行的促销活动），个性化模型因此能够按照捕捉用户偏好的方式对项目进行排名。

一个好的个性化模型还需要处理冷启动问题——如果有一个新用户，仍然需要为他们提供一个合理的体验；如果有一个新项目，仍然需要模型向某些客户推荐该项目。冷启动问题通常作为预处理步骤处理，寻找历史不足的用户或项目，并为他们提供一个合理的体验（例如，推荐最流行的项目而不是不太流行的项目）。

图 10-9. 仅涉及少量潜在选择的个性化架构；部署的模型是一个包括处理冷启动和修剪最近购买的流水线的一部分。

个性化模型通常需要对推荐结果进行一些后处理。例如，如果用户刚在您的视频流服务中观看了《肖申克的救赎》，您可能不希望再次推荐同一部电影。后处理包括这类规则，用于修剪自动生成的推荐列表。

图 10-9 所示的架构与结果预测（在图 10-5 中描述）的架构相同，只是需要额外的预处理和后处理过滤器。因此，该模型被部署为一个流水线。预处理步骤要求使用统计模型（例如，最流行的项目）来创建一个可以在冷启动情况下使用的模型。后处理步骤要求过滤掉最近的购买，并且需要连接到实时事务数据库。

在图 10-9 中的架构在候选项数量过大时会崩溃。例如，当您访问 YouTube 首页时，会呈现一组推荐视频。该列表的候选空间是整个 YouTube 目录。在您访问网页时对整个目录进行排名是不可行的。因此，当候选列表较大时，架构包括一个批处理管道，为每个用户预先计算出较小的候选推荐列表。此批处理管道运行的频率可能根据用户的活跃程度而变化，并且这些预计算的候选项可以通过流行话题进行补充，以确保体验不会过时。这在图 10-10 中有所体现。

图 10-10. 当候选总空间较大时，通过预定的批处理管道预先计算出较小的候选列表。

现在让我们来看看最后一种 AI 应用类型：自动化。

自动化

与个性化类似，后台流程的自动化需要多个模型以及前后处理过滤器。每个模型都必须基于自己的数据进行训练，并且部署的管道是作为有向无环图（DAG）调用的 ML 模型。

ML 模型本身可能并非全部从头开始训练。构建块模型（如表单解析器、翻译工具等）是这些自动化模型管道的常见组件。

通常，在自动化管道中，模型对高置信度预测的决策是自动执行的，但也考虑到人类监督，如图 10-11 所示。例如，会将一小部分高置信度预测发送给人类专家进行持续验证。这被称为人在循环中。此外，涉及昂贵、低置信度或难以逆转的决策也需要人类批准。这被称为人在环中。这两者都非常重要。

任何模型的高价值预测结果都会被传递到 ML 管道的下一步骤。如果任何模型的低置信度预测结果，输入会被发送到队列进行人工处理。自动化管道的一个关键组成部分是标记——必须捕获和处理这些低置信度预测的人类决策作为标签。一旦标记，这些数据就会添加到训练数据中，并用于后续的重新训练。

图 10-11. 自动化管道由多个 ML 模型链式连接而成。

根据其类型（例如 AutoML、预建 API 或定制模型），机器学习模型将被训练和部署。模型集成到管道中，并在诸如 Kubeflow Pipelines 等系统中进行编排，这些系统在公共云中存在托管服务。队列可以是任何分布式任务队列：AWS Simple Queue Service、Google Cloud Pub/Sub 等。训练数据将存储在云对象存储或数据仓库中，具体取决于数据是结构化的还是非结构化的。

负责任的 AI

由于机器学习是如此强大的工具，您必须小心不要滥用它。请意识到您的组织和政府的政策和法规。例如，考虑这样一个用例：您希望减少人们等待电梯的时间。因此，您想自动识别走进大厦大堂的人，并利用您对他们的办公室楼层的了解。这样，您可以最优化地引导个人进入电梯，以最小化停止次数。在许多司法管辖区中，这种用例可能违反隐私法规，因为拍摄和追踪人员可能是被禁止的。

由于机器学习模型永远不完美，您在决策完全自动化且无人干预的情况下使用机器学习时必须小心。著名的 Zillow 在建立过多库存后不得不 关闭其自动购房模型 ——房屋被低估的人不会卖给 Zillow，但被高估的人会急于出售。

注意

欲深入了解这些概念，请参考 负责任的机器学习，作者为 Patrick Hall、Navdeep Gill 和 Benjamin Cox（O’Reilly）。

AI 原则

您的组织可能已经为 AI 的使用和不使用设立了原则。例如，这些是 Microsoft 的 AI 原则。

公平性

AI 系统应该公平对待所有人。

可靠性和安全性

AI 系统应该可靠且安全运行。

隐私和安全

AI 系统应该安全并尊重隐私。

包容性

AI 系统应该赋予每个人力量并与人们互动。

透明度

AI 系统应该易于理解。

责任

人们应对 AI 系统负责。

Microsoft 的负责任 AI 工具箱是一组集成工具和功能，旨在支持开发人员负责任地使用 AI。该公司还帮助创建了一个名为 ToxiGen 的数据集，以帮助机器学习从业者检测针对多个少数群体的毒性。

另一个例子是 Google 的 AI 原则，它们如何推动或限制 Google 在其产品中使用 AI：

社会效益

例如，谷歌地图利用 AI 建议最环保的路线。谷歌估计，环保路线有潜力每年减少超过一百万吨碳排放，这显然是社会的一个好处。

避免创建或加强偏见。

2021 年 2 月，谷歌云的视觉 API 停止附加性别标签如“男性”或“女性”。问题在于自动识别性别会导致创造或延续偏见的用例。

为安全而建造和测试。

Waymo，谷歌的自动驾驶汽车项目，在向公众开放其完全自动驾驶的乘车服务时分享了其安全框架。

对人们负责。

例如，即使谷歌 Nest 学习恒温器可以学习用户的日常活动并自动创建温度时间表，用户也可以关闭自动调度功能。

结合隐私设计原则。

为了减少谷歌助手在设备误听用户说“Hey Google”时的误触发，设备上的模型被调整到与该设备的用户相适应。然而，这使用了联邦学习，这是一种增强隐私的技术，可以在不将用户原始数据发送到谷歌服务器的情况下工作。

维护高科学卓越标准。

谷歌在知名科学会议上发表了许多作品，例如Neu⁠r­IPS。通过使在机器学习领域工作的工程师在同行评议的期刊上发表成果成为其角色的关键部分，谷歌促进了高科学标准。

应该提供符合这些原则的用途。

谷歌将 AI 技术作为开源（例如 TensorFlow、BERT 等）和通过谷歌云（Vertex AI、Retail Search 等）提供。

如果技术可能会造成整体伤害，则不要设计或部署 AI。

例如，如果其主要目的是作为伤害人员的武器、进行监视或违反人权的 AI，则不要设计或部署。例如，2020 年，谷歌云 CEO 表示，公司已从美国海关和边境保护局获得确认，其技术不会用于边境的移民执法。

虽然谷歌或微软的原则可能不适合贵公司的使命和目标（例如，如果您在国防行业工作，则最后一个原则肯定不适用），在着手新的 AI 项目之前，请与您的 AI 治理委员会核实，并检查最近的法规变化，因为它们经常更新。

机器学习公平性

您还必须谨慎使用训练 ML 模型的历史数据，这些模型做出会影响人们的不可逆决策，因为 ML 模型会吸收历史数据中固有的偏见。例如，考虑到是否负责使用基于以前监禁时长历史数据的 ML 模型，来推荐今天犯罪被判者的监禁时长。如果现实生活中的检察官和法官倾向于对少数族裔持有偏见，ML 模型会吸收到这种偏见 — 即使种族并不是 ML 模型的显式输入，也可以基于被判人所在地或其被指控的犯罪而隐含地捕捉到。这并不是一个容易解决的问题 — 您可以考虑的几乎所有公平措施（不使用受保护属性，实现分类平等，或者独立于受保护属性的校准结果）都可能存在问题。

云 ML 框架中有多种工具可用于帮助诊断 ML 公平性问题。例如，可以进行切片评估，进行假设测试，并持续监控模型在受保护标准上的表现。

可解释性

经常，利益相关者（最终用户、监管者）会拒绝采纳 ML 模型，除非他们能够得到模型作出推荐的原因的某些指示。很少有医生会接受一个仅仅告诉是否有骨折的自动化 X 光模型，而没有任何其他解释。很少有监管者会接受银行保证其在贷款批准中不会歧视，除非银行能够解释其贷款决策背后的理由。解释性对于向非专业人士解释模型工作原理及其固有风险，并建立社会对自动驾驶汽车等技术的接受度也很重要。这在组织培训中也是如此，因为公司内的每个人，从营销到销售再到数据团队，都必须理解模型如何根据可用数据做出推荐。

云 ML 框架提供了可解释 AI（XAI）工具，可以帮助您理解 ML 模型如何做出决策。这并不是对 AI 模型的完整逐步分解，如果尝试追溯深度学习算法中使用的数百万参数几乎是不可能的。相反，XAI 旨在提供关于模型工作方式的洞见，使人类专家能够理解做出决策的逻辑。

成功应用时，XAI 提供三个重要好处：

增强对 ML 模型的信任

可解释性工具（XAI）可以用来提供清晰易懂的解释，说明了模型输出的推理过程。假设您正在使用深度学习模型来分析医学图像，如 X 光片；您可以使用 XAI 生成显著性地图，突出显示用于进行诊断的像素。

提供了一种解决机器学习问题的方法

AI 的可解释性还可以帮助您调试模型并排查模型运行情况。What-If 工具允许您更改模型输入的一个变量，并查看在那种情况下模型会做出什么样的预测。

识别公平性问题

例如，您可能有一个模型用于识别汽车何时进行非法左转。解释可能会建议，与其集中于汽车非法左转，模型更可能是在寻找是否有坑洞。这种影响可能是由一个包含大量在道路维护不良地区拍摄的图像的倾斜数据集引起的，甚至是真实的偏见，即在城市中的资金不足地区可能更有可能被处以罚款。

云 ML 框架在开发过程中提供 XAI 支持，作为笔记本开发体验的一部分。例如，What-If 工具已集成到 Vertex AI Workbench 中。它们还为部署的模型提供 XAI 支持，以便模型预测可以附带解释。显著性地图已集成到 Vertex AI Predictions 中。由于 Google 的 What-If 工具是开源的，因此它也可以从其他云上的笔记本中使用。Azure 机器学习和 AWS SageMaker 与 Vertex AI Predictions 一样，提供了解释预测的支持。

摘要

本章为您提供了一个关于如何有效地将 AI 和 ML 应用到您的数据平台边界中的最相关事项的概述。关键要点如下：

• AI 是通过使计算机像人类一样思考和行动来解决问题的研究领域。

• 机器学习是使用数据而不是定制逻辑解决 AI 问题的 AI 的一个子领域。

• 深度学习是机器学习的一个子领域，成功应用于理解语音、图像、视频和自然语言等非结构化数据。

• 生成式 AI 可以用来创建非结构化数据。

• 生成模型可以用来生成文本、图像、音乐和视频。它们通常作为 API 被调用，接受文本提示作为输入。

• 可以对大型模型进行微调，使它们执行它们原本未经训练的任务。这通常是以 QLoRA 等方法进行的参数高效方式。

• 可以使用检索增强生成和少样本学习等模式来让生成模型学习新信息。

• ML 最引人注目的用例通常出现在以下情况中：重复决策、标记数据、容错使用案例、难以表达的逻辑和非结构化数据。

• 如果供应商有一个解决您想解决的问题的解决方案，并且他们拥有更多的数据，那么您应该购买它。如果没有，就自己构建。第三个选择是根据您的数据调整解决方案。

• 您可以购买 AI 能力的三个抽象级别：SaaS、构建块和企业应用程序。购买 SaaS 以获取易于集成的即插即用服务或 API。购买构建块，例如用于 ML 应用程序的表单解析器。企业应用程序可以配置以满足您组织的需求。

• 通过迁移学习或微调来适应预建的 ML 模型。在您达到非常大的数据集之前，这些方法可能会胜过仅基于您的数据构建的自定义模型。

• 使用 AWS SageMaker、GCP Vertex AI 和 Azure Machine Learning 构建端到端 ML 模型。这将在接下来的章节中进行介绍。

• 处理涉及非结构化数据的问题时，通常不需要设计自己的模型架构。可以使用无代码或低代码服务，例如 Vertex AI AutoML 来训练和部署模型。

• 在预测结果时，使用 SQL 在您的 DWH 内训练 ML 模型。在 DWH 内执行批量预测。对于在线预测，将训练过的模型部署到托管的 ML 服务中。

• 解决预测问题的最佳方法是使用数据管道框架，例如 Apache Beam，在批处理和流数据集上执行相同代码的方法。

• 异常检测的架构与预测案例类似，但需要维护两个时间窗口。

• 在个性化方面，部署的模型是管道的一部分，该管道还包括处理冷启动和修剪最近购买的操作。当候选者的总体空间很大时，将使用定期批处理管道预先计算较小的候选者列表。

• 自动化管道由许多串联的 ML 模型组成。通常包括一个人在循环中验证一部分预测结果，一个人在循环中对低置信度预测结果做出决策，并且有一种方法来捕获人类决策以进行后续重新训练。

• 因为 ML 是如此强大的工具，我们必须小心不要滥用它。在启动新的 AI 项目之前，请与您的 AI 治理委员会或法律顾问核实。

• 切片评估、假设测试和对受保护标准进行模型性能的持续监控是追踪 ML 公平性的方式。

• 云 ML 框架提供 XAI 工具，提供有关模型工作原理的洞察，以便人类专家能够理解决策背后的逻辑。

在下一章中，您将学习如何支持自定义 ML 模型的开发和部署。我们将涵盖各种开发阶段和支持这种活动的框架。

¹ 研究人员指出，这些 LLM（大语言模型）并非真正开源。但它们允许您在商业应用中进行精细调整和部署，没有太多限制。

第十一章：设计一个 ML 平台

在上一章中，我们讨论了 ML 应用程序的整体架构，并且在许多情况下，您将使用预先构建的 ML 模型。在某些情况下，您的团队将不得不开发 ML 模型，这是 ML 应用程序的核心。

在本章中，您将深入探讨开发和部署此类定制 ML 模型。您将查看 ML 模型开发的各个阶段和支持此类开发的框架。在模型创建后，您需要通过查看可以帮助您实现这一过渡的工具和产品来自动化训练过程。最后，您需要监控已部署到端点的训练模型的行为，以查看它们在进行推断时是否存在漂移。

在前几章中，我们讨论了数据平台各部分所能提供的 ML 能力。具体来说，你的 ML 平台的数据存储可以在数据湖中（第五章）或 DWH 中（第六章），训练会在适合该存储的计算资源上进行，推断可以从流水线中调用（第八章）或部署到边缘上（第九章）。在本章中，我们将总结所有这些讨论，并考虑这些 ML 能力的具体内容。

ML 活动

如果你正在构建一个支持自定义 ML 模型开发的 ML 平台，你需要支持哪些活动呢？我们经常看到架构师直接跳到 ML 框架（“我们需要支持 XGBoost 和 PyTorch，因为这是我的数据科学家使用的”），而没有考虑数据科学家和 ML 工程师在平台上需要做的许多活动。

典型情况下，ML 平台必须支持图 11-1 中的活动。

图 11-1：ML 平台需要支持的活动

你需要清洁和处理原始数据，使其更适合 ML，并使得最终训练出来的模型更加准确。数据准备需要进行探索性数据分析来检查数据，绘制其分布，并研究其细微差别。然后，ML 模型会在数据的一个子集上进行训练，并使用另一个子集进行评估。基于此，数据科学家将对数据准备或建模步骤进行更改。这个过程是迭代的，通常涉及大量的实验。

模型训练完成后，您需要对其进行测试数据评估，检查其符合性和性能，然后将其部署到一个端点。ML 模型的客户端随后可以向端点发送预测请求。

经过训练的模型不会永远保持合适。环境通常会发生变化，随着时间的推移，模型开始变得不太准确。因此，您必须自动化模型训练和部署步骤，以确保您的模型始终保持最新和准确。

此外，您必须仔细而持续地监控模型（以确保它处理传入的预测请求），评估它（以确保预测保持准确，特征没有漂移），并在检测到新的训练数据、新代码或模型漂移时重新训练它。

让我们看看如何设计一个 ML 平台来支持所有这些活动。

开发 ML 模型

开发 ML 模型涉及迭代开发，包括：

• 为 ML 准备数据

• 编写 ML 模型代码

• 在准备好的数据上运行 ML 模型代码

为了支持这些步骤，您的数据科学家需要一个 ML 开发环境。

标记环境

要开发自定义 ML 模型，您需要拥有将用于训练模型的数据。假设所需数据已被收集并存储在 DWH 或数据湖中。

在监督学习的情况下，训练数据需要有标签或正确答案。在某些情况下，这些标签可能自然存在于数据中，而在其他情况下，您需要使用人工专家来标记数据。通常情况下，这些工具是外包的，而不是由数据科学团队自己完成，但值得询问的是，ML 平台是否需要支持标签应用程序。

开发环境

由于 ML 开发过程如此迭代，数据科学家在能够编写代码、运行代码、查看结果、立即更改代码并重新运行代码的环境中最具生产力。数据科学家需要能够在小片段中执行其代码，而不需要重新运行整个程序。代码及其输出存储在一个称为笔记本的文档中，正如我们在“使用笔记本进行交互式分析”中预期的那样。笔记本将由 Web 浏览器呈现，这是用户访问笔记本的方式。笔记本中的代码由称为笔记本服务器的软件执行（请参见图 11-2）。笔记本服务器软件安装在云 VM 上，并通过托管笔记本服务（如 SageMaker、Databricks、Vertex AI Workbench 或 Azure Machine Learning）来管理其生命周期。

图 11-2. 笔记本电脑的高级架构

正如您在之前章节中已经了解到的，Jupyter Notebook 已经成为数据科学开发的事实标准，因为它支持这种交互式工作流程。在所有主要的云提供商上都存在运行 Jupyter Notebook 服务器的托管服务。这些服务通常预安装必要的统计和 ML 软件框架，并提供在启用 GPU 的机器上进行数学计算加速的能力。

笔记本服务也作为云无关数据框架的一部分提供，例如 Databricks，几乎在所有主要云上的工作方式相同。Google Colab 提供免费的托管笔记本，但这些笔记本有时间和硬件限制。这些限制在专业版 Colab 中也有所解除。最后，还有领域特定的托管笔记本，如 Terra.bio——这些笔记本添加了生物学特定的库和可视化功能到通用笔记本中。

随着基于生成 AI 的编程助手工具（例如 Replit、GitHub Copilot 和 Google Codey）被整合到 Colab 和 Jupyter 等笔记本服务中，事情可能会发生显著变化。在撰写本文时，很难预测未来会发生什么，但 AI 助理很可能大大简化和简化软件开发。

用户环境

典型的方法是笔记本由用户管理。本质上，您将 Jupyter 运行的 VM 视为数据科学家的工作站。没有其他人能够登录到该工作站。数据科学家将大部分工作时间花费在其中。笔记本文件存放在版本控制下，版本控制系统（例如 GitLab 或 GitHub）提供项目的协作一致的团队视图。

用户管理的笔记本实例让数据科学家以可审计的简单方式访问云数据和 ML 服务。

当数据科学家需要存储数据时，必须以所有合作者都可以访问的方式存储数据。数据不像传统工作站中的本地数据，而是存储在数据仓库（DWH）或对象存储中，并且根据需要动态读取。在某些情况下，将数据副本下载到足够大的本地磁盘可能会有所帮助。

在许多情况下，数据科学家处理机密数据或包含隐私敏感信息的数据。因此，通常将托管的笔记本服务和数据源放置在较高的信任边界内，例如虚拟专用云（VPC），如图 11-3 所示。这样的架构有助于减少数据科学家数据外泄的风险，保护笔记本实例免受外部网络流量的影响，并限制访问托管笔记本服务器的虚拟机。

图 11-3. 使用更高的信任边界来包括笔记本服务器、数据密钥和训练数据。

确保在为数据科学家提供访问权限时使用细粒度访问控制，例如列级/行级安全性。数据所有者应确保数据科学家尽可能访问经过编辑或标记化的数据集。将加密边界应用于所有数据集，并通过云密钥管理服务管理这些密钥。这确保在读取任何数据之前需要加密密钥，并且密钥管理团队与数据所有者保持分离。

数据科学家在处理非结构化数据训练深度学习模型时需要带 GPU 的虚拟机。如果为每位数据科学家提供独立的托管笔记本实例，成本可能会成为一个问题。作为第一步，确保设置托管服务的功能，以便在虚拟机未被使用一段时间后自动暂停或停止。

对于大型团队（超过 50 名数据科学家），停止空闲实例可能不足以进行充分的成本优化。您希望多个用户共享相同的硬件，以便跨这些用户分摊计算能力。在这种情况下，架构涉及在 Kubernetes 集群上运行笔记本服务器，而不是在虚拟机上（JupyterHub 支持此功能），然后从同一集群向多个用户提供笔记本。由于这种架构是多租户的，使安全考虑变得更加困难。请考虑成本节约是否值得增加的安全风险。

数据准备

许多机器学习项目的第一步是从源系统（通常是 DWH 或关系数据库）中提取数据，预处理/清理数据，并将其转换为优化用于机器学习训练的格式（如 TensorFlow Records）。生成的机器学习数据存储在对象存储服务中，以便从笔记本轻松访问。

例如，许多图像分类模型架构要求所有图像具有相同的尺寸。在数据准备步骤中，可以执行裁剪或调整图像大小以符合所需尺寸。类似地，在文本模型中，输入文本单词和句子必须转换为数值表示。通常通过将大型模型（例如 BERT、GPT-3）应用于单词或句子来获得一批数字。

此时，数据科学家视觉检查数据至关重要。Jupyter 环境中包含常见的绘图库。如果有工具可以让数据科学家更轻松地完成这项工作（例如，视频渲染软件或特定领域的框架和库），请确保在 Jupyter 虚拟机上安装它们。

在视觉检查期间，数据科学家将发现需要校正或丢弃数据的情况。可以对数据集进行这些更改并创建新数据集，也可以将这些更改添加到读取数据的软件中。如果这些数据在预测期间提供，则更常见的是在软件中进行清理，因为这样可以提供一种一致的处理方式。

接下来，通常会将数据分成子集。一个子集用于训练，另一个子集用于确保模型不过拟合。有时，还会保留第三个子集进行最终评估。

数据科学家可以通过多种方式从源系统读取数据，过滤掉不良值，转换数据，并将其分成子集。在数据仓库（DWH）中使用 SQL 进行数据准备通常是处理结构化数据的便捷选择。然而，在 SQL 中进行统计处理存在一定的局限性。因此，数据处理通常会使用 pandas——虽然 pandas 适用于小数据集，但处理大量数据时，您需要像 Dask、Apache Spark 或 Apache Beam 这样的框架。因此，需要在高信任边界内使用云管理服务来运行 Dask、Spark 或 Beam。

所有这些活动都应与业务协调进行，以清晰了解组织的目标，并确保在准备阶段保留正确的信息。

训练 ML 模型

数据科学家将在 Jupyter 笔记本中编写模型代码，使用诸如 scikit-learn、XGBoost、Keras/TensorFlow 或 PyTorch 等框架。然后，他们将多次执行模型代码，通过训练数据集确定模型的最优权重。

编写 ML 代码

代码通常会以小批量读取训练数据，并通过训练循环来调整权重。读取数据的数据管道可能会进行数据增强，例如翻转图像以人工增加数据集的大小。模型架构将与读取的输入及其转换方式紧密相关。数据科学家通常会尝试许多选项来表示数据，许多类型的模型以及许多优化方法。¹

模型代码是迭代开发的，因此与云端的低延迟连接和快速周转时间能力至关重要。在不必重新运行整个训练程序的情况下尝试对代码进行小的更改非常重要。编写代码通常不是使用托管训练服务的时候——在此阶段，数据科学家使用本地环境中的笔记本。

在大型数据集上进行交互式开发会导致不必要的延迟。为了加快开发速度，提供一个可以下载到笔记本虚拟机的大型数据集样本可能会很有用。在涉及涉及隐私敏感数据的情况下，样本可能必须由模拟/合成数据组成。

一旦代码开发完毕，数据科学家通常希望在整个数据集上运行训练作业。他们是否可以在笔记本中这样做取决于数据集的大小以及笔记本服务器的 VM 的功能。

小规模工作

对于小数据集和简单模型，训练运行时间可以在一小时内完成，可以在笔记本本身提供运行训练作业的能力。

托管笔记本服务提供给数据科学家改变笔记本运行的机器类型的能力，使其更加强大—这可以通过切换到附有 GPU 或 TPU 的机器来完成。这将为在中等规模数据集上训练模型提供必要的计算能力。

对于更大的数据集和/或复杂模型或者训练运行时间超过一小时的情况，最好使用托管训练服务。可以将笔记本提交到像 SageMaker 或 Vertex AI 这样的托管训练服务，使笔记本完全执行，并在几个小时后收到更新的笔记本。

分布式训练

对于非常大的数据集，简单地升级到更强大的计算机是不够的。您将不得不在一组以特殊方式相互通信的机器上运行训练作业的集群中运行训练作业。基本上，每个训练示例的批次被分布在集群中的机器上，每个机器对其批次的子集进行数学计算，并使用中间计算来确定匹配的实际结果。TensorFlow 和 PyTorch 等框架支持分布式训练，但必须以特定方式设置集群。

要在笔记本中获取代码的分布式训练，需要在适当配置的集群上运行笔记本服务器（例如，在 Kubeflow 集群上的 JupyterHub）。除非这是您创建的用户环境，否则这种更改并不迅速。

更好的选择是跳到讨论的自动化步骤“自动化”并使用托管训练框架。

无代码机器学习

定制模型并不总是需要在 TensorFlow、PyTorch 等中进行编码。存在低代码和无代码选项。例如，可以使用云控制台或创建和部署 AutoML 模型。Dataiku 和 DataRobot 等工具提供了完全的点对点方式来训练和部署模型。

无代码 ML 模型的能力继续变得越来越好。对于非结构化数据（图像、视频、文本），很难找到比现有的 AutoML 选项更好的解决方案。对于图像，您可以使用 AutoML 进行分类、分割，甚至根据文本提示生成图像。对于文本，您可以使用它来解析表单、提取实体、检测情感、总结文档和回答问题。

在所有这些情况下，您可以将 AutoML 生成的模型视为可以像由数据科学团队编写的模型一样部署的自定义模型。

部署 ML 模型

如第十章所讨论的，批量预测用于定期评分大量数据，而在线预测用于近实时数据评分。

如果只进行批量预测，可以直接使用来自大规模数据处理框架（如 Spark、Beam 和 Flink）的训练模型文件。您无需部署该模型。某些数据仓库（如 BigQuery）允许您在 Cloud Storage 上提供训练好的 TensorFlow 模型进行批量预测。

要将模型用于在线预测，您需要将其部署为服务环境中的微服务。主要的云 ML 框架（Vertex AI、SageMaker、Azure Machine Learning）具有类似的概念，并支持在线预测的类似功能。

部署到端点

客户通过与其关联的 URL 访问端点（见图 11-4）。客户端发送带有 JSON 负载的 HTTP POST 请求，其中包含预测方法的输入。端点包含多个模型对象，其中它分割流量。在图 11-4 中，80%的流量流向模型 1，10%流向模型 2，其余流向模型 3。该模型是一个引用在各种框架（TensorFlow、PyTorch、XGBoost 等）中构建的 ML 模型的对象。每个框架都有预构建的容器映像。在 TensorFlow 的情况下，容器映像寻找 SavedModel 文件，这是 Keras/TensorFlow 2.0 模型默认导出的格式。

图 11-4. 将训练好的模型部署到端点

端点由一个自动扩展服务支持，可以处理流量的变化。然而，选择足够大的机器以支持几个同时的请求是机器学习工程师的责任，可以通过测量来实现计算的加速。运行具有加速器（如 GPU 或可编程门阵列[FPGA]）的机器上的端点可以加快计算速度。如果使用大型模型（如文本模型），可能需要确保机器有足够的内存。由于自动扩展可能会引入不可接受的延迟，因为新机器可能需要一些时间上线，因此确保有一个有一定数量最小机器的热池可能会有所帮助。

评估模型

将多个模型部署到一个端点的原因是为了让机器学习工程师能够控制向它们的流量分配。这是因为机器学习平台需要允许对模型进行 A/B 测试，以便机器学习工程师可以决定是否用新开发的模型替换当前的生产模型。

机器学习托管服务提供了监控资源使用情况的能力，确保部署的模型能够跟得上输入请求。可以将输入的样本及其对应的预测发送到数据仓库，并用来比较不同模型版本的性能。

混合和多云

由于数据传输成本高昂，还增加了治理和安全考虑因素，通常会选择在大部分历史数据存储的云端训练机器学习模型。另一方面，为了最小化网络延迟，需要将模型部署到应用程序运行的云端（或边缘）。在图 11-5 中，您可以看到在一个云端（存储您的数据的地方）进行训练，然后在另一个云端（运行您的应用程序的地方）部署的示例。为了进行这样的混合训练和部署，使用标准模型格式（如 TensorFlow SavedModel、ONNX 或.bst文件）和容器。

图 11-5. 可以在一个云上训练机器学习模型并在另一个云上部署它们

在构建机器学习平台时，能够脱离云端运行推断是一个重要的考虑因素。选择那些不依赖专有实现的框架。

训练-服务偏差

机器学习中的主要挑战之一是训练-服务偏差。当机器学习模型在预处理数据上训练时，需要对传入的预测请求执行相同的步骤。这是因为需要向模型提供与其训练数据具有相同特征的数据。如果不这样做，训练和服务之间会存在偏差，模型的预测结果将不会很好。

有三种方法可以确保在训练期间进行的预处理在预测期间按原样重复进行：将预处理代码放入模型内部、使用转换函数或使用特征存储。让我们逐一讨论它们。

在模型内部

最简单的选择是，如图 11-6 所示，将预处理步骤整合到模型函数中。例如，在 Keras 中可以通过 Lambda 层进行预处理。这样，在保存模型时，预处理步骤将自动成为模型的一部分。

图 11-6. 将预处理代码整合到模型函数中

这种方法的优点在于简单性。不需要额外的基础设施。预处理代码与模型一起传递。因此，如果需要在边缘或其他云中部署模型，无需特别操作。SavedModel 格式包含所有必要的信息。

该方法的缺点是，预处理步骤将在每次对训练数据集进行迭代时被浪费地重复执行。计算量越大，这种重复执行的成本就越高。

另一个缺点是，数据科学家必须在与 ML 模型相同的框架中实现预处理代码。因此，例如，如果使用 PyTorch 编写模型，则预处理也必须使用 PyTorch。如果预处理代码使用自定义库，这可能会变得困难。

转换函数

正如您所理解的，将预处理代码放在模型函数内部的主要缺点是，代码需要在模型训练过程的每次迭代中用于转换原始数据，并且必须使用与训练代码相同的语言。

如果您捕获预处理步骤并将其应用于原始数据，则可以优化此过程。然后，可以在预处理数据上进行模型训练，从而更加高效。当然，您必须确保从训练和预测代码中调用该函数（参见图 11-7）。或者，您可以捕获预处理步骤并将其封装到容器中，在输入和模型之间插入该容器。虽然这会增加效率，但也会增加复杂性——您必须确保将转换函数保存为与模型关联的工件，并知道要调用哪个转换函数。

图 11-7. 将预处理代码封装到转换函数中，该函数应用于原始数据集和预测请求

TensorFlow Extended（TFX）等框架提供了转换功能以简化所涉及的簿记工作。一些基于 SQL 的机器学习框架（如 BigQuery ML）也支持TRANSFORM子句。Vertex AI 支持特征转换引擎。

如果额外的基础设施和簿记开销值得的话，你应该优先使用转换函数而不是将转换代码放入模型中。如果特征计算开销大的话，这种情况就是如此。

特征存储

将预处理代码放在模型函数内部或封装在转换函数（或 SQL 子句或容器）中对于绝大多数特征来说足够了。

当你很快学到时，有两种情况这些不足以满足，你会需要一个特征存储（见图 11-8），一个用于存储和提供机器学习特征的仓库。特征存储本质上是一个键-值存储，其中键由实体（例如，hotel_id）和时间戳组成，值由该实体的属性组成（例如，价格，预订数量，过去一小时内到达酒店列表的网站访客数量等），作为该时间戳的属性。所有主要的机器学习框架（AWS SageMaker，Vertex AI，Databricks 等）都配备了特征存储。

图 11-8. 特征存储是一个提供某个时间点上实体值的中央存储库

第一种情况是，如果客户端请求预测时不知道特征值，而必须在服务器上计算，那么你将需要一个特征存储。如果请求预测的客户端不知道特征值，那么你需要一种机制将特征值注入到传入的预测请求中。特征存储发挥了这种作用。例如，动态定价模型的一个特征可能是过去一小时内项目列表的网站访问者数量。请求酒店价格的客户端（考虑一个移动应用程序）不会知道这个特征。这些信息必须通过点击流数据上的流式处理管道在服务器上计算，并插入到特征存储中。

第二种情况是为了防止数据的不必要复制。例如，考虑一个计算开销大且用于多个机器学习模型的特征。与其使用转换函数并将转换后的特征存储在多个机器学习训练数据集中，将其存储在集中式存储库中要更有效和可维护得多。

在任一情况下都不要过度行事。例如，如果模型的所有特征都需要在服务器端计算方式相同（例如，它们从关系数据库检索或由流水线计算），将检索代码放在转换函数或容器中是完全可以接受的。同样，重复一些特征处理几次而不是通过特征存储复杂化您的 ML 平台也是可以接受的。

特征存储的典型用途

特征存储的最重要用例是当情况 #1 和 #2 都适用时。例如，考虑您需要一个“时间点查找”，以获取训练数据来训练模型。诸如过去一小时网站访问者数量或司机过去一小时内的行程数等特征，被多个模型使用。但它们相对直接，因为它们由流水线计算，并且它们的实时值可以成为数据仓库的一部分。这些相对简单，不总是需要特征存储。

现在考虑一种备选特征类型，许多模型使用它，并且持续改进，如图 11-9 所示——例如，也许您在音乐流媒体服务中有歌曲、艺术家和用户的嵌入。有一个团队每天更新用户和歌曲的嵌入。每次消费这一特征的模型被重新训练时 — 高商业价值的用例需要定期重新训练 — 训练代码将需要获取与训练标签和最新版本嵌入算法对齐的此特征的值。这必须在所有标签中高效且轻松地完成。而且这必须在模型使用的数十甚至数百个特征之间完成。特征存储使得对难以计算且频繁改进的特征进行周期性模型重新训练尤为有用。

图 11-9. 特征存储尤其适用于难以计算且频繁更新的特征，因为模型将必须根据“时间点”嵌入进行训练。

决策图

此处讨论的考虑因素总结在 图 11-10 中。这不是一个决策树来决定您的组织是否需要一个特征存储 — 可能只有少数特征需要。这是一个决策树，用来决定是否对您正在构建或操作的特定特征/模型使用特征存储。

所有三个主要的云 ML 框架（AWS SageMaker、Vertex AI、Azure Machine Learning）都配备了特征存储。Databricks 和 Tecton.ai 提供了与云无关的特征存储。

图 11-10. 选择不同的预处理选项

自动化

正如你到目前为止理解的那样，可以使用云控制台部署自定义模型。可以使用笔记本开发和部署 TensorFlow 或 PyTorch 模型到 AWS/GCP/Azure。但这些方法都不适用于数百个模型和大型团队。

自动化训练和部署

例如，通过 Web 控制台创建 AutoML 模型后，您将获得一个可以监控的端点，并且可以设置持续评估。如果发现模型漂移，自动在新数据上重新训练会很困难——您不希望在凌晨 2 点起床使用用户界面来训练模型。最好能够仅使用代码训练和部署模型。对于您的团队来说，代码更容易自动化。

将在 Jupyter 笔记本中训练的 TensorFlow 模型部署为 SavedModel 到 Vertex AI 或 SageMaker 也会遇到相同的问题。重新训练将会很困难，因为运维团队必须在这些笨重且非最小化的操作和监控调度之上设置所有的运维工作。

对于重新训练，最好的方式是从数据集创建到训练再到部署的整个过程都由代码驱动。将模型代码与运维代码清晰分离，并用“普通”的 Python 表达，而不是笔记本，非常重要。

为了做到这一点，数据科学家团队在笔记本中开发的代码必须转移到常规文件中，并进行少量参数化：

• 数据将根据托管机器学习服务的合同规定从对象存储服务位置读取。例如，在 Google Cloud 中是 AIP_TRAIN⁠ING​_DATA_URI，在 AWS 中是 InputDataConfig，在 Azure Machine Learning 中是 Run 上下文。

• 模型创建代码被提取为普通的 Python 文件。

• 模型输出（在 SavedModel、ONNX、.bst等格式中）将保存到由托管机器学习服务的合同规定的对象存储服务位置。

现在让我们专注于如何编排所有训练模型所需的步骤。

使用管道进行编排

仅仅将数据科学家准备的 Jupyter Notebook 步骤转换为可执行脚本是不够的。需要在适当的基础设施上“编排”这些步骤：

• 使用 Spark、Beam、SQL 等准备数据集。

• 提交一个训练作业到托管的机器学习服务。

• 如果模型表现比先前训练的模型更好，则将训练好的模型部署到端点。

• 监控模型性能并进行实时数据的 A/B 测试以评估模型。

就编排而言，大体上有四种选择：托管管道、Airflow、Kubeflow 和 TFX。

托管管道

如果您正在为完整的开发和部署工作流程使用单一云，使用提供的 ML 工作流编排机制。在该云上使用托管服务执行的每个任务将具有相应的运算符，并且这些作业将理解依赖关系跟踪。例如，Vertex AI 提供 Vertex AI Pipelines，这是一个完全托管的服务，允许您根据需要重新训练模型。Azure Machine Learning 具有本地的设计器，提供相同的功能。

所有托管的管道提供编程 SDK，提供便捷的自动化能力。在 Databricks 的情况下，这个管道 SDK 是由 MLflow 提供的，它是一个在 Spark 上运行但提供 TensorFlow、PyTorch 和其他 ML 库和框架集成的开源框架。

Airflow

如果您已经在使用 Airflow 进行数据管道的调度和编排，将其扩展到机器学习的使用将允许您拥有一个简单、一致的系统。缺点是 Airflow 没有定制的 ML 运算符，因此您将发现自己使用通用的 Python 或 bash 运算符，这些运算符反过来调用云 SDK。Airflow 是开源的，您可以使用托管服务来运行 Airflow——如 Google Cloud Composer、Amazon Managed Workflows for Airflow 和 Astronomer.io，它是云不可知的。

Kubeflow 管道

每个步骤都可以容器化，并在 Kubernetes 上编排容器。Kubeflow 已经为流行的 ML 框架、ML 指标等提供了操作符。Kubeflow 也是开源的，您可以在公共云上使用托管的 Kubernetes 服务（如 Google Kubernetes Engine、Amazon Elastic Kubernetes Service 或 Azure Kubernetes Service）来运行 Kubeflow。还有像 Iguazio 这样的云不可知的托管 Kubeflow 提供者。

TensorFlow Extended

如果您正在使用 TensorFlow 生态系统，TFX 提供了便捷的 Python 函数用于常见操作，如模型验证、评估等。这提供了一种规范、易于使用的编排方法，避免了构建和维护运算符或容器的需要。TFX 是一个开源软件包，可以在托管管道、Airflow 和 Kubeflow 上运行。

TFX 是一个集成的 ML 平台，用于开发和部署生产 ML 系统。它专为可扩展、高性能的 ML 任务设计。TFX 的关键库包括预构建的 Python 库如下：

TensorFlow 数据验证（TFDV）

用于检测数据中的异常

TensorFlow 转换（TFT）

用于数据预处理和特征工程

Keras

用于构建和训练 ML 模型

TensorFlow 模型分析（TFMA）

用于 ML 模型评估和分析

TensorFlow 服务（TFServing）

用于在端点上提供 ML 模型

这些库使用开源 Apache Beam 和 TensorFlow 来实现它们的任务。任务可以在本地 Kubeflow 或 Airflow 集群上运行，也可以提交作业到托管服务，如 Dataflow 和 Vertex AI。

持续评估和训练

ML 工作流程中的每一步都会产生输出工件，您需要以系统化的方式组织这些工件。

工件

用户笔记本、管道源代码、数据处理函数和模型源代码需要存储在源代码仓库中。

数据科学家进行的每一个实验都需要进行跟踪：参数、指标、使用的数据集以及创建的模型。所有的机器学习编排框架都提供这一能力。

模型训练作业、随后训练的模型文件以及部署的模型都在托管的 ML 服务中进行跟踪（如 Azure 机器学习、Vertex AI 或 SageMaker）。

用于开发、训练和部署的环境被容器化，并在容器注册表中进行跟踪。这对于可重现性是至关重要的。

依赖跟踪

ML 管道中的步骤应该进行依赖跟踪，只有当其中一个依赖发生变化时才启动任务。例如，除非原始数据发生了变化，否则不应该导致重新创建训练数据的管道调用。这是预构建的操作器和托管的 ML 管道提供的功能，但自定义操作器和管道可能没有。

一旦将训练和预测代码自动化到 ML 管道中并系统地捕获了工件，就可以设置持续集成/持续部署（CI/CD）管道。在 ML 上下文中，这涉及持续评估和持续重新训练。

持续评估

要设置持续评估，您需要配置预测端点以将输入和相应预测的样本存储到数据仓库（DWH）。如果需要，可以定期运行一个标记作业，以便人工验证已进行的预测。定期的评估查询将比较人工标签与已进行的预测，以监控模型性能随时间变化的漂移。在 TFX 中，Model Analysis 组件会自动处理这一过程。

定期的评估查询还需要检查模型特征的分布，并监控其漂移。在 TFX 中，Data Validation 组件会自动处理这些。Vertex AI 中托管的预测服务也为所有模型类型提供了偏斜和漂移检测的开箱即用功能。

持续重新训练

每当评估查询识别出偏斜或漂移时，应该发出警报，以便人员审查需要进行的变更类型。其他类型的变更可以触发立即的重新训练。

每当代码更改被检入时，可能需要启动模型训练流水线。可以通过 GitHub/GitLab Actions 来处理。

最后，每当接收到足够大量的新数据时，模型训练流水线将需要启动。可以通过触发云对象存储中新文件的 Lambda 或 Cloud Function 来处理，并让函数调用流水线端点。

选择 ML 框架

在第十章中，您主要关注了预构建的 ML 模型以及如何在此类基础能力之上构建 ML 应用程序。您还研究了创建 ML 模型的低代码和无代码方式。在本章中，您研究了定制的 ML 模型。

作为云架构师，您应根据将构建 ML 应用程序的人员的技能选择 ML 平台中可用的工具。如果 ML 模型由数据科学家构建，您需要使他们能够使用基于代码的 ML 框架（如 Keras/TensorFlow 或 PyTorch），并使用 SageMaker、Vertex AI、Databricks 等来操作它。如果模型由领域专家开发，为他们提供一个低代码 ML 框架，如 BigQuery ML 或 AI Builder。虽然数据科学家可能不满意预构建模型（及相应的灵活性不足），但 BigQuery ML 提供的易用性和数据整理能力将非常适合领域专家。领域内的从业者将需要一个无代码 ML 框架，例如 DataRobot 或 Dataiku 来创建 ML 模型。

团队技能

同一 ML 问题的答案将因组织而异。例如，考虑使用 ML 进行定价优化的情况。团队将根据他们的技能选择方法：

• 数据科学家团队将选择构建动态定价模型。他们可能会从受控变异定价方法开始，并逐步引入需求冲击等因素。关键是这是一个使用复杂方法的复杂、专业团队。他们需要使用代码完成这些工作。

• 一个领域专家团队可能会选择构建分层定价模型。例如，产品经理可以使用历史数据来制定不同层次的定价，并根据市场细分特征调整新市场段的定价。这涉及到分析或回归模型，在 SQL 中非常可行。

• 一个非技术从业者团队确定最佳价格。例如，你可以让店长根据历史数据和他们认为重要的因素来定价他们店铺的产品。这需要一个无代码框架（例如，DataRobot 定价保险）。

正确答案取决于您的业务及您的领导期望从上述各种方法中获得的 ROI。

任务考虑

模型训练需要数据科学技能（统计、Python、笔记本），部署需要 ML 工程师技能集（软件工程、云基础设施、运维），而调用模型可以由任何开发者完成。然而，重要的是要认识到 ML 工作流程不仅仅是模型训练和部署。端到端的 ML 工作流程包括：（1）训练、（2）部署、（3）评估、（4）调用、（5）监控、（6）实验、（7）解释、（8）故障排除，以及（9）审计。作为云架构师，你需要确定公司内谁将负责每个 ML 问题的任务。这些其他步骤很少由工程师执行（确实，如果只有工程师能够执行这些任务，则是一个警告信号）。

例如，由数据科学家创建的模型可能需要作为销售人员在 Salesforce 内运行报告的一部分，并由销售经理审核。如果数据科学家在 Spark 中构建这样的模型，将其产品化为笔记本，并将其部署为 API，销售经理如何进行审计呢？现在你需要一个软件工程团队来构建定制应用程序（可能利用 Streamlit 框架或类似的工具）来启用 ML 工作流程的这一部分。这是时间、金钱和精力的严重浪费。这是一个云架构师可以通过将模型部署到支持仪表板的 DWH 中避免的问题。

用户中心化

这听起来很明显，但我们看到很多组织都犯了这个错误，值得指出：试图在 ML 框架上进行标准化，而忽视需要执行任务的人的技能集的组织将会失败。因为你的组织内技能集是不同的，你的组织内将会有不同的 ML 框架和工具。

确保选择开放、互操作的工具，以免陷入信息孤岛。选择能够解决不同复杂性水平的解决方案也是有帮助的——这样一来，供应商负责处理互操作性问题。

摘要

在本章中，我们介绍了如何为开发和部署定制 ML 模型的 ML 平台进行架构设计。主要收获如下：

• 一个 ML 平台需要支持模型开发、部署、编排以及持续评估和重新训练。

• 在编写代码和进行探索性数据分析时，数据科学家在笔记本环境中最具生产力。

• 所有主要的云服务提供商都为 Jupyter Notebook 提供托管的笔记本服务器。

• 在处理机密或私密数据时，将笔记本服务器、输入数据和加密密钥放置在更高信任边界内，将减少数据外泄的风险。

• 可以使用 pandas 对小数据集进行数据准备。对于较大的数据集，使用 Dask、Spark 或 Beam 进行数据准备的扩展。

• 模型代码的编写通常是通过数据集的小样本完成的。对于私人或机密数据，提供一个可下载到笔记本 VM 的样本。

• 在笔记本中的模型代码可以通过将机器类型更改为带有 GPU 的类型来在小数据集上执行。对于大数据集，使用笔记本执行器服务在托管训练服务中执行笔记本。后一选项也适用于大规模数据集上的分布式训练。

• 部署模型到由能够在 GPU 上运行的自动扩展服务支持的端点。

• 通过对部署到端点的模型进行 A/B 测试来评估模型。

• 通过使用标准模型格式和框架或容器来支持混合和多云场景。

• 为了防止训练 - 服务偏差，将预处理代码封装在模型内部或在转换函数中。或者，使用特征存储。

• 对于重新训练，最好从数据集创建到训练再到部署的整个过程都由代码驱动。

• 有四种编排选项：托管管道，Airflow，Kubeflow 和 TFX。如果您使用单一云，则使用托管管道；如果需要与数据管道保持一致性，则使用 Airflow；如果所有步骤都是容器化的，则使用 Kubeflow；如果您在 TensorFlow 生态系统内并希望使用易于使用的预设系统，则使用 TFX。

• 应备份诸如笔记本、管道源代码等工件，以便能够重现错误。

• 通过配置预测端点将输入和对应预测的样本存储到数据仓库来实现连续评估。

• 连续重新训练是由新代码、新数据或检测到的漂移触发的。

• 确保基于将构建机器学习应用程序的用户的技能集来选择 ML 框架。

• 将这些任务分开考虑：(1) 训练，(2) 部署，(3) 评估，(4) 调用，(5) 监控，(6) 实验，(7) 解释，(8) 故障排除 和 (9) 审计。然后，询问在贵公司谁将为每个机器学习问题执行这些任务。

在下一章中，您将通过一个模型案例的描述学习如何应用您到目前为止学到的原则。您将了解将老式数据平台转变为现代化和云原生的含义。

¹ 这里的参考是指正则化、学习率调度、优化器等。

第十二章：数据平台现代化：一个典型案例

在前几章中，我们探讨了如何利用云来构建能够处理大规模数据的现代数据平台，帮助您的组织消除数据孤岛，使更多员工能够访问数据，更轻松地从数据中获取见解，并加速 AI/ML 的采纳。这些能力共同促进了从数据中提取价值的过程。在本章的最后，我们将应用这些原则到一个典型案例中，以解释将老式数据平台转变为现代云原生平台的含义。请注意，该典型案例纯属虚构，旨在帮助深化讨论。

新时代的新技术

YouNetwork 是一家重要的视频广播公司，为整个欧洲 1500 万以上的客户提供服务。在其 30 多年的运营过程中，YouNetwork 在几次技术变革周期中航行，从 20 世纪 90 年代初的卫星广播先驱采用到最近的互联网协议电视(IPTV)协议实施。采用 IPTV 使 YouNetwork 能够推出一个提供实时节目和视频点播(VOD)的服务，利用与互联网连接的定制机顶盒(STB)。

在此期间，该组织通过每年扩展其视频目录（例如电视节目、电影、体育赛事等），成功地根据客户需求调整其产品。令人印象深刻的是，它还成功地实现了多样化的组合，增加了新的服务（例如在线游戏、互联网连接等），以支持和促进其全新 IPTV 服务的采用。

换句话说，YouNetwork 是一家在其核心业务（内容）创新并成功整合新技术以扩展市场的成功企业。新服务产生的数据激增以及基于实时数据缺乏敏捷性的问题，促使公司思考其技术堆栈的未来。主要驱动因素包括：（1）随着数据量增加，服务的可扩展性，（2）迅速实施并投入生产新的基于分析的解决方案的必要性，以及（3）需要向越来越期望个性化的客户提供更加量身定制的内容流。

变革的需求

在上一财年初，董事会安排了一次会议，讨论业务战略，其中讨论的主要话题之一是技术栈需要变革的问题。传统上，当 YouNetwork 投资技术时，通常是在自己的数据中心构建能力。然而，随着可扩展性问题日益严重，这变得越来越难以实现。董事会最大的担忧是，每一项旨在实施像定制客户信息收集、用户喜欢看到的下一个内容的预测以及实时欺诈检测系统等创新解决方案的开发都变得困难，并最终无法及时实施。

议事板讨论突显了对彻底变革的需求。从技术角度来看，特别是在数据方面，YouNetwork 在其历史上经历了两次主要的数字化转型：

COTS 时代

在这个时期，公司投入了大量资金购买来自单一供应商的硬件和软件，并且所有这些设备协同工作，执行各种活动（例如 DWH/数据仓库/立方体分析）。

OSS 时代

公司试图区分硬件和软件，采用了更开放源码的方法（主要是 Hadoop），能够处理新的用例，如非结构化数据管理和时间序列分析。

董事会认识到公司现在需要进行第三次重大的演进性转型，决定采取一条新的道路，利用近年来最具颠覆性的技术之一：公共云。

由于公司内没有人拥有足够的经验来推动这样的转型，首要决定是成立一个技术“SWAT”团队（由内部领导和来自顶级咨询公司的承包商组成），旨在搜索市场上所有可能的解决方案，并准备一个扎实的业务计划，以现代化 YouNetwork 当前的数据平台。

这不仅仅是技术问题。

SWAT 团队组织了一系列与主要云供应商的一对一会议，以更好地了解如何将数据平台架构转型为现代化堆栈。即使在第一次互动后，显然，向云的转型不仅仅是技术上的旅程，还需要 YouNetworkers 在使用数据方面进行全面的组织转型。

SWAT 团队发现，有必要将云策略与整体组织战略对齐，考虑业务如何在技术更新的背景下发展。例如，对基于互联网的技术和协议的深度投资要求相应地投资于可扩展的数据平台，以应对新系统将产生的实时 TB 级数据。这样的可扩展数据平台将支持提取可操作信息，并使 YouNetwork 能够提高服务质量（QoS）并更好地了解用户。而 QoS 的改善将改变可提供的节目组合，并且更好地了解用户将促使个性化，从而改变正在制作的节目。这意味着内容采购团队现在成为数据平台转型的利益相关者。

另一个关键成果是需要来自高层的赞助，但在这种情况下，该计划最初由董事会生成，KPI 和来自 C 级管理层的支持已经成为现实。然而，公司内部需要将这种赞助从上到下传递，这种组织内的倡导最佳途径是通过建立一个名为“云卓越中心”（CCoE）的专门团队。考虑到组织的初期遗留足迹，清晰地确定能够推动这样一种转型的人员并不容易。YouNetwork 采用了混合方法，从 SWAT 团队开始，内部和外部个人合作建立了 CCoE：

内部资源

产品、架构和工程领域的三位人士分别带来了关于现有工作和问题的内部知识和专业知识。由于他们对云端开放并倾向于推动公司变革，YouNetwork 选择了那些已经在进行一些“非官方”研究和实验，利用云服务的人员。

外部资源

第三方高级顾问团队带来了帮助定义整体战略、采纳以及相关治理的专业知识和经验。他们在需要时充当领导和顾问的角色，主要目标是在初期阶段提供秩序、方法和支持，尤其是因为内部团队在云知识方面缺乏的情况下。¹ 随着时间的推移，随着内部团队变得越来越有能力，这个团队中的人数逐渐减少。

最初的成就主要是战略性的，专注于找到一个扎实的回答：“我们如何引导公司进入新的篇章？”正如你将在本章中看到的，关键任务是仔细分析、比较和评判云供应商提出的建议，以选择最符合组织需求的最佳方案。

如图 12-1 所示，CCoE 确定了策略并明确了在四个阶段中应遵循的过程：

治理

确定和实施标准，以指导新创建的数据平台的使用，衡量其成功，管理相关支出，并追求效率。

迁移管理

推动和控制工作负载在云中的迁移。

运行环境的操作化

控制已迁移到云中的工作负载的云团队运营

培训和支持

作为工程、产品和运营团队的主题专家，促进云在新项目中的进一步采纳，同时赋予业务理解和利用组织新创建的云能力的能力，特别是通过大规模培训会议（即变更管理）

在新数据平台开发完成后，内部人员全力推动了 CCoE。CCoE 也在扩展——增加了诸如安全、站点可靠性工程师（SREs）、数据工程师、数据科学家、云操作、技术支持工程师等全新角色——在公司业务单位内部成立新团队，以执行每个流程。今天，YouNetwork 的 CCoE 由 10 名成员组成。

图 12-1. CCoE 的角色

需要注意的是，CCoE 的责任之一是考虑公司未来可能面临的组织变化（参见“步骤 3：打破信息孤岛”）。为了帮助团队顺利过渡到新世界，请遵循团队的建议。

旅程的开始

正如前面所强调的，在了解采用复杂转型和现代化旅程所需的挑战和努力后，YouNetwork 首先必须确定可能的目标架构，然后定义如何使其成为现实，考虑到其本地/遗留基础设施。基于与云供应商的初步讨论，CCoE 准备了一些文件，描述了当前环境的高层次图像和预见的目标架构。

当前环境

如前所述，数据平台的技术足迹需要进化，公司决定向各个云供应商发布 RFP（实际上是一个招标，供应产品和服务的报价），以获得可能的目标架构及相关程序的报价。

当遗留系统最初设计如图 12-2 所述时，施加了一些标准化：所有遗留架构的源系统都必须生成文件（例如，CSV、JSON、Parquet 等），以上传到 FTP 服务器。从那里，一个 COTS ETL 解决方案读取和转换数据，以便根据 Hadoop/Spark 技术摄取到 DWH 和数据湖中。Hadoop 集群与 DWH 之间的通信通过一个特定的连接器实现。数据分析师和决策者主要使用 Excel 和其他基于商业解决方案的 BI 工具进行所有活动和分析。

图 12-2. 本地数据平台架构

每个当前工作负载的配置信息被添加为 RFP 的附件，以帮助云供应商从技术和经济的角度确定最终解决方案的规模：

• 环境数量（通常为三个：开发、测试和生产）

• 节点数量

• 每个节点的核心数

• CPU 平均利用率（例如，92%）

• CPU 利用率峰值（例如，100%）

• 每个节点的内存大小

• 内存平均利用率（例如，92%）

• 内存利用率峰值（例如，100%）

• 每个节点的存储大小，备份存储和总存储

• HDFS 复制因子（例如，3）

• 操作系统类型和版本（例如，Windows Server 2008/Linux CentOS 7）

• 节点的正常运行时间（例如，24/7/365 或每月 160 小时）

• 每天生成的数据量（例如，约 350 GB）

• 数据保留策略（平均 730 天）

类似于那样的遗留解决方案，硬件接近寿命末期，软件超过支持结束，维护难度大，尤其是在 DWH 方面的许可成本正在激增。此外，由于无法采用流式模式，架构非常受限。需要更新 Hadoop 集群的硬件（系统接近崩溃，新的作业可能在排队几天后才能执行）和软件（Hadoop 发行版已过时）。

系统位于两个物理分离的数据中心：主站点和故障转移站点。它们配置为主动/主动，这意味着在两个设施中都有足够的基础设施来运行业务，并在灾难情况下减少系统退化（即整个数据中心的故障），从而提高可靠性。DWH 数据实现了实时同步，达到接近零的恢复点目标（RPO）。数据湖数据使用 DistCp 工具多次每天对齐，目标 RPO 为六小时。在灾难情况下，可以将流量从一个数据中心路由到另一个数据中心，最小化停机时间，实现接近零的恢复时间目标（RTO）。

目标环境

在 RFP 文档中，CCoE 团队概述了 YouNetwork 新云环境的期望最终状态。从总体上看，目标是拥有一个单一系统（即数据湖仓库），作为整个公司的唯一真相点。所有用户应能够根据其访问权限访问数据并进行自我报告。该想法是尽可能减少用于此类活动的工具数量，并向开源软件过渡。在可能的情况下，ETL 部分必须采用 ELT 方法进行现代化。采用开源软件的目标是尽可能终止 COTS 许可证。团队选择了以 SQL 为先的数据湖仓库（见第七章）方法，因为尽管 Hadoop 是传统架构的重要支柱，但熟悉 SQL 的人数多于能够使用 Spark 的用户数。意图是同时（1）重视组织已完成的将所有源数据登陆到数据湖的工作，以及（2）帮助减少约束，促进更民主的数据访问方法。

由于当前架构显示出弹性和成本优化的限制，组织想要实现的是提供无限可扩展性并依赖现代技术（如瞬时集群）来优化资源使用和成本的云解决方案。此外，未结构化数据所在的 Hadoop 集群大小也必须减小，因为大多数活动应由 DWH 直接执行。

另一个关键元素是实时处理数据的能力：过去，批处理方法足以进行请求的分析，但是为了为客户提供即时和定制的反馈，推动公司转向流式使用案例。此外，考虑到需要管理和控制的任务数量众多，显然需要一个工作流管理平台层，帮助使用“配置即代码”的方法编排所有数据任务。架构的每个组件都必须通过细粒度控制策略进行保护，并通过解决方案进行管理，允许用户完全了解发生的情况。

最后，该平台必须通过启用和扩展 ML 的采用来成为创新的摇篮，以改善客户体验，降低成本，增加收入，并通过为客户提供更有价值的服务获得竞争优势。这导致了所期望的目标架构，如图 12-3 所示。

图 12-3. 构想中的高级云数据平台架构

根据我们的经验，选择成功的供应商和选择不佳的供应商之间的区别在于您的业务目标与供应商的产品之间的对齐。 YouNetwork 特别注意确保这一点正确。 YouNetwork 向供应商解释了为什么要投入精力转移到云端的原因。正如在开头强调的那样，YouNetwork 技术栈改造背后有三个主要动机：

• 组织希望扩大其市场份额，增加访问服务的用户数量，直接影响平台的可扩展性：更多用户、更多访问和更多资源用于服务系统，可能会出现不可预测的模式。

• 公司希望提供更具吸引力的服务，这意味着采用快速失败的方法进行大量实验和 A/B 测试。

• YouNetwork 希望发展忠诚度，为用户提供更加量身定制的内容，通过对其硬件设备的 QoS 进行更精细的控制，同时提供更加稳健的服务。

YouNetwork 明确表达了希望在 RFP 响应中看到其目标反映的期望，并且事实上，公司要求开发一个 PoC 来展示现代数据平台的价值。

PoC 使用案例

YouNetwork 决定向云供应商提出一个特定的场景，这个场景在本地环境中造成了很大的困扰，特别是在两个主要动机中：完成任务所需的空间和获得最终结果所需的时间。 公司每 15 分钟从其客户 STB 收集数据，以分析 QoS 并生成其设备网络状态的热图。 每个 STB 生成一个包含其状态快照的文件，然后连接到 FTP 服务器上传内容。 从那里，ETL 批处理作业处理 FTP 服务器中的所有数据，汇总所有文件并提取相关信息以上传到 DWH。 然后，SQL 作业处理数据并将结果物化为一个表，这是一个仪表板的基础，用于显示 STB 的状态，如图 12-4 所示。

图 12-4. PoC 本地使用案例架构

这种架构的主要缺点如下：

无法扩展

有超过 1500 万设备可能每 15 分钟发送信息，但后端无法处理如此大量的多个连接，因此实际上，并非每台设备每 15 分钟发送数据，而是仅选中一些设备以轮询的方式发送数据。

请求空间的大小

每个单独的文件本身并不是很大（大约 1 MB），但考虑到生成频率，存储在 DWH 中的数据量是无法管理的，这意味着 YouNetwork 只能在线维护很短的历史数据（仅生成 100+ TB 的数据，包含 1 亿多行，只有七天）。

访问数据的时间

由于 DWH 已经在处理多个用例时已经处于压力之下，执行用于可视化工具的表的材料化查询所需的时间大约是 55 分钟。

注意

选择 PoC 用例非常重要。请注意，YouNetwork 选择了一个如果成功，将为构建云原生数据平台提供理由的用例。您也应选择一个比典型用例更难、对业务影响显著，并能揭示云相对于现状改进的相对优势的用例。不应选择一次性或主要是操作性质的用例，特别是当大多数评估人员都在 IT 部门时。PoC 不应该是摄入一个随机文件并对其进行查询（一次性用例，没有业务影响），或者履行“被遗忘权”请求（操作性质）。因此，在选择 PoC 用例时，请走出去与业务用户交流！

云供应商提出的 RFP 响应

为了更好地理解如何实现其目标，YouNetwork 决定准备一份详细的投标文件，与提交特定提案的所有云供应商分享。尽管价值主张基于不同的差异化因素，但提出的高层架构非常相似。接下来的章节将讨论云供应商响应的关键组成部分，概述了他们提出的现代化旅程计划。在这样一个规模的组织中进行这样的项目通常是一个典型的流程。然而，请注意，其他组织可能采用不同的方法，可能更或者更少正式。请专注于各个部分的内容，而不是整个过程的结构。

目标环境

每个云供应商的提案都遵循图 12-5 中描绘的架构（您在第 7 章中看到的那个），并利用突出的 PoC 用例来解释它。

图 12-5. 提议的云数据平台架构

架构的主要组成部分包括以下内容：

数据源

机顶盒将数据发送到后端。它们可以实时和/或批处理发送数据：

实时

设备通常每 x 秒发送其状态信息，通常以 JSON 格式。

批处理

设备同时发送多条消息或者单条消息包含多条消息，可能是在重新启动或更新操作之后。

数据摄入

这是从 STB 接收消息并负责数据收集和存储的组件。对于实时消息，它使用了一个能够处理每秒数百万条消息的发布/订阅无服务器解决方案。数据随后被推送到基于对象存储解决方案的原始落地区（铜区）的数据湖中，这种解决方案天生具有无限可扩展性。这将成为实时和批处理消息的家园，后续管道将处理这些消息。

转换

在这个阶段，系统处理 JSON 数据以提取相关信息（并丰富内部数据以进行治理），例如带宽、延迟、抖动或丢包，并将其存储在数据湖的生产区以及 DWH 中的专用表中。

分析

现在是分析收集的数据的时候，以确定是否存在问题或情况是否受控。用户可以通过纯 SQL 查询阅读信息，以验证设备状态或分析某些参数随时间的演变。但他们也可以进行更复杂的分析，例如特定 STB 集和相关用户的计划政策变更效果，或者验证特定视频压缩级别与特定内容前使用时间的相关性。

商业智能和 AI/ML

分析师现在可以开发一些实时可视化仪表板，例如热图，轻松识别 STB 的使用情况，或者实时监控流媒体视频的数据包延迟或压缩级别。由于底层基础设施能够同时处理多个数据集上的多个分析而不会降低整体性能，因此可以大规模进行这些分析。有了大量的新旧数据可用，数据科学家可以通过实施 ML 算法来预测 STB 何时会发生故障，建议客户需要新设备，或者更好地自动触发程序来为他们寄送新设备。

数据消费者

它们可以是用户或其他系统。消费者可以利用原始数据或从分析或商业智能和 AI/ML 系统的外推中进行策划后的数据。在这种特定场景中，大部分数据消费者是基于某些处理结果（例如对抖动级别的分析）的自动解决方案，可以自动触发一些程序以改善服务质量，例如带宽塑形或流量管控。

与前述部分相对应，还有水平服务：

编排

解决方案通过一个 DAG 来协调所有数据处理任务，该 DAG 定义了各种作业的所有依赖关系，处理故障、重试和回填。

目录和隐私

数据目录操作（例如，元数据管理、数据血统等）和防止数据外泄/泄露、保护敏感信息内容（例如信用卡号）的解决方案。

IAM/操作/日志和监控

控制“谁访问什么”并记录数据旅程的每一步（例如，加载事件数量、数据摄入的维度、执行特定查询的用户等），具备监控和控制整个数据平台健康状况的能力的解决方案。

持续集成和持续交付

源代码、脚本、配置和基础设施版本控制的解决方案；自动构建、测试和部署；以及从生产环境中设置、隔离和分离的环境。

在开发方面，云供应商决定选择公司所希望的高度灵活性水平：

IaaS

最佳的管理控制水平，但需承担管理负担；符合 COTS 和 OSS 标准。组织必须完全管理整个基础设施，并处理像打补丁、更新发布、维护等活动。这里我们谈论的是基于 VM 部署选定解决方案的配置，YouNetwork 必须执行。

PaaS

让组织专注于开发适当的解决方案，而不是管理基础设施，根据应用程序需求自动扩展的解决方案。例如 AWS Lambda、Azure Functions、Google Cloud Functions、AWS Redshift、Azure Synapse 或 Google BigQuery。

SaaS

用户可以直接利用的解决方案。它们可以在任何地方部署（云端或本地），但对于在线访问服务的用户来说完全透明。例如 Salesforce、Looker 和 Palantir。

需要注意的是，从 RFP 中并不是非常清楚 YouNetwork 的首选战略是什么：其过去的专业经验是处理 VM 和服务器，因此 IaaS 方法是最容易应对的，但要实现设想中的转型水平，云提供商推动更多的是 PaaS 和 SaaS 方法，完全解放组织不再维护基础设施，而是将所有用户聚焦于为公司创造价值。为了避免组织做双重翻转，供应商之一提出了一个混合方法，关键组件基于 PaaS 技术（例如 DWH、数据湖），但其他组件（例如调度器）部署在 IaaS 上以简化采用过程。

需要注意的是，RFP 并不总是对组织希望实现的要求或将用于评估它们的 KPI 100%清晰。有一个专门的部分，供应商可以在正式提交响应之前向相关利益相关者提出详细问题，这是标准做法。有时这些问题对所有参与者公开，有时则不公开，这取决于组织制定的规则。

迁移方法

RFP 的另一个关键部分旨在回答一个简单的问题：“我们如何到达那里？” 从本地环境迁移到一个超出传统数据中心范围的现代化环境，一开始可能看起来令人生畏。这就是为什么您需要清楚地理解实施这种转型所需的方法和不同阶段。除了建议的最初发现和规划阶段，该阶段是回顾了第四章中描述的内容，所有供应商的提议都集中在一个基于四个不同阶段的多步骤方法上，具有相关的重点和目的：

基础开发

架构的基础必须同时构建 IaaS 和 PaaS/SaaS 解决方案

快速获胜迁移

迁移特定的工作负载，这些工作负载可以很容易地在新环境中找到适合的位置，从而启用下游应用程序（例如，从 STB 获取 JSON 数据的数据收集器）

迁移实现

完成所有工作负载背后的数据迁移（例如，历史 STB 数据）

现代化

引入新功能（例如，流媒体和 AI/ML 能力），并重新设计/重新实施老式工作负载以利用云原生功能（例如，采用更 SQL 优先的数据湖和数据仓库湖屋方法）

让我们深入研究云供应商提出的所有步骤。

基础开发

这一步是 YouNetwork 必须在云中为所有未来工作负载开发基础的步骤。它指的是云环境的基线和结构配置。您可以将其视为启用遗留工作负载迁移和新工作负载实施所需的最低配置，并且通常包括使平台成为工作负载理想场所的所有水平服务。

供应商的提议旨在针对以下被确定为 YouNetwork 采纳的关键因素：

身份管理

您必须以安全可靠的方式处理用户和服务的认证：

• 云身份服务 初步与当前本地解决方案集成（在这种情况下是 Microsoft Active Directory），随后完全采用在云环境中完全管理的解决方案，并自然弃用旧解决方案

• 认证选项（例如用户/密码或单点登录）及相关安全性（例如双因素认证），以允许 YouNetwork 用户摒弃 VPN 方法，并采用现代零信任安全方法，以实现安全、快速和便捷的远程工作。

• 审计活动用于跟踪和监控平台内每个单一身份执行的所有活动（例如用户登录），以便符合合规性和控制目的。

访问管理

您必须确保只有经授权的身份才能访问选定资源，并拥有正确的权限集：

• IAM 解决方案可大规模处理所有身份的权限。

• 组织策略用于定义应在组织级别应用的所有规则（例如审计团队可以以只读模式访问所有云资源）。

安全性

您必须定义策略和操作以保护新环境，考虑到与云技术相关的共享责任（即云环境的安全由云供应商处理，而在云环境中的安全则由最终用户管理）。

网络

您定义云环境中所有新组件的通信方式，以及它们如何最终与外部和本地资源交互。

可见性

您描述了如何获取与运行工作负载相关的实时信息的访问方式（例如日志记录、监控、错误报告、计费消耗和预算等）。

所有供应商的基础性提案预计在一个N个月的期间内，YouNetwork、云服务供应商的专业服务组织（PSO）团队以及第三方系统集成商将共同深入研究前述主题，为第一个工作负载部署（即来自 STB 的 JSON 数据的数据收集器）做准备。

现在是反思 CCoE 角色及如何规划其扩展的时候了。初始阶段，CCoE 只是公司内特定业务单位（即产品、工程和架构）中工作的一小群人。然而，目标是将其扩展到多个其他领域（例如安全、运营、培训等），并使云知识贯穿整个组织。对于 YouNetwork 的提案实际上是让 PSO 和系统集成商与 CCoE 合作，在基础设施设置期间定义最佳实践、蓝图和监控活动。这使得组织可以第一手体验在云环境中利用的方法，并理解如何加固和扩展 CCoE 团队。

注意

请不要忘记，您的最终目标是使 CCoE 非常成功，以至于项目完成时可以解散它，因为组织内所有相关职能都将掌握和利用云环境的知识和工具扩展它们。

快速胜利迁移

这是 YouNetwork 可以开始特定遗留工作负载的初始迁移阶段（请参阅第四章中提到的快速胜利解决方案），这些工作负载在评估和规划阶段已经被识别出来。正如您之前所阅读的，已经确定的用例当然是来自 STB 的数据收集器，这使技术用户能够更好地了解设备足迹的状态。数据是以批处理模式收集的，STB 将数据上传到 FTP 服务器，然后通过 ETL 管道摄取到 DWH 中。目标是利用这个快速胜利展示第一步现代化：使系统能够从多个 STB 收集指标，利用完全无服务器的管道。为此，使用 FTP 服务器进行文件收集将完全被弃用，改用发布/订阅消息方法，这是迈向未来全面流式应用的第一步。一旦数据被摄取到数据湖中，可以通过分析引擎直接查询数据，并通过仪表板可视化结果。与此用例相关的整个数据流程可以在两个系统（即本地和云端）上并行运行²，在并行一段时间后，工作负载可以从遗留系统完全停用。您必须了解，这种初始过渡需要一组非平凡的手动活动，不仅因为它是第一个真正的迁移活动，而且因为现在是开始开发所有需要实施自动化的工件（例如基础设施即代码模板、通用查询转译器、数据验证管道等）的良好时机，这些工件将在后续迁移阶段中被利用。

迁移履行。

第一批快速胜利的成功迁移完成是设定整个项目成功轨迹的一个非常重要的里程碑，你应该非常关注它。利用完全迁移的解决方案进入新的云环境，您可以向业务展示即时的好处，如可伸缩性、弹性、改进的可观察性和减少的数据访问时间。这样的展示对于建立对下一步的信心非常重要，即遗留平台的完全迁移。考虑到 YouNetwork 想要快速放弃其本地数据中心，这个阶段专注于迁移速度（特别是数据迁移），因此建议采用主要的重新托管策略，并在可能的情况下采用重新平台化的细微差别。这使得组织能够：

定义各种迁移活动的标准。

每种工作负载的迁移蓝图定义，这些工作负载都是迁移范围的一部分（例如，自定义应用程序、数据库等）。

自动化迁移活动。

数据提取、压缩、去重、传输、摄取和转换、任务编排、监控和验证。

提议除了 DWH 外，已包含在快速胜利战略中，通常保留原始技术堆栈，引入一些本地云功能以提高解决方案的可用性。所有转型步骤都推迟到最后一步：

• FTP 服务器（不再用于来自 STB 的数据，而是用于视频内容、图像等其他类型的数据）。

  • 定时的虚拟机只在预期数据以文件形式进入的特定时间段运行。

  • 与云原生网络附加存储（NAS）系统解决方案集成，用于存储临时数据。

  • 集成与云原生 blob 存储解决方案，用于备份原始数据副本。

• ETL

  • 以现状迁移 COTS 解决方案。

• Hadoop 环境

  • 以现状迁移 Hadoop 发行版。

  • 与云原生 blob 存储解决方案集成，以减少 HDFS 文件系统的大小。

需要注意的是，迁移后，工作负载将自动受益于在云基础设施阶段实施的所有横向解决方案（即网络、安全、可见性等）。在迁移过程中，当然还有一个重要的主题需要考虑，即数据迁移，可以通过各种技术处理；在这种情况下，数据迁移需要采用双腿方法：

热数据

直接执行迁移，利用本地数据中心与云环境之间的高速连接。

冷数据

在第二个时机执行迁移，利用物理传输设备：

• 将物理设备连接至本地环境。

• 下载冷数据。

• 将物理设备转移到连接到目标云数据中心的位置，并使用超高速连接。

• 将数据上传至云环境，验证内容（例如 CRC32C 校验和）。

• 清空物理设备的内容。

现在让我们看一下如何现代化架构。

现代化。

在此阶段，您应该考虑如何增强迁移后的工作负载，扩展当前功能，并实施新功能。流媒体能力、实时分析和机器学习自动从数据中提取价值只是需要执行的几个活动。前一步骤的目标是尽快迁移工作负载，采用更多的 IaaS 导向方法；现在的目标是改变思维模式，开始利用完全托管的解决方案——减轻基础设施管理的负担，让用户专注于他们的业务解决方案，这才是真正重要的事情。第一件事是扩展初步工作负载分析，以发现：

• 最佳方法是添加在本地环境中不可行的新功能。

• 将过时的工作负载重新设计以利用 PaaS 和无服务器解决方案的最佳方法

在现代化旅程中，你不应低估的一个要素是平台的每个组件都必须通过 API 可访问：这是转型的核心元素，因为它使得内部和外部资源之间的集成、架构的未来重组以及组件之间的实时互操作成为可能。当你审视迁移的元素时，你可以为每个层次识别主要的转型：

数据摄取

这是你应该重新设计的第一个组件，不仅因为要摆脱 FTP 服务器方法（速度慢、不可扩展、不安全），而且因为批处理范式对像 YouNetwork 这样以流媒体技术为基础的公司来说已经不够用了。它必须建立一个能够在规模上处理数据收集（即从多个源并行处理）并实时处理的层，利用消息队列/事件范式（例如类似 Kafka 的解决方案）。这些解决方案与数据源的集成通常由第三方合作伙伴、内部定制开发或利用云厂商的原生解决方案（例如 AWS Glue、Azure Data Factory 或 Google Data Fusion）完成。数据必须存储在一个无限扩展的 Blob 存储中，可能以原始格式存储，在此处数据可以在进行转换之前临时存储，或者可以保持几个月甚至几年不变——例如，完全受保护和认证的存储区域，以供审计目的使用。

数据转换

在这里应该遵循的方法是扩展基于 ETL 的常规技术，其中所有逻辑都驻留在转换工具中，采用可以利用分析层引擎的 ELT 方法。原始的 COTS 解决方案在前一步中已按原样迁移，但现在是改变方法的时候了，开始实施一个开源解决方案，它可以减少供应商锁定并为批处理和流处理提供统一的方法。这将避免需要学习和管理两种不同的模型来处理转换（Apache Beam 是这方面的一个有趣例子）。该层必须能够处理大量数据、高级别并行处理，并可能处理来自生产系统的实时数据。

数据分析

数据湖和 DWH 正在一个单一环境中汇聚，用户可以利用他们需要的引擎（例如 SQL、Spark）来分析数据，正如您在第七章中所读到的那样。在这里，VMs 的概念完全从方程中移除，而是采用无服务器和完全托管的解决方案（例如 AWS Redshift 和 EMR、Azure Synapse 或 Google BigQuery 和 Dataproc）来领先于满足所需的可扩展性。在与其他存储形式（例如 Blob 存储、DWH 存储等）更好地集成的情况下，HDFS 模型可以被超越，从而使不同资源的使用能力更强（即系统不需要像 HDFS 范式那样始终运行）。显然，甚至所有的保留和备份政策都需要根据用户需求进行重新审视。

BI 和 AI/ML

除了迁移工具向更现代的 BI 解决方案（例如 Tableau、Power BI、Looker 等）的演进外，您应该利用以实现最高现代化水平的组件当然是 AI/ML。这种技术在使用本地化 YouNetwork 架构难以扩展，是实施一系列功能的核心，将提升组织服务的采用率，例如：

个性化推荐

通过分析客户的观看历史和偏好来增加参与度和满意度

内容优化

为了确定在制作或获取新内容时的投资领域，识别兴趣集群。

预测性维护

监控服务的健康状态，减少停机时间并提高客户的整体服务质量

受众分析

分析观看模式和人口统计信息，更好地了解客户并为他们提供更贴心的服务和定价策略

欺诈检测

检测欺诈活动，如多用户共享帐户或使用盗窃的信用卡购买服务

现在您对云供应商所做出的响应有了更好的理解，让我们看看 YouNetwork 如何评估它们。

RFP 评估过程

在对不同 RFP 响应进行详细分析和评估后，考虑到不仅是技术愿景和战略，还有商业数字（显然超出本书范围，但在最终决策中起着至关重要的作用），YouNetwork 团队选择了少数云供应商继续进行评估的最后一步，即构建 PoC。目标是了解采用特定云解决方案的便捷性和有效性。

PoC 的范围

公司决定利用 RFP 中描述的特定场景来评估和验证各个云供应商的能力。云供应商必须实现一个模型来展示他们处理描述的用例在规模上的能力。

YouNetwork 定义了三个特定的 KPI 来评估 PoC 的结果：

20M 台设备

收集来自扩展 STB 群体的数据

两周（最好一个月）的时间窗口

扩展存储的历史数据大小

少于五分钟

准备建立表格

提交 PoC 的时间是两周。

YouNetwork 向云供应商提供了：

• 由 STB 生成的示例数据文件

• 从示例文件中提取和转换所需数据的指导方针

• DWH 表的模型

• 定义需要从中提取并可视化为报告的主要信息

现在让我们来看看 PoC 的执行方式。

PoC 的执行

选定的超大规模系统集成商利用此机会与其首选的系统集成商合作展示了一个非常普通的模型，云供应商与第三方公司合作，可以带来深厚的架构和产品专业知识，以及能够扩展的能力：一个真正可扩展的现代化团队在行动。两位参与者对标书的方法非常相似，并且基于以下支柱：

• 设计和配置通过 API 可访问的 Blob 存储，STB 可以上传其文件。

• 使用 Java 或类似语言实现一个定制应用程序，模仿多个基础 STB 的行为，目标非常基础：

  • 基于 YouNetwork 提供的示例生成随机数据。

  • 尝试连接到后端发送数据。

  • 发送数据。

  • 在收到数据已正确传递的确认后销毁自身。

• 并行启动多个 VM，运行 STB 仿真器的多个实例。

• 开发批量 ETL 无服务器流水线，以规模化读取和转换所有数据，并将其注入到 DWH 中。

• 实现仪表板，直接从 DWH 查询数据。

现在让我们来看看在云供应商之一实施后每个 KPI 的结果：

20M 台设备：✅

如何可能实现这一点？这是一个巨大的数字！是的，确实如此，但对于云来说，这是一个相当常见的用例：处理突发性需求！让我们想象一个初始状态，您在 VM 环境中运行您的仿真器（例如 AWS EC2、Azure 虚拟机、Google Compute Engine）：仿真器只需模拟生成一些随机数据的 STB 的行为，将数据实现为文件，然后上传到 Blob 存储。假设仿真器可以并行模拟多个 STB；为了快速达到您的目标数字，您只需部署其他 VM，并为每个实例运行另一个仿真器。按照这种方法，您可以轻松地达到（甚至超过）您的目标。数据可以并行上传到 Blob 存储，这是一个本质上可以扩展的无服务器解决方案（例如 AWS S3、Azure Blob Storage、Google Cloud Storage）：这里没有空间问题，因为它可以被认为是无限的。

两周的窗口期：✅

再次？是的！如前所述，可用存储空间可以被认为是无限的，对于 DWH 的存储也是如此，所以这里没有问题。从成本的角度来看，云存储的价格足够低廉，扩展窗口不会造成预算问题。

少于五分钟将数据实现：✅

这意味着什么？这意味着您可以直接从摄入表中查询数据，而不需要将其实现为新表，并且仍然能够获得超快速的响应。这可以通过无服务器解决方案（例如 AWS Redshift、Azure Synapse、Google BigQuery）实现，它们（由于存储与计算的分离）可以轻松提升其分析引擎以加快查询执行（有趣的事实是：当 YouNetwork 董事会亲眼看到从 DWH 运行的查询渲染仪表板所需的时间以及处理超过 100 TB 数据时，首席数据官说，“这是一个 Flash 动画”，顾问回答说，“这会花更长时间”）。

现在让我们看看 YouNetwork 的最终决定是什么。

最终决定

YouNetwork 对通过 PoC 执行所取得的结果印象深刻，因为它能够体验到整体现代化价值的一部分。在最终决策关于现代化旅程分配的问题时，以下是考虑的要素：

解决方案的技术强度

不仅仅是在可伸缩性和弹性方面，还涉及可用性、灾难恢复选项、备份解决方案等。

视野和路线图

我们现在的位置以及未来的发展方向，尤其是创新方面。

团队和组织

能够完成迁移项目。

合作伙伴关系

主要但不限于系统集成商（甚至软件供应商）。

培训计划

必须为员工拥有坚实的培训计划。

总体定价

现代化很酷，但必须在财务上可持续。

现在呢？选择的云提供商是谁（只有一个？），系统集成商是谁（只有一个？），迁移整个基础设施花了多少个月？这些并不是重要的事情，因为每家公司在做决策时都有自己的正确方式（并且会根据上述因素进行权衡）：真正重要的是，YouNetwork 现在拥有一个数据架构，使其能够更有信心地朝未来迈进。它已经在其 IPTV 和 VOD 系统中实施了几个新的用例，涵盖了安全（例如，在其在线电子商务网站中新的欺诈检测系统）、用户体验（例如，电影中演员的实时识别，通过语音交互实时搜索节目）、以及运营（例如，通过异常检测进行实时 QoS 分析）。毫无疑问，还将推出更多创新的数据产品。

结论

我们编写本书，旨在指导希望通过使用公共云技术创建数据和机器学习平台来支持业务数据驱动决策的架构师。我们的目标是帮助您更好地理解建立现代云数据平台所需的主要概念、架构模式和可用工具。

在本书中，我们讨论了基于云的数据平台如何降低获取数据、运行交互式查询、创建报告、进行自动决策和个性化业务服务的技术障碍。一个设计良好的数据和机器学习平台使得可以从任何地方访问数据，在边缘设备上进行快速的大规模查询，并利用提供多种分析和人工智能能力的服务。

当您企业中的每个利益相关者都能访问他们所需的数据时，他们可以更好地做出决策并更有效地解决问题。使数据的使用变得简单和广泛将为您带来竞争优势，帮助您做出更好的决策，改进您的产品和服务，并促进业务增长。民主化数据存在许多挑战——除了构建数据和机器学习平台的技术方面外，您还需要确保每个人都具备访问和使用数据所需的技能和工具，并创建保护隐私和安全的政策。然而，正如本书所示，这些挑战并非不可克服。

民主化数据的好处远远超过挑战。

总结

在这一章中，我们将之前章节学到的原则应用到一个典型案例中。您已经看到了从传统环境迁移到现代云原生数据平台所需的步骤。主要收获如下：

• 当组织意识到他们当前的数据平台与他们当前和未来的业务发展计划不兼容时，就是开始进行现代化旅程的时候了。

• 第一步是成立一个专门的 SWAT 团队，负责确定可能的解决方案。

• SWAT 团队可以迅速成为 CCoE 的首次实验，需要与主要云供应商进行初步讨论，了解可能的发展路径。

• 对组织的利益相关者来说，必须清楚现代化项目不仅仅是技术问题，还涵盖整个组织，包括其人员。

• 当组织决定踏上这一旅程时，一切都始于对当前足迹的分析，并确定可能的目标架构。这通常由 CCoE 团队执行。

• 通常，组织会发布 RFP 以全方位了解跳入云端意味着什么。

• 通常邀请顶级云供应商，并且他们通常基于四个步骤共享一个共同的愿景：云基础设施的开发，快速成功的迁移，迁移的履行 和 现代化。

• 发布招标的公司分析了不同的提案，并将最终名单缩减为两家供应商。

• 一旦组织的 CCoE 完成了初步分析阶段，并在本地环境中确定了问题，顶级供应商候选人将实施 PoC 以展示云在改善特定用例中的力量。

• 最终，组织决定选择一个特定（单一或多个）的云供应商，并实施新平台，通过一系列用例扩展其当前的足迹，以提高服务的整体质量和用户体验。

感谢您的阅读。我们希望您在本书中学到的内容能够对您在公共云上建立企业数据平台或在企业数据平台上构建数据驱动产品时有所裨益。

¹ 实际数字很难确定，因为有几位顾问轮换进入和退出项目，并且每位顾问都是兼职，同时为多个客户工作。最初，外部顾问的数量在 5 到 10 人之间，后来变为 2 到 3 人。

² 需要注意的是，为了实现这一点，必须向所有 STB 设备发送专门的固件更新。