shengjk1的博客

Flink 的 Materialized Table 为简化数据管道的开发和管理提供了一种强大的解决方案。它通过统一流批处理、降低开发成本、提高数据处理灵活性等方式，帮助用户更高效地应对复杂的数据处理需求。虽然目前还存在一些限制，但随着技术的不断进步和社区的努力，这些问题有望得到解决。对于需要构建高效、灵活数据管道的开发者来说，Materialized Table 是一个值得深入探索和应用的技术。

本文介绍了Java中的Metaspace，以及如何设置Metaspace的大小和增长速度等参数。同时，通过分析GC日志，发现了使用Aviator表达式引擎时可能导致Metaspace内存泄漏的问题，并提供了解决方案。

文章主要介绍了作者在开发一个基于状态计算各种汇总数据的Flink作业时遇到的问题排查过程。作者一开始遇到报错后尝试调大Flink参数解决问题，但仍出现FullGC严重的情况。经过查看数据量、增大内存和排查后发现是由于Metadata内存分配失败导致的FullGC，最终调大JVM metadata阈值解决了问题。

Java的可移植性和跨平台性也是其受欢迎的原因之一。另外，Java社区的活跃程度也是不容忽视的，Java的开发者群体庞大且经验丰富，他们可以为Flink提供宝贵的支持和指导，从而帮助用户更好地使用和优化Flink的功能。随着时间的推移，Flink社区的主要焦点已经转向JavaAPI，而Flink中的Scala支持与JavaAPI并不同步。Flink抛弃Scala的主要原因是因为，社区缺少Scala相关的人员，并且新的Api都是Java的，另外因为兼容性问题，Scala和JavaApi的发展并不同步。

细细查看就发了改变的 keyby 对应的 value，然后就会觉得很奇怪，为啥改变它会无法从 ck 中恢复呢？源码中已经枚举出来了，存在 Flink backends 中不同类型的 state，当他们中任何一个发生变化时都没有办法从 ck 中 restore。Flink State 是有元数据的，元数据发生改变后，Flink 就无法从 ck 或者 savepoint 中恢复。有时候明明没有改动关于。

OperatorChain 的对象重用，可以提高效率，但什么情况下可以重用，什么情况下不可以重用，我们一起来看你一下代码：首先，在OperatorChain 类的 createChainedOperator 方法如果启用了对象重用，即 isObjectReuseEnabled==true，创建的 outPut 为 ChainingOutput，如果没有启用对象重用，则 outPut 为 CopyingChainingOutput。需要明确的是 currentOperatorOutput 是为给下游算子输入

背景我们经常通过 Flink Shell 提交代码，如 flink run -p 2 -m yarn-cluster -ynm test -c test ./test-1.0-SNAPSHOT.jar "file" "./test.properties"&正文总结

背景学习了 apache calcite，基本上把 apache calcite 的官网看了一遍，也写了几个小例子，现在该分析一下 Flink SQL 的执行过程了，其中关于 apache calcite 的部分不深究，因为 apache calcite 有些复杂，真的要了解清楚需要大量时间，本次还是聚焦 Flink.正文以 SQL Query 为例 select a.* from a join b on a.id=b.idsql query 入口方法// sql query 入口方法 ove

背景刚开始接触 FlinkSQL 时，对 LAST_VALUE 特别好奇，虽然工作当中有在用到，但还是特别的想知道它是怎么实现的，今天终于可以总结一下原理当我们写入如下类似的 sql 时，就会用到 LAST_VALUE 函数select LAST_VALUE(status) from temp;LAST_VALUE 函数对应的具体类为 LastValueWithRetractAggFunction。LAST_VALUE函数之所以能够起作用最关键的是 /** Accumulator for L

背景前面我们了解了 写给大忙人看的Flink 消费 Kafka，今天我们一起来看一下 FlinkSQL Kafka 是如何与 Flink Streaming Kafka 结合起来的正文创建 kafka sourceCREATE TABLE orders( status int, courier_id bigint, id bigint, finish_time BIGINT, place_time BIGINT, PR

0. 背景1. Session Mode2. Per-Job Mode3. Application Mode4. 总结5. 参考0.背景关于 Flink 的 Application Mode 自己还比较陌生，像 -d 等参数自己也不熟悉，决定好好总结一下1.Session Mode这个不用多说，也就是起一个 session，然后会有多个程序提交到这一个 session 中。好处：集群资源仅分配一次，充分利用资源，程序App 启动较快坏处：可能会连锁式的重启，jobManager 负.

背景由于公司内部需求较多，并不想每次都写一个 streaming 程序，故而开始搭建 flinksql 平台效果传一个 sql 文件给 jar 包，然后 sql 文件内的 sql 将自动执行为什么选用 jar 而不是 web调研了基于 web 的 zeppline，有一下几个担心的点zeppline 设计的初衷其实是为了交互式分析基于 zeppline rest api 与现有的监控不兼容，需要修改现有监控的代码虽然带有 web 界面的对用户很是友好，对于分析人员来说，是一个不错的选择，但

前言使用 flink 很长一段时间了，突然发现竟然没有计算过 topN，这可是 flink 常见的计算场景了， 故自己想了一个场景来计算一下。基于 Flink 1.12场景外卖员听单的信息会发到单独一个 topic 中，计算一个每天有多少个 外卖员听单以及总共的听单次数。kafka 中消息类型{"locTime":"2020-12-28 12:32:23","courierId":12,"other":"aaa"}locTime：事件发生的时间，courierId 外卖员id计算一天中 听

前言使用 flink 很长一段时间了，突然发现竟然没有计算过 pv uv，这可是 flink 常见的计算场景了，面试时也是常问题之一。故自己想了一个场景来计算一下。基于 Flink 1.12场景外卖员听单的信息会发到单独一个 topic 中，计算一个每天有多少个 外卖员听单以及总共的听单次数。kafka 中消息类型{"locTime":"2020-12-28 12:32:23","courierId":12,"other":"aaa"}locTime：事件发生的时间，courierId 外卖

之前在介绍 flink timer 的时候( 一文搞懂 Flink Timer ) 官网有这样的一句话Flink synchronizes invocations of onTimer() and processElement(). Hence, users do not have to worry about concurrent modification of state.当时觉得特别奇怪，今天我们就一起来看一下，flink 是如何保证 onTimer 与 processElement 同步的以

1. 正文2. 总结1.正文前面，我们已经学过了 一文搞懂 Flink 处理 Barrier 全过程，今天我们一起来看一下 flink 是如何处理水印的，以 Flink 消费 kafka 为例 FlinkKafkaConsumer<String> consumer = new FlinkKafkaConsumer<String>(topics, new SimpleStringSchema(), properties); consumer.setStartFromL.

总括详解一般情况下，我们会写如下的代码DataStreamSource<Tuple2<Long, Long>> addSource = env.addSource(new WordSource()); addSource.join(addSource).where(new KeySelector<Tuple2<Long, Long>, Long>() { @Override public Long getKey(Tuple2&lt

什么是装饰者模式动态的将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案。简单的理解就是通过包装来扩展功能，相比于继承，更有弹性Flink 是如何实现观察者模式的@Internalpublic class KafkaDeserializationSchemaWrapper<T> implements KafkaDeserializationSchema<T> { private static final long serialVersionUID =

什么是观察者模式定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新观察者模式实现1.可观察者，也可以称之为主题2.观察者其实类似于订阅邮件，订阅者就是观察者，而发送邮件的就是可观察者( 主题 )/** * @author shengjk1 * @date 2020/11/9 *///主题，注册观察者、remove观察者、// nofity observer 通知完之后，具体 Observer 要做什么完全在于 Observer//

1. 背景2. 步骤3.自定义 Format 4. 使用自定义 Format1.背景由于 kafka 中的 json 属于嵌套，又不想二次序列化再把它展开，故自定义 format。2.步骤1.自定义 Factory 实现 DeserializationFormatFactory2.自定义 DeserializationSchema 实现 DeserializationSchema3. 自定义 Factory 中 createDecodingFormat 方法返回 createDeco.

背景内部要做 Flink SQL 平台，本文以自定义 Redis Sink 为例来说明 Flink SQL 如何自定义 Sink 以及自定义完了之后如何使用基于 Flink 1.11步骤implements DynamicTableSinkFactoryimplements DynamicTableSink创建 Redis Sink自定义 sink 代码import com.ishansong.bigdata.common.util.redis.RedisUtil;import org

缺少 flink-client jar引入即可<dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-clients_2.11</artifactId> <version>${flink.version}</version> </dependency&

工作中遇到了与 snapshot 异常相关的问题，特此总结一下，与 snapshot 相关的流程图如下：当调用 AbstractUdfStreamOperator.snapshotState 方法时，实际上调用了public static void snapshotFunctionState( StateSnapshotContext context, OperatorStateBackend backend, Function userFunction) throws Excepti

错误今天在实验 Flink 连接 hive 的操作，由于 CDH 的 hadoop 是 HA，连接过程中报错如下：Exception in thread "main" java.lang.IllegalArgumentException: java.net.UnknownHostException: nameservice1 at org.apache.hadoop.security.SecurityUtil.buildTokenService(SecurityUtil.java:378) at o

1. 前言2. FlatMap 的转化1.前言通过一文搞懂这一系列的文章，我们已经知道了，Flink 作业的提交过程：这篇文章主要聚焦在我们以简单的代码为例/** * @author shengjk1 * @date 2018/11/23 */public class FlinkJava8Demo { public static void main(String[] args) throws Exception { StreamExecutionEnvironmen..

对于分布式框架来说，我们经常听到的一句话就是：移动计算，不移动数据。那么对于 Flink 来说是如何移动计算的呢？我们一起重点看一下 ExecuteGraph基本概念ExecutionJobVertex：表示 JobGraph 的一个计算顶点，每个 ExecutionJobVertex 可能会有很多个 并行的 ExecutionVertexExecutionVertex：表示一个并行的 subtaskExecution: 表示 ExecutionVertex 的一次尝试执行Graph 变化源代

什么是 Timer顾名思义就是 Flink 内部的定时器，与 key 和 timestamp 相关，相同的 key 和 timestamp 只有一个与之对应的 timer。timer 本质上是通过 ScheduledThreadPoolExecutor.schedule 来实现的Flink synchronizes invocations of onTimer() and processElement(). Hence, users do not have to worry about concurr

当我们设置 rocksdb state backend 时，并且从 checkpoint 重启时，首先进入 RocksDBKeyedStateBackendBuilder 的 getRocksDBRestoreOperation 方法// rockdb restore 入口方法 private AbstractRocksDBRestoreOperation<K> getRocksDBRestoreOperation( int keyGroupPrefixBytes, Closeabl

由 一文搞懂 checkpoint 全过程，我们可以知道当 executeCheckpointing 的时候会执行 AsyncCheckpointRunnable@Override public void run() { ...... reportCompletedSnapshotStates( jobManagerTaskOperatorSubtaskStates, localTaskOperatorSubtaskStates, asyncDura

前言上一篇 一文搞定 Flink Job 提交全流程，我们知道每一个 operator chain 作为一个整体，提交 task 。正文@Override // Execution 将 task submit 至此 public CompletableFuture<Acknowledge> submitTask( TaskDeploymentDescriptor tdd, JobMasterId jobMasterId, Time timeout) { try

前言前面，我们已经分析了 一文搞定 Flink 消费消息的全流程 、写给大忙人看的 Flink Window原理 还有 一文搞定 Flink Checkpoint Barrier 全流程 等等，接下来也该回归到最初始的时候，Flink Job 是如何提交的。正文我们知道 Flink 总共有两种提交模式：本地模式和远程模式( 当然也对应着不同的 environment，具体可以参考 Flink Context到底是什么？)，我们以本地模式为主，两种模式基本上相似。当我们执行 env.execute ，

前言上一篇，我们了解了 checkpoint 全流程，现在我们具体讲解一下 checkpoint 时 snapshot 的全过程

前言前面我们讲解了 一文搞懂 Flink 处理 Barrier 全过程 和 一文搞定 Flink Checkpoint Barrier 全流程 基本上都是跟 checkpoint 相关。这次我们就具体看一下 checkpoint 是如何发生的。正文跟 checkpoint 相关的起点在 buildGraph@Deprecated public static ExecutionGraph buildGraph( @Nullable ExecutionGraph prior, JobGra

上次我们讲到了 Flink Checkpoint Barrier 全流程 还有 Flink 消费消息的全流程分类Flink 处理 Barrier 分两种：barrier 对齐barrier 不对齐对应的类我们就以 BarrierBuffer ( barrier 对齐 ) 为例。正文关键就是 getNextNonBlocked 方法 @Override // 从 ResultSubPartition 中获取数据并处理 barrier public BufferOrEvent get

上文中，我们一起了解了 一文搞定 Flink 消费消息的全流程，接下来呢，我们一起来看一下 checkpoint barrier 的全流程。首先呢，Job 启动的时候，Flink 会 startCheckpointSchedulerpublic void startCheckpointScheduler() { synchronized (lock) { if (shutdown) { throw new IllegalArgumentException("Checkpoint coo

Window 可以说是 Flink 中必不可少的 operator 之一，在很多场合都有很非凡的表现。今天呢，我们就一起来看一下 window 是如何实现的。window 分类Tumbling WindowSliding WindowSession WindowGlobal Windowwindow operatorevictorevictor 主要用于做一些数据的自定义操作，可以在执行用户代码之前，也可以在执行用户代码之后，更详细的描述可以参考 org.apache.flink.str

我们以下面代码为例：FlinkKafkaConsumer<String> consumer = new FlinkKafkaConsumer<>("canal_monitor_order_astable", new SimpleStringSchema(), properties); consumer.setStartFromEarliest(); env.addSource(consumer).flatMap(...).print()当 Flink 程序启动，lea

写给大忙人看的Flink 消费 Kafka 已经对 Flink 消费 kafka 进行了源码级别的讲解。可是有一点没有说的很明白那就是 offset 是怎么存储到状态中的？Kafka Offset 是如何存储在 state 中的在 写给大忙人看的Flink 消费 Kafka 的基础上继续往下说。// get the records for each topic partition // 我们知道 partitionDiscoverer.discoverPartitions 已经保证了 sub

1. 疑问2. 解释1. 疑问前一篇文章 一文搞懂 Flink window 元素的顺序问题 我们已经知道了，state 的获取、更新、清除等都与 key 相关。那么 key 是如何设置的呢？2.解释这需要从 StreamTask 的 run 方法说起。以 OneInputStreamTask 为例，当程序启动开始消费消息时，会进行 OneInputStreamTask 的 run 方法，@Override protected void run() throws Exceptio..

1. 起因2. 解释1. 起因在我们使用 evictor 算子的时候，官网有这样的一句话：Flink provides no guarantees about the order of the elements within a window. This implies that although an evictor may remove elements from the beginning of the window, these are not necessarily t..