目录
【Connector】
1、增加 MQTT source & sink
【CLI】
1、flink help 提示信息缺少 run-application ✅
2、run-application 提示信息缺少 yarn-application
【Deployment/Yarn】
1、on Yarn 支持上传的资源来自于本地或者hdfs
2、通过匹配前缀的方式覆盖 hadoop / yarn 配置 ✅
3、对 YarnConfigurationOption 中的配置项进行规范化 ✅
【Deployment/Kubernetes】
1、non-HA 模式下去除 k8s internal service ❎
2、对 'kubernetes.container.image' 的描述信息进行规范化 ✅
Flink Issue
Flink PR
背景:
Flink 社区没有对接 MQTT Connector,如果读写 MQTT 的话,需要使用者自行开发对接。
诉求:
增加 MQTT source 和 sink,提供读写 MQTT 的功能。
issue:
BAHIR-212
进展:
并未贡献给 Flink 而是贡献给了 Bahir,但是该项目好像停滞了,代码待 review。
背景:
flink 1.12 支持 6 种 action: run、run-application、list、info、savepoint、stop、cancel,flink cli 输入其他 action 会有提示信息。
诉求:
提示信息缺少 run-application。
issue:
FLINK-20686
进展:
社区已采纳 -> issue 已分配给我 -> 代码已提交 -> 代码 review 中 -> 代码 review 通过 -> 代码已合入
背景:
run-application 模式下支持两种 target: yarn-application、kubernetes-application。
诉求:
在未设置 hadoop_classpath的情况下,提示信息缺少 yarn-application。我们认为提示信息应与环境无关,因此需要给出 yarn-application。
issue:
FLINK-20687
进展:
给出了三点应该输出yarn-application的原因,社区未再回应。
社区已采纳 -> issue 已分配给我 -> 代码已提交 -> 代码 review 中 -> 代码 review 通过 -> 代码已合入。
背景:
Application 模式下(Flink 1.10 新增) 提交 flink 作业到 yarn, 支持 ship 文件到 HDFS 并添加到容器的 classpath 中, 其中文件包括特定格式的压缩文件、普通的文件及目录。
诉求:
支持 ship 的文件不仅可以来自于本地,也可以来自于分布式文件系统,这样可以避免文件从本地上传到 hdfs 所带来的开销,从而加快作业的启动。
issue:
FLINK-20681
进展:
社区已采纳 -> issue 已分配给我 -> 代码已提交 -> 代码 review 中 -> 代码 review 通过 -> 代码已合入
背景:
flink 提交作业到 yarn,有时需要覆盖集群中设置的 hadoop / yarn 配置,但是 1.12 之前并不支持或者通过扩展 flink 配置进行部分支持。
诉求:
参考 spark 的方案,通过匹配'flink.hadoop.' / 'flink.yarn.'前缀的方式将配置项设置到 hadoop / yarn configuration 中。
issue:
FLINK-20682 & FLINK-16005
进展:
社区已采纳 -> issue 已分配给我 -> 代码已提交 -> 代码 review 中 -> 代码 review 通过 -> 代码已合入
背景:
flink 定义了一些对接 yarn 的配置项,这些配置项放在了 YarnConfigurationOption 中,但是有部分配置项并不规范。
诉求:
对 YarnConfigurationOption 中的配置项进行规范化编码。
issue:
FLINK-20927
进展:
社区已采纳 -> issue 已分配给我 -> 代码已提交 -> 代码 review 中 -> 代码 review 通过 -> 代码已合入
背景:
HA 模式下,TM 直接通过 JM podIP与之通信,在 JM failover 时通过 zk,TM 可发现新的 JM 进行注册并之通信。non-HA 模式下,TM 则通过 k8s internal service 与 JM 通信,这个服务发现功能是 k8s 特有的,Flink 社区希望通过这个服务发现能够在 JM failover 后,原先的 TM 依然能够被新的 JM 复用从而避免重新启动等数量的 TM。
诉求:
non-HA 模式下,在实际使用上 k8s internal service 并非能够达到使旧 TM 重新连接并被新 JM 复用的预期效果,这是因为当 JM failover 之后,旧 TM 能否连上新 JM 还取决于作业启动的速度和旧 TM 重新注册的速度,而且目前旧 TM 注册时并不会被新 JM 接纳,因此,k8s internal service 可以剔除,这样有几个好处:(1)提交作业时减少一个组件的创建,可以降低资源开销,尽管这部分资源可以忽略不计;(2)提高作业运行的稳定性。
issue:
FLINK-20249
由上面的 issue 引出的新的问题 FLINK-20332
进展:
只有在新 issue(FLINK-20332) 解决的前提下,internal service 才能发挥作用,否则没有实质收益。目前我给出的建议是:可以增加一个配置项: kubernetes.internal-serviece.enable,true 则复用旧 TM(新的issue解决的前提下),false 则启动等数量的 TM(这样可以yarn的行为保持一致)。社区未采纳。
背景:
'kubernetes.container.image' 的描述信息中含有外部链接,但是这个外部链接无法直接跳转访问。
诉求:
通过使用带有 link 的 text description 对该配置项进行规范化描述。
issue:
FLINK-20905
进展:
社区已采纳 -> issue 已分配给我 -> 代码已提交 -> 代码 review 中 -> 代码 review 通过 -> 代码已合入