从流批一体到流批融合 流批融合的技术解决方案 社区进展及未来展望
从流批一体到流批融合
1.1 流批一体
1.2 影响流批不同模式的前提条件
批作业：可以做到见缝插针式的资源使用方式。即使当前物理资源不满足所有算子同时执行的需求，也可以先利用现有资源执行一部分任务（task）。任务执行完后空出的资源可以调度下一批任务，从而提高资源利用率。 流作业：为了保证更好的实时性，流作业需要在一开始就申请好从源头（source）到终点（sink）的所有算子及其并发资源，以确保数据流的连续性和低延迟。
批作业：可以只保存一个主键对应的状态，并连续处理该主键的所有数据。 流作业：由于无法预知下一个相同主键的数据何时到来，需要保存所有主键的状态，并对随机访问进行优化，以支持实时处理。
批作业：在每个任务执行完之后，Flink作业可以暂时将中间结果缓存下来，然后下一个任务可以接着消费这个中间结果。当某个任务失败时，只需重启该任务，并从之前保存的中间结果重新消费即可。 流作业：Flink引入了检查点（checkpoint）机制，通过定时对整个数据处理链路进行快照，实现容错。当某个任务失败时，可以从最近的检查点恢复，从而保证数据处理的连续性和一致性。
1.3 前提条件的动态变化
在离线场景中，作业场景一般始终具有高吞吐量的倾向。 而在实时场景下，用户通常更注重低延迟、高实时性和高数据新鲜度。然而，当实时场景出现数据积压时，由于客观因素的限制，Flink 作业此时已经无法维持端到端的低延迟策略。这时，用户追求的是以最短时间消费完现有的数据积压、尽快恢复到实时状态，即高吞吐量策略。 在全增量一体化的场景中，这两种模式的区别进一步被细化为全量和增量的区别。在这两种状态下，除了对吞吐量和实时性的要求不同外，还有关于数据先验知识的变化。在同步一个全量数据库的场景下，所有数据之间的主键不会重复，是对整个数据库进行一次全面扫描。而在增量场景下，可能会出现更新操作，对已有的重复主键进行数据更新。
1.4 流批融合的目标
实现流批融合的技术方案
2.1 数据流批倾向性的定量指标
2.2 量化指标的收集
2.3 基于量化指标的优化策略
（1）Processing Time Temporal Join
（2）调整checkpoint时间间隔
（3）优化数据的处理顺序
（4）基于isInsertOnly优化Sink行为
社区进展以及未来展望
3.1 isProcessingBacklog进展
3.2 isInsertOnly进展
3.3 未来展望
点击「阅读原文」跳转 FFA 2024官网提交议题或报名 ～
公众号：Apache FlinkFlink全新周边正式上线！议题征集正在进行中！
活动推荐
