[빅데이터의 파이프라인] 3. 스트리밍 형의 데이터 플로우

---

이 글은 빅데이터를 지탱하는 기술을 읽고 정리한 글입니다.

---

 

 

 

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

---

배치 처리를 중심으로 하는 데이터 파이프라인은 데이터를 분석할 수 있게 될 때까지 시간이 걸린다는 것이다. 그래서 집계 효율을 높이기 위해 열 지향 스토리지를 만드려고 해도 시간이 필요하다. 그래서 몇 초만에 결과를 알 수 있는 데이터 처리를 위해서는 별개의 계통으로 파이프라인을 만들어야 한다.

 

실시간성이 높은 데이터 처리 시스템

- 시스템 모니터링: 서버와 네트워크 상태를 감시하고 시간에 따라 그래프를 표시함

- 로그 관리 시스템: 운영체제의 시스템 이벤트나 로그 파일을 검색해 비정상적인 상태이면 경고를 생성함

- 복합 이벤트 처리(CEP): 다수의 업무 시스템으로부터 내려온 이벤트 데이터를 자동으로 처리함

 

 

배치 처리는 메시지 플로우를 통해 받은 데이터를 분산 스토리지에 부분적으로 보관부터 시작하는 것을 뜻한다. 이때 분산 스토리지에 보관한 것을 정기적으로 추출하면서 데이터를 처리하는데, 데이터가 영속적으로 보존되기 때문에 몇 번이고 재실행을 할 수 있다. 하지만 데이터를 바로바로 처리하지는 않으므로 실시간 집계에는 스트림 처리를 사용하는 것이 좋다.

스트림 처리는 분산 스토리지에 저장하지 않고 처리를 계속하는 것이다. 스트림 처리는 데이터가 오자마자 동시에 처리가 되기 때문에 처리 내용을 미리 정의해야 한다. 이때 처리한 결과는 시계열 데이터에 적합한 데이터베이스에 보관하거나 실시간 시스템에 전송한다. 이때 과거 데이터를 집계할 때는 스트림 처리는 과거로 거슬러 올라가 재실시하는 것을 고려하지 않으므로 배치 처리를 사용해야 한다.

---

 

 

 

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

---

배치 처리에는 데이터 양이 정해져 있으므로 유한 데이터라고 하고, 스트림 처리는 끊임 없이 데이터가 흘러 들어와서 무한 데이터라고 부른다. 둘은 이런 차이점이 있지만 데이터를 작게 분할해 DAG에서 실행한다는 것은 같다. 그래서 DAG를 사용한 데이터 플로우에서는 배치 처리와 스트림 처리를 동일하게 프로그래밍 할 수 있다.

스트림 처리를 살짝 손봐서 배치 처리를 할 수 있는데 Spark가 배치 처리와 스트림 처리 기능을 통합하여 사용하고 있다.

만약 스트림 처리에서 모든 데이터를 저장하고 싶지 않다면 데이터 삭감을 위한 스트림 처리를 사용할 수도 있다.

---

 

 

 

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

---

스트림 처리에는 두 가지 문제가 있는데 스트림 처리에는 시간을 되돌린다는 것은 전혀 고려하지 않으므로 틀린 결과를 어떻게 수정해야할지에 대한 문제가 있다. 나머지 하나는 메시지 배송에 지연이 발생하여 데이터가 늦게 전송되는 것이다. 이 경우에는 데이터의 결과가 부정확해져서 첫번째 문제가 발생할 가능성이 존재한다.

이 두 문제는 배치 처리를 실행하여 데이터가 늦게 전송하는 것을 우선적으로 해결하여 틀린 결과가 나오지 않게 만들 수도 있다. 그래서 이것을 발전시킨 방법이 람다 아키텍처, 카파 아키텍처이다.

 

 

람다 아키텍처

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

1. 배치 레이어

모든 데이터는 반드시 배치 레이어에 장기적으로 축적하고 여러 번 다시 집계할 수 있도록 한다. 배치 레이어에서는 대규모 배치 처리를 실행할 수 있는 반면에 1회 처리에는 긴 시간이 걸린다.

2. 서빙 레이어

배치 처리 결과는 서빙 레이어를 통해서 접근한다. 여기에는 응답이 빠른 데이터베이스를 설치해 집계 결과를 바로 추출할수 있도록 하고, 이렇게 얻어진 결과를 배치 뷰라고 부른다. 배치 뷰는 정기적으로 업데이트 되지만, 실시간 정보를 얻을 수 없다.

3. 스피드 레이어

스피드 레이어에서는 실시간으로 결과를 얻을 수 있는데, 그 결과를 실시간 뷰라고 부른다. 실시간 뷰는 배치 뷰가 업데이트될 동안만 사용하고, 오래된 데이터는 순서대로 삭제 된다.

4. 결과

배치 뷰와 실시간 뷰 모두를 조합시키는 형태로 쿼리를 실행한다. 이러면 최근 집계 결과는 실시간 뷰를 참고하고, 이전 데이터는 배치 뷰를 사용하여 각 처리에 대한 결점을 보완한다.

람다 아키텍처의 장점은 실시간 뷰가 나중에 배치 뷰로 치환되는 것이고, 배치 처리만 안정되게 동작하고 있으면 스트림 처리를 다시 실행할 필요가 없다.

 

카파 아키텍처

람다 아키텍처의 문제점은 배치 레이어나 스피드 레이어가 같은 처리를 하고 있으므로 개발 효율이 좋지 않다. 그래서 람다 아키텍처를 단순화한 카파 아키텍처가 선택될 수 있다.

카파 아키텍처는 배치 레이어와 서빙 레이어를 제거하고 스피드 레이어만 남긴다. 그리고 메시지 브로커의 데이터 보관 기간을 길게하여 문제가 일어나면 메시지 배송 시간을 과거로 다시 설정하여 과거의 데이터가 스트림 처리로 다시 흘러 들어서 재실행과 같은 효과를 얻을 수 있도록 만든다. 이때 스트림 처리의 내용이 멱등으로 되어 있으면 데이터 중복 문제를 피할 수 있게 된다.

하지만 카파 아키텍처의 문제점은 스트림 처리의 데이터 플로우에 대량의 데이터를 보내면 부하가 높아진다는 것이다. 그러나 이것은 최근에 클라우드 서비스 보급 덕분에 부하를 낮출 수 있는 것이 어려운 일이 되지 않게 되었다.

---

 

 

 

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

---

 

스트림 처리에는 늦게 오는 메시지 때문에 올바른 집계 결과를 얻기 힘든 아웃 오브 오더의 데이터 문제가 발생한다.

 

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

스트림 처리는 프로세스에 의한 실시간 데이터 처리이므로 프로세스 시간과 연관되어 있는데, 스트림 처리를 일시적으로 멈추고 재가동을 하면 한번에 데이터가 흘러들어와서 집계 결과가 변한 것처럼 보일 수 있다. 이렇게 된다면 신뢰성이 낮아지기 때문에 데이터가 처음 생성된 시간인 이벤트 시간으로 집계를 해야 올바른 결과를 얻을 수 있다.

 

이벤트 시간 윈도윙

스트림 처리는 일정 시간으로 나누어 윈도우를 만들고, 그 안에서 데이터 집계를 한다. 이벤트 시간에 의해 윈도우를 나누는 것을 이벤트 시간 윈도윙이라고 부르며, 이벤트 시간으로 볼 때 메시지가 배송된 데이터는 시간이 뒤죽박죽으로 나열된 아웃 오브 오더 상태이므로 이것을 적절히 순서를 바꾸어 집계 결과를 업데이트 해야한다.

---