빅데이터의 실시간 처리 -TIL230710

📚 KDT WEEK 15 DAY 1 TIL

• 빅데이터의 처리

 

---

 

🟥 빅데이터의 처리

 

처음에는 배치 처리에 초점 > 처리할 수 있는 데이터의 양이 중요

서비스가 고도화되면서 점점 더 실시간 처리 요구가 생기기 시작했다.

 

데이터 처리에서 사용하는 주요 용어 4개

• 처리량(Throughput) : 단위 시간동안 처리할 수 있는 데이터의 양, 데이터 웨어하우스의 배치 시스템에서 중요
• 지연시간(Latency) : 데이터를 처리하는 데 걸리는 시간, 프로덕션 DB처럼 실시간 시스템에서 중요
• 대역폭(Bandwidth) : 처리랑 x 지연시간
• SLA(Service Level Argreement) : 서비스 제공업체와 고객 간의 계약 또는 합의
  • 사내 시스템들간에서도 지연시간이나 업타임등이 SLA로 사용되기도 한다.
  • 데이터 시스템이라면 데이터의 시의성(Freshness)도 중요한 포인트가 된다.
  • ex) API의 평균 응답 시간이 0.5초안에 응답 되어야한다

 

❗ 데이터의 실시간 처리

 

데이터의 배치 처리

• 보통 분에서 시간, 일 단위로 데이터를 모아서 처리 및 저장
• 한번에 모아서 저장하기 때문에 분산 파일 시스템(HDFS, S3 등)을 사용
• 데이터 처리를 위해 분산 처리 시스템(MapReduce, Hive, Spark 등) 및 스케줄링으로 Airflow를 사용

 

데이터 실시간 처리

• 분보다 더 낮은 주기(micro batch)로 연속적인 데이터 처리 => semi-realtime
• 특정한 이벤트를 트리거로 즉시 데이터를 처리 및 저장 => realtime
• 처리량보다 지연시간(처리속도, Latency)가 중요
• 배치 처리 다음의 고도화 단계로, 시스템 관리 등의 복잡도가 증가한다.

 

실시간 데이터 처리의 일반적인 방법

 

1. 데이터 생성자(Producer, Publisher)가 데이터 생성

2. 연속해서 발생하는 데이터를 시간순으로 정렬되어 Message Queue(or Event Stream)에 저장

3. 이 데이터를 데이터 소비자(Consumer, Subscriber)가 읽게 됨

 

이 초단위의 계속적인 데이터 처리에서 데이터를 Event라고 부르며, Immutable한 특성이 있다.

 

++) 이 실시간 처리를 위한 서비스들

이벤트 데이터를 저장하기 위한 메시지 큐들 : Kafka, Kinesis..

이벤트 처리를 위한 처리 시스템 : Spark Streaming, Samza...

실시간 데이터 분석 대시보드 : Druid(오픈소스)

 

📌 실시간 데이터 처리의 장단점

 

실시간 처리의 장점

• 즉작적인 인사이트 발견 및 이벤트에 대한 신속 대응
• 운영의 효율성 향상과 효율적인 개인화된 사용자 경험
• IoT 및 센서 데이터에 활용 및 탐지와 보안 기능성

 

실시간 처리의 단점

• 배치 시스템과 다르게 실제 사용자와 관련된 일에 사용될 확률이 높아 시스템 장애 대응이 중요
• 이에 따른 운영 비용 증가 : 데이터 유실 가능성이 커짐에 따라 항상 백업에 신경써야함

 

🆚 Realtime vs Semi-Realtime

 

Realtime

• 짧은 Latency, 거의 즉각 반응
• 연속적인 데이터 스트림
• 이벤트 중심 아키텍처 : 수신 데이터 이벤트에 의해 작업이나 계산이 트리거되는 구조 ex) 신용카드의 사용
• 동적 및 반응형 : 데이터 스트림의 변화에 동적으로 대응하여 실시간 분석

 

Semi-Realtime

• 합리적인 Latency, 일반적인 배치보다는 짧은 주기
• 배치와 유사한 처리(하지만 micro-batch)
• 적시성과 효율성 사이의 균형을 맞춰 사용 > 리소스 활용도를 높이기 위한 즉각성의 희생

 

---

 

🎇 람다 아키텍처(Lambda Architecture)

배치 레이어와 실시간 레이어 두 개를 별도로 운영하는 아키텍처

 

Lambda Architecture

 

🆚 실시간 데이터 처리 방법 두 가지

 

1. Point to Point

Producer가 Consumer에게 데이터를 바로 보내는 형태

• Throughput도 중요하지만 Latency가 중요한 시스템에서 사용 가능 (보통 API)
• 다수의 Consumer들이 존재하는 경우 데이터를 중복해서 보내야함
• BackPressure에 취약함

 

2. Messaging Queue

Producer가 생성한 데이터가 Message Queue를 거쳐 Consumer가 소비하는 형태

• Producer와 Consumer가 독립적인 형태로 사고 위험이 적음
• 아주 짧은 주기(micro-batch)로 데이터를 모아서 처리 > ex) Spark Streaming
• 다수의 Consumer를 쉽게 만들 수 있으며 Point-to-Point보다 운영이 용이

 

♠ BackPressure

 

데이터 생성자가 데이터를 생성하는 빈도가 데이터 소비자의 데이터 소비 빈도보다 높아 데이터가 밀리는 문제

 

Message Queue를 중간에 도입하는 것으로 어느정도 방지 가능 >> Kafka

Consumer에게 Buffer라는 작은 공간이 있긴하지만, 이건 금방참

 

BackPressure