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

들어가며

1. 워크플로우 관리

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

워크플로우 관리 도구(workflow management tool)의 기능
Task를 정기적인 스케줄로 실행하고, 그 결과를 통지한다.
Task간의 의존관계를 정하고, 정해진 순서대로 빠짐없이 실행한다.
Task의 실행결과를 보관하고, 오류 발생시에는 재실행할 수 있도록 한다.

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

오류

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

복구(recovery)와 플로우의 재실행
- 대부분의 워크플로우 관리 도구는 과거에 실행한 플로우와 파라미터를 자동으로 데이터베이스에 기록하게 되어 있습니다. 따라서 실패한 플로우를 재실행하는 것으로 복구가 가능합니다.
- 재실행 시에는 실행되는 Task를 되도록 작게 나누어 유지하면 도중에 문제가 발생해도 해당 단계에서 재수행이 가능합니다.
- 오류의 원인을 파악하지 못한 채로 무분별한 재실행은 의미없을 뿐더러 예상외의 문제를 발생시킬 수 있습니다.
팩필(backfill)
- 실패한 플로우 전체를 처음부터 다시 실행하는 것을 백필(backfill) 이라고 합니다.
- 파라미터에 포함된 일시를 순서대로 바꿔가면서 일정시간의 플로우를 연속적으로 실행합니다. 과거의 플로우를 모아서 실행하거나, 과거의 데이터로 실행하는 케이스를 말합니다.
- 한번에 대량의 백필은 성능상 악영향을 끼칠 수 있습니다(한번에 평균 이상의 데이터를 수행할 수 있기 때문). 따라서 점진적으로 테스트하며 진행합니다.

멱등

데이터 복구를 위해 플로우를 재실행하게 된다면, 항상 기억해 둘 점은 재실행의 안정성 입니다. 각 Task는 원자성 조작(atomic operation)이 성립되어야 하므로 각 테스트별로 한번만 시스템에 영향(예를 들어 ‘쓰기’)을 줄 수 있도록 합니다. 물론 이런 경우임에도 버그 등의 이유로 이미 성공한 Task를 실패로 여기는 경우도 있으므로 이런 작업이 재실행에 의해 반복되지 않기 위해서는 오류 내용을 파악하여 수동으로 복구하는 작업이 필요합니다. 또한 같은 테이블에 여러번 쓰기 작업을 하는 경우는 중간테이블에 모아 쓴 다음 한번에 기록하는 것도 좋은 방법입니다.

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

테이블 파티셔닝(table partitioning) 은 이를 보완하기 위해서 만들어진 방법입니다. 예를 들어 테이블을 1일 혹은 1시간 단위로 분할하고, 파티션 단위로 치환한다면 Truncate - Insert 좀 더 효율적인 작업이 가능해 집니다. 파티션의 모든 데이터를 삭제하는 데에는 truncate나 insert overwrite 와 같은 효율 좋은 명령이 사용 가능해집니다. 하지만 Amazone Redshift 등은 파티셔닝의 개념이 없어 UNION ALL을 사용한 뷰를 작성하여 대응하는 등 시스템에 맞게 재구출 할 필요가 있습니다.

큐

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

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로 조립되고 난 후, 내부 스케줄러에 의해 효율적인 실행플랜을 작성할 수 있으므로 데이터플로우의 큰 장점이라고 할 수 있습니다.

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

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

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

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

스크림 처리에서도 너무 많는 데이터가 들어오는 경우, 필요한 데이터만 뽑아서 사용하는 것도 가능합니다. 스트림 처리 결과만을 따로 모아 다시 메세지 브로커에 작성하는 경우도 있습니다.

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

틀린 결과를 수정할 방법이 없다.
- 스트림 처리는 새롭게 도착한 데이터를 처리할 뿐이므로 시간을 되돌린다는 개념이 없습니다.
늦게 전송된 데이터에 의한 부정확한 집계.
- 스트림 처리는 처리 이전에 데이터 배송이 이루어져야 하는데, 데이터가 발생한 시각과 데이터가 도착한 시각에 차이가 있을 수 있습니다.

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

람다 아키텍처(lambda architecture)

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

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

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

카파 아키텍처(kappa architecture)

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

아웃 오브 오더(out of order)

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

정리하며

이번 장의 내용은 정리하면 다음과 같습니다.

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

참고문헌

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