📒 빅데이터 처리

📌 데이터 처리

데이터 처리의 일반적인 단계

• 데이터 수집 (Data Collection)
• 데이터 저장 (Data Storage)
• 데이터 처리(Data Processing)
  -> 이 과정에서 서비스 효율을 높이거나 의사결정을 더 과학적으로 하게 된다.

데이터 처리의 고도화

• 처음에는 배치로 시작
  -> 이 경우 처리할 수 있는 데이터의 양이 중요하다.

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

  • Realtime 처리 vs. Semi Realtime 처리
  • 동일 데이터 소비가 필요한 케이스 증가 : 다수의 데이터 소비자가 등장

처리량 vs. 지연시간

• 처리량 : Throughput, 주어진 단위 시간 동안 처리할 수 있는 데이터의 양
• 지연시간 : Latency, 데이터를 처리하는 데 걸리는 시간
  -> 작을수록 응답이 빠름을 의미한다. 실시간 시스템에서 더 중요하다 ex) Production DB
• 대역폭 (Bandwidth) = 처리량 X 지연시간

SLA : Service Level Agreement

• 서비스 제공업체와 고객 간의 계약 또는 합의
  • 서비스 제공업체가 제공하는 서비스 품질, 성능 및 가용성의 합의된 수준을 개괄적으로 기술
  • SLA는 통신, 클라우드 컴퓨팅 등 다양한 산업에서 사용된다.
• 사내 시스템들간에도 SLA를 정의하기도 한다.
  • 이 경우 Latency나 Uptime등이 보통 SLA로 사용된다.
    • ex) Uptime 99.9% = 8시간 45.6분
    • API라면 평균 응답 시간 혹은 99%이상 0.5초 전에 응답이 되어야함
  • 데이터 시스템이라면 데이터의 시의성 (Freshness)도 중요한 포인트가 된다.

배치 처리

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

데이터 배치 처리

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

실시간 처리

• 연속적인 데이터 처리
  -> realtime vs. semi-realtime (micro batch)
• 이 경우 지연시간(처리속도, Latency)이 중요하다.

데이터 실시간 처리

• 배치 처리 다음의 고도화 단계
  -> 시스템 관리 등의 복잡도가 증가
• 초단위의 계속적인 데이터 처리
  • 이런 데이터를 보통 Event라고 부르며 Event의 특징은 바뀌지 않는 데이터라는 점이다.(Immutable)
  • 계속해서 발생하는 Event들을 Event Stream이라고 부른다.

• 다른 형태의 서비스들이 필요해지기 시작한다.
  • Event를 저장하기 위한 메세지 큐 : Kafka, Kinesis, Pub/Sub, ...
  • Event 처리를 위한 처리 시스템 : Spark Streaming, Samza, Flink, ..
  • 이런 형태의 데이터 분석을 위한 애널리틱스/대시보드 : Druid

• 처리 시스템 구조
  • Producer(Publisher)가 있어서 데이터 생성
  • 생선된 데이터를 메세지 큐와 같은 시스템에 저장
    • Kafka, Kinesis, PubSub 등의 시스템이 존재한다.
    • 데이터 스트림 (Kafka에서는 Topic이라고 부른다)마다 별도의 데이터 보유 기한을 설정
  • Consumer (Subscriber)가 있어서 큐로부터 데이터를 읽어서 처리한다.
    • Consumer마다 별도 포인터를 유지한다.
    • 다수의 Consumer가 데이터 읽기를 공동으로 수행하기도 한다.

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

• 전체 시스템이 계속적으로 업데이트
• 구글 Page Rank 계산과 같은 부분이 증분
  -> 계산이 가능해짐 -> 람다 아키텍처

1. 웹페이지 접속
2. 웹페이지 콘텐츠 읽기
3. 데이터 저장 -> 데이터 스토리지(분산 파일 시스템)
4. 연속적인 Page Rank 계산과 검색 인덱스 업데이트(분산 컴퓨팅 시스템) -> 검색 인덱스
5. 검색처리

Lambda Architecture

• Batch Layer와 실시간 Layer 두 개를 별도로 운영
• 여기에도 다양한 아키텍처가 존재한다.

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

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

데이터 실식산 처리의 장점

• 즉각적인 인사이트 발견
• 운영 효율성 향상
• 사고와 같은 이벤트에 대한 신속 대응
• 더 효율적인 개인화된 사용자 경험
• IoT 및 센서 데이터를 활용
• 사기 탐지 및 보안
• 실시간 협업 및 커뮤니케이션

데이터 실시간 처리의 단점

• 전체적으로 시스템이 복잡해진다.

  • 배치 시스템은 주기적으로 동작하며 보통은 실제 사용자에게 바로 노출되는 일을 하지 않는다.

  • 실시간 처리의 경우에는 실제 사용자와 관련된 일에 사용될 확률이 더 높기에 시스템 장애 대응이 중요해진다.

    • 배치 추천 vs. 실시간 추천
    • Dev Ops의 영역으로 들어가기 시작한다.

• 운영 비용 증가
  -> 배치 처리는 잘못 되어도 데이터 유실 이슈가 적지만 실시간 처리는 데이터 유실의 가능성이 커지기에 항상 데이터 백업에 신경을 써야한다.

📌 실시간 데이터 처리

실시간 데이터 처리 단계

• Event 모델 결정
• Event 전송/저장
• Evnet 처리
• Event 데이터 관리 이슈 모니터링과 해결

1. Event 모델 결정

• 최소 Primart key와 Timestamp가 필요하다.
  • 사용자 정보가 필요할 수도 있다.
  • Event 자체에 대한 세부 정보가 필요하다.

2. Event 전송/저장

• Point to Point
  -> Many to Many 연결이 필요하다.

• Messaging Queue
  -> 중간에 데이터 저장소를 두고 생산자와 소비자가 decouple된 상태로 작업한다.

Point to Point

• Throughput은 중요하지만 Latency가 중요한 시스템에서 사용 가능하다.
• 많은 API 레이어들이 이런 식으로 동작한다.
• 다수의 Consumer들이 존재하는 경우 데이터를 중복해서 보내야한다.

Messaging Queue

• Producer별로 Topic이 생성된다.

3. Event 처리

• 앞서 데이터 저장 모델과 활용 사례에 데이터 처리 모델도 결정된다.

• Point to Point

  • Consumer쪽의 부담이 커지며 정말 실시간으로 데이터가 처리되어야 한다.(Backpressure)
    -> 데이터 유실의 가능성이 크다.
  • Low Throughput Low Latency가 일반적이다.

• Messaging Queue

  • 보통 micro-batch라는 형태로 아주 짧은 주기로 데이터를 모아서 처리한다.
    -> Spark Streaming이 대표적이다.

  • 다수의 Consumer를 쉽게 만들 수 있다는 장점이 존재한다.

  • Point to Point 보다는 운영이 용이하다.

Backpressure(배압)

• 스트리밍 시스템에서 데이터는 일반적으로 일정한 속도로 생성한다.(Producer)
  -> 가끔은 데이터 생성이 폭발적으로 늘어날 수 있다.

• 다운 스트림 단계(Consumer)에서 적시에 처리되어야 한다.
  -> 들어오는 데이터 속도를 따라잡지 못하면 시스템에 데이터가 쌓여 지연되면서 메모리 사용량 증가 등으로 잠재적인 시스템 장애를 초래할 수 있다.
  -> 이를 Backpressure Issue라고 부른다.

• Backpressure를 줄이는 방법 중의 하나는 중간에 메세지 큐를 도입하는 것이다.
  -> Backpressure문제를 많이 해결할 수 있지만 완전히 해결은 불가능하다.

• Point to Point 시스템의 경우에도 Comsumer/Subscriber쪽에 작은 버퍼가 존재한다.
  -> 하지만 버퍼의 크기가 곧 부족해진다 -> Overflow