《Architecting Data and Machine Learning Platforms》第六章：使用企业数据仓库进行创新

第3章中，您了解到在云数据平台的核心组件中选择数据湖还是数据仓库取决于您的组织是以工程/科学为先（选择数据湖）还是以分析为先（选择数据仓库）。在第5章中，我们专注于数据湖作为数据平台设计的中心元素的概念。在本章中，您将学习如何使用现代数据仓库作为中心元素来解决成本、民主化、灵活性和治理等相同的问题。

我们将首先快速回顾构建数据平台时要解决的问题，并讨论使云数据仓库成为一个吸引人的解决方案的技术趋势。然后，我们将深入探讨现代数据仓库架构的特点，以及如何有效地为数据分析师和数据科学家提供支持。

现代数据平台

每当您开始进行大型技术项目时，首先应该问自己您想要实现什么业务目标，您当前的技术挑战是什么，以及您想要利用哪些技术趋势。在本节中，我们将重点帮助您了解在构建现代数据平台时如何回答这些问题，以及企业数据仓库方法如何引导您的数据平台设计焦点。许多这些概念在先前的章节中已经涉及到，但将它们在这里重新构架将有助于您将现代数据仓库的设计与架构解决的问题联系起来。

组织目标

在我们的客户访谈中，CTOs 反复提到以下组织目标的重要性：

1. 无隔阂

   • 数据必须在整个企业范围内得以激活，因为业务的一个部分需要访问其他部门创建的数据。例如，确定明年产品设计的产品经理可能需要访问由零售运营团队创建和管理的交易数据。

2. 民主化

   • 数据平台必须支持领域专家和其他非技术用户，他们可以在不经过技术中介的情况下访问数据，但应能够依赖数据的质量和一致性。

3. 可发现性

   • 数据平台必须支持数据工程师和其他技术用户，他们需要在不同处理阶段访问数据。例如，如果我们有一个数据集，其中已经调整了原始的传入交易数据，数据科学家需要能够获取已调整的数据集。如果他们无法发现它，他们将重新构建一个调整例程。因此，应该能够发现所有这些"中间"数据集，以便在整个组织中不重复处理步骤。

4. 管理

   • 数据集应该由了解它们的团队控制。例如，财务数据应由财务部门控制，而不是由 IT 部门控制。

5. 单一来源

   • 数据应该在原地读取。最小化数据的复制和提取。

6. 安全性和合规性

   • IT 应该作为数据的经纪人，确保只有具有适当权限的人可以访问它。必须实施法规要求的所有合规性检查（例如 GDPR、CCPA、格拉姆-利奇-布莱利法案）。确保实施将数据分类为敏感/受限数据与开放或行业特定数据的解决方案。

7. 易用性

   • 使报告更容易，因为有数百名分析师正在创建支持各种功能的报告。

8. 数据科学

   • 使数据科学团队更具生产力，因为这些角色往往既昂贵又难以招聘。

9. 灵活性

   • 使决策者更快地获得见解。

虽然这些目标在组织之间的相对顺序有所不同，但所有这些目标在我们接触的每个组织中以某种方式出现。因此，现代数据平台应使CTOs能够实现这些目标。

技术挑战

在实现这些目标时，CTO们使用组织内已部署的技术时面临哪些障碍呢？CTO们通常提到以下技术挑战：

• 规模和规模

他们的组织收集的数据量随着时间的推移急剧增加，并预计将继续增加。他们目前的系统无法扩展，并无法保持在业务的速度和成本限制内，从而导致妥协，例如对传入数据进行抽样或严重优先考虑新数据项目。

• 复杂的数据和用例

越来越多的收集到的数据是非结构化数据，如图像、视频和自然语言文本。他们目前用于管理结构化和非结构化数据的系统没有交集。然而，需要在推荐等用例中将结构化数据（例如产品目录详情）和非结构化数据（例如目录图像、用户评论）一起使用。

• 集成

随着时间的推移，我们看到技术领域涌现了许多新的数据源和数据接收端，组织希望并应该利用这些资源。例如，他们希望在Salesforce中管理销售信息，在Adobe中管理广告活动，在Google Analytics中管理网页流量。有必要同时分析和决策所有这些数据。

• 实时性

许多新数据是实时收集的，能够在数据到达时处理并做出决策具有竞争优势。然而，组织没有一个无缝支持流式处理的数据平台。

这当然只是传统大数据挑战的一个更具细化的版本：数据的规模、多样性（数据和系统）、速度。

技术趋势和工具

为实现组织的业务和技术目标，云架构师可以利用前几章描述的趋势和工具。为了方便起见，我们在这里对它们进行了总结：

1. 计算和存储的分离 公共云提供商允许您将数据存储在Blob存储中，并从临时计算资源中访问它。这些计算资源包括Google BigQuery、AWS Redshift、Snowflake、Amazon EMR、Google Dataproc、Cloud Dataflow或Databricks等自定义构建或调整的软件，它们利用了计算与数据处理的分离，并在多个工作节点上分布数据处理。它们涵盖结构化和非结构化数据。
2. 多租户 云计算资源被设计为允许多个租户。因此，不需要为组织中的每个部门创建独立的集群或存储阵列。因此，两个不同的部门可以将其数据存储在单个DWH中，并从它们各自支付的计算资源中访问彼此的数据，每个团队都可以在共享的通用数据集上启动自己的分析。同样，组织可以使用其计算资源访问来自多个组织的数据并对连接的数据集进行分析。与传统的Hadoop集群不同，不必在与数据共同运行计算工作负载。
3. 身份验证和授权的分离 云IAM解决方案可以确保中央IT团队在数据所有者控制访问的同时确保身份的安全性。事实上，通过提供对组的访问，可以允许访问组织来管理成员资格，而数据所有者仅管理提供何种访问的业务逻辑。
4. 分析中心 无服务器DWH（以及正如我们在上一章中看到的数据湖）使架构师能够打破组织边界之外的数据孤立。虽然数据所有者支付存储费用，但数据使用者支付查询费用。此外，虽然数据所有者决定了哪些组具有访问权限，但组的成员资格可以由数据使用者管理。因此，合作伙伴和供应商可以共享数据，而不必担心查询成本或组成员资格。
5. 跨云语义层 诸如Informatica或Looker之类的工具可以创建一个跨超大规模云（例如AWS、GCP或Azure）、多云数据平台（例如Snowflake或Databricks）和本地环境的语义层。语义层可以实时重写查询，以提供一致和连贯的数据字典。（请注意，语义层将在本章后面更详细地讨论。）
6. 一致的管理界面 数据fabric解决方案在公共云上提供一致的管理体验，无论数据存储在DWH中还是以Parquet文件的数据湖格式存储在Blob存储中。
7. 跨云控制面板 诸如BigQuery Omni之类的工具提供了一个一致的控制面板和查询层，无论您的组织使用哪个超大规模云（AWS、GCP或Azure）来存储数据。如果关心确保可以使用相同的工具，而不管特定数据集存储在哪个超大规模云中，这些工具是有用的。这是与GCP控制面板的增加依赖性的权衡。
8. 多云平台 Snowflake、Confluent和Databricks提供了在任何超大规模云上运行相同软件的能力。然而，与前一个项目不同，不同云上的运行时仍然是不同的。如果关心确保可以从一个超大规模云转移到另一个超大规模云，这些工具是有用的。这是对单一来源软件供应商增加依赖性的权衡。
9. 数据湖和DWH的融合 联邦和外部查询使得可以在DWH上运行Spark作业以及在数据湖上运行SQL查询。我们将在下一章对这个主题进行扩展。
10. 内建ML 像AWS Redshift和Google BigQuery这样的企业DWH提供了在不移动数据出DWH的情况下进行ML训练和运行ML的能力。Spark具有ML库（Spark MLlib），并且ML框架（如TensorFlow）在Hadoop系统中得到支持。因此，ML可以在数据平台上进行，而无需提取数据到单独的ML平台。
11. 流式摄取 诸如Kafka、AWS Kinesis、Azure Event Hub和Google Cloud Pub/Sub之类的工具支持实时将数据着陆到超大规模云的数据平台。诸如AWS Lambda、Azure Functions、Google Cloud Run和Google Cloud Dataflow之类的工具还支持在数据到达时对数据进行转换，以进行质量控制、聚合或语义上的纠正，然后将数据写出。
12. 流式分析 DWH支持流式SQL，因此只要数据实时着陆在DWH中，查询就会反映最新的数据。
13. 变更数据捕获 诸如Qlik、AWS Database Migration Service和Google Datastream之类的工具提供了捕获操作关系数据库（例如在AWS关系数据库服务[RDS]上运行的Postgres或在Google Cloud SQL上运行的MySQL）更改并实时流式传输到DWH的能力。
14. 嵌入式分析 可以使用Power BI等现代可视化工具将分析嵌入到最终用户使用的工具（手机或网站）中，而无需让最终用户操作仪表板。
15. 枢纽和辐条体系结构提供了实现CTO期望目标并利用上述技术能力的经过验证的方法。

枢纽和辐条架构

在设计围绕数据仓库的现代云数据平台时，枢纽和辐条是理想的架构。在这种架构中，数据仓库充当一个集线器，收集所有用于业务分析的数据。辐条是自定义的应用程序、仪表板、ML 模型、推荐系统等，通过标准接口（即 API）与数据仓库进行交互。工具如 Sigma Computing、SourceTable 和 Connected Sheets 甚至提供了一种电子表格界面，模拟了在数据仓库顶部运行的 Excel。所有这些辐条都可以直接从数据仓库访问数据，而无需复制。

我们建议这种方法适用于没有遗留技术需要适应的初创公司，希望进行全面改建以实现全面转型的组织，甚至大型企业，因为它具有可伸缩性、灵活性和弹性。

它是可伸缩的，因为新的（现代的）数据仓库可以轻松集成新的数据源和用例到现有的基础设施，而无需重新配置整个系统。它是灵活的，因为您可以定制整体架构以满足企业的特定需求（例如，启用流处理）。而且它是弹性的，因为它可以承受比其他架构更多的故障。 现代的云原生企业数据仓库形成了枢纽和辐条架构的中枢，而辐条是数据提供者和数据消费者，如图 6-1 所示。请在阅读以下段落时参考图中的组件。

面向分析的数据和 ML 能力涉及将原始数据加载到数据仓库（企业数据仓库）中，然后根据需要进行转换以支持各种需求。由于计算和存储的分离，数据仅有一个唯一的副本。不同的计算工作负载，如查询（查询 API）、报告/交互式仪表板（商业和智能报告工具）和 ML（数据科学和 ML 工具），都可以在数据仓库中的这些数据上运行。由于可以利用 SQL 进行所有转换，因此可以使用视图和物化视图进行详细说明，从而无需进行 ETL 流水线。这些视图可以调用外部函数，从而允许使用 ML API 和模型对数据进行增强。在某些情况下，甚至可以仅使用 SQL 语法训练 ML 模型，并且可以通过简单的 SQL 命令调度复杂的批处理流水线。现代数据仓库甚至支持直接摄取（加载 API）流式数据（流式 API），因此只有在需要对数据执行低延迟、窗口聚合分析时，才必须利用流水线。始终记住评估解决方案的最终成本并将其与您将获得的收益进行比较。有时一种策略（批处理）可能比另一种策略（流处理）更好，反之亦然。

枢纽和辐条架构的关键思想是尽可能高效地将所有数据引入企业数据仓库。当数据来自 SaaS 软件（如 Salesforce）时，可以通过计划的自动导出机制加载数据。而当数据来自操作性数据库（如 Postgres）时，可以通过 CDC 工具实时接收数据。同时，实时数据源预计在发生新事件时将新数据发布到数据仓库。某些数据源是联合的（联合数据集），这意味着您将动态查询并将其视为数据仓库的一部分。现在，所有企业数据都在逻辑上成为数据仓库的一部分，数据科学和报告工具可以对数据进行操作（存储 API/查询 API）。

如果您没有需要迁移的现有 ETL 流水线或需要支持的现有终端用户工具选择，那么枢纽和辐条是简单、强大、快速和经济有效的。Google Cloud 上这种架构的一个示例呈现在图 6-2 中。其他超大规模云提供了更多选项（例如 AWS 上的 Athena、Redshift、Snowflake）；我们将在第 7 章中介绍这些变体。

在其完全自动化的形式中，枢纽和辐条对于没有强大工程技能的企业以及进行影子 IT 的小部门来说是一个很好的选择，因为在数据摄取方面几乎没有代码需要维护。此外，您只需了解 SQL 就可以完成数据科学和报告活动。

值得注意的是，支持面向分析的数据仓库的这些功能都是最近的发展。计算和存储的分离随着公共云的出现而产生：此前，大数据范式由 MapReduce 主导，该范式需要将数据分片到本地存储。分析工作负载需要构建业务特定的数据集市。由于性能限制，需要在将数据加载到这些数据集市之前进行转换（即 ETL）。存储过程是数据仓库，而不是外部函数，它们本身依赖于无状态微服务的自动缩放的发展。ML 部署需要捆绑和分发库，而不是无状态的 ML API。ML 工作流基于独立的训练代码，而不是由容器化组件组成的 ML 流水线。流处理涉及不同的代码库，而不是统一的批处理和流处理。

现在您已经了解了枢纽和辐条架构的基本概念，让我们深入探讨其主要组成部分：摄取、商业智能、转换和 ML。

数据摄取

枢纽与辐条架构中的一个辐条（在图 6-1 中围绕企业数据仓库的方框）对应于将数据（或进行摄取）传送到数据仓库的各种方式。有三种摄取机制：预建连接器、实时数据捕获和联合查询。我们将在本节分别讨论每种机制。

预建连接器

将数据导入数据仓库可以变得非常简单，尤其是在利用流行的SaaS平台时，因为它们提供了自动导入数据的连接器，只需点击几下即可。每个云原生数据仓库（如Google BigQuery、AWS Redshift、Snowflake、Azure Synapse等）通常都支持SaaS软件，例如Salesforce、Google Marketing Platform和Marketo。如果您使用的软件不受您选择的数据仓库支持，可以查看软件供应商是否提供到您选择的数据仓库的连接器，例如Firebase（一个移动应用平台）可以直接将移动应用的崩溃报告导出到BigQuery进行分析（"crashlytics"）。

您可以设置这些SaaS服务将数据推送到常见的数据仓库（例如Salesforce将自动将数据推送到Snowflake），或者使用BigQuery数据传输服务等服务将这些数据集导入数据仓库。这通常被称为Zero ETL------正如无服务器并不意味着没有服务器，只是服务器由其他人管理一样，Zero ETL意味着ETL过程由您的SaaS供应商或您的数据仓库供应商管理。 第三个选择是使用提供连接器的第三方供应商，例如Fivetran。他们的预建连接器提供了一种轻松集成来自营销、产品、销售、财务等应用程序的能力（见图6-3）。

通过云提供商的传输服务、支持云连接器的软件供应商以及第三方连接器供应商，您可以购买（而不是构建）定期从SaaS系统导出数据并将其加载到企业数据仓库的能力。

实时数据

如果您希望您的数据仓库能够实时反映变化，您需要利用一组较小的工具，称为CDC工具。操作性数据库（Oracle、MySQL、Postgres）通常是其中的一部分，企业资源规划（ERP）工具如SAP也是支持的。确保这些工具使用DWH的Streaming API以近实时的方式加载数据。在Google Cloud上，Datastream是推荐的CDC工具，在AWS上则是Database Migration Service（DMS）。

如果您有实时数据源，例如点击流数据或来自物联网设备的数据，请寻找一种能够使用DWH的Streaming API将事件实时发布的能力。由于Streaming API可以通过HTTPS访问，所以您只需要一种在事件发生时调用HTTPS服务的方式。

如果您的物联网设备提供商不支持推送通知，那么请寻找一种将事件发布到消息队列（例如使用消息队列遥测传输或MQTT），并使用流处理器（在GCP上使用Dataflow，在AWS上使用Kinesis）将这些事件写入DWH的方法（参见图6-4）。

联邦数据

你甚至可能无需将数据加载到数据仓库中即可使用它。现代云数据仓库能够在标准格式（如Avro、CSV、Parquet和JSONL（逐行JavaScript对象表示法））的数据集上运行查询，而无需将数据移到数据仓库中。这被称为联邦查询，通常要求数据格式是自描述的，或者模式被预先指定。例如，让Google BigQuery对Avro文件执行联邦查询包括以下三个步骤：

1. 使用bq mkdef --source_format=AVRO gs://filename创建一个表定义文件，并在必要时编辑默认值。例如，您可能会更改Avro中的整数字段，使其被视为实数。
2. 使用生成的表定义文件使用bq mk --external_table_definition mydataset.mytablename创建一个BigQuery数据集。
3. 像正常的SQL一样查询数据集。

请注意，数据仍然以Avro格式保存在Cloud Storage中。这就是这被称为联邦查询的原因。如果数据格式不是自描述的，则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. 像正常一样查询模式。

在所有这些情况中，关键要注意的是数据仍然保持在原地，并且从那里进行查询，而不是加载到数据仓库中。由于当数据保持原地时（无法进行分区、聚类等），进行联邦查询和外部查询的优化机会更有限，因此它们往往比本地查询慢一些。 鉴于联邦查询和外部查询较慢，为什么要使用它们？为什么不简单地将数据加载到数据仓库中并将数据仓库视为真实数据的来源？有一些情况下，避免移动数据可能是有利的：

1. 在某些情况下，数据仓库内的存储费用可能高于其外部存储。对于很少查询的数据，将数据保留在联邦数据源中可能更具成本效益。当需要最佳性能时，请使用数据仓库解决方案提供的本机存储系统。如果相反，灵活性更为重要，则尝试利用联邦数据源。
2. 如果关系数据库中的数据经常更新，将关系数据库视为黄金来源可能是有利的。从操作性数据库到数据仓库进行CDC可能会引入不可接受的延迟。
3. 数据可能是由工作负载（如Spark）创建或需要的。因此，可能需要维护Parquet文件。使用联邦/外部查询限制了数据的移动。当您已经拥有数据湖时，这是最常见的用例。
4. 数据可能属于与查询它的组织不同的组织。联邦查询很好地解决了这个问题。但是，假设您正在使用完全无服务器的数据仓库，比如Google BigQuery，它不是基于集群的。在这种情况下，即使是对本机存储，也可以直接提供对合作伙伴和供应商的访问。

最后一种情况是我们建议使用完全无服务器的数据仓库的原因之一，它不要求您将数据移动到集群、创建数据提取或提供特定应用程序（而不是特定用户）访问数据。 现在您对数据摄入的可用选项有了更好的了解，让我们深入了解如何通过查看我们可以在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方法。

可视化

您的SQL查询将生成表格。然而，仅仅从原始表格中获得理解和见解可能是困难的。相反，您通常会将结果绘制成图形、图表或地图。可视化SQL查询结果通常是引发洞察力的原因。

在探索性数据分析中，可视化是临时的。然而，可视化必须帮助使用常见的图表元素回答常见问题。这是Tableau、Looker、Power BI和Looker Studio等仪表板工具的职责。

优秀的仪表板考虑受众，并讲述故事。它们既可以作为当前状态的高层概述，也可以作为进一步交互式分析的起点。它们使用适当形式的图表显示上下文相关的重要指标。

嵌入式分析

通过传统的仪表板工具进行可视化足以与少数内部人员共享分析结果。这些用户会欣赏仪表板提供的丰富控件和互动性。但如果您是手工艺市场或电信运营商，并且希望每位艺术家或每个摊位都能够查看其自己商店性能的近实时图表呢？

当您为数千用户提供定制报告时，您不希望向最终用户提供一个功能丰富的仪表板界面，因为这可能难以支持和维护。相反，您需要一个轻量级的图形可视层，可以嵌入到用户已经在使用的工具中。通常将分析嵌入到艺术家用于上架商品或摊位运营用于订购新商品的网站或移动应用程序中。

为商店性能提供一致的实时指标可以显著提高艺术家和运营商在您的市场上赚钱的能力。还可以更好地连接工作流程，例如，使用分析，卖家可能能够轻松调整经常缺货商品的价格。提供诸如预测产品需求之类的机器学习功能还可能为市场带来新的收入来源。

语义层

自助分析和一致性之间存在紧张关系。赋予公司内每位业务分析师快速创建仪表板的能力是重要的，而不必等待中央IT团队。同时，保持仪表板在计算方面的一致性至关重要（例如，运输成本在各个仪表板中必须以相同的方式计算）。尽管业务分析师能够自己构建复杂的仪表板很重要，但他们尽可能地重复使用现有的可视化也同样重要。提供一致性和重复使用的传统方法是在IT内部集中计算和基础能力。然而，在数据驱动的环境中，这种集中式的以IT为中心的解决方案通常过于脆弱且速度太慢，无法满足业务用户的需求。

现代BI工具如Looker或MicroStrategy提供了一个语义层（参见第2章）来解决这种紧张关系。语义层是一种额外的层，允许您通过常用的业务术语自主访问数据；它通过表创建者采用的术语与业务用户采用的名称之间的解耦来工作。LookML是Looker称之为语义模型层的一种基于SQL的数据语言（见示例6-1）。它为数据管理者提供了创建可重复使用的维度或度量，业务分析师可以重复使用和扩展的能力。这些定义在数据字典中提供，方便进行发现和管理。

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的语义层，而不是直接连接到DWH。

尽管业务用户通常不会直接看到或与类似LookML的工具进行交互，但他们可以构建使用定义的维度和度量的仪表板。这有助于促进重复使用，使每个分析师都无需为他们使用的每个维度或度量从基本表列中定义。集中定义度量还可以减少人为错误的可能性，并提供可以更新定义的单一点。在文本文件中存在这样一个集中的定义允许轻松进行版本控制。

您已经了解了如何通过BI工具的帮助深入挖掘数据，并通过语义层帮助业务用户自主管理数据。有时，这种方法还不足以满足需求，您需要在开始将数据摄取到DWH之前对数据进行准备。在接下来的部分，我们将重点关注这个主题。

转换

假设您将来自ERP系统的原始数据摄取到DWH。如果ERP是SAP，列名很可能是德语的，并反映了应用程序状态，而不是我们认为有用于持久化的数据。我们不希望强迫所有用户每次需要数据时都必须将数据转换为可用形式。那么转换应该在哪里进行呢？

一种选择是在语义层中定义列的转换方式，该语义层是您BI工具的一部分，正如前一节所讨论的那样。但是，这将定义限制为维度和度量，而从非BI工具访问这些定义将会很困难。

更好的方法是在SQL中定义转换并创建视图、表或材料化视图。在本节中，我们将查看在DWH内处理转换的常见选项。这是"中心辐射"架构的另一个优势：当在DWH中实施数据转换时，结果立即对所有需要它们的用例可用。

第三种方法是利用超大规模云提供商上可用的应用程序开发平台。使用事件机制（Eventarc、EventBridge、Event Grid）在创建新表分区时启动一个无服务器函数（Lambda、Cloud Functions）。然后，该函数可以通过调用其API将转换后的数据"推送"到后端系统，从而启动业务操作（例如发货通知）。这被称为反向ETL，因为数据流的方向是远离DWH。

使用视图的ELT

与ETL不同，可以将数据按原样加载到DWH中，并在通过视图读取时即时对其进行转换（见示例6-2）。由于视图在将数据加载到DWH后即时进行转换（在加载之前不进行转换），因此这通常被称为提取-加载-转换（ELT），与典型的ETL工作流形成对比。

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为业务用户提供了对原始数据的一致、受控的视图。因为最终查询在进一步聚合或选择之前运行视图查询，所以所有查询都反映了基于DWH中存在的任何数据的最新信息。

然而，就计算资源、时间和/或金钱而言，视图可能会变得相当昂贵。例如，考虑示例6-2中显示的连接销售订单表和销售领域的视图。在此视图中，正在查询业务的整个历史期间所有领域的所有销售订单。即使查询视图的分析师只关注特定年份或地区（在这种情况下，过滤掉不相关的数据然后执行联接是有意义的），这也是如此。

预定查询

如果表的更新频率较低，定期将数据提取到表中可能更为高效。例如，在Google BigQuery中，如示例6-3中所述，我们指定目标表、查询运行频率和查询本身。

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小时。通过更频繁地运行定期查询，可以减少查询的过时程度。当然，定期查询的频率越高，成本优势就越容易消失。定期查询的另一个缺点是，如果最终的目标表从未被查询，它们可能会是一种浪费。

物化视图

很明显，平衡过时数据和成本的最有效方法是在首次请求视图时将原始数据提取到目标表中。随后的查询可以很快，因为它们可以从目标表中检索数据而无需进行任何提取。与此同时，系统需要监视基础表，并在原始表更改时重新提取数据。您还可以通过使用新的原始数据行更新目标表而不是重新查询整个表来使系统更加高效。

虽然您可以构建一个数据工程流水线来执行所有这些操作，但现代云DWH在开箱即用时就支持完全托管的物化视图。在这些系统中创建物化视图类似于创建实时视图（见示例 6-4），您可以像查询任何其他视图一样查询它。DWH会确保查询返回最新的数据。DWH供应商会对管理物化视图收取一些费用。

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;

然而，请注意一些DWH（例如Amazon Redshift，在撰写本文时）不会自动为您管理物化视图；您需要设置一个计划或触发器来刷新物化视图。从这个意义上说，他们所谓的物化视图实际上只是一个表提取。

Google BigQuery、Snowflake、Databricks和Azure Synapse会透明地维护物化视图内容。随着数据被添加到底层表中，视图内容会自动更新。

安全性和血统

数据治理的最佳实践是确保组织从数据摄取到使用的所有数据转换都能被跟踪。

一个需要考虑的重要方面与识别哪些资源（例如，整个数据集或表中的某些字段）需要被视为敏感并需要通过设计进行保护有关。不仅要防止访问公司内部应视为机密的信息，甚至要准备好根据一些在某些情况下变得越来越严格的政府法规正确地管理数据（例如，欧洲的GDPR，美国的《健康保险可移植性与责任法案》或HIPAA等）。需要注意的是，在谈论安全性和合规性时，焦点不应仅限于谁访问了什么（这可以通过精细的访问控制列表[ACL]策略管理方法和数据加密/伪装技术来解决）；它还应该集中在：

• 数据的起源
• 在其被使用之前应用的不同转换
• 当前物理数据位置（例如，德国的数据湖或英国的DWH）

追踪这类元数据被称为数据血统，它有助于确保正在使用准确、完整和可信的数据来推动业务决策。查看数据血统在需要保证数据局部性的情况下也很有帮助，因为由于某些本地法规（例如，在德国的电信元数据中），如果您可以追踪数据在其生命周期中的位置，那么您可以实施自动化来防止那些不符合最低要求的人访问、使用和移动该信息。

正如您所见，元数据在帮助公司组织其数据并管理其访问方面起着中心作用。它对于以准确性、完整性、一致性和新鲜度为标准评估所收集数据的质量也至关重要：低质量的数据可能导致错误的业务决策和潜在的安全问题。有几种技术和相关工具可以支持数据质量活动，但最常见的是：

• 标准化：将来自不同来源的数据放入一致的格式中的过程（例如，修复大小写不一致性、字符更新、错误字段的值、数据格式等）
• 重复数据删除：识别重复记录（利用相似度得分）并随后删除重复的值的过程
• 匹配：查找数据集之间的相似性或关联以发现潜在的依赖关系的过程
• 个人资料和监控：识别一系列数据值（例如，最小值、最大值、平均值），揭示可能需要进行数据修复或模式演变的异常和异常

如果您使用云供应商的本机托管服务执行数据转换，工具通常会管理并携带元数据。因此，如果您使用例如Google Cloud上的Data Fusion、视图、物化视图等，Data Catalog将得到更新并保持血统。如果使用Dataflow构建转换管道，则应更新Data Catalog。同样，爬虫将自动更新AWS上的Data Catalog，但是如果实施自己的转换，则需要调用Glue API以添加到目录中。

您已经了解了DWH（我们体系结构中的中心）如何推动数据转换，使其对您想要实现的所有用例都可用，同时保持您需要维护强大的所有加工的血统的元数据。现在让我们看看如何构建组织结构的结构以匹配中心和辐射架构。

组织结构

在许多组织中，业务分析师的数量通常远多于工程师，通常的比例是100：1。对于希望构建主要服务业务分析师的数据和机器学习平台的组织来说，Hub-and-Spoke架构是理想的选择。由于Hub-and-Spoke架构假定业务分析师能够编写自定义的SQL查询和构建仪表板，因此可能需要一些培训。

在以分析师为先的系统中，中央数据工程团队负责（参见图6-7中的填充形状）：

1. 将原始数据从各种来源加载到数据仓库（DWH）中。许多来源可以配置为直接发布到现代数据仓库。
2. 确保数据治理，包括语义层和个人身份信息（PII）的保护。
3. 处理涉及业务单元跨越的工作负载（例如激活），涉及业务单元间数据的工作负载（例如身份解析），或需要专业工程技能的工作负载（例如机器学习）。
4. 管理常见的工件存储库，如数据目录、源代码存储库、秘密存储、特征存储和模型注册表。

业务单元负责（参见图6-7中的未填充形状）：

1. 从业务特定来源加载数据到数据仓库。
2. 将原始数据转换为可用于下游分析的形式。
3. 向治理目录和工件注册表中填充业务特定的工件。
4. 为业务决策制定报告、自定义分析和仪表板。

图6-7显示了Google Analytics、财务和Salesforce作为数据源的示例。在我们的示例中，Google Analytics的数据可能需要跨多个业务单元使用，因此由中央数据工程团队进行摄取。财务和Salesforce数据仅由特定的业务单元使用，因此由该业务单元进行摄取。

每个业务单元管理自己的部署。中央团队的责任是将数据加载到业务团队使用的数据仓库中。这通常意味着中央团队使用的软件需要在不同的云环境中具有可移植性，并且由管道生成的数据格式是可移植的格式。因此，Apache Spark和Parquet通常是构建ETL管道的常见选择。

如果两个业务单元选择使用相同的数据仓库技术，那么在这两个业务单元之间共享数据就变得更简单了，因此，在可能的情况下，我们建议在整个组织中使用相同的数据仓库技术（如BigQuery、Snowflake、Redshift等）。然而，在通过收购进行业务扩展的企业中，这并不总是可能的。根据我们的经验，最好使用单一的云技术作为您的数据仓库，以充分发挥其在所有部门中的能力，即使您采用多云战略。我们曾与一些利用两种甚至更多技术的组织合作过，但他们在维护所有系统之间的一致性上所付出的努力并不值得其中的好处。

在本节中，您已经了解了如何通过实施Hub-and-Spoke架构来现代化您的数据平台，将您的数据仓库置于中心位置。您了解了多个"辐条"是如何围绕中央枢纽，即现代数据仓库，以实现批处理和流处理的任何用例，利用纯SQL语言，并符合数据治理要求。在接下来的章节中，我们将讨论数据仓库如何使数据科学家能够进行其活动。

数据仓库（DWH）以支持数据科学家

数据分析师通过对数据进行临时分析以创建报告，然后通过商业智能（BI）将报告操作化，以支持数据驱动的决策。数据科学家旨在利用统计学、机器学习和人工智能自动化和扩展数据驱动的决策。现代云数据仓库（DWH）对数据科学家和数据科学工具有哪些需求呢？正如您在图6-1中所见，他们需要以各种方式与DWH进行交互，以执行查询或仅仅获取对低级数据的访问权限。在本节中，我们将研究他们可以利用的最常见工具，以实现这一目标。

正如您在前一章中所看到的，数据科学家需要进行实验，尝试不同形式的自动化，并了解自动化如何在历史数据的各个切片上运作。正如我们之前所见，数据科学家用于实验的主要开发工具是笔记本。因此，他们需要以高效的方式访问DWH中的数据，无论是通过DWH的查询界面进行的探索性数据分析，还是通过DWH的存储界面进行的操作化（请参阅图6-1）。确保您的云DWH支持这两种机制非常重要。让我们看看这些机制是如何工作的。

查询接口

在自动化决策之前，数据科学家需要进行大量的探索性数据分析和实验。这需要以交互方式进行。因此，需要一种快速的方式从笔记本中调用SQL查询。

Jupyter魔法（例如图6-8中单元格中的%%bigquery行）提供了一种无需样板代码即可从笔记本中调用SQL查询的方法。结果以一种称为DataFrame的本机Python对象返回，可以使用pandas（一种数据分析函数库）进行操作。

重要的是要注意，这是在不创建数据的内存提取的情况下完成的。云数据仓库以分布式方式执行SQL查询。笔记本服务器不需要运行在与数据仓库相同的计算基础设施上。

利用数据仓库后端进行大规模数据处理以及笔记本前端的编程和可视化能力的结合对于数据科学家的高效工作是强大且必要的。

存储API

虽然笔记本与数据仓库连接的交互能力对于探索和实验非常重要，但这并不是自动化所需的。对于自动化而言，数据访问速度至关重要。机器学习框架应该能够绕过查询API，直接访问数据仓库的存储层。存储访问应支持从多个后台线程并行读取数据，因为通常情况下，在ML加速器（GPU或TPU）对前一批数据进行繁重计算的同时，会读取下一批数据。

因此，与其使用查询API，不如使用机器学习框架支持的存储API，以高效且并行的方式从数据仓库中读取数据。在示例6-5中展示了使用Spark和TensorFlow从Google BigQuery中使用Storage API读取数据的方法。

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是数据科学家用来访问数据仓库进行分析的两种方法。现在有一个新的趋势需要考虑------在不必提取数据的情况下，直接在数据仓库中实现、训练和使用机器学习算法的能力。在接下来的部分，我们将看看它是如何工作的。

在不移动您的数据的情况下进行机器学习

一些现代的云数据仓库（例如BigQuery和Redshift，截至撰写本文时）还支持在数据仓库中对数据进行机器学习模型训练，而无需首先提取数据。它们通过在SQL中训练简单模型，并通过分别将任务委托给Vertex AI和SageMaker来训练更复杂的模型来实现这一点。让我们看看如何直接从您的数据仓库利用训练和服务（称为激活）您的机器学习算法。

训练ML模型

假设您想要训练一个机器学习模型，以预测用户在给定账户特征和账户费用的情况下是否会流失：可以利用历史数据来完成所有操作，如示例6-6所示。训练的模型类型可以非常复杂。

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所示。

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语句编写的异常检测系统。

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进行机器学习而无需设置数据移动，使得更广泛的组织能够进行预测性分析。这使机器学习变得更加民主化，因为借助典型的商业智能工具，数据分析师现在可以实施预测。这还显著提高了生产力------如果只需要两行SQL而不是需要熟练掌握TensorFlow或PyTorch的数据科学家进行为期六个月的项目，那么组织更有可能能够识别异常活动。

ML训练和服务

训练机器学习模型并不是现代数据仓库支持的唯一机器学习活动。它们还支持以下功能：

• 将经过训练的机器学习模型导出为标准机器学习格式，以在其他地方进行部署。
• 将机器学习训练纳入数据仓库作为更大机器学习工作流的一部分。
• 调用机器学习模型作为外部函数。
• 直接加载机器学习模型到数据仓库，以便以分布式方式高效调用机器学习预测。

让我们一起看看这四种活动，它们为何重要，以及现代数据仓库如何支持它们。

导出经过训练的机器学习模型

在数据仓库中训练的机器学习模型可以通过ML.PREDICT在批处理模式下直接对历史数据进行调用。然而，对于需要实时结果的现代应用程序（例如，基于连接的用户，决定在页面中显示哪些广告的电子商务应用程序），这样的能力是不够的。有必要能够在线调用模型，即作为对单个输入或一小组输入的同步请求的一部分。

在Redshift中，您可以通过将模型部署到SageMaker端点来实现这一点，在Google Cloud中则通过以SavedModel格式导出模型。然后，您可以将其部署到支持此标准机器学习格式的任何环境中。当然，支持Vertex AI端点，还支持SageMaker、Kubeflow Pipelines、iOS和Android手机以及Coral Edge TPUs。Vertex AI和SageMaker支持部署为微服务，并且通常用于基于服务器的应用程序，包括网站。部署到流水线支持流数据处理、自动交易和监控等用例。部署到iOS和Android支持移动电话，而部署到Edge TPUs则支持定制设备，例如汽车仪表板和信息亭。

在机器学习流水线中使用您训练的模型

很少有数据科学家的实验仅包括训练一个机器学习模型。通常，一个实验将包括一些数据准备、训练多个机器学习模型、进行测试和评估、选择最佳模型、创建模型的新版本、在小部分流量上设置A/B测试以及监控结果。只有其中的一些操作是在数据仓库中完成的。因此，在数据仓库中完成的步骤必须成为更大的机器学习工作流的一部分。

机器学习实验及其工作流程被捕捉在机器学习流水线中。这些流水线包含许多容器化步骤，其中少数涉及数据仓库。因此，当数据准备、模型训练、模型评估等成为机器学习流水线的一部分时，它们必须作为容器可调用。

流水线框架提供了方便的函数，以在云数据仓库上调用操作。例如，要从Kubeflow Pipelines中将BigQuery作为容器化操作调用，您可以使用BigQuery运算符。

调用外部机器学习模型

如今，机器学习是理解非结构化数据（如图像、视频和自然语言文本）的常用方法。在许多情况下，已经存在许多种类非结构化内容和用例的预训练机器学习模型，例如，已有预训练的模型可用于检测某些评论文本是否包含有害言论。您无需训练自己的有害言论检测模型。因此，如果您的数据集包含非结构化数据，能够对其进行机器学习模型的调用非常重要。

例如，在Snowflake中，可以使用EXTERNAL FUNCTION调用Google Cloud的Translate API。通过通过网关创建API集成，然后配置Snowflake，可以按照示例6-9中演示的步骤完成这一操作。

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 ...

加载预训练的机器学习模型

使用外部函数调用机器学习模型可能效率较低，因为计算没有充分利用数据仓库的分布式性质。更好的方法是加载已训练的机器学习模型，并使数据仓库在其自己的计算环境中调用该模型。

在BigQuery中，您可以首先加载TensorFlow模型，然后通过在SELECT语句中使用ML.PREDICT来调用它，如示例6-10中所示。

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工具。
• 当你有数千到数百万的客户时，提供一个轻量级的图形可视化层更具可扩展性，可以嵌入到用户已经使用的工具中。
• 建立一个语义层来捕获关键业绩指标（KPIs）、度量和维度，以促进一致性和重用。
• 视图提供了一种使落入数据仓库的原始数据更易用的方式。将查询调度到表中以提取视图内容可能更具成本效益。物化视图则兼具两者的优点。
• 随着数据的爆炸，架构变得更加复杂，访问和利用数据的用户数量增加，立法者正在引入更严格的规则来处理数据，数据治理和安全性变得更加重要。
• 数据科学家需要能够从笔记本交互式地访问数据仓库，在没有样板代码的情况下运行查询，并直接从数据仓库的存储中批量访问数据。
• 能够在不进行任何数据移动的情况下进行机器学习，并使得到的机器学习模型能够在许多环境中使用，有助于在业务的许多部分推动AI的使用。
• 在组织层面，一些数据工程和治理功能是集中的，但不同的业务部门以不同的方式转换数据，仅在需要时进行。

在下一章中，我们将讨论数据湖和数据仓库世界的融合，看看现代平台如何利用这两种范式的优势，为最终用户提供最大的灵活性和性能。