데이터 처리의 일반적인 단계
- 데이터 수집 (Data Collection)
- 데이터 저장 (Data Storage)
- 데이터 처리 (Data Processing)
이 과정에서 서비스 효율을 높이거나 의사결정을 더 과학적으로 하게 됨
데이터 처리의 고도화
- 처음에는 배치로 시작
- 처리할 수 있는 데이터의 양이 중요 (얼마나 큰 데이터를 한꺼번에 처리할 수 있는가)
- 서비스가 고도화되면서 실시간 처리 요구가 생기기 시작
- Realtime 처리 vs Semi Realtime 처리
- 동일 데이터 소비가 필요한 케이스 증가: 다수의 데이터 소비자 등장
처리량(Throughput) vs 지연시간(Latency)
- 처리량(Throughput): 주어진 단위 시간 동안 처리할 수 있는 데이터의 양
- 클수록 처리할 수 있는 데이터의 양이 큼
- 배치 시스템에서 더 중요 (ex. 데이터 웨어하우스)
- 지연시간(Latency): 데이터를 처리하는 데 걸리는 시간
- 작을수록 응답이 빠름
- 실시간 시스템에서 더 중요 (ex. 프로덕션 DB)
- 대역폭 (Bandwidth) = 처리량 x 지연시간
데이터 목적에 따라 어떤 것을 더 고려할 지 달라짐
SLA (Service Level Agreement)
- 서비스 제공업체와 고객 간의 계약 또는 합의
- 서비스 제공업체가 제공하는 서비스 품질, 성능 및 가용성의 합의된 수준을 개괄적으로 기술
- SLA는 통신, 클라우드 컴퓨팅 등 다양한 산없에서 사용됨
- 사내 시스템들간에도 SLA를 정의하기도 함
- 지연시간이나 업타임등이 보통 SLA로 사용됨
- 예를 들어, 업타임이라면 99.9% = 8시간 45.6분
- API라면 평균 응답 시간 혹은 99% 이상 0.5초 전에 응답이 되어야 함
- 데이터 시스템이라면 데이터의 시의성도 중요한 포인트가 됨
- 지연시간이나 업타임등이 보통 SLA로 사용됨
배치 처리
- 주기적으로 데이터를 한 곳에서 다른 곳으로 이동하거나 처리
- 처리량(Throughput)이 중요
데이터 배치 처리
- 처리 주기는 보통 분, 시간, 일 단위
- 데이터를 모아서 처리
- 처리 시스템 구조
- 분산 파일 시스템 (HDFS, S3)
- 분산 처리 시스템 (MapReduce, Hive/Presto, Spark DataFrame, Spark SQL)
- 처리 작업 스케줄링 (airflow)
실시간 처리
- 연속적인 데이터 처리
- realtime vs semi-realtime (micro batch)
- 지연시간(처리속도, Latency)이 중요
데이터 실시간 처리
- 배치 처리 다음의 고도화 단계
- 시스템 관리 등의 복잡도 증가
- 데이터 유실될 확률이 있음
- 초단위의 계속적인 데이터 처리
- 보통 event라고 부르며 이벤트의 특징은 바뀌지 않는 데이터라는 점 (Immutable)
- 계속해서 발생하는 event들을 event stream이라고 함
- 다른 형태의 서비스들이 필요해지기 시작
- 이벤트 데이터를 저장하기 위한 메세지 큐
- ex. Kafka, Kinesis, Pub/Sub, ...
- 이벤트 처리를 위한 처리 시스템
- ex. Spark Streaming, Samza, Flink, ...
- 이런 형태의 데이터 분서을 위한 애널리틱스/대시보드
- ex. Druid
- 이벤트 데이터를 저장하기 위한 메세지 큐
- 처리 시스템 구조
- Producer(Publisher)가 있어서 데이터 생성
- 생성된 데이터를 메세지 큐와 같은 시스템에 저장
- kafka, kinesis, pubsub 등의 시스템 존재
- 데이터 스트림마다 별도의 데이터 보유 기한 설정
- Consumer가 있어서 큐로부터 데이터를 읽어서 처리
- Consumer마다 별도 포인터 유지
- 다수의 Consumer가 데이터 읽기를 공동 수행하기도 함
데이터 실시간 처리의 장점
- 즉각적인 인사이트 발견
- 운영 효율성 향상
- 사고와 같은 이벤트에 대한 신속 대응
- 더 효율적인 개인화된 사용자 경험
- IoT 및 센서 데이터 활용
- 사기 탐지 및 보안
- 실시간 협업 및 커뮤니케이션
데이터 실시간 처리의 단점
- 전체적으로 시스템이 복잡해짐
- 배치 시스템은 주기적으로 동작하며 보통은 실제 사용자에게 바로 노출되는 일을 하지 않음
- 실시간 처리의 경우, 실제 사용자와 관련된 일에 사용될 확률이 더 높기에 시스템 장애 대응이 중요해짐
- 배치 추천 vs 실시간 추천
- DevOps의 영역으로 들어가기 시작함
- 운영 비용 증가
- 배치 처리는 잘못 되어도 데이터 유실 이슈가 적지만 실시간 처리는 데이터 유실의 가능성이 커지기에 항상 데이터 백업에 신경 써야함
반응형
