CheckPoint Kafka Streams가 시작되면, Kafka Streams는 GlobalStreamThread / StreamThread의 StateStore를 초기화한다. StateStore를 초기화 할 때 체크 포인트 파일이 존재하는지를 확인한다. 체크 포인트 파일은 StateStore에 플러쉬되고 change-log 토픽에 쓰여진 가장 최신의 레코드에 대한 Offset을 저장하고 있다. 따라서 Kafka Streams가 시작할 때 체크 포인트 파일이 존재하고, 특정 change log 토픽의 파티션에 대한 체크포인트가 존재한다면 StateStore는 체크포인트 파일에 존재하는 오프셋으로 설정되게 된다. 만약 체크포인트 파일이 존재하지 않으면 복구는 가장 처음 오프셋부터 시작된다. CheckP..
GlobalKTable vs KTable GlobalKTable은 Kafka Streams DSL에서 지원하는 KTable이다. 일반적으로 제공되는 KTable과는 다음 차이가 존재한다. KTable은 해당 노드에 할당된 파티션의 데이터만 읽어와서 StateStore에 보관한다. GlobalKTable은 모든 파티션의 데이터를 읽어와서 StateStore에 보관한다. 이런 특징 때문에 GlobalKTable은 파티셔닝에 대한 신경을 쓰지 않아도 된다는 장점이 있다. 반면, 카프카 스트림즈의 모든 클러스터는 각각 토픽의 전체 파티션을 모두 읽어와서 각 노드에 각각의 StateStore를 가지고 있게 된다. GlobalKTable은 읽어온 Table을 Local 스토리지를 이용해서 StateStore에 보관..
들어가기 전 이번 포스팅에서는 Kafka Streams에서 Session Window를 이용해서 집계를 했을 때, 실제 집계 동작이 어떻게 이루어지는지를 오픈소스 코드를 뜯어보며 이해하고자 한다. 알아두면 좋은 것 Session Window는 새로 들어온 메세지들에 대해서 비활성 시간을 바탕으로 같은 세션 윈도우에 묶일 수 있는지를 확인한다. 이 때 사용되는 개념은 In-activate Time과 Grace Period Time이다. 아래 그림에서는 실제 코드를 두 가지 경우로 나눠서 확인해보고자 한다. Record가 도착하면 Window StateStore에서 현재 Record Timestamp를 기준으로 In-activate Time 간격 내에서 조회되는 모든 Session Window를 가져온다. ..
들어가기 전 Kafka Streams에서 스트림의 레코드 처리는 하나의 레코드씩 깊이 우선으로 처리를 하고 있다. 생성된 Topology가 다양한 형태로 되어있다고 하더라도 하나의 레코드를 기준으로 깊이 우선으로 처리를 한 후에 다음 레코드를 처리하는 형태다. 이번 포스팅에서는 간단한 Join 메서드를 이용해서 Topology를 구현하고, 해당 Topology에서 실제 구현은 어떻게 되는지를 살펴보고자 한다. 각 스트림의 Join 실행 방식 왼쪽 그림처럼 Topology를 생성하고 스트림 프로세스를 시작한다고 가정해보자. 오른쪽 그림은 Topology를 만족하기 위해서 실제로 생성되는 Stream들을 의미한다. 실제로는 각각의 Stream으로 나누어져서 동작하는 구조를 가진다. 그리고 서두에서 이야기한 ..
이 글은 Kafka Streams In Action 5장을 공부하고 정리한 글입니다. 들어가기 전 Stream은 끊임없는 이벤트의 흐름이다. Table은 어떤 처리(집계)등을 통해서 현재 상태를 보여주는 역할을 한다. Table은 Stream과는 꽤 다른 방식으로 동작하기도 하지만, Stream과 Join하면서 Stream에 또 다른 문맥을 추가해주는 역할을 할 수 있다. 때로는 Table은 Stream으로 바뀌어서 최신 데이터들만 Stream 하는 녀석도 될 수 있다. 5.1 스트림과 테이블의 관계 스트림은 연속적인 이벤트의 흐름이고, 테이블은 연속적인 이벤트들의 현재 상태를 나타낸다. 아래에서 좀 더 자세히 살펴보고자 한다. 5.1.1 레코드 스트림과 DB의 테이블 예를 들어 위와 같이 주가에 대한 ..