起因

隔壁 infra team 没有用一个统一的管理工具去管理cluster，每次来了一批新机器都是用脚本配置环境的，如果脚本有改动，每个批次的机器的环境就不一样了，同样的程序在不同的机器上的执行结果可能不一样。目前Ocean CI 上有2/3的机器是hadoop 身份配置的，剩下的都是以yarn的身份起来的。我这次的任务就是把cluster上的数据拷到s3上。我们最初的想法是用写个简单的shell脚本扔到oozie里面，但是发现当oozie job deploy后，在不同的机器上，起shell的身份不同，若果是yarn的身份起来的话，读取目录很有可能没有权限，这样无论是读写都会出现问题。

理论

我们去找他们组的人交流这个问题，他们是强烈不建议我们使用shell的。当然如果cluster 上千台机器的配置都是一样的，就不会出现这样的问题。但是不用shell的话，我们需要重新dev。职场就是这样，大家多多少少都在推卸责任，如果你在职场上没有见到dirty的事情，那么必定是有人替你抵挡住dirty的事情。僵持不下。我们有两种back up plan。

  • oozie 的distcp action
  • java

整体来说oozie的distcp action 要简单，但是没有谁用过，我们还有配置额外的参数，主要是调mapper的数量，默认是20-30个mapper，数据量一大，20-30个mapper肯定忙不过来。java的方法配置的东西很多，Sijia 那边有类似的code可以看看。两边的effort可能差不多。想着以后说不定也遇到这种情况，从长期来开还是explore oozie的方法比较好。

dev

遇到的问题还是挺多的，有针对性的列几点

  1. fs:exists(string path): 注意要用concate 连接起来，variable的话直接用variable,不需要 ${variable}.
  2. distcp paramaters: 参考下面code
  3. Dfs.s3n.awsAccessKeyId=${s3_key}: s3_key 和 s3_sercret 初始化的时候不能带引号
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<start to="decision"/>
<decision name="decision">
  <switch>
    <case to="data-distcp">${fs:exists(concate(nameNode,status_src_check))}</case>
    <default to="skip-trigger-distcp"/>
  </switch>
</decision>
<action name="data-distcp">
  <distcp xmlns="uir:oozie:distcp-action:0.2">
    <arg>-Dfs.s3n.awsAccessKeyId=${s3_key}</arg>
    <arg>-Dfs.s3n.awsSecretAccessKey=${s3_secret}</arg>
    <arg>-m</arg>
    <arg>300</arg>
    <arg>-update</arg>
    <arg>${nameNode1}/${input}</arg>
    <arg>${nameNode2}/${output}</arg>
  </distcp>
  <ok to="status-distcp"/>
  <error to="data-fail"/>
</action>

life