浪浪山下那个村 👋🏼

主要区别在与args[0]的值，在C语言当中args[0]是C语言编译出的当前二进制的名称，而在Java当中却是第一个参数的值。比较容易混淆。

背景 在Idea当中运行Test的时候发现报错如下： scala: No scalac found to compile scala sources 但是在操作系统上面安装了scala，在idea当中也安装了 原因 虽然在操作系统上面安装了scala，但是idea当中没有添加scala，

1. 内存设置 1.1 TaskManager 内存模型 TaskManager的内存模型如下图所示(1.10之后版本内存模型)： Flink使用了堆上内存和堆外内存。 Flink 框架内存使用了堆外内存和堆外内存，不计入slot资源。 Task执行的内存使用了堆上内存和堆外内存。 网络缓冲内存：网络数据交换所使用的内存大小，如网络数据交换缓冲区。 框架堆外内存、Task堆外内存、网络缓冲内存都在堆外的直接内存里面。 管理内存：Flink堆外内存的管理，用于管理排序，hash表，缓冲中间结果以及RocksDb 状态后端的本地内存。 JVM特有内存：JVM本身占用的内存，包括元数据和执行开销。 Flink 使用内存 = 框架堆内和堆外内存 + Task堆内和堆外内存 + 网络缓冲内存 + 管理内存。 进程内存 - Flink 内存 + JVM特有内存 1.1.1 JVM特有内存详解 JVM特定内存： JVM本身使用的内存，包含JVM的metaspace和over-head JVM的metaspace：JVM 元空间。taskmanager.memory.jvm-meta-sp....

RocksDB 介绍 RocksDB 是嵌入式的 Key-Value 数据库，在 Flink 中被用作 RocksDBStateBackend 的底层存储。如下图所示，RocksDB 持久化的 SST文件在本地文件系统上通过多个层级进行组织，不同层级之间会通过异步Compaction 合并重复、过期和已删除的数据。在 RocksDB 的写入过程中，数据经过序列化后写入到WriteBuffer，WriteBuffer 写满后转换为 Immutable Memtable 结构，再通过 RocksDB 的flush 线程从内存 flush 到磁盘上；读取过程中，会先尝试从 WriteBuffer 和 Immutable Memtable 中读取数据，如果没有找到，则会查询 Block Cache，如果内存中都没有的话，则会按层级查找底层的 SST 文件，并将返回的结果所在的 Data Block 加载到 BlockCache，返回给上层应用。 RocksDBKeyedStateBackend增量快照介绍 这里介绍一下大家在大状态场景下经常需要调优的 RocksDBKeyedStateBac....

简介 反压（backpressure）是实时计算应用开发中，特别是流式计算中，十分常见的问题。反压意味着数据管道中某个节点成为 瓶颈，处理速率跟不上上游发送数据的速率，而需要对上游进行限速。由于实时计算应用通常使用消息队列来进行生产端和 消费端的解耦，消费端数据源是 pull-based 的，所以反压通常是从某个节点传导至数据源并降低数据源（比如 Kafka consumer）的摄入速率。 简单来说，Flink 拓扑中每个节点（Task）间的数据都以阻塞队列的方式传输，下游来不及消费导致队列被占满后，上游的 生产也会被阻塞，最终导致数据源的摄入被阻塞。 TCP-based 反压的弊端 单个Task导致的反压，会阻断整个TM-TM之间的socket，连checkpoint barries也无法发出。 反压传播路径长，导致生效时延较大。 Credit-based 反压 反压过程简介 如图所示在 Flink 层面实现反压机制，就是每一次 ResultSubPartition 向 InputChannel 发送消息的时候都会发送一个 backlog size 告诉下游准备发送多少消息，下....

数据倾斜原理 数据倾斜就是数据的分布严重不均，流入部分算子的数据明显多余其他算子，造成这部分算子压力过大。 影响 单点问题 数据集中在某些分区上（Subtask），导致数据严重不平衡。 GC 频繁 过多的数据集中在某些 JVM（TaskManager），使得JVM 的内存资源短缺，导致频繁 GC。 吞吐下降、延迟增大 数据单点和频繁 GC 导致吞吐下降、延迟增大。 系统崩溃 严重情况下，过长的 GC 导致 TaskManager 失联，系统崩溃。 Flink数据倾斜问题定位 定位反压 定位反压有2种方式：Flink Web UI 自带的反压监控（直接方式）、Flink Task Metrics（间接方式）。通过监控反压的信息 ，可以获取到数据处理瓶颈的 Subtask。 确定数据倾斜 Flink Web UI 自带Subtask 接收和发送的数据量。当 Subtasks 之间处理的数据量有较大的差距，则该 Subtask 出现数据倾斜。 Flink 如何处理常见数据倾斜 数据源 source 消费不均匀 解决思路：通过调整并发度，解决数据源消费不均匀或者数据源反压的情况。 例如kaf....

设置空闲状态保留时间 不设置空闲状态保留时间会导致状态爆炸。 FlinkSQL 的 regular join inner 、 left 、 right ），左右表的数据都会一直保存在状态里，不会清理！要么设置 TTL ，要么使用 Flink SQL 的 interval join 。 使用 Top N 语法进行去重，重复数据的出现一般都位于特定区间内（例如一小时或一天内），过了这段时间之后，对应的 状态就不再需要了。 Flink SQL可以指定空闲状态（即未更新的状态）被保留的最小时间 当状态中某个 key对应的 状态未更新的时间达到阈值时， 该条状态被自动清理。 API 设置： tableEnv.getConfig().setIdleStateRetention(Duration.ofHours(1)); 配置参数设置： Configuration configuration = tableEnv.getConfig().getConfiguration(); configuration.setString("table.exec.state.ttl", " 1 h" ); ....

底层原理简介 LState:存储左边数据流中的数据。 RState：存储右边数据流中的数据。 当左边数据流数据到达的时候会保存到LState，并且到RState中进行Join。将Join生成的结果数据发送到下游。 右边数据流中数据到达的时候，会保存到RState当中，并且到LState中进行Join，然后将Join之嚄胡的结果数据发送到下游。 为了保障左右两边流中需要Join的数据出现在相同节点，Flink SQL会利用Join中的on的关联条件进行分区，把相同关联条件 的数据分发到同一个分区里面。 普通双流Join 现有订单表A和支付表B进行关联得到汇总表C。订单表和支付表初始数据如下： 表A：订单表数据 order_id timestamp 1001 2023-02-04 10:00:00 1002 2023-01-04 10:01:02 表B：支付表数据 order_id pay_money order_id pay_money 1001 80 1002 100 inner join 当A表中每一条数据到达时，都会和B表中....

Flink大数据常见问题总结。

Neovim是一个社区驱动的开源项目，是Vim文本编辑器的一个分叉版本，它的构建使Vim更容易为核心开发人员维护。是对vim的一个增强，相比与vim性能更好，速度更快。