之前的DataStream API 我们可以通过State进行一些复杂的逻辑。比如所有message的某个field的最大值。Flink
SQL有类似的方法吗？
Hi Yingjie,
Thanks for your explanation. I have no more questions. +1
On Tue, Dec 14, 2021 at 3:31 PM Yingjie Cao wrote:
>
> Hi Jingsong,
>
> Thanks for your feedback.
>
> >>> My question is, what is the maximum parallelism a job can have with the
> >>> default configuration? (Does this break o
Hi Jingsong,
Thanks for your feedback.
>>> My question is, what is the maximum parallelism a job can have with the
default configuration? (Does this break out of the box)
Yes, you are right, these two options are related to network memory and
framework off-heap memory. Generally, these changes w
Hi Yingjie,
+1 for this FLIP. I'm pretty sure this will greatly improve the ease
of batch jobs.
Looks like "taskmanager.memory.framework.off-heap.batch-shuffle.size"
and "taskmanager.network.sort-shuffle.min-buffers" are related to
network memory and framework.off-heap.size.
My question is, wha
应该在open中做全量数据的初始化。然后broadcastState做增量的更新。
Caizhi Weng 于2021年12月14日周二 09:50写道：
> Hi！
>
> 可以看一下 event time temporal join [1] 是否满足需求。
>
> [1]
>
> https://nightlies.apache.org/flink/flink-docs-release-1.13/zh/docs/dev/table/sql/queries/joins/#event-time-temporal-join
>
> casel.chen 于2021年12月12日周日 1
Hi Jiangang,
Thanks for your suggestion.
>>> The config can affect the memory usage. Will the related memory configs
be changed?
I think we will not change the default network memory settings. My best
expectation is that the default value can work for most cases (though may
not the best) and for
Hi Yun,
Thanks for your feedback.
I think setting taskmanager.network.sort-shuffle.min-parallelism to 1 and
using sort-shuffle for all cases by default is a good suggestion. I am not
choosing this value mainly because two reasons:
1. The first one is that it increases the usage of network memory
Hi！
可以看一下 event time temporal join [1] 是否满足需求。
[1]
https://nightlies.apache.org/flink/flink-docs-release-1.13/zh/docs/dev/table/sql/queries/joins/#event-time-temporal-join
casel.chen 于2021年12月12日周日 11:12写道：
> 有一个场景是通过一张mysql的控制表来控制kafka流中的元素分流到不同下游sink，例如事实表的kafka和维表hbase等。
> 可我发现BroadcastConn
Hi！
从 Flink 1.13 开始，引入了新的时间类型 timestamp_ltz，对应一个时间点，可以认为是 Java 的
Interval。之间的时间类型 timestamp 可以认为对应一个字符串。具体区别详见 [1]。
现在 current_timestamp 函数会返回 timestamp_ltz，不能直接和 timestamp 类型做运算。
[1]
https://nightlies.apache.org/flink/flink-docs-master/zh/docs/dev/table/timezone/
Pinjie Huang 于2021年12月13日周一 1
您好，目前flinkSQL KafkaConnector目前不支持Source算子并行度配置以及数据分发策略选择：
导致的问题：
1、当并行度 > source中间件消息分区时, 超出的部分会空跑占用资源
2、假设： 并行度>消息分区， source vertex： Source: TableSourceScan->Calc(select…);
当Calc（select..）为cpu密集（json解析）算子，其将会成为任务的性能瓶颈，Calc算子无法享受到扩容带来的资源（超出kafka分区的并发没有数据流入）。
请问下目前社区有没有现有的 / 计划中的解决方案？
您好，目前flinkSQL KafkaConnector目前不支持Source算子并行度配置以及数据分发策略选择：
导致的问题：
1、当并行度 > source中间件消息分区时, 超出的部分会空跑占用资源
2、假设： 并行度>消息分区， source vertex： Source: TableSourceScan->Calc(select…);
当Calc（select..）为cpu密集（json解析）算子，其将会成为任务的性能瓶颈，Calc算子无法享受到扩容带来的资源（超出kafka分区的并发没有数据流入）。
请问下目前社区有没有现有的 / 计划中的解决方案？
您好，目前flinkSQL KafkaConnector目前不支持Source算子并行度配置以及数据分发策略选择：
导致的问题：
1、当并行度 > source中间件消息分区时, 超出的部分会空跑占用资源
2、假设： 并行度>消息分区， source vertex： Source: TableSourceScan->Calc(select…);
当Calc（select..）为cpu密集（json解析）算子，其将会成为任务的性能瓶颈，Calc算子无法享受到扩容带来的资源（超出kafka分区的并发没有数据流入）。
请问下目前社区有没有现有的 / 计划中的解决方案？
13 matches
Mail list logo
