那意思是会优先处理已经在增量阶段的表，再处理新增快照阶段的表？顺序反过来的话会有什么影响？如果新增表全量数据比较多会导致其他表增量处理变慢是么？
在 2023-12-20 21:40:05，"Hang Ruan" 写道：
>Hi，casel
>
>这段逻辑应该只有在处理到新增表的时候才会用到。
>CDC 读取数据正常是会在所有SnapshotSplit读取完成后，才会下发BinlogSplit。
>但是如果是在增量阶段重启作业，同时新增加了一些表，就会出现同时有BinlogSplit和SnapshotSplit的情况，此时才会走到这段逻辑。
>
你好,
请发送任意内容的邮件到 user-zh-unsubscr...@flink.apache.org 来取消订阅邮件
Best,
Junrui
jimandlice 于2023年12月21日周四 17:43写道：
> 退订
> | |
> jimandlice
> |
> |
> 邮箱：jimandl...@163.com
> |
Hi,
需要精准控制异常数据的话，就不太推荐flink sql了。
考虑使用DataStream将异常数据用侧流输出[1]，再做补偿。
Best,
Jiabao
[1]
https://nightlies.apache.org/flink/flink-docs-release-1.18/docs/dev/datastream/side_output/
On 2023/12/06 08:45:20 Xuyang wrote:
> Hi,
> 目前flink sql主动收集脏数据的行为。有下面两种可行的办法：
> 1.
Hi, casel.
使用三次lookup join是可以实现的，加上缓存，性能应该不差。
WITH users AS (
SELECT *
FROM (VALUES(1, 'zhangsan'), (2, 'lisi'), (3, 'wangwu')) T (id, name)
)
SELECT orders.id,
u1.name as creator_name,
u2.name as approver_name,
u3.name as deployer_name
FROM (
SELECT *
退订
| |
jimandlice
|
|
邮箱：jimandl...@163.com
|
退订
| |
jimandlice
|
|
邮箱：jimandl...@163.com
|
Hi rania,
Does "pending records" specifically refer to the records that have been read
from the source but have not been processed yet?
If this is the case, FLIP-33[1] introduces some standard metrics for Source,
including "pendingRecords," which can be helpful.
However, not all Sources
