闪烁窗口和状态维护
2）我研究了循环分区的重新平衡。假设我建立了一个集群，如果我的源的并行度为1，如果我进行了重新平衡，我的数据是否会在机器之间进行重排以提高性能？如果是这样，是否有一个特定的端口将数据传送到集群中的其他节点？
3）状态维护有什么限制吗？我计划维护一些用户id相关的数据，这些数据可能会变得很大。我读到flink使用rocks db来维护状态。只是想检查一下是否有限制可以维护多少数据？
4）同样，如果数据量较少，状态维护在哪里？（我猜是在JVM内存中）如果我的集群上有几台机器，每个节点都能得到当前的状态版本吗？
共有1个答案
>
如果您在user上键控您的流，则Flink将在内部按用户对流进行分区。因此，用户分布在一组并行的子任务上。窗口运算符的并行性控制每个并行子任务上的负载。如果您分配足够多的机器并适当配置程序的并行性，处理1000万用户应该没有问题。
是的，如果作业在多台计算机上运行，rebalance()将在网络上进行洗牌。在默认配置下，数据端口将自动选择。如果需要固定端口，可以使用taskmanager.data.port键对其进行配置。
状态大小限制取决于配置的状态后端。对于RocksDB状态后端，限制是本地文件系统的大小，即RocksDB将数据溢出到磁盘。万一碰到这个限制，可以增加并行度，因为每个工作者通常会处理多个键的键。
-
有人能帮我理解一下在flink中的窗口（会话）是什么时候和如何发生的吗？或者样品是如何加工的？ 例如：假设定义的时间窗口是30秒，如果一个事件在t时间到达，另一个事件在t+30，那么这两个事件都将被处理，但是在t+31到达的事件将被忽略。 如果我说的不对，请纠正。 上面的问题是：如果一个事件在t时间到达，而另一个事件在t+3时间到达，是否还会等待整个30秒来汇总并最终确定结果？ DTO： ====
-
我正在开发一个简单的聚合，它对给定资源上发生的事件总数进行汇总（请参阅：在flink中计算总数并定期发射）。在一些人的帮助下，我成功地完成了这项工作，但现在我遇到了另一个问题。 我试图计算资源生命周期的总数，但我正在从保留期为24小时的kinesis流中读取事件。因为这意味着我无法访问在此之前发生的事件，所以我需要从一个每天计算一次总数的遗留（批处理）系统引导我的状态。 基本上，我希望以某种方式从
-
我有一个流系统，在这里我可以获得点击流数据。 数据格式： 我怎样才能做到这一点呢？基本上，我必须维护窗口中所有事件的状态，然后，一旦我获得事件，我必须从该状态获取价格。我并不要求任何工作解决方案，只是要求如何维护窗口中所有事件的状态。我也有一些自定义的Reduce操作。 在:我将2个事件数据加入到列表中。
-
作业并行性（4,8,16):[自动生成源]-->[Map1]-->[滚动窗口(10s)]-->[Map2]-->[接收器] Flink窗口性能eps 4p、8p、16p 作业以上的性能最高达到了每秒50k+-左右，不管我如何将集群缩放成4-16的并行度。 闪烁性能无窗口4p、8p 我已经删除了窗口的逻辑，以消除瓶颈性能的应用程序逻辑，但似乎窗口仍然导致我的整个流性能下降，即使该窗口只是一个通过函数
-
我正在运行一个简单的示例来测试基于EventTime的Windows。我能够生成带有处理时间的输出，但当我使用EventTime时，没有输出。请帮助我明白我做错了什么。
-
感谢任何能帮助你回答问题的人。