[요약 정리] 5-3. 스트리밍 형의 데이터 플로우

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

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

배치처리

• 도달한 데이터를 우선 분산 스토리지에 보관하고, 그것을 정기적으로 추출함으로써 데이터 처리를함
• 데이터가 영속적으로 보존되기 때문에 몇 번이고 재실행 할 수 있음
• 장기적인 데이터 분석을 예상하여 집계 효율이 높은 열 지향 스토리지를 구축할 수 있음
• 배치 처리의 사이클이 올때까지는 데이터를 볼 수 없어 실시간 집계에는 적합하지 않음

 

스트림처리

• 데이터가 도달하는 것과 거의 동시에 처리가 시작됨
• 처리 내용은 미리 정해 둘 필요가 있으며, 과거로 거슬러 올라가 재실시하는 것은 고려하지 않음
• 처리한 결과는 시계열 데이터에 적합한 데이터 스토어에 보관하거나, 기존 실시간 시스템에 전송
• 처리 내용을 변경하면 새롭게 도닥한 데이터에는 적용되지만, 이미 처리가 끝난 과거 데이터까지는 변경되지 않음

 

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

• 배치 처리에서는 먼저 데이터가 있고, 데이터를 작게 나눠서 DAG에 흘려 넣음
• 스트림 처리에서는 끊임없이 데이터가 생성되며, 데이터가 DAG에 흘러들어옴에 따라 처리 진행
• 배치 처리와 같이 실행 시에 데이터 양이 정해짐 → 유한 데이터
• 스트림 처리와 같이 제한이 없이 데이터가 보내지는 것 → 무한 데이터
• 스트림 처리를 위한 DAG를 약간 손봐서 분산 스토리지 상의 과거 데이터(유한 데이터)를 읽어 들이도록 하면 그것으로 배치 처리도 할 수 있음

 

※ 스트림 처리에 의한 1차 집계

• 데이터 양이 너무 많아서 전부를 저장하고 싶지 않은 경우 데이터 양을 삭감하기 위한 스트림 처리를 사용할 수 있음
• 스트림 처리의 결과는 메시지 브로커에 다시 작성해서 재이용할 수 있음
• 그 후 삭감된 데이터를 일반 메시지 전송처럼 한편에서 배치 처리를 위해 분산 스토리지에 보관하고, 다른 쪽에선 실시간 보고서를 위해 시계열 데이터베이스 등에 전송할 수 있음

 

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

- 스트림 처리의 두 가지 문제에 대한 대처

• 틀린 결과를 어떻게 수정할 것인가, 늦게 전송된 데이터 취급 → 스트림 처리의 잠재적인 두 문제
• 전통적인 대처는 스트림 처리와는 별개로 배치 처리를 실행시켜 배치 처리의 결과가 옳다고 하는 것

 

람다 아키텍처 - 배치 레이어, 서빙 레이어, 스피드 레이어

• 배치 레이어
  • 모든 데이터는 반드시 배치 레이어에서 처리
  • 과거의 데이터를 장기적인 스토리지에 축적하고, 여러 번이고 다시 집계할 수 있게 함
  • 배치 레이어는 대규모 배치처리를 실행할 수 있는 반면, 1회 처리에는 긴 시간이 걸림
• 서빙 레이어
  • 배치 처리 결과는 서빙 레이어를 통해 접근
  • 응답이 빠른 데이터베이스를 설치하여 집계 결과를 바로 추출
  • 서빙 레이어에서 얻어진 결과를 배치 뷰 라고 함
  • 배치 뷰는 정기적으로 업데이트되지만, 실시간 정보를 얻을 수 없음
• 스피드 레이어
  • 실시간 정보를 얻기 위해 다른 경로로 스트림 처리를함
  • 스피드 레이어에서 얻은 결과를 실시간 뷰 라고 함
  • 실시간 뷰는 배치 뷰가 업데이트될 동안까지만 이용되고, 오래된 데이터는 순서대로 삭제됨
• 장점
  • 실시간 뷰의 결과는 나중에 배치 뷰로 치환됨
  • 스트림 처리의 결과는 일시적으로만 사용되고, 잠시 기다리면 배치 처리에 의해 올바른 결과를 얻을 수 있음

 

카파 아키텍처

• 람다 아키텍처에서 스피드 레이어만 남김
• 메시지 브로커의 데이터 보관 기간을 충분히 길게 하여 문제 발생 시 메시지 배송 시간을 과거로 재설정
• 그러면 과거의 데이터가 다시 스트림 처리로 흘러 들어 실질적으로 재실행이 이루어짐
• 스트림 처리의 내용이 멱등으로 되어 있으면 출력 데이터가 덮어씌워져 새로운 결과로 다시 쓰임
• 배치 처리와 같은 과거 데이터의 일괄 처리를 스트림 처리만으로 실행할 수 있음
• 부하가 높아짐

 

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

• 프로세스 시간과 이벤트 시간의 차이(늦게 도착하는 메시지) → 아웃 오브 오더

 

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

• 프로세스 시간으로 집계하면 원래 데이터의 모습을 알 수 없음
• 데이터가 처음 생성된 시간(이벤트 시간)으로 집계해야 올바른 결과를 얻을 수 있음

 

이벤트 시간 윈도윙

• 시간을 일정 간격으로 나누어 윈도우를 만들고 그 안에서 데이터 집계
• 이벤트 시간에 의해 윈도우를 나누는 것
• 과거의 이벤트의 상태를 보관하면서, 데이터가 도달할 때마다 해당하는 윈도우 재집계

 

 

[출처]

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