[Kafka streams] 컨셉

참고 : 공식홈페이지 Apache Kafka - Concepts

Apache Kafka

 

 

1. kafka streams란?

• kafka에 저장된 데이터를 분석하고 작업하기 위한 client library
• 확장을 할때는 작성한 application을 단지 여러개의 인스턴스를 실행하기면 하면 된다. kafka streams가 로드 밸런싱을 알아서 해준다.

 

2. kafka streams의 장점

• 간단하고 가벼운 library
• kafka를 제외하고 추가적인 종속성이 불필요하다. 확장시에도 추가적으로 할것이없다.
• 내결함성이다. (중간에 작업이 실패하더라도 재시도 및 정상 동작이 가능하다 - 내 의견)
• 1개의 데이터는 1번만 처리하도록 보장된다. 
• 한번에 하나의 레코드만 처리하므로, 레코드 시간 기반 관련 작업이 가능하다
• high-level Streams DSL과 low-level Processor API를 제공한다.

 

3. Stream Processing Topology란?

• stream processing application 
  - kafka streams library를 사용하는 프로그램이다
  - 이 프로그램은 1개 이상의 processor topologies를 통해 로직을 정의한다.
• processor toplogy
  - streams와 연결된 stream processors의 그래프이다.
• stream processor
  - processor topology 속 노드 개념이다.
  - stream data를 처리하는 작업 단계라고 할 수 있다.
• topology의 대표적인 2가지 processor
  • Source Processor : 이전 processor가 없고, kafka topic 들로부터 input stream을 만들고 다음 processor로 넘김
  • Sink Processor : 다음 processor가 없고, 받은 stream을 kafka topic에 보낸다

• 2가지 processing topology 작성 방법을 제공
  • Kafka Streams DSL : map, filter, join, aggregations과 같은 일반적인 방법 제공
  • Processor API : custom processors를 만들 수 있게 해준다. 

 

4. Time

• Time은 windowing 등을 할때 중요한 요소이다
• Time 종류
  • Event time : 현장에서 event 또는 record가 생성된 시각
  • Ingestion time : kafka topic에 저장된 시각. event time과 다를 수 있다.
  • Processing time : stream processing application에 처리 시작 시각
• 함수 처리 시 어떤 time을 기준으로 할지는 kafka 설정으로 선택할 수 있다.
• kafka streams는 TimestampExtractor를 통해 모든 record에 timestamp를 부여한다. 이 시간을 활용할 수도 있다.
• kafka streams는 kafka에 새로운 records를 쓸때도 timestamp를 부여한다.
  • input record 작업을 통해 만들어지는 경우 input record로부터 상속받은 시각
  • periodic function을 통해 만들어지는 경우 현재시각
  • aggregations의 경우 여러 input records 중 가장 큰 시각
  • Processor API로 custom
  • aggregations & Join의 경우
    • join의 경우 left, right record 중 max 시각
    • stream-table join의 경우 stream record의 시각
    • aggregations의 경우 모든 records 중 max 시각
    • 상태 비저장 연산의 경우 input record 시각을 상속 받음. ex) flatMap

 

5. Duality of Streams and Tables (stream과 table의 이중성, stream ≈ table)

실제로 구현하다보면 stream과 database가 필요하다. 그러므로 stream 처리기술은 stream과 table에 대해 최고수준의 지원을 해야한다. stream과 table은 가까운 관계인데, 이것이 흔히 말하는 stream-table duality 이다. kafka는 이 duality를 많곳에서 사용한다.

ex) 내결함성 상태저장 처리, 최신 처리결과 저장 등 개발자들이 이 duality를 사용할 수 있도록 Kafka Streams API를 지원한다.

• Table 같은 Stream
  stream은 table의 changelog라고 생각될 수 있다. 처음부터 끝까지 stream을 재생하면 table이 만들어질 수 있다. 비슷하게 aggregation 또한 table로 볼 수 있다.
• Stream 같은 Table
  table은 가장 최근값의 snapshot이라고 할 수 있다. Table의 변화 과정을 따라가면 Stream을 만들 수 있다.

예를 들어, 변경 데이터 캡처(CDC)를 통해 데이터베이스를 복제하는 데에도 동일한 메커니즘이 사용되며, 내결함성을 위해 카프카 스트림 내에서 소위 상태 저장소를 여러 머신에 복제하는 데에도 동일한 메커니즘이 사용된다. 스트림-테이블 이중성은 매우 중요한 개념으로, 카프카 스트림은 KStream, KTable, GlobalKTable 인터페이스를 통해 이를 명시적으로 모델링한다.

 

 

6. Aggregations(집계)

• 집계를 위해 1개의 input stream 또는 table이 필요하다.
  records를 1개의 ouput record로 결합하여 테이블을 새로 만든다. ex) count or sum
• kafka Streams DSL에서 aggregation의 input stream은 KStream이나 KTable이 될 수 있다.
  하지만 output stream은 항상 KTable이다. 이를 통해 순서를 벗어난 record가 왔을 때도 집계 값을 업데이트할 수 있다.

 

7. Windowing (그룹핑)

• Windowing이란 stateful 동작을 위해 같은 key를 가진 records들을 aggregations 또는 join 등을 통해 제어하는 것이다.
• Windowing operations는 Kafka Streams DSL에서 사용 가능하다. windows를 사용할 때 grace period를 정할 수 있다. grace period란 얼마나 오래 데이터를 기다려 줄지 제어하는 것이다. 만약 유예 기간이 지난 후에 레코드가 도착하면 폐기된다.

 

8. States

• Kafka Streams는 소위 state stores를 제공한다. data를 저장하고 쿼리하는데 사용한다. Kafka Stream의 모든 작업에서 사용된다.
• state store는 영구 key-value 저장, 메모리 hash map 등이 사용될 수 있다.
• local state stores에 대해 자동 복구, 내결함성 등을 제공한다.
• Kafka streams는 state stores에 대해 외부(methods, threads, process, apllications 등)의 직접 읽기 전용 쿼리를 허용한다. Interactive Queries 라는 기능을 통해 제공된다.

 

9. Processing guarantees

• 0.11.0.0 버전 부터 end-to-end exactly-once processing을 보장한다. 도중에 장애가 발생하더라도 각 레코드가 한 번만 처리된다. topic에서 record를 읽으면 processing 결과는 한개만 나오도록 보장한다. (output kafka topic, state stores 결과물 등)
• 2.6.0 부터 “exactly-once v2”가 나오면서 더 효율적으로 변했다.
• 정확히 한 번 동작을 활성화 하려면 processing.guarantee 설정값을 default값인 at_least_once에서 StreamsConfig.EXACTLY_ONCE_V2로 변경하면 된다. (broker는 2.5버전 이상 필요)

 

10. Out-of-Order Handling 순서가 잘못된 데이터 처리

• 2가지 경우
  • 순차적으로 들어온 record의 timestamp가 순차적이지 않은 경우
  • multiple topic-partitions 을 사용해 작업하는 경우. ( 필요한 partition-topic의 데이터가 모두 들어올 때까지 기다리지 못한 경우)
• stateless 작업은 큰 영향이 없다. stateful 작업(이전 상태 저장이 필요한 작업)은 문제가될 수 있다.
• (아래내용은 요약하기가 애매하여 번역) 사용자가 이러한 순서가 맞지 않는 데이터를 처리하려면 일반적으로 애플리케이션이 더 오랜 시간 대기하도록 허용하면서 대기 시간 동안 상태를 기록해야 한다. 즉, 지연 시간, 비용, 정확성 사이에서 절충점을 찾아야 한다. 특히 카프카 스트림에서는 사용자가 윈도우 집계에 대한 윈도우 연산자를 구성하여 이러한 절충점을 달성할 수 있다. 조인의 경우, 사용자는 아직 스트림에서 지연 시간과 비용을 증가시켜서 순서가 맞지 않는 데이터 중 일부를 처리할 수 없다는 점에 유의해야 한다
  • stream-stream join : 모든 join은 out-of-order records를 맞게 다룬다. 하지만 결과 stream은 불필요한 것들 포함하고 있을 수 있다. ( leftRecord-null(left join), leftRecord-null(outer join), null-rightRecord(outer join) )
  • stream-table join : out-of-order records는 다뤄지지 않는다.
  • table-table join : out-of-order records는 다뤄지지 않는다. 하지만 결과는 변경 로그 stream이므로 일관성은 유지 된다.
  •