Oozie 워크플로 구성

앞서 본 바와 같이 우지의 워크플로는 action 노드와 control 노드로 구성된다. 여기서는 이를 좀 더 자세히 살펴본다. action 노드란 각각의 실제 작업단위(workflow task)를 말하며 control 노드는 위의 여러 action들이 어떤 조건에 의해 어떤 순서로 진행될 것인지를 지정한다. 유의할 것은 action 노드에 의해 실시되는 모든 작업(computation task)은 기본적으로 하둡의 맵리듀스 프레임워크 속에서 진행되므로 실제 작업은 우지와는 별개의 것으로 수행된다는 점이다. 즉 우지의 워크플로 action은 원격 시스템에서의 작업(job) 형태로 수행되고, 작업이 완료되면 해당 원격시스템은 우지를 호출(callback)해 그 작업이 완료됐음을 알려준다. 우지는 이러한 작업완료 통보를 받은 후 지정돼있던 다음 작업을 진행하도록 조치한다. 우지는 callback 또는 polling 두 가지 방식으로 이들 작업 진행상태를 파악한다. 예컨대 특정 작업이 완료됐다면, 우지는 HTTP callback을 통해 클라이언트에게 완료상태(workflow status)을 통보한다.

action 노드

actioin 노드에는 다음과 같은 것들이 포함된다.

• 하둡 맵리듀스 작업 수행
• 하둡 파일시스템 (HDFS)으로 파일 이동
• Pig 프로그램 수행
• Java 프로그램 수행
• Sqoop를 이용해 데이터를 import
• 기타 각종의 sub-workflow와 custom Java 코드

control 노드

control 노드에는 다음과 같은 것들이 있다.

• start 노드: 워크플로 job의 시작을 지정한다.
• end 노드: 워크플로 job의 종료를 지정한다.
• decision 노드: 워크플로 job의 진행 중 분기를 위한 조건을 규정한다.
• kill 노드: 진행 중인 job을 정지시킨다.
• error 노드: 작업 흐름의 진행 중 문제가 발생했을 때 이를 오류로 규정하고 해당사항을 알려준다.

[그림 Ⅱ-4-6] 우지의 작업흐름과 workflow.xml 파일의 작성

이하에서는 workflow.xml에서 주요 control 노드를 실제로 정의하는 방법을 살펴본다.

start 노드

<workflow-app>과 </workflow-app> 태그는 이 설정파일의 시작과 끝을 나타낸다. 그리고 <start to=” “> 태그는 이 설정파일에 의한 우지 워크플로 프로그램의 시작점(entry point)을 표시한다.
위에서는 startdatafeed라는 action 노드가 1차적으로 수행되도록 설정했다.

end 노드

<end name=” “> 태그는 end 노드다. 즉 이 단계에 이르면 성공적으로 작업이 완료됐음을 의미한다. 모든 워크플로 정의 파일은 항상 end 노드로 끝맺어야 한다.

decision 노드

수행상의 경로를 결정하기 위한 조건을 규정한다. 이는 일반 프로그램에서의 switch-case 문과 유사하다.

fork-join 노드

fork 노드는 하나의 프로세스를 여러 개의 프로세스로 복제해 분기한다. join 노드는 이러한 fork 노드에 의한 여러 프로세스가 모두 완료될 때까지 기다렸다가 하나로 합치는 것을 말한다.

Oozie 작업 순서

우지에서 작업의 흐름을 지정하고 이용하기 위해서는 HDFS 디렉터리에 다음 파일을 설치(deploy)해야 한다.

• workflow.xml
• config-default.xml
• lib 서브디렉터리: 여기에는 워크플로 action들이 이용할 classes가 jar 파일의 형식으로 위치한다.

이하에서 이들 각각에 대해 주요한 사항을 살펴본다.

workflow.xml 파일

워크플로 job 속성

작업자가 우지에서 워크플로 job의 실행을 요청(submit)할 때는 필요한 사항을 job의 속성으로 제시하게 된다. 작업흐름을 이처럼 파라미터화 해 정의하는 예는 다음과 같다.

위에서 보듯이 <workflow-app name='hello-wf'>...</workflow-app> 태그를 통해 수행할 전체작업의 흐름을 정의할 것임을 선언한 후 <action name = 'firstjob'>...</action>를 통해 각각의 작업속성을 action 노드로 규정했다. 이들 각각에 대해서는 해당 속성이 정의되는데 이러한 속성 정의 중 중요한 것에는 다음 세 가지가 있다.

• jobTracker : 수행될 jobTracker 작업
• inputDir: 입력 디렉터리
• outputDir: 출력 디렉터리

표현언어 함수

우지를 통해 작업흐름을 관리하는 방법으로서 워크플로 job을 수행 시 여러가지의 파라미터를 적용할 수 있다. 여기에는 WF job의 속성을 정의하는 것(Workflow Job Properties)과 표현언어(Expression Language)를 이용하는 두 가지 방식이 가능하다.
표현언어란 자바코드를 대신해 다른 표현식을 사용함으로써 태그와의 혼동을 막고 좀 더 간결한 소스 작성이 가능하게 하는 것을 말한다. 예를 들어 워크플로 정의상의 ${inputDir} 같은 변수를 통해 각종 작업이 병행(concurrent) 수행되도록 하는 것을 들 수 있다. 우지에서는 작업관리 용의 표현언어로서 몇 가지 기본 상수(예: MB: 메가바이트, G: 기가바이트)와 함께 다양한 여러 함수를 제공한다. 표현언어 함수의 예를 한두 가지를 알아보자.

1. 기본함수
   
   1. - String firstNotNull(String value1, String value2): null 값이 아닌 첫 문자열을 반환
   2. - String concat(String s1, String s2): 두 개 문자열을 연결한 후 이를 반환
   3. - 기타
2. 작업흐름을 지정하는 EL 함수
   
   1. - String wf:id(): workflow job ID 를 반환
   2. - String wf:name(): workflow application의 이름을 반환
   3. - String wf:appPath(): workflow application의 경로를 반환
   4. - String wf:conf(String name): workflow job의 설정된 속성값을 반환
   5. - String wf:callback(String stateVar): 현재의 action 노드의 callback용 URL을 반환
   6. - 기타

config-default.xml 파일

한편 config-default.xml 파일에는 워크플로 job 속성의 각종 기본 (default) 값이 지정된다. 단 이 파일은 하둡의 설정파일 포맷을 따르며 EL 구문을 따르지 않음을 유의한다.

lib 디렉터리

lib 디렉터리에는 모든 jar 파일과 관련 라이브러리가 저장된다. 이 내용은 자동으로 맵리듀스 및 pig job의 classpath 및 LD_PATH에 추가된다.

job의 수행 (submit)

앞의 워크플로 관련 각종 파일이 설치되면 명령어를 통해 워크플로 job을 수행시키는데 다음과 같은 방법이 가능하다.
- 명령어 (command line) 인터페이스를 통해 shell 명령어 방식으로 작업을 관리한다.
- Web service API를 통해 웹 브라우저로 언제 어디서나 감시와 관리가 가능하다.

명령어 줄에서 실제 사용하는 우지 명령어는 매우 다양하다. 몇 가지 기본형을 살펴보면 다음과 같다.

실제 수행과정을 살펴보면 다음 그림과 같다.

[그림 Ⅱ-4-7] 우지에서 하둡 클러스터로 작업 흐름 제어용 job을 수행

실제 워크플로 job을 수행하고 그 결과 상태(status)를 체크하는 명령어는 다음과 같다.

이제 그 결과가 화면에 다음과 같이 출력됐다.

이상의 작업 진행을 시간 경과에 따라 다음과 같이 표현할 수 있다.

[그림 Ⅱ-4-8] 우지의 작업흐름을 시간 흐름으로 본 모습

우지 명령어와 함께 제시되는 각종 인자값(argument)과 config-default.xml 파일에 지정되는 값들 사이에는 중첩되는 항목들이 존재한다. 이에 대해 서로 다른 값들이 지정됐다면, 명령어 줄에서 제시된 값이 우선권을 가진다. 될 수 있으면 config-default.xml 파일로 통일시켜 값을 지정하는 것을 권한다.