데이터 엔지니어링 61일차 TIL

학습 내용

빅데이터 처리의 발전
- 처음에는 배치로 시작
        - 처리할 수 있는 데이터의 양이 중요
- 서비스가 고도화되면서 점점 더 실시간 처리 요구가 생기기 시작
        - Realtime 처리 vs Semi Realtime 처리
        - 동일 데이터 소비가 필요한 케이스 증가 : 다수의 데이터 소비자 등장

처리량(Throughput) vs 지연시간(Latency)
- 처리량 : 주어진 단위 시간동안 처리할 수 있는 데이터의 양
        - 클수록 처리 할 수 있는 데이터의 양이 큼을 의미한다.
        - 배치 시스템에서 더 중요(데이터 웨어하우스)
- 지연시간 : 데이터를 처리하는데 걸리는시간
        - 적을수록 응답시간이 빠름을 의미한다.
        - 실시간 시스템에서 더 중요하다(프로덕션 DB)
- 대역폭(Bandwidth) = 처리량 X 지연시간

SLA(Service Level Agreement)
- 서비스 제공업체와 고객 간의 계약 또는 합의
        - 서비스 제공업체가 제공하는 서비스 품질, 성능 및 가용성의 합의된 수준을 개괄적으로 기술
        - SAL는 통신, 클라우드 컴퓨팅 등 다양한 산업에서 사용된다.
- 사내 시스템들간에도 SLA를 정의하기도 한다.
        - 지연시간이나 업타임등이 보통 SLA로 사용된다.
        - 데이터 시스템이라면 데이터의 시의성(Freshness)도 중요한 포인트가 된다.

데이터 배치 처리
- 주기적으로 데이터를 한 곳에서 다른 곳으로 이동하거나 처리하는 것.
- 처리량(Throughput)이 중요하다.
- 처리 주기는 보통 분에서 시간, 일 단위
- 처리 시스템 구조
        - 분산 파일 시스템(HDFS, S3)
        - 분산 처리 시스템(MapReduce, Hive/Presto, Spark DataFrame, Spark SQL)
        - 처리 작업 스케쥴링에 보통 Airflow사용

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

람다 아키텍쳐(Lambda Architecture)
- 배치 레이어와 실시간 레이어 두 개를 별도로 운영

 

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

데이터 실시간 처리의 단점
- 전체적으로 시스템이 복잡해진다.
        - 배치 시스템은 주기적으로 동작하며 보통은 실제 사용자에게 바로 노출되는 일을 하지 않음
        - 실시간 처리의 경우에는 실제 사용자와 관련된 일에 사용될 확률이 더 높기에 시스템 장애 대응이 중요해진다.
                - 배치 추천 vs 실시간 추천
                - DevOps의 영역으로 들어가기 시작
- 운영비용 증가
        - 배치처리는 잘못되어도 데이터 유실 이슈가 적지만 실시간 처리는 데이터 유실의 가능성이 커지기에 항상 데이터 백업에 신경을 써야한다.

데이터 실시간 처리 : Realtime vs Semi-Realtime
- Realtime
        - 짧은 Latency
        - 연속적인 데이터 스트림
        - 이벤트 중심 아키텍쳐 : 수신 데이터 이벤트에 의해 작업이나 계산이 트리거되는 구조
        - 동적 및 반응형 : 데이터 스트림의 변화에 동적으로 대응하여 실시간 분석, 모니터링 및 의사결정을 수행
- Semi-Realtime
        - 합리적인 Latency
        - 배치와 유사한 처리 (Micro-batch)
        - 적시성과 효율성 사이의 균형 : 처리 용량과 리소스 활용도를 높이기 위해 일부 즉각성을 희생하기도 함
        - 주기적인 업데이트

온라인 서비스
- 온갖 종류의 Funnel Data
        - Product Impressions, Clicks(Click Stream), Purchase 등
        - User Registration
- Page View and Performance Data
        - 페이지별로 렌더링 시간을 기록하면 나중에 문제 발생시 원인 파악이 쉽다.(데스크탑, 모바일 등 디바이스 타입에 따라 기록)
        - 페이지별로 에러 발생시 에러 이벤트 등록
- 사용자 등록, 사용자 로그인, 방문자 발생
- 이런 사용자 행동 데이터들의 데이터 모델 정의와 수집이 중요해짐.
        - 데이터가 제대로 수집된 후에 저장과 소비도 가능
        - 이벤트 데이터 수집만 전담하는 팀도 생기기 시작함

Retail Business
- 재고 업데이트 : 재고 추가 또는 품절과 같은 재고 수준의 변화를 반영하는 이벤트
- 주문 이벤트 : 주문 배치, 주문 상태 업데이트 및 주문 이행을 나타내는 이벤트
- 배송 이벤트 : 배송된 상품의 상태 및 위치 업데이트를 기록하는 이벤트

IoT(Internet of Things)
- 센서 판독값 : IoT 장치에서 수집한 온도, 습도, 압력 등 측정값 기록 이벤트
- 장치 상대 업데이트 : 온라인/오프라인 상태 또는 배터리 잔량과 같은 장치 상태 이벤트
- 알람 이벤트 : 동작 감지나 임계값 초과 등 특정 조건에 의해 트리거되는 이벤트

Even 데이터 처리를 필요로 하는 유스케이스
- Real-time Reporting
        - A/B Test Analytics, Marketing Campaign Dashboard, Infrastructure Monitoring
- Real-time Alerting
        - Fraud Detection, Real-time Bidding, Remote Patient Monitoring
- Real-time Prediction (ML Model)
        - Personalized Recommendation

실시간 데이터 처리 단계
1. 이벤트 데이터 모델 결정
        - 최소 Primary Key와 Timestamp가 필요
        - 이벤트 자체에 대한 세부 정보 필요
2. 이벤트 데이터 전송/저장
        - Point-to-Point 방법
                - Many to Many 연결이 필요
                - Backpressure에 취약함
        - Messaging Queue 방법
                - 중간에 데이터 저장소를 두고 생산자와 소비자가 decouple된 상태로 작업
3. 이벤트 데이터 처리
: 데이터 저장모델과 활용사례에 따라 데이터 처리모델이 결정
        - Point to Point : Consumer쪽의 부담이 커지며 정말로 바로바로 데이터 처리가 되어야한다(Backpressure)
                - Low Throughput Low Latency가 일반적이다.
        - Messaging Queue : 보통 micro-batch형태로 아주 짧은 주기로 데이터를 모아서처리(Spark Streaming)
                - 다수의 Consumer를 쉽게 만들 수 있다
                - Point to Point 보다 운영이 용이하다
4. 이벤트 데이터 관리 이슈 모니터링과 해결

Backpressure(배압)
- 스트리밍 시스템에서 데이터는 일반적으로 일정한 속도로 생성(Producer)
        - 가끔 데이터 생성이 폭발적으로 늘어날 수 있다.
- 다운스트림 단계(Consumer)에서 적시에 처리되어야함
        - 들어오는 데이터 속도를 따라잡지 못하면 시스템에 데이터가 쌓여 지연되면서 메모리 사용량 증가 등으로 잠재적인 시스템 장애를 초래  => Backpressure
- Backpressure를 줄이는 방법 중의 하나는 중간에 메세지 큐를 도입하는 것
        - Backpressure 문제를 어느정도 해결이 가능하지만 완전한 해결은 불가능