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

시작하며

5장은 빅데이터 파이프라인의 전체 구조를 다룬다. 워크플로우 관리 도구를 통해 파이프라인을 안정적으로 운영하는 방법, DAG를 활용한 배치 데이터플로우, 그리고 스트리밍 처리를 위한 람다·카파 아키텍처를 살펴본다.

1. 워크플로우 관리

워크플로우 관리(workflow management)란 정기적인 태스크를 원활하게 실행하고, 비정상적인 태스크를 감지하여 해결하는 행위를 말한다.

Info

워크플로우 관리 도구(workflow management tool)의 기능

• 태스크를 정기적인 스케줄로 실행하고, 그 결과를 통지한다.
• 태스크 간의 의존관계를 정하고, 정해진 순서대로 빠짐없이 실행한다.
• 태스크의 실행 결과를 보관하고, 오류 발생 시에는 재실행할 수 있도록 한다.

워크플로우 관리 도구에는 1) XML, YAML 등의 서식으로 워크플로우를 기술하는 선언형(declarative)이 있고, 2) 스크립트 언어로 워크플로우를 기술하는 스크립트형(scripting) 관리 도구가 있다. 일반적으로 스크립트형은 선언형에 비해 유연성이 높고 프로그래밍이 가능하여 데이터 처리를 태스크 안에서 수행 가능하다.

오류

데이터 파이프라인은 일시적인 네트워크 장애, 하드웨어 장애, 데이터 증가로 인한 쿼리 수행 시간 초과, 성능 부족 등 다양한 요인으로 인해 오류가 발생할 수 있다. 이를 신속하게 해결하지 못하면 더 큰 문제가 야기될 수 있으므로 오류에 강한 워크플로우를 구축하여 반복되는 데이터 처리를 안정적으로 실행할 수 있도록 하여야 한다.

1. 복구(recovery)와 플로우의 재실행

   • 대부분의 워크플로우 관리 도구는 과거에 실행한 플로우와 파라미터를 자동으로 데이터베이스에 기록한다. 따라서 실패한 플로우를 재실행하는 것으로 복구가 가능하다.
   • 재실행 시에는 실행되는 태스크를 되도록 작게 나누어 유지하면 도중에 문제가 발생해도 해당 단계에서 재수행이 가능하다.
   • 오류의 원인을 파악하지 못한 채로 무분별한 재실행은 의미 없을 뿐더러 예상 밖의 문제를 발생시킬 수 있다.

2. 백필(backfill)

   • 실패한 플로우 전체를 처음부터 다시 실행하는 것을 백필(backfill)이라고 한다.
   • 파라미터에 포함된 일시를 순서대로 바꿔가면서 일정 시간의 플로우를 연속적으로 실행한다. 과거의 플로우를 모아서 실행하거나, 과거의 데이터로 실행하는 케이스를 말한다.
   • 한 번에 대량의 백필은 성능상 악영향을 끼칠 수 있다. 따라서 점진적으로 테스트하며 진행한다.

멱등

데이터 복구를 위해 플로우를 재실행하게 된다면, 항상 기억해 둘 점은 재실행의 안정성이다. 각 태스크는 원자성 조작(atomic operation)이 성립되어야 하므로 각 태스크별로 한 번만 시스템에 영향을 줄 수 있도록 한다.

따라서 이 원자성 조작(atomic operation)보다 좀 더 안전하게 동작하도록 찾은 방법이 멱등한 조작(idempotent operation)이다. 예를 들어 테이블을 통째로 지우고 다시 쓰는 Drop - Create - Insert나 Truncate - Insert, Delete - Insert가 여기에 해당한다. 하지만 이 방법은 원하는 데이터 이상의 데이터를 날릴 위험성이 있고, 성능상의 비효율을 가져온다.

테이블 파티셔닝(table partitioning)은 이를 보완하기 위해 만들어진 방법이다. 예를 들어 테이블을 1일 혹은 1시간 단위로 분할하고, 파티션 단위로 치환한다면 Truncate - Insert보다 좀 더 효율적인 작업이 가능해진다. 파티션의 모든 데이터를 삭제하는 데에는 truncate나 insert overwrite와 같은 효율 좋은 명령이 사용 가능해진다.

큐

워크플로우 관리 도구를 사용하면서는 외부 시스템의 부하 역시 고려해야 한다. 외부 시스템의 부하에 따라 워크플로우 서버에도 적절한 병렬화와 적절한 태스크 사이즈를 통해 부하를 조절해 주어야 한다.

2. DAG를 사용한 배치형의 데이터플로우

데이터 플로우(data flow)는 다단계의 데이터 처리를 그대로 분산 시스템의 내부에서 실행하는 것을 말한다. 대표적으로 MapReduce가 있었고 이제는 Google Cloud Dataflow, Hadoop Tez, Apache Spark, Apache Flink 등이 이 바통을 넘겨받았다.

이들 새로운 프레임워크에는 DAG(Directed Acyclic Graph)라고 하는 데이터 구조가 공통적으로 들어간다. 방향성 비순환 그래프라고 불리는 이 자료 구조는 동일 노드로 되돌아오지 않는 방향성 그래프를 의미하며, 의존관계를 유지하며 모든 태스크를 빠짐없이 완료하게 되는 개념이다. 이는 쿼리 엔진(Tez나 Presto)이 내부적으로 만들기도 하고 Spark는 파이썬 스크립트를 통해 생성하기도 한다.

DAG는 Lazy evaluation이라는 특성을 가지고 있으며 명시적 혹은 암묵적으로 실행 결과를 요구하는 상황에 도달해야 데이터 처리가 시작된다. 이는 전체 파이프라인이 DAG로 조립되고 난 후, 내부 스케줄러에 의해 효율적인 실행 플랜을 작성할 수 있으므로 데이터플로우의 큰 장점이다.

따라서 전체적인 흐름은 워크플로우 관리 도구가 관리하고, 각각의 내부적인 데이터 플로우는 상황에 맞게 분산 시스템에서 동작하도록 여러 프레임워크를 통해 작성하여 관리한다.

Info

데이터 플로우(data flow)의 작업 예시

• 문자 코드 변환
• 날짜와 시간의 서식 정규화
• 정규 표현에 의한 칼럼 추출
• 중복 배제
• 열 지향 스토리지로의 변환
• 복수의 테이블 결합
• SQL 집계
• CSV 파일로의 변환

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

데이터의 실시간 처리를 높이려면 배치 처리와는 전혀 다른 데이터 파이프라인이 필요하다. 분산 스토리지를 거치지 않는 실시간 처리를 스트림 처리(stream processing)라고 한다. 스트림 처리는 실시간성이 우수하지만 과거의 데이터를 집계하는 데는 기존의 배치 처리가 성능이 우수하므로 이 두 가지 처리 방법을 데이터 목적에 맞게 구분하여 사용한다.

스트림 처리에는 다음과 같은 두 가지 문제점이 있다.

1. 틀린 결과를 수정할 방법이 없다.

   • 스트림 처리는 새롭게 도착한 데이터를 처리할 뿐이므로 시간을 되돌린다는 개념이 없다.

2. 늦게 전송된 데이터에 의한 부정확한 집계.

   • 스트림 처리는 처리 이전에 데이터 배송이 이루어져야 하는데, 데이터가 발생한 시각과 데이터가 도착한 시각에 차이가 있을 수 있다.

위 문제에 대한 전통적인 방법은 스트림 처리와 배치 처리를 함께 가져가는 것이다. 빠르게 데이터를 서빙해야 하는 경우는 조금 부정확하더라도 스트림 데이터를 사용하고, 이후 배치 처리가 완료되면 정확한 값으로 대치한다.

람다 아키텍처(lambda architecture)

람다 아키텍처(lambda architecture)에서는 데이터를 3개의 레이어로 구분한다.

1. 모든 데이터는 우선 배치 레이어(batch layer)에서 처리한다. 이는 과거의 데이터를 축적하여 여러 번 집계할 수 있게 하기 위함이다.
2. 배치 처리 결과는 서빙 레이어(serving layer)로 접근할 수 있다. 응답이 빠른 데이터베이스로 집계 결과를 바로 확인할 수 있게 한다.
3. 스트림 처리는 스피드 레이어(speed layer)를 사용한다. 실시간 뷰를 생성하기 위한 목적이다. 이후 오래된 데이터는 삭제된다.

실시간 뷰와 배치 처리 결과를 조합하여 쿼리 질의에 대한 결과값을 도출한다. 따라서 어느 정도의 정확성과 성능을 확보할 수 있고 스트림 처리를 다시 실행해야 할 요건이 사라진다.

카파 아키텍처(kappa architecture)

카파 아키텍처(kappa architecture)는 같은 처리가 중복되는 람다(배치와 스트림)에 비해 단순하다. 배치 레이어나 서빙 레이어를 제거하고 스피드 레이어(speed layer)만을 남겨 사용한다. 대신에 카파 아키텍처는 메시지 브로커를 이용한다. 메시지 브로커 내의 배송 시간을 과거로 되돌려 스트림 처리의 재실행을 가능하게 한다. 따라서 스트림 처리의 멱등성만 보장되었다면 스트림 처리의 단점을 해소할 수 있다.

아웃 오브 오더(out of order)

아웃 오브 오더(out of order) 문제는 스트림 처리의 두 번째 문제인 늦게 전송된 데이터에 의한 부정확한 집계와 관련이 있다. 바로 프로세스 시간과 이벤트 시간의 차이이다. 데이터가 처리된 프로세스 시간은 사실 많은 이유로 부정확한 모습이 될 가능성이 높다. 반면 실제 이벤트가 발생한 이벤트 시간은 해당 데이터의 특성을 잘 보존한 상태이다. 따라서 스트림 처리에서는 시간을 일정 단위로 쪼갠 window를 통해 데이터를 집계한다. 이를 이벤트 시간 윈도잉(event-time windowing)이라고 한다. 프로세스 시간대로 나열되어 정작 이벤트 시간은 무작위로 나열되었을 수 있으므로, 과거의 이벤트 시간을 이 윈도우가 보관하면서 데이터가 도달함에 따라 재집계한다.

정리하며

이번 장의 내용을 정리하면 다음과 같다.

• 워크플로우 관리 도구(workflow management tool)는 데이터 플로우(data flow)를 포함하여 전체 파이프라인을 관리하며, 워크플로우는 오류와 멱등성에 유연하게 제작한다.
• 데이터 플로우(data flow)는 DAG(Directed Acyclic Graph)라고 하는 데이터 구조를 통해 의존관계를 유지하며 모든 태스크를 빠짐없이 완료하게 한다.
• 실시간 데이터 처리는 스트림 처리(stream processing)를 이용하며, 처리 방식에 따라 배치 데이터를 통해 보완하는 람다(3-layer)와 메시징 브로커를 활용하는 카파(speed only)로 나눌 수 있다.

참고문헌

• [출처] 니시다 케이스케(Keisuke Nishida), ⌜빅데이터를 지탱하는 기술(BIG DATA WO SASAERU GIJUTSU)⌟, 장성두 옮김, 주식회사 제이펍