本地环境Hadoop/Spark等ETL作业部署调度实践及资料问询

开发环境 #

• 本地调试阶段：开发者通常在本地搭建的轻量组件环境中直接手动提交作业，常用命令包括spark-submit、hadoop jar、hive -f 脚本路径.hql、pig -x local 脚本路径.pig，不需要额外调度工具，核心目标是验证业务逻辑正确性。
• 测试集群阶段：作业上传到测试集群的边缘节点后，开发者可通过SSH登录节点手动提交，也可配置简单的crontab定时任务做小范围稳定性验证，该阶段一般不会引入重型编排工具。

生产环境 #

• 代码同步：完成测试的ETL作业会统一打包归档（Spark作业可打包为jar/Python包、Hive/Pig脚本统一存储），通过CI/CD流程同步到生产集群边缘节点或HDFS等分布式存储中。
• 权限管控：所有作业的提交权限通过Kerberos、Ranger等组件统一管控，禁止普通用户随意登录生产节点手动提交作业。
• 运行触发：所有正式上线的生产作业都通过统一的调度入口触发，极少出现手动提交的情况。

是否必须使用Airflow、Oozie这类编排工具 #

不是必须，编排工具的选型完全取决于作业复杂度：

• 单步、无上下游依赖、仅需定时触发的简单ETL作业，完全可以通过crontab+bash脚本的方式运行，不需要引入重型编排工具。
• 存在多步依赖（比如A作业成功后才能运行B、B成功后触发C，失败需要自动重试、发送告警），或者需要统一监控作业状态、管理运行日志、维护依赖关系的场景，才需要用到专业的编排调度工具，可选工具除了Airflow、Oozie，还有Azkaban、DolphinScheduler等。

"作业几乎不会独立运行，即便是简单定时bash脚本也一定会通过调度器执行"的判断准确性 #

这个判断在生产环境下基本准确，开发环境除外：

• 生产环境中所有需要定时运行的作业，哪怕是仅包含一行命令的简单脚本，也一定会通过调度器（包含crontab这类轻量调度器，不局限于重型编排工具）统一管理，不会存在无记录的手动触发场景，核心是为了可追溯、可监控，避免人为操作失误。
• 开发环境下存在大量手动触发的独立运行作业，主要用于调试、临时数据查询等场景，不需要走调度流程。

• 官方文档类：Hadoop、Spark、Hive、Pig、常用调度工具的官方文档，重点阅读作业提交、第三方调度集成相关的章节即可。
• 书籍类：《Hadoop权威指南》中MapReduce作业提交、调度相关章节，《Spark权威指南》中作业部署运行相关章节，《大数据调度平台实战》讲解各类调度工具的适用场景和落地实践。
• 实践类：可以在本地搭建单节点Hadoop集群，依次尝试手动提交作业、crontab定时提交、Airflow配置依赖调度的全流程，能够快速理解不同部署方式的差异。

内容的提问来源于stack exchange，提问作者user538578964