如果有些map阶段的计算很慢,它发checkpoint也很慢,那么这样会阻塞reduce operator进行后续的操作吗

2020-02-23 Thread Mark Zang
假设一个简单的map和reduce操作。A是Map Operator,B是keyby Operator。 A有两个task:taskA1和taskA2,B只有一个taskB 如果taskA2执行的特别慢,taskA1执行完毕checkpoint cp1后,告诉了taskB,然后已经开始(或者说可以开始)处理下一个checkpoint cp2的数据了。 这时候taskA2还在缓慢的处理cp1的数据。这时候: taskA1会继续处理cp2的数据吗? 如果是继续处理,taskB会处理taskA传递给taskB的cp2的数据吗? 还是taskA1和taskB都停止处理*,*等taskA2?

Re: 如果有些map阶段的计算很慢,它发checkpoint也很慢,那么这样会阻塞reduce operator进行后续的操作吗

2020-02-23 Thread Jark Wu
Hi Mark, > taskA1会继续处理cp2的数据吗?如果是继续处理,taskB会处理taskA传递给taskB的cp2的数据吗? A1会继续处理。如果是 exactly-once 模式,taskB 不会处理 taskA传递给taskB的cp2的数据。所以,如果 A2 非常非常慢,最终 taskB 会反压到 A1,导致 A1也无法继续处理数据。 > 同样的问题,如果taskA本身就是一个reduce操作(keyby),taskB是一个map操作。那么同样的问题,答案是一样的吗? 答案一样。 Best, Jark On Sun, 23 Feb 2020 at 19:18, Mar

Re: timestamp问题

2020-02-23 Thread Jark Wu
Hi Fei, Kafka source/sink 不支持 TIMESTAMP(6) 类型,支持精度3,且现在 TIMESTAMP 不带精度默认是6,所以需要你将 DDL 声明中的 TIMESTAMP 改成 TIMESTAMP(3). Beest, Jark On Sun, 23 Feb 2020 at 15:44, Fei Han wrote: > > Hi,all: >我在zeppelin执行如下DDL和SQL,报如下错误: > DDL: > DROP TABLE IF EXISTS user_log ; > CREATE TABLE user_log ( >

Flink读写kafka数据聚集任务失败问题

2020-02-23 Thread chanamper
大家好,请教一下,flink任务读取kafka数据进行聚集操作后将结果写回kafka,flink版本为1.8.0。任务运行一段时间后出现如下异常,之后flink任务异常挂掉,请问一下这个问题该如何解决呢?多谢 2020-02-19 10:45:45,314 ERROR org.apache.flink.runtime.io.network.netty.PartitionRequestQueue - Encountered error while consuming partitions java.io.IOException: Connection reset by peer