Batch vs Stream

Pasted image 20230202134200.png

  • Batch Processing
    • 批处理面向 bounded stream
    • 在这种模式下你可以在产生任何结果之前选择注入整个 dataset
    • 因此你可以对数据进行排序，计算 statistics，或者是产生一个最终报告
  • Stream Processing
    • 流处理面向 unbounded stream
    • 理论上，输入永远不会终止
    • 所以当数据到来时，你必须持续的处理数据

Concepts

在 Flink 中，applications 都是由 streaming dataflows 组成，他们会被 user-defined 的 operators 转换。这些 dataflows 会组成有向图，有向图中可能有一个或者多个 sources，并以一个或者多个 sinks 结束。

下面是一个由 Flink 程序映射为 Streaming Dataflow 的示意图，如下所示：

image-program_dataflow
image-program_dataflow

上图中：

  • FlinkKafkaConsumer 是一个 Source Operator
  • map、keyBy、timeWindow、apply 是 Transformation Operator
  • MySink 是一个 Sink Operator。

通常在 transformations in the program 和 operators in the dataflow 之间有 one-to-one 的对应关系。有时候，一个 transformation 也可能由多个 operators 组成。

Pasted image 20230202140101.png

  • Sources:
    • 可能来自于 streaming sources，比如 message queues 或者 distributed logs，like Apache Kafka 或者 Kinesis
    • 可能来自于 bounded sources，比如 historic data
  • Sinks
    • 另一个 stream 处理系统
    • Database
    • File/Object storage

Parallel Dataflows

在 Flink 中，程序天生是并行和分布式的：

  • 一个 Stream 可以被分成多个 Stream Partitions
  • 一个 Operator 可以被分成多个 Operator Subtask，每一个 Operator Subtask 是在不同的线程中独立执行的。
  • 一个 Operator 的并行度，等于 Operator Subtask 的个数
  • 一个 Stream 的并行度总是等于生成它的 Operator 的并行度

有关 Parallel Dataflow 的实例，如下图所示：

image-parallel_dataflow
image-parallel_dataflow

上图 Streaming Dataflow 的并行视图中，展现了在两个 Operator 之间的 Stream 的两种模式：

One-to-One

比如从 Source[1] 到 map()[1]，它保持了 Source 的分区特性（Partitioning）和分区内元素处理的有序性。也就是说 map()[1] 的 Subtask 看到数据流中记录的顺序，与 Source[1] 中看到的记录顺序是一致的。

Redistribution

  • 这种模式改变了输入数据流的分区。
  • 比如从 map()[1]、map()[2] 到 keyBy()/window()/apply()[1]、keyBy()/window ()/apply()[2]，上游的 Subtask 向下游的多个不同的 Subtask 发送数据，改变了数据流的分区，这与实际应用所选择的 Operator 有关系。