Flink 是如何统一批流引擎的？.docxVIP

Flink 是如何统一批流引擎的？ 这个很好理解，由于流式作业是 All or Nothing 的设计，要么全部 Task 都 Run 起来，要么就不跑。 05 LAZY LAZY 模式就是先调度上游，等待上游产生数据或结束后再调度下游。有些类似 Spark 中的 Stage 执行模式。 06 Region Scheduling 可以看到，不管是 EAGER 还是 LAZY 都没有方法执行我们刚才提出的批流混合的任务，于是社区提出了 Region Scheduling 来统一批流作业的调度，我们先看一下如何定义 Region： 以 Join 算子为例，我们都晓得假如 Join 算子的两个输入都是海量数据的话，那么我们是需要等两个输入的数据都完全预备好才能进行 Join 操作的，所以 Join 两条输入的边对应的数据交换模式对应的应当是 BLOCKING 模式，我们可以依据 BLOCKING 的边将作业划分为多个子 Region，如上图虚线所示。 假照实现了 Region Scheduling 之后，我们在上面提到的批流混合的作业就可以将深色部分流式作业划为一个 Region，淡色部分批式作业再划分为多个 Region，而淡色部分是深色部分 Region 的输入，所以依据 Region Scheduling 的准绳会优先调度最前面的 Region。 07 总结 上面提到了数据交换模型和调度模型，简约来讲其实就两句话： ?实现了用 PIPELINED 模型去跑批式作业 用 PIPELINED 模型跑流式作业和用 BLOCKING 模型跑批式作业都是没有什么新颖的。这里提到用 PIPELINED 模式跑批作业，次要是针对实时分析的场景，以 Spark 为例，在大部分消灭 Shuffle 或是聚合的场景下都会消灭落盘的行为，并且调度挨次是一个一个 Stage 进行调度，极大地降低了数据处理的实时性，而使用 PIPELINED 模式会对功能有肯定提升。 可能有人会问类似 Join 的算子如何使用 PIPELINED 数据交换模型实现不落盘的操作？现实上 Flink 也会落盘，只不过不是在 Join 的两个输入端落盘，而是将两个输入端的数据传输到 Join 算子上，内存撑不住时再进行落盘，海量数据下和 Spark 的行为并没有本质区分，但是在数据量中等，内存可容纳的情况下会带来很大的收益。 ?集成了一部分调度系统的功能 依据 Region 来调度作业时，Region 内部跑的具体是流作业还是批作业，Flink 本身是不关怀的，更关怀的 Region 之间的依靠关系，肯定程度上，利用这种调度模型我们可以将过去需要拆分为多个作业的执行模式放到一个作业中来执行，比如上面提到的批流混合的作业。 - END - 推举阅读： Openapi 接口设计思路 监控告警成长之路 服务端高并发分布式架构演进之路 开放API接口签名验证，让你的接口从今不再裸奔 点一下在看再走吧