Spark Accumlator 解析
问题:
- Accumlator 的更新粒度是 Task 级别,还是什么粒度?
- Task 失败时的累加器信息,是否仍会更新,出现重复的情况?
- Action 中的累加器如何保证只执行一次?
- Transform 中的累加器是否有办法解决重算时多次更新的问题?
问题:
在 Github 上发布 Release 时,默认只会发布源码的zip包,但是有时候会想要将一些编译出来的文件也放在 Release 中。虽然可以在本地编译,然后通过界面手动上传。但是可以基于 Github Action 实现自动发布。
在开发通过包/类/方法注解自动生成README的功能时,在使用时,如果使用 Jar 依赖的方式,需要为每个工程定义一个 Main 方法,并且需要手动调用。
因此想通过开发Maven 插件,在compile阶段自动调用并生成 README,因此便研究如何开发 Maven 插件。
https://community.cloudera.com/t5/Community-Articles/Starting-Spark-jobs-directly-via-YARN-REST-API/ta-p/245998 这篇文章是Spark 1.6, 已经过时,只能作为基本的参考,具体还是要阅读Spark on Yarn的提交代码。
- 本文基于 Spark 2.4.8 和 Hadoop 3.2 进行验证。
将 Spark 作业提交到 Yarn上时,只能通过命令行 spark-submit 进行操作,本文通过解析 spark-submit 的源码,探究如何使用 Yarn Rest API 进行提交 Spark 作业(仅 cluster 模式,因 client 模式 driver 运行在 client 中而不是 AM 中)。
一句话总结:还是用命令行调用spark-submit
!
在开发CRD时,定义 controller
的时候,会看到如下代码
mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
// 是否进行 leader 选举
LeaderElection: enableLeaderElection,
// Namespace and name
LeaderElectionNamespace: leaderElectionNamespace,
LeaderElectionID: "alluxio.data.fluid.io",
// ...
})
对于有状态组件来说,实现高可用一般来说通过选主来达到同一时刻只能有一个组件在处理业务逻辑。
这里,会比较好奇这个选举是如何实现的,接下来的内容便从源码的角度进行解读。