【问题标题】:why is it bad to execute Flink job with parallelism = 1?为什么以并行度 = 1 执行 Flink 作业是不好的?
【发布时间】:2020-05-15 15:11:06
【问题描述】:

我试图了解在提交 Flink 作业之前需要考虑哪些重要功能。

我的问题是并行数是多少,是否有上限(物理上)?并行性如何影响我的工作性能?

例如,我有一个 CEP Flink 作业,它从非键控流中检测模式,并行数将始终为 1,除非我使用 KeyBy 运算符对数据流进行分区。

如果我错了,请纠正我:

如果我对数据流进行分区,那么我的并行数将等于不同键的数量。但问题是模式匹配是针对每个键独立完成的,因此我无法定义需要来自具有不同键的 2 个分区的信息的模式。

【问题讨论】:

    标签: apache-flink flink-streaming flink-cep flink-sql flink-batch


    【解决方案1】:

    使用并行度 = 1 的 Flink 还不错。但它违背了使用 Flink 的主要目的(能够扩展)。

    一般来说,您不应该拥有比您的核心更高的并行度(物理或虚拟取决于用例),因为您希望尽可能地使您的核心饱和。超出此范围的任何事情都会对您的性能产​​生负面影响,因为它需要更多的通信开销和上下文切换。通过横向扩展,您可以从网络中的分布式计算节点添加内核,这是使用大数据技术与手动编写应用程序相比的主要优势。

    正如您所说,您只能在对数据进行分区时使用并行性。如果您有一个需要所有数据的算法,您最终需要在一个核心上处理它。但是,通常您可以在最终核心合并数据之前并行执行大量预处理(过滤、转换)和部分聚合。例如,考虑简单地计算所有事件。您可以计算每个分区的数据,然后在最后一步简单地总结部分计数,这几乎可以完美地扩展。

    如果您的算法不允许拆分,那么您的用例可能不允许分布式处理。在这种情况下,Flink 并不合适。但是,如果替代算法(有时是近似算法)也足以满足您的用例,则值得探索。这就是将单一算法拆分为可并行化的子算法的数据工程艺术。

    【讨论】:

    • 在我看来,一些应用程序可能会受益于使用 Flink 轻松组织容错流水线阶段的并发执行,即使每个任务的并行度只有一个。但这几乎不是主流用例。
    • 感谢您提供这些信息,所以如果我理解正确,使用 CEP Flink 有一些限制,例如如果输入是未键入的 Stream,则可扩展性,对吧?
    • 这取决于模式。如果它使用可分解的函数(参见我的计数示例),那么它将扩展。您可以在执行时轻松地在 UI 中检查所有子任务是否都获取数据。一般来说,如果你的算法是无键的并且不能被分解,不要指望它可以处理更大的数据量。除非我有一个非常具体的用例,否则我总是尝试找到一种可扩展的算法,因为数据量的增长速度比单个 CPU 的能力要快得多。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-07-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2019-03-30
    相关资源
    最近更新 更多