我有一些复杂的 Oozie 工作流要从本地 Hadoop 迁移到 GCP Dataproc。工作流由 shell 脚本、Python 脚本、Spark-Scala 作业、Sqoop 作业等组成。
我遇到了一些结合我的工作流调度需求的潜在解决方案：
请告诉我哪个选项在性能、成本和迁移复杂性方面最有效。
【问题讨论】：
标签： hadoop airflow google-cloud-dataproc google-cloud-composer oozie-workflow
所有 3 个都是合理的选项（尽管 #2 Scheduler+Dataproc 是最笨重的）。需要考虑的几个问题：您的工作流程多久运行一次，您对未使用的虚拟机的容忍度如何，您的 Oozie 工作流程有多复杂，以及您愿意花时间进行迁移吗？
Dataproc 的工作流支持分支/加入，但缺少其他 Oozie 功能，例如在作业失败时如何处理、决策节点等。如果您使用其中任何一个，我什至不会考虑直接迁移到工作流模板并选择#3 或下面的混合迁移。
混合迁移是一个很好的起点（这是假设您的集群很少使用）。保留您的 Oozie 工作流程并让 Composer + Workflow Templates 使用 Oozie 创建一个集群，使用 init 操作来暂存您的 Oozie XML 文件 + 作业 jars/artifacts，从 Workflow 添加单个 pig sh 作业以通过 CLI 触发 Oozie。
【讨论】：
workflow challenges吗？如果您的目标是提升和转移（从 DC 到 Cloud），那么＃3 是显而易见的。我唯一的建议是研究可以避免长时间运行持久集群的方法（例如，您不会获得操作系统或 OSS 更新）。最终，您将不得不升级 Dataproc 映像版本，如果没有自动化，这将非常痛苦。