我正在努力了解在提交flink工作之前需要考虑的重要特性是什么。
我的问题是什么是并行数，是否有一个上限（物理上）？并行性如何影响我的工作表现？
例如，我有一个cep-flink作业，它从未知流中检测模式，除非我用keyby操作符对数据流进行分区，否则并行数总是1。
如果我错了，请纠正我：
如果我对数据流进行分区，那么并行性的数量将等于不同键的数量。但问题是，模式匹配是为每个键独立完成的，因此我无法定义一个模式，该模式需要来自具有不同键的两个分区的信息。
我正在努力了解在提交flink工作之前需要考虑的重要特性是什么。
我的问题是什么是并行数，是否有一个上限（物理上）？并行性如何影响我的工作表现？
例如，我有一个cep-flink作业，它从未知流中检测模式，除非我用keyby操作符对数据流进行分区，否则并行数总是1。
如果我错了，请纠正我：
如果我对数据流进行分区，那么并行性的数量将等于不同键的数量。但问题是，模式匹配是为每个键独立完成的，因此我无法定义一个模式，该模式需要来自具有不同键的两个分区的信息。
1条答案
按热度按时间u91tlkcl1#
使用并行度为1的flink也不错。但是它破坏了使用flink（能够扩展）的主要目的。
一般来说，您不应该拥有比核心更高的并行性（物理或虚拟取决于用例），因为您希望尽可能地饱和核心。任何超出此范围的内容都会对您的性能产生负面影响，因为它需要更多的通信开销和上下文切换。通过扩展，您可以从网络中的分布式计算节点添加核心，这是使用大数据技术与手工编写应用程序相比的主要优势。
正如您所说的，只有对数据进行分区，才能使用并行性。如果你有一个需要所有数据的算法，你最终需要在一个核心上处理它。但是，通常在将数据合并到最终核心之前，可以并行地进行大量预处理（过滤、转换）和部分聚合。例如，可以简单地计算所有事件。您可以对每个分区的数据进行计数，然后在最后一步简单地将部分计数相加，这几乎可以完美地扩展。
如果您的算法不允许将其拆分，那么您的用例可能不允许分布式处理。那样的话，Flink就不合适了。然而，如果替代算法（有时是近似的）也能满足您的用例，那么值得探讨。这是数据工程的艺术，将单片算法分解成可并行化的子算法。