我有一些复杂的oozie工作流要从on prem hadoop迁移到gcp dataproc。工作流由shell脚本、python脚本、spark scala作业、sqoop作业等组成。
我遇到了一些结合我的工作流调度需求的潜在解决方案：
云生成器
带有云调度的dataproc工作流模板
在dataproc自动伸缩集群上安装oozie
请让我知道哪个选项在性能、成本和迁移复杂性方面最有效。
我有一些复杂的oozie工作流要从on prem hadoop迁移到gcp dataproc。工作流由shell脚本、python脚本、spark scala作业、sqoop作业等组成。
我遇到了一些结合我的工作流调度需求的潜在解决方案：
云生成器
带有云调度的dataproc工作流模板
在dataproc自动伸缩集群上安装oozie
请让我知道哪个选项在性能、成本和迁移复杂性方面最有效。
1条答案
按热度按时间hjqgdpho1#
所有3个都是合理的选择（尽管#2 scheduler+dataproc是最笨拙的）。需要考虑的几个问题：您的工作流多长时间运行一次，您对未使用的vm的容忍度如何，您的oozie工作流有多复杂，以及您愿意在迁移中投入多少时间？
dataproc的工作流支持分支/联接，但缺少其他oozie功能，如作业失败时的操作、决策节点等。如果您使用其中任何一个，我甚至不会考虑直接迁移到工作流模板，而选择下面的#3或混合迁移。
混合迁移是一个很好的起点（假设集群很少使用）。保留你的oozie工作流，让composer+工作流模板用oozie创建一个集群，使用init action暂存你的oozie xml文件+job jar/工件，添加一个
pig sh通过cli从工作流触发oozie的作业。