在上一章中，我们探讨了当今生态系统中的现有实时系统，并介绍了三个不同的数据层面：操作层面、分析层面和流处理层面。操作层面和分析层面主要处理静态数据，侧重于静态信息。相比之下，流处理层面则独特地以动态数据为特征，是唯一涉及“运动中的数据”的领域。

在本章中，我们将深入探讨流处理层面，以及数据架构师和工程师如何开始思考它在简化实时分析中的作用。

我们经常将异步、数据流动和流处理等术语相互关联，并将它们视为可以互换的表达方式。它们都是指长期运行的过程，这些过程持续进行转换，简化并加快应用程序获取实时分析数据的速度。

图9-1展示了在第7章中贯穿始终的维恩图中仅包含流处理层面的部分。在本章中，我们将多次引用该图表。

本章将探讨几个关键主题，以理解流处理层面上实时数据处理的复杂性。其中一个重点是操作层面的分析（或称操作分析）的概念，它深入探讨了在操作层面靠近应用程序执行分析工作负载的实践。此外，我们还将扩展到数据本地性的各个方面，研究数据与其处理环境的地理接近性如何影响整个系统的性能。理解数据本地性对于优化资源利用率和减少流处理分析场景中的延迟至关重要。

另一个我们将探讨的关键主题是数据复制，这是流处理层面上的一项基础策略。数据复制涉及在多个节点或全球区域内的数据复制，促进了去中心化。我们还将讨论受数据网格启发的数据产品概念，探讨如何利用实时分析生成可在全球范围内复制、供本地消费的有价值数据产品。

通过探索这些重要主题，读者将了解流处理层面所呈现的多方面挑战和机遇，并找到在全球流处理分析环境中设计弹性和高效系统的关键解决方案。

数据引力

将数据想象成一个星球。当数据累积质量时，它会像引力吸引月球到地球一样，吸引服务和应用程序，并防止它们漂离。例如，当你在社交媒体上发布消息时，你创建了数据。你的消息提交给了一个服务，该服务吸引了你朋友的互动，并创造了更多的数据。

在一个未考虑流处理层面的数据架构中，操作层面会直接将数据推送到分析层面。可以将操作层面想象成围绕着一个密集星球（即分析层面）运行的月球。操作层面的“月球”将数据推送到这个“星球”。随着更多操作层面的“月球”将数据发送回分析层面“星球”，这个“星球”逐渐成为一个庞大的历史数据系统。工作负载开始受到数据规模的影响，导致延迟增加。

正如我们在前几章中提到的那样，数据从操作层面到分析层面的移动是一个单向的下游流动。强迫数据逆流而上是很困难的。另一种看法是数据引力的概念。

图9-2展示了一个未考虑流处理层面的典型数据架构。操作层面作为外围的节点存在，将数据发布到代表地球的分析层面。

随着越来越多的操作系统将数据发送到分析层面，分析层面逐渐成为一个庞大的历史数据系统。分析层面的工作负载开始受到数据规模的影响，这导致分析过程出现更多延迟，并无法再提供实时数据分析。

如果你的数据架构中包含流处理层面，情况就有所不同。操作层面的“月球”不再直接将数据推送到“星球”，而是将数据推送到流处理层面内的“卫星”。这些“卫星”提供了一种方法，可以在更接近操作层面的“月球”处实现分析，同时将数据产品传送到“星球”。这减弱了引力的影响。流处理层面提供了所需的流动性，使数据能够回流到操作层面，以便为用户提供实时分析。

在图9-3中，可以将流处理层面中的物化视图数据想象成围绕“星球”（或分析层面）运行的“卫星”。你可以像从卫星上观看直播电视节目一样，从这些物化视图中消费实时数据。类似于观看直播电视节目，流处理层面中的数据可以在全球范围内提供服务。

流处理层面提供了一种方法，使分析能够更接近操作层面进行，同时将构成这些分析的数据产品全球化地传递。它减弱了数据引力的影响，同时仍然为分析层面提供了归档和大规模批处理所需的增量数据。

流处理层面的组件

图9-4展示了当今流处理层面的多个解决方案和系统。在本章中，我们将利用这张图来帮助描述构成流处理层面的系统，以及它们如何促进数据去中心化和实时分析。

图9-4显示了位于两端的熟悉的操作层面和分析层面，它们被流处理层面（表示为云）分隔开来。流处理层面由两个组成其基础的组件支撑：流处理平台（如Kafka）和源/汇连接器。图9-4中的双向箭头标识了这些组件。正是基于这一基础，流处理层面的其他组件才能消费实时数据。

流处理器、RTOLAP数据库和流处理数据库都从Kafka中读取数据，以转换并提供实时分析数据。流处理器和流处理数据库还可以将分析数据写回Kafka，使它们能够在其他层面上构建分析数据的副本。

流处理层面分为一致性和最终一致性的流处理和实时系统。流处理层面的系统会迁移到其各自的一致性位置，并在其消费层面附近执行工作负载。在流处理层面的左侧是操作分析。在流处理层面的右侧，我们有能够容忍最终一致性的内部分析，并能够访问所有历史数据。

总结来说，以下是流处理层面的组成部分：

• 流处理平台（如Kafka）
• 源和汇连接器
• 流处理器（如Flink）
• RTOLAP数据库
• 流处理数据库

在设计实时分析的数据基础设施时，架构师需要考虑一致性以及消费分析的用户角色。

流处理层面的基础设施

在构建操作层面、分析层面和流处理层面的基础设施时，架构师应考虑为每个层面提供独立的基础设施。为操作层面和分析层面提供专用基础设施一直是标准做法。由于流处理层面是本书引入的新概念，架构师可能不会明显意识到需要为流处理层面提供专用基础设施。相反，架构师可能会考虑将流处理系统部署到现有的操作或分析层面，特别是因为流处理系统通常不会长时间持久化数据。

专用基础设施有很多理由。表9-1列出了其中的一部分。

表9-1. 为数据系统提供专用基础设施的原因

原因	描述
可扩展性	随着数据量的增长，架构师需要设计能够扩展以处理增加的数据负载而不影响性能的基础设施。这包括选择适当的硬件、数据库和其他可以轻松水平或垂直扩展的组件。
性能	专用基础设施使架构师能够优化特定数据相关任务的性能。这包括对数据处理速度、查询性能和整体系统响应能力的考虑。
可靠性和可用性	架构师设计基础设施以确保数据系统在需要时可靠和可用。这包括冗余、故障转移机制和灾难恢复计划，以尽量减少停机时间和数据丢失。
安全性	保护敏感数据是首要任务。专用基础设施允许架构师实施强有力的安全措施，包括访问控制、加密和定期审计，以防止未经授权的访问和网络威胁。
集成	在许多组织中，数据系统需要与各种应用程序、服务和平台集成。专用基础设施促进了无缝集成，确保数据能够在整个组织中高效地共享和使用。
合规性	根据行业的不同，可能会有关于数据存储和处理的法规要求。架构师必须设计符合这些法规的基础设施，以避免法律问题和罚款。
成本效率	为数据系统分配特定的基础设施资源可以帮助架构师优化成本。他们可以选择最具成本效益的存储解决方案、处理单元和网络组件，以满足数据系统的具体需求。
数据治理	基础设施在执行数据治理政策方面起着关键作用。架构师可以设计跟踪和执行数据质量、完整性和一致性的系统，确保数据可靠且准确。

专用基础设施的重点是有效地管理、存储、处理和访问数据。流处理层面不会长时间存储数据，而是在规模上处理和移动数据。为流处理系统提供专用基础设施对于确保有效、安全和可靠的动态数据管理，支持其各种功能和战略目标至关重要。

在流处理层面持久化的任何数据都是短暂的——是临时或短期的。流处理层面的流动性保持了数据的新鲜度，并限制了数据引力的影响。其处理能力为操作层面提供了分析工作负载。

操作分析

操作分析指的是在数据生成源附近（通常在或接近用户面对的应用程序）收集、处理和分析数据，而不仅仅依赖于分析层面的系统。操作分析指的是在生成数据的应用程序或微服务附近执行分析工作负载。它们通过利用流处理层面的大规模运行异步进程的能力来实现这一点。

你可能会想，“为什么要在操作层面执行分析工作负载？”这个问题是合理的，尤其是因为我们在第3章中讨论了将这些工作负载分离的许多原因。

以下是将分析工作负载移至操作层面的几个原因：

• 实时决策 操作分析使组织能够从数据中实时获得洞察。这对于做出快速且明智的决策至关重要，而这些决策会影响正在进行的操作。
• 提高效率 通过在操作系统中嵌入分析功能，组织可以简化流程并减少手动干预的需求。操作工作流中的自动化分析可以提高效率并减少处理时间。
• 改善客户体验或个性化 实时分析使组织能够根据客户当前的行为和偏好来个性化互动。这可以显著提升整体客户体验。
• 主动解决问题和预测性分析 操作分析通常包括预测建模，帮助组织在问题升级之前识别潜在问题。这种主动方法允许及时干预和问题解决。
• 节省成本和优化资源 通过将分析集成到操作系统中，组织可以优化资源分配，例如人力资源、库存或设备。这可以带来成本节约和资源利用率的提高。

总的来说，将分析工作负载移至操作层面的驱动力在于敏捷性、实时决策的需求，以及在正在进行的业务操作背景下直接提取可操作洞察的愿望。这种集成使组织能够更加数据驱动，并对其操作环境中的快速变化做出响应。

操作层面的基础设施不具备分析层面基础设施所拥有的存储所有历史数据的能力。在操作层面上执行的分析工作负载只能有限地访问历史数据。操作系统的规模也有限制，因此即使它们能够访问历史数据，它们也只能消耗其中的一小部分。

将历史数据从分析层面传送到操作层面以供分析工作负载使用可能很困难。数据引力的影响是显著的，并且不仅适用于数据。它也适用于处理数据的应用程序。由于这些影响，构建操作分析的解决方案可能会变得复杂。在第10章中，我们将讨论获取历史数据的解决方案。

尽管存在这些限制，将分析更接近应用程序和数据源使其成为不断发展的实时分析领域中的一种有价值的模式。回想第6章中的玩具银行用例，作为操作分析一部分使用的流处理器或流处理数据库需要具有一致性。异步处理交易流并将其实时反馈回应用程序的可能性极高。不一致的后果可能会产生严重影响，并导致对应用程序的信任丧失，正如我们在第6章中演示的那样。

Materialize.io的首席科学家Frank McSherry（也是一名计算机科学家）谈到了信任流数据的问题。信任体现在以下三个特性中：

• 响应性 指的是对分析数据的同步交互访问，衡量标准为查询延迟、QPS（每秒查询数）和并发性（终端用户数量）。
• 新鲜度 指的是分析结果的接近实时程度。数据的新鲜度是其随着时间推移的价值的量度。在图9-5中，x轴（时间）的尺度是相对于具体用例的，可以是小时、分钟、秒或毫秒。
• 一致性 我们在第6章中详细讨论了一致性。

在图9-5中，实时框包含了由于时间推移还未完全丧失价值的数据。x轴（时间）尺度将决定你需要采用的系统类型。如果尺度是以天或每日结束计算，批处理可能就足够了。如果尺度小于一小时，你必须利用部署在流处理层面基础设施上的流处理系统。如果尺度在8小时以内，流处理系统将为你未来更激进的时间表做好准备。

流处理层面为操作层面提供了所有进行实时分析处理所需的要素，包括流处理数据库和流处理器。它为应用程序及其用户提供了表格结构中的实时分析。此外，从通用的角度来看，由连接和表格组成的流处理层面类似于一个流处理数据库。操作分析的实施理念与数据网格架构相契合，该架构促进了数据的去中心化，并逆转了数据引力的影响。

数据网格

数据网格是由Zhamak Dehghani在2019年提出的一个数据架构概念框架。与传统的集中式模型不同，数据网格倡导一种去中心化的方法，将数据视为产品，并将所有权分散到不同的领域或业务单元中。每个领域都对其自身的数据负责，从而促进自主性和责任感。数据团队的运作方式类似于产品团队，负责其处理的数据的端到端生命周期管理，包括质量、文档和可访问性。基础设施设计为自助式，使领域团队能够独立访问和管理其数据。联邦计算治理确保在允许每个领域内本地控制的同时，遵守共同的标准和政策。这种方法旨在解决大型组织中的可扩展性挑战，促进敏捷性并提高整体数据质量。

数据网格的支柱

数据网格由四个关键原则或支柱组成。这些支柱是设计和实施去中心化和可扩展数据架构的基础：

1. 面向领域的去中心化数据所有权 这一支柱强调在组织内部将数据所有权分配给不同的领域或业务单元。与其让集中式数据团队管理数据，不如让各个领域对其生成和使用的数据负责。这种方法使数据管理与组织结构保持一致，促进了自主性和责任感。
2. 数据即产品 第二个支柱将数据视为一种具有自身生命周期、质量标准和文档的产品。数据团队作为产品团队，负责他们所生产数据的端到端管理。这包括确保数据质量、提供适当的文档以及使数据在组织内部易于访问。将数据视为产品鼓励了向提供高质量、可用数据的思维转变。
3. 自助式数据基础设施 第三个支柱侧重于创建一种自助式数据基础设施，使领域团队能够自主访问和管理自己的数据。这涉及提供工具、平台和服务，赋予领域团队在不依赖集中式数据团队的情况下处理数据的能力。自助式基础设施支持敏捷性，减少瓶颈，使团队能够更迅速地响应其特定的数据需求。
4. 联邦计算治理 第四个支柱通过联邦计算治理来解决治理问题，这涉及使用联邦委员会来设定共同的标准和政策，同时允许各领域内的本地自主权。这确保了在执行组织范围内标准的同时，为各领域提供了根据其特定需求管理数据的灵活性。联邦计算治理有助于在整个组织中保持一致性和合规性。

这四个支柱共同构成了数据网格框架的基础，为组织构建可扩展且敏捷的数据架构提供了指导原则。

通过去中心化数据所有权并将数据视为产品，数据网格旨在克服集中式模型的局限性，促进自主性、效率和改进的治理。这种方法承认数据管理的动态性和不断演变的特性，符合组织适应变化的需求，并将数据视为战略资产。

数据网格主要关注数据的去中心化，包括分析数据。同样，操作分析也关注将分析工作负载移动到操作层面，这种做法继承了去中心化数据和分析工作负载的副作用。

将分析工作负载更接近操作层面与数据网格的概念相一致，促进了去中心化的数据所有权并提高了面向领域团队的自主性。这种一致性的核心思想是赋予操作团队直接访问分析的权限，使他们能够实时获取洞察并做出数据驱动的决策。

以下是这种一致性在数据网格背景下的具体体现：

1. 面向领域的去中心化数据所有权 在数据网格中，数据所有权分布在不同的领域或业务单元中。将分析工作负载移近操作层面扩展了这一原则，使操作团队能够拥有并分析在其特定领域内生成的数据。这种去中心化促进了更敏捷和上下文感知的分析，因为操作团队对其数据有更深入的理解。
2. 数据即产品 将数据视为产品意味着数据不仅要收集和存储，还要作为整体数据产品生命周期的一部分进行分析和消费。将分析工作负载移近操作确保了从分析中获得的洞察无缝集成到操作流程中。操作团队负责其数据的端到端生命周期管理，包括分析、解释和应用以推动业务成果。
3. 自助式数据基础设施 分析工作负载通常需要专门的工具和平台。通过将这些工作负载移近操作层面，操作团队在访问和使用分析工具方面获得了更多自主权。这减少了对集中式数据团队的依赖，赋予操作团队执行临时分析、生成洞察并迭代分析流程的能力，而无需广泛的外部支持。
4. 联邦计算治理 操作层面的分析工作负载需要遵循共同的标准和治理政策，同时允许本地自主权。联邦计算治理对于确保一致性、合规性和安全性至关重要。这一原则确保了在操作团队拥有分析自主权的同时，仍有整体的标准来维护组织数据的完整性和可靠性。

总而言之，在数据网格背景下，将分析工作负载与操作层面对齐，支持了去中心化、自主性和将数据视为产品的核心原则。这种对齐旨在使分析更能响应操作需求，促进在组织内不同领域中建立数据驱动决策文化。

数据网格的挑战

然而，实施数据网格面临挑战，因为这需要显著的文化转变、技术复杂性、组织孤岛和技能差距。文化转变涉及从集中控制向去中心化模型的转变，强调面向领域的所有权和协作。技术挑战在于构建与数据网格原则一致的自助式数据基础设施，通常需要与现有系统的集成。克服组织孤岛并促进跨职能协作至关重要，同时还需要解决技能差距，确保团队采用产品导向的思维方式。数据质量和治理在平衡本地自主权与整体标准时也带来了挑战。有效的沟通和协调至关重要，同时在支持现有基础设施的同时，逐步采用数据网格实践也需要仔细规划。

尽管存在这些挑战，数据网格的潜在收益，如增强的敏捷性和改进的数据质量，推动组织克服这些复杂性，以成功实施数据网格。

简化且熟悉的数据网格方法可以简化其采用和实施，而这正是流处理数据库可以提供帮助的地方。流处理数据库带来了熟悉的数据处理方法，使数据更易于访问，并加快了数据网格架构的采用。它们允许多个领域在全球范围内消费数据产品，加速迭代开发，并快速完善数据解决方案。

具有流处理层面和流处理数据库的流数据网格

流数据网格实现了数据网格的所有支柱，但其实现方式是通过实时流。这使得所有领域的消费者都能够进行实时分析。通过使用流处理数据库，各个领域可以构建流数据产品，而无需深入了解流处理概念——相反，他们可以利用自己对数据库的知识来操作流处理数据库。

在第7章中，我们从数据库的角度定义了流处理数据库，称其为“能够消费和发出数据流并异步执行物化视图的数据库”。

流处理数据库具有一个独特的能力，即可以将数据作为流发出，供其他流处理数据库消费。你可以在流处理数据库之间建立一个数据共享的连接网络。正如所述，流处理层面可以被视为跨越所有企业领域的一个流处理数据库。

图9-6展示了流数据网格的目标以及它如何通过流处理层面来实现。流处理数据库基于来自其他领域的复制数据构建物化视图，并发出它们的数据产品供不同领域使用。

数据本地性

在数据网格中本地消费数据对性能和安全性都有重要影响。从性能的角度来看，本地消费可以实现更高效、更快速的数据访问。由于数据是从远程领域复制并存储在需要的本地领域内，团队可以最大限度地减少延迟，并针对特定用例优化数据处理。这可以提高分析工作负载、实时处理和其他数据驱动操作的性能，因为团队可以根据本地的性能需求定制其数据基础设施。此外，本地消费有助于数据处理的可扩展性，因为领域团队可以根据其特定需求独立扩展其基础设施，而不会影响其他领域。

在安全方面，本地消费数据符合数据网格中联邦计算治理的原则。可以在领域级别实施安全措施，使每个领域能够执行其自己的安全策略和访问控制。此外，领域团队可以专注于保护其数据资产，而不会影响整个组织的安全性。通过在领域级别实施安全措施并遵循通用的全球标准，数据网格在本地自主性与组织整体安全需求之间实现了更好的平衡。

为了在领域内本地使用数据，复制数据的系统是数据网格的基石之一。

数据复制

在流数据网格中，复制对于确保数据到达其目的地以供本地消费至关重要。数据在不同领域之间分布，实时复制机制对于维护数据的一致性和可靠性至关重要。

此外，复制支持流数据网格的可扩展性需求。随着数据量和处理需求在各领域之间的变化，复制允许高效分配数据处理工作负载。通过将相关的数据流复制到需要它们的领域，组织可以优化资源利用，减少延迟，使每个领域能够根据其特定的操作需求独立扩展其基础设施。这种可扩展性对于应对数据速度的波动至关重要，并确保流数据网格能够敏捷且高效地适应不断变化的业务需求。

流处理层面的数据复制通过构建连接的流处理平台网络来实现。例如，Kafka有一个称为Mirror Maker 2.0（MM2）的机制，可以将主题从一个Kafka集群镜像到不同的远程Kafka集群。

示例9-1 是一个用于在Kafka集群之间镜像主题的MM2示例配置。

示例9-1. Mirror Maker 2.0 配置，用于在两个Kafka集群之间镜像主题

# 指定任意数量的集群别名
clusters = source, destination 

# 每个集群的连接信息
# 这是每个集群的以逗号分隔的host:port对
# 例如：
# "A_host1:9092, A_host2:9092, A_host3:9092"
# 你可以在Ambari > Hosts上查看确切的主机名
source.bootstrap.servers = kafka-source1:9092,kafka-source2:9092,kafka-source3:9092
destination.bootstrap.servers = kafka-dest1:9092,kafka-dest2:9092,kafka-dest3:9092

# 启用并配置各个复制流
source->destination.enabled = true

# 定义要复制哪些主题的正则表达式。例如 "foo-.*"
source->destination.topics = foo 
groups=.*
topics.blacklist="*.internal,__.*"

# 设置新创建的远程主题的复制因子
replication.factor=3

checkpoints.topic.replication.factor=1
heartbeats.topic.replication.factor=1
offset-syncs.topic.replication.factor=1

offset.storage.replication.factor=1
status.storage.replication.factor=1
config.storage.replication.factor=1

• 源和目标Kafka集群的名称
• 在目标Kafka集群中要镜像的主题

MM2仅在两个Kafka集群之间镜像主题。流处理层面可以由多个Kafka集群组成，每个领域可能有1到2个集群。对于想要在本地消费实时数据的其他地区，必须部署一个MM2实例。

MM2通常作为一个在Kafka Connect集群中运行的连接器实现。如本章前面所述，流处理层面建立在流处理平台和连接器的基础上。正是这些组件创建了流数据网格。

MM2的替代方案是由Confluent提供的专有解决方案，称为Cluster Linking (CL)。CL连接Kafka集群并在它们之间镜像主题。与MM2不同，CL不需要Kafka Connect集群。MM2和CL都提供了保持数据流动的解决方案，以最大限度地减少数据引力的影响。

总结

流处理数据库通过提供简单且熟悉的数据库体验，抽象掉了流处理层面的大量复杂性。任何操作领域都可以参与数据网格，并与其他领域一起生产和消费实时数据产品，而无需深入了解流处理。在下一章中，我们将回顾不同的部署模型，这些模型将作为你实时分析需求的蓝图。