Flink基于checkpoint的容错机制是一项标志性功能。因为这一设计，Flink统一了批流处理，能够很容易扩展到极小和极大场景并支持许多类似状态演化实现有状态升级和回滚及时间穿梭的操作功能。 尽管有这些很棒的特性，Flink的checkpoint方式有一个致命弱点：checkpoint速度取决与数据流过整个应用的速度。当应用发生背压时，checkpoint也同样被压（附录1概括了什么是背压，为什么背压可能是好事）。在这种情况下，checkpoint可能会花费更多时间，甚至会超时。 在Flink 1.11版本，社区引入了一个新特性“非对齐checkpoint”来解决这一问题，在Flink […]
此文章改编自Piotr Nowojski’s presentation from Flink Forward Berlin 2017，你可以从Flink Forward柏林站找到ppt和演讲录音。 Apache Flink 1.4.0发布于2017年12月，为流式处理引入了一个重要的里程碑：TwoPhaseCommitSinkFunction（相关jira单），通过将两阶段提交协议的通用逻辑进行抽取，使得使用Flink和包括kafka等一系列source，sink来开发端到端Exactly-Once的应用成为可能。它提供了一层抽象，用户只需要实现 […]
1. 起因 线上有个Flink ETL任务突发Kafka消费延迟告警，之前压测时150并行度就可以满足需求，线上并行度设置为200，但任务延迟还是不断增加。 查看Kafka监控发现有流量突增，与运维同事沟通后确认是由于有一台Broker节点宕机导致，于是修改任务并行度至400加速消费数据，但消费延迟还是没有下降，吞吐只比200并行度时提高了20%且波动很大。 2. 算子性能瓶颈？ GC问题？ 此时开始怀疑是任务本身出现了性能瓶颈，查看Flink Dashboard发现部分节点的消费数量非常低，初步怀疑是算子内部计算逻辑的RPC调用耗时增加导致的， […]
Flink是为状态流处理而生。然而什么是状态呢？状态可以简单理解为Flink应用中算子处理数据所产生的信息，这些信息将影响后续数据的处理。 状态是大多数复杂流处理程序所必须的一项基础概念，例如： 匹配事件流中的pattern，需要将已经接受到的事件存储到状态中 每分钟的事件聚合，需要用状态来缓存待聚合事件。 通过事件流训练模型，需要用状态存储当前的模型参数。 然而在实际生产环境中，只有支持容错的状态才是有意义的。“支持容错”意味着无论是出现软件还是硬件错误，计算的最终结果总是准确的，不会出现数据丢失或者重复计算。 Flin […]