You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-zh@flink.apache.org by 1048262223 <10...@qq.com> on 2020/06/09 09:14:36 UTC
回复：延迟事件处理
Hi
我没有从你的需求场景中理解你是怎样推导出你说的那两种方案可以作为解决方法的，可以详细描述一下整个需求场景吗。
比如你们的整体场景是什么，为什么需要用flink满足你们的需求。
Best,
Yichao Yang
------------------ 原始邮件 ------------------
发件人: "wangxiangyan"<wangxiangyan@dutinn.com>;
发送时间: 2020年6月9日(星期二) 下午5:10
收件人: "user-zh"<user-zh@flink.apache.org>;
主题: 延迟事件处理
hi
在使用中遇到的需求是，按分钟处理数据，数据源是不稳定的，可能会一段时间内下线，比如第二天前一天的数据大量涌入，可能的选择方案有
1.延迟数据处理：将延迟数据采取另外的逻辑处理与外部系统交互，但是允许延迟的状态存储是不是需要调节为一天时间
2.每天晚上定时使用批处理重新计算白天的数据去校正
应该使用哪种方式或者使用更好的方式去处理呢？
回复：延迟事件处理
Posted by 1048262223 <10...@qq.com>.
Hi
我所说的第一种方法是【在一个【处理时间】语义的job中即处理延迟数据也处理正常数据，这里是同时进行的，都是通过和mysql交互，将统计出的指标求和然后更新】
前端页面获取不到最近几分钟的数据这个我不太懂，是说延迟数据量很大导致的？正常数据和延迟数据同时处理时应该不会出现延迟很大的情况？
我所说的【处理时间】只是说job用处理时间运行（为了避免延迟数据丢失），但是更新mysql数据还是可以使用【事件时间】的，这个其实和你使用【事件时间】语义去运行job，更新数据直接用【事件时间】本质都是一样的。
或者你也可以使用【事件时间】，可以使用旁路输出把延迟数据收集，然后去处理也是可以的。
Best,
Yichao Yang
------------------ 原始邮件 ------------------
发件人: "wangxiangyan"<wangxiangyan@dutinn.com>;
发送时间: 2020年6月9日(星期二) 晚上6:02
收件人: "user-zh"<user-zh@flink.apache.org>;
主题: Re:延迟事件处理
1. 指标统计展示是mysql，按照事件时间做窗口的统计，如果按照处理时间，需要找到数据所属的窗口实现外部系统的更新，但在前台页面可能获取不到最近几分钟的统计数据，此时事件时间也同样延迟，语义上不如事件事件解释性强一些
2. 白天运行的时候显示实时的数据，晚上去更正一整天的数据，资源消耗很大，不确定这种延迟的频率，应该也不会常出现吧&nbsp;
还是将延迟数据收集起来，另外启动一个流处理任务不断消费延迟数据，通过和mysql交互，将统计出的指标和之前窗口统计出的指标求和然后更新，这个逻辑似乎比较合理
------------------&nbsp;Original&nbsp;------------------
From: &nbsp;"1048262223"<1048262223@qq.com&gt;;
Date: &nbsp;Tue, Jun 9, 2020 05:40 PM
To: &nbsp;"user-zh"<user-zh@flink.apache.org&gt;;
Subject: &nbsp;回复：延迟事件处理
&nbsp;
Hi
个人经验：【数据延迟】其实是在事件时间语义的基础上的。
1.如果你们的指标统计展示系统是olap或者可更新的数据存储引擎，我建议其实使用【处理时间】也就不存在延迟数据这一种情况了，然后迟到的数据可以根据时间数据中的事件时间戳字段更新到olap或者可更新存储引擎就可以。也就对应到你所说的第一种方法。
2.如果业务可以忍受大概 t - 1 延迟的数据上的误差其实我建议你使用你所说的第二种方法使用离线去更正，因为实时本质上最注重的就是数据的实时性，像这种延迟的数据更适合使用离线的方式处理。
Best,
Yichao Yang
------------------&amp;nbsp;原始邮件&amp;nbsp;------------------
发件人:&amp;nbsp;"wangxiangyan"<wangxiangyan@dutinn.com&amp;gt;;
发送时间:&amp;nbsp;2020年6月9日(星期二) 下午5:26
收件人:&amp;nbsp;"user-zh"<user-zh@flink.apache.org&amp;gt;;
主题:&amp;nbsp;Re:延迟事件处理
这是一个需要实时展示统计指标的系统，数据来源于检测器，检测器安装在客户那边，可能有下线的状态，或者数据延迟到达，不确定下线的时间，某个检测器下线之后在第二天上线会有一批昨天的数据，会发生延迟的数据处理
&amp;amp;nbsp;
&amp;amp;nbsp;
------------------&amp;amp;nbsp;Original&amp;amp;nbsp;------------------
From: &amp;amp;nbsp;"1048262223"<1048262223@qq.com&amp;amp;gt;;
Date: &amp;amp;nbsp;Tue, Jun 9, 2020 05:14 PM
To: &amp;amp;nbsp;"user-zh"<user-zh@flink.apache.org&amp;amp;gt;;
Subject: &amp;amp;nbsp;回复：延迟事件处理
&amp;amp;nbsp;
Hi
我没有从你的需求场景中理解你是怎样推导出你说的那两种方案可以作为解决方法的，可以详细描述一下整个需求场景吗。
比如你们的整体场景是什么，为什么需要用flink满足你们的需求。
Best,
Yichao Yang
------------------&amp;amp;amp;nbsp;原始邮件&amp;amp;amp;nbsp;------------------
发件人:&amp;amp;amp;nbsp;"wangxiangyan"<wangxiangyan@dutinn.com&amp;amp;amp;gt;;
发送时间:&amp;amp;amp;nbsp;2020年6月9日(星期二) 下午5:10
收件人:&amp;amp;amp;nbsp;"user-zh"<user-zh@flink.apache.org&amp;amp;amp;gt;;
主题:&amp;amp;amp;nbsp;延迟事件处理
hi
在使用中遇到的需求是，按分钟处理数据，数据源是不稳定的，可能会一段时间内下线，比如第二天前一天的数据大量涌入，可能的选择方案有
1.延迟数据处理：将延迟数据采取另外的逻辑处理与外部系统交互，但是允许延迟的状态存储是不是需要调节为一天时间
2.每天晚上定时使用批处理重新计算白天的数据去校正
应该使用哪种方式或者使用更好的方式去处理呢？
Re:延迟事件处理
Posted by wangxiangyan <wa...@dutinn.com>.
1. 指标统计展示是mysql，按照事件时间做窗口的统计，如果按照处理时间，需要找到数据所属的窗口实现外部系统的更新，但在前台页面可能获取不到最近几分钟的统计数据，此时事件时间也同样延迟，语义上不如事件事件解释性强一些
2. 白天运行的时候显示实时的数据，晚上去更正一整天的数据，资源消耗很大，不确定这种延迟的频率，应该也不会常出现吧
还是将延迟数据收集起来，另外启动一个流处理任务不断消费延迟数据，通过和mysql交互，将统计出的指标和之前窗口统计出的指标求和然后更新，这个逻辑似乎比较合理
------------------ Original ------------------
From: "1048262223"<1048262223@qq.com>;
Date: Tue, Jun 9, 2020 05:40 PM
To: "user-zh"<user-zh@flink.apache.org>;
Subject: 回复：延迟事件处理
Hi
个人经验：【数据延迟】其实是在事件时间语义的基础上的。
1.如果你们的指标统计展示系统是olap或者可更新的数据存储引擎，我建议其实使用【处理时间】也就不存在延迟数据这一种情况了，然后迟到的数据可以根据时间数据中的事件时间戳字段更新到olap或者可更新存储引擎就可以。也就对应到你所说的第一种方法。
2.如果业务可以忍受大概 t - 1 延迟的数据上的误差其实我建议你使用你所说的第二种方法使用离线去更正，因为实时本质上最注重的就是数据的实时性，像这种延迟的数据更适合使用离线的方式处理。
Best,
Yichao Yang
------------------&nbsp;原始邮件&nbsp;------------------
发件人:&nbsp;"wangxiangyan"<wangxiangyan@dutinn.com&gt;;
发送时间:&nbsp;2020年6月9日(星期二) 下午5:26
收件人:&nbsp;"user-zh"<user-zh@flink.apache.org&gt;;
主题:&nbsp;Re:延迟事件处理
这是一个需要实时展示统计指标的系统，数据来源于检测器，检测器安装在客户那边，可能有下线的状态，或者数据延迟到达，不确定下线的时间，某个检测器下线之后在第二天上线会有一批昨天的数据，会发生延迟的数据处理
&amp;nbsp;
&amp;nbsp;
------------------&amp;nbsp;Original&amp;nbsp;------------------
From: &amp;nbsp;"1048262223"<1048262223@qq.com&amp;gt;;
Date: &amp;nbsp;Tue, Jun 9, 2020 05:14 PM
To: &amp;nbsp;"user-zh"<user-zh@flink.apache.org&amp;gt;;
Subject: &amp;nbsp;回复：延迟事件处理
&amp;nbsp;
Hi
我没有从你的需求场景中理解你是怎样推导出你说的那两种方案可以作为解决方法的，可以详细描述一下整个需求场景吗。
比如你们的整体场景是什么，为什么需要用flink满足你们的需求。
Best,
Yichao Yang
------------------&amp;amp;nbsp;原始邮件&amp;amp;nbsp;------------------
发件人:&amp;amp;nbsp;"wangxiangyan"<wangxiangyan@dutinn.com&amp;amp;gt;;
发送时间:&amp;amp;nbsp;2020年6月9日(星期二) 下午5:10
收件人:&amp;amp;nbsp;"user-zh"<user-zh@flink.apache.org&amp;amp;gt;;
主题:&amp;amp;nbsp;延迟事件处理
hi
在使用中遇到的需求是，按分钟处理数据，数据源是不稳定的，可能会一段时间内下线，比如第二天前一天的数据大量涌入，可能的选择方案有
1.延迟数据处理：将延迟数据采取另外的逻辑处理与外部系统交互，但是允许延迟的状态存储是不是需要调节为一天时间
2.每天晚上定时使用批处理重新计算白天的数据去校正
应该使用哪种方式或者使用更好的方式去处理呢？
回复：延迟事件处理
Posted by 1048262223 <10...@qq.com>.
Hi
个人经验：【数据延迟】其实是在事件时间语义的基础上的。
1.如果你们的指标统计展示系统是olap或者可更新的数据存储引擎，我建议其实使用【处理时间】也就不存在延迟数据这一种情况了，然后迟到的数据可以根据时间数据中的事件时间戳字段更新到olap或者可更新存储引擎就可以。也就对应到你所说的第一种方法。
2.如果业务可以忍受大概 t - 1 延迟的数据上的误差其实我建议你使用你所说的第二种方法使用离线去更正，因为实时本质上最注重的就是数据的实时性，像这种延迟的数据更适合使用离线的方式处理。
Best,
Yichao Yang
------------------ 原始邮件 ------------------
发件人: "wangxiangyan"<wangxiangyan@dutinn.com>;
发送时间: 2020年6月9日(星期二) 下午5:26
收件人: "user-zh"<user-zh@flink.apache.org>;
主题: Re:延迟事件处理
这是一个需要实时展示统计指标的系统，数据来源于检测器，检测器安装在客户那边，可能有下线的状态，或者数据延迟到达，不确定下线的时间，某个检测器下线之后在第二天上线会有一批昨天的数据，会发生延迟的数据处理
&nbsp;
&nbsp;
------------------&nbsp;Original&nbsp;------------------
From: &nbsp;"1048262223"<1048262223@qq.com&gt;;
Date: &nbsp;Tue, Jun 9, 2020 05:14 PM
To: &nbsp;"user-zh"<user-zh@flink.apache.org&gt;;
Subject: &nbsp;回复：延迟事件处理
&nbsp;
Hi
我没有从你的需求场景中理解你是怎样推导出你说的那两种方案可以作为解决方法的，可以详细描述一下整个需求场景吗。
比如你们的整体场景是什么，为什么需要用flink满足你们的需求。
Best,
Yichao Yang
------------------&amp;nbsp;原始邮件&amp;nbsp;------------------
发件人:&amp;nbsp;"wangxiangyan"<wangxiangyan@dutinn.com&amp;gt;;
发送时间:&amp;nbsp;2020年6月9日(星期二) 下午5:10
收件人:&amp;nbsp;"user-zh"<user-zh@flink.apache.org&amp;gt;;
主题:&amp;nbsp;延迟事件处理
hi
在使用中遇到的需求是，按分钟处理数据，数据源是不稳定的，可能会一段时间内下线，比如第二天前一天的数据大量涌入，可能的选择方案有
1.延迟数据处理：将延迟数据采取另外的逻辑处理与外部系统交互，但是允许延迟的状态存储是不是需要调节为一天时间
2.每天晚上定时使用批处理重新计算白天的数据去校正
应该使用哪种方式或者使用更好的方式去处理呢？
Re: Re:延迟事件处理
Posted by "wangweiguang@stevegame.cn" <wa...@stevegame.cn>.
觉得对于下线产生的历史数据，用批处理应该更好一点，可以避免数据量过大造成的问题！
发件人： wangxiangyan
发送时间： 2020-06-09 17:26
收件人： user-zh
主题： Re:延迟事件处理
这是一个需要实时展示统计指标的系统，数据来源于检测器，检测器安装在客户那边，可能有下线的状态，或者数据延迟到达，不确定下线的时间，某个检测器下线之后在第二天上线会有一批昨天的数据，会发生延迟的数据处理
------------------ Original ------------------
From: "1048262223"<1048262223@qq.com>;
Date: Tue, Jun 9, 2020 05:14 PM
To: "user-zh"<user-zh@flink.apache.org>;
Subject: 回复：延迟事件处理
Hi
我没有从你的需求场景中理解你是怎样推导出你说的那两种方案可以作为解决方法的，可以详细描述一下整个需求场景吗。
比如你们的整体场景是什么，为什么需要用flink满足你们的需求。
Best,
Yichao Yang
------------------&nbsp;原始邮件&nbsp;------------------
发件人:&nbsp;"wangxiangyan"<wangxiangyan@dutinn.com&gt;;
发送时间:&nbsp;2020年6月9日(星期二) 下午5:10
收件人:&nbsp;"user-zh"<user-zh@flink.apache.org&gt;;
主题:&nbsp;延迟事件处理
hi
在使用中遇到的需求是，按分钟处理数据，数据源是不稳定的，可能会一段时间内下线，比如第二天前一天的数据大量涌入，可能的选择方案有
1.延迟数据处理：将延迟数据采取另外的逻辑处理与外部系统交互，但是允许延迟的状态存储是不是需要调节为一天时间
2.每天晚上定时使用批处理重新计算白天的数据去校正
应该使用哪种方式或者使用更好的方式去处理呢？
Re:延迟事件处理
Posted by wangxiangyan <wa...@dutinn.com>.
这是一个需要实时展示统计指标的系统，数据来源于检测器，检测器安装在客户那边，可能有下线的状态，或者数据延迟到达，不确定下线的时间，某个检测器下线之后在第二天上线会有一批昨天的数据，会发生延迟的数据处理
------------------ Original ------------------
From: "1048262223"<1048262223@qq.com>;
Date: Tue, Jun 9, 2020 05:14 PM
To: "user-zh"<user-zh@flink.apache.org>;
Subject: 回复：延迟事件处理
Hi
我没有从你的需求场景中理解你是怎样推导出你说的那两种方案可以作为解决方法的，可以详细描述一下整个需求场景吗。
比如你们的整体场景是什么，为什么需要用flink满足你们的需求。
Best,
Yichao Yang
------------------&nbsp;原始邮件&nbsp;------------------
发件人:&nbsp;"wangxiangyan"<wangxiangyan@dutinn.com&gt;;
发送时间:&nbsp;2020年6月9日(星期二) 下午5:10
收件人:&nbsp;"user-zh"<user-zh@flink.apache.org&gt;;
主题:&nbsp;延迟事件处理
hi
在使用中遇到的需求是，按分钟处理数据，数据源是不稳定的，可能会一段时间内下线，比如第二天前一天的数据大量涌入，可能的选择方案有
1.延迟数据处理：将延迟数据采取另外的逻辑处理与外部系统交互，但是允许延迟的状态存储是不是需要调节为一天时间
2.每天晚上定时使用批处理重新计算白天的数据去校正
应该使用哪种方式或者使用更好的方式去处理呢？