Kafka와 Spark Streaming_(1)

실시간 데이터 처리

• 데이터 처리의 일반적인 단계
  • 데이터 수집 (Data Collection)
  • 데이터 저장 (Data Storage)
  • 데이터 처리 (Data Processing)
• 데이터 처리의 고도화
  • 처음에는 배치로 시작
    • 처리할 수 있는 데이터 양이 중요
  • 서비스가 고도화되면 점점 더 실시간 처리 요구가 생기기 시작
    • Realtime 처리 vs Semi Realtime 처리
    • 동일 데이터 소비가 필요한 케이스 증가 : 다수의 데이터 소비자 등장
  • 처리량 (Throughput) vs 지연시간 (Latency)
    • 처리량 : 주어진 단위 시간 동안 처리할 수 있는 데이터의 양 (배치 시스템에서 가장 중요)
       - 처리량이 클수록 처리할 수 있는 데이터 양이 큼 (데이터 웨어하우스에서 중요)
    • 지연시간 : 데이터를 처리하는데 걸리는 시간 (실시간 시스템에서 중요)
       - 시간이 작을수록 응답이 빠름. (프로덕션 DB에서 중요)
    • 대역폭 (Bandwidth) = 처리량 x 지연시간
  • SLA (Service Level Agreement)
    • 서비스 제공업체와 고객 간의 계약 또는 합의
      • 서비스 제공업체가 제공하는 서비스 품질, 성능 및 가용성의 합의된 수준을 개괄적으로 기술
      • SLA는 통신, 클라우드 컴퓨팅 등 다양한 산업에서 사용
    • 사내 시스템들간에도 SLA를 정의하기도 함
      • 지연시간이나 업타임등이 보통 SLA로 사용
         - 업타임이라면 99.9% = 8시간 45.6분
         - API라면 평균 응답 시간 혹은 99% 이상 0.5초 전에 응답이 되어야 함
      • 데이터 시스템이라면 데이터의 시의성 (Freshness)도 중요한 포인트
  • 데이터 배치처리
    • 처리 주기는 보통 분에서 시간, 일 단위
    • 데이터를 모아서 처리
    • 처리 시스템 구조
      • 분산 파일 시스템 (HDFS, S3)
      • 분산 처리 시스템 (MapReduce, Hive/Presto, Spark DataFrame, Spark SQL)
      • 처리 작업 스케줄링에 보통 Airflow 사용

---

• 데이터 실시간 처리
  • 배치 처리 다음의 고도화 단계
    • 시스템 관리 등의 복잡도 증가
  • 초단위의 계속적인 데이터 처리
    • 이런 데이터를 보통 Event라고 부르며 이벤트의 특징은 바뀌지 않는 데이터 (Immutable)
    • 계속해서 발생하는 Event들을 Event Stream이라고 부름
  • 다른 형태의 서비스들이 필요해지기 시작함
    • 이벤트 데이터를 저장하기 위한 메세지 큐 - Kafka, Kinesis, Pub/Sub, ...
    • 이벤트 처리를 위한 시스템 - Spark Straming, Samza, Flink, ...
    • 이런 형태의 데이터 분석을 위한 애널리틱스/대시보드 - Druid
  • 처리 시스템 구조
    • Producer (Publisher)가 있어서 데이터 생성
    • 생성된 데이터를 메세지 큐와 같은 시스템에 저장
      • Kafka, Kinesis, PubSub 등의 시스템 존재
      • 데이터 스트림 (kafka에서는 토픽이라고 칭함)마다 별도의 데이터 보유 기한 설정
    • Consumer (Subscriber)가 있어서 큐로부터 데이터를 읽어서 처리
      • Consumer마다 별도 포인터 유지. 다수의 Consumer가 데이터 읽기를 공동 수행하기도 함
  • 데이터 실시간 처리의 장점
    • 즉각적인 인사이트 발견
    • 운영 효율성 향상
    • 사고와 같은 이벤트에 대한 신속 대응
    • 더 효율적인 개인화된 사용자 경험
    • IoT 및 센서 데이터 활용
    • 사기 탐지 및 보안
    • 실시간 협업 및 커뮤니케이션
  • 데이터 실시간 처리의 단점
    • 전체적으로 시스템이 복잡
      • 배치 시스템은 주기적으로 동작하고 실제 사용자에게 바로 노출되는 일을 하지 않음
      • 실시간 처리의 경우에는 실제 사용자와 관련된 일에 사용될 확률이 높아 시스템 장애 대응이 중요
    • 이에 따른 운영 비용 증가
      • 배치처리는 잘못 되어도 데이터 유실 이슈가 적지만 실시간 처리는 데이터 유실의 가능성이 커 항상 백업에 신경을 써야함
    • Realtime vs Semi-Realtime
      • Realtime
        • 짧은 Latency
        • 연속적인 데이터 스트림
        • 이벤트 중심 아키텍쳐 : 수신 데이터 이벤트에 의해 작업이나 계산이 트리거되는 구조
        • 동적 및 반응형 : 데이터 스트림의 변화에 동적으로 대응하여 실시간 분석, 모니터링 및 의사 결정 수행
      • Semi-Realtime
        • 합리적인 Latency
        • 배치와 유사한 처리 (Micro-batch)
        • 적시성과 효율성 사이의 균형 : 처리 용량과 리소스 활용도를 높이기 위해 일부 즉각성을 희생하기도 함
        • 주기적인 업데이트