빅데이터를 지탱하는 기술 - Chapter5 빅데이터의 파이프라인

워크플로 관리

워크플로 기초

정의

• 정해진 업무를 정해진 스케줄에 따라 자동으로 실행하는 구조를 워크플로로 관리라고 한다.

워크플로 관리 도구

• 정기적인 태스크의 실행
• 비정상적인 상태 감지와 해결

태스크

• 데이터 파이프라인의 과정은 데이터가 이동하는 과정이다.
• 이때 이동하면서 이뤄지는 개별 처리를 태스크라고 한다.

빅데이터 파이프라인에 워크플로 도구가 필요한 이유

• 복잡해지고, 많은 수의 태스크에 오류가 생긴다면 복구하는 과정이 어렵다.
• 정기적인 태스크 수행과 보고.
• 태스크 간의 의존 관계 설정과 정해진 순서의 실행.
• 태스크 실행 결과의 보관과 오류 시 재실행.
• 모든 태스크를 일원 관리하는 것이 빅데이터에서 워크플로 관리 도구의 역할이다.

워크플로 관리 도구의 종류 - 선언 형, 스크립트 형

• 선언형
  • XML, YAML 등의 서식으로 기술
  • 미리 제공된 기능만 이용 가능
  • 동일한 워크플로가 되기에 유지보수성이 높음
  • 단순 반복으로 사용
• 스크립트형
  • 유연성이 가장 큰 장점
  • 스크립트 언어를 통해 데이터 처리를 태스크 안에서 할 수 있음
• 데이터를 수집 하는 과정인 ETL 프로세스에서는 유연한 스크립트를 쓰고, 데이터가 구축되면 정형적인 처리를 위한 SQL 실행에는 선언형 도구가 좋다.

 

오류로부터의 복구 방법 먼저 생각하기

장애 발생 원인

• 네트워크 및 하드 웨어 장애
• 스토리지 용량 부족
• 쿼리 증가에 따른 성능 부족 등
• 이러한 오류들을 어떻게 회복할 지 계획하기

복구와 플로우의 재실행

• 통신 오류 → 반복 실행 시 성공
• 인증 오류 → 수동 대처 필요
• 수작업에 의한 복구를 전제로, 실패한 태스크를 모두 기록하여 나중에 재실행 할 수있다.

플로우란?

• 워크플로 관리 도구에 의해 실행되는 일련의 태스크이다.
• 각 플로우에 파라미터가 있고, 파라미터를 넣으면 태스크가 실행된다.
• 즉 플로우에 동일 파라미터를 넣으면 동일한 태스크가 나오기에 복구의 기초가 된다.

워크플로의 버전 관리

• 복잡한 데이터 파이프라인의 구축은 시스템 개발과 동일하다.
• 즉 소프트웨어 관리 처럼 깃을 사용한 관리가 필요하다.

재시도

• 일정 간격을 두고 실행 시 성공 할 수있다.
• 재시도가 적으면, 복구 전에 태스크가 실패로 끝난다.
• 재시도가 많으면, 태스크가 실패하지 않은 것처럼 된다.
• 재시도 횟수는 태스크 성격마다 다르다.
• 이상적으로 재시도 없이 모든 오류를 통지하는 것이 좋고, 원인을 조사하여 대책 마련하는 것이 이상적이다.
• 오류가 생겨도 데이터 전송에 성공한 경우도 있다.
• 재시도 시 데이터가 중복되는 경우도 있다.
• 반복적인 재시도가 아닌, 올바른 문제 해결 방법을 찾는 것이 중요하다.

백필

• 플로우 전체를 처음부터 다시 실행 하는 것이다.
• 일정 기간의 플로우를 연속해서 실행하는 것
• 장 기간의 태스크 실패 혹은 워크플로를 과거로 되돌아가서 실행하고 싶을 때 사용

 

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

복구 전에 재실행의 안정성이 중요하다. 태스크가 작업 중 실패했을 때 흔적이 남아있으면 재실행시 데이터가 혼재 될 수있다.

각 태스크는 마지막까지 성공 혹은 실패하면 아무것도 남지 않아야한다.

원자성 조작

• 하나의 태스크에 Insert를 2개 해야된다면, 중간에 실패하고 재실행시 데이터가 중복된다,
• 쓰기가 필요한 만큼 태스크를 원자처럼 나누어야 한다.
• 완벽한 처리가 필요한 경우, 원자성 조작에 의존하지 않고 자동적인 재시도가 아닌 오류의 내용을 반드시 확인한 뒤 수동으로 복구해야 한다. → 네트워크 오류 등으로 중복 발생 가능성이 있음

멱등한 조작

• 동일한 태스크를 반복해도 동일한 결과가 나오게 하는 것이다.
• SQL의 경우 테이블 삭제 후 다시 만들기가 멱등한 조작의 예시다.
• 추가는 중복 가능성이 있고, 치환은 멱등한 태스크다.
• 태스크에 부여된 파라미터를 잘 이용해 고유의 이름을 생성해서 치환이되도록 설계하게되면 멱등한 태스크가 되므로 자동 복구하기 쉽다.

멱등한 추가

• 매번 치환시 부하가 크다.
• 이때 테이블 파티셔닝 개념을 도입해서 일정 단위로 치환을 한다.
• 파티션의 데이터 삭제 시, TRUNCATE문 등 효율 좋은 명령어가 있다.

태스크 내부에서의 재시도 제어

• 지수 백오프
• 타임아웃

원자성을 지닌 추가

• 복잡한 플로우에서는 하나의 테이블에 여러번 데이터를 써넣을 때, 추가의 반복이 아닌 중간 테이블을 만들고 마지막 목적 테이블에 한번에 추가하자
• 중간 테이블은 치환으로 만들고, 마지막 테이블은 원자성을 지닌 조작으로 1회만 추가하자

 

워크플로 전체를 멱등으로 하기

안정적인 파이프라인의 필수 요건은 태스크와 플로우의 멱등함이다.

• 데이터 수집 - 테이블 파티셔닝을 통한 치환
• 벌크형 데이터 전송 - 워크플로 도구를 이용한 파라미터사용으로 태스크 단위의 치환
• 데이터 마트 구축 - 가능한 치환을 통한 구축
• 데이터 자체에 문제가 생겨, 태스크 취소 후 재실행시 멱등한 태스크가 아니면 문제가 발생한다.
• 재실행의 안전성을 위해서라면 플로우는 멱등함을 유지해야한다, 첫 태스크가 초기화 후 다음 태스크 부터 추가를 하면서 마무리를 하는 것이 그 예이다.

 

태스크 큐

대량의 태스크를 동시 실행하면 과부하가 일어나기에, 태스크 큐라는 구조를 사용해서 한 곳에 모은 후 워커 프로세스가 순서대로 꺼내어 병렬화를 실현하는 개념이다.

병목 현상의 해소

• 8코어 서버에서 8워커가 아닌 20개 정도의 태스크를 동시에 실행한다.
• 워커가 너무 많으면 병목 현상이 발생한다.(성능 향상의 한계점과 오류 발생)
• 내부적인 요인
  • CPU사용률
  • 메모리부족
  • 디스크 초과
  • 디스크I/O 한계
  • 네트워크 대역 한계
  • 통신오류 혹은 타임 아웃
• 외부요인의 경우 문제를 제거 할 수 없고, 업무량을 줄인다.(분산 스토리지, 파일 서버 등)

태스크 수의 적정화

• 태스크가 너무 작거나 클 때, 합치거나 쪼개서 사용을 하는 것이 효율적이다.
• 이렇게 데이터 파이프라인 전체가 원활하게 실행되도록 제어하는 것도 워크플로 관리 도구의 역할이다.

 

배치 형의 데이터 플로우

워크플로우와 데이터플로우

• 분산 스토리지에 데이터 저장 후, 분산 시스템 프레임워크를 이용한다.
• 이때 SQL뿐 아니라, 프로그래밍 언어를 이용하여 데이터 파이프라인을 작성 할 수 있다.
• MapReduce를 워크플로우 안의 태스크로 등록하여 분산시스템 내부에서 다단계의 처리를 한다.
• 이것을 데이터 플로우라고 지칭한다.

MapReduce의 구조

• 데이터를 나눈다
• 개별로 데이터를 처리한다(Map)
• 마지막에 합쳐준다(Reduce)
• 단점
  • 복잡한 데이터 처리는 이러한 구조를 반복해서 처리한다.
  • 하나의 사이클이 끝나야만 다음 사이클로 이동 가능하다.
  • 애드 혹 분석의 경우 빠른 집계가 필요하므로 알맞지 않다.

 

MapReduce 대체 프레임워크

DAG

• 방향성 비순환 그래프이다.
• MapReduce도 단순한 DAG지만 비효율적인 구조이다
• 모든 노드가 병행이 되므로 대기 시간이 훨씬 짧아진다
• 지연 평가가 가장 큰 특징이다
• Map Reduce 하나씩 실행하지 않고, DAG로 조립 후 실행하며 내부 스케줄러가 분산 시스템에 맞춰 효과적인 실행을 해주는 것이 데이터 플로우의 장점이다.

 

데이터 플로우와 워크플로우의 조합

데이터플로우와 워크플로우는 상호보완적인 관계다

• 정기적 실행과 실패한 태스크의 기록은 워크플로우
• 데이터 플로우는 워크플로우에 존재하는 일부의 태스크다
• 분산 시스템 내부에 처리되는 것은 하나의 데이터플로우이다.

데이터를 읽어들이는 플로우

• 데이터 플로우로 읽어들이는 경우, 성능이 안정적인 분산스토리지가 좋다
• 데이터 소스에서 분산스토리지로 옮길 때는 벌크형의 전송도구가 좋다.
• 데이터의 복사가 완료되면 데이터 플로우의 전문 분야(텍스트데이터가공, 열 지향 스토리지로의 변환)다.
• 이러한 과정이 정기적으로 데이터를 읽어들이는 워크플로우의 완성이다.

데이터를 써서 내보내는 플로우

• 데이터 플로우 안에서 대량의 데이터 전송하는 행위는 피하자
• CSV등의 취급하기 쉬운 형식으로 변환 후 분산스토리지의 저장까지가 데이터플로우의 역할은 끝이다.
• 이제 외부 시스템의 전송은 워크플로의 역할이다
  • 벌크 형의 전송도구로 태스크 구현
  • 외부 시스템이 직접 파일을 읽어가기

 

데이터 플로우와 SQL 나누어 사용

위의 과정에서 SQL에 의한 쿼리 실행 조합이면, 배치형 데이터 파이프라인의 완성이다.

• MPP DB에서 SQL 실행 - 데이터웨어하우스의 파이프라인
• 분산 시스템상 쿼리 - 데이터마트의 파이프라인

대화식 플로우

• 애드혹 분석의 파이프라인이다.
• 수작업이 많으므로 워크플로는 필요하지 않다.
• 구조화되지 않은 데이터를 분석하므로 데이터 플로우가 매우 유용하다
• 로우 데이터에 접근하여 가공 집계 한다.
• 만약 데이터가 구조화가 되어있다면 고속 처리 및 쿼리 엔진을 사용 할 수 있다.

 

스트리밍 형의 데이터 플로우

배치처리와 스트림 처리로 경로 나누기

• 앞서 배운 배치 처리는 분산 스토리지의 저장이 시작이며, 스트림 처리는 이를 거치지 않는다.

 

배치 처리와 스트림 처리 통합하기

• 배치처리의 경우 쪼개서 데이터를 넣는다
• 스트림 처리의 경우 잘개 쪼개재서 끊임없이 들어온다.
• 데이터를 넣는 DAG를 조금씩 수정해서 두 가지 상황에서 처리 할 수 있다.
• 데이터가 생성되는 양이 많은 경우 스트림 처리로 집계를 한 후 모아서 분산스토리지에 저장 할수도있다.

 

스트림 처리의 결과를 배치 처리로 치환하기

스트림 처리의 문제점 해결방법

• 배치처리 처럼 되돌리는 개념이 없기에 서로 상호보완적인 관계를 가져야한다
• 람다 아키텍처
  • 스트림으로 짧은 기간을 실시간으로 본다.
  • 배치 처리로 이전의 결과를 보거나, 올바른 결과로 수정한다
• 카파 아키텍처
  • 람다의 경우 2개의 레이어를 구현 처리 해야하므로 효율적이지 않다
  • 메시지 브로커의 보관 기간을 늘림으로서 과거 데이터 수정을 한다.
  • 재 실행의 개념으로 과거로 부터의 많은 데이터가 들어올경우 시스템 부하가 올 수 있다.

 

아웃 오브 오더의 데이터 처리

프로세스 시간과 이벤트 시간의 차이로 발생하는 것.

• 이벤트 시간 윈도윙 사용