实战经典JOB案例详解.docxVIP

阅读建议建议你耐心仔细阅读本文，先对JOB的结构有整体概念，然后研究每个文件的意义，过程中请多翻看案例代码demo-cd。至此，你一定能够深刻理解JOB的构造。案例demo-cd的模拟场景简述：每日从上游业务系统同步增量数据到HADOOP，然后运行数据分析模型，对新过来的数据进行分析，得出分析结果后，把结果导出到前端系统，供前端做人工审查。阅读本文之前，建议你对SHELL、HIVE、SQOOP有所了解，这些都是零部件，而本文所述是整体结构。 一、JOB的文件结构JOB的文件结构通常是这样的： 在SVN目录oozie-app下，有各种JOB，他们是相对独立的，每个JOB都可以提取下来单独发布到HADOOP平台上运行（部署过程另外讲解）。比如我们的经典案例demo-cd，就是一个JOB。hql目录用于存放hive脚本，hive脚本习惯后缀.q；shell目录用于存放shell脚本，shell脚本习惯后缀.sh 。文件coordinator.xml、perties、runJob.sh、workflow.xml，是一个JOB所必需的，文件removeJob.sh不是必需的，它们的意义下面详解。二、JOB的文件分解在讲解JOB的各个文件意义之前，我们思考一个业务场景：当客户提出一个数据模型，我们首先要通过SQOOP工具，把业务数据从业务系统同步到HADOOP平台供数据分析使用，然后通过HIVE实现数据模型，这过程中可能形成多个HIVE.q脚本和SHELL.sh脚本，它们之间相互依赖，必须有序地、且可能要求按一定的频率重复执行。目前这些脚本都还只是零散的工作部件（action），我们希望这些脚本被组织起来，按照预设的执行顺序和调度频率执行，谁来负责这个事情？预设脚本的执行顺序，是工作流（workflow）要解决的问题；预设工作流的执行频率，是调度机制（coordinator）要解决的问题。Coordinator和workflow一起让工作变得有组织和有序。1）workflow.xml它负责组织一个工作流。文件中，你可以看到多个action，每个action都有各自负责执行的内容（通常是执行一个SHELL脚本），多个action之间的流向是预设的，而且是单向的非闭合的。以下我们截取一段workflow.xml做详解：workflow-app xmlns=uri:oozie:workflow:0.4 name=demo-wf start to=check_this_job_satete/… … 省略workflow中间多个action，详看案例代码action name=model-001 shell xmlns=uri:oozie:shell-action:0.2 job-tracker${jobtracker_address}/job-tracker name-node${namenode_address}/name-node prepare delete path=${sqoop_import_path}/ /prepare configuration property name/name value${mapred_job_queue_name}/value /property /configuration exec${file_execute_Q}/exec argument${file_model_001}/argument argument${nominalformate_Date}/argument argument${mapred_job_queue_name}/argument fileshell/${file_execute_Q}#${file_execute_Q}/file filehql/${file_model_001}#${file_model_001}/file /shell ok to=SYNC_sqoop_export/ error to=fail//action… … 省略workflow中间多个action，详看案例代码action name=clean_path_node fs delete path=${sqoop_import_path}//fs ok to=end/ error to=fail/ /action kill name=fail messageaml wf failed, error message[${wf:errorMessage(wf:lastErrorNode())}]/message /kill end name=end//workflow-app2）coordinator.xml上面讲到workflow是一个工作流，但它是单向的非闭合的，它没有回路，换言之