BigData | 优秀的流处理框架 Flink

? Index

• Flink核心模型介绍
• Flink的架构介绍
• Flink与Spark的异同之处

? Flink核心模型介绍

Apache Flink就是其中的翘楚，它采用了基于操作符（operator）的连续流模型，可以做到微秒的延迟。Flink最核心的数据结构是Stream，它代表一个运行在多个分区上的并行流，它没有边界，随着时间的增长而不断变化，而且它是逐条进行操作的，每当有新数据进行就会被执行，这也是Flink低延迟的根本。

当一个Flink程序被执行的时候，会被映射为Streaming Dataflow，如下图：

图来自极客时间

其中，Streaming Dataflow由 Operator以及Stream组成，Transformation Operator把一个或多个Stream转换成Stream，一个Stream可以包含多个分区（Stream Partitions），一个操作符可以被分成多个操作符子任务，每个子任务在不同的线程或者不同的机器节点中独立执行。

Stream与Operator之间传输数据有两种形式：

• One-to-One（一对一）：Stream维护着分区以及元素的顺序，每个操作符与Stream之间一一对应。
• Redistributing（重新分布）：Stream中数据的分区会发生改变，操作符的每一个子任务把数据发送到不同的目标子任务。

? Flink的架构介绍

Flink的架构如下图所示：

图来自极客时间

同样的，这架构也是大致分成4层：存储层、部署层、核心处理引擎层、high-level的API和库。

• 存储层：兼容多种主流文件系统，如HDFS、Amazon S3，多种数据库，如HBase，多种数据流，如Kafka、Flume等
• 部署层：支持本地运行，还可以在独立集群或者被YARN或Mesos管理的集群上运行，也可以部署在云端
• 核心处理引擎：其实就是Streaming Dataflow，因为所有的程序都会被映射成这种形式来执行
• High-Level：核心API就是DataSet API以及DataStream API，一个用来做批处理、一个用来做流处理

? Flink与Spark的异同之处

Flink的诞生总是有原因的，简单来说因为它统一了批处理和流处理，并且对于实时计算可以实现微秒级别的输出。

与Spark一样的地方

• 基于内存计算
• 都有统一的批处理和流处理API
• 都支持SQL编程
• 都支持多种转换操作，如map、filter、count、groupBy等等
• 都有完善的错误恢复机制
• 都支持Exactly One的语义一执行

与Spark不一样的地方

• Spark虽然也支持流处理，但是其实也还是批处理，因为它只是把流处理当成了window很小的批处理，所以延迟性得不到保证；而Flink是基于每个事件去处理，每当由新数据进来的时候就会马上执行，延迟上明显优于Spark
• 虽然都支持SQL编程，但Spark提供的SparkSQL会在使用性能上更优，而Flink提供的Table API仍有很大的进步空间，如相应的优化、扩展和性能方面
• 生态圈方面，Spark会明显优于Flink

? Spark和Flink的适用场景

在下面的场景，可以优先使用Spark：

• 数据量大而且业务逻辑复杂的批处理，并且对计算效率有很高要求
• 基于历史数据的交互式查询
• 对实时流数据处理，延迟仅仅需要数百毫秒到数秒之间

在下面的场景，可以优先使用Flink：

• 对延迟要求很高的实时数据处理场景，如实时日志报表

? References

• 百度百科
• 蔡元楠-《大规模数据处理实战》21小节 —— 极客时间