《Architecting Data and Machine Learning Platforms》第一章：现代化您的数据平台：入门概览

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

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

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

数据生命周期

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

通往智慧的旅程

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

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

水管类比

为了更好地理解数据生命周期，可以将其想象成一个简化的水管系统。水源始于一个引水渠，然后通过一系列管道进行传输和转化，最终到达一组房屋。数据生命周期类似，数据在被收集、存储、处理/转换和分析之前会经过一系列步骤，最终用于做出决策（见图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的查询语言的强大功能进行更精细和定制的分析。此外，可能还有数据科学家，他们可以利用机器学习技术从数据中提取有意义的见解，发现模式和相关性，提高对客户的理解和定位，从而提高企业的收入、增长和市场地位。

激活

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

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

这三种场景的技术堆栈是不同的。对于自动操作，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-4）导致了混乱。

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

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

反模式：集中控制

为了解决数据分散、分散并通过特定任务的数据处理解决方案进行管理的问题，一些组织尝试将一切都集中到由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]等）的采用。

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

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

混合云的挑战