上两篇文章中分别介绍了Spark堆内和堆外内存溢出的排查案例，这次我们来看一个Flink任务的真实案例。 有一个线上任务，代码逻辑相对简单，从kafka读取数据，进行异步查询后落地数据到hdfs： 此任务启动后1-2天就会出现内存超出Yarn container限制而被终止的异常： 2024-05-06 00:16:36,280 INFO org.apache.flink.runtime.resourcemanager.active.ActiveResourceManager [] – Worker container_e10_1634010428940_125776_01_000003 is […]
上一篇文章我们通过一个真实案例介绍了Spark任务堆内存溢出的排查思路和方法，接下来啃一个硬骨头：Container killed by YARN for exceeding physical memory limits。 如果你经常在Yarn集群执行Spark任务，一定会遇到这个异常，我们只知道Executor使用的内存超过了向Yarn申请的内存，但是具体原因如何排查呢？为什么-Xmx参数已经限制了堆内存大小，还是会溢出呢？ 1.JVM内存构成 要解决这个问题，我们先要了解JVM的内存构成： Heap Space：也就是堆内存，大小由Xmx和Xms控制，由jvm负责进行垃圾回收，溢出时会产生 […]
先来看一个简单的Spark任务： ss.sparkContext.sequenceFile(inputPath, classOf[Text], classOf[BytesWritable]) .map(i => (i._1.toString.split("#")(1), (i._1.toString, i._2.copyBytes()))) .repartitionAndSortWithinPartitions(new HashPartitioner(partition)) .map(_._2) .saveAsSequenceFile(outputPath, Opti […]
Flink源码中经常会出现以下注解： @GuardedBy @ThreadSafe @Nullable @PublicEvolving …… 这些注解在Flink中的作用主要分为几大类： 代码静态检查： @GuardedBy 检查操作被注解的对象/方法前是否对指定锁对象进行加锁 @ThreadSafe 类是线程安全的 @Nullable 被标注对象可以为空 接口迭代状态&发版对比： @PublicEvolving 类/方法相对稳定，可以被外部调用，但接口/签名(返回类型+参数类型)可能会发生变化 @Public 类/方法相对稳定，只有跨大版本才可能进行修改 @Experimen […]
这篇文章大致介绍Flink如何调度job以及JobManager是如何表示并追踪其状态的。 调度 Flink中的执行资源通过Task Slots来定义。每一个TaskManager拥有一个或多个task slots，每个slot可以执行并行任务中的一个pipeline。一个pipeline包含多个连续任务，例如第n个MapFunction和第n个ReduceFunction实例的组合。注意Flink经常并行执行连续任务：对于流处理程序十分常见，对于批处理程序也经常发生。 下图说明了这一点。设想一个程序有一个data source，一个MapFunction和一个ReduceFunction。S […]
数据分析领域正在见证许多用例从批处理到流处理的演变。尽管批处理可以被作为流处理的一个特殊例子，处理永不结束的流式数据通常需要转换思维方式且通常有自己的术语（例如“窗口”和“最少一次/只有一次”处理）。这对于新接触流处理的人来说可能会相当疑惑。Flink是一个可用于生产的流处理器，具有易于使用但有表现力的API来构建高级流式分析程序。Flink的API在数据流窗口的定义十分灵活，使其从其他开源流处理器中脱颖而出。 在这篇文章中，我们将讨论流式处理窗口的概念，展示Flink内置窗口并解释其对自定义窗口语义的支持。 什么是窗口，窗口有什么用？ &ems […]
动机 此FLIP旨在解决当前流式source接口（SourceFunction）的一些问题和短板，同时统一流批的source接口。我们要解决的缺点或要点： 当前批流的source实现是不同的。 “工作发现”（splits,partition等）和实际的数据“读取”混杂在SourceFunction接口和DataStream API中，导致注入Kafka和Kinesis这类source的实现十分复杂。 Partitions/shards/splits在接口中不明确。这使得实现一个source无关的特定方法十分困难，例如event-time对齐，per-partition watermarks，动 […]
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调用耗时增加导致的， […]