双流 join 的场景下可以考虑关联条件引入时间属性，变成 interval join 可以实现一定的时间对齐（
https://nightlies.apache.org/flink/flink-docs-release-1.16/docs/dev/table/sql/queries/joins/#interval-joins
）
另外如果可以使用 lookup join 单边驱动关联并且不是所有数据都需要等待的话，可以尝试 lookup join 的延迟重试
https://nightlies.apache.org/flink/flink-docs-release-1.16/docs/de
flink on native k8s模式调度能否根据节点磁盘和网络io指标进行调度？
貌似现在只能根据cpu/内存剩余量进行调度，但如果新加一个节点会导致新作业全部的pod都部署到该节点上，造成该节点网络或磁盘IO飙升，这种情况有什么好的对策么？
有人能够解答一下吗？
在 2022-11-26 11:20:34，"casel.chen" 写道：
>双流关联场景下，流A数据到达后并不马上和流B进行关联，而是经过设置一段时间后再关联，这种场景下如何用flink
>sql实现？如果当前不支持，需要怎样扩展flink sql呢？
维表流数据晚于主表流数据到达甚至可能到达不了，所以想设置个5分钟等待窗口，关联上正常处理，关联不上发到另一个kafka topic，这种场景使用flink
sql要如何实现？
各位，问一下我一个main方法里面用了datastream api和table
api，用命令行提交任务是没问题的，insert作业和其他的datastream job会拆开生成多个作业。但是当我用flink web
ui提交任务时报上面这个错，有什么解决方案吗？
我的代码：
中间还有一些processfunction
flink on native kubernetes如何使用 affinity 配置软互斥？即同一个作业的不同pod分布在不同的节点node上
在 2022-12-05 19:51:02，"casel.chen" 写道：
>我司flink作业运行在k8s集群上，日前发现有一些k8s集群节点的网络io在某些时间段超过了告警阈值180MB/s，最多达到430MB/s，最少的只有4MB/s，导致新作业无法部署到网络负载高的节点上，哪怕cpu和内存还有很多剩余。
>目前我想的办法是利用节点亲和性手动从负载高的节点上迁移出那些耗网络io高的作业pod到负载低的节点，
如题，这个问题长期存在，我想了解几个点：
（1）connection time out
是连接时才会报的错误嘛？作业正常运行期间可能有嘛？我理解是连接时的报错，但是我看部分报错是作业运行不少时间才报错的（比如40分钟，1小时多），这种时刻为什么会有
connect 操作呢？netty的connection不是在作业启动时，就发 partition request 的时候创建好的嘛。
（2）之前调整过 netty 的 server 的 backlog，目前设置2048，不应该是这个导致。
（3）之前我TM都是1个slot，netty的server thread默认就是1，后来设置成2，我考虑是
请问下 flink executeAsync() 一般都什么使用场景
无限流情况下executeAsync() / execute()是一样的吧
主要是想问下 场景/区别
