引入

我们整个大数据处理里面的计算模式主要可以分为以下四种：

1. 批量计算（batch computing）
   MapReduce
   Hive
   Spark
   Flink
   pig
2. 流式计算（stream computing）
   Storm
   SparkStreaming/StructuredStreaming
   Flink
   Samza
3. 交互计算（interactive computing）
   Presto
   Impala
   Druid
   Drill
4. 图计算（graph computing）
   Giraph （Facebook)
   Graphx (Spark)
   Gelly（Flink)

在本专栏里面，我们重点关注的是Flink，它涉及批量计算、流式计算以及图计算，下面我们重点看一下批量计算和流式计算的核心区别：

• 数据时效性不同：流式计算实时、低延迟，批量计算非实时、高延迟。
• 数据特征不同：流式计算的数据一般是动态的、没有边界的，而批处理的数据一般则是静态数据。
• 应用场景不同：流式计算应用在实时场景，时效性要求比较高的场景，如实时推荐、业务监控等；批量计算一般称为批处理，应用在实时性要求不高、离线计算的场景下，数据分析、离线报表等。
• 运行方式不同：流式计算的任务持续进行的，批量计算的任务则一次性完成。

随着企业对数据处理实时性要求越来越高，越来越多的业务场景开始更加强调时效性，比如说实时推荐、风控等业务。而伴随这些这些业务的需求的是开源流式处理技术日趋成熟，这极大的促使数据处理的技术里，流式计算开始逐步成为主流。

业界主流的流式处理框架演进

我们下面来看下，随着技术发展，有哪些主流的流式框架：

Storm

最早使用的流处理框架，社区比较成熟。
支持原生流处理，即单事件来处理数据流（所有记录一个接一个处理）。
延迟性低（毫秒级）。
消息保障能力弱，消息传输可能重复但不会丢失。
吞吐量比较低。

1. 社区成熟度

Storm 是最早使用的流处理框架之一，社区比较成熟。它最早由Twitter开源，后于2014年成为Apache基金会的顶级项目。Storm社区的活跃度和稳定性较高，全球有众多代码贡献者，这为Storm的持续发展和优化提供了有力支持。

2. 原生流处理能力

Storm 支持原生流处理，即单事件来处理数据流，所有记录一个接一个处理。Storm中的数据流由一个个连续不断的Tuple组成，每个Tuple代表一条数据。Spout作为数据源，负责从外部读取数据并将其发送到数据流中；Bolt作为数据处理节点，负责接收数据流中的数据并进行处理。这种处理方式使得Storm能够实时地处理数据，适用于需要快速响应的应用场景。

3. 低延迟特性

Storm 的延迟性低，可以达到毫秒级。Storm的这种低延迟特性使得它在实时性要求高的场景中表现出色，例如金融交易、社交媒体监控等。

4. 消息保障能力

Storm 的消息保障能力相对较弱，消息传输可能重复但不会丢失。Storm通过ACK机制保证每个消息至少被处理一次，但可能会出现重复处理的情况。这意味着在某些情况下，可能会有重复的消息被发送到下游系统，需要下游系统具备处理重复消息的能力。

5. 吞吐量

Storm 的吞吐量相对较低。尽管Storm能够高效地处理数据流，但在处理大规模数据时，其吞吐量可能不如其他一些流处理框架（如Apache Flink）。不过，Storm的分布式架构使其具备了良好的扩展性，可以通过增加工作节点来水平扩展系统，以应对不同规模的数据处理需求。

总结

Apache Storm 作为一个开源的分布式实时计算系统，具有社区成熟、原生流处理能力、低延迟等优点，适用于需要实时处理数据的场景。然而，其消息保障能力和吞吐量方面存在一定的局限性，需要根据具体的应用场景进行权衡和选择。

SparkStreaming

SparkStreaming属于SparkAPI的扩展。
以固定时间间隔（如几秒种）处理一段段的批处理作业（即“微批处理”）
延迟性较高（秒级），但能够保证消息传输既不会丢失也不会重复。
具有非常高的吞吐。

1. Spark API 的扩展

Spark Streaming 是 Spark 核心 API 的一个扩展，它允许开发人员使用 Spark 的编程模型和 API 来处理实时数据流。

2. 微批处理机制

如下图所示，Spark Streaming 采用微批处理（Micro-batch）的机制来处理数据流。它将输入的数据流按照固定的时间间隔（如几秒钟）分割成一个个小批次（batch），然后对每个批次的数据进行批处理作业。这种机制使得 Spark Streaming 能够在处理数据时兼顾吞吐量和延迟。具体来说，Spark Streaming 将实时输入数据流划分为多个小批次，每个批次对应一个 RDD（弹性分布式数据集），然后通过 Spark Engine 对这些 RDD 进行处理，最终生成结果流。

3. 延迟性较高

由于采用了微批处理机制，Spark Streaming 的延迟性相对较高，通常在秒级。与像 Apache Storm 这样的纯流处理系统相比，Spark Streaming 的延迟要高一些，因为它不是逐条处理数据，而是将数据分批处理。然而，这种微批处理的机制使得 Spark Streaming 能够在处理大规模数据时保持较高的吞吐量和容错性。

4. 消息保障能力强

Spark Streaming 能够保证消息传输既不会丢失也不会重复。它通过写前日志（Write Ahead Log，WAL）机制来实现这一点。当数据到达 Spark Streaming 时，会先写入 WAL 中，从而确保即使在数据接收过程中发生故障，数据也不会丢失。此外，Spark Streaming 的容错性还体现在它能够从节点故障或任务失败中快速恢复，并重新处理数据，确保数据的完整性和一致性。

5. 高吞吐量

Spark Streaming 具有非常高的吞吐量。它利用 Spark 的分布式计算能力和内存计算特性，能够高效地处理大规模的数据流。通过将数据分批处理，Spark Streaming 能够充分利用集群资源，实现数据的并行处理，从而达到高吞吐量的效果。此外，Spark Streaming 还支持多种优化策略，如数据分区、内存管理等，以进一步提高数据处理的效率。

总结

Apache Spark Streaming 作为 Spark 核心 API 的扩展，通过微批处理机制实现了对实时数据流的高吞吐量处理。虽然其延迟性相对较高，但它能够保证消息传输的可靠性和完整性，适用于需要处理大规模数据流且对数据准确性要求较高的应用场景。

Flink

真正的流处理框架（DataFlowModel）。
延迟性较低（毫秒级），且能够保证消息传输不丢失不重复。
具有非常高的吞吐。
支持原生流处理。

1. 真正的流处理框架

Flink 是一个真正的流处理框架，基于 DataFlow Model。它能够处理任何类型的数据流，无论是有界还是无界的数据流。Flink 的核心是其数据流模型，它将数据视为连续的事件流，并在这些事件到达时进行实时处理。Flink 支持实时数据流和历史数据流的处理，适用于多种应用场景，如实时数据分析、ETL（Extract, Transform, Load）、机器学习和事件驱动应用等。

2. 低延迟特性

Flink 的延迟性较低，可以达到毫秒级。它通过高效的数据处理引擎和优化的执行计划，能够在处理大规模数据流时保持低延迟。Flink 的这种低延迟特性使其适用于需要快速响应的实时应用场景，如网络安全监测、电商推荐系统和物联网数据分析等。

3. 消息保障能力强

Flink 能够保证消息传输既不会丢失也不会重复。它通过 Checkpoint 和 WAL 机制来实现这一点。Checkpoint 机制定期将应用状态持久化到外部存储系统，如 HDFS、S3 等，从而在发生故障时能够快速恢复应用状态，确保数据的完整性和一致性。WAL 机制确保即使在数据接收过程中发生故障，数据也不会丢失。

4. 高吞吐量

Flink 具有非常高的吞吐量。它利用分布式计算和内存计算特性，能够高效地处理大规模的数据流。Flink 的架构设计使其能够充分利用集群资源，实现数据的并行处理。此外，Flink 还支持多种优化策略，如数据分区、窗口操作等，以进一步提高数据处理的效率。

5. 支持原生流处理

Flink 支持原生流处理，即单事件来处理数据流。Flink 的 DataStream API 允许开发人员直接操作数据流，进行各种转换操作，如 map、filter、keyBy、window、reduce 等。这种原生流处理能力使得 Flink 能够高效地处理无界和有界的数据流，适用于需要实时响应的应用场景。

总结

Apache Flink 是一个功能强大的流处理框架，适用于各种实时数据处理场景。它通过 DataFlow Model 实现了真正的流处理，具有低延迟、高吞吐量和强大的消息保障能力。Flink 的原生流处理支持和灵活的 API 设计使其成为大数据处理的重要工具，能够满足不同应用场景的需求。

为什么选择Flink？

我们通常会从下面四个方面去考察一个流式处理技术是否满足我们的要求：

• 处理延迟
  我们需要考察这个技术，能否达到我们预期的延时去处理对应的数据。
• 吞吐量
  除了时效性，我们还需要关注这个技术，是不是能够达到业务需要的，比如每秒千万级别的吞吐量。
• 准确性
  当然，实时数据处理场景最重要的还是看，这个技术能否达到Exactly-once，也就是数据既不丢失也不重复的这样一个数据准确性保障。
• 易用性
  最后就是看这个技术，是否提供一些类似于SQL的，能极大提到易用性的开发能力。

对于Storm和Spark Streaming来说，它们都不能在以上四个方面做到完美，而Flink能够做到低延迟、高吞吐以及达到Exactly-once的准确性，同时还提供了不同抽象级别的能力供用户使用开发。所以它对于其他的一些流处理框架，具有非常高的一个优势，这也是它成为目前业界最主流的流处理技术的原因。

Flink发展时间线及重大变更

Flink最早是德国一些大学中的研究项目，并且早期项目名称也不是Flink，在2010~2014年间，由德国柏林工业大学、德国柏林洪堡大学和德国哈索·普拉特纳研究所联合发起名为"Stratosphere:Information Management on the Cloud"研究项目，该项目就是Flink的前身：Stratosphere项目。该项目创建初衷就是构建一个一数据库概念为基础、以大规模并行处理架构为支撑、以MapReduce计算模型为逻辑框架的分布式数据计算引擎，在此构想之上还引入了流处理，为后来的Flink发展打下良好基础。

2014年4月，Stratosphere代码被贡献给Apache软件基金会，成为Apache基金会孵化器项目，项目孵化期间，项目Stratosphere改名为Flink。Flink在德语中意为"敏捷、快速"，用来体现流式 数据处理器速度快 和 灵活性强 等特点，同时使用棕红色松鼠图案作为Flink项目的Logo，也是为了突出松鼠灵活快速的特点，由此，Flink正式进入社区开发者的视线。

Flink自从加入Apache后发展十分迅猛，自2014年8月发布0.6版本后，Flink仅用了3个月左右的时间，在2014年11月发布了0.7版本，该版本包含Flink目前为止最重要的 Flink Streaming 特性，2014年底，Flink顺利从孵化器"毕业"成为Apache顶级项目。随着Flink技术成为Apache顶级项目，Flink受到社区越来越多的关注，Flink逐步增加了很多核心的功能，例如：一致性语义、事件时间和Table API等，其功能和稳定性也不断得到完善。

早期Stratosphere项目的核心成员曾共同创办一家名叫"Data Artisans"的公司，其主要的任务就是致力于Flink技术的发展和商业化，2019年阿里巴巴收购了Data Artisans公司，并将其开发的分支Blink开源，越来越多的公司开始将Flink应用到他们真实的生产环境中，并在技术和商业上共同推动Flink的发展。

Flink逐步被广泛使用不仅仅是因为 Flink支持高吞吐、低延迟和exactly-once语义的实时计算，同时Flink还提供基于流式计算引擎处理批量数据的计算能力，在计算框架角度真正实现了批流统一处理。

Flink发展非常迅速，目前官网Flink最新版本是2.0.0 版本，下面列举Flink发展过程中重要时间和重要版本发布时间点以及Flink各个版本推出的新特性以帮助大家更好了解Flink：

• 2019-08-22：Flink 1.9.0 版本发布，主要特性如下：

  • 合并阿里内部Blink；

  • 重构Flink WebUI；

  • Hive集成；

  • Python Table API支持；

• 2020-02-11：Flink 1.10.0 版本发布，主要特性如下：

  • 整合Blink全部完成；

  • 集成K8S；

  • PyFlink优化；

  • 内存管理配置优化；

• 2020-07-06：Flink 1.11.0 版本发布，主要特性如下：

  • 从Flink1.11开始,Blink planner是Table API/SQL中的默认设置，仍支持旧的Flink planner；

  • Flink CDC支持；

  • 支持Hadoop3.x版本，不提供任何更新的flink-shaded-hadoop-x jars，用户需要通过HADOOP_CLASSPATH环境变量（推荐）或 lib/ folder 提供 Hadoop 依赖项。

• 2020-12-08：Flink 1.12.0 版本发布，主要特性如下：

  • DataStream API 上添加了高效的批执行模式的支持，批处理和流处理实现真正统一的运行时的一个重要里程碑；

  • 实现了基于Kubernetes的高可用性（HA）方案，作为生产环境中，ZooKeeper方案之外的另外一种选择；

  • 扩展了 Kafka SQL connector，使其可以在 upsert 模式下工作，并且支持在 SQL DDL 中处理 connector 的 metadata；

  • PyFlink 中添加了对于 DataStream API 的支持；

  • 支持FlinkSink，不建议再使用StreamingFileSink；

• 2021-04-30：Flink 1.13.0 版本发布，主要特性如下：

  • SQL和表接口改进；

  • 改进DataStream API和Table API/SQL之间的互操转换；

  • Hive查询语法兼容性；

  • PyFlink的改进；

• 2021-09-29：Flink1.14.0 版本发布，主要特性如下：

  • 改进批和流的状态管理机制;

  • 优化checkpoint机制;

  • 不再支持Flink on Mesos资源调度；

  • 开始支持资源细粒度管理；

• 2022-05-05：Flink1.15.0 版本发布，主要特性如下：

  • Per-job任务提交被弃用，未来版本会丢弃，改用Application Mode。

  • Flink依赖包不使用Scala的话可以排除Scala依赖项，依赖包不再包含后缀；

  • 持续改进Checkpoint和两阶段提交优化；

  • 对于Table / SQL用户，新的模块flink-table-planner-loader取代了flink-Table-planner_xx，并且避免了Scala后缀的需要；

  • 添加对opting-out Scala的支持,DataSet/DataStream api独立于Scala,不再传递地依赖于它。

  • flink-table-runtime不再有Scala后缀了；

  • 支持JDK11,后续对JDK8的支持将会移除；

  • 不再支持Scala2.11，支持Scala2.12；

  • Table API & SQL优化，移除FlinkSQL upsert into支持；

  • 支持最低的Hadoop版本为2.8.5；

  • 不再支持zookeeper3.4 HA ,zookeeper HA 版本需要升级到3.5/3.6；

  • Kafka Connector默认使用Kafka客户端2.8.1；

• 2022-10-28：Flink1.16.0 版本发布，主要特性如下：

  • 弃用jobmanager.sh脚本中的host/web-ui-port参数，支持动态配置；

  • 删除字符串表达式DSL;

  • 不再支持Hive1.x、2.1.x、2.2.x版本；

  • 弃用StreamingFileSink，建议使用FileSink。

  • 优化checkpoint机制；

  • PyFlink1.16将python3.6版本标记为弃用，PyFlink1.16版本将成为使用python3.6版本最后一个版本；

  • Hadoop支持3.3.2版本；

  • Kafka支持3.1.1版本；

  • Hive支持2.3.9版本；

• 2023-03-23：Flink 1.17.0版本发布，主要特性如下：

  • Streaming Warehouse API: FLIP-282 在 Flink SQL 中引入了新的 Delete 和 Update API，它们可以在 Batch 模式下工作。在此基础上，外部存储系统比如 Flink Table Store 可以通过这些新的 API 实现行级删除和更新。同时对 ALTER TABLE 语法进行了增强，包括 ADD/MODIFY/DROP 列、主键和 watermark 的能力，这些增强使得用户更容易维护元数据。

  • Batch 性能优化: 在 Flink 1.17 中，批处理作业的执行在性能、稳定性和可用性方面都得到了显着改进。就性能而言，通过策略优化和算子优化，如新的 join-reorder 算法和自适应的本地哈希聚合优化、Hive 聚合函数改进以及混合 shuffle 模式优化，这些改进带来了 26% 的 TPC-DS 性能提升。就稳定性而言，Flink 1.17 预测执行可以支持所有算子，自适应的批处理调度可以更好的应对数据倾斜场景。就可用性而言，批处理作业所需的调优工作已经大大减少。自适应的批处理调度已经默认开启，混合 shuffle 模式现在可以兼容预测执行和自适应批处理调度，同时所需的各种配置都进行了简化。

  • SQL Client/Gateway: Apache Flink 1.17 支持了 SQL Client 的 gateway 模式，允许用户将 SQL 提交给远端的 SQL Gateway。同时，用户可以在 SQL Client 中使用 SQL 语句来管理作业，包括查询作业信息和停止正在运行的作业等。这表示 SQL Client/Gateway 已经演进为一个作业管理、提交工具。

  • Streaming SQL 语义增强: 非确定性操作可能会导致不正确的结果或异常，这在 Streaming SQL 中是一个极具挑战性的话题。Flink 1.17 修复了不正确的优化计划和功能问题，并且引入了实验性功能 PLAN_ADVICE，PLAN_ADVICE 可以为 SQL 用户提供潜在的正确性风险提示和 SQL 优化建议。

  • Checkpoint 改进: 通用增量 Checkpoint（GIC）增强了 Checkpoint 的速度和稳定性，Unaligned Checkpoint (UC) 在作业反压时的稳定性也在 Flink 1.17 中提高至生产可用级别。此外，该版本新引入一个 REST API 使得用户可以触发自定义 Checkpoint 类型的 Checkpoint。

  • Watermark 对齐完善: 高效的 watermark 处理直接影响 event time 作业的执行效率，在 Flink 1.17 中， FLIP-217 通过对 Source 算子内部的 split 进行数据对齐发射，完善了 watermark 对齐功能。这一改进使得 Source 中 watermark 进度更加协调，从而减轻了下游算子的缓存过多数据，增强了流作业执行的整体效率。

  • StateBackend 升级: 此次发布将 FRocksDB 的版本升级到了 6.20.3-ververica-2.0，对 RocksDBStateBackend 带来了许多改进。同时，例如在插槽之间共享内存，并且现在支持 Apple Silicon 芯片组，如 Mac M1。Flink 1.17 版本还提供了参数扩大 TaskManager 的 slot 之间共享内存的范围，提升了 TaskManager 中 slot 内存使用不均是的效率。

• 2023-10-25：Flink 1.18.0版本发布，主要特性如下：

  • Flink SQL 提升

  • 流处理提升

  • 批处理提升

  • Java 17 支持

  • SourceFunction现在已经弃用。如果您仍在使用基于 SourceFunction 构建的连接器，请将其迁移到 Source。SinkFunction 目前尚未正式弃用，但它也即将接近生命周期结束，将被 SinkV2 所取代。

  • Queryable State现已弃用，将在 Flink 2.0 中移除。

  • DataSet API现已弃用。建议用户迁移到执行模式设置为 BATCH 的 DataStream API。

• 2024-03-18：Flink 1.19.0版本发布，主要特性如下：

  • Flink SQL 提升

  • Runtime & Coordination 提升

  • Checkpoints 提升

  • Connector API提升

• 2024-08-02：​​​​​​​Flink 1.20.0版本发布，主要特性如下：

  • 引入物化表

  • 完善 Catalog 相关语法

  • DDL 支持 DISTRIBUTED BY 语句

  • 统一的检查点文件合并机制

  • 压缩小的 SST 文件

  • JobMaster 发生故障时更好的错误恢复机制

  • HiveSource 支持动态并发推断

  • 支持 DataStream API 上的全量分区数据处理

• 2024-10-23：​​​​​​​Flink 2.0-preview1发布；2025-03-24：Flink 2.0.0 发布，这是自 Flink 1.0 发布以来的首次重大更新。主要特性如下：

  • 存算分离状态管理：引入了基于远程存储的存算分离状态管理，解决了容器化环境下计算节点受本地磁盘大小限制的问题，以及 RocksDB 中 LSM 结构的周期性 Compaction 导致计算资源尖峰的问题。

  • 物化表：增强了物化表功能，支持与主流的湖格式集成以及生产就绪的调度器实现。

  • 批作业的自适应执行：具备基于作业已完成阶段的信息，对逻辑计划和物理计划进行动态优化的能力，初步支持的策略包括动态应用 Broadcast Join 以及对数据倾斜的 Join 进行优化。

  • 流式湖仓：Flink 和 Apache Paimon 的集成迈出了重要一步，带来了诸多重要改进，如使用 Paimon 丰富的合并引擎进行 SQL 执行计划优化、大幅提升 Lookup-Join 的性能、支持 Flink 物化表、以及对自适应批处理和推测执行的支持。