[TIL] streaming-day 1~4

Day 1

• 배치 처리
  주기적으로 데이터를 한 곳에서 다른 곳으로 이동하거나 처리. 처리량(Throughput)이 중요

• 데이터 배치 처리

  • 처리 주기는 보통 분에서 시간, 일 단위
  • 데이터를 모아서 처리
  • 처리 시스템 구조
    • 분산 파일 시스템(HDFS, S3)
    • 분산 처리 시스템(MapReduce, Hive/Presto, Spark DataFrame, Spark SQL)
    • 처리 작업 스케줄링에 보통 Airflow 사용

• 데이터 실시간 처리

  Realtime	Semi-Realtime
  짧은 Latency	합리적인 Latency
  연속적인 데이터 스트림	배치와 유사한 처리(Micro-batch)
  이벤트 중심 아키텍처 (수신 데이터 이벤트에 의해 작업이나 계산이 트리거되는 구조)	적시성과 효율성 사이의 균형 (처리 용량과 리소스의 활용도를 높이기 위해 일부 즉각성을 희생하기도 함)
  동적 및 반응형 (데이터 스트림의 변화에 동적으로 대응하여 실시간 분석, 모니터링 및 의사 결정을 수행)	주기적인 업데이트

• 이벤트 데이터 모델 전송/저장

  • Point to Point
    Many to Many 방식. Throughput은 중요하지만 Latency가 중요한 시스템에서 사용 가능. 다수의 Consumer들이 존재하는 경우 데이터를 중복해서 보내야 함. Backpressure에 취약한 형태. 이 시스템의 경우에도 Consumer/Subscriber쪽에 작은 버퍼가 존재하지만 곧 부족해짐.
    • 🙄 Backpressure issue란?
      스트리밍 시스템에서 데이터는 일반적으로 일정한 속도로 생성 (Producer). 하지만 가끔 데이터 생성이 폭발적으로 늘어날 수 있음.
      다운스트림 단계(Consumer)에서 적시에 처리되어야 함.
      하지만 들어오는 데이터 속도를 따라잡지 못하면, 시스템에 데이터가 쌓여 지연되면서 메모리 사용량 증가 등으로 잠재적인 시스템 장애 초래 가능
  • Messaging Queue
    Backpressure issue를 해결할 수 있는 방식. 그러나 완전하게 해결은 못함. Producer별로 Topic이 생성됨.
    보통 micro-batch라는 형태로 아주 짧은 주기로 데이터를 모아서 처리하는데, Spark Streaming이 대표적임.

Day 3

• Kafka
  실시간 데이터를 처리하기 위해 설계된 오픈소스 분산 스트리밍 플랫폼, 데이터 재생이 가능한 분산 커밋 로그 (Distributed Commit Log)
  Scalability와 Fault Tolerance를 제공하는 Publish-Subscription (= Producer-Consumer) 메시징 시스템
  High Throughput과 Low Latency 실시간 데이터 처리에 맞게 구현됨
  Retention Period 동안 메시지를 저장

• Kafka Broker
  = Kafka Server, Kafka Node

• Kafka Topic

  • Consumer가 데이터(Message)를 읽는다고 없어지지 않음
  • Consumer별로 어느 위치의 데이터를 읽고 있는지 위치 정보를 유지함
  • Fault Tolerance를 위해 이 정보는 중복 저장됨

• 직렬화 vs 역직렬화

  • 직렬화(Serialization): 데이터나 객체를 바이트로 변환한다는 의미. 객체의 상태를 저장하거나 전송할 수 있는 형태로 변환하는 프로세스. 보통 이 과정에서 데이터 압축 등을 수행. 가능하다면 데이터의 스키마 정보 추가
  • 역직렬화(Deserialization): Serialized된 데이터를 다시 사용할 수 있는 형태로 변환하는 Deserialization. 이 과정에서 데이터 압축을 해제하거나 스키마 정보 등이 있다면 데이터 포맷 검증도 수행

Day 4

• kafka-console-consumer
  커맨드라인을 통해 Topic에서 Message 읽기 가능.
  --from-beginning 옵션이 있으면 처음부터 읽음(Earliest), 아니면 latest로 동작

• ksqlDB
  REST API나 ksql 클라이언트 툴을 사용해서 Topic을 테이블처럼 SQL로 조작

• Consumer Group

  • Consumer가 Topic을 읽기 시작하면 해당 Topic내 일부 Partition들이 자동으로 할당됨
  • Consumer의 수 < Partion의 수인 경우: Partition은 라운드 로빈 방식으로 Consumer들에게 할당됨 (하나의 Partition은 하나의 Consumer에게만 할당되므로)
  • 데이터 소비 병렬성 ↑, Backpressure ↓

• Consumer/Producer 패턴
  많은 경우 Consumer는 한 Topic의 메시지를 소비해서 새로운 Topic을 만들기도 함. 즉 Consumer이면서 Producer로 동작