【问题标题】:Flink - multiple instances of flink application deployment on kubernetesFlink - kubernetes 上的多个 flink 应用部署实例
【发布时间】:2020-08-24 04:53:29
【问题描述】:

我需要关于在 K8 上部署 Flink 应用程序的帮助

我们有 3 个源,它们将以 SQL 查询的形式发送触发条件。总查询数约为 3-6k,实际上是 flink 实例的沉重负载。我尝试执行,但速度很慢,需要很长时间才能开始。

由于查询量很大,我们决定为每个源创建多个 flink 应用实例。所以有效地,一个 flink 实例只会执行大约 1-2K 查询。

示例:sql查询源为A、B、C

Flink 实例:

App A --> 只负责处理源 A 查询

App B --> 将只负责处理源 B 查询

App C --> 只负责处理源 C 查询

我想在 Kubernetes 上部署这些实例

问题:

a) 是否可以使用迷你集群(内置)部署独立的 flink jar?就像启动主方法一样:Java -cp mainMethod(sourceName 是命令行参数 A/B/C)。

b) 如果 k8 的一个 pod 或 flink 实例宕机,那么我们如何在另一个 pod 或另一个 flink 实例中管理它?是否可以将工作交给其他 pod 或其他 flink 实例?

对不起,如果我把两个或更多的东西混在一起了:(

感谢您的帮助。谢谢

【问题讨论】:

  • 通常你会通过增加源函数的并行度来处理这个“重负载”问题,并且(根据需要)弄清楚如何对查询进行分区,以便每个子源实际上具有相同的加载。为什么这不是您的选择?
  • 感谢您的建议,因此假设我根据“源”对规则(sql 查询)进行了分区以分配任务负载。如果 sql 查询有任何变化,这意味着重新启动完整的 flink 实例。对?如果是,那么它是其他来源的停机时间,这是我们试图通过基于“来源”创建多个实例来避免的事情。

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


【解决方案1】:

撇开一次性语义问题不谈,处理此问题的一种方法是使用一个并行源函数来发出 SQL 查询(每个子任务一个),以及一个执行查询的下游 FlatMapFunction(一个每个子任务)。然后,您的来源可以向查询发送更新,而不会强制您重新启动工作流。

【讨论】:

  • 最初,我的计划与源函数相同,将接收 sql 查询,然后由 map 函数执行。我尝试过,但遇到了很多序列化问题。这是相同的讨论:stackoverflow.com/questions/62680606/…
猜你喜欢
  • 2020-04-06
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-10-03
  • 2022-10-20
相关资源
最近更新 更多