什么是事件流？

事件流是事件流处理 (ESP) 中的关键功能，支持 IT 基础架构通过在事件或变化发生时处理数据来处理大量连续的事件流。事件流与流处理截然不同。事件流提供事件传输与存储的基础设施。流处理则可对这些事件执行过滤、聚合或扩充操作。

事件流通常与批处理互为补充；批处理用于处理大型静态数据集（或称 “静态数据”）。但是，事件流不能批量处理有界数据，而是可以在无界数据到达时对其进行处理。借助该方式，架构内的软件可实时解读数据流（即 “动态数据”）并做出响应。

高性能事件流服务可以为一系列任务提供支持，涵盖库存变动、产品调价时推送通知这类简单功能，以及更为复杂的工作负载。这类服务还可运行人工智能（AI） 和实时 机器学习模型，检测可疑用户活动。

即使在批处理的情况下，事件流也可通过将事件与其各自的时间戳连接起来。它还有助于识别历史趋势，从而增加数据分析的深度。

事件流以连续且可能无边界的数据记录序列为核心，这类记录即为 “事件”，是记录系统或环境中各类事件的基础数据结构。事件是对已发生行为（例如创建订单、付款授权）的不可变记录。“流”（也叫数据流或流数据）指上述事件的持续传输过程。

每个事件一般包含用于标识事件或关联实体的键、承载事件实际内容的值。此外还带有时间戳，标记事件发生或被记录的时间，部分情况下还包含数据源、架构版本或其他属性相关元数据。

在专用流处理引擎的帮助下，事件可以在流中经历几个不同的过程。“聚合”执行数据计算，例如均值、总和和标准差。“摄取”将流数据添加到数据库。分析处理使用流数据中的模式来预测未来事件，而丰富处理将数据点与其他数据源相结合，以提供上下文并创造意义。

随着组织生成大量事件数据，它们可借助实时分析识别不断涌现的模式、异常与趋势。AI 基于这类实时洞察，解析事件流中的复杂关联，生成预测结论并给出行动建议。

该能力已成为智能体式 AI 系统的先决条件：IDC 数据显示，80% 的智能体式 AI 用例都需要具备实时性、场景化且可广泛访问的数据。无论是支撑分析、AI 应用还是自动化工作流，这类系统都依赖能够反映组织全域业务活动的连续事件流。

事件通常与业务操作或用户导航流程相关联，通常会触发另一个操作、流程或一系列事件。以网上银行为例。当用户点击“转账”，以将资金从一个银行账户汇款到另一个银行账户时，资金将从汇款人的账户中提取并添加到收款人的银行账户中，同时向一方（或双方）发送电子邮件或短信通知，必要时还会部署安全和欺诈预防协议。

事件是事件流的核心组件。然而，一系列其他组件使流服务能够像它们一样快速有效地处理事件。其他重要组件包括：

代理从生产者接收事件，完成整理与存储后，再交付给使用者。作为中间媒介，代理让生产者与消费者无需建立直连即可通信，双方能够独立运行和扩容。 

在分布式事件流系统中，代理通过在多个节点之间复制事件来确保低延迟和高可用性。代理还可以形成集群（代理集一起工作，以便更轻松地实现负载均衡和可扩展性）。

主题是事件发布到的分类或源名称，提供一种在平台内组织和筛选事件的方法。它们充当事件的“主题”，允许使用者订阅主题并仅接收相关事件。

主题可以进一步划分为分区，从而允许多个使用者同时读取一个主题，而不会破坏每个分区的顺序。

偏移量是分区内每个事件的唯一标识符，用于标记事件在序列中的位置。使用者使用偏移量来组织他们处理过的事件。例如，如果使用者断开与事件的连接并稍后重新连接，则可以从最后已知偏移量恢复处理。

鉴于数据的激增以及由此产生的数据流量激增，事件流已成为现代数据架构的重要组成部分，在需要快速决策能力的环境或希望自动执行决策职责的组织中尤其如此。

以下是事件流服务管理事件数据的方式：

1. 事件生成。当创建者（例如微服务、后端系统、物联网生态系统或事件驱动型 API）将事件发送到事件流平台时，事件流开始。
   
   
2. 事件发布。借助客户端库，创建者将事件发布到平台内的特定主题，此时它们可供使用者（订阅该主题的应用程序和服务）使用。
   
   
3. 事件存储。平台将事件存储在预先确定的时间段内，并由代理管理事件存储和检索过程。
   
   
4. 事件使用。使用者处理事件数据以启动其他事件。根据其目的或配置，它们可以在事件到达时立即采取行动（实时处理）、存储事件以供日后处理或编译事件以进行批处理。使用者还使用偏移量跟踪自己在数据管道中的位置，因此在发生故障或重新启动时可以从中断的位置恢复处理。
   
   
5. 事件传递。 事件代理向使用者提供事件。它可基于 “至少一次” 语义保障事件送达，确保每个事件最终抵达目标，允许出现重复消息。该过程也可支持 “恰好一次” 传递，保证每个事件有且仅传递一次，或是采用其他交付语义。
   
   
6. 事件处理。使用并传递初始事件后，处理事件数据以执行多个下游操作，包括转换数据、聚合数据和触发复杂事件处理 (CEP) 工作流。组织通常使用 Apache Flink、Apache Spark Structured Streaming 和 Kafka Streams 等流处理技术，在分布式事件驱动系统中实时执行这些操作。由此产生的实时数据流，还可为 AI 系统供给连续数据，支撑实时决策。

事件流一般采用分布式架构部署，用于捕获、存储、处理和分发跨多系统的连续事件流数据。事件流架构不依赖点对点直连，而是通过共享基础设施解耦数据生产者与消费者，让应用可以独立扩容并实时交换信息。该框架包含以下几项核心架构组件：

多数事件流架构的核心组件为事件代理，充当事件数据持久化、可扩展的主干。 事件写入分布式日志的主题，按接收顺序保存，可供后续读取使用。

该架构允许多个应用独立访问同一事件流，无需与数据源系统做集成对接。Apache Kafka、Amazon Kinesis 和 Apache Pulsar 等技术常用来实现该能力。

为承载大规模工作负载，事件流通常按主题组织，并拆分为可分布在多台服务器上的分区。分区支持并行处理，提升吞吐量；副本机制可在不同节点创建数据副本，当单个组件故障时，提升系统容错能力与可用性。

事件流架构将数据生成系统与数据消费系统相互隔离。生产者向主题发布事件，消费者订阅这些主题并独立处理事件。这种解耦设计支持新增应用与服务，无需改动数据源系统。

不少事件流架构内置流处理层，在事件流转于系统的过程中完成数据分析与转换。常用流处理技术包括 Apache Flink、Kafka Streams、ksqlDB 以及 Apache Spark Structured Streaming。这类技术支持对持续流入的数据执行过滤、扩充、关联与聚合等操作。

部分流式工作负载要求应用维护过往事件相关信息。例如，电商平台可分析过去一小时内的全部购买记录，识别热门商品，并近乎实时更新推荐内容。状态管理让系统能够长期保存并更新这类信息；窗口管理则将连续数据流划分为基于时间或事件的区间，用于分析。

事件流架构一般内置防数据丢失与故障恢复机制。根据应用需求，系统可提供至多一次、至少一次或恰好一次的处理保障。检查点、副本机制与消费者偏移量跟踪，能够在中断或系统重启时维持数据一致性。

处理完成后的事件通常转发至下游目标端，例如数据库、数据仓库、数据湖、搜索索引、机器学习系统或其他事件流。通过这类集成，事件数据可支撑实时分析、各类应用、自动化工作流以及 AI 应用。

除了标准的流式传输和处理之外，事件流平台（例如 Amazon Kinesis、Google Cloud Pub/Sub、Azure Event Hubs 和 IBM® Event Automation）还可支持多种流式实践，进一步增强能力。尤其是 IBM Event Automation，它依托开源 Apache Kafka 平台的处理能力，优化事件驱动型工作流。这些能力还可帮助组织交付分析和 AI 系统所依赖的实时数据管道。

“恰好一次处理” 指流内每个事件仅被处理一次，是避免流事件重复或丢失的基础能力。大多数事件流系统都包含提供恰好一次语义的机制，而不管系统中其他地方是否发生故障。

当下游组件无法跟上传入事件速率时，背压可以防止流压垮系统。利用背压（一种数据流控制机制），当使用者因数据处理不堪重负或无法跟上传入事件时，他们可以向创建者发出信号，以限制或停止数据创建。

此过程允许系统通过缓冲或删除传入事件（而不是破坏整个系统）来正常处理工作负载，以便事件处理在工作负载波动时保持稳定。

事件使用者通常作为使用者组的一部分工作，以加速事件使用。使用者组内的每个使用者会分配到一部分分区，实现并行消费，提升效率。如果组中的一个使用者出现故障或需要添加或删除，平台可以动态重新分配分区以保持平衡和容错能力。

事件流通常要求以时间敏感的方式处理数据。水印是系统对事件时间推进情况的估算值。水印设定完整性阈值，判定系统何时可认定事件数据已完成全部处理。水印还可保障基于时间的处理精度，并对无序事件进行协调。

大多数事件流平台都提供可定制数据保留策略，允许开发人员控制事件可供使用的时长。而数据压缩是一种从主题中移除冗余或过期数据的过程，可在保留关键数据的同时，将存储占用降至最低。

值得再次指出的是，标准流架构通常会将事件创建者、事件代理和使用者分离开来，以便可以独立扩展和维护组件。这种灵活性让企业能够支撑多种下游应用场景，包括实时分析、AI 驱动决策以及工作流自动化。 这种灵活性让企业能够支撑多种下游应用场景，包括实时分析、AI 驱动决策以及工作流自动化。

事件流处理和批处理的区别在于，事件流处理在事件发生时连续处理数据，而批处理处理则定期或在触发时处理累积的数据。

事件流和批处理都移动和处理数据，但主要区别在于处理数据的时机和方式。事件流在应用、数据库、物联网设备等数据源产生事件时，持续捕获并传输事件。系统无需等待完整数据集就绪，而是在事件抵达时处理单个事件或小批量事件，实现低延迟分析与响应。

该方案非常适用于数据价值高度依赖时效性的场景，例如欺诈检测、运营监控、实时推荐，以及依赖最新信息的 AI 系统。

批处理会在指定时段内收集数据，再作为独立工作负载执行处理。由于无需即时输出结果，批处理适合生成日报、账户对账、更新分析看板等任务。

此外，两种方案互为补充而非互斥：组织可借助事件流在业务活动发生时进行检测与响应，再通过批处理对累积数据开展全面的历史分析。

事件流是一个强大的概念，允许组织在数据生成时加以利用，从而创建响应更快、更智能的系统。随着数据驱动型决策的兴起，事件流成为现代软件架构中越来越重要的组成部分。

因此，事件流技术在各个业务领域拥有一系列用例，包括：

除了特定行业之外，事件流在与其他技术和架构协同部署时也很有用。例如，事件流有时与事件源和命令查询职责分离 (CQRS) 等模式相关联。

事件源是一种架构模式，在这种模式中，应用程序状态的变化被存储为一系列事件。与事件流一起使用时，事件源允许流媒体系统重放这些事件。该能力还可重建任何时间点的实体状态，或驱动系统的其他组件。

在 CQRS 架构模式中，系统被拆分为两种不同的模型：一种处理命令（写入），一种处理查询（读取）。事件流可用于 CQRS，将更改从写入模型实时传播到读取模型，从而实现两者之间的异步集成。

事件流也是构建事件驱动型架构的基础技术。事件驱动架构支持松散耦合的组件通过事件进行通信，但它不是向代理发布事件流，而是发布一个单一目的事件，其他应用程序或服务可以利用该事件依次执行操作。

事件驱动型架构提供的流内处理能力（与事件流功能一起使用）使企业能够响应动态数据并根据当前和历史数据快速做出决策。该实时响应能力同样支撑依赖持续更新数据的分析与 AI 应用。

近年来，云提供商已开始将事件流原则作为服务提供。事件流即服务使企业可以更轻松地采用事件流，而无需管理整个底层基础架构，从而进一步拓宽事件流的用例。