[英]Different time scaling between timestamps and watermarks
我有一個 stream,其傳感器數據從 now() 開始,每秒發出數據,但它們的時間戳增加了 15 分鍾。 假設現在是 19:00:00,所以我們有
('TH1', '2023-01-17 19:00', 15.559) at 19:00:00
('TH1', '2023-01-17 19:15', 12.008) at 19:00:01
('TH1', '2023-01-17 19:30', 15.706) at 19:00:02
等。因為我知道延遲數據將隨着 x 模擬天數的 BoundedOutOfOrderness 實時到達,也就是 24*(60/15)*x 秒,所以我正在努力實現 WatermarkStrategy 和 TimestampAssigner,因為未來的時間戳。 目標是匯總整個模擬日(即 96 秒)的事件。
到目前為止,我已經嘗試使用TumblingProcessingTimeWindows
觸發聚合器,但我認為使用EventTime
會更好。 BoundedOutOfOrderness
和 TumblingEvent window 的某些組合似乎不起作用。 我是 flink 的新手,我正在嘗試使用 1.6。 據我所知,沒有多少代碼可供我查找,因為這個 Watermark 是新版本的。
以下是我認為可行的代碼
KafkaSource<SensorMessage> consumer = KafkaSource.<SensorMessage>builder()
.setBootstrapServers(parameterTool.get("bootstrap.servers"))
.setTopics(String.format("sensors.%s", topic))
.setGroupId(parameterTool.get("group.id"))
.setValueOnlyDeserializer(new SensorMessageDeserializationSchema()).build();
SingleOutputStreamOperator<SensorMessage> soso = env.fromSource(consumer,
WatermarkStrategy.
<SensorMessage>forBoundedOutOfOrderness(Duration.ofSeconds(3*96)) // 3 days
.withTimestampAssigner(((sensorMessage, l) -> sensorMessage.timestamp)),
topic);
soso.keyBy(s -> s.name)
.window(TumblingEventTimeWindows.of(Time.seconds(96)))// sum 1 day
.sum("value")
.map(s -> s.name + ", " + s.value)
.sinkTo(KafkaSink.<String>builder()
.setBootstrapServers(
parameterTool
.getProperties()
.getProperty("bootstrap.servers"))
.setRecordSerializer(KafkaRecordSerializationSchema.builder()
.setTopic("flink.output")
.setValueSerializationSchema(new SimpleStringSchema())
.build())
.build());
我認為你在這里混合東西。
ProcessingTime
是由系統時鍾測量的時間,因此在您的情況下,1 個模擬日將有 96 秒。
另一方面, EventTime
根本不使用系統時鍾,所有時間流都是根據您收到的事件的timestamp
來衡量的,這意味着即使您在 96 秒內收到一整天的模擬,從事件時間的角度來看,一整天過去了,所以在定義亂序和 window 大小時,您需要從事件時間的角度定義它們,例如您想要 window 大小為 24 小時而不是 96 秒。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.