5 웹서비스에서 발생하는 데이터의 종류와 특징

5.1 Use Cases

5.2 서버 엔지니어가 다루는 데이터

데이터 엔지니어링의 특수성이 어디서 나오는지 구분하기 위해서 데이터의 성격을 구분한 것이다.
꼭 서버 엔지니어는 이런 데이터만 다루고, 데이터 엔지니어는 어떤 데이터만 다룬다는 의미는 아니다.
비즈니스나 데이터가 커지다보면, 데이터의 성격에 따라 기술 스택도 다른 것이 필요하게 된다.
그 과정에서 역할이 나뉘다 보면 자연스럽게 이런 식으로 서버 엔지니어와 데이터 엔지니어의 역할이 나뉘게 된다. 백엔드 (서버) 쪽을 한다면 모두 잘 다루는 것이 좋다.

5.2.1 Transaction (거래 데이터)

거래 요청이 있고 요청에 대한 처리의 결과가 있는 데이터. 비즈니스나 시스템에서 빈번하게
생성되고 업데이트 되는 데이터를 의미한다.

전자 상거래 시스템을 생각한다면, 다음과 같은 데이터가 Transaction Data이다.
1. 상품 주문 ( 주문 요청 + 재고 확인, 주문 성사 여부 등의 결과도 같이 처리되어야 함)
2. 결제
3. 환불 요청
4. 기술적으로 시스템의 여러 동작/기능이 하나로 연결되어야 하고, 완결될 때 모두 같이 상태가 결정되는 경우.(all or nothing)

거래 시, 사용자가 상품을 주문하면 해당 수량만큼 재고를 먼저 차감해 놓는다. 그러나 결제 단계에서 잔액 부족 등의 이유로 주문이 취소될 경우, 차감했던 재고를 다시 원래 상태로 되돌려야 한다. 이러한 처리 방식은 "All or Nothing" 원칙이라고 하며, 하나의 트랜잭션이 전부 성공하거나, 실패 시에는 이전 상태로 완전히 롤백되어야 함을 의미한다. 이는 재고나 주문 상태의 불일치 같은 문제를 방지하기 위해 중요하다.

5.2.2 Metadata (메타 데이터)

비즈니스나 도메인을 구성하는 추상화된 정보. 시스템을 다루는 이해관계자(stakeholders)나 제품에 대한 상태 정보 등이 여기에 속한다.
메타데이터는 업데이트가 될 수 있다. 하지만 자주 업데이트 되지는 않는다.

전자 상거래 시스템을 생각한다면, 다음과 같은 데이터가 Metadata이다.
1. 회원의 기본 정보
2. 판매자의 기본 정보
3. 판매자가 등록한 상품 정보
4. 광고주가 설정한 광고 요청 설정
5. 시스템의 설정 정보

메타데이터를 직접 다룰 일은 나중에 데이터를 여러가지 같이 합칠 때 메타데이터를 구분하는 게 중요해진다. 데이터 엔지니너링 관련 시스템을 구축하거나 업무를 할 때.

거래데이터와 메타데이터들을 다루기 위해 가장 많이 사용하는 기술은 테이블 형태가 있는 RDB를 많이 사용한다.

5.3 데이터 엔지니어가 다루는 데이터

데이터 엔지니어가 다루는 데이터는 다음과 같은 특징이 있다.

1. 하나의 메시지가 그 자체로 완결성을 가진다.

   • 이 정보는 유저가 주문하는 도중에 생성된 것이라면 주문하는 도중에 생성된 것이란 정보가 그 메세지 안에 있어야 한다. (이 것 보다 하나 전에 데이터를 봐야 이 데이터를 이해할 수 있어요~ 이런 식의 데이터 x)

2. 하나의 메시지는 Immutable 하다.

   • 메시지 발생 이후에 메시지 안의 값을 변경하지 않는다.
   • 요구사항에 따라 파이프라인에서 특정 데이터를 추가/삭제 정도만 한다.

3. 메시지 안에 메시지의 고유 값(다른 메시지들과 비교해서 unique함을 판단할 수 있는)을 구분할 수 있다.

4. 시간 정보가 항상 있다.

5.3.1 Event

하나의 독립된 사건을 알리는 데이터. 데이터의 발생만 있고, 응답은 필요 없는 데이터. 발생한 데이터를 추후 활용해야 비즈니스/도메인의 의미가 부여된다.

언제나 발생 시간(timestamp) 정보를 가지고 있다.

다음과 같을 때 Event 데이터를 남긴다.
1. 거래 데이터가 아니지만, 비즈니스에 필요한 데이터인 경우 (족발 본 유저가 맥주 살 확률이 높더라)
2. 하나의 사건 이후에 여러 거래들이 후처리 되어야 하는 경우 (결제는 완료 되었는데 그 다음에 다른 사람들이 결제된 내역을 알아야 한다던지)
3. Transaction으로 처리할 수도 있지만 꼭 하나로 연결될 필요가 없어서 독립된 여러 이벤트로 정의/발생 시킨 뒤, 추후에 분석단계에서 엮어서 활용하고 싶은 경우.

5.3.2 Log

어떤 시스템이나 거래의 중간에 순간의 주요 정보를 기록한 데이터.
Event와 의미가 거의 같거나 비슷하다. (구분하는 것의 의미 없을 수도 있다.)
프로그래머의 관행상 파일로 남기는 event data를 로그라고 한다.

Event 와 Log의 처리에서는 다음과 같은 기술적 주제를 다룬다.

1. 하나의 사건 이후에 여러 거래들이 후처리 되어야 하는 경우
   • Message Queue를 이용한 Pub-Sub model
2. 실시간 Event 전송
   • Streaming, CDC
3. Event, Log 의 Visualization(이벤트,로그를 활용하려면 일단 볼 수 있어야 함)
   • ES(OS) - Kibana
4. Event, Log 의 Data Cleansing
   • Streaming, Batch

5.3.3 Aggregation (집계)

Raw-Data(원본/원천 데이터)로부터 비즈니스에 필요한 데이터를 얻기 위해서 집계, 통계를
이용해서 데이터를 만든다. 주로 합계, 평균, 추이를 나타내는 데이터를 만든다.
시간 또는 범위가 있는 시간 정보가 항상 있다.

---

Aggregation이 데이터 엔지니어링 기술이 필요한 경우

데이터 분석가가 ad-hoc하게 Aggregation을 수행할 수도 있지만, 다음과 같은 경우에는 데이터 엔지니어링 기술이 본격적으로 필요하다:

1. 비즈니스를 위해 지속적으로 집계 데이터가 필요한 경우 (매일 총 거래량,매출량, 방문 대비 구매전환율 등)

   • Batch(ETL), Streaming 시스템 필요
   • 안정성과 신뢰성을 갖춘 시스템 설계 필요

2. 집계 대상이 되는 데이터 사이즈가 큰 경우

   • 대용량 데이터 처리를 위한 DB 또는 OLAP 시스템 사용
   • 데이터 백업, Merge, Partitioning, Sharding 등의 기법 활용

3. 집계 대상 데이터(데이터 소스 또는 테이블)가 많은 경우

   • Denormalization 및 Star-Schema 설계 필요
   • OLAP Cube 등의 다차원 집계 구조 필요

4. 도메인의 특수성이 있는 경우

   • 해당 도메인의 특수한 집계 로직, 지식 등을 시스템에 반영해야 함

---

Idempotent
Aggregation을 잘하기 위해서는 idempotent(멱등성)을 보장하는 시스템을 만들어야 한다.

Idempotent 하다는 것(멱등성이 있다)은 같은 대상(Raw-Data)에 대해서 재처리를 하면 언제나 똑같은 결과가 보장되어야 한다는 의미이다.