Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
Tags
- 네이버
- 웹/모바일
- 네이버 부스트 코스
- 백준 #baekjoon # 2563
- id # tr # 환경변수
- 운영체제론
- Virtual Box 7.0.6
- 부스트캠프
- Ubuntu 20.04
- 보기 편하라고 만든
- 후기
- 8기
Archives
- Today
- Total
Miner
스트리밍 데이터 처리(8) 본문
실시간 데이터 처리 단계
- 이벤트 데이터 모델/스키마 결정
- 이벤트 데이터 전송/저장 - Kafka
- 이벤트 데이터 처리
- 이벤트 데이터 관리 이슈 모니터링과 해결
이벤트 데이터 모델 결정
최소 Primary Key와 Timestamp가 필요!
- 사용자 정보가 필요할 수도 있음
- 이벤트 자체에 대한 세부 정보 필요
이벤트 데이터 모델 전송/저장 (다시** 더 정리할 것)
Point to Point
(다시** 더 정리할 것)
- Many to Many 연결이 필요
Messaging Queue
- 중간에 데이터 저장소를 두고 생산자와 소비자가 decouple된 상태로 작업 - 독립
이벤트 데이터 처리
앞서 데이터 저장 모델과 활용 사례에 데이터 처리 모델도 결정됨
Point-to-Point 형태의 경우
- Consumer쪽의 부담이 커지며 정말 바로바로 데이터가 처리되어야 함(Backpressure) - 데이터 유실의 가능성이 큼
- Low Throughput Low Latency가 일반적
Messaging Queue의 경우
- 보통 micro-batch라는 형태로 아주 짧은 주기로 데이터를 모아서 처리 - Spark Streaming이 대표적
- 다수의 Consumer를 쉽게 만들 수 있다는 장점 존재
- Point-to-Point 보다는 운영이 용이
'데이터 엔지니어링 > 실시간 처리' 카테고리의 다른 글
스트리밍 데이터 처리(7) - Event 데이터 종류/사용 사례 (0) | 2024.02.11 |
---|---|
스트리밍 데이터 처리(6) - 장점/단점 (0) | 2024.02.11 |
스트리밍 데이터 처리(5) - 람다 아키텍처 (0) | 2024.02.11 |
스트리밍 데이터 처리(4) - 처리 시스템 구조 (0) | 2024.02.11 |
스트리밍 데이터 처리(3) - 배치/실시간 (0) | 2024.02.11 |