Code의 경우, Python을 이용하여 컨버팅하려고 하였으나, faust에서 Null 키에 대해 오류가 많이 발생하여 우선은 코드 변환 패스
카프카 스트림즈
카프카 스트림즈는 토픽에 적재된 데이터를 상태/비상태 기반으로 실시간 변환하여 다른 토픽에 적재하는 라이브러리이다. 컨슈머와 프로듀서의 조합으로 스트림즈 제공하는 기능과 유사하게 만들 수는 있으나, 장애 허용 시스템, 데이터 처리등의 특징 들은 2개의 조합으로 완벽하게 구현하기 어렵다. 하지만 스트림즈에 없는 기능의 경우 위의 2개를 이용해서 개발할 수도 있다.
스트림즈에서 task는 스트림즈 애플리케이션을 실행하면 생기는 데이터 처리 최소 단위이다. 만약 3개의 파티션으로 이루어진 토픽을 처리하는 스트림즈 애플리케이션을 실행하면 내부에 3개의 태스크가 생긴다.
실제 운영환경에서는 실행되는 서버 장애가 발생하더라도 안전하게 스트림 처리를 할 수 있게 2개 이상의 서버로 구성하여 스트림즈 애플리케이션을 운영한다.
카프카 스트림즈에서 토폴로지를 이루는 노드를 processor, 노드와 노드를 잇는 선을 stream이라고 부른다. 스트림의 경우, 토픽의 데이터를 뜻하며 프로듀서 컨슈머에서 활용했던 레코드와 동일하다. 프로세서는 총 3개로 나뉘며 아래와 같다.
- 소스 프로세서
데이터를 처리하기 위해 최초로 선언해야 하는 노드로, 하나 이상의 토픽에서 데이터를 가져오는 역할 - 스트림 프로세서
다른 프로세서가 반환한 데이터를 처리하는 역할(변환, 분기 처리 등과 같은 로직) - 싱크 프로세서
데이터를 특정 카프카 토픽으로 저장하는 역할
스트림즈의 경우 2가지 방법으로 개발 가능하며 데이터 처리 예시는 아래와 같다.
- 스트림즈 DSL
- 메시지 값을 기반으로 토픽 분기 처리
- 지난 10분간 들어온 데이터의 개수 집계
- 토픽과 다른 토픽의 결합으로 새로운 데이터 생성
- 프로세서 API
- 메시지 값의 종류에 따라 토픽을 가변적으로 전송
- 일정한 시간 간격으로 데이터 처리
Streams DSL(Domain Specific Language)
KStream
KStream은 레코드의 흐름을 표현한 것으로 메시지 키와 값으로 구성되어 있다. KStream으로 데이터를 조회하면 토픽에 존재하는 모든 레코드가 출력되며, 컨슈머로 토픽을 구독하는 것과 동일한 선상에서 사용하는 것이라고 볼 수 있다.
(약간 CDC 데이터와 같은 느낌 같음..)
KTable
KTable은 메시지 키를 기준으로 묶어서 사용한다. 토픽의 모든 레코드를 조회할 수 있으나 유니크한 메시지 키를 기준으로 가장 최신 레코드를 사용한다. 따라서 KTable로 데이터를 조회시 메시지 키를 기준으로 가장 최신에 추가한 레코드의 데이터가 출력된다.
(약간 python의 dict형식 같음)
GlobalKTable
GlobalKTable은 KTable과 동일하게 메시지 키를 기준으로 묶어서 사용하지만, KTable로 선언된 토픽은 1개 파티션이 1개 테스크에 할당되어 사용되고, GlobalKTable로 선언된 토픽은 모든 파티션 데이터가 각 테스크에 할당되어 사용된다는 차이가 있다.
GlobalKTable 설명의 가장 좋은 예는 KStream과 KTable이 join을 수행할 때다. 이 때 반드시 co-partitioning이 되어 있어야 하는데, 이는 join을 하고자 하는 2개의 데이터의 파티션 개수 및 partitioning strategy(파티셔닝 전략)을 동일하게 맞추는 작업이다.(코파티셔닝이 안된 2개의 토픽 join 시 ToplologyException 발생)
만약 KStream, KTable이 코파티셔닝이 되어 있지 않으면 repartitioning이 이루어져야 한다. 이 때 데이터 중복 생성 뿐만 아니라 프로세싱하는 과정도 거쳐야 한다. KTable을 GlobalKTable로 선언하여 사용하게 되면, GlobalKTable로 정의된 데이터는 스트림즈 애플리케이션의 모든 테스크에 동일하게 공유되어 사용되기 때문에 코파티셔닝 되지 않은 KStream과 데이터 조인이 가능하다.
GlobalKTable을 사용하면 GlobalKTable로 정의된 모든 데이터를 저장하고 사용하기 때문에 스트림즈 애플리케이션의 로컬 스토리지의 사용량이 증가하고 네트워크, 브로커에 부하가 생기므로 되도록 작은 용량의 데이터일 경우에만 사용하는 것이 좋다.(만약, 많은 양의 데이터를 가진 토픽으로 조인할 경우 리파티션을 통해 KTable로 사용하는 것을 권장)
Processor API
스트림즈 DSL보다 투박한 코드를 가지지만 토폴로지를 기준으로 데이터를 처리한다는 관점에서는 동일한 역할을 한다.
