开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第1天 juejin.cn/post/716729…
Apache Flink 是一个开源的分布式，高性能，高可用，准确的流处理框架。 分布式：表示flink程序可以运行在很多台机器上， 高性能：表示Flink处理性能比较高 高可用：表示flink支持程序的自动重启机制。 准确的：表示flink可以保证处理数据的准确性。 Flink支持流处理和批处理，虽然我们刚才说了flink是一个流处理框架，但是它也支持批处理。 其实对于flink而言，它是一个流处理框架，批处理只是流处理的一个极限特例而已。
业务逻辑图
左边：数据源，日志信息，数据库，文件系统，非关系型数据库
中间：Flink，进行数据处理
右边：目的地位置，落地存储系统、日志、文件、非关系型数据库
架构图
底层：Flink的部署模式，local，集群，云端
第二层：分布式流处理引擎
第三层：Flink核心Api：包括DataStream与DataSet
第四层：复杂实践处理，机器学习，图计算，Table操作等。
结论：Flink存在自己的生态圈，包含批处理，微批处理等等。功能上，它与Spark类似，但是计算引擎本质上，还是存在非常大的区别
三大核心组件
DataSource：数据源-接入数据
Transformations：算子：对数据进行处理
DataSink：输出组件-落地数据
流处理与批处理
框架对比
一般来讲：批处理和流处理是两种不同的任务，普遍大数据计算框架设计的核心也是只能处理其中一种任务。
比如Storm只负责流处理，MapReduce，Spark只支持批处理。这里要说下Spark Streaming是Spark上支持的流处理任务子系统，表面看是特例，实际上只是Spark Streaming采用微批的架构，把输入的数据流切分成细粒度的批次，并为每个批次提交一个批处理Spark任务，所以本质上还是批处理，它与流处理的设计核心是完全不同的。
Flink优势
Flink通过灵活的设计，可以同时支持流处理和批处理。
在执行引擎这一层，流处理系统与批处理系统最大的不同在于节点之间的数据传输方式。
对于一个流处理系统，其节点间数据传输的标准模型是：当一条数据被处理完成后，序列化到缓存中，然后立刻通过网络传输到下一个节点，由下一个节点继续处理 这就是典型的一条一条处理。
而对于一个批处理系统，其节点间数据传输的标准模型是：当一条数据被处理完成后，序列化到缓存中，并不会立刻通过网络传输到下一个节点，当缓存写满的时候，就持久化到本地硬盘上，当所有数据都被处理完成后，才开始将处理后的数据通过网络传输到下一个节点。
这两种数据传输模式是两个极端，对应的是流处理系统对低延迟的要求和批处理系统对高吞吐量的要求。
Flink的执行引擎采用了一种十分灵活的方式，同时支持了这两种数据传输模型。
Flink以固定的缓存块为单位进行网络数据传输，用户可以通过缓存块超时值指定缓存块的传输时机。
- 如果缓存块的超时值为0，则Flink的数据传输方式类似前面所说的流处理系统的标准模型，此时系统可以获得最低的处理延迟
- 如果缓存块的超时值为无限大，则Flink的数据传输方式类似前面所说的批处理系统的标准模型，此时系统可以获得最高的吞吐量。
这样就比较灵活了，其实底层还是流式计算模型，批处理只是一个极限特例而已。
三种传输模型如：
图1：一条一条处理
图2：一批一批处理
图3：按照缓存超时值处理，可大可小，同时支持
实时框架选型
1：需要关注流数据是否需要进行状态管理
2：消息语义是否有特殊要求At-least-once或者Exectly-once
3：小型独立的项目，需要低延迟的场景，建议使用Storm
4：如果项目中已经使用了Spark，并且秒级别的实时处理可以满足需求，建议使用SparkStreaming
5：要求消息语义为Exectly-once，数据量较大，要求高吞吐低延迟，需要进行状态管理，建议选择Flink
