新書推薦：
《
索恩丛书·盛清统治下的太监与皇帝
》
售價：HK$
88.5
《
透过器物看历史（全6册）
》
售價：HK$
490.6
《
我在台北故宫博物院读名画
》
售價：HK$
109.8
《
尼罗河往事：古埃及文明4000年
》
售價：HK$
76.2
《
一个人·谁也不是·十万人（诺贝尔文学奖得主反思自我的巅峰之作）
》
售價：HK$
54.9
《
重写晚明史（全5册 精装）
》
售價：HK$
781.8
《
汉末晋初之际政治研究
》
售價：HK$
132.2
《
强者破局：资治通鉴成事之道
》
售價：HK$
80.6
|
| 編輯推薦： |
|
本书共13章，主要内容包括数据仓库、Hadoop及其生态圈的相关概念，使用Sqoop从关系数据库全量或增量抽取数据，使用Hive进行数据转换和装载处理，使用Oozie调度作业周期性执行，使用Impala进行快速联机数据分析，使用Hue将数据可视化，以及数据仓库中的渐变维（SCD）、代理键、角色扮演维度、层次维度、退化维度、无事实的事实表、迟到的事实、累积的度量等常见问题在Hadoop上的处理等。本书适合数据库管理员、大数据技术人员、Hadoop技术人员、数据仓库技术人员，也适合高等院校和培训学校相关专业的师生教学参考。
|
| 內容簡介： |
本书讲述在流行的大数据分布式存储和计算平台Hadoop上设计实现数据仓库，将传统数据仓库建模与SQL开发的简单性与大数据技术相结合，快速、高效地建立可扩展的数据仓库及其应用系统。
本书内容包括数据仓库、Hadoop及其生态圈的相关概念，使用Sqoop从关系数据库全量或增量抽取数据，使用HIVE进行数据转换和装载处理，使用Oozie调度作业周期性执行，使用Impala进行快速联机数据分析，使用Hue将数据可视化，以及数据仓库中的渐变维（SCD）、代理键、角色扮演维度、层次维度、退化维度、无事实的事实表、迟到的事实、累积的度量等常见问题在Hadoop上的处理等。
本书适合数据库管理员、大数据技术人员、Hadoop技术人员、数据仓库技术人员，也适合高等院校和培训机构相关专业的师生教学参考。
|
| 關於作者： |
|
王雪迎 ，毕业于中国地质大学计算机专业，高级工程师，拥有20年数据库、数据仓库相关技术经验。曾先后供职于北京现代商业信息技术有限公司、北京在线九州信息技术服务有限公司、华北计算技术研究所、北京优贝在线网络科技有限公司，担任DBA、数据架构师等职位。
|
| 目錄：
|
目 录
第1章 数据仓库简介
1.1 什么是数据仓库 1
1.1.1 数据仓库的定义 1
1.1.2 建立数据仓库的原因 3
1.2 操作型系统与分析型系统 5
1.2.1 操作型系统 5
1.2.2 分析型系统 8
1.2.3 操作型系统和分析型系统对比 9
1.3 数据仓库架构 10
1.3.1 基本架构 10
1.3.2 主要数据仓库架构 12
1.3.3 操作数据存储 16
1.4 抽取-转换-装载 17
1.4.1 数据抽取 17
1.4.2 数据转换 19
1.4.3 数据装载 20
1.4.4 开发ETL系统的方法 21
1.4.5 常见ETL工具 21
1.5 数据仓库需求 22
1.5.1 基本需求 22
1.5.2 数据需求 23
1.6 小结 24
第2章 数据仓库设计基础
2.1 关系数据模型 25
2.1.1 关系数据模型中的结构 25
2.1.2 关系完整性 28
2.1.3 规范化 30
2.1.4 关系数据模型与数据仓库 33
2.2 维度数据模型 34
2.2.1 维度数据模型建模过程 35
2.2.2 维度规范化 36
2.2.3 维度数据模型的特点 37
2.2.4 星型模式 38
2.2.5 雪花模式 40
2.3 Data Vault模型 42
2.3.1 Data Vault模型简介 42
2.3.2 Data Vault模型的组成部分 43
2.3.3 Data Vault模型的特点 44
2.3.4 Data Vault模型的构建 44
2.3.5 Data Vault模型实例 46
2.4 数据集市 49
2.4.1 数据集市的概念 50
2.4.2 数据集市与数据仓库的区别 50
2.4.3 数据集市设计 50
2.5 数据仓库实施步骤 51
2.6 小结 54
第3章 Hadoop生态圈与数据仓库
3.1 大数据定义 55
3.2 Hadoop简介 56
3.2.1 Hadoop的构成 57
3.2.2 Hadoop的主要特点 58
3.2.3 Hadoop架构 58
3.3 Hadoop基本组件 59
3.3.1 HDFS 60
3.3.2 MapReduce 65
3.3.3 YARN 72
3.4 Hadoop生态圈的其他组件 77
3.5 Hadoop与数据仓库 81
3.5.1 关系数据库的可扩展性瓶颈 82
3.5.2 CAP理论 84
3.5.3 Hadoop数据仓库工具 85
3.6 小结 88
第4章 安装Hadoop
4.1 Hadoop主要发行版本 89
4.1.1 Cloudera Distribution for Hadoop（CDH） 89
4.1.2 Hortonworks Data Platform（HDP） 90
4.1.3 MapR Hadoop 90
4.2 安装Apache Hadoop 91
4.2.1 安装环境 91
4.2.2 安装前准备 92
4.2.3 安装配置Hadoop 93
4.2.4 安装后配置 97
4.2.5 初始化及运行 97
4.3 配置HDFS Federation 99
4.4 离线安装CDH及其所需的服务 104
4.4.1 CDH安装概述 104
4.4.2 安装环境 106
4.4.3 安装配置 106
4.4.4 Cloudera Manager许可证管理 114
4.5 小结 115
第5章 Kettle与Hadoop
5.1 Kettle概述 117
5.2 Kettle连接Hadoop 119
5.2.1 连接HDFS 119
5.2.2 连接Hive 124
5.3 导出导入Hadoop集群数据 128
5.3.1 把数据从HDFS抽取到RDBMS 128
5.3.2 向Hive表导入数据 132
5.4 执行Hive的HiveQL语句 134
5.5 MapReduce转换示例 135
5.6 Kettle提交Spark作业 143
5.6.1 安装Spark 143
5.6.2 配置Kettle向Spark集群提交作业 146
5.7 小结 149
第6章 建立数据仓库示例模型
6.1 业务场景 150
6.2 Hive相关配置 152
6.2.1 选择文件格式 152
6.2.2 支持行级更新 159
6.2.3 Hive事务支持的限制 164
6.3 Hive表分类 164
6.4 向Hive表装载数据 169
6.5 建立数据库表 174
6.6 装载日期维度数据 179
6.7 小结 180
第7章 数据抽取
7.1 逻辑数据映射 182
7.2 数据抽取方式 185
7.3 导出成文本文件 191
7.4 分布式查询 196
7.5 使用Sqoop抽取数据 200
7.5.1 Sqoop简介 200
7.5.2 CDH 5.7.0中的Sqoop 203
7.5.3 使用Sqoop抽取数据 203
7.5.4 Sqoop优化 207
7.6 小结 208
第8章 数据转换与装载
8.1 数据清洗 210
8.2 Hive简介 214
8.2.1 Hive的体系结构 215
8.2.2 Hive的工作流程 216
8.2.3 Hive服务器 218
8.2.4 Hive客户端 221
8.3 初始装载 231
8.4 定期装载 236
8.5 Hive优化 246
8.6 小结 254
第9章 定期自动执行ETL作业
9.1 crontab 256
9.2 Oozie简介 260
9.2.1 Oozie的体系结构 260
9.2.2 CDH 5.7.0中的Oozie 262
9.3 建立定期装载工作流 262
9.4 建立协调器作业定期自动执行工作流 271
9.5 Oozie优化 275
9.6 小结 276
第10章 维度表技术
10.1 增加列 278
10.2 维度子集 285
10.3 角色扮演维度 292
10.4 层次维度 298
10.4.1 固定深度的层次 299
10.4.2 递归 302
10.4.3 多路径层次 310
10.4.4 参差不齐的层次 312
10.5 退化维度 313
10.6 杂项维度 316
10.7 维度合并 323
10.8 分段维度 329
10.9 小结 335
第11章 事实表技术
11.1 事实表概述 336
11.2 周期快照 337
11.3 累积快照 343
11.4 无事实的事实表 349
11.5 迟到的事实 354
11.6 累积度量 360
11.7 小结 366
第12章 联机分析处理
12.1 联机分析处理简介 367
12.1.1 概念 367
12.1.2 分类 368
12.1.3 性能 371
12.2 Impala简介 371
12.3 Hive、SparkSQL、Impala比较 377
12.3.1 Spark SQL简介 377
12.3.2 Hive、Spark SQL、Impala比较 379
12.3.3 Hive、Spark SQL、Impala性能对比 382
12.4 联机分析处理实例 387
12.5 Apache Kylin与OLAP 399
12.5.1 Apache Kylin架构 399
12.5.2 Apache Kylin安装 401
12.6 小结 407
第13章 数据可视化
13.1 数据可视化简介 408
13.2 Hue简介 410
13.2.1 Hue功能快速预览 411
13.2.2 配置元数据存储 412
13.3 Zeppelin简介 415
13.3.1 Zeppelin架构 415
13.3.2 Zeppelin安装配置 416
13.3.3 在Zeppelin中添加MySQL翻译器 421
13.4 Hue、Zeppelin比较 425
13.5 数据可视化实例 426
13.6 小结 434
|
| 內容試閱：
|
前 言
似乎所有人嘴边都挂着大数据这个词。围绕大数据这个主题开展的讨论几乎已经完全压倒了传统数据仓库的风头。某些大数据狂热者甚至大胆预测，在不久的将来，所有企业数据都将由一个基于Apache Hadoop 的系统托管，企业数据仓库（EDW）终将消亡。无论如何，传统数据仓库架构仍在不断发展演化，这一点不容置疑。一年来，我一直在撰写相关的文章和博客，但它真的会消亡吗？我认为几率很小。实际上，尽管所有人都在讨论某种技术或者架构可能会胜过另一种技术或架构，但IBM有着不同的观点。在IBM，他们更倾向于从Hadoop 与数据仓库密切结合这个角度来探讨问题，两者可以说是天作之合。试想一下，对于采用传统数据仓库的企业而言，大数据带来的机会就是能够利用过去无法通过传统仓库架构利用的数据，但传统数据仓库为什么不能承担起这个责任？原因是多方面的。首先，数据仓库的传统架构方式采用业务系统中的结构化数据，用它们来分析有关业务的方方面面，对这些数据进行清理、建模、分布、治理和维护，以便执行历史分析。无论是从结构方面考虑，还是从数据摄取速率方面考虑，我们在数据仓库中存储的数据都是可预测的。相比之下，大数据是不可预测的。大数据的结构多种多样，对于 EDW 来说数量过于庞大。尤其要考虑的是，我们更习惯于浏览大量数据来查找真正需要的信息。不久之后可能又会决定丢弃这些数据，在某些情况下，这些数据的保存期限可能会更短。如果我们决定保留所有这些数据，则需要使用比 EDW 更经济的解决方案来存储非结构化数据，以便将来使用这些数据进行历史分析，这也是将 Hadoop 与数据仓库结合使用的另一个论据。本书通过简单而完整的示例，论述了在Hadoop平台上设计和实现数据仓库的方法。将传统数据仓库建模与SQL开发的简单性与大数据技术相结合，快速、高效地建立可扩展的数据仓库及其应用系统。本书共13章，主要内容包括数据仓库、Hadoop及其生态圈的相关概念，使用Sqoop从关系数据库全量或增量抽取数据，使用Hive进行数据转换和装载处理，使用Oozie调度作业周期性执行，使用Impala进行快速联机数据分析，使用Hue将数据可视化，以及数据仓库中的渐变维（SCD）、代理键、角色扮演维度、层次维度、退化维度、无事实的事实表、迟到的事实、累积的度量等常见问题在Hadoop上的处理等。本书适合数据库管理员、大数据技术人员、Hadoop技术人员、数据仓库技术人员，也适合高等院校和培训学校相关专业的师生教学参考。最后，感谢清华大学出版社图格事业部的编辑们，他们的辛勤工作使得本书尽早与读者见面。编者2017年6月
第 9 章? 定期自动执行ETL作业 ?
一旦数据仓库开始使用，就需要不断从源系统给数据仓库提供新数据。为了确保数据流的稳定，需要使用所在平台上可用的任务调度器来调度ETL定期执行。调度模块是ETL系统必不可少的组成部分，它不但是数据仓库的基本需求，也对项目的成功起着举足轻重的作用。操作系统一般都为用户提供调度作业的功能，如Windows的计划任务和UNIXLinux的cron系统服务。绝大多数Hadoop系统都运行在Linux之上，因此本章详细讨论两种Linux上定时自动执行ETL作业的方案。一种是经典的crontab，这是操作系统自带的功能，二是Hadoop生态圈中的Oozie组件。为了演示Hadoop对数据仓库的支持能力，我们的示例将使用后者实现ETL执行自动化。9.1crontab上一章我们已经准备好用于定期装载的regular_etl.sh shell脚本文件，可以很容易地用crontab命令创建一个任务，定期运行此脚本。# 修改文件属性为可执行chmod 755 rootregular_etl.sh# 编辑crontab文件内容crontab -e# 添加如下一行，指定每天2点执行定期装载作业，然后保存退出0 2 * * * rootregular_etl.sh这就可以了，需要用户做的就是如此简单，其他的事情交给cron系统服务去完成。提供cron服务的进程名为crond，这是Linux下一个用来周期性执行某种任务或处理某些事件的守护进程。当安装完操作系统后，会自动启动crond进程，它每分钟会定期检查是否有要执行的任务，如果有则自动执行该任务。Linux下的任务调度分为两类，系统任务调度和用户任务调度。? 系统任务调度：系统需要周期性执行的工作，比如写缓存数据到硬盘、日志清理等。在etc目录下有一个crontab文件，这个就是系统任务调度的配置文件。? 用户任务调度：用户要定期执行的工作，比如用户数据备份、定时邮件提醒等。用户可以使用crontab命令来定制自己的计划任务。所有用户定义的crontab文件都被保存在 varspoolcron目录中，其文件名与用户名一致。1. crontab权限Linux系统使用一对allowdeny文件组合判断用户是否具有执行crontab的权限。如果用户名出现在etccron.allow文件中，则该用户允许执行crontab命令。如果此文件不存在，那么如果用户名没有出现在etccron.deny文件中，则该用户允许执行crontab命令。如果只存在cron.deny文件，并且该文件是空的，则所有用户都可以使用crontab命令。如果这两个文件都不存在，那么只有root用户可以执行crontab命令。allowdeny文件由每行一个用户名构成。2. crontab命令通过crontab 命令，我们可以在固定间隔的时间点执行指定的系统指令或 shell脚本。时间间隔的单位可以是分钟、小时、日、月、周及以上的任意组合。crontab 命令格式如下：crontab [-u user] filecrontab [-u user] [ -e | -l | -r ]说明：? -u user：用来设定某个用户的crontab服务，此参数一般由root用户使用。? file：file是命令文件的名字，表示将file作为crontab的任务列表文件并载入crontab。如果在命令行中没有指定这个文件，crontab命令将接受标准输入，通常是键盘上键入的命令，并将它们载入crontab。? -e：编辑某个用户的crontab文件内容。如果不指定用户，则表示编辑当前用户的crontab文件。如果文件不存在，则创建一个。? -l：显示某个用户的crontab文件内容，如果不指定用户，则表示显示当前用户的crontab文件内容。? -r：从varspoolcron目录中删除某个用户的crontab文件，如果不指定用户，则默认删除当前用户的crontab文件。注意：如果不经意地输入了不带任何参数的crontab命令，不要使用Control-d退出，因为这会删除用户所对应的crontab文件中的所有条目。代替的方法是用Control-c退出。3. crontab文件用户所建立的crontab文件中，每一行都代表一项任务，每行的每个字段代表一项设置。它的格式共分为六个字段，前五段是时间设定段，第六段是要执行的命令段，格式如下：.---------------- 分钟（0 - 59）| .------------- 小时（0 - 23）| | .---------- 日期（1 - 31）| | | .------- 月份（1 - 12）| | | | .---- 星期（0 - 6，代表周日到周一）| | | | |* * * * * 要执行的命令，可以是系统命令，也可以是自己编写的脚本文件。在以上各个时间字段中，还可以使用如下特殊字符：? 星号（*）：代表所有可能的值，例如月份字段如果是星号，则表示在满足其他字段的制约条件后每月都执行该命令操作。? 逗号（,）：可以用逗号隔开的值指定一个列表范围，例如，1,2,5,7,8,9。? 中杠（-）：可以用整数之间的中杠表示一个整数范围，例如2-6表示2,3,4,5,6。? 正斜线（）：可以用正斜线指定时间的间隔频率，例如0-232表示每两小时执行一次。同时正斜线可以和星号一起使用，例如*10，如果用在分钟字段，表示每十分钟执行一次。注意，日期和星期字段都可以指定哪天执行，如果两个字段都设置了，则执行的日期是两个字段的并集。4. crontab示例# 每1分钟执行一次command* * * * * command# 每小时的第3和第15分钟执行3,15 * * * * command# 在上午8点到11点的第3和第15分钟执行3,15 8-11 * * * command# 每隔两天的上午8点到11点的第3和第15分钟执行3,15 8-11 *2 * * command# 每个星期一的上午8点到11点的第3和第15分钟执行3,15 8-11 * * 1 command# 每晚的21：30执行30 21 * * * command# 每月1、10、22日的4：45执行45 4 1,10,22 * * command# 每周六、周日的1：10执行10 1 * * 6,0 command# 每天18：00至23：00之间每隔30分钟执行0,30 18-23 * * * command# 每星期六的晚上11：00执行0 23 * * 6 command# 每一小时执行一次* *1 * * * command# 晚上11点到早上7点之间，每隔一小时执行一次* 23-71 * * * command# 每月的4号与每周一到周三的11点执行0 11 4 * 1-3 command# 一月一号的4点执行0 4 1 1 * command# 每小时执行etccron.hourly目录内的脚本01 * * * * root run-parts etccron.hourly说明：run-parts会遍历目标文件夹，执行第一层目录下具有可执行权限的文件。5. crontab环境有时我们创建了一个crontab任务，但是这个任务却无法自动执行，而手动执行脚本却没有问题，这种情况一般是由于在crontab文件中没有配置环境变量引起的。cron从用户所在的主目录中使用shell调用需要执行的命令。cron为每个shell提供了一个默认的环境，Linux下的定义如下：SHELL=binbashPATH=sbin：bin：usrsbin：usrbinMAILTO=用户名HOME=用户主目录在crontab文件中定义多个调度任务时，需要特别注意的一个问题就是环境变量的设置，因为我们手动执行某个脚本时，是在当前shell环境下进行的，程序能找到环境变量；而系统自动执行任务调度时，除了默认的环境，是不会加载任何其他环境变量的。因此就需要在crontab文件中指定任务运行所需的所有环境变量。不要假定cron知道所需要的特殊环境，它其实并不知道。所以用户要保证在shell脚本中提供所有必要的路径和环境变量，除了一些自动设置的全局变量。以下三点需要注意：? 脚本中涉及文件路径时写绝对路径；? 脚本执行要用到环境变量时，通过source命令显式引入，例如：#!binshsource etcprofile? 当手动执行脚本没问题，但是crontab不执行时，可以尝试在crontab中直接引入环境变量解决问题，例如：0 * * * * . etcprofile;binsh pathtomyscript.sh6. 重定向输出邮件默认时，每条任务调度执行完毕，系统都会将任务输出信息通过电子邮件的形式发送给当前系统用户。这样日积月累，日志信息会非常大，可能会影响系统的正常运行。因此，将每条任务进行重定向处理非常重要。可以在crontab文件中设置如下形式，忽略日志输出：0 *3 * * * usrlocalmyscript.sh devnull 2&1devnull 2&1表示先将标准输出重定向到devnull，然后将标准错误重定向到标准输出。由于标准输出已经重定向到了devnull，因此标准错误也会重定向到devnull，这样日志输出问题就解决了。7. 生成日志文件可以将crontab执行任务的输出信息重定向到一个自定义的日志文件中，例如：8 * * * rm homesomeusertmp* homesomeusercronlogsclean_tmp_dir.log9.2Oozie简介除了利用操作系统提供的功能以外，Hadoop生态圈的工具也可以完成同样的调度任务，而且更灵活，这个组件就是Oozie。Oozie是一个管理Hadoop作业、可伸缩、可扩展、可靠的工作流调度系统，它内部定义了三种作业：工作流作业、协调器作业和Bundle作业。工作流作业是由一系列动作构成的有向无环图（DAGs），协调器作业是按时间频率周期性触发Oozie工作流的作业，Bundle管理协调器作业。Oozie支持的用户作业类型有Java map-reduce、Streaming map-reduce、Pig、 Hive、Sqoop和Distcp，及其Java程序和shell脚本或命令等特定的系统作业。Oozie项目经历了三个主要阶段。第一版Oozie是一个基于工作流引擎的服务器，通过执行Hadoop MapReduce和Pig作业的动作运行工作流作业。第二版Oozie是一个基于协调器引擎的服务器，按时间和数据触发工作流执行。它可以基于时间（如每小时执行一次）或数据可用性（如等待输入数据完成后再执行）连续运行工作流。第三版Oozie是一个基于Bundle引擎的服务器。它提供更高级别的抽象，批量处理一系列协调器应用。用户可以在bundle级别启动、停止、挂起、继续、重做协调器作业，这样可以更好地简化操作控制。使用Oozie主要基于以下两点原因：? 在Hadoop中执行的任务有时候需要把多个MapReduce作业连接到一起执行，或者需要多个作业并行处理。Oozie可以把多个MapReduce作业组合到一个逻辑工作单元中，从而完成更大型的任务。? 从调度的角度看，如果使用crontab的方式调用多个工作流作业，可能需要编写大量的脚本，还要通过脚本来控制好各个工作流作业的执行时序问题，不但不好维护，而且监控也不方便。基于这样的背景，Oozie提出了Coordinator的概念，它能够将每个工作流作业作为一个动作来运行，相当于工作流定义中的一个执行节点，这样就能够将多个工作流作业组成一个称为Coordinator Job的作业，并指定触发时间和频率，还可以配置数据集、并发数等。9.2.1Oozie的体系结构Oozie的体系结构如图9-1所示。图9-1Oozie体系结构Oozie是一种Java Web应用程序，它运行在Java Servlet容器，即Tomcat中，并使用数据库来存储以下内容：? 工作流定义。? 当前运行的工作流实例，包括实例的状态和变量。Oozie工作流是放置在DAG（有向无环图 Direct Acyclic Graph）中的一组动作，例如，Hadoop的MapReduce作业、Pig作业等。DAG控制动作的依赖关系，指定了动作执行的顺序。Oozie使用hPDL这种XML流程定义语言来描述这个图。hPDL是一种很简洁的语言，它只会使用少数流程控制节点和动作节点。控制节点会定义执行的流程，并包含工作流的起点和终点（start、end和fail节点）以及控制工作流执行路径的机制（decision、fork和join节点）。动作节点是实际执行操作的部分，通过它们工作流会触发执行计算或者处理任务。Oozie为以下类型的动作提供支持：Hadoop MapReduce、Hadoop HDFS、Pig、Java和Oozie的子工作流。而SSH动作已经从Oozie schema 0.2之后的版本中移除了。所有由动作节点触发的计算和处理任务都不在Oozie中运行。它们是由Hadoop的MapReduce框架执行的。这种低耦合的设计方法让Oozie可以有效利用Hadoop的负载平衡、灾难恢复等机制。这些任务主要是串行执行的，只有文件系统动作例外，它是并行处理的。这意味着对于大多数工作流动作触发的计算或处理任务类型来说，在工作流操作转换到工作流的下一个节点之前都需要等待，直到前面节点的计算或处理任务结束了之后才能够继续。Oozie可以通过两种不同的方式来检测计算或处理任务是否完成，这就是回调和轮询。当Oozie启动了计算或处理任务时，它会为任务提供唯一的回调URL，然后任务会在完成的时候发送通知给这个特定的URL。在任务无法触发回调URL的情况下（可能是因为任何原因，比方说网络闪断），或者当任务的类型无法在完成时触发回调URL的时候，Oozie有一种机制，可以对计算或处理任务进行轮询，从而能够判断任务是否完成。Oozie工作流可以参数化，例如在工作流定义中使用像${inputDir}之类的变量等。在提交工作流操作的时候，我们必须提供参数值。如果经过合适地参数化，比如使用不同的输出目录，那么多个同样的工作流操作可以并发执行。一些工作流是根据需要触发的，但是大多数情况下，我们有必要基于一定的时间段、数据可用性或外部事件来运行它们。Oozie协调系统（Coordinator system）让用户可以基于这些参数来定义工作流执行计划。Oozie协调程序让我们可以用谓词的方式对工作流执行触发器进行建模，谓词可以是时间条件、数据条件、内部事件或外部事件。工作流作业会在谓词得到满足的时候启动。不难看出，这里的谓词，其作用和SQL语句的WHERE子句中的谓词类似，本质上都是在满足某些条件时触发某种事件。有时，我们还需要连接定时运行、但时间间隔不同的工作流操作。多个以不同频率运行的工作流的输出会成为下一个工作流的输入。把这些工作流连接在一起，会让系统把它作为数据应用的管道来引用。Oozie协调程序支持创建这样的数据应用管道。9.2.2CDH 5.7.0中的OozieCDH 5.7.0中，Oozie的版本是4.1.0，其元数据存储使用MySQL（4.4节CDH安装中有相关配置）。关于CDH 5.7.0中Oozie的属性，参考以下链接：https：www.cloudera.comdocumentationenterpriselatesttopicscm_props_cdh570_oozie.html9.3建立定期装载工作流对于刚接触Oozie的用户来说，前面介绍的概念过于抽象，不易理解，那么就让我们一步步创建销售订单示例ETL的工作流，在实例中学习Oozie的特性和用法。1. 修改资源配置Oozie运行需要使用较高的内存资源，因此要将以下两个YARN参数的值调大：? yarn.nodemanager.resource.memory-mb：NodeManage总的可用物理内存。? yarn.scheduler.maximum-allocation-mb：一个MapReduce任务可申请的最大内存。如果分配的内存不足，在执行工作流作业时会报类似下面的错误：org.apache.oozie.action.ActionExecutorException： JA009： org.apache.hadoop.yarn.exceptions.InvalidResourceRequestException： Invalid resource request, requested memory max configured, requestedMemory=1536, maxMemory=1500我们的实验环境中，每个Hadoop节点所在虚拟机的总物理内存为8GB，所以把这两个参数都设置为2GB。修改的方法有两种，可以编辑yarn-site.xml文件里的属性，如：yarn.nodemanager.resource.memory-mb 2000 yarn.scheduler.maximum-allocation-mb 2000或者在Cloudera Manager中修改，yarn.nodemanager.resource.memory-mb参数在YARN服务的NodeManager范围里，yarn.scheduler.maximum-allocation-mb参数在YARN服务的ResourceManager范围里。无论使用哪种方法，修改后都需要保存更改并重启Hadoop集群。2. 启用Oozie Web Console默认安装CDH时，Oozie Web Console是禁用的，为了后面方便监控Oozie作业的执行，需要将其改为启用状态。启用 Oozie 服务器 Web 控制台属性在Oozie服务的Oozie Server Default Group里。具体的做法是： 下载ext-2.2包，解压缩到Oozie服务器实例所在节点的varliboozie目录下。 登录Cloudera Manager管理控制台，进入Oozie服务页面。 单击配置标签。 定位启用 Oozie 服务器 Web 控制台属性，或者在搜索框中输入该属性名查找。 选择启用 Oozie 服务器 Web 控制台的复选框。 单击保存更改按钮提交所做的修改。 重启Oozie服务。3. 启动Sqoop的share metastore service定期装载工作流需要用Oozie调用Sqoop执行，这需要开启Sqoop的元数据共享存储，命令如下：sqoop metastore tmpsqoop_metastore.log 2&1 &metastore工具配置Sqoop作业的共享元数据信息存储，它会在当前主机启动一个内置的HSQLDB共享数据库实例。客户端可以连接这个metastore，这样允许多个用户定义并执行metastore中存储的Sqoop作业。metastore库文件的存储位置由sqoop-site.xml中的sqoop.metastore.server.location属性配置，它指向一个本地文件。如果不设置这个属性，Sqoop元数据默认存储在~.sqoop目录下。如果碰到用Oozie工作流执行Sqoop命令是成功的，但执行Sqoop作业却失败的情况，可以参考Oozie系列3之解决Sqoop Job无法运行的问题这篇文章。该文中对这个问题有很详细的分析，并提供了解决方案，其访问地址是：http：www.lamborryan.comoozie-sqoop-fail4. 连接metastore重建sqoop job我们在上一章中建立了一个增量抽取sales_order表数据的Sqoop作业，但其元数据并没有存储在shared metastore里，所以需要使用以下的命令进行重建：last_value=`sqoop job --show myjob_incremental_import | grep incremental.last.value | awk ''{print $3}''` sqoop job --delete myjob_incremental_import sqoop job \ --meta-connect jdbc：hsqldb：hsql：cdh2：16000sqoop \ --create myjob_incremental_import \ -- \ import \ --connect "jdbc：mysql：cdh1：3306source?useSSL=false&user=root&password=mypassword" \ --table sales_order \ --columns "order_number, customer_number, product_code, order_date, entry_date, order_amount" \ --hive-import \ --hive-table rds.sales_order \ --incremental append \ --check-column order_number \ --last-value $last_value在上面命令的第一行中，先用sqoop的--show选项查询最后一次执行定期装载后incremental.last.value的值，并将这个值赋给名为last_value的shell变量。在创建作业命令的最后一行中，--last-value选项将当前最大值作为参数。和上一章的myjob_incremental_import作业创建命令对比，会发现多了一行--meta-connect jdbc：hsqldb：hsql：cdh2：16000sqoop，就是通过这个选项将作业元数据存储到HSQLDB数据库文件中，metastore的默认端口是16000，可以用sqoop.metastore.server.port属性设置为其他端口号。创建作业前，需要使用--delete参数先删除已经存在的同名作业。5. 定义工作流建立内容如下的workflow.xml文件： ${jobTracker} ${nameNode} import --connect jdbc：mysql：cdh1：3306source?useSSL=false --username root --password mypassword --table customer --hive-import --hive-table rds.customer --hive-overwrite tmphive-site.xml#hive-site.xml tmpmysql-connector-java-5.1.38-bin.jar#mysql-connector-java-5.1.38-bin.jar ${jobTracker} ${nameNode} import --connect jdbc：mysql：cdh1：3306source?useSSL=false --username root --password mypassword --table product --hive-import --hive-table rds.product --hive-overwrite tmphive-site.xml#hive-site.xml tmpmysql-connector-java-5.1.38-bin.jar#mysql-connector-java-5.1.38-bin.jar ${jobTracker} ${nameNode} job --exec myjob_incremental_import --meta-connect jdbc：hsqldb：hsql：cdh2：16000sqoop tmphive-site.xml#hive-site.xml tmpmysql-connector-java-5.1.38-bin.jar#mysql-connector-java-5.1.38-bin.jar ${jobTracker} ${nameNode} tmphive-site.xml tmpregular_etl.sql Sqoop failed, error message[${wf：errorMessagewf：lastErrorNode}] 这个工作流的DAG如图9-2所示。图9-2定期装载DAG上面的XML文件使用hPDL的语法定义了一个名为regular_etl的工作流。该工作流包括9个节点，其中有5个控制节点，4个动作节点：工作流的起点start、终点end、失败处理节点fail（DAG图中未显示），两个执行路径控制节点fork-node和joining，三个并行处理的Sqoop动作节点sqoop-customer、sqoop-product、sqoop-sales_order用作数据抽取，一个Hive动作节点hive-node用作数据转换与装载。Oozie的工作流节点分为控制节点和动作节点两类。控制节点控制着工作流的开始、结束和作业的执行路径。动作节点触发计算或处理任务的执行。节点的名字必须符合[a-zA-Z][\-_a-zA-Z0-0]*这种正则表达式模式，并且不能超过20个字符。（1）控制节点控制节点又可分成两种，一种定义工作流的开始和结束，这种节点使用start、end和kill三个标签。另一种用来控制工作流的执行路径，使用decision、fork和join标签。start节点是一个工作流作业的入口，是工作流作业的第一个节点。当工作流开始时，它会自动转到start标签所标识的节点。每一个工作流定义必须包含一个start节点。end节点是工作流作业的结束，它表示工作流作业成功完成。当工作流到达这个节点时就结束了。如果在到达end节点时，还有一个或多个动作正在执行，这些动作将被kill，这种场景也被认为是执行成功。每个工作流定义必须包含一个end节点。kill节点允许一个工作流作业将自己kill掉。当工作流作业到达kill节点时，表示作业以失败结束。如果在到达kill节点时，还有一个或多个动作正在执行，这些动作将被kill。一个工作流定义中可以没有kill节点，也可以包含一个或多个kill节点。decision节点能够让工作流选择执行路径，其行为类似于一个switch-case语句，即按不同情况走不同分支。我们刚定义的工作流中没有decision节点，因此到11.1节用到decision节点时再详细讨论。fork节点将一个执行路径分裂成多个并发的执行路径。直到所有这些并发执行的路径都到达join节点后，工作流才会继续往后执行。fork与join节点必须成对出现。实际上join节点将多条并发执行路径视作同一个fork节点的子节点。（2）动作节点动作节点是实际执行操作的部分。Oozie支持很多种动作节点，包括Hive脚本、Hive Server2脚本、Pig脚本、Spark程序、Java程序、Sqoop1命令、MapReduce作业、shell脚本、HDFS命令等。ETL工作流中使用了Sqoop和Hive两种。ok和error是动作节点预定义的两个XML元素，它们通常被用来指定动作节点执行成功或失败时的下一步跳转节点。这些元素在Oozie中被称为转向元素。arg元素包含动作节点的实际参数。sqoop-customer和sqoop-product动作节点中使用arg元素指定Sqoop命令行参数。command元素表示要执行一个shell命令。在sqoop-sales_order动作节点中使用command元素指定执行Sqoop作业的命令。file和archive元素用于为执行MapReduce作业提供有效的文件和包。为了避免不必要的混淆，最好使用HDFS的绝对路径。我们的三个Sqoop动作节点使用这两个属性为Sqoop指定Hive的配置文件和MySQL JDBC驱动包的位置。必须包含这两个属性Sqoop动作节点才能正常执行。script元素包含要执行的脚本文件，这个元素的值可以被参数化。我们在hive-node动作节点中使用script元素指定需要执行的定期装载SQL脚本文件。（3）工作流参数化工作流定义中可以使用形式参数。当工作流被Oozie执行时，所有形参都必须提供具体的值。参数定义使用JSP 2.0的语法，参数不仅可以是单个变量，还支持函数和复合表达式。参数可以用于指定动作节点和decision节点的配置值、XML属性值和XML元素值，但是不能在节点名称、XML属性名称、XML元素名称和节点的转向元素中使用参数。我们的工作流中使用了${jobTracker}和${nameNode}两个参数，分别指定YARN资源管理器的主机端口和HDFS NameNode的主机端口。（4）表达式语言函数Oozie的工作流作业本身还提供了丰富的内建函数，Oozie将它们统称为表达式语言函数（Expression Language Functions，简称EL函数）。通过这些函数可以对动作节点和decision节点的谓词进行更复杂的参数化。我们的工作流中使用了wf：errorMessage和wf：lastErrorNode两个内建函数。wf：errorMessage函数返回特定节点的错误消息，如果没有错误则返回空字符串。错误消息常被用于排错和通知的目的。wf：lastErrorNode函数返回最后出错的节点名称，如果没有错误则返回空字符串。6. 部署工作流这里所说的部署就是把相关文件上传到HDFS的对应目录中。我们需要上传工作流定义文件，还要上传file、archive、script元素中指定的文件。可以使用hdfs dfs -put命令将本地文件上传到HDFS，-f参数的作用是，如果目标位置已经存在同名的文件，则用上传的文件覆盖已存在的文件。hdfs dfs -put -f workflow.xml userroot hdfs dfs -put etchiveconf.cloudera.hivehive-site.xml tmp hdfs dfs -put rootmysql-connector-java-5.1.38-bin.jar tmp hdfs dfs -put rootregular_etl.sql tmp7. 建立作业属性文件到现在为止我们已经定义了工作流，也将运行工作流所需的所有文件上传到了HDFS的指定位置。但是，仍然无法运行工作流，因为还缺少关键的一步：必须定义作业的某些属性，并将这些属性值提交给Oozie。在本地目录中，我们需要创建一个作业属性文件，这里命名为job.properties，其中的内容如下：nameNode=hdfs：cdh2：8020 jobTracker=cdh2：8032 queueName=default oozie.use.system.libpath=true oozie.wf.application.path=${nameNode}user${user.name}注意，此文件不需要上传到HDFS。这里稍微解释一下每一行的含义。nameNode和jobTracker是工作流定义里面的两个形参，分别指示NameNode和YARN资源管理器的主机名端口号。工作流定义里使用的形参，必须在作业属性文件中赋值。queueName是MapReduce作业的队列名称，用于给一个特定队列命名。默认时，所有的MR作业都进入default队列。queueName主要用于给不同目的作业队列赋予不同的属性集来保证优先级。为了让工作流能够使用Oozie的共享库，要在作业属性文件中设置oozie.use.system.libpath=true。oozie.wf.application.path属性设置应用工作流定义文件的路径，在它的赋值中，${nameNode}是引用第一行的变量，${user.name}系统变量引用的是Java环境的user.name属性，通过该属性可以获得当前登录的操作系统用户名。8. 运行工作流经过一连串的配置，现在已经万事俱备，可以运行定期装载工作流了。下面的命令用于运行工作流作业。oozie是Oozie的客户端命令，job表示指定作业属性，-oozie参数指示Oozie服务器实例的URL，-config参数指示作业属性配置文件，-run告诉Oozie运行作业。oozie job -oozie http：cdh2：11000oozie -config rootjob.properties -run 此时从Oozie Web控制台可以看到正在运行的作业，如图9-3所示。图9-3运行的作业单击Active Jobs标签，会看到表格中只有一行，就是我们刚运行的工作流作业。Job Id是系统生成的作业号，它唯一标识一个作业。Name是我们在workflow.xml文件中定义的工作流名称，Status为RUNNING，表示正在运行。页面中还会显示执行作业的用户名、作业创建时间、开始时间、最后修改时间、结束时间等作业属性。单击作业所在行，可以打开作业的详细信息窗口，如图9-4所示。图9-4作业详细信息这个页面有上下两部分组成。上面是以纵向方式显示作业属性，内容和9-3所示的一行相同。下面是动作的信息。在这个表格中会列出我们定义的工作流节点。从图中可以看到节点的名称和类型，分别对应workflow.xml文件中节点定义的属性和元素，Transition表示转向的节点，对应工作流定义文件中to属性的值。从Status列可以看到节点执行的状态，图中表示正在运行sqoop-sales_order动作节点，前面的start、fork-node、sqoop-customer、sqoop-product都已执行成功，后面的joining、hive-node、end节点还没有执行到，所以图中没有显示。这个表格中只会显示已经执行或正在执行的节点。表格中还有StartTime和EndTime两列，分别表示节点的开始和结束时间，fork节点中的三个Sqoop动作是并行执行的，因此起止时间上有所交叉。单击动作所在行，可以打开动作的详细信息窗口，如图9-5所示。图9-5动作详细信息这个窗口中显示一个节点的12个相关属性。从上图中可以看到正在运行的hive-node节点的属性，注意Console URL属性，单击它右侧的图标，可以打开真正执行动作的MapReduce作业的跟踪页面，如图9-6所示。Oozie中定义的动作，实际上是作为MapReduce之上的应用来执行的。从这个页面可以看到相关MapReduce作业的属性，包括作业ID、总的MapReduce数、已完成的MapReduce数、Map和Reduce的处理进度等信息。图9-6执行动作的MapReduce作业当Oozie作业执行完，可以在图9-3所示页面的All Jobs标签页看到，Status列已经从RUNNING变为SUCCEEDED，如图9-7所示。图9-7完成的工作流可以看到，整个工作流执行了将近31分钟。细心的读者可能发现了，显示的时间点是3点。这个时间比较奇怪，它和我们手工执行工作流的时间相差了8小时。造成这个问题的原因稍后再做解释。为了验证数据是否正确，我们查看cdc_time表的数据。因为整个定期装载过程的最后一条HiveQL语句是更新cdc_time表，如果它被正确更新，说明前面的语句都成功执行了（Hive的任何一步出错都会中断退出，不会继续执行后面的语句）。查询及其结果如下所示，可以看到日期已经改为当前日期，说明定期装载工作流执行正确。0： jdbc：hive2：cdh2：10000dw select * from rds.cdc_time;OK --------------------- ------------------------ -- | cdc_time.last_load | cdc_time.current_load | --------------------- ------------------------ -- | 2016-07-11 | 2016-07-11 | --------------------- ------------------------ -- row selected 0.289 seconds9.4建立协调器作业定期自动执行工作流工作流作业通常都是以一定的时间间隔定期执行的，例如我们的定期装载ETL作业需要在每天2点执行一次。Oozie的协调器作业能够在满足谓词条件时触发工作流作业的执行。现在的谓词条件可以定义为数据可用、时间或外部事件，将来还可能扩展为支持其他类型的事件。协调器作业还有一种使用场景，就是需要关联多个周期性运行工作流作业。它们运行的时间间隔不同，前面所有工作流的输出一起成为下一个工作流的输入。例如，有5个工作流，前4个顺序执行，每隔15分钟运行一个，第5个工作流每隔60分钟运行一次，前面4个工作流的输出共同构成第5个工作流的输入。这种工作流链有时被称为数据应用管道。Oozie协调器系统允许用户定义周期性执行的工作流作业，还可以定义工作流之间的依赖关系。和工作流作业类似，定义协调器作业也要创建配置文件和属性文件。1. 建立协调器作业配置文件建立内容如下的coordinator.xml文件： ${workflowAppUri} jobTracker ${jobTracker} nameNode ${nameNode} queueName ${queueName} 在上面的XML文件中，我们定义了一个名为regular_etl-coord的协调器作业。coordinator-app元素的frequency属性指定工作流运行的频率。我们用Oozie提供的${coord：daysint n} EL函数给它赋值，该函数返回n天的分钟数，示例中的n为1，也就是每隔1440分钟运行一次工作流。start属性指定起始时间，end属性指定终止时间，timezone属性指定时区。这三个属性都赋予形参，在属性文件中定义参数值。xmlns属性值是常量字符串uri：oozie：coordinator：0.1。${workflowAppUri}形参指定应用的路径，就是工作流定义文件所在的路径。${jobTracker}、${nameNode}和${queueName}形参与前面workflow.xml工作流文件中的含义相同。2. 建立协调器作业属性文件建立内容如下的job-coord.properties文件：nameNode=hdfs：cdh2：8020 jobTracker=cdh2：8032 queueName=default oozie.use.system.libpath=true oozie.coord.application.path=${nameNode}user${user.name} timezone=UTC start=2016-07-11T06：00Z end=2020-12-31T07：15Z workflowAppUri=${nameNode}user${user.name}这个文件定义协调器作业的属性，并给协调器作业定义文件中的形参赋值。该文件的内容与工作流作业属性文件的内容类似。oozie.coord.application.path参数指定协调器作业定义文件所在的HDFS路径。需要注意的是，start、end变量的赋值与时区有关。Oozie默认的时区是UTC，而且即便在属性文件中设置了timezone=GMT 0800也不起作用。我们给出的起始时间点是2016-07-11T06：00Z，实际要加上8个小时，才是我们所在时区真正的运行时间，即14点（为了便于及时验证运行效果，设置这个时间点）。因此在定义时间点时一定要注意时间的计算问题，这也就是在前面的工作流演示中，控制台页面里看到的时间是凌晨3点的原因，真实时间是上午11点。3. 部署协调器作业执行下面的命令将coordinator.xml文件上传到oozie.coord.application.path参数指定的HDFS目录中。hdfs dfs -put -f coordinator.xml userroot 4. 运行协调器作业执行下面的命令运行协调器作业：oozie job -oozie http：cdh2：11000oozie -config rootjob-coord.properties -run 此时从Oozie Web 控制台可以看到准备运行的协调器作业，作业的状态为PREP，如图9-8所示。PREP状态表示已经将作业提交给Oozie，并且准备运行。图9-8提交协调器作业当时间到达14：00时，满足了时间谓词条件，协调器作业开始运行，作业状态由PREP变为RUNNING，如图9-9所示。图9-9运行协调器作业单击作业所在行，可以打开协调器作业的详细信息窗口，如图9-10所示。图9-10协调器作业详细信息单击协调器作业所在行，可以打开调用的工作流作业的详细信息窗口，如图9-11所示。这个页面和图9-4所示的是同一个页面，但这时在Parent Coord字段显示了协调器作业的Job Id。图9-11工作流作业的详细信息9.5Oozie优化Oozie本身并不真正运行工作流中的动作，它在执行工作流中的动作节点时，会先启动一个发射器（Launcher）。发射器类似于一个YARN作业，由一个AppMaster和一个Mapper组成，只负责运行一些基本的命令，如为执行Hive CLI胖客户端的hive、Hive Beeline瘦客户端的hive2、Pig CLI、Sqoop、Spark Driver、Bash shell等。然后，由这些命令产生一系列真正执行工作流动作的YARN作业。值得注意的是，YARN并不知道发射器和它所产生的作业之间的依赖关系，这在hive2动作中表现得尤为明显。hive2动作的发射器连接到HiveServer2，然后HiveServer2产生动作相关的作业。知道了Oozie的运行机制，就可以有针对性地优化Oozie工作流的执行了。下面以Hive动作为例进行说明。1. 减少给发射器作业分配的资源发射器作业只需要一个很小的调度（记住只有一个Mapper），因此它的AppMaster所需资源参数值应该设置得很低，以避免因消耗过多内存阻碍了后面工作流队列的执行。可以通过配置以下动作属性值修改发射器使用的资源。? oozie.launcher.yarn.app.mapreduce.am.resource.mb：发射器使用的总内存大小。? oozie.launcher.yarn.app.mapreduce.am.command-opts：需要在Oozie命令行显式地使用-Xmx参数限制Java堆栈的大小，典型地配置为80%的物理内存。如果设置的太低，可能出现OutOfMemory错误；如果太高，则YARN可能会因为限额使用不当杀死Java容器。2. 减少给hive2发射器作业分配的资源类似地，配置以下动作属性值：? oozie.launcher.mapreduce.map.memory.mb? oozie.launcher.mapreduce.map.java.opts3. 利用YARN队列名如果能够获得更高级别的YARN队列名称，可以为发射器配置oozie.launcher.mapreduce. job.queuename属性。对于实际的Hive查询，可以如下配置：? 在Oozie动作节点中设置mapreduce.job.queuename属性。这种方法仅对hive动作有效。? 在HiveQL脚本开头插入set mapreduce.job.queuename = *** ;命令。这种方法对hive和hive2动作都起作用。4. 设置Hive查询的AppMaster资源如果默认的AppMaster资源对于实际的Hive查询来说太大了，可以修改它们的大小：? 在Oozie动作节点中设置yarn.app.mapreduce.am.resource.mb和yarn.app.mapreduce.am. command-opts属性，或者tez.am.resource.memory.mb和tez.am.launch.cmd-opts属性（当Hive使用了Tez执行引擎时）。这种方法仅对hive动作有效。? 在HiveQL脚本开头插入设置属性的set命令。这种方法对hive和hive2动作都起作用。注意，对于上面的1、2、4条，不能配置低于yarn.scheduler.minimum-allocation-mb的值。5. 合并HiveQL脚本可以将某些步骤合并到同一个HiveQL脚本中，这会降低Oozie轮询YARN的开销。Oozie会向YARN询问一个查询是否结束，如果是就启动另一个发射器，然后该发射器启动另一个Hive会话。当然，对于出现查询出错的情况，这种合并做法的控制粒度较粗，可能在重新启动动作前需要做一些手工清理的工作。6. 并行执行多个步骤在拥有足够YARN资源的前提下，尽量将可以并行执行的步骤放置到Oozie ForkJoin的不同分支中。7. 使用Tez计算框架在很多场景下，Tez计算框架比MapReduce效率更高。例如，Tez会为Map和Reduce步骤重用同一个YARN容器，这对于连续的查询将降低YARN的开销，同时减少中间处理的磁盘IO。9.6小结（1）cron服务是Linux下用来周期性地执行某种任务或处理某些事件的系统服务，默认安装并启动。（2）通过crontab 命令可以创建、编辑、显示或删除crontab文件。（3）crontab文件有固定的格式，其内容定义了要执行的操作，可以是系统命令，也可以是用户自己编写的脚本文件。（4）crontab执行要注意环境变量的设置。（5）Oozie是一个管理Hadoop作业、可伸缩、可扩展、可靠的工作流调度系统，它内部定义了三种作业：工作流作业、协调器作业和Bundle作业。（6）Oozie的工作流定义中包含控制节点和动作节点。控制节点控制着工作流的开始、结束和作业的执行路径，动作节点触发计算或处理任务的执行。（7）Oozie的协调器作业能够在满足谓词条件时触发工作流作业的执行。现在的谓词条件可以定义为数据可用、时间或外部事件。（8）配置协调器作业的时间触发条件时，一定要注意进行时区的换算。（9）通过适当配置Oozie动作的属性值，可以提高工作流的执行效率。
|
|
購物車/收銀台(0) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
