여러 아파치 하둡 작업(Map Reduce, Hive, Spark, Sqoop, Pig 등)을 실행하고 관리하는 워크플로우 스케줄러 시스템

Oozie 용어

Action : Oozie에서 실행할 수 있는 작업단위(MapReduce 작업, Spark 작업, Shell script 작업)

Workflow : 기본적 의미는 이전 작업의 출력이 다음 작업의 입력으로 이어지는 것을 말함. Oozie에서 Workflow는 Action들의 제어와 의존 관계를 DAG 형식으로 표한 한다.

Coordinator : Data Sets과 Workflow를 실행하는 스케줄을 정의 한 것.

Bundle : Coordinator의 집합.

 

핵심 기능

Scheduling

  • 특정 시간에 액션 수행
  • 주기적인 간격 이후에 액션 수행
  • 이벤트가 발생하면 액션 수행

Coordinating

  • 이전 액션이 성공적으로 끝나면 다음 액션 시작

Managing

  • 액션이 성공하거나 실패했을 때 이메일 발송
  • 액션 수행시간이나 액션의 단계를 저장

 

워크플로우 노드 유형

시작/종료 제어플로우 노드

Action 노드 : 실제로 처리되는 Task를 정의.

Fork/Join 노드 : 워크플로우에서 Task를 병렬로 실행시킨다.

제어 플로우 노드 : 이전 액션 결과를 기반으로 다음 실행을 위한 판단을 내린다.

 

 

Oozie 실행 과정

1. 클라이언트는 우지 서버에 연결하여 job properties을 제출

  • job properties는 key-value 형태로 작업에 필요한 파라미터를 정의
  • workflow.xml(Action들과 그들을 연결하는 로직은 Workflow를 정의) 파일의 NameNode와 Yarn ResourceManager(혹은 JobTracker)에 대한 URI를 포함하고 있음.

2. 우지 서버가 HDFS로 부터 workflow 파일을 읽는다.

3. 우지 서버에서 workflow를 파싱해서 액션을 수행한다.

 

 

사용 예시

Oozie의 스크립트는 xml로 작성하고 이를 수행하는 방식이다. 아래는 xml 예시파일이다.

<!-- This is a comment -->
<workflow-app xmlns = "uri:oozie:workflow:0.4" name = "simple-Workflow">
   <start to = "Create_External_Table" />

   <!—Step 1 -->
   
   <action name = "Create_External_Table">
      <hive xmlns = "uri:oozie:hive-action:0.4">
         <job-tracker>xyz.com:8088</job-tracker>
         <name-node>hdfs://rootname</name-node>
         <script>hdfs_path_of_script/external.hive</script>
      </hive>
		
      <ok to = "Create_orc_Table" />
      <error to = "kill_job" />
   </action>

   <!—Step 2 -->
   
   <action name = "Create_orc_Table">
      <hive xmlns = "uri:oozie:hive-action:0.4">
         <job-tracker>xyz.com:8088</job-tracker>
         <name-node>hdfs://rootname</name-node>
         <script>hdfs_path_of_script/orc.hive</script>
      </hive>
		
      <ok to = "Insert_into_Table" />
      <error to = "kill_job" />
   </action>

   <!—Step 3 -->
      
   <action name = "Insert_into_Table">
      <hive xmlns = "uri:oozie:hive-action:0.4">
         <job-tracker>xyz.com:8088</job-tracker>
         <name-node>hdfs://rootname</name-node>
         <script>hdfs_path_of_script/Copydata.hive</script>
         <param>database_name</param>
      </hive>
		
      <ok to = "end" />
      <error to = "kill_job" />
   </action>
   
   <kill name = "kill_job">
      <message>Job failed</message>
   </kill>
	
   <end name = "end" />

</workflow-app>

 

이런 Oozie의 스크립트는 DAG 형식으로 표현했을 때 아래와 같다.

 

 

 

출처 : https://seamless.tistory.com/31 [Apache Oozie 알아보기]

출처 : https://www.tutorialspoint.com/apache_oozie/apache_oozie_workflow.htm [Apache Oozie - Workflow]

'좌뇌 > 빅데이터(BigData)' 카테고리의 다른 글

ZooKeeper  (0) 2022.05.19
DB vs DW (데이터베이스와 데이터웨어하우스 차이)  (0) 2022.05.15

코디네이션 서비스

각 시스템의 중요한 상태정보나 설정정보들을 유지하고 동기화를 위한 lock처리 등을 관리하는 서비스를 의미한다.

 

ZooKeeper 란?

ZooKeeper는 Hadoop의 분산 시스템에서 분산 애플리케이션에 대한 코디네이션 서비스를 제공하는 역할을 한다. 애플리케이션들의 설정 정보 관리, 이름을 지정, 분산 동기화를 제공하며, 그룹화 서비스를 제공하는 중앙 집중식 서비스이다.

ZooKeeper는 이러한 다양한 서비스의 본질을 중앙 집중식 조정 서비스에 대한 매우 간단한 인터페이스로 통합하는 것을 목표로 한다.

 

 

모델

ZooKeeper는 분산 애플리케이션에 대한 동기화, 설정 정보, Lock(잠금처리) 등에 대한 조율을 위해 각 애플리케이션들에 대한 서버를 두고 이를 관리하는 구조로 되어있다. 그런데 단순한 서버 클라이언트 구조가 아닌 안전성, 분산 애플리케이션 환경 등을 고려하여 설계되었다.

 

znode

주키퍼에게 필요한 글로벌 락, 동기화, 리더 채택, 설정 관리 등의 기능을 구현할 수 있도록 하는 파일시스템이 있다. 이 파일 시스템에서의 각각 파일을 znode라고 부른다.


znode는 unix-like 시스템에서 쓰이는 file system처럼 node 간에 hierarchy namespace를 가지고 '/'로 구분하여 사용한다. 그러나 ZooKeeper에서 일반적인 file system과 다른 부분은 file과 directory의 구분이 없이 znode라는 것 하나만을 제공한다

 

 

znode의 종류

  • Persistent mode: Persistent mode로 생성된 znode는 명시적으로 삭제될 때까지 지워지지 않는, 우리가 일반적으로 생각하는 file과 같다.

 

  • Ephemeral mode: Ephemeral mode로 생성된 znode는 ZooKeeper서버와 znode를 생성하도록 요청한 클라이언트 사이의 connection이 종료되면 자동으로 지워진다. ephemeral node의 이런 특성을 이용하여 lock이나 leader election을 구현하기도 하고 클라이언트와 연결 여부를 확인하기도 용이하다.

 

  • Sequence mode : znode는 Persistent일 수도 Ephemeral일 수도 있다. Sequence mode로 znode가 만들어 질 때 주키퍼 데이터 모델 상에서 이 znode는 10자리 연속된 숫자를 가지고 있는 이름을 가지고 만들어 진다. Sequence mode의 znode가 만들어 질 때, 주키퍼 데이터 모델 상에서 이 znode는 10자리 연속된 숫자를 가지고 있는 이름을 가지고 만들어 진다. 예로들어 /app 이라는 연속형 znode를 만들면 app0000000001, app0000000002, ... 로 자동적으로 만들어지는 형식이다. 이 연속형 znode는 lock을 구현하거나 글로벌 큐(global queue)를 구현할 때 사용된다.


znode는 사용성에 따라 모드를 반드시 지정해서 create를 호출해야 한다

 

 

ZooKeeper 아키텍쳐

 

주키퍼의 서버는 한대가 아닌 여러대를 동시에 운용한다. 그리고 서버들의 묶음을 앙상블(Ensemble)이라고 칭한다.

이 서버들은 모두 동일한 데이터를 가지고 있는데, 갱신이 일어날 때도 같이 동기화 되도록 프로그래밍 되어있다.

이렇게 동일한 데이터를 가진 서버를 여러대 두고 운용하는 이유는 장애에 대한 대비 때문이다. 만약 한 대의 서버로 운용하는데 서버에 장애가 발생하면 모든 분산 애플리케이션은 중단된다. 그러나 2대 이상의 동일한 서버를 두고 운용하면 장애에 대한 안정성은 높아 진다. Ensemble은 과반수 이상의 서버에 장애가 생기면 서비스 불가 상태가 된다. 즉 서버가 N대일 때, ⌈N/2⌉대 이상 장애가 발생하면 서비스 불가 상태가 된다. 


각 서버가 동일한 데이터를 가지도록 동기화 시키는 방법에 대해 자세히 설명하면 다음과 같다. 다이어그램에 나와있듯이 클라이언트(분산 애플리케이션)들은 주키퍼 서버들로 이루어진 앙상블(Ensemble)에 접근하여 znode의 데이터를 읽거나 데이터를 업데이트 한다. 

만일 주키퍼 서버에 쓰기 동작을 할 경우에, 클라이언트는 특정 서버에 접속하여 그 서버의 데이터를 업데이트 한다. 그리고 업데이트 된 서버는 leader의 역할을 맡은 주키퍼 서버에 그 데이터를 알리고 업데이트한다. 이 업데이트를 감지한 leader 서버는 그 정보를 다른 곳에 브로드캐스트(Broadcast) 형식으로 알리게 된다. 그 업데이트 정보를 받은 나머지 Follower 주키퍼 서버들은 그 내용을 갱신하여 전체 서버들의 데이터들이 일관된 상태로 유지된 상태로 있게 된다. 이런 과정을 통해 Ensemble안의 주키퍼 서버들은 조율된 상태이며 항상 동일한 데이터를 가지고 있게 된다. 클라이언트는 어느 주키퍼 서버에서 데이터를 읽어도 똑같은 값을 가져온다.

 

ZooKeeper  특징

Sequential Consistency(순차적 일관성) - 클라이언트의 업데이트가 전송된 순서대로 적용됩니다.
Atomicity(원자성) - 업데이트가 성공하거나 실패합니다. 부분 결과가 없습니다.
Single System Image - 클라이언트는 연결된 서버에 관계없이 동일한 데이터를 볼 수 있다. 
Reliability - 클라이언트 요청에 의해 업데이트가 적용되면 다른 클라이언트가 업데이트를 덮어쓸 때까지 데이터(znode 등)가 계속 유지된다.
Timeliness - 특정 시간(time bound)내에는 클라이언트 정보가 최신 상태로 유지되도록 보장합니다.

 

 

ZooKeeper  활용 사례

아래와 같이 Hadoop의 클러스터 구성에 활용된다. Hadoop클러스터에서 Active Namenode와 Stanby Namenode가 존재할 때, Namenode가 비정상 상태인 경우 Stanby Namednode가 동작해야 한다. 방법은 다음과 같다. Active Namenode가 비정상일 경우 ZooKeeper서버와 connection이 끊길 것이다. 이를 ZooKeeper를 통해 Stanby Namenode가 알게 될 것이고, Stanby Namenode는 Active 상태가 된다.

ZooKeeper는 이외에도 Hbase, Kafka 등의 애플리케이션에서 활용된다.

 

ZooKeeper API 활용하여 애플리케이션 개발

ZooKeeper를 활용하여 개발하는 방법은 아래 블로그에 소개가 나와있으니 참고한다.

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=alice_k106&logNo=220620934774 

 

60. [Zookeeper] 분산 코디네이터 - Zookeeper 예제 코딩편 (java)

이번 포스트에서는 Zookeeper(이하 주키퍼)를 이용한 코드를 설명한다. 정말로 간단한 예제를 설명한다. ...

blog.naver.com

 

 

 

참고 

출처: https://engkimbs.tistory.com/660

출처: https://kimseunghyun76.tistory.com/397

출처: https://zookeeper.apache.org/doc/current/zookeeperOver.html#sc_designGoals 

출처: https://blog.seulgi.kim/2014/05/zookeeper-1-znode-zookeeper-data.html

'좌뇌 > 빅데이터(BigData)' 카테고리의 다른 글

Apache Oozie  (0) 2022.06.02
DB vs DW (데이터베이스와 데이터웨어하우스 차이)  (0) 2022.05.15

Database vs Data Warehouse

  데이터 베이스 데이터웨어 하우스
목적 기록하도록 설계 분석하도록 설계
가공 방법 OLTP (온라인 트랜잭션 처리) OLAP (온라인 분석 처리)
용법 데이터베이스는 비즈니스를위한 기본적인 작업 수행에 도움이됩니다. 데이터웨어 하우스를 사용하면 비즈니스를 분석 할 수 있습니다.
테이블과 조인 데이터베이스의 테이블과 조인은 정규화되면 복잡합니다. 테이블 및 조인은 비정규화되어 있기 때문에 데이터웨어 하우스에서 간단합니다.
정위 응용 프로그램 지향 데이터 수집 주제 중심의 데이터 모음
저장 용량 한도 일반적으로 단일 응용 프로그램으로 제한됩니다. 여러 애플리케이션의 데이터 저장
유효성 실시간으로 데이터를 이용할 수 있습니다. 필요한 경우 원본 시스템에서 데이터를 새로 고칩니다.
용법 ER 모델링 기술은 설계에 사용됩니다. 데이터 모델링 기술은 설계에 사용됩니다.
기술 데이터 캡처 데이터 분석
데이터 형식 데이터베이스에 저장된 데이터는 최신 상태입니다. 현재 및 과거 데이터는 데이터웨어 하우스에 저장됩니다. 최신이 아닐 수도 있습니다.
데이터 저장 Flat Relational Approach 방법은 데이터 저장에 사용됩니다. 데이터 구조에 대해 차원적이고 표준화 된 접근 방식을 사용합니다. 예 : 스타 및 스노우 플레이크 스키마.
쿼리 유형 간단한 트랜잭션 쿼리가 사용됩니다. 복잡한 쿼리는 분석 목적으로 사용됩니다.
데이터 요약 상세 데이터는 데이터베이스에 저장됩니다. 고도로 요약 된 데이터를 저장합니다.

*OLTP

OLTP 란 온라인 트랜잭션 처리를 말하며, 네트워크 상의 온라인 사용자들의 Database 에 대한 일괄 트랜잭션 처리를 의미한다.

흔히 말하는 "트랜잭션(Transaction) 처리" 를 OLTP 라 부며, 트랜잭션이라 부르는 용어의 의미 자체가 OLTP 의 의미를 포함하고 있다.

트랜잭션의 주 특징은 그루핑된 연산의 실패시, Rollback 이 지원된다는 점이다.

 

*OLAP

온라인 분석 처리(Online Analytical Processing, OLAP)는 의사결정 지원 시스템 가운데 대표적인 예로, 사용자가 동일한 데이터를 여러 기준을 이용하는 다양한 방식으로 바라보면서 다차원 데이터 분석을 할 수 있도록 도와준다.

최종 사용자가 다차원 정보에 직접 접근하여 대화식으로 정보를 분석하고 의사결정에 활용하는 과정에서 등장하였다. Database 자체적으로 운용되는 시스템을 의마하는 것은 아니다. 사용자가 온라인상에서 직접 데이터에 접근하고 대화식으로 정보를 분석하므로 사용자가 기업의 전반적인 상황을 이해할 수 있게 하고 의사결정하는 일련의 시스템을 의미한다.

 

출처: https://ko.wikipedia.org/wiki/온라인_분석_처리 [위키백과]
출처: https://jins-dev.tistory.com/entry/간략하게-정리해보는-OLTP-OLAP-의-개념 [Jins' Dev Inside]

출처: https://dbrang.tistory.com/1380 [디비랑[dɪ'bɪraŋ]]

'좌뇌 > 빅데이터(BigData)' 카테고리의 다른 글

Apache Oozie  (0) 2022.06.02
ZooKeeper  (0) 2022.05.19

+ Recent posts