gpt4 book ai didi

java - Kafka KStream - 在窗口中使用 AbstractProcessor

转载 作者:行者123 更新时间:2023-11-29 06:53:42 25 4
gpt4 key购买 nike

我希望将来自 KStream 的窗口化批处理输出组合在一起,并将它们写入辅助存储。

我期待看到 .punctuate() 大约每 30 秒被调用一次。我得到的反而被保存了here .

(原文件几千行)

总结 - .punctuate() 被随机调用,然后被重复调用。它似乎不符合通过 ProcessorContext.schedule() 设置的值.


编辑:

同一代码的另一次运行大约每四分钟产生一次对 .punctuate() 的调用。这次我没有看到疯狂的重复值。源代码没有变化 - 只是结果不同。

使用以下代码:

主要内容

StreamsConfig streamsConfig = new StreamsConfig(config);
KStreamBuilder kStreamBuilder = new KStreamBuilder();
KStream<String, String> lines = kStreamBuilder.stream(TOPIC);

lines.process(new BPS2());

KafkaStreams kafkaStreams = new KafkaStreams(kStreamBuilder, streamsConfig);

kafkaStreams.start();

处理器

public class BP2 extends AbstractProcessor<String, String> {
private static final Logger LOGGER = LoggerFactory.getLogger(BP2.class);

private ProcessorContext context;
private final long delay;
private final ArrayList<String> values;

public BP2(long delay) {
LOGGER.debug("BatchProcessor() constructor");
this.delay = delay;

values = new ArrayList<>();

}

@Override
public void process(String s, String s2) {
LOGGER.debug("batched processor s:{} s2:{}", s, s2);

values.add(s2);
}

@Override
public void init(ProcessorContext context) {
LOGGER.info("init");

super.init(context);

values.clear();

this.context = context;
context.schedule(delay);
}

@Override
public void punctuate(long timestamp) {
super.punctuate(timestamp);

LOGGER.info("punctuate ts: {} count: {}", timestamp, values.size());

context().commit();
}
}

处理器供应商

public class BPS2 implements ProcessorSupplier<String, String> {
private static final Logger LOGGER = LoggerFactory.getLogger(BPS2.class);

@Override
public Processor<String, String> get() {
try {
return new BP2(30000);
} catch(Exception exception) {
LOGGER.error("Unable to instantiate BatchProcessor()", exception);
throw new RuntimeException();
}
}
}

编辑:

为了确保我的调试器不会减慢它的速度,我构建了它并在与我的 kafka 进程相同的机器上运行它。这次它甚至没有尝试延迟 4 分钟或更长时间 - 在几秒钟内它就输出了对 .punctuate() 的虚假调用。其中许多(大多数)没有对 .process() 的干预调用。

最佳答案

更新:这部分答案适用于 Kafka 0.11 或更早版本(Kafka 1.0 及更高版本见下文)

在 Kafka Streams 中,标点符号基于流时间不是系统时间(又名处理时间)。

默认情况下,stream-timeevent-time,即嵌入在 Kafka 记录本身中的时间戳。由于您没有设置非默认的 TimestampExtractor(请参阅 http://docs.confluent.io/current/streams/developer-guide.html#optional-configuration-parameters 中的 timestamp.extractor),对 punctuate 的调用仅取决于与您处理的记录相关的事件时间流程。因此,如果您需要多分钟来处理“30 秒”(事件时间)的记录,punctuate 的调用频率将低于 30 秒(挂钟时间)...

这也可以解释您不规则的调用模式(即突发和长时间延迟)。如果您的数据事件时间确实“跳跃”,并且您要处理的数据已经在您的主题中完全可用,Kafka Streams 也会在内部维护的stream-time 方面“跳跃”。

我假设,您可以使用 WallclockTimestampExtractor 解决您的问题(参见 http://docs.confluent.io/current/streams/developer-guide.html#timestamp-extractor)

还有一件事要提:stream-time 仅在处理数据时才会提前——如果您的应用程序到达输入主题的末尾并等待数据,punctuate 不会被调用。即使您使用 WallclockTimestampExtractor,这也适用。

顺便说一句:目前有一个关于 Streams 的标点符号行为的讨论:https://github.com/apache/kafka/pull/1689

Kafka 1.0 及更高版本的答案

从 Kafka 1.0 开始,可以根据挂钟时间或事件时间注册标点符号:https://kafka.apache.org/10/documentation/streams/developer-guide/processor-api.html#id2

关于java - Kafka KStream - 在窗口中使用 AbstractProcessor,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39251997/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com