【大数据】流处理基础概念（一）：Dataflow 编程基础、并行流处理

流处理基础概念（一）：Dataflow 编程基础、并行流处理

• [1.Dataflow 编程基础](#1.Dataflow 编程基础)
• • [1.1 Dataflow 图](#1.1 Dataflow 图)
  • [1.2 数据并行和任务并行](#1.2 数据并行和任务并行)
  • [1.3 数据交换策略](#1.3 数据交换策略)
• 2.并行流处理
• • [2.1 延迟与吞吐](#2.1 延迟与吞吐)
  • • [2.1.1 延迟](#2.1.1 延迟)
    • [2.1.2 吞吐](#2.1.2 吞吐)
    • [2.1.3 延迟与吞吐](#2.1.3 延迟与吞吐)
  • [2.2 数据流上的操作](#2.2 数据流上的操作)
  • • [2.2.1 数据接入和数据输出](#2.2.1 数据接入和数据输出)
    • [2.2.2 转换操作](#2.2.2 转换操作)
    • [2.2.3 滚动聚合](#2.2.3 滚动聚合)
    • [2.2.4 窗口操作](#2.2.4 窗口操作)
    • • [2.2.4.1 滚动窗口](#2.2.4.1 滚动窗口)
      • [2.2.4.2 滑动窗口](#2.2.4.2 滑动窗口)
      • [2.2.4.3 会话窗口](#2.2.4.3 会话窗口)
      • [2.2.4.4 小结](#2.2.4.4 小结)

1.Dataflow 编程基础

1.1 Dataflow 图

Dataflow 程序描述了数据如何在不同操作之间流动。Dataflow 程序通常表示为 有向图。图中 顶点 称为 算子，表示计算；而 边 表示 数据依赖关系。算子是 Dataflow 程序的基本功能单元，它们从输入获取数据对其进行计算，然后产生数据并发往输出，以供后续处理。没有输入端的算子称为 数据源（data sources），没有输出端的算子称为 数据汇（data sinks）。一个 Dataflow 图至少要有一个数据源和一个数据汇。

上图中的 Dataflow 图被称作 逻辑图，因为它们表达了高层视角下的计算逻辑。为了执行 Dataflow 程序，需要将逻辑图转化为 物理 Dataflow 图。后者会指定程序的执行细节，例如，当我们使用分布式处理引擎时，每个算子可能会在不同物理机器上运行多个并行任务。**在逻辑 Dataflow 图中，顶点代表算子。在物理 Dataflow 图中，顶点代表任务。**如下图所示，"抽取主题标签" 和 "计数" 算子都包含 2 个并行算子任务，每个任务负责计算一部分输入数据。

1.2 数据并行和任务并行

Dataflow 图的并行性可以通过多种方式加以利用。

首先你可以将输入数据分组，让同一操作的多个任务并行执行在不同数据子集上，这种并行称为 数据并行。数据并行非常有用，因为它能够将计算负载分配到多个节点上，从而允许处理大规模的数据。

再者，你可以让不同算子的任务（基于相同或不同的数据）并行计算，这种并行称为任务并行。通过任务并行，可以更好的利用集群的计算资源。

1.3 数据交换策略

数据交换策略定义了如何将数据项分配给物理 Dataflow 图中的不同任务。这些策略可以由执行引擎根据算子的语义自动选择，也可以由 Dataflow 编程人员显示指定。常见的数据交换策略如下图所示：转发、广播、基于键值、随机。

2.并行流处理

在此，我们给出数据流的定义：数据流是一个可能无限的事件序列。数据流中的事件可以表示 监控数据、传感器测量值、信用卡交易、气象站观测数据、在线用户交互，以及 网络搜索 等。

2.1 延迟与吞吐

对于批处理应用而言，我们通常会关心作业的总执行时间，或者说处理引擎读取输入、执行计算、写回结果总共需要多长时间。但由于流式应用会持续执行且输入可能是无限的，所以在数据流处理中，没有总执行时间的概念。取而代之的是，流式应用需要针对到来数据 尽可能快的计算结果，同时还要应对 很高的事件接入速率，我们用 延迟 和 吞吐 来表示这两方面的性能需求。

2.1.1 延迟

延迟表示处理一个事件所需的时间，本质上它是从接收事件到在输出中观察到事件处理效果的时间间隔。

在流处理中，延迟是以时间片（例如毫秒）为单位测量的。根据应用的不同，你可能会关注平均延迟，最大延迟或延迟的百分位数值。

保证低延迟，对很多流式应用（例如：诈骗识别、系统告警、网络监测，以及遵循服务级别协议的服务）而言至关重要。低延迟是流处理的一个关键特性，它滋生出了所谓的实时应用。

2.1.2 吞吐

吞吐是用来衡量系统处理能力（处理速率）的指标，它告诉我们系统 每单位时间可以处理多少事件。

吞吐的衡量方式是计算每个单位时间的事件或操作数。但要注意，处理速率取决于数据到来速率，因此吞吐低不一定意味着性能差。在流处理系统中，你通常希望系统有能力应对以最大期望速率到来的事件。换言之，首要的关注点是确定 峰值吞吐，即系统满负载时的性能上限。

2.1.3 延迟与吞吐

延迟和吞吐并非相互独立的指标。如果事件在数据处理管道中传输时间太久，我们将难以确保高吞吐；同样，如果系统性能不足，事件很容易堆积缓冲，必须等待一段时间才能处理。然而，通过并行处理多条数据流，可以在处理更多事件的同时降低延迟。

2.2 数据流上的操作

流处理引擎通常会提供一系列内置操作来实现数据流的获取、转换，以及输出。这些算子可以组合生成 Dataflow 处理图，从而实现流式应用所需的逻辑。

这些操作既可以是 无状态（stateless）的，也可以是 有状态（stateful）的。无状态的操作不会维持内部状态，即处理事件时无需依赖已处理过的事件，也不保存历史数据。由于事件处理互不影响且与事件带来的时间无关，无状态的操作很容易并行化。此外，如果发生故障，无状态的算子可以很容易地重启，并从中断处继续工作。相反，有状态算子可能需要维护之前接收的事件信息。它们的状态会根据传入的事件更新，并用于未来事件的处理逻辑中。有状态的流处理应用在并行化和容错方面会更具挑战性，因为它们需要对状态进行高效划分，并且在出错时需进行可靠的故障恢复。

2.2.1 数据接入和数据输出

数据接入和数据输出操作允许流处理引擎和外部系统进行通信。数据接入操作是从外部数据源获取原始数据并将其转换成适合后续处理的格式。实现数据接入操作逻辑的算子称为 数据源。数据源可以从 TCP 套接字、文件、Kafka 主题或传感器数据接口中获取数据。数据输出操作是将数据嗯以适合外部系统使用的格式输出。负责数据输出的算子称为 数据汇，其写入的目标可以是文件、数据库、消息队列或监控接口等。

2.2.2 转换操作

转换操作是一类 只过一次 的操作，它们会分别处理每个事件。这些操作逐个读取事件，对其应用某些转换并产生一条新的输出流。转换逻辑可以是算子内置的，也可以由用户自定义函数提供。

算子既可以同时接收多个输入流或产生多条输出流，也可以通过单流分割或合并多条流来改变 Dataflow 图的结构。

2.2.3 滚动聚合

滚动聚合（如求和、求最小值和求最大值）会根据每个到来的事件持续更新结果。聚合操作都是有状态的，它们通过将新到来的事件合并到已有状态来生成更新后的聚合值。注意，为了更有效的合并事件和当前状态并生成单个结果，聚合函数必须满足 可结合 及 可交换 的条件，否则算子就要存储整个流的历史记录。下图展示了一个求最小值的滚动聚合，其算子会维护当前的最小值，并根据每个到来的事件去更新这个值。

2.2.4 窗口操作

转换操作和滚动聚合每次处理一个事件来产生输出并（可能）更新状态。然而，有些操作必须收集并缓冲记录才能计算结果。例如流式 Join 或像是求中位数的整体聚合（holistic aggregate）。为了在无限数据流上高效地执行这些操作，必须对操作所维持的数据量加以限制。窗口操作 支持这项功能。

除了产生单个有用的结果，窗口操作还支持在数据流上完成一些具有切实语义价值的查询。你已经了解滚动聚合是如何将整条历史流压缩成一个聚合值，以及如何针对每个事件在极低延迟内产生结果。该操作对某些应用而言是可行的，但如果你只对最新的那部分数据感兴趣该怎么办呢？

窗口操作会持续创建一些称为 桶 的 有限事件集合，并允许我们基于这些有限集进行计算。事件通常会根据其时间或其他数据属性分配到不同桶中。为了准确定义窗口算子语义，我们需要决定事件如何分配到桶中以及窗口用怎样的频率产生结果。窗口的行为是由一系列策略定义的，这些窗口策略决定了 什么时间创建桶，事件如何分配到桶中 以及 桶内数据什么时间参与计算。

其中参与计算的决策会根据触发条件判定，当触发条件满足时，桶内数据会发送给一个 计算函数（evolution function），由它来对桶中的元素应用计算逻辑。这些计算函数可以是某些聚合（例如求和，求最小值），也可以是一些直接作用于桶内收集元素的自定义操作。策略的指定可以基于时间（例如最近 5 秒钟接收的事件）、数量（例如最新 100 个事件）或其他数据属性。

2.2.4.1 滚动窗口

滚动窗口（tumbling window）将事件分配到长度固定且互不重叠的桶中，在窗口边界通过后，所有事件会发送给计算函数进行处理。

基于数量的滚动窗口 定义了在触发计算器需要集齐多少条事件。

基于时间的滚动窗口 定义了在桶中缓冲数据的时间间隔。

2.2.4.2 滑动窗口

滑动窗口（sliding window）将事件分配到大小固定且允许相互重叠的桶中，这意味着每个事件可能会同时属于多个桶。我们通过指定长度（fixed length）和滑动间隔（slide）来定义滑动窗口。滑动间隔决定每隔多久生成一个新的桶。

上图为长度为 4 个事件、滑动间隔为 3 个事件的基于数量的滑动窗口。

2.2.4.3 会话窗口

会话窗口（session window）在一些常见的真实场景中非常有用，这些场景既不适合用滚动窗口，也不适合用滑动窗口。假设有一个应用要在线分析用户行为，在该应用中我们要把事件按照用户的同一活动或会话来源进行分组。会话由发生在相邻时间内的一系列事件，外加一段非活动时间组成。例如，用户浏览一连串新闻文章的交互过程，可以看做一个会话。由于会话长度并非预先定义好，而是和实际数据有关，所以无论是滚动还是滑动窗口都无法用于该场景。而我们需要一个窗口操作，能将属于同一会话事件分配到相同桶中。会话窗口根据会话间隔（session gap）将事件分为不同的会话，该间隔值定义了绘画在关闭前的非活动时间长度。

2.2.4.4 小结

迄今为止，你所见到的所有窗口都是基于 全局流数据 的窗口。但在实际应用中，你可能会想将数据流划分为多条逻辑流并定义一些并行窗口。例如，如果你在收集来自不同传感器的测量值，那么可能会想在应用窗口计算器按照传感器 ID 对数据流进行划分。并行窗口中，每个数据分区所应用的窗口策略都相互独立。下图展示了一个按事件颜色划分、基于数量 2 的并行滚动窗口。

窗口操作与流处理中两个核心概念密切相关：时间语义（time semantics）和 状态管理（state management）。时间可能是流处理中最重要的一个方面。尽管低延迟是流处理中一个很吸引人的特性，但流处理的真正价值远不止提供快速分析。

现实世界的系统、网络及通信信道往往充斥着缺陷，因此流数据通常都会有所延迟或者以乱序到达。了解如何在这种情况下提供精准确定的结果就变得至关重要。此外，处理实时事件的流处理应用还应以相同的方式处理历史事件，这样才能支持离线分析，甚至时间旅行式分析（time travel analysis）。当然，如果你的系统无法在故障时保护状态，那一切都是空谈。

至今为止你见到的所有窗口类型都要在生成结果前缓冲数据。实际上，如果你想在流式应用中计算任何有意义的结果（即便是简单的计数），都需要维护状态。考虑到流式应用可能需要整日、甚至长年累月的运行，因此必须保证出错时其状态能进行可靠的恢复，并且即使系统发生故障，系统也能提供准确的结果。后续，我们将深入研究流处理中的时间以及发生故障时和状态保障相关的概念。