[책정리]빅데이터를 지탱하는 기술 5.3 스트리밍형 데이터플로우

6월 선정도서 - 빅데이터를 지탱하는 기술

선정계기 - 데이터가 쌓이고 흐르는 전체적인 구조를 깊이 있게 이해할 수 있고,

미래의 데이터엔지니어로써 해야하는 업무들의 전반적인 흐름을 파악할 수 있을 것 같아 선정(기대가 된다

 

목차 

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

5-1. 워크플로관리 

5-2. 배치형의 데이터플로우

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

 

---

배치처리 VS 스트림처리

배치처리

도달한 데이터를 분산스토리지에 보관하고, 정기적으로 추출하여 분석할 수 있도록 데이터를 처리한다.

데이터가 영속적으로 보존되기 때문에 몇번이고 재실행가능,

장기적인 데이터분석을 예상하여 집계효율이 높은 열지향 스토리지 구축 가능 

다만 데이터가 분석할 수 있게 될때 즉 데이터를 모아서 열지향 스토리지를 구축할때 까지 시간이 걸린다. 

 

스트림처리

데이터가 도달하는 것과 동시에 분산스토리지를 거치지 않고 '실시간으로' 처리한다.

처리내용을 미리 정해둘 필요가 있으며 과거로 거슬러 올라가 재실시하는 것은 고려하지 않는다. 

처리한 결과는 시계열 데이터에 적합한 데이터스토어에 보관하거나 실시간 시스템에 전송한다. 

 

'실시간'이란?

이벤트 발생 후 몇 초안에는 결과를 알 수 있는것을 실시간이라고 칭한다. 

1시간 후는 실시간보다 배치처리로도 할 수 있다. 

 

어떤 시스템이 실시간에 적합한가?

시스템 모니터링 - 서버와 네트워크의 상태를 감시하고, 그 시간 추이를 그래프로 표시한다.

로그관리 시스템 - OS의 시스템 이벤트나 로그파일을 검색해서 비정상적인 상태라면 경고생성

복합이벤트처리 - 다수의 업무 시스템으로부터 보내온 이벤트 데이터를 자동으로 처리한다.

 

배치처리와 스트림처리는 서로결점을 보완하는 관계

배치처리는 1년이상의 장기적인 데이터분석을 예상한 스토리지를 구축한다. 1시간마다 비교적 큰 단위로 데이터 처리.

배치처리의 사이클이 올때까지는 데이터를 볼 수 없어 실시간 집계에는 적합하지 않다.

반면 스트림처리는 반대로 실시간성이 우수하지만 과거의 데이터를 취급하는데는 부적합하다. 

앞으로의 데이터에만 흥미가 있다면 스트림처리, 과거데이터를 집계하고 싶다면 배치처리 

---

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

유한데이터와 무한데이터

배치처리는 실행시 데이터의 양이 정해진 유한 데이터가 있고, 그것을 작게 나눠서 DAG에 흘려 넣는다. 

스트림처리는 실행시 끊임없이 무한데이터가 생성되며, 그것이 DAG안에 흘려들어옴에 따라 처리가 진행된다.

보내지는 데이터가 다르지만, 데이터를 작게 분할해서 DAG에서 실행한다는 점은 같다. 

 

그래서 DAG를 사용한 데이터플로우에서는 배치처리와 스트림처리를 동일하게 프로그래밍할 수 있다.

배치처리와 스트림처리는 달성하고 싶은 목적이 다르므로 실제로 양쪽에서 같은 코드를 동작시키는 일은 거의 없다.

하지만 이렇게 Spark처럼 하나의 프레임워크에서 통합적인 데이터처리를 기술할 수 있다

---

스트림처리 -> 배치처리 치환

스트림처리의 문제

스트림처리는 아래와 같은 2가지 문제점이 있을 수 있다.

1. 틀린결과를 어떻게 수정할 것인가?

스트림처리는 원치적으로 시간을 되돌릴 수 없다. 새로운 데이터만 처리할 뿐 과거로 거슬러 올라가 재실시할 수 없다.

2. 늦게 전송된 데이터를 어떻게 받을 것인가?

스트림처리를 할 경우 배송지연이 발생할 경우, 이것을 이벤트 시간으로 집계하면 문제가 발생한다. 

집계가 종료한 후에 데이터가 도착하게 된다면 스트림처리 결과는 부정확해질 수 있기 때문.

 

위와 스트림처리의 문제를 해결하기 위해 스트림처리와는 별개로 배치처리를 실행시켜 후자의 결과가 옳다고 한다.

스트림처리의결과는 배치처리의 결과가 나올떄까지 잠정값, 배치처리 결과가 나오면 이걸 확정값으로 분류한다. 

 

람다아키텍쳐

위와 같이 스트림처리의 문제를 해결하기 위한 방법을 발전시킨 방법이다. 

데이터파이프라인을 3개의 레이어로 구분한다. 

1. 배치레이어 

모든데이터는 반드시 배치레이어에서 처리한다.

과거의 데이터를 장기적인 스토리지에 축적하고, 여러번이고 다시 집계 할 수 있게 한다.

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

2.서빙레이어/배치뷰

배치처리결과가 서빙레이어를 통해 접근한다. 

응답이 빠른 데이터베이스를 설칠하여 집계결과를 바로 추출하도록 한다. 

그리고 서빙레이어에서 얻어진 결과가 배치뷰이다.

하지만 배치뷰는 정기적으로 업데이트 되지만 실시간 정보를 얻을 순 없다. 

3.스피드레이어/실시간뷰

스트림처리를 위해 스피드레이어를 설치하고, 그 결과를 실시간 뷰로 받을 수 있다.

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

마지막으로 배치뷰와 실시간뷰를 조합시켜 집계를 수행할 쿼리를 실행한다. 

 

람다아키텍쳐의 장점

실시간 뷰의 결과가 나중에 배치뷰로 치환된다는 것이다.

스트림처리의 결과는 일시적으로만 사용되고, 잠시 기다리면 배치처리에 의해 올바른 결과를 얻을 수 있다.

그래서 스트림처리 문제로 인해 스트림처리 결과가 부정확하더라도 길게보면 문제가 없다.

배치처리만 안정적으로 동작한다면 스트림처리를 다시 실행할 필요가 없다.

 

람다아키텍쳐의 단점

나쁜개발효율

스피드레이어와 배치레이어가 모두 똑같은 처리를 구현하고 있어서 번거롭다. 

그래서 람다아키텍쳐를 단순화한 카파 아키텍쳐가 선택될 수 도 있다.

 

카파(kappa) 아키텍쳐

카파아키텍쳐는 배치레이어,서빙레이어를 제거하고 스피드레이어만 남는다. 

대신 메시지 브로커의 데이터보관기간을 늘려 문제가 발생했을때 메세지 배송시간을 과거로 돌려 재실행을 할 수 있다.

 

하지만 부하가 높아지는 한계점이 존재한다.

스트림처리의 데이터플로우에 대량의 과거데이터를 흘려보내면,

이를 계산하기 위해 평상시보다 훨씬 많은 리소스를 일시적으로 소비한다.

---

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

스트림처리의 문제점을 해결하기 위해 배치처리에만 의존하고 있지 않다. 

늦게 도달하는 메시지 즉 프로세스 시간과 이벤트 시간의 차이까지 문제가 생길 수 있는데

이걸 아웃오브 오더(out of order)의 데이터처리 문제라고 불린다.

---

 

최종정리