[빅데이터를 지탱하는 기술] 5. 빅데이터의 파이프라인 (3)

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

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

▪ 배치 처리를 중심으로 하는 데이터 파이프라인은 데이터를 모아서 변환하는 데까지  일정 시간이 필요

▪ 받은 데이터를 분산 스토리지를 거치지 않고 처리를 계속하는 것이 '스트림 처리(streaming procession)'

▪ 배치 처리에서는 받은 데이터를 우선 분산 스토리지에 저장하고, 정기적으로 추출해서 데이터 처리

▪ 스트림 처리는 데이터가 도달하는 것과 거의 동시에 처리가 시작, 처리한 결과는 데이터 스토어에 저장하거나 실시간 시스템에 전송

 

배치 처리와 스트림 처리

  

▪ 배치 처리와 실시간 처리는 서로의 결점을 보완 

▪ 배치처리는 장기적인 데이터 분석을 예상한 스토리지를 구축, 1시간마다 큰 단위로 데이터를 처리, 배치 처리 사이클 전까지 데이터를 볼 수 없어 실시간 집계에는 적합하지 않음 

▪ 스트림 처리는 실시간성이 우수하지만 과거의 데이터를 취급하는 데는 부적합, 앞으로 도달할 데이터에만 흥미가 있다면 스트림 처리가 적합  

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

▪ 배치 처리에서는 데이터를 작게 나눠서 DAG에 흘려 넣음

▪ 스트림 처리에서는 끊임없이 데이터가 생성되며, DAG 안으로 흘러들어옴에 따라 처리가 진행 

▪ 배치 처리와 같이 실행 시 데이터양이 정해지는 것을 '유한 데이터(bounded data)'

▪ 스트림 처리와 같이 제한이 없이 데이터가 보내지는 것을 '무한 데이터(undbounded data)'

▪ 데이터를 작게 분할해서 DAG에서 실행한다는 점은 같음 

▪ DAG을 사용한 데이터 플로우에서는 스트림 처리를 위한 DAG을 약간 손봐서 유한 데이터를 읽어 들이도록하면 배치 처리로도 가능 

 

스트림 처리와 배치 처리의 차이

Spark 스트리밍의 DAG

▪ Spark는 원래 배치 처리를 위한 분산 시스템 

▪ 'Spark 스트리밍'이라는 기능이 통합되어 스트림 처리까지 취급하는 프레임워크가 됨 

▪ 스트림 처리는 프로그램을 정지할 때까지 끝없이 실행됨 

▪ 하나의 프레임워크에서 통합적인 데이터 처리를 기술할 수 있다는 점이 데이터 플로우의 장점 

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

▪ 스트림 처리는 프로그램 버그나 일시적인 장애에 의한 과거의 결과를 수정하는 데 있어 문제가 있음 

▪ 다른 문제는 늦게 전송된 데이터를 취급하는데 문제, 집계가 종료한 후에 도착하는 데이터도 있으므로 스트림 처리의 결과는 본질적으로 부정확함 

▪ 이런 문제에 대한 대처 방법은 스트림 처리와 별개로 배치 처리를 실행시켜 후자의 결과가 옳다고 함 

람다 아키텍처

▪ 이를 발전시킨 '람다 아키텍처(lambda architecture)'

▪ 람다 아키텍처에서는 데이터 파이프라인을 3개의 레이어로 구분 

▪ 모든 데이터는 반드시 '배치 레이어(batch layer)'에서 처리 

▪ 과거의 데이터를 장기적인 스토리지에 축적하고, 여러번 다시 집계 가능

▪ 배치 레이어는 대규모 배치 처리를 실행할 수 있지만, 1회 처리에 긴 시간이 걸림

▪ 배치 처리 결과는 '서빙 레이어(serving layer)'를 통해 접근 가능

▪ 서빙 레이어에서 얻어진 결과를 '배치 뷰(batch view)'라고 함, 이는 정기적으로 업데이트되지만 실시간 정보는 얻을 수 없음

▪ 스트림 처리를 하기 위해 '스피드 레이어(speed layer)' 설치, 스피드 레이어에서 얻은 결과를 '실시간 뷰(realtime view)'라고 함

▪ 실시간 뷰는 배치 뷰가 업데이트될 동안까지만 이용되고, 오래된 데이터 순으로 삭제 

▪ 마지막으로 배치 뷰와 실시간 뷰 모두를 조합하는 형태로 쿼리 실행 

▪ 스트림 처리의 결과는 일시적으로 사용하고, 배치 처리에 의해 올바른 결과를 얻을 수 있음 

 

람다 아키텍처

 

카파 아키텍처

▪ 람다 아키텍처의 스피드 레이어와 배치 레이어는 모두 같은 처리를 하고 있음으로 구현하기 번거로움 

▪ 람다 아키텍처를 단순화한 '카파 아키텍처(kappa architecture)'

▪ 스피드 레이어만을 남기고 배치 레이어와 서빙 레이어를 제거

▪ 메시지 브로커의 데이터 보관 기간을 충분히 길게 해서 문제가 발생하면 메세지 배송 시간을 과거로 다시 설정

▪ 과거의 데이터가 다시 스트림 처리로 흘러 들어 재실행이 이루어짐 

▪ 카파 아키텍처의 문제점은 부하가 높아짐, 스트림 처리의 데이터 플로우에 대량의 과거 데이터를 흘려보내면 일시적으로 많은 자원을 소비 

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

▪ 스트림 처리에서 프로세스 시간과 이벤트 시간의 차이가 발생하는 문제를 '아웃 오브 오더(out of order)'의 데이터 문제라고 불림  

원래 데이터의 모습은 '이벤트 시간'으로 얻을 수 있다

▪ 스트림 처리는 기본적으로 프로세스 시간에 의한 실시간 데이터 처리

▪ 시스템 상의 이유로 스트림 처리가 일시적으로 멈춘 후에 다시 재가동할 경우 쌓여있던 데이터 처리가 재개되면 데이터 양이 변화가 있는 것처럼 보일 수 있음

▪ 데이터가 처음에 생성된 시간인 '이벤트 시간'으로 집계해야 올바른 결과를 얻을 수 있음

이벤트 시간 윈도윙 

▪ 스트림 처리에서는 시간을 일정 간격으로 나누어 '윈도우(window)'를 만들고 그 안에서 데이터 집계 

▪ 이벤트 시간에 의해 윈도우를 나누는 것을 '이벤트 시간 윈도윙(event time windowing)'이라고 함

▪ 메시지가 배송된 데이터는 무작위 순으로 나열된 '아웃 오브 오더' 상태로 순서를 바꿔 집계 결과 업데이트

▪ 과거 이벤트의 상태를 보관하면서, 데이터가 도달할 때마다 해당하는 윈도우를 재집계 

▪ 일정 시간 늦게 온 데이터는 무시할 필요도 있음, 이러한 경우를 고려하며 DAG을 기술 

 

아웃 오브 오더인 이벤트의 집계

 

 

빅데이터를 지탱하는 기술(니시다 케이스케)