빅데이터처리의 발전단계 (2)

 

 

Contents

1. 실시간 데이터 처리 소개
2. Udemy 데이터 시스템 발전 여정 소개
3. Kafka 소개
4. Kafka 기본 프로그래밍
5. Spark Streaming 소개
6. Spark Streaming + Kafka 프로그래밍
7. 마무리

 

 

Contents

1. 구글이 데이터 분야에 끼친 영향
2. 데이터 처리의 발전 단계
3. 실시간 데이터 종류와 사용 사례
4. 실시간 데이터 처리 챌린지

 

 

 

 

 

 

 

데이터 처리의 발전 단계

빅데이터 처리가 배치 중심에서 어떻게 실시간으로 발전했는지 살펴보자

 

 

 

 

 

 

 

배치 처리

 

주기적으로 데이터를 한 곳에서 다른 곳으로 이동하거나 처리

여기서의 주기는 보통 daily나 hourly 더 짧다면 분 단위입니다. 다만 5분 이하의 경우라면 Airflow로도 버거워지기 시작합니다.

 

처리량(Throughput)이 중요

 

 

 

 

 

 

 

 

 

 

 

데이터 배치 처리

 

처리 주기는 보통 분에서 시간, 일 단위

 

데이터를 모아서 처리

 

처리 시스템 구조

분산 파일 시스템(HDFS, S3)
분산 처리 시스템(MapReduce, Hive/Presto, Spark DataFrame, Spark SQL)
처리 작업 스케줄링에 보통 Airflow 사용

 

 

 

 

 

 

 

 

 

 

 

 

 

 

실시간 처리

 

연속적인 데이터 처리

realtime vs. semi-realtime (micro batch)

 

이 경우 지연시간(처리속도, Latency)이 중요

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

데이터 실시간 처리 (1)

 

배치 처리 다음의 고도화 단계

시스템 관리 등의 복잡도가 증가

 

초단위의 계속적인 데이터 처리

이런 데이터를 보통 Event라고 부르며 이벤트의 특징은 바뀌지 않는 데이터라는 점 (Immutable)
계속해서 발생하는 Event들을 Event Stream이라고 부름

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

데이터 실시간 처리 (2)

다른 형태의 서비스들이 필요해지기 시작함

이벤트 데이터를 저장하기 위한 메세지 큐들: Kafka, Kinesis, Pub/Sub, …
이벤트 처리를 위한 처리 시스템: Spark Streaming, Samza, Flink, …
이런 형태의 데이터 분석을 위한 애널리틱스/대시보드: Druid

 

 

 

 

 

 

 

 

 

 

 

 

데이터 실시간 처리 (3)

처리 시스템 구조

a. Producer(Publisher)가 있어서 데이터 생성
b. 생성된 데이터를 메세지 큐와 같은 시스템에 저장

    - Kafka, Kinesis, PubSub 등의 시스템 존재
    - 데이터 스트림(Kafka에서는 토픽이라 부름)마다 별도의 데이터 보유 기한 설정
c. Consumer (Subscriber)가 있어서 큐로부터 데이터를 읽어서 처리
    - Consumer마다 별도 포인터 유지. 다수의 Consumer가 데이터 읽기를 공동 수행하기도 함

 

 

 

 

 

 

 

 

 

 

 

검색엔진의 데이터 처리 - 계속적인 검색 인덱스 업데이트

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

람다 아키텍처 (Lambda Architecture)

 

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

 

여기에도 다양한 아키텍처가 존재. 그 중 2개를 뒤에서 살펴볼 예정

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

람다 아키텍처 (Lambda Architecture)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

람다 아키텍처 (Lambda Architecture)

 

 

 

 

 

 

 

 

 

 

 

 

데이터 실시간 처리의 장점

 

즉각적인 인사이트 발견

 

운영 효율성 향상

 

사고와 같은 이벤트에 대한 신속 대응

 

더 효율적인 개인화된 사용자 경험

 

IoT 및 센서 데이터 활용

 

사기 탐지 및 보안

 

실시간 협업 및 커뮤니케이션

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

데이터 실시간 처리의 단점

 

전체적으로 시스템이 복잡해짐

배치 시스템은 주기적으로 동작하며 보통은 실제 사용자에게 바로 노출되는 일을 하지 않음
실시간 처리의 경우에는 실제 사용자와 관련된 일에 사용될 확률이 더 높기에 시스템 장애 대응이 중요해짐
    - 배치 추천 vs. 실시간 추천
    - DevOps의 영역으로 들어가기 시작함

 

이에 따른 운영 비용 증가

배치처리는 잘못 되어도 데이터 유실 이슈가 적지만 실시간 처리는 데이터 유실의 가능성이 커지기에 항상 데이터 백업에 신경을 써야함

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

데이터 실시간 처리: Realtime vs. Semi-Realtime

 

Realtime

짧은 Latency
연속적인 데이터 스트림
이벤트 중심 아키텍처: 수신 데이터 이벤트에 의해 작업이나 계산이 트리거되는 구조
동적 및 반응형: 데이터 스트림의 변화에 동적으로 대응하여 실시간 분석, 모니터링 및 의사 결정을 수행

 

Semi-Realtime

합리적인 Latency
배치와 유사한 처리 (Micro-batch)
적시성과 효율성 사이의 균형: 처리 용량과 리소스 활용도를 높이기 위해 일부 즉각성을 희생하기도 함
주기적인 업데이트