针对版本v1.14.3 ,之前的都是基于v1.12 .Flink的官方文档的变动不是一般的小.而且版本升级也挺快短短4个月从1.12发布到了1.14.3 . 总是该文是基于v1.14.3版本cuiyaonan2000@163.com
该批流统一是基于DataStream的官方最新文档梳理,版本v1.14.3cuiyaonan2000@163.com
参考资料:
- 执行模式（流/批） | Apache Flink
DataStream API 支持不同的运行时执行模式，你可以根据你的用例需要和作业特点进行选择。
哪两种呢?如下所示(废话么~~~):
流（STREAMING）执行模式: 这种模式适用于需要连续增量处理，而且预计无限期保持在线的无边界作业。批（BATCH）执行模式: 这种执行作业的方式更容易让人联想到批处理框架，比如 MapReduce。这种执行模式适用于有一个已知的固定输入，而且不会连续运行的有边界作业。
注意这里是在使用DataStream API的时候选择 设置不同的模式,如果选择对了会对你的程序起到优化的效果.毕竟流数据跟批量数据的不同.cuiyaonan2000@163.com
官方文档描述:
通过启用批执行，我们允许 Flink 应用只有在我们知道输入是有边界的时侯才会使用到的额外的优化。例如，可以使用不同的关联（join）/ 聚合（aggregation）策略，允许实现更高效的任务调度和故障恢复行为的不同 shuffle。下面我们将介绍一些执行行为的细节。
一般来说，在你的程序是有边界的时候，你应该使用批执行模式，因为这样做会更高效。当你的程序是无边界的时候，你必须使用流执行模式，因为只有这种模式足够通用，能够处理连续的数据流。
执行模式可以通过 execute.runtime-mode 设置来配置。有三种可选的值：
STREAMING: 经典 DataStream 执行模式（默认)BATCH: 在 DataStream API 上进行批量式执行AUTOMATIC: 让系统根据数据源的边界性来决定
$ bin/flink run -Dexecution.runtime-mode=BATCH examples/streaming/WordCount.jar
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
env.setRuntimeMode(RuntimeExecutionMode.BATCH);具体参考V14.3的官网.这只简单说明下.我感觉差别比较大的.
先看官网的用例代码:
StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
DataStreamSource source = env.fromElements(...);
source.name("source")
.map(...).name("map1")
.map(...).name("map2")
.rebalance()
.map(...).name("map3")
.map(...).name("map4")
.keyBy((value) -> value)
.map(...).name("map5")
.map(...).name("map6")
.sinkTo(...).name("sink");包含 1-to-1 连接模式的操作(即算子并行度为1)，比如 map()、 flatMap() 或 filter()，可以直接将数据转发到下一个操作，这使得这些操作可以被链接在一起。这意味着 Flink 一般不会在他们之间插入网络 shuffle。
而像 keyBy() 或者 rebalance() 这样需要在不同的任务并行实例之间进行数据 shuffle 的操作，就会引起网络 shuffle。------这里的shuffle你可以理解为任务拆分以及合并,即多少个算子算一个任务放在一个taskmanager中cuiyaonan2000@163.com
对于上面的例子，Flink 会将操作分组为这些任务:
- 任务1:
source、map1和map2 - 任务2:
map3和map4 - 任务3:
map5、map6和sink
我们在任务1到任务2、任务2到任务3之间各有一次网络 shuffle。这是该作业的可视化表示：
在流执行模式下，所有任务需要一直在线/运行。这使得 Flink可以通过整个管道立即处理新的记录，以达到我们需要的连续和低延迟的流处理。这同样意味着分配给某个作业的 TaskManagers 需要有足够的资源来同时运行所有的任务。
网络 shuffle 是 流水线 式的，这意味着记录会立即发送给下游任务(即流模式下,数据从一个算子到另一个算子是实时的,不会存在停顿cuiyaonan2000@163.com)，在网络层上进行一些缓冲。同样，这也是必须的，因为当处理连续的数据流时，在任务（或任务管道）之间没有可以实体化的自然数据点（时间点）。这与批执行模式形成了鲜明的对比，在批执行模式下，中间的结果可以被实体化，如下所述。
在批执行模式下，一个作业的任务可以被分离成可以一个接一个执行的阶段。我们之所以能做到这一点，是因为输入是有边界的，因此 Flink 可以在进入下一个阶段之前完全处理管道中的一个阶段。在上面的例子中，工作会有三个阶段，对应着被 shuffle 界线分开的三个任务。
不同于上文所介绍的流模式立即向下游任务发送记录，分阶段处理要求 Flink 将任务的中间结果实体化到一些非永久存储中，让下游任务在上游任务已经下线后再读取。这将增加处理的延迟，但也会带来其他有趣的特性。其一，这允许 Flink 在故障发生时回溯到最新的可用结果，而不是重新启动整个任务。其二，批作业可以在更少的资源上执行（就 TaskManagers 的可用槽而言），因为系统可以一个接一个地顺序执行任务。-----最大的差别就是批模式的任务是分阶段执行的,即如上的3个任务处理,不像流模式那样同时存在,批模式下这3个任务是一个执行完了,才创建另外一个任务.所以这里需要实例化中间结果cuiyaonan2000@163.com
TaskManagers 将至少在下游任务开始消费它们前保留中间结果（从技术上讲，它们将被保留到消费的流水线区域产生它们的输出为止）。在这之后，只要空间允许，它们就会被保留，以便在失败的情况下，可以回溯到前面涉及的结果。
DataStream API模式的更多差异参考官方文档:执行模式（流/批） | Apache Flink
