第一章：现代化您的数据平台：入门概览-灵析社区

攻城狮无远

数据是一项宝贵的资产，可以帮助您的公司做出更明智的决策，发现新的机会，并改进业务运营。谷歌在2013年启动了一项战略项目，旨在通过提高管理质量来提高员工留任率。即使像管理技能这样宽泛的概念也可以以数据驱动的方式进行研究。通过分析1万份绩效评价，识别高绩效经理的共同行为，并创建培训计划，谷歌成功将管理青睐度从83%提高到88%。亚马逊也进行了一项战略性的数据项目。这家电商巨头实施了一个基于客户行为的推荐系统，该系统在2017年推动了35%的购买。旧金山的篮球队勇士队是另一个例子；他们实施了一个分析计划，帮助他们一举成为联赛的佼佼者。这些例子——员工留任、产品推荐、提高胜率——都是通过现代数据分析实现的业务目标。

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

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

数据生命周期

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

通往智慧的旅程

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

  1. 收集 数据必须被获取并注入到目标系统中（例如，手动数据录入、批量加载、流式摄取等）。
  2. 存储 数据需要以可持续的方式存储，并且能够在未来轻松访问（例如，文件存储系统、数据库）。
  3. 处理/转换 数据必须被操纵以使其对后续步骤有用（例如，清理、整理、转换）。
  4. 分析/可视化 数据需要被研究，通过手动加工（例如，查询、切片和切块）或自动处理（例如，使用ML应用程序编程接口进行丰富）来得出业务见解。
  5. 激活 在形式和位置上展示数据洞察，使决策能够被做出（例如，作为特定手动操作的触发器的通知，当满足特定条件时自动执行的作业，向设备发送反馈的ML模型）。

这些阶段中的每一个都向下一个阶段提供输入，类似于水通过一组管道流动。

水管类比

为了更好地理解数据生命周期，可以将其想象成一个简化的水管系统。水源始于一个引水渠，然后通过一系列管道进行传输和转化，最终到达一组房屋。数据生命周期类似，数据在被收集、存储、处理/转换和分析之前会经过一系列步骤，最终用于做出决策（见图1-1）。

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

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

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

既然我们已经定义了数据生命周期并总结了数据从原始数据收集到激活的旅程的各个阶段，让我们逐个深入了解数据生命周期的五个阶段。

采集

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

Volume（容量） 数据的大小是多少？通常在处理大数据时，这意味着以TB（千兆字节）或PB（拍字节）为单位的数据。

Velocity（速度） 数据输入的速度是多少？通常以MB/s（兆字节/秒）或TB/day（千兆字节/天）为单位。这通常被称为吞吐量。

Variety（多样性） 数据的格式是什么？表格、平面文件、图像、声音、文本等。

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

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

存储

在这一步骤中，存储您在前一步中收集的原始数据。您不对数据进行任何更改，只是存储它。这很重要，因为您可能希望以不同的方式重新处理数据，而为此您需要有原始数据。

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

可扩展性

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

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

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

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

性能与成本

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

将最重要且访问频率最高的数据（热数据）存储在高性能存储系统中，例如数据仓库的本地存储。将不太重要的数据（冷数据）存储在成本较低的存储系统中，例如云存储（它本身有多个层次）。如果您需要更高的性能，比如用于交互式用例，您可以使用缓存技术将热数据的有意义部分加载到一个易失性存储层中。

高可用性

高可用性意味着在请求时具有运行和提供对数据的访问的能力。通常通过硬件冗余来实现，以应对可能的物理故障/中断。在云中，通过将数据存储在至少三个可用性区域来实现这一目标。这些区域可能并非物理上分开（即它们可能在同一个“园区”），但往往会有不同的电源等。硬件冗余通常被称为系统正常运行时间，现代系统通常具有四个9或更多的正常运行时间。

耐久性

耐久性是在长期内存储数据而不会遭受数据退化、损坏或彻底丢失的能力。通常通过在物理上分开的位置存储数据的多个副本来实现。在云中，通过将数据存储在至少两个区域（例如在伦敦和法兰克福）来实现这一目标。在面对自然灾害时，这在处理数据恢复操作时变得极为重要：如果底层存储系统具有很高的耐久性（现代系统通常具有11个9），那么除非发生灾难性事件使得即使是物理上分开的数据中心也宕机，否则所有数据都可以恢复而不会出现问题。

开放性

尽量使用非专有且不会造成封锁效应的格式。理想情况下，应该能够使用多种处理引擎查询数据，而无需生成数据的副本或将其从一个系统移动到另一个系统。也就是说，可以使用使用专有或本地存储格式的系统，只要它们提供方便的导出功能。

与大多数技术决策一样，开放性是一种权衡，专有技术的回报率可能足够高，以至于您愿意承担封锁的代价。毕竟，转向云的原因之一是为了降低运营成本，这些成本优势在完全托管/无服务器系统中往往比在托管的开源系统中更高。例如，如果您的数据用例需要事务，Databricks（使用基于Parquet的准开放存储格式Delta Lake）的运营成本可能比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）的《自助数据路线图》一书的第10章。

分析/可视化

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

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

激活

这是最终用户能够根据数据分析和机器学习预测做出决策的步骤，从而实现数据决策过程。从提取或预测的见解中，现在是采取一些行动的时候。

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

  1. 自动操作 自动化系统可以使用推荐系统的结果向客户提供定制推荐，从而通过增加销售额帮助业务的顶线。
  2. SaaS集成 通过与第三方服务集成可以执行操作。例如，一家公司可能会实施一项营销活动，试图降低客户流失率。他们可以分析数据并实施倾向模型，以识别可能对新商业报价做出积极响应的客户。然后，客户电子邮件地址列表可以自动发送到营销工具，以启动活动。
  3. 警报 您可以创建实时监视数据的应用程序，并在满足某些条件时发送个性化消息。例如，定价团队可能在访问某个商品列表页面的流量超过某个阈值时接收到主动通知，从而使他们可以检查商品是否定价正确。

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

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

传统方法的局限性

传统上，组织的数据生态系统包括用于提供不同数据服务的独立解决方案。不幸的是，这些专用的数据存储解决方案有时可能规模庞大，可能导致组织内部形成信息孤岛。由此产生的信息孤岛系统是独立的解决方案，它们无法以高效的方式协同工作。信息孤岛中的数据是沉默的数据，从中难以获取洞察。为了拓宽和统一企业智能，跨业务部门安全共享数据至关重要。

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

一种解决方案是开发一个统一的数据平台，更确切地说，是一个云数据平台（请注意，统一并不一定意味着集中，稍后将讨论）。数据平台的目的是允许在整个组织的所有数据上以一致、可扩展和可靠的方式进行分析和机器学习。在这样做时，您应该尽可能地利用托管服务，以便组织可以专注于业务需求而不是操作基础架构。基础设施的运营和维护应完全委托给底层的云平台。在本书中，我们将介绍在开发一个可扩展和可靠的平台来整合跨业务部门的数据时，您需要做出的核心决策。

反模式：通过ETL打破信息孤岛

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

通常，会定期使用ETL工具从事务性数据库中提取最新的交易并将其存储在分析存储中，以供仪表板访问。然后进行标准化。为了进行分析而对每个数据库表创建ETL工具，这样就可以在不必每次都访问源系统的情况下执行分析（见图1-3）。


跨组织捕获所有数据的中央分析存储，根据使用的技术而定，被称为DWH或数据湖。这两种方法之间的高级区别基于系统内部存储数据的方式：如果分析存储支持SQL并包含经过管控的、经过质量控制的数据，则被称为DWH。相反，如果它支持Apache生态系统中的工具（如Apache Spark）并包含原始数据，则被称为数据湖。有关称为介于两者之间的分析存储（例如经管控的原始数据或未管控的质量受控数据）的术语因组织而异，有些组织称其为数据湖，而其他组织则称其为DWH。正如您将在本书后面看到的，这种混乱的词汇不是问题，因为数据湖（第5章）和DWH（第6章）方法正在汇聚成为被称为数据湖仓（第7章）的东西。

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

  1. 数据质量：ETL工具通常由数据的使用者编写，这些使用者往往对数据的了解程度不及数据的所有者。这意味着很多时候提取的数据不是正确的数据。
  2. 延迟：ETL工具引入了延迟。例如，如果用于提取最近交易的ETL工具每小时运行一次，并且运行需要15分钟，那么分析存储中的数据可能在75分钟内变得陈旧。通过流式ETL可以解决这个问题，其中事件在发生时即时处理。
  3. 瓶颈：ETL工具通常涉及编程技能。因此，组织建立了专门的数据工程团队来为ETL编写代码。随着组织内数据的多样性增加，需要编写越来越多的ETL工具。数据工程团队成为组织利用数据能力的瓶颈。
  4. 维护：ETL工具需要由系统管理员定期运行和进行故障排除。底层基础设施系统需要持续更新，以应对增加的计算和存储容量，并确保可靠性。
  5. 变更管理：输入表模式的更改要求更改ETL工具的提取代码。这使得变更变得困难，或者导致ETL工具被上游更改破坏。
  6. 数据缺失：很可能必须将许多错误升级到数据的所有者、ETL工具的创建者或数据的使用者。这增加了维护开销，并且很多时候工具停机时间较长。由于这个原因，数据记录中通常存在很大的缺陷。
  7. 管理：随着ETL流程的增多，越来越有可能由不同的流程执行相同的处理，从而导致相同信息的多个源。随着时间的推移，这些流程通常会发散，以满足不同的需求，导致为不同的决策使用不一致的数据。
  8. 效率和环境影响：支持这些类型转换的基础设施是一个问题，因为它通常是全天候运行的，产生了显着的成本，并增加了碳足迹的影响。

前面列表中的第一点（数据质量）经常被忽视，但随着时间的推移，它往往是最重要的。通常需要在数据“可信”可用于生产之前对数据进行预处理。来自上游系统的数据通常被认为是原始的，如果没有得到适当的清理和转换，它可能包含噪音甚至是错误的信息。必须专门为手头的任务构建数据处理工具。在考虑一个数据源时，这种情况是合理的，但总的收集（见图1-4）导致了混乱。


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

  1. 他们的DWH/数据湖无法满足不断增长的业务需求。
  2. 日益增长的数字化计划（以及与数字原生企业的竞争）已经将业务转变为系统中涌入大量数据的业务。
  3. 为不同的数据科学任务创建单独的数据湖、DWH和特殊存储最终会创建多个数据孤岛。
  4. 由于性能、安全性和治理方面的挑战，数据访问需要受到限制或受到限制。
  5. 由于需要更新许可证并支付昂贵的支持资源，因此变得具有挑战性。

很明显，这种方法无法满足新的业务需求，不仅因为技术复杂性，还因为这种模型涉及的安全性和治理要求。

反模式：集中控制

为了解决数据分散、分散并通过特定任务的数据处理解决方案进行管理的问题，一些组织尝试将一切都集中到由IT部门控制的单一的、单片的平台中。如图1-5所示，底层技术解决方案并没有改变，而是通过将问题交给一个组织来解决，使问题更容易解决。


由一个独特部门实施的这种集中控制方式带来了自己的挑战和权衡。所有业务单元（BUs）— IT 本身、数据分析和业务用户在 IT 控制所有数据系统时都会遇到困难：

IT IT 部门面临的挑战是这些数据孤岛涉及的各种技术。IT 部门很少拥有管理所有这些系统所需的所有技能。数据存储在本地和云端的多个存储系统中，管理 DWH、数据湖和数据集市的成本较高。跨不同来源定义安全性、治理、审计等内容也并不总是清晰。此外，这引入了一个获取数据访问权限的可伸缩性问题：IT 需要执行的工作量随着将作为一部分图像的源系统和目标系统的数量的增加而线性增加，因为这肯定会增加所有相关利益相关者/业务用户的数据访问请求。

分析 阻碍有效分析流程的主要问题之一是无法访问正确的数据。当存在多个系统时，将数据移动到/从单片数据系统变得昂贵，导致不必要的 ETL 任务等。此外，预先准备好并随时可用的数据可能没有最新的源，或者可能存在提供更深度和更广泛信息的其他版本的数据，例如拥有更多列或更精细的记录。由于数据治理和运营问题，不可能让您的分析团队自由发挥，每个人都可以访问所有数据。组织通常最终会通过限制数据访问来换取分析灵活性。

业务 获取业务可以信任的数据和分析结果是困难的。围绕限制您向业务提供的数据存在问题，以便确保最高质量。替代方法是开放访问业务用户所需的所有数据，即使这意味着牺牲质量。然后，挑战就变成了在数据质量和可信赖数据量之间取得平衡。往往情况是 IT 没有足够的合格的业务代表来推动优先事项和要求。这很快可能成为组织创新过程中的一个拖慢速度的瓶颈。

尽管存在这么多的挑战，一些组织在多年来采用了这种方法，导致了在获取他们需要履行任务的数据方面受到延迟的业务用户的挫败和紧张。受挫的业务单元通常通过另一种反模式来应对，即影子 IT——整个部门开发和部署有用的解决方案以绕过这些限制，但最终使数据孤立问题变得更糟。

有时会采用一种称为数据布局的技术方法。这仍然依赖于集中化，但数据布局是一个虚拟层，提供统一的数据访问。问题在于这样的标准化可能是一个沉重的负担，并且对于组织范围内对数据的访问来说可能会引入延迟。然而，数据布局对于试图访问客户专有数据的 SaaS 产品是一种可行的方法——集成专家提供了从客户模式到 SaaS 工具期望的模式的必要翻译。

反模式：数据集市和 Hadoop

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

由于可伸缩性和成本问题，基于 Apache Hadoop 生态系统的大数据解决方案应运而生。Hadoop 引入了使用低成本通用服务器进行分布式数据处理（横向扩展）的概念，使以前只能通过高端（非常昂贵）专用硬件实现的用例成为可能。在 Hadoop 顶部运行的每个应用程序都被设计为容忍节点故障，使其成为某些传统 DWH 工作负载的经济有效替代方案。这导致了一个称为数据湖的新概念的发展，迅速成为数据管理的核心支柱，与 DWH 一起。其思想是，在核心运营技术部门继续执行日常任务的同时，所有数据都被导出到一个集中的数据湖中进行分析。数据湖旨在成为分析工作负载和业务用户的中央存储库。数据湖已经从仅用于原始数据的存储设施发展为支持大量数据上进行高级分析和数据科学的平台。这使得整个组织能够进行自助式分析，但需要对高级 Hadoop 和工程流程有广泛的工作知识才能访问数据。与组织数据使用者无法理解的无治理数据混乱相结合，技能差距和数据质量问题意味着企业很难从本地数据湖中获得良好的投资回报。

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

创建一个统一的分析平台

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

选择云而非本地部署

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

然而，在本地环境中运行DWH和数据湖存在一些固有的挑战，例如扩展和运营成本。这促使组织重新考虑其方法，并开始将云（特别是公共云）视为首选环境。为什么呢？因为它允许它们：

  • 通过利用新的定价模型（按使用量付费模型）降低成本
  • 通过利用最先进的技术加快创新速度
  • 使用“突发”方法扩展本地资源
  • 通过在多个区域和地区存储数据来规划业务连续性和灾难恢复
  • 利用完全托管的服务自动管理灾难恢复

当用户不再受到基础设施容量的限制时，组织能够在其整个组织中实现数据的民主化并解锁洞察。云支持组织进行现代化改造，因为它通过卸载行政、低价值任务来最小化琐碎和摩擦。云数据平台承诺提供一个环境，在这里，您不再需要妥协，可以构建一个涵盖从数据收集到服务的端到端数据管理和处理阶段的全面数据生态系统。您可以使用云数据平台以多种格式存储大量数据，而无需妥协延迟。

云数据平台承诺：

  • 集中的治理和访问管理
  • 增加生产力和降低运营成本
  • 在整个组织中更大范围的数据共享
  • 不同角色的扩展访问
  • 访问数据时延迟减少

在公共云环境中，DWH和数据湖技术之间的界限变得模糊，因为云基础设施（具体而言，计算和存储的分离）实现了在本地环境中不可能的融合。今天可以将SQL应用于存储在数据湖中的数据，并且可以在DWH中存储的数据上运行传统的Hadoop技术（例如Spark）。在本节中，我们将为您介绍这种融合的基本原理，以及它如何成为可以彻底改变组织对数据看法的全新方法的基础；在第5到7章中，您将获得更多详细信息。

数据集市和数据湖的缺点

在过去的40年中，IT部门已经意识到数据仓库（实际上是数据集市）很难管理，并且可能变得非常昂贵。在过去运作良好的传统系统（例如本地的 Teradata 和 Netezza 设备）已经被证明很难扩展，非常昂贵，并且涉及与数据新鲜度相关的一系列挑战。此外，它们无法轻松提供现代功能，如访问 AI/ML 或实时特性，而不是在事后添加该功能。

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

数据湖并不像它们看起来那么简单和经济实惠。虽然它们理论上可以轻松扩展，但组织在规划和提供足够存储空间方面通常面临挑战，特别是如果它们产生高度变化的数据量。此外，在高峰期为计算能力进行规划可能很昂贵，导致不同业务部门之间争夺有限资源。

本地数据湖可能很脆弱，并需要耗时的维护。本应该开发新功能的工程师通常被降级为维护数据集群和为业务部门调度作业。对于许多企业来说，总体拥有成本通常高于预期。简而言之，数据湖并不创造价值，许多企业发现其投资回报率为负。

对于数据湖，治理并不容易解决，尤其是当组织的不同部分使用不同的安全模型时。然后，数据湖变得孤立和分段，使得难以在团队之间共享数据和模型。

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

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

鉴于这些权衡，许多公司最终采用混合方法，其中设置了一个数据湖以将一些数据升级到数据仓库，或者数据仓库有一个附加的数据湖用于额外的测试和分析。然而，由于多个团队正在构建适应其个别需求的数据架构，对于中央 IT 团队来说，数据共享和保真度变得更加复杂。

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

基于这一原则，数据行业开始转向一种新方法，即“lakehouse” 和“数据网格”（data mesh），它们能够很好地协同工作，因为它们有助于解决组织内的两个不同挑战：

  • Lakehouse 允许具有不同技能集（数据分析师和数据工程师）的用户使用不同的技术访问数据。
  • 数据网格允许企业创建一个统一的数据平台，而不是将所有数据都集中在 IT 部门——这样，不同的业务部门可以拥有自己的数据，但允许其他业务部门以高效、可扩展的方式访问它。

作为额外的好处，这种架构组合还带来了更严格的数据治理，这是数据湖通常缺乏的。数据网格赋予人们避免被一个团队拖慢的权力，从而启用整个数据堆栈。它将隔间打破成一个个较小的组织单元，在提供以联邦方式访问数据的架构中。

数据湖仓

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

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

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

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

  • 存储和计算的解耦，实现了： 廉价、几乎无限且无缝可扩展的存储 无状态、具有弹性的计算 支持ACID的存储操作 逻辑数据库存储模型，而非物理存储
  • 数据治理（例如，数据访问限制和模式演变）
  • 通过与商业智能工具的本地集成支持数据分析
  • 支持数据湖方法的典型多版本方法（即，青铜、白银和黄金）
  • 使用Apache Parquet和Iceberg等开放格式的数据存储和管理
  • 支持结构化或非结构化格式的不同数据类型
  • 具有处理数据实时分析的流式功能
  • 实现从商业智能到机器学习等各种工作负载的多样化应用

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

湖仓方法使组织能够实施一个支持任何类型工作负载的非常多样化数据平台的核心支柱。但是对于位于其之上的组织来说呢？用户如何充分利用平台的优势来执行他们的任务呢？在这种情况下，有一个新的运营模型正在形成，那就是数据网格。

数据网格

数据网格是一个技术、人员和流程的分散型运营模型，旨在解决分析中最常见的挑战之一——即在数据所有权必然分散的环境中对控制权进行集中的愿望，如图1-7所示。看待数据网格的另一种方式是，它引入了一种将数据视为自包含产品而非ETL流水线产品的方式。

在这种方法中，分布式团队拥有数据生成并通过明确定义的数据模式为内部/外部消费者提供服务。总体而言，数据网格建立在数据仓库和数据湖领域的创新基础之上，结合了与公共云中数据仓库技术相关的可扩展性、按消费付费模型、自助API和紧密集成。 通过这种方法，您可以有效地创建按需数据解决方案。数据网格将数据所有权分散给领域数据所有者，每个领域数据所有者都负责以标准方式提供其数据作为产品（见图1-8）。数据网格还支持组织内各个部分之间的通信，以在不同位置分发数据集。 在数据网格中，从数据中提取价值的责任被委托给最了解该数据的人；换句话说，创建数据或将其引入组织的人必须负责从他们创建的数据中创建可消耗的数据资产，将其作为数据产品。在许多组织中，由于在整个组织中反复提取和转换数据而没有对新创建的数据明确的所有权责任，建立“单一真相”或“权威数据源”变得棘手。在数据网格中，权威数据源是源领域发布的数据产品，有明确定义的数据所有者和数据监护人负责该数据。


从技术角度（lakehouse）和组织角度（数据网格）都能够访问这一统一视图意味着人们和系统能够以最适合其需求的方式获取数据。在某些情况下，这种体系结构必须跨越多个环境，从而产生了非常复杂的体系结构。让我们看看公司如何管理这一挑战。

混合云

在设计云数据平台时，可能一个单一的环境无法完全管理工作负载。这可能是由于法规约束（即，您无法将数据移动到组织边界之外的环境），或者由于成本（例如，组织在基础设施上进行了一些未达到寿命周期的投资），或者因为您需要的某种技术在云中不可用。在这种情况下，采用混合模式可能是一种可能的方法。混合模式是一种应用程序在各种环境中运行的模式。混合模式的最常见示例是将私有计算环境（如本地数据中心）与公共云计算环境结合在一起。在本节中，我们将解释这种方法在企业中的运作方式。

混合云是必要的原因

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

允许工作负载在公共云和私有云环境之间迁移提供了更高级别的灵活性和数据部署的额外选择。有几个原因推动混合（即跨越本地、公共云和边缘的体系结构）和多云（即跨越多个公共云供应商，如AWS、Microsoft Azure和Google Cloud Platform [GCP]等）的采用。

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

  1. 数据驻地法规： 由于一些行业或地区对数据存储位置有严格的法规要求，一些组织可能永远不会完全迁移到公共云。这也适用于那些在没有公共云存在和数据驻地要求的国家进行工作负载的情况。
  2. 遗留投资： 一些客户希望保护他们的遗留工作负载，如SAP、Oracle或Informatica在本地的情况，但又希望利用公共云创新，比如Databricks和Snowflake等。
  3. 过渡： 大型企业通常需要多年的过渡过程，将其现代化为云原生应用程序和架构。他们将不得不在多年的时间里采用混合架构作为中间状态。
  4. 云突发： 有些客户主要在本地，不想迁移到公共云。然而，由于临时大批量作业、繁忙时段的突发流量或大规模机器学习训练作业，他们在满足业务服务水平协议（SLA）方面面临挑战。他们希望利用公共云中可扩展的容量或自定义硬件，避免在本地基础设施上进行规模扩大的成本。采用“本地优先”计算方法的解决方案，比如MotherDuck，正在变得流行。
  5. 最佳选择： 一些组织选择在不同的公共云提供商中执行不同的任务，这是一种有意的策略，选择最能满足其需求的技术。例如，Uber使用AWS为其Web应用提供服务，但在Google Cloud上使用Cloud Spanner来运行其履行平台。Twitter在AWS上运行其新闻提要，但在Google Cloud上运行其数据平台。

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

混合云的挑战

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

  1. 治理 在多个环境中应用一致的治理政策很难。例如，在本地环境和公共云之间通常以不同方式处理合规性安全策略。通常，在本地和云中数据的部分重复。想象一下，如果组织正在运行财务报告，如果数据存在于多个平台上，如何保证使用的数据是最新更新的副本呢？
  2. 访问控制 用户访问控制和策略在本地和公共云环境之间有所不同。云服务提供商为其提供的服务有自己的用户访问控制（称为身份和访问管理，IAM），而本地使用诸如本地目录访问协议（LDAP）或Kerberos等技术。如何保持它们同步或在不同环境之间拥有单一的控制平面呢？
  3. 工作负载互操作性 在跨越多个系统时，不可避免地会有需要管理的不一致的运行时环境。
  4. 数据移动 如果本地和云应用程序都需要访问某些数据，那么这两个数据集必须保持同步。在多个系统之间移动数据成本高昂——需要人力成本来创建和管理管道，可能由于使用的软件而产生许可成本，最后但同样重要的是，它会消耗计算、网络和存储等系统资源。组织如何处理来自多个环境的成本？如何连接在各种环境中孤立的异构数据？在连接过程的结果中，数据最终存储在何处？
  5. 技能集 拥有两个云（或本地和云）意味着团队必须了解并建立在两个环境中的专业知识。由于公共云是一个快速发展的环境，因此在一个云中提升员工的技能，更不用说在两个云中了，都会产生显著的开销。技能集对于招聘系统集成商（SIs）也可能是一个挑战——尽管大多数大型SIs都有每个主要云的实践，但很少有团队了解两个或更多的云。随着时间的推移，我们预计雇佣愿意学习定制本地技术的人将变得越来越困难。
  6. 经济学 数据分布在两个环境之间可能带来意想不到的成本：也许您在一个云中有数据，想要将其提供给另一个云，从而产生出站费用。

尽管存在这些挑战，混合设置仍然是可行的。我们将在下一小节中看看如何解决这些问题。

为什么混合云可以奏效

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

  1. 选择 云服务提供商通常对开源技术做出重大贡献。例如，尽管 Kubernetes 和 TensorFlow 是在 Google 开发的，但它们是开源的，因此在所有主要云平台上都存在用于托管执行环境的版本，甚至可以在本地环境中使用。
  2. 灵活性 诸如 Databricks 和 Snowflake 的框架允许您在任何主要公共云平台上运行相同的软件。因此，团队可以学习一套在任何地方都适用的技能。需要注意的是，在多云环境中工作的工具所提供的灵活性并不意味着您已经摆脱了锁定。您将需要在（1）框架级别锁定和云级别灵活性之间进行选择（由 Databricks 或 Snowflake 等技术提供），以及（2）云级别锁定和框架级别灵活性之间进行选择（由云原生工具提供）。
  3. 开放性 即使工具是专有的，由于采用了开放标准和导入/导出机制，其代码也以可移植的方式编写。因此，例如，即使 Redshift 只在 AWS 上运行，但查询是用标准 SQL 编写的，并且存在多个导入和导出机制。综合考虑，这些功能使得 Redshift、BigQuery 和 Synapse 成为开放平台。这种开放性允许使用 Teads 等用例，其中数据使用 AWS 上的 Kafka 进行收集，使用 Google Cloud 上的 Dataflow 和 BigQuery 进行聚合，然后写回到 AWS Redshift（见图1-9）。


云服务提供商正在通过大力投资于开源项目，致力于提供选择、灵活性和开放性，以帮助客户在多个云中使用。因此，多云数据仓库或混合数据处理框架正在变为现实。因此，您可以构建更好的云软件生产、发布和管理，以实现您期望的混合和多云部署，而不是按照供应商的规定。

边缘计算

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

随着边缘计算的采用和走向主流，对于各行业来说有许多潜在的优势：

  1. 更快的响应时间 在边缘计算中，数据存储和计算的能力被分布并在需要做出决策的地方提供。不需要往返到云端可以降低延迟，实现更快的响应。在预防性维护中，它有助于阻止关键机器操作的故障或危险事件的发生。在活动游戏中，边缘计算可以提供所需的毫秒级响应时间。在欺诈防范和安全场景中，它可以防范隐私泄漏和拒绝服务攻击。
  2. 间歇性连接 在偏远资产（如油井、农田泵、太阳能场或风车）存在不可靠的互联网连接可能使监测这些资产变得困难。边缘设备在本地存储和处理数据的能力确保在互联网连接有限的情况下不会发生数据丢失或操作失败。
  3. 安全性和合规性 边缘计算可以消除设备和云端之间的大量数据传输。可以在本地筛选敏感信息，只将关键的数据模型构建信息传输到云端。例如，在智能设备中，监听诸如“OK Google”或“Alexa”的语音处理可以在设备本身上进行。潜在的私人数据无需收集或发送到云端。这使用户能够构建适用于企业安全性和审计的适当安全和合规框架。
  4. 经济实惠的解决方案 围绕物联网采用的一个实际关切是由于网络带宽、数据存储和计算能力而导致的前期成本。边缘计算可以在本地执行大量数据计算，使企业能够决定哪些服务在本地运行，哪些发送到云端，从而降低整体物联网解决方案的最终成本。这就是在类似 Rust 或 Go 等现代编译语言构建的 Open Neural Network Exchange（ONNX）格式中进行嵌入模型的低内存二进制部署可以发挥作用的地方。
  5. 互操作性 边缘设备可以充当传统和现代机器之间的通信联络点。这使得传统工业机器能够连接到现代机器或物联网解决方案，并立即从传统或现代机器中获得洞察力。

所有这些概念使得架构师在定义其数据平台时具有极大的灵活性。在第9章中，我们将更深入地探讨这些概念，并看到这种模式正在成为标准。

应用人工智能

许多组织因需要采用人工智能技术而被迫设计云数据平台——在设计数据平台时，确保其具备支持人工智能用例的未来性是非常重要的。考虑到人工智能对社会的巨大影响以及其在企业环境中的传播，让我们迅速深入了解如何在企业环境中实施人工智能。您将在第10章和第11章中找到更深入的讨论。

机器学习

如今，一种被称为监督机器学习的人工智能分支取得了巨大的成功，以至于人们更经常将术语“人工智能”用作该分支的总称。监督机器学习的工作原理是向计算机程序展示许多例子，其中正确答案（称为标签）是已知的。机器学习模型是一个标准算法（即完全相同的代码），具有可调参数，可以“学习”如何从提供的输入到标签。然后，这样一个学到的模型被部署用于对那些正确答案未知的输入进行决策。

与专家系统不同，不需要通过编程显式地将规则传递给人工智能模型以做出决策。由于许多现实领域涉及到专家难以表达其逻辑的人类判断，让专家简单地为输入示例打标签比捕捉其逻辑更为可行。

现代的国际象棋算法和医学诊断工具使用机器学习。国际象棋算法从人类过去玩过的游戏记录中学习，而医学诊断系统则通过专业医生为诊断数据打标签而学习。

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

为了使这些机器学习方法运作，它们需要大量的训练数据和现成的定制硬件。因此，采用人工智能的组织通常从构建云数据/机器学习平台开始。

机器学习的用途

机器学习在工业界取得惊人的普及有几个关键原因：

  1. 数据更容易获取。 获取标记数据比捕捉逻辑更容易。每一种人类推理都有难以编码的例外情况，这些例外情况会随着时间的推移而被编码。让一组眼科医生标记一千张图像比让他们描述如何识别血管出血更容易。
  2. 重新训练更容易。 当机器学习用于推荐物品给用户或运行营销活动等系统时，用户行为会迅速适应变化。持续训练模型变得很重要。这在机器学习中是可能的，但使用代码要困难得多。
  3. 更好的用户界面。 一类被称为深度学习的机器学习已被证明能够在非结构化数据（如图像、视频和自然语言文本）上进行训练。这些类型的输入通常很难进行编程。这使得您可以将真实世界的数据用作输入，比如考虑一下，当您只需拍摄支票的照片而无需在网页表单中键入所有信息时，存款检查的用户界面会变得更好。
  4. 自动化。 机器学习模型理解非结构化数据的能力使得许多业务流程可以自动化。表单可以轻松数字化，仪表盘可以更容易读取，工厂车间可以更容易监控，因为可以自动处理自然语言文本、图像或视频。
  5. 成本效益。 赋予机器理解和创建文本、图像、音乐和视频的机器学习API每次调用成本仅为几分之一，而雇佣人类执行这些任务的成本则高得多。这使得在推荐等情况下使用技术成为可能，而个人购物助手的成本则无法承受。
  6. 协助。 生成式人工智能可以使开发人员、营销人员和其他白领工作者更加高效。编码助手和工作流合作伙伴能够简化许多企业职能的部分，比如发送定制的销售电子邮件。

考虑到这些优势，不难理解哈佛商业评论的一篇文章发现，人工智能通常支持三个主要的业务需求：

  • 自动化业务流程，通常是自动化后勤行政和财务任务。
  • 通过数据分析获取洞察。
  • 与客户和员工互动。

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

为什么选择云进行人工智能？

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

云基础设施

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

为了让您了解完成现代机器学习模型训练所需的数据量，图像分类模型通常在一百万张图像上进行训练，而主要的语言模型则在多个 terabyte 的数据上进行训练。

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

许多最近的人工智能进步都可以归因于数据规模和计算能力的增加。云中大型数据集与支持它的众多计算机之间的协同作用已经促使机器学习取得了巨大的突破。这些突破包括将语音识别中的词错误率降低了30%，是传统方法中20年来取得的最大增益。

民主化

建模机器学习模型，特别是在复杂领域，如时间序列处理或自然语言处理（NLP），需要对机器学习理论有所了解。使用诸如PyTorch、Keras或TensorFlow等框架编写用于训练机器学习模型的代码需要了解Python编程和线性代数。此外，机器学习的数据准备通常需要数据工程专业知识，评估机器学习模型需要高级统计知识。部署机器学习模型和监控它们需要了解DevOps和软件工程（通常称为MLOps）。毫无疑问，很少有组织具备所有这些技能。鉴于此，对于传统企业来说，利用机器学习解决业务问题可能会很困难。

云技术提供了几种选项来使机器学习的使用民主化：

  1. 机器学习APIs： 云提供商提供可通过API调用的预构建机器学习模型。此时，开发人员可以像使用任何其他Web服务一样使用机器学习模型。他们只需具备针对表述状态转移（REST）Web服务进行编程的能力。此类机器学习API的示例包括Google Translate、Azure Text Analytics和Amazon Lex，这些API可以在不了解NLP的情况下使用。云提供商还提供用于文本和图像生成的生成模型作为API，其中输入只是文本提示。
  2. 可定制的机器学习模型： 一些公共云提供“AutoML”，即端到端的机器学习管道，只需点击鼠标即可进行训练和部署。AutoML模型执行“神经架构搜索”，通过搜索机制实质上自动进行机器学习模型的架构设计。虽然与人类专家选择有效模型相比，训练时间较长，但对于没有能力设计自己模型的业务线来说，AutoML系统足够使用。请注意，并非所有的AutoML都相同，有时所谓的AutoML只是参数调整。确保您获得的是定制的架构，而不仅仅是在预构建模型之间进行选择，并仔细检查哪些步骤可以自动化（例如，特征工程、特征提取、特征选择、模型选择、参数调整、问题检查等）。
  3. 简化的机器学习： 一些数据仓库（例如BigQuery和Redshift）提供了仅使用SQL对结构化数据进行机器学习模型训练的能力。Redshift和BigQuery通过分别委托给Vertex AI和SageMaker来支持复杂模型。诸如DataRobot和Dataiku之类的工具提供了用于训练机器学习模型的点对点界面。云平台使生成模型的微调比以前更容易。
  4. 机器学习解决方案： 一些应用非常常见，可以购买和部署端到端的机器学习解决方案。Google Cloud上的Product Discovery为零售商提供了端到端的搜索和排名体验。Amazon Connect提供了一个由机器学习驱动的可立即部署的联系中心。Azure Knowledge Mining提供了一种挖掘各种内容类型的方式。此外，Quantum Metric和C3 AI等公司为几个行业的常见问题提供了基于云的解决方案。
  5. 机器学习构建块： 即使整个机器学习工作流没有现成的解决方案，其中的部分工作可能仍然可以利用构建块。例如，推荐系统需要匹配项目和产品的能力。Google Cloud提供了一种称为“两塔编码器”的通用匹配算法。虽然没有端到端的后勤自动化机器学习模型，但您可以利用表单解析器更快地实现该工作流程。

这些功能使企业能够在没有深度专业知识的情况下采用人工智能，从而使人工智能更广泛地可用。即使企业具有人工智能方面的专业知识，这些功能也非常有用，因为您仍然需要决定是购买还是构建机器学习系统。通常情况下，机器学习的机会比解决这些问题的人更多。鉴于此，允许使用预构建工具和解决方案执行非核心功能具有优势。这些即插即用的解决方案可以立即提供大量价值，而无需编写定制应用程序。例如，可以通过API调用将自然语言文本的数据传递给预构建模型，将文本从一种语言翻译为另一种语言。这不仅减少了构建应用程序的工作量，还使非机器学习专家能够使用人工智能。在谱的另一端，问题可能需要自定义解决方案。例如，零售商通常会构建机器学习模型来预测需求，以便了解需要备货多少产品。这些模型通过公司的历史销售数据学习购买模式，结合内部专业直觉。另一个常见的模式是使用预构建的即插即用模型进行快速实验，一旦证明了ML解决方案的价值，数据科学团队就可以以定制的方式构建它，以获得更高的准确性，希望能够在竞争中脱颖而出。

实时

ML基础设施必须与现代数据平台集成，因为实时、个性化的机器学习是产生价值的地方。因此，分析速度变得非常重要，因为数据平台必须能够实时摄取、处理和提供数据，否则就会失去机会。这还需要与行动的速度相辅相成。机器学习推动基于客户上下文的个性化服务，但必须在客户上下文切换之前提供推断——在大多数商业交易中，机器学习模型需要在关闭窗口内为客户提供行动选择。为了实现这一点，您需要使机器学习模型的结果能够实时到达行动点。

能够实时为机器学习模型提供数据并在实时获取机器学习预测是防范欺诈和发现欺诈之间的区别。为了防范欺诈，需要实时摄取所有支付和客户信息，运行机器学习预测，并将机器学习模型的结果实时提供回支付站点，以便在怀疑欺诈时拒绝付款。

实时处理可以在其他情况下节省成本，例如客户服务和购物车放弃。在呼叫中心捕捉客户的不满并立即升级情况对于提供有效服务至关重要——一旦失去客户，重新获取他们将花费更多的钱，而在当下提供良好服务的成本较低。同样，如果购物车有被放弃的风险，提供5%的折扣或免费运输等诱因的成本可能会低于需要让客户回到网站所需的更大力度的促销。

在其他情况下，批处理根本不是一个有效的选择。为了使Google Maps允许驾驶员避开交通拥堵，需要实时交通数据和实时导航模型。

正如您将在第8章中看到的那样，云服务的弹性和自动扩展能力在本地很难实现。因此，最好在云中进行实时机器学习。

MLOPS

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

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

除了讨论的与数据相关的监控方面之外，您还需要对任何运行中的服务进行监控和运营化。生产应用程序通常是24/7/365持续运行的，定期会有新的数据进入。因此，您需要具备工具，使得轻松编排和管理这些多阶段的机器学习工作流程，并能够可靠地重复运行它们。

像Google的Vertex AI、Microsoft的Azure Machine Learning和Amazon的SageMaker这样的云AI平台提供了整个机器学习工作流的托管服务。在本地进行这项工作需要您自己组合底层技术并自行管理集成。

在编写本书时，MLOps功能正在以极快的速度添加到各种云平台上。这引出了一个附带的观点，即随着机器学习领域的快速变化，将构建和维护机器学习基础设施和工具的任务委托给第三方，并专注于与核心业务相关的数据和见解，会更为明智。

总而言之，基于云的数据和人工智能平台可以帮助解决与数据隔离、治理和容量相关的传统挑战，同时使组织能够为未来更加重要的人工智能能力做好准备。

核心原则

设计数据平台时，制定关键设计原则并确定希望分配给每个原则的权重可能会有所帮助。您可能需要在这些原则之间进行权衡，拥有一个所有利益相关者都同意的预定评分卡可以帮助您在不必返回第一原则或受到最强烈抗议声响影响的情况下做出决策。

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

  1. 提供无服务器分析，而不是基础设施。 为完全托管的环境设计分析解决方案，尽量避免搬移和转移的方法。专注于现代无服务器架构，使数据科学家（我们广义上使用此术语来指数据工程师、数据分析师和ML工程师）能够将注意力完全集中在分析上，远离基础设施考虑。例如，使用自动化数据传输从系统中提取数据并提供用于跨任何服务进行联合查询的环境。这消除了维护自定义框架和数据管道的需要。
  2. 嵌入端到端ML。 允许组织将端到端的ML操作化。不可能构建组织需要的每个ML模型，因此确保您正在构建的平台能够嵌入民主化的ML选项，如预建的ML模型、ML构建模块和更易于使用的框架。确保在需要自定义训练时，可以访问强大的加速器和可定制的模型。确保支持MLOps，以便部署的ML模型不会漂移并且不再适用。简化整个堆栈上的ML生命周期，以便组织可以更快地从其ML倡议中获取价值。
  3. 推动整个数据生命周期的分析。 数据分析平台应提供一套全面的核心数据分析工作负载。确保您的数据平台提供数据存储、数据仓库、流数据分析、数据准备、大数据处理、数据共享和变现、商业智能（BI）和ML等服务。避免购买需要集成和管理的临时解决方案。更全面地看待分析堆栈将允许您打破数据隔离，使用实时数据为应用程序提供动力，添加只读数据集，并使查询结果对任何人都可访问。
  4. 启用开源软件（OSS）技术。 在可能的情况下，确保开源是您平台的核心。您希望确保您编写的任何代码都使用开源标准，如标准SQL、Apache Spark、TensorFlow等。通过启用最佳的开源技术，您将能够在数据分析项目中提供灵活性和选择性。
  5. 为增长而构建。 确保您构建的数据平台能够满足组织预期面临的数据大小、吞吐量和同时用户数量的规模。有时，这将涉及选择不同的技术（例如，对于某些用例使用SQL，对于其他用例使用NoSQL）。如果这样做，请确保您选择的两种技术能够互操作。利用已被世界上最具创新性的公司证明并用于运行其关键任务的解决方案和框架。

总体而言，这些因素按照我们通常建议的顺序列出。由于企业选择进行云迁移的两个主要动机是成本和创新，我们建议您优先考虑无服务器（用于节省成本和使员工摆脱例行工作）和端到端ML（用于启用的广泛创新）。在某些情况下，您可能希望优先考虑某些因素而不是其他因素。对于初创公司，我们通常建议最重要的因素是无服务器、增长和端到端ML。为了加快速度，可以牺牲综合性和开放性。高度受监管的企业可能会优先考虑综合性、开放性和增长，而不是无服务器和ML（即监管机构可能要求在本地进行）。对于数字原生企业，我们建议按照端到端ML、无服务器、增长、开放性和综合性的顺序。

总结

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

  • 数据生命周期有五个阶段：收集、存储、处理、分析/可视化和激活。这些需要由数据和ML平台支持。
  • 传统上，组织的数据生态系统由独立的解决方案组成，导致组织内部产生数据孤岛。
  • 数据移动工具可以打破数据孤岛，但它们会带来一些缺点：延迟、数据工程资源瓶颈、维护开销、变更管理和数据缺失。
  • 在IT内部集中控制数据会导致组织面临一些挑战。IT部门没有必要的技能，分析团队得到质量较差的数据，业务团队不信任结果。
  • 组织需要构建云数据平台，以获取最佳架构、处理业务单元的整合、扩展本地资源并规划业务连续性。
  • 云数据平台利用现代方法，旨在通过重新构建数据、打破数据孤岛、使数据民主化、强制数据治理、实时决策和使用位置信息进行数据驱动创新，以及从描述性分析无缝过渡到预测性和规范性分析。
  • 所有数据可以从操作系统导出到一个集中的数据湖进行分析。数据湖充当分析工作负载和业务用户的中央存储库。然而，缺点是业务用户没有编写代码对抗数据湖的技能。
  • 数据仓库是支持SQL的集中式分析存储，业务用户熟悉这一点。
  • 数据湖仓库基于这样一个观念，即所有用户，无论其技术技能如何，都可以并且应该能够使用数据。通过提供一个使数据可访问的集中和基础框架，可以在湖仓库顶部使用不同的工具来满足每个用户的需求。
  • 数据网格引入了将数据视为独立产品的一种方式。在这种方法中，分布式团队拥有数据生成，并通过明确定义的数据模式为内部/外部消费者提供服务。
  • 混合云环境是满足企业现实情况的务实方法，如收购、当地法律和延迟要求。
  • 公共云提供管理大型数据集和按需提供GPU的方式，使其成为所有形式的ML，特别是深度学习和生成AI不可或缺的工具。此外，云平台提供了民主化、更容易操作和跟上技术进展的关键能力。
  • 云数据平台的五个核心原则是优先考虑无服务器分析、端到端ML、全面性、开放性和增长。相对权重将因组织而异。

现在您知道自己想要的方向，在下一章中，我们将探讨达到目标的策略。

阅读量：2100

点赞量：0

收藏量:0