[Kafka] 실시간 데이터 처리

1980년대 후반 Top-down 방식의 Data Warehouse

 

2000년대 Bottom-up 방식의 Data Lake

 

2010년 중반

오픈소스 Kafka aws Kinesis 구글클라우드 pub/sub

한쪽에는 데이터만드는 데이터 프로듀서(pubsub의 경우 publisher)가 있고 

중앙에 메시지큐에 저장하고 Messaging queue (데이터스트림(토픽)마다 별도의 데이터 보유기한 설정)

반대쪽에 데이터를 소비하는 데이터 컨슈머(pubsub의 경우 subscriber)가 있음(별도 포인터 유지, offset)

실시간 데이터 처리

중앙에 데이터팀이 처리

 

2021년

데이터 매쉬 Data Mesh

중앙에서 관리(인프라)하더라도 현업은 각 부서에서 사용(분산 시스템) 

 

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

- 분산 파일 시스템 HDFS, S3...

- 분산 처리 시스템 MapReduce, Hive/Presto, Spark DataFrame, Spark SQL...

- 처리 작업 스케줄링 Airflow...

 

<-> 실시간 처리(연속적인 데이터 처리, 1분 이내라면 Airflow로 사용하기 보다는 Kafka나 Spark streaming같은 다른 프레임워크 사용 필요) 지연시간(Latency) 중요

Realtime 처리 vs. Semi Realtime(Near Realtime, micro batch) 처리

이벤트(Immutable, 바뀌지 않는 데이터) 발생 처리 vs. 배치처리긴 한데 한번에 옮기는 데이터 양이 적거나 주기가 매우 짧은 경우

계속해서 발생하는 Event를 event stream 라고 하고, 

kafka에서는 topic이라고 부름.

- 데이터 저장하기 위한 메시지 큐들 Kafka, Kinesis, Pub/Sub...

- 이벤트 처리 Spark Streaming, Samza, Flink...

- 데이터분석을 위한 애널리틱스/대시보드  Druid...

 

동일한 데이터 소비에 대해 다수의 컨슈머가 있어도 상관없음 (배치)

vs. 실시간은 문제가 생길 수 도 있음.(Messaging queue 필요) 

 

처리량(Throughput) vs. 지연시간(Latency)

배치시스템(DW) vs. 실시간 시스템(프로덕션 DB) => SLA(Service Level Agreement)

대역폭 Bandwidth = 처리량 X 지연시간

 

람다 아키텍처 Lambda Architecture

배치 레이어와 실시간 레이어 두 개를 별도로 운영

 

이벤트 데이터 모델 1) Point to Point 시스템은 지연시간은 줄지만, 다수의 컨슈머, backpressure? 이슈 취약 문제

완화를 위해 2) Messaging Queue 사용, decouple