checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？

2019-07-18 Thread 陈冬林 


state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/1e95606a-8f70-4876-ad6f-95e5cc38af86
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/2a012214-734a-4c2b-804b-d96f4f3dddf8
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/31871f64-7034-4323-9a2e-5e387e61b7c4
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/54c12a36-c121-4fa0-be76-7996946b4beb
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/63a22932-4bce-4531-bc65-a74d403efb91
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/64b10d96-8333-4a7e-87d1-8afe24c7d2df
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/66290710-e619-4ccf-90b6-5f09f89354f8
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/_metadata

QA1： chk文件下面的文件个数是跟operator个数并行度有关系吗？我只了解到_metadata文件是用来恢复状态的，那么其他文件代表的是什么意思呢？

QA2: 可以将这些文件合并在一起吗？

Re: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？

2019-07-18 Thread Yun Tang 
Hi

A1: chk-x文件下面的文件个数是跟operator个数并行度是有关系的，主要是operator 
state的文件。对于checkpoint场景，_metadata只是元数据，真实的operator数据都是在其他文件内。

A2: 
不可以将这些文件合并在一起。因为_metadata内主要记录了文件路径，如果合并的话，找不到原始路径会有问题，无法从checkpoint进行restore

祝好
唐云

From: 陈冬林 <874269...@qq.com>
Sent: Thursday, July 18, 2019 15:21
To: user-zh@flink.apache.org 
Subject: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？

[cid:A90251C2-5DED-42D9-AA11-8D9314A2F1B9@360buyAD.local]

state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/1e95606a-8f70-4876-ad6f-95e5cc38af86
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/2a012214-734a-4c2b-804b-d96f4f3dddf8
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/31871f64-7034-4323-9a2e-5e387e61b7c4
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/54c12a36-c121-4fa0-be76-7996946b4beb
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/63a22932-4bce-4531-bc65-a74d403efb91
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/64b10d96-8333-4a7e-87d1-8afe24c7d2df
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/66290710-e619-4ccf-90b6-5f09f89354f8
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/_metadata

QA1： chk文件下面的文件个数是跟operator个数并行度有关系吗？我只了解到_metadata文件是用来恢复状态的，那么其他文件代表的是什么意思呢？

QA2: 可以将这些文件合并在一起吗？

checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？

2019-07-18 Thread 陈冬林 


state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/1e95606a-8f70-4876-ad6f-95e5cc38af86
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/2a012214-734a-4c2b-804b-d96f4f3dddf8
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/31871f64-7034-4323-9a2e-5e387e61b7c4
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/54c12a36-c121-4fa0-be76-7996946b4beb
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/63a22932-4bce-4531-bc65-a74d403efb91
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/64b10d96-8333-4a7e-87d1-8afe24c7d2df
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/66290710-e619-4ccf-90b6-5f09f89354f8
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/_metadata

QA1： chk文件下面的文件个数是跟operator个数并行度有关系吗？我只了解到_metadata文件是用来恢复状态的，那么其他文件代表的是什么意思呢？

QA2: 可以将这些文件合并到_metadata文件里吗？

Fwd: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？

2019-07-18 Thread 陈冬林 
谢谢您的解答，
那些文件的数量是只和operator的并行度相关吗？是不是还有key 的个数等相关？有没有具体的公式呢？我没有在源码里找到这块的逻辑

还有一个最重要的问题，这些文件即然不能合并，state小文件合并指的是那些文件呢？


祝安
Andrew


> 下面是被转发的邮件：
> 
> 发件人: Yun Tang 
> 主题: 回复： checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？
> 日期: 2019年7月18日 GMT+8 下午3:24:57
> 收件人: "user-zh@flink.apache.org" 
> 回复－收件人: user-zh@flink.apache.org
> 
> Hi
> 
> A1: chk-x文件下面的文件个数是跟operator个数并行度是有关系的，主要是operator 
> state的文件。对于checkpoint场景，_metadata只是元数据，真实的operator数据都是在其他文件内。
> 
> A2: 
> 不可以将这些文件合并在一起。因为_metadata内主要记录了文件路径，如果合并的话，找不到原始路径会有问题，无法从checkpoint进行restore
> 
> 祝好
> 唐云
> From: 陈冬林 <874269...@qq.com>
> Sent: Thursday, July 18, 2019 15:21
> To: user-zh@flink.apache.org 
> Subject: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？
>  
> 
> 
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/1e95606a-8f70-4876-ad6f-95e5cc38af86
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/2a012214-734a-4c2b-804b-d96f4f3dddf8
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/31871f64-7034-4323-9a2e-5e387e61b7c4
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/54c12a36-c121-4fa0-be76-7996946b4beb
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/63a22932-4bce-4531-bc65-a74d403efb91
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/64b10d96-8333-4a7e-87d1-8afe24c7d2df
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/66290710-e619-4ccf-90b6-5f09f89354f8
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/_metadata
> 
> QA1： chk文件下面的文件个数是跟operator个数并行度有关系吗？我只了解到_metadata文件是用来恢复状态的，那么其他文件代表的是什么意思呢？
> 
> QA2: 可以将这些文件合并在一起吗？

Re: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？

2019-07-18 Thread Yun Tang 
Hi

源码部分可以参考[1] DefaultOperatorStateBackendSnapshotStrategy 执行完成的时候，每个operator 
state backend 都只会产生至多一个文件。

state小文件合并，你指的应该是FLINK-11937 
吧，这里的所谓合并是每个rocksDB state 
backend创建checkpoint的时候，在一定阈值内，若干sst文件的序列化结果都写到一个文件内。由于keyed 
state体积比较大，每次checkpoint时候，创建的文件数目一般不止一个。


[1] 
https://github.com/apache/flink/blob/1ec34249a0303ae64d049d177057ef9b6c413ab5/flink-runtime/src/main/java/org/apache/flink/runtime/state/DefaultOperatorStateBackendSnapshotStrategy.java#L179

祝好
唐云



From: 陈冬林 <874269...@qq.com>
Sent: Thursday, July 18, 2019 15:34
To: user-zh@flink.apache.org 
Subject: Fwd: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？

谢谢您的解答，
那些文件的数量是只和operator的并行度相关吗？是不是还有key 的个数等相关？有没有具体的公式呢？我没有在源码里找到这块的逻辑

还有一个最重要的问题，这些文件即然不能合并，state小文件合并指的是那些文件呢？


祝安
Andrew


> 下面是被转发的邮件：
>
> 发件人: Yun Tang 
> 主题: 回复： checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？
> 日期: 2019年7月18日 GMT+8 下午3:24:57
> 收件人: "user-zh@flink.apache.org" 
> 回复－收件人: user-zh@flink.apache.org
>
> Hi
>
> A1: chk-x文件下面的文件个数是跟operator个数并行度是有关系的，主要是operator 
> state的文件。对于checkpoint场景，_metadata只是元数据，真实的operator数据都是在其他文件内。
>
> A2: 
> 不可以将这些文件合并在一起。因为_metadata内主要记录了文件路径，如果合并的话，找不到原始路径会有问题，无法从checkpoint进行restore
>
> 祝好
> 唐云
> From: 陈冬林 <874269...@qq.com>
> Sent: Thursday, July 18, 2019 15:21
> To: user-zh@flink.apache.org 
> Subject: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？
>
>
>
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/1e95606a-8f70-4876-ad6f-95e5cc38af86
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/2a012214-734a-4c2b-804b-d96f4f3dddf8
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/31871f64-7034-4323-9a2e-5e387e61b7c4
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/54c12a36-c121-4fa0-be76-7996946b4beb
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/63a22932-4bce-4531-bc65-a74d403efb91
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/64b10d96-8333-4a7e-87d1-8afe24c7d2df
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/66290710-e619-4ccf-90b6-5f09f89354f8
> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/_metadata
>
> QA1： chk文件下面的文件个数是跟operator个数并行度有关系吗？我只了解到_metadata文件是用来恢复状态的，那么其他文件代表的是什么意思呢？
>
> QA2: 可以将这些文件合并在一起吗？

Fwd: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？

2019-07-18 Thread 陈冬林 

好的，非常感谢您的解答。






> 下面是被转发的邮件：
> 
> 发件人: Yun Tang 
> 主题: 回复： checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？
> 日期: 2019年7月18日 GMT+8 下午4:06:59
> 收件人: "user-zh@flink.apache.org" 
> 回复－收件人: user-zh@flink.apache.org
> 
> Hi
> 
> 源码部分可以参考[1] DefaultOperatorStateBackendSnapshotStrategy 执行完成的时候，每个operator 
> state backend 都只会产生至多一个文件。
> 
> state小文件合并，你指的应该是FLINK-11937
>  吧，这里的所谓合并是每个rocksDB state 
> backend创建checkpoint的时候，在一定阈值内，若干sst文件的序列化结果都写到一个文件内。由于keyed 
> state体积比较大，每次checkpoint时候，创建的文件数目一般不止一个。
> 
> 
> [1] 
> https://github.com/apache/flink/blob/1ec34249a0303ae64d049d177057ef9b6c413ab5/flink-runtime/src/main/java/org/apache/flink/runtime/state/DefaultOperatorStateBackendSnapshotStrategy.java#L179
> 
> 祝好
> 唐云
> 
> 
> 
> From: 陈冬林 <874269...@qq.com>
> Sent: Thursday, July 18, 2019 15:34
> To: user-zh@flink.apache.org 
> Subject: Fwd: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？
> 
> 谢谢您的解答，
>那些文件的数量是只和operator的并行度相关吗？是不是还有key 的个数等相关？有没有具体的公式呢？我没有在源码里找到这块的逻辑
> 
>还有一个最重要的问题，这些文件即然不能合并，state小文件合并指的是那些文件呢？
> 
> 
> 祝安
> Andrew
> 
> 
>> 下面是被转发的邮件：
>> 
>> 发件人: Yun Tang 
>> 主题: 回复： checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？
>> 日期: 2019年7月18日 GMT+8 下午3:24:57
>> 收件人: "user-zh@flink.apache.org" 
>> 回复－收件人: user-zh@flink.apache.org
>> 
>> Hi
>> 
>> A1: chk-x文件下面的文件个数是跟operator个数并行度是有关系的，主要是operator 
>> state的文件。对于checkpoint场景，_metadata只是元数据，真实的operator数据都是在其他文件内。
>> 
>> A2: 
>> 不可以将这些文件合并在一起。因为_metadata内主要记录了文件路径，如果合并的话，找不到原始路径会有问题，无法从checkpoint进行restore
>> 
>> 祝好
>> 唐云
>> From: 陈冬林 <874269...@qq.com>
>> Sent: Thursday, July 18, 2019 15:21
>> To: user-zh@flink.apache.org 
>> Subject: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？
>> 
>> 
>> 
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/1e95606a-8f70-4876-ad6f-95e5cc38af86
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/2a012214-734a-4c2b-804b-d96f4f3dddf8
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/31871f64-7034-4323-9a2e-5e387e61b7c4
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/54c12a36-c121-4fa0-be76-7996946b4beb
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/63a22932-4bce-4531-bc65-a74d403efb91
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/64b10d96-8333-4a7e-87d1-8afe24c7d2df
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/66290710-e619-4ccf-90b6-5f09f89354f8
>> state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/_metadata
>> 
>> QA1： 
>> chk文件下面的文件个数是跟operator个数并行度有关系吗？我只了解到_metadata文件是用来恢复状态的，那么其他文件代表的是什么意思呢？
>> 
>> QA2: 可以将这些文件合并在一起吗？
>

Re: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？

2019-07-18 Thread Yun Tang 
hi

首先先要确定是否是大量创造文件导致你的namenode 
RPC相应堆积多，RPC请求有很多种，例如每个task创建checkpoint目录也是会向namenode发送大量RPC请求的（参见 
[https://issues.apache.org/jira/browse/FLINK-11696]）；也有可能是你的checkpoint 
interval太小，导致文件不断被创建和删除（subsume old checkpoint），先找到NN压力大的root cause吧。

至于使用FsStateBackend能否减少checkpoint文件数量，这是另外一个话题。首先，我需要弄清楚你目前使用的是什么state 
backend，如果目前是MemoryStateBackend，由于该state backend对应的keyed state 
backend并不会在checkpoint时候创建任何文件，反而在文件数目上来看是对NN压力最小的（相比于FsStateBackend来说要更好）。还有你作业的并发度是多少，每个checkpoint目录下的文件数目又是多少。降低并发度是一种减少文件数目的办法。当然，我觉得如果你只是使用MemoryStateBackend就足够handle
 checkpoint size的话，不应该会触及文件数目太多的问题，除非你的checkpoint间隔实在太小了。

祝好
唐云

From: 陈冬林 <874269...@qq.com>
Sent: Thursday, July 18, 2019 17:49
To: user-zh@flink.apache.org 
Cc: myas...@live.com 
Subject: Fwd: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？


唐云老师您好；
基于hdfs的backend 可以优化checkpoint小文件的数量吗？减少namenode压力吗？
现状是会影响namenode rpc响应设计  gc频繁，内存占用过高。

下面是被转发的邮件：

发件人: 陈冬林 <874269...@qq.com>
主题: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？
日期: 2019年7月18日 GMT+8 下午3:21:12
收件人: user-zh@flink.apache.org

[cid:A90251C2-5DED-42D9-AA11-8D9314A2F1B9@360buyAD.local]

state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/1e95606a-8f70-4876-ad6f-95e5cc38af86
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/2a012214-734a-4c2b-804b-d96f4f3dddf8
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/31871f64-7034-4323-9a2e-5e387e61b7c4
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/54c12a36-c121-4fa0-be76-7996946b4beb
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/63a22932-4bce-4531-bc65-a74d403efb91
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/64b10d96-8333-4a7e-87d1-8afe24c7d2df
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/66290710-e619-4ccf-90b6-5f09f89354f8
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/_metadata

QA1： chk文件下面的文件个数是跟operator个数并行度有关系吗？我只了解到_metadata文件是用来恢复状态的，那么其他文件代表的是什么意思呢？

QA2: 可以将这些文件合并在一起吗？

请问这些名词，在翻译 Glossary 时，有必要翻译成中文吗？

2019-07-18 Thread highfei2011 
Hi 各位,
  晚上好！
  以下名词在翻译 Glossary 章节时，有必要翻译成中文吗？名词列表如下：


 
Flink Application Cluster


Flink Cluster


Event


ExecutionGraph


Function


Instance


Flink Job


JobGraph


Flink JobManager


Logical Graph


Managed State


Flink Master


Operator


Operator Chain


Partition


Physical Graph


Record


Flink Session Cluster


State Backend


Sub-Task


Task


Flink TaskManager


Transformation




祝好！

Re: 请问这些名词，在翻译 Glossary 时，有必要翻译成中文吗？

2019-07-18 Thread Zili Chen 
没有可援引的通译出处建议专有名词不要翻译。Glossary 的解释部分可以解释得详尽一点，上面像 record task
这些有比较普遍共识的还有商讨空间，像 transformation "operator chain"
强行翻译很可能是懂的人本来就看得懂，不懂的人看了还是不懂。现在不翻译在有通译之后可以改，先根据个人喜好翻译了以后就不好改了。

一点拙见。


Best,
tison.


highfei2011  于2019年7月18日周四 下午11:35写道：

> Hi 各位,
>   晚上好！
>   以下名词在翻译 Glossary 章节时，有必要翻译成中文吗？名词列表如下：
>
>
>
> Flink Application Cluster
>
>
> Flink Cluster
>
>
> Event
>
>
> ExecutionGraph
>
>
> Function
>
>
> Instance
>
>
> Flink Job
>
>
> JobGraph
>
>
> Flink JobManager
>
>
> Logical Graph
>
>
> Managed State
>
>
> Flink Master
>
>
> Operator
>
>
> Operator Chain
>
>
> Partition
>
>
> Physical Graph
>
>
> Record
>
>
> Flink Session Cluster
>
>
> State Backend
>
>
> Sub-Task
>
>
> Task
>
>
> Flink TaskManager
>
>
> Transformation
>
>
>
>
> 祝好！

Re:请问这些名词，在翻译 Glossary 时，有必要翻译成中文吗？

2019-07-18 Thread highfei2011 
Hi，Zili Chen:
早上好，你讲的没错，谢谢。另外我发现，Glossary 英文文档中没有 Slot 和 Parallelism 
的说明，建议添加。这样可以方便初学者和用户的学习和使用！


祝好




 Original Message 
Subject: Re: 请问这些名词，在翻译 Glossary 时，有必要翻译成中文吗？
From: Zili Chen 
To: user-zh@flink.apache.org
CC: 


没有可援引的通译出处建议专有名词不要翻译。Glossary 的解释部分可以解释得详尽一点，上面像 record task
这些有比较普遍共识的还有商讨空间，像 transformation "operator chain"
强行翻译很可能是懂的人本来就看得懂，不懂的人看了还是不懂。现在不翻译在有通译之后可以改，先根据个人喜好翻译了以后就不好改了。

一点拙见。


Best,
tison.


highfei2011 highfei2...@126.com 于2019年7月18日周四 下午11:35写道：

 Hi 各位,
 晚上好！
 以下名词在翻译 Glossary 章节时，有必要翻译成中文吗？名词列表如下：



 Flink Application Cluster


 Flink Cluster


 Event


 ExecutionGraph


 Function


 Instance


 Flink Job


 JobGraph


 Flink JobManager


 Logical Graph


 Managed State


 Flink Master


 Operator


 Operator Chain


 Partition


 Physical Graph


 Record


 Flink Session Cluster


 State Backend


 Sub-Task


 Task


 Flink TaskManager


 Transformation




 祝好！

Re: 请问这些名词，在翻译 Glossary 时，有必要翻译成中文吗？

2019-07-18 Thread Zili Chen 
Hi,

欢迎有 PR 后同步到这个 thread 上 :-)

Best,
tison.


highfei2011  于2019年7月19日周五 上午8:34写道：

> Hi，Zili Chen:
> 早上好，你讲的没错，谢谢。另外我发现，Glossary 英文文档中没有 Slot 和 Parallelism
> 的说明，建议添加。这样可以方便初学者和用户的学习和使用！
>
> 祝好
>
>
>
>  Original Message 
> Subject: Re: 请问这些名词，在翻译 Glossary 时，有必要翻译成中文吗？
> From: Zili Chen
> To: user-zh@flink.apache.org
> CC:
>
> 没有可援引的通译出处建议专有名词不要翻译。Glossary 的解释部分可以解释得详尽一点，上面像 record task
> 这些有比较普遍共识的还有商讨空间，像 transformation "operator chain"
> 强行翻译很可能是懂的人本来就看得懂，不懂的人看了还是不懂。现在不翻译在有通译之后可以改，先根据个人喜好翻译了以后就不好改了。
>
> 一点拙见。
>
>
> Best,
> tison.
>
>
> highfei2011  于2019年7月18日周四 下午11:35写道：
>
> > Hi 各位,
> >   晚上好！
> >   以下名词在翻译 Glossary 章节时，有必要翻译成中文吗？名词列表如下：
> >
> >
> >
> > Flink Application Cluster
> >
> >
> > Flink Cluster
> >
> >
> > Event
> >
> >
> > ExecutionGraph
> >
> >
> > Function
> >
> >
> > Instance
> >
> >
> > Flink Job
> >
> >
> > JobGraph
> >
> >
> > Flink JobManager
> >
> >
> > Logical Graph
> >
> >
> > Managed State
> >
> >
> > Flink Master
> >
> >
> > Operator
> >
> >
> > Operator Chain
> >
> >
> > Partition
> >
> >
> > Physical Graph
> >
> >
> > Record
> >
> >
> > Flink Session Cluster
> >
> >
> > State Backend
> >
> >
> > Sub-Task
> >
> >
> > Task
> >
> >
> > Flink TaskManager
> >
> >
> > Transformation
> >
> >
> >
> >
> > 祝好！
>
>

Flink 的 log 文件夹下产生了 44G 日志

2019-07-18 Thread Henry 
 大家好，之前那个报错图片大家没看到，重新弄一下。
报错图片链接：
https://img-blog.csdnimg.cn/20190719092540880.png
https://img-blog.csdnimg.cn/20190719092848500.png


我看报错的原因是，我这里Source用的是ActiveMQ，从昨天早上9点开始运行Flink任务接收消息，到今天早上8点都很正常。然后在今天早上8点4分的时候开始猛报错flink往log文件夹下写日志。第二个图是报错开始，显示ActiveMQ好像超时，然后就是消费者关闭一直猛写log。
 我想问一下有没有什么办法设置flink不让他一直写log，这样感觉没办法测试运行啊，只要一报错就一直写日志，把服务器磁盘都干满了直接崩溃了。求助。

Re: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？

2019-07-18 Thread Yun Tang 
Hi

[https://issues.apache.org/jira/browse/FLINK-11696] 
里面目前的PR是我们的生产代码，你可以用。但是你现在的问题的root 
cause不是这个，而是创建文件和删除文件的请求太多了。可以统计一下目前你们几百个作业的checkpoint 
interval，一般而言3~5min的间隔就完全足够了，没必要将interval调整得太小，这是一个影响你们整个集群使用的配置，必要时需要告知用户正确的配置。

如果你们使用FsStateBackend，在目前的Flink场景下，已经是创建文件数目最优的选项了。剩下能做的优化就是降低不必要的并发度还有就是调大 
state.backend.fs.memory-threshold 
参数（默认值是1KB，最大值是1MB），但是这个参数会有一个副作用，可能需要同时调大jobmanager的heap大小。

祝好
唐云

From: 陈冬林 <874269...@qq.com>
Sent: Friday, July 19, 2019 9:45
To: user-zh@flink.apache.org 
Subject: Re: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？


[cid:D24EB2D4-FA6B-41BD-A6B5-265B7E0C259E@360buyAD.local]

您好！
我觉得您分析的很有道理，集群 createFile和deleteFile 调用请求是最多的。

我们的小集群上跑了近百个flink任务，使用FsStateBackend 存储到hdfs上。checkpoint interval不是我们能决定的。
有没有其他方面可以减少namenode的压力，我看了您github上的代码，是个很不错的优化点，可以考虑实践一下，请问线上验证过吗，我稍后再学习一下您的代码？

至于使用FsStateBackend能否减少checkpoint文件数量，这是另外一个话题

请问这个话题有没有什么优化点可以启发一下吗？




在 2019年7月18日，下午9:34，Yun Tang mailto:myas...@live.com>> 写道：

hi

首先先要确定是否是大量创造文件导致你的namenode 
RPC相应堆积多，RPC请求有很多种，例如每个task创建checkpoint目录也是会向namenode发送大量RPC请求的（参见 
[https://issues.apache.org/jira/browse/FLINK-11696]）；也有可能是你的checkpoint 
interval太小，导致文件不断被创建和删除（subsume old checkpoint），先找到NN压力大的root cause吧。

至于使用FsStateBackend能否减少checkpoint文件数量，这是另外一个话题。首先，我需要弄清楚你目前使用的是什么state 
backend，如果目前是MemoryStateBackend，由于该state backend对应的keyed state 
backend并不会在checkpoint时候创建任何文件，反而在文件数目上来看是对NN压力最小的（相比于FsStateBackend来说要更好）。还有你作业的并发度是多少，每个checkpoint目录下的文件数目又是多少。降低并发度是一种减少文件数目的办法。当然，我觉得如果你只是使用MemoryStateBackend就足够handle
 checkpoint size的话，不应该会触及文件数目太多的问题，除非你的checkpoint间隔实在太小了。

祝好
唐云

From: 陈冬林 <874269...@qq.com>
Sent: Thursday, July 18, 2019 17:49
To: user-zh@flink.apache.org 
mailto:user-zh@flink.apache.org>>
Cc: myas...@live.com 
mailto:myas...@live.com>>
Subject: Fwd: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？


唐云老师您好；
基于hdfs的backend 可以优化checkpoint小文件的数量吗？减少namenode压力吗？
现状是会影响namenode rpc响应设计  gc频繁，内存占用过高。

下面是被转发的邮件：

发件人: 陈冬林 <874269...@qq.com>
主题: checkpoint 文件夹Chk-no 下面文件个数是能计算出来的吗？
日期: 2019年7月18日 GMT+8 下午3:21:12
收件人: user-zh@flink.apache.org

[cid:A90251C2-5DED-42D9-AA11-8D9314A2F1B9@360buyAD.local]

state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/1e95606a-8f70-4876-ad6f-95e5cc38af86
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/2a012214-734a-4c2b-804b-d96f4f3dddf8
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/31871f64-7034-4323-9a2e-5e387e61b7c4
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/54c12a36-c121-4fa0-be76-7996946b4beb
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/63a22932-4bce-4531-bc65-a74d403efb91
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/64b10d96-8333-4a7e-87d1-8afe24c7d2df
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/66290710-e619-4ccf-90b6-5f09f89354f8
state_checkpoints_dir/2d93ffacbddcf363b960317816566552/chk-2903/_metadata

QA1： chk文件下面的文件个数是跟operator个数并行度有关系吗？我只了解到_metadata文件是用来恢复状态的，那么其他文件代表的是什么意思呢？

QA2: 可以将这些文件合并在一起吗？

Re: Flink 的 log 文件夹下产生了 44G 日志

2019-07-18 Thread Caizhi Weng 
Hi Henry,

这个 source 看起来不像是 Flink 提供的 source，应该是 source 本身实现的问题。你可能需要修改 source
的源码让它出错后关闭或者进行其它处理...

Henry  于2019年7月19日周五 上午9:31写道：

>  大家好，之前那个报错图片大家没看到，重新弄一下。
> 报错图片链接：
> https://img-blog.csdnimg.cn/20190719092540880.png
> https://img-blog.csdnimg.cn/20190719092848500.png
>
>
> 我看报错的原因是，我这里Source用的是ActiveMQ，从昨天早上9点开始运行Flink任务接收消息，到今天早上8点都很正常。然后在今天早上8点4分的时候开始猛报错flink往log文件夹下写日志。第二个图是报错开始，显示ActiveMQ好像超时，然后就是消费者关闭一直猛写log。
> 我想问一下有没有什么办法设置flink不让他一直写log，这样感觉没办法测试运行啊，只要一报错就一直写日志，把服务器磁盘都干满了直接崩溃了。求助。

Re: 请问这些名词，在翻译 Glossary 时，有必要翻译成中文吗？

2019-07-18 Thread Jark Wu 
Hi highfei,

Thanks for bringing up this discussion. I would suggest to move the
discussion to the Glossary translation JIRA FLINK-13037
.


Thanks,
Jark




On Fri, 19 Jul 2019 at 09:00, Zili Chen  wrote:

> Hi,
>
> 欢迎有 PR 后同步到这个 thread 上 :-)
>
> Best,
> tison.
>
>
> highfei2011  于2019年7月19日周五 上午8:34写道：
>
> > Hi，Zili Chen:
> > 早上好，你讲的没错，谢谢。另外我发现，Glossary 英文文档中没有 Slot 和 Parallelism
> > 的说明，建议添加。这样可以方便初学者和用户的学习和使用！
> >
> > 祝好
> >
> >
> >
> >  Original Message 
> > Subject: Re: 请问这些名词，在翻译 Glossary 时，有必要翻译成中文吗？
> > From: Zili Chen
> > To: user-zh@flink.apache.org
> > CC:
> >
> > 没有可援引的通译出处建议专有名词不要翻译。Glossary 的解释部分可以解释得详尽一点，上面像 record task
> > 这些有比较普遍共识的还有商讨空间，像 transformation "operator chain"
> > 强行翻译很可能是懂的人本来就看得懂，不懂的人看了还是不懂。现在不翻译在有通译之后可以改，先根据个人喜好翻译了以后就不好改了。
> >
> > 一点拙见。
> >
> >
> > Best,
> > tison.
> >
> >
> > highfei2011  于2019年7月18日周四 下午11:35写道：
> >
> > > Hi 各位,
> > >   晚上好！
> > >   以下名词在翻译 Glossary 章节时，有必要翻译成中文吗？名词列表如下：
> > >
> > >
> > >
> > > Flink Application Cluster
> > >
> > >
> > > Flink Cluster
> > >
> > >
> > > Event
> > >
> > >
> > > ExecutionGraph
> > >
> > >
> > > Function
> > >
> > >
> > > Instance
> > >
> > >
> > > Flink Job
> > >
> > >
> > > JobGraph
> > >
> > >
> > > Flink JobManager
> > >
> > >
> > > Logical Graph
> > >
> > >
> > > Managed State
> > >
> > >
> > > Flink Master
> > >
> > >
> > > Operator
> > >
> > >
> > > Operator Chain
> > >
> > >
> > > Partition
> > >
> > >
> > > Physical Graph
> > >
> > >
> > > Record
> > >
> > >
> > > Flink Session Cluster
> > >
> > >
> > > State Backend
> > >
> > >
> > > Sub-Task
> > >
> > >
> > > Task
> > >
> > >
> > > Flink TaskManager
> > >
> > >
> > > Transformation
> > >
> > >
> > >
> > >
> > > 祝好！
> >
> >
>

Re: 请问这些名词，在翻译 Glossary 时，有必要翻译成中文吗？

2019-07-18 Thread Jark Wu 
Hi,

Just find the Glossary translation PR is created [1]. Let's move the
discussion there.

[1]. https://github.com/apache/flink/pull/9173

On Fri, 19 Jul 2019 at 11:22, Jark Wu  wrote:

> Hi highfei,
>
> Thanks for bringing up this discussion. I would suggest to move the
> discussion to the Glossary translation JIRA FLINK-13037
> .
>
>
> Thanks,
> Jark
>
>
>
>
> On Fri, 19 Jul 2019 at 09:00, Zili Chen  wrote:
>
>> Hi,
>>
>> 欢迎有 PR 后同步到这个 thread 上 :-)
>>
>> Best,
>> tison.
>>
>>
>> highfei2011  于2019年7月19日周五 上午8:34写道：
>>
>> > Hi，Zili Chen:
>> > 早上好，你讲的没错，谢谢。另外我发现，Glossary 英文文档中没有 Slot 和 Parallelism
>> > 的说明，建议添加。这样可以方便初学者和用户的学习和使用！
>> >
>> > 祝好
>> >
>> >
>> >
>> >  Original Message 
>> > Subject: Re: 请问这些名词，在翻译 Glossary 时，有必要翻译成中文吗？
>> > From: Zili Chen
>> > To: user-zh@flink.apache.org
>> > CC:
>> >
>> > 没有可援引的通译出处建议专有名词不要翻译。Glossary 的解释部分可以解释得详尽一点，上面像 record task
>> > 这些有比较普遍共识的还有商讨空间，像 transformation "operator chain"
>> > 强行翻译很可能是懂的人本来就看得懂，不懂的人看了还是不懂。现在不翻译在有通译之后可以改，先根据个人喜好翻译了以后就不好改了。
>> >
>> > 一点拙见。
>> >
>> >
>> > Best,
>> > tison.
>> >
>> >
>> > highfei2011  于2019年7月18日周四 下午11:35写道：
>> >
>> > > Hi 各位,
>> > >   晚上好！
>> > >   以下名词在翻译 Glossary 章节时，有必要翻译成中文吗？名词列表如下：
>> > >
>> > >
>> > >
>> > > Flink Application Cluster
>> > >
>> > >
>> > > Flink Cluster
>> > >
>> > >
>> > > Event
>> > >
>> > >
>> > > ExecutionGraph
>> > >
>> > >
>> > > Function
>> > >
>> > >
>> > > Instance
>> > >
>> > >
>> > > Flink Job
>> > >
>> > >
>> > > JobGraph
>> > >
>> > >
>> > > Flink JobManager
>> > >
>> > >
>> > > Logical Graph
>> > >
>> > >
>> > > Managed State
>> > >
>> > >
>> > > Flink Master
>> > >
>> > >
>> > > Operator
>> > >
>> > >
>> > > Operator Chain
>> > >
>> > >
>> > > Partition
>> > >
>> > >
>> > > Physical Graph
>> > >
>> > >
>> > > Record
>> > >
>> > >
>> > > Flink Session Cluster
>> > >
>> > >
>> > > State Backend
>> > >
>> > >
>> > > Sub-Task
>> > >
>> > >
>> > > Task
>> > >
>> > >
>> > > Flink TaskManager
>> > >
>> > >
>> > > Transformation
>> > >
>> > >
>> > >
>> > >
>> > > 祝好！
>> >
>> >
>>
>

could rest api : /jobs/:jobid/yarn-cancel trigger the savepoint?

2019-07-18 Thread LakeShen 
Hi community, I have a question is that could  rest api :
/jobs/:jobid/yarn-cancel trigger the savepoint? I saw the fink src code,
and I find it didn't trigger the savepoint, is it right?
Thank you to reply .

Re:Re: 请问这些名词，在翻译 Glossary 时，有必要翻译成中文吗？

2019-07-18 Thread 杨继飞 
Hi,
   Jark Wu ,Thanks  I am discussing  in there  .




在 2019-07-19 11:22:53，"Jark Wu"  写道：
>Hi,
>
>Just find the Glossary translation PR is created [1]. Let's move the
>discussion there.
>
>[1]. https://github.com/apache/flink/pull/9173
>
>On Fri, 19 Jul 2019 at 11:22, Jark Wu  wrote:
>
>> Hi highfei,
>>
>> Thanks for bringing up this discussion. I would suggest to move the
>> discussion to the Glossary translation JIRA FLINK-13037
>> .
>>
>>
>> Thanks,
>> Jark
>>
>>
>>
>>
>> On Fri, 19 Jul 2019 at 09:00, Zili Chen  wrote:
>>
>>> Hi,
>>>
>>> 欢迎有 PR 后同步到这个 thread 上 :-)
>>>
>>> Best,
>>> tison.
>>>
>>>
>>> highfei2011  于2019年7月19日周五 上午8:34写道：
>>>
>>> > Hi，Zili Chen:
>>> > 早上好，你讲的没错，谢谢。另外我发现，Glossary 英文文档中没有 Slot 和 Parallelism
>>> > 的说明，建议添加。这样可以方便初学者和用户的学习和使用！
>>> >
>>> > 祝好
>>> >
>>> >
>>> >
>>> >  Original Message 
>>> > Subject: Re: 请问这些名词，在翻译 Glossary 时，有必要翻译成中文吗？
>>> > From: Zili Chen
>>> > To: user-zh@flink.apache.org
>>> > CC:
>>> >
>>> > 没有可援引的通译出处建议专有名词不要翻译。Glossary 的解释部分可以解释得详尽一点，上面像 record task
>>> > 这些有比较普遍共识的还有商讨空间，像 transformation "operator chain"
>>> > 强行翻译很可能是懂的人本来就看得懂，不懂的人看了还是不懂。现在不翻译在有通译之后可以改，先根据个人喜好翻译了以后就不好改了。
>>> >
>>> > 一点拙见。
>>> >
>>> >
>>> > Best,
>>> > tison.
>>> >
>>> >
>>> > highfei2011  于2019年7月18日周四 下午11:35写道：
>>> >
>>> > > Hi 各位,
>>> > >   晚上好！
>>> > >   以下名词在翻译 Glossary 章节时，有必要翻译成中文吗？名词列表如下：
>>> > >
>>> > >
>>> > >
>>> > > Flink Application Cluster
>>> > >
>>> > >
>>> > > Flink Cluster
>>> > >
>>> > >
>>> > > Event
>>> > >
>>> > >
>>> > > ExecutionGraph
>>> > >
>>> > >
>>> > > Function
>>> > >
>>> > >
>>> > > Instance
>>> > >
>>> > >
>>> > > Flink Job
>>> > >
>>> > >
>>> > > JobGraph
>>> > >
>>> > >
>>> > > Flink JobManager
>>> > >
>>> > >
>>> > > Logical Graph
>>> > >
>>> > >
>>> > > Managed State
>>> > >
>>> > >
>>> > > Flink Master
>>> > >
>>> > >
>>> > > Operator
>>> > >
>>> > >
>>> > > Operator Chain
>>> > >
>>> > >
>>> > > Partition
>>> > >
>>> > >
>>> > > Physical Graph
>>> > >
>>> > >
>>> > > Record
>>> > >
>>> > >
>>> > > Flink Session Cluster
>>> > >
>>> > >
>>> > > State Backend
>>> > >
>>> > >
>>> > > Sub-Task
>>> > >
>>> > >
>>> > > Task
>>> > >
>>> > >
>>> > > Flink TaskManager
>>> > >
>>> > >
>>> > > Transformation
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > 祝好！
>>> >
>>> >
>>>
>>

多滑动窗口问题

2019-07-18 Thread 刘晨 
您好:
 请问, 在进行流计算时, source相同, 处理逻辑相同, 但要计算不同的滑动时间窗口, 
 比如 每分钟统计最近 5m,15m,30m 以及 每15分钟计算, 1h, 3h , 12h的数据 
 除去每种窗口写一个程序外, 有其他更加便捷的解决方式吗 ? 


  谢谢

多滑动窗口问题

2019-07-18 Thread aegean0...@163.com 
您好:
 请问, 在进行流计算时, source相同, 处理逻辑相同, 但要计算不同的滑动时间窗口, 
 比如 每分钟统计最近 5m,15m,30m 以及 每15分钟计算, 1h, 3h , 12h的数据 
 除去每种窗口写一个程序外, 有其他更加便捷的解决方式吗 ? 


  谢谢

Re:Re: Flink 的 log 文件夹下产生了 44G 日志

2019-07-18 Thread Henry 


你好，谢谢！是的，这个Source是用JMS实现的自定义Source。目前还在查原因，但是怎么能够让Flink不这样爆炸写log日志呢？20分钟就能写满磁盘，写了40G多。





在 2019-07-19 11:11:37，"Caizhi Weng"  写道：
>Hi Henry,
>
>这个 source 看起来不像是 Flink 提供的 source，应该是 source 本身实现的问题。你可能需要修改 source
>的源码让它出错后关闭或者进行其它处理...
>
>Henry  于2019年7月19日周五 上午9:31写道：
>
>>  大家好，之前那个报错图片大家没看到，重新弄一下。
>> 报错图片链接：
>> https://img-blog.csdnimg.cn/20190719092540880.png
>> https://img-blog.csdnimg.cn/20190719092848500.png
>>
>>
>> 我看报错的原因是，我这里Source用的是ActiveMQ，从昨天早上9点开始运行Flink任务接收消息，到今天早上8点都很正常。然后在今天早上8点4分的时候开始猛报错flink往log文件夹下写日志。第二个图是报错开始，显示ActiveMQ好像超时，然后就是消费者关闭一直猛写log。
>> 我想问一下有没有什么办法设置flink不让他一直写log，这样感觉没办法测试运行啊，只要一报错就一直写日志，把服务器磁盘都干满了直接崩溃了。求助。

Re: Re: Flink 的 log 文件夹下产生了 44G 日志

2019-07-18 Thread Caizhi Weng 
Hi Henry

你的意思是不想让 Flink 写 log 吗？那只能通过 `log4j.rootLogger=OFF` (log4j) 或者 `  ` (logback) 把 log 关掉，或者把 log
等级设成更高的 FATAL... 但我感觉问题还是自定义的 source 里写 log 的时候死循环了...

Henry  于2019年7月19日周五 下午2:20写道：

>
>
>
> 你好，谢谢！是的，这个Source是用JMS实现的自定义Source。目前还在查原因，但是怎么能够让Flink不这样爆炸写log日志呢？20分钟就能写满磁盘，写了40G多。
>
>
>
>
>
> 在 2019-07-19 11:11:37，"Caizhi Weng"  写道：
> >Hi Henry,
> >
> >这个 source 看起来不像是 Flink 提供的 source，应该是 source 本身实现的问题。你可能需要修改 source
> >的源码让它出错后关闭或者进行其它处理...
> >
> >Henry  于2019年7月19日周五 上午9:31写道：
> >
> >>  大家好，之前那个报错图片大家没看到，重新弄一下。
> >> 报错图片链接：
> >> https://img-blog.csdnimg.cn/20190719092540880.png
> >> https://img-blog.csdnimg.cn/20190719092848500.png
> >>
> >>
> >>
> 我看报错的原因是，我这里Source用的是ActiveMQ，从昨天早上9点开始运行Flink任务接收消息，到今天早上8点都很正常。然后在今天早上8点4分的时候开始猛报错flink往log文件夹下写日志。第二个图是报错开始，显示ActiveMQ好像超时，然后就是消费者关闭一直猛写log。
> >>
> 我想问一下有没有什么办法设置flink不让他一直写log，这样感觉没办法测试运行啊，只要一报错就一直写日志，把服务器磁盘都干满了直接崩溃了。求助。
>

Re: Re: Flink 的 log 文件夹下产生了 44G 日志

2019-07-18 Thread Biao Liu 
最根本的解法当然是去掉打日志的地方，这 source 不是 Flink 内置的，Flink 当然不能控制你们自定义 source 的行为。

你可以考虑自己改一下 log4j.properties，手动关掉这个 logger, Flink 内置的 log4j.properties 里有
example，参考着改一下

log4j.logger.org.apache.flink.shaded.akka.org.jboss.netty.channel.DefaultChannelPipeline=ERROR,
file
改成 log4j.logger.com.JavaCustoms.FlinkJMSStreamSource=OFF, file

但是这明显是个 ERROR，最好还是解决一下，要不就是掩耳盗铃啊


Henry  于2019年7月19日周五 下午2:20写道：

>
>
>
> 你好，谢谢！是的，这个Source是用JMS实现的自定义Source。目前还在查原因，但是怎么能够让Flink不这样爆炸写log日志呢？20分钟就能写满磁盘，写了40G多。
>
>
>
>
>
> 在 2019-07-19 11:11:37，"Caizhi Weng"  写道：
> >Hi Henry,
> >
> >这个 source 看起来不像是 Flink 提供的 source，应该是 source 本身实现的问题。你可能需要修改 source
> >的源码让它出错后关闭或者进行其它处理...
> >
> >Henry  于2019年7月19日周五 上午9:31写道：
> >
> >>  大家好，之前那个报错图片大家没看到，重新弄一下。
> >> 报错图片链接：
> >> https://img-blog.csdnimg.cn/20190719092540880.png
> >> https://img-blog.csdnimg.cn/20190719092848500.png
> >>
> >>
> >>
> 我看报错的原因是，我这里Source用的是ActiveMQ，从昨天早上9点开始运行Flink任务接收消息，到今天早上8点都很正常。然后在今天早上8点4分的时候开始猛报错flink往log文件夹下写日志。第二个图是报错开始，显示ActiveMQ好像超时，然后就是消费者关闭一直猛写log。
> >>
> 我想问一下有没有什么办法设置flink不让他一直写log，这样感觉没办法测试运行啊，只要一报错就一直写日志，把服务器磁盘都干满了直接崩溃了。求助。
>

Re: 多滑动窗口问题

2019-07-18 Thread Biao Liu 
比如这样？

dataStream.timeWindow(...) // 5m
dataStream.timeWindow(...) // 15m
dataStream.timeWindow(...) // 30m
...


刘晨  于2019年7月19日周五 下午2:07写道：

> 您好:
>  请问, 在进行流计算时, source相同, 处理逻辑相同, 但要计算不同的滑动时间窗口,
>  比如 每分钟统计最近 5m,15m,30m 以及 每15分钟计算, 1h, 3h , 12h的数据
>  除去每种窗口写一个程序外, 有其他更加便捷的解决方式吗 ?
>
>
>   谢谢

多滑动窗口问题

2019-07-18 Thread aegean0...@163.com 
您好:
 请问, 在进行流计算时, source相同, 处理逻辑相同, 但要计算不同的滑动时间窗口, 
 比如 每分钟统计最近 5m,15m,30m 以及 每15分钟计算, 1h, 3h , 12h的数据 
 除去每种窗口写一个程序外, 有其他更加便捷的解决方式吗 ? 


  谢谢