双流 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 的延迟重试
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
Hi, what's the type of the input for the SortOperator? I mean what's the
TypeInformation? For example, PojoTypeInfo or RowTypeInfo?
Best regards,
Yuxia
发件人: "Ken Krugler"
收件人: "User"
发送时间: 星期三, 2022年 12 月 07日 上午 9:11:17
主题: Registering serializer for RowData
Hi there,
I’m using the
Hi there,
I’m using the Hudi sink to write data, in bulk insert mode, and running into an
issue where Hudi is unhappy because (I think) Flink is using the Kryo
serializer for RowData records, instead of something that extends
AbstractRowDataSerializer.
It’s this bit of (Hudi) code in
Hi,
There is a ZLIB vulnerability reported by the official National
Vulnerability Database. This vulnerability causes memory corruption while
deflating with ZLIB version less than 1.2.12.
Here is the link for details...
https://nvd.nist.gov/vuln/detail/cve-2018-25032#vulnCurrentDescriptionTitle
One concrete question, under the HA folder I also see these sample entries:
- job_name/blob/job_uuid/blob_...
- job_name/submittedJobGraphX
- job_name/submittedJobGraphY
Is it safe to clean these up when the job is in a healthy state?
Regards,
Alexis.
Am Mo., 5. Dez. 2022 um 20:09 Uhr schrieb
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和内存还有很多剩余。
如题，这个问题长期存在，我想了解几个点：
（1）connection time out
是连接时才会报的错误嘛？作业正常运行期间可能有嘛？我理解是连接时的报错，但是我看部分报错是作业运行不少时间才报错的（比如40分钟，1小时多），这种时刻为什么会有
connect 操作呢？netty的connection不是在作业启动时，就发 partition request 的时候创建好的嘛。
（2）之前调整过 netty 的 server 的 backlog，目前设置2048，不应该是这个导致。
（3）之前我TM都是1个slot，netty的server
Thanks a lot for your input, Gyula!
Best,
Paul Lam
> 2022年12月6日 18:38，Gyula Fóra 写道：
>
> Hi!
>
> The stable state is not marked in the reconciliation state field but instead
> using the last stable spec field. Deployed simply means that something is
> running :)
>
> The structure of the
Hi!
The stable state is not marked in the reconciliation state field but
instead using the last stable spec field. Deployed simply means that
something is running :)
The structure of the status is a bit complex to avoid too much redundancy
and limit the size and is mostly considered to be
|The Apache Flink community is very happy to announce the release of
Apache flink-connector-cassandra 3.0.0. |
|Apache Flink® is an open-source stream processing framework ||for|
|distributed, high-performing, always-available, and accurate data
streaming applications.|
|The release is
请问下 flink executeAsync() 一般都什么使用场景
无限流情况下executeAsync() / execute()是一样的吧
主要是想问下 场景/区别
Hi all,
I’m trying out Flink K8s operator 1.2 with K8s 1.25 and Flink 1.15.
I found kubectl shows that flinkdeployments stay in DEPLOYED like forever (the
Flink job status are RUNNING), but the operator logs shows that the
flinkdeployments already turned into STABLE.
Is that a known bug or
16 matches
Mail list logo
