任务调度器Azkaban（Azkaban环境部署）

azkaban是什么，我们又用Azkaban 做写什么
azkaban是工作流程的调度器,是用来调度工作流程的
比如说做饭 我们需要 1. 采购食材 2. 洗菜 3. 炒菜 这是一个典型的工作流程
一个工作流程的特点是 由多个任务单元组成， 并且多个任务单元之间是有前后依赖关系的
azkaban是干什么用的.就是用来调度工作流程的  
当然azkaban他所调度的工作流程肯定不是我刚刚炒菜的工作流程，他所调度的是hadoop工作流程
hadoop工作流程是什么样子的， 在哪里会用到hadoop工作流程

接下来我们就会涉及到数仓  数仓的数据从哪里来 到哪里去，我们的数仓后面会接入各种Bi应用（QuickBi）
数据从前到后会经历那些处理过程  现在我们数仓的主体还是hive

我们通过sqoop或者Fluem 将业务数据和用户行为Log进行采集，然后先同步至数仓，我们的数据在数仓中
也是以各种表的形式存在的，我们吧数据从业务系统传输到我们数仓中，此时需要对数据进行一系列处理
比如说 我们需要对数据进行简单的清理操作，比如说一些脏数据的过滤，以及脱敏
清洗完毕之后我们可能还要对数据进行一些汇总
我们可能还要对数据进行一些进一步的计算
最终得到我们想要的结果输出到bi报表中
这就是一个简单的工作流程（典型的工作流程）
他的工作单元是有一定的前后关系的 比如说先吧数据同步到我的数仓中 才能对他进行一些清洗操作，清洗之后才能汇总，汇总之后才可以计算 最终得到我想要的结果. 这就是一个典型的工作流程
这就是hadoop的工作流程

大致已经知道什么叫做数仓，而且也已经知道数仓的工作流程了 我们需要思考为什么用Azkaban来调度这些工作流程
我们不用行不行
假设我们不用调度工具，我们的工作流程该如何提交 逐个提交（按照前后关系依次去提交么）
假设整个流程都是人工操作的我第一个流程可能提交完毕1小时之后才能完成
完成之后我提交下一个，可能第二个任务也需要1小时 等他提交之后我才能提交
显然 人工去提交是不合理的
而且每天会有新的数据产生，新的数据每天都会对他进行处理，也就是说整个流程不是说提交一次就OK了
需要每天重复去提交，这样我们人工去提交显然更不行 
所以说有这么一个痛点  我们才需要用Azkaban调度工具来帮我们进行调度工作流程
azkaban他能够实现什么样的功能
主要就是2个功能
第一个就是我们吧整个工作流程里面的工作 工作的依赖都告诉给azkaban,azkaban就能够按照我们的工作单元
之间的依赖关系一次帮我们提交任务
先会提交第一个而且他会进行监控，等这个任务完成以后，再去提交下一个
这些都是自动化运行的 我们要做的只是提交一次 然后剩下的会根据这个依赖关系逐个提交每个工作单元的
这是azkaban的一个功能

第二个功能就是可以定时实现调度的功能，整个工作流程，我们需要每天去重复执行的
azkb可以定时去调度 定时去执行工作流程
这个就是azkb的意义以及应用场景
首先我已经知道了 他是工作流程调度系统或者工作流程调度器 我们在哪里会用到 
在数仓就会用到工作流

市面上常见的任务调度器 这么多调度器 我们该如何去选择

cron只能做简单的，我们使用cron 比如说数据库的定时备份任务
对于我们前面涉及到的复杂的工作流程的依赖关系是不行的  你用cron 是不行的

比如说Ooize以及Azkaban这些调度器我们在使用的时候 一般分2步去做
第一步 是描述工作流程的  我们需要告诉任务调度器（比如说Ooize和Azkaban）我们的工作流程和几个工作单元，每个工作单元的具体工作是什么，以及工作单元和工作单元的前后依赖关系
只有告诉他 我们才能够按照我们的依赖关系逐个去提交我们的任务
第二步 配置定时规则  比如说我需要让我的任务在每一天的什么时候去执行

区别就是  我们在描述工作流程或者说是配置这个定时任务上面的不同
有些可能通过web界面进行配置 有些可能通过yaml配置 有些可能通过db进行配置
Ooize  CDH平台下的调度器  我们可以借助Hue可视化界面  我们所有配置都在页面上去完成
azkaban 简单易用的工作流程  我们可以通过yaml配置的工作流程	定时规则在页面配置
airFlow  python 脚本配置的 ,我们需要通过python脚本来配置定时规则和工作流程

目前我们使用最多的就是Ooize和azkaban
Ooize功能全面带来的就是配置起来复杂 
azkaban功能精简 只有核心功能 但是一般就够用了
常见的工作流程调度系统

azkaban的部署架构
# azkaban分三部分 这三部分的主要职责是 
azkaban web Server 项目管理 用户管理 以及权限管理  任务定时和触发 工作界面
azkaban Executor Server 具体任务的执行 也就是azkaban 所调度的任务 最终是在executor所在的节点去执行的
mysql 会存储 工作流程的配置 定时规则的配置  以及任务的执行状态

部署模式 单机模式 只有一个进程 （1个进程包括web和Executor ） 同一个进程
		集群模式（生产配置）web和Executor 是独立部署的 2个不一样的进程
		集群模式可以配置多个Executor 比如说1个web 3个executor
		多executor 能够起到什么作用   负载均衡和容灾的功能
		在生产环境 下部署多exector

上面就是azkaban的基本架构以及他的部署模式

azkaban的部署阶段 我们采用集群模式 并且多Exector模式
Hadoop102  hadoop103  hadoop104
web
Executor   Executor   Executor
这就是我们的部署集群规划

首先第一步需要准备azkaban 的安装包
azkaban一共有3个包 一个web  一个 Executor 一个db(运行过程中的建表语句)
准备好了安装包之后就可以部署了


数据库的初始化(1.数据库的创建 2. 用户的创建 3. 用户对数据库的权限操作}  建表语句{db包 中有sql 脚本} 

接下来部署Executor的配置，
我们的web根据集群配置 是配置在hadoop102上

executor.port 为executor.port指明一个端口号
如果我们不指明端口号 这里默认是一个随机值  不方便管理，让他的端口号固定下来 方便管理
通过Xyscp 同步给其他三个节点  因为我们之前在hadoop102 hadoop103 hadoop104分别部署azkaban的exector  现在我们进行分发
这样 我们在3台节点上都完成了azkaban的executor的部署
executor的启动 分2个步骤 1启动 2激活
只有激活的executor才可以被我们使用

bin /start-exec.sh启动  通过start-exec.sh启动之后用jps命令查看

我们也可以用navicate连接库存 看这个表的信息  102的启动成功了   0代表没有激活

之后我们启动103 和104 

每个exectors 在启动的时候会在这个表中插入一条数据
相当于完成注册  停止的时候这个数据也会被删除了
我们现在已经完成了3台节点的azkb的exector的启动 但是我们还没有激活

bin /shutdown-exec.sh停止
如何去激活
怎么去激活 我们向他提供一个get请求
用curl发送get请求  我们现在逐个去激活每一个Exector

回复success就代表已经是激活状态  然后我们在看db的落表情况
现在已经激活并且是可用的状态 现在我们已经激活103 和104 了
激活的命令

之后我们再一个个的处理~  直到3台服务器的active都为1  就代表都已经激活了
我们目前已经完成了azakan exector的部署 配置 以及启动

azkb第三个步骤就是web Server的部署和配置
WebServer需要部署在hadoop102的这个主机 现在我们已经将azakban的webService解压下来了
接下来我们来看azkb的web配置需要有那些配置

因为我们的azkb的webserver和azkb的exector是独立部署的 2个地方的时区都要修改下
这里也改下和db相关的数据库配置

这个改完毕之后我们还得再改一个
azkb-users.xml文件  这个文件是用来干什么的  是azkb web-service 用来做用户管理的文件
azakban-users
这个文件是用来做用户管理以及权限管理的文件

比如说我此时配置的atguigu拥有admin角色
atguigu----->admin角色-------->admin权限  后续我们再使用azkb的时候就可以使用atguigu用户去登录azkb了

我们azkb需要改的配置文件都改完了  这个时候我们就可以启动azkb的webService了
启动webService的时候 /bin/start-web.sh去启动  /bin/shut-down.sh停止
启动完毕之后我们可以用jps 查看是否启动成功

多了一个进程
我们现在访问azkb的管理台页面  http:hadoop102/

看看有没有启动成功 我们此时尝试登录(atguigu) 因为我们刚刚设置账号和密码 并且设置权限了

呢么这个azkb到底该怎么用呢 先演示下azkb的使用   我们使用这些工作流程调度系统的时候 主要就是分2步
1.描述我们	的工作流程 第二步就是定时	
azkb也不例外	 我们要用azkb来调度我们的工作流程 首先要怎么做  
写一个.project和.flow文件  然后将这2个文件打包成zip包
我们现在完成2个文件的创建了 创建完毕以后 打开azkb的页面

create project
上传 下载就是我们工作流程的描述文件  因为我们说使用这个工作流程调度系统
我们首先需要描述工作流程,我的先告诉azkb我的工作流程是什么样子的
吧这2个文件 打到同一个zip包中进行上传

上传之后怎么去执行 工作流程
怎么去执行exector flow 执行工作流程
我们这个最简单的工作流程 只有一个工作单元 jobA  然后点击下一步

定时调度   execute 这个工作流程会立即执行 而且只会执行一次
做定时调度的  会配置一个定时规则 比如说每天的0点30分去跑

某个工作单元是绿色 代表已经执行成功了
如果某个工作单元是蓝色 代表工作单元正在执行中
如果是个红色 代表该任务已经失败了

比如说此时是绿色的代表 成功了 因为此时的任务很简单.
如果变红代表报错了 代表有问题了 我们需要查找这个单元他失败的原因
去哪里去看失败原因 或者说哪里去看任务执行的日志

这里的job List去看工作流程的日志 
这里强调2个概念 一个是flow 一个是job
在azkb当中  flow  工作流程
Job--->工作单元
Job Log就是工作单元日志
Flow 只会展示整体成功还是失败

这个job List是有一个列表 他会吧我们整个流程的每一个工作单元展示出来
因为此时我们这边只有一个工作单元，假设此时有多个工作单元
此时我们要找到呢个红色的工作单元 看看为什么报错 {log 该工作单元执行过程中打印的日志}

这就是我们出现问题之后去排查日志的方法
Azkb我们第一个案例就结束了,我们需要整体大致了解azkb的从头到尾的使用过程
我的JOBA 也仅仅打印一句话hello world

对于azkb的使用 我们azkb的使用过程最核心的就是这个配置文件的编写

这2个文件的编写  只要我们学会这2个文件的编写 呢么azkb的使用就不是问题
project文件 的内容是固定的  这个文件的内容有什么含义 标识flow的版本  在使用azkb的时候 我们要使用配置文件来描述工作流程  那个文件用来描述工作流程的呢 就是下面的flow文件 	就是我们用来描述工作流程的文件
呢么azkb 目前所支持的描述工作流程的配置文件的写法  2中 1.yaml 2.propeities
protitws是第一代 
yaml是第二代
这个文件作用就是 告诉azkb我现在用的工作流程的描述版本为version2



第二个文件就是用来描述我们工作流程的文件 这个文件才是我们重点学习的文件 
这个语法采用的yaml语法

command相当于执行一条命令
我们的命令就是打印我们的 hello woldl
执行结果是怎么样的  我们可以看对应的日志

工作单元的执行结果
这里我们就对我们的flow文件有个大概的了解了

我们再去看我们这个flow文件
这里就相当于我们azkb的job的概念
假设这是我们调用的工作流程它里面有4个Job  这个工作流程 我们要用flow文件去描述的化
我们的数组应该有4个数组的	每个元素所描述的就是他所对应的工作单元

这既是我们flow文件的编写规则，做完第一个hello World案例规则之后，又讲解一个工作流程
继续进行,接下来要讲的案例叫做作业依赖案例
之前的hellworld案例.他其实不算一个严格的工作流程 
一个工作流程有2个特点 一个是由多个 任务单元组成 多个任务单元有相互前后关系
helloworld只有一个工作单元

呢么如果涉及到作业依赖的案例 我们又该怎么去写

C是依赖于A和B  基于需求编写配置文件
关于工作单元的依赖关系  还没有进行描述  dependOn 描述依赖关系
我们声明了我们的JOBC是依赖于jobA和jobb了
joba和jobb不依赖于任何工作单元 他俩执行完毕之后 再执行jobC

再之后我们吧他打成zip包  在web上进行上传

现在的效果就和我们预期效果一样 同样我们先测试下

当然我们执行任务简单 就是打印输出一句话 所以说这三个任务瞬间就变绿了

我们也可以根据时间线，看到我们可以A和b是并行执行的 ,等他们都执行完毕了 再去执行C 
这样的任务的依赖关系就讲完了  依赖DependSon属性

作业依赖案例 接下来 我们看失败重试案例
一个是自动失败重试案例  一个是手动失败重试案例
自动失败重试 比如说a--->b--->c  b是失败了 假定b此时失败的原因是暂时性的故障，比如说暂时性的
系统资源不足或者网络抖动而导致连接的超时或者申请资源超时

这样的问题 可能就是重新跑一次就有可能成功  因为这是暂时性的问题 我们此时可以使用自动失败重试  来解决这样的问题	只要遇到问题 我就让他重新跑
这就是自动失败重试

手动失败重试,导致我们任务失败的原因不是暂时性故障 而是一些比如说 服务器宕机
或则话说我们任务本身就有问题
我们只能定位问题 再去改 然后我能够吧已经完成的跳过 避免重复执行

手动失败重试 我们该怎么去实现 我们刚刚说的这种效果
任务失败 我重新跑的时候  如何跳过已经成功的工作单元从失败的开始跑

这个就是自动失败重试和手动失败重试,自动失败重试我们做的很简单  我们在flow文件中

我此时的command 执行一个不存在的文件,不存在的脚本 呢么这个任务肯定会执行失败

红色表示失败 因为我们的脚本本身就不存在
 表明该任务单元一共执行了4次 
这就是我们自动失败重试---？她所能解决的问题就是

这就是我们自动失败重试--->她所能解决的问题就是
一些暂时性的网络波动导致的超时 或者由于暂时性的资源不足导致的超时
但是有些问题我们通过自动失败重试是解决不了的 这样的问题我们最终还是会失败
这时候要求我们掌握手动失败重试
期望能得到效果就是说,当我们工作流程在经历自动失败重试以后最终还是失败了	
这时候我们就得排查自动失败的原因  看看到底是什么原因导致的
当我们排查修复后 这个任务需要恢复执行  恢复执行的时候 我们期望达到 
吧成功的单元跳过让他从失败的位置开始继续往下进行

这个也是可以配置的