Stream Processing 특징
지연 시간이 가장 적은 데이터 처리 방식이다, 짧은 응답 시간(1ms ~)을 가진다. 그러나 애플리케이션이 요청을 전송한 후 프로세싱 시스템의 응답을 기다려야 한다. 데이터베이스에서는 OLTP(online transaction processing)라고 하며 POS(point of sale) 시스템, 신용카드 시스템, 실시간 추적시스템 등 사용자 요청에 바로 응답을 필요로하는 데이터 처리 방식을 사용 한다.
데이터
Stream Processing은 이벤트 스트림(데이터 스트림, 스트리밍 데이터)이라는 데이터를 가공한다. 이벤트 스트림이란 무엇일까?
무한 데이터- 이벤트 스트림은 끝이 없는 무한(undounded)를 뜻하는 뜻하며, 끊임없이 데이터가 들어오는걸 뜻한다.- 이벤트 스트림에는
순서가 있다 - 본질적으로 이벤트는 다른이벤트 전이나 후에 발생한다. 불변 데이터 레코드- 이벤트 자체는 일단 발생하면변경될 수 없다.- 이벤트 스트림은
재생 가능할 수 있다.
시간
시간(time)은 Stream Processing에서 매우 중요 하다. 이벤트의 앞 뒤를 구분할때 사용 할수도 있고, 어떤 시간을 기준으로 잡느냐에 따라 Stream Processing의 결과물이 다를 수가 있다.
이벤트 시간(event time)- 이벤트가 발생할때 생성된 시간- 로그 추가 시간(log append time) - 메시지 큐에 저장된 시간
- 처리 시간(processing time) - Stream Processing이 처리된 시간
왠만하면 이벤트 시간을 사용 하자.
상태
Stream Processing에서는 여러 Stream을 만들 수가 있다. 각 Stream에는 상태(State)를 갖고 있으며, 애플리케이션이 중단 되거나 다시 시작할때 복구 되도록 해야 한다.
로컬 또는 내부 상태(local or internal state)- 특정 인스턴스에서만 사용할 수 있는 상태- 외부 상태(external state) - 외부 데이터스토어에 저장하며, 지연과 복잡도가 증가 하는 단점이 존재
스트림과 테이블의 이원성
테이블은 레코드의 모음이며, 각 레코드는 기본키로 식별되고 스키마로 정의된 속성들을 갖는다. 테이블에서는 최종 상태만 저장하고 있으므로 특별하게 설계되지 않는한 과거 데이터 이력을 갖고 있지 않는다.
테이블과는 다르게 Stream은 변경 사항의 이력을 포함한다. 테이블에서 Stream으로 변환하기 위해서는 추가(Insert), 변경(Update), 삭제(Delete) 이벤트를 받아서 Stream에 저장한다.
이와는 반대로, Stream을 테이블로 변환하기 위해서는 모든 변경 사항을 테이블에 적용해야 한다. 이것을 Stream의 구체화(materializing)라고 한다.
즉 메모리, 내부 상태 저장소, 외부 데이터베이스 중 하나에 테이블을 생성하고, 스트림의 처음부터 끝까지 모든 이벤트를 읽어서 상태를 변경한다.
그리고 작업이 끝나면 특정 시점의 상태를 나타내는 테이블이 된다.
타임 윈도우(고정된 시간 간격)
대부분의 스트림 작업은 타임윈도우로 수행된다.
- 크기 - 예를 들어, 모든 이벤트의 이동 평균을 매 5분 또는 15분 또는 하루 중의 어떤 타임 윈도우로 산출할 것인지를 나태낸다. 타임 윈도우가 클수록 지연도 커진다.
- 이동 빈도 - 타임 윈도우가 스트림을 따라 이동하는
진행간격(advance interval)시간이 타임 윈도우 크기와 같은 경우를텀블링 윈도우(tumbling window)라고 하며, 다른 경우를호핑 윈도우(hopping window)라고 한다. 모든 레코드를 따라서 이동하는 것을슬라이딩 윈도우(sliding window)라고 한다. - 이벤트 변경 가능 시간 - 예를 들어 00:00-00:05 타임 윈도우의 이동 평균을 산출하였다고 하고, 한 시간이 지난 후에 새로운 추가 이벤트 00:02가 있다고 한다면 00:00-00:05의 타임윈도우 이동 편균 결과값은 달라질 것이다. 또 추가 이벤트를 너무 늦게까지 받게되면 후에 추가된 이벤트는 무시할 수 있다.
출처 - 책 '카프카 핵심 가이드'
