[책정리]빅데이터를 지탱하는 기술 5.1 워크플로 관리

6월 선정도서 - 빅데이터를 지탱하는 기술

선정계기 - 데이터가 쌓이고 흐르는 전체적인 구조를 깊이 있게 이해할 수 있고,

미래의 데이터엔지니어로써 해야하는 업무들의 전반적인 흐름을 파악할 수 있을 것 같아 선정(기대가 된다

 

목차 

챕터5. 빅데이터의 파이프라인

5-1. 워크플로관리 

5-2. 배치형의 데이터플로우

5-3. 스트리밍형의 데이터플로우

 

정기적인 데이터관리를 자동화하여 안정된 배치처리를 실행하기 위해 워크플로 관리도구 도입

아, 아무래도 기존 데이터웨어하우스, 데이터마트보다 덜 접해본 개념이다보니 너무나도 생소하고 낯설다..

그래서 이해가 되지 않는 부분이 꽤나 많았다...

---

워크플로 관리

워크플로 관리란?

정해진 업무를 원활하게 진행하기 위한 구조

정해진 스케쥴에 따라 자동으로 실행되도록 하는 자동화된 워크플로우.

무엇인가 비정상적인 일이 발생한 경우 사람이 개입하여 문제를 해결하도록 한다. 

 

워크플로우 관리도구

정기적으로 태스크를 실행하고, 비정상적인 상태를 감시하여 그것에 대한 해결을 돕는게 목적

데이터 파이프라인의 실행에 특화된 오픈소스의 워크플로 관리도구를 이용한다

ex ; Ariflow,Azkanban(아즈카반), Digdag(디그더그),Luigi(루이지), Oozie(우지)

 

테스크(Task)

데이터를 잇다라 이동하면서 정해진 처리를 반복하는데 이때 실행되는 개별처리 

테스크를 단지 실행하거라면 특별한 도구 없이 직접만든 스크립트를 실행시키는 게 곧 데이터파이프라인 실현

그럼 왜 굳이 워크플로우 관리툴을 사용하는건가?
테스크 실행에 실패할 수 있기 때문이다.

테스크 수가 증가하면, 실패한 테스크를 다시 실행하는 일이 점점 어려워진다.

그래서 워크플로 관리도구가 아래와 같은 기능을 제공해준다.

• 테스크의 정기적인 스케쥴실행, 결과통지
• 테스크 간의 의존관계 정의, 정해진 순서대로 빠짐없이 실행하기
• 테스크의 실행결과 보관하여 오류발생시 재실행할 수 있도록 하기 

그래서 워크플로 관리툴로 데이터파이프라인의 모든 테스트를 관리하기 쉽게 한다.

 

워크플로우 관리도구의 종류(선언형 vs 스크립트형)

선언형

정의 : xml이나 yaml 등의 서식으로 워크플로우룰 기술하는 타입 

특징 : 누가 작성해도 워크플로가 되기 떄문에 유지보수성이 높아진다. 

사용 : 동일 쿼리를 파라미터만 바꿔서 여러실행하거나,단순반복적으로 자동생성 할 경우

 

스크립트형 

정의 : 스크립트 언어로 워크플로우를 정의하는 타입 

특징 : 일반적인 스크립트처럼 변수,제어구문을 사용할 수 있어서 유연성이 높다. 프로그래밍 할 수 있다.

사용 : 스트립트 처리가 필요한 경우, 데이터처리를 테스크 안에서 실행하는 경우 

 

데이터수집 과정에서는 스크립트 처리가 많아 ETL프로세스에서는 스트립트형 도구를, 

데이터를 모아두면 정형적인 처리가 많아 SQL실행에는 선언형 도구로 나누어 사용한다. 

---

테스트 오류가 발생하면 어떻게 복구하는가?

미리 예기치 못한 오류가 발생할 가능성을 고려해두고 오류발생시 대처방법을 결정해두어야한다.

워크플로 관리에서 테스트 실행순서 뿐만 아니라 오류로부터 어떻게 회복할것인가? 에 대한 계획도 정한다. 

 

복구(Recover)와 플로우의 재실행 

1.몇번반복하면 성공하는것 (통신오류) -> 잠깐 기다리면 끝남

2.몇차례 반복해도 실패하는 것 (인증오류) -> 수동으로 대처필요

이렇게 오류에는 수많은 가능성이 있어서 기본적으로 워크플로우 관리에서 오류로부터 자동으로 회복시키 않음.

대신에 수작업에 의한 복구를 전제로 태스크를 설계한다.

 

플로우:워크플로 관리도구에 의해 실행되는 태스크

각 플로우에는 실행시에 고정 파라미터가 부여되어 있다. 

일별 배치처리라면, 특정날짜가 파라미터가 된다.

동일 플로우에 동일파라미터를 건내면 완전히 동일한 태스크를 실행할 수 있다. 그래서 복구가 가능

즉, 플로우가 도중에 실패해도 동일한 파라미터로 재실행이 가능하다. ->복구의 기초

 

과거에 실행한 플로우와 그 파라미터를 자동으로 데이터베이스에 저장한다.

그래서 실패한 플로우를 선택하여 재실행하는 것만으로도 복구가 완료된다. 

대부분 오류는 일시적인 것이 많아 시간을 두고 재실행하는 것만으로도 해결되는 경우가 많기 때문이다.

 

재시도

단순 재실행, 테스트 단위의 자동적인 재시도.

여러번 발생하는 오류에 대해서는 자동화하여 수작업 없이 복구할 수 있다.

곧바로 재시도하면 다시 실패할 수 있기 떄문에 재시도 간격을 5분이나 10분정도로 두면 성공할 수 있다. 

 

재시도횟수에 주의해야한다. 

재시도가 적으면 장애로부터 복구하기 전에 재시도종료->테스크 실행실패

재시도가 많으면 테스크가 실패하지 않은 것 처럼 된다 -> 중대한 문제가 발생해도 눈치채지 못할 수 있다. 

재시도횟수는 테스크의 성격에 따라 다르다. 

 

백필(backfill)

플로우 전체를 처음부터 다시 실행하는 것, 

파라미터에 포함된 일시를 순서댈 바꿔가면서 일정기간의 플로우를 연속해서 실행한다. 

테스트의 실패가 며칠동안 계속된 후에 이를 모아서 재실행하고 싶을때나,

새롭게 만든 워크플로를 과거로 거슬러 올라가 실행하고 싶은 경우 사용한다. 

 

성능상의 주의가 필요하다.

예를 들어 새롭게 일별 플로우를 작성하고, 백필해서 과거 30일간의 데이터를 처리하고 싶다.

하지만 과거 하루동안 쌓인 데이터양이 그리 많지 않다고 해도 그것에 30배나 되는 데이터를 한번에 처리해야한다.

그래서 커다란 부하가 걸릴 수 있고, 평소라면 일어나지 않을 오류가 대량으로 발생할 수 도 있다. 

 

그래서 대규모 백필을 실시할때는 자동적인 재시도는 모두 무효로 하고, 오로는 모두 통지한다.

테스트삼아 조금씩 백필을 실행하여 오류가 발생하는지, 어떤오루가 나는지 확인 

 

멱등한 조작으로 태스크를 기술하기