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

학습내용

특강
사용자 행동 데이터 분석 = 제품 분석 = 디지털 분석
- 이를 가능하게 해주는 툴을 제품 분석 플랫폼 또는 디지털 분석 플랫폼이라 부른다
- 제품/서비스에 대한 사용자 행동을 분석하고 이해하는 데 도움이 되는 툴
- 마케팅 기여도 분석용으로도 사용한다

제품 분석 플랫폼의 주요 특징과 기능
- 사용자 행동 데이터 수집
: 웹사이트, 모바일 앱, 백엔드 시스템 등 다양한 소스에서 데이터를 수집하여 사용자 행동에 대한 충분한 데이터 마련
- 사용자 세분화(User Segment)
: 특정 속성이나 행동에 따라 사용자 그룹을 세분화
분석시 사용자 세그먼트에 따른 차이점과 인사이트 제공
- 퍼널 분석(Funnel Analysis)
: 사용자 여정과 전환 퍼널을 분석하여 이탈 지점 등의 최적화 영역 파악
제품 구매 퍼널 분석, 회원 등록 퍼널 분석
- 코호트 분석(Cohort Analysis)
: 공통된 특성이나 행동에 따라 사용자를 그룹화하여 시간 경과에 따른 사용자 행동을 분석하고 서로 다른 코호트 간의 비교 가능

제품 분석 플랫폼의 주요 특징과 기능
- A/B테스트
: 기능 변경이 사용자 행동 및 주요 지표에 미치는 영향을 평가하기 위한 A/B 테스트의 생성 및 비교 기능 제공
- 사용자 리텐션 분석
: 사용자 유지율/이탈률을 측정하여 시간 경과에 따른 사용자 참여도를 파악하고 사용자 유지에 영향을 미치는 요인을 파악

마케팅 효과분석 : CPC(Cost Per Click)
CPC :
- 고객이 광고를 클릭하는데 드는 평균 비용
- 즉 회사가 고객의 광고 클릭 하나에 지불하는 평균 비용
- 보통 캠페인별로 계산되고 마케팅 플랫폼 레벨로 모아서 계산
- 이 방식의 문제는 실제 클릭이 구매로 이뤄졌는지 따지지 않는다는 점이다
특정 캠페인의 CPC
: CPC = 캠페인에 들어간 모든 비용 / 총 클릭 수 
- CPC가 클수록 마케팅 효과는 떨어진다고 본다

사용자 행동 이벤트 정의(사용자 행동 분석 플랫폼)
- 사용자가 온라인 서비스 내에서 수행하는 특정 작업 또는 상호 작용
- 이러한 이벤트는 사용자 행동을 포착하여 다양한 분석을 가능하게 함
ex) 가입/등록, 로그인, 페이지/화면 보기, 버튼 클릭 수, 양식 제출, 검색 쿼리, 카트에 추가, 결제 시작, 결제 완료

구글 애널리틱스
- 웹 사이트와 앱 방문 트래픽을 추적하고 분석할 수 있게 해주는 서비스
- 구글 마케팅 플래폼에서 근간이 되는 서비스

구글 애널리틱스로 할 수 있는 일
- 몇 명의 방문자가 있고 몇 개의 세션이 있는지
- 어디서 방문하는지 (뒤에서 설명할 접점과 마케팅 채널 등등)
- 얼마나 오랫동안 머무르는지 (총 세션의 길이)
- 어느 페이지들을 방문하는지
- 어느 페이지에서 가장 많이 사이트를 나가는지: 이탈율 (bounce rate)
- 방문자들의 인구통계 정보 (연령대, 성별, 지역, 언어 ... )

방문자
- 쿠키를 이용해 방문자별로 유일한 식별자 부여
- 식별자는 디바이스마다 부여

세션
시간 기반:
- 30분 이상 아무 행동도 취하지 않으면 세션 종료 (수정 가능)
- 구글 애널리틱소에 정한 시간대로 자정이 넘어가는 순간 세션 종료
캠페인 기반:
- 세션이 끝나기 전이라도 새로운 캠페인을 타고 다시 방문하면 기존 세션 종료후 새 세션 시작
- 즉 세션에는 세션을 시작하게 한 캠페인 정보(접점 정보)가 태그됨


ETL vs ELT
ETL: 데이터를 데이터 웨어하우스 외부에서 내부로 가져오는 프로세스
- 보통 데이터 엔지니어들이 수행함
ELT: 데이터 웨어하우스 내부 데이터를 조작해서 (보통은 좀더 추상화되고 요약된) 새로운 데이터를 만드는
프로세스
- 보통 데이터 분석가들이 많이 수행
- 이 경우 데이터 레이크 위에서 이런 작업들이 벌어지기도 함
- 이런 프로세스 전용 기술들이 있으며 dbt가 가장 유명: Analytics Engineering
- dbt: Data Build Tool



데이터 레이크 (Data Lake)
- 구조화 데이터 + 비구조화 데이터
- 보존 기한이 없는 모든 데이터를 원래 형태대로 보존하는 스토리지에 가까움
- 보통은 데이터 웨어하우스보다 몇배는 더 큰 스토리지

데이터 웨어하우스 (Data Warehouse)
- 보존 기한이 있는 구조화된 데이터를 저장하고 처리하는 스토리지
- 보통 BI 툴들(룩커, 태블로, 수퍼셋, ….. )은 데이터 웨어하우스를 백엔드로 사용함

Data pipeline
:데이터를 소스로부터 목적지로 복사하는 작업
- 이 작업은 보통 코딩 (파이썬 혹은 스칼라) 혹은 SQL을 통해 이뤄짐
- 대부분의 경우 목적지는 데이터 웨어하우스가 됨
- 데이터 소스의 예:
Click stream, call data, ads performance data, transactions, sensor data, metadata, ...
More concrete examples: production databases, log files, API, stream data (Kafka topic)
- 데이터 목적지의 예:
데이터 웨어하우스, 캐시 시스템 (Redis, Memcache), 프로덕션 데이터베이스, NoSQL, S3, ...

데이터 파이프라인의 종류
- Raw Data ETL Jobs(보통 데이터 엔지니어의 역할)
1. 외부와 내부 데이터 소스에서 데이터를 읽어온다(대부분 API를 이용)
2. 적당한 데이터 포맷 변환(데이터의 크기가 커지면 Spark등이 필요하다)
3. 데이터 웨어하우스 로드

- Summary/Report Jobs(Analytics Engineer의 역할)
1. DW로부터 데이터를 읽어 다시 DW에 쓰는 ETL
2. Raw Data를 읽어 일종의 리포트 형태나 summary 형태의 테이블을 다시 만드는 용도
3. 특수한 형태로는 AB테스트 결과를 분석하는 데이터 파이프라인도 존재

-Production Data Jobs
1. DW로부터 데이터를 읽어 다른 Storage로 쓰는 ETL
- 써머리 정보가 프로덕션 환경에서 성능 이유로 필요한 경우
- 머신러닝 모델에서 필요한 피쳐들을 미리 계산해두는 경우

이상과 현실간의 괴리
- 이상 혹은 환상
: - 내가 만든 데이터 파이프라인은 문제없이 동작할 것이다.
  - 내가 만든 데이터 파이프라인을 관리하는 것은 어렵지 않을  것이다.
- 현실 혹은 실상
- 데이터 파이프라인은 많은 이유로 실패함
1. 버그
2. 데이터 소스상의 이슈
3. 데이터 파이프라인들간의 의존도에 이해도 부족
- 데이터 파이프라인의 수가 늘어나면 유지보수 비용이 기하급수적으로 늘어난다.
   - 데이터 소스간의 의존도가 생기면서 이는 더 복잡해짐

Best Practices
- 가능하면 데이터가 작을 경우 매번 통채로 복사해서 테이블을 만든다(Full Refresh)
- Incremental update만이 가능하다면, 대상 데이터소스가 갖춰야할 조건
1. created
2. modified
3. deleted
  - 데이터 소스가 API라면 특정 날짜를 기준으로 새로 생성되거나 업데이트된 레코드들을 읽어올 수 있어야한다
- 멱등성(Idempotency)를 보장하는것이 중요하다
   - 동일한 입력 데이터로 데이터 파이프라인을 다수 실행해도 최종 테이블의 내용이 달라지지 않아야한다(중복 데이터 생성X)
   - critical point들이 모두 one atomic action으로 실행 되어야 한다.(sql의 transaction이 꼭 필요한 기술)
- 데이터 파이프라인의 입력과 출력을 명확히 하고 문서화해야한다
- 주기적으로 쓸모 없는 데이터들을 삭제한다
- 데이터 파이프라인 사고시 마다 사고 리포트(post_mortem)작성

Airflow
: 파이썬으로 작성된 데이터 파이프라인(ETL) 프레임워크
- 데이터 파이프라인 스케줄링 지원
   - 정해진 시간에 ETL 실행 혹은 한 ETL의 실행이 끝나면 다음 ETL 실행
- Airflow에서는 데이터 파이프라인을 DAG(Directed Acyclic Graph)라고 부른다

Airflow : 5개 컴포넌트로 구성
- 웹 서버(Web Server)
- 스케줄러(Scheduler)
- 워커(Worker)
- 메타 데이터 데이터베이스(기본적으로 Sqlite가 설치됨)
- 큐(다수서버 구성인 경우에만 사용)
* 스케줄러는 DAG들을 워커들에게 배정하는 역할을 수행
* 웹 UI는 스케줄러와 DAG의 실행상황을 시각화해준다
* 워커는 실제로 DAG를 실행하는 역할을 수행한다
* 스케줄러와 각 DAG의 실행결과는 별도 DB에 저장된다
  - 기본적으로 설치되는 DB는 SQLite이다
  - 실제 프로덕션에서는 MySQL이나 Postgress를 사용해야한다

Airflow의 장단점
장점
- 데이터 파이프라인을 세밀하게 제어가능
- 다양한 데이터 소스와 데이터 웨어하우스를 지원
- 백필(Backfill)이 쉽다
단점
- 배우기가 어렵다
- 상대적으로 개발환경을 구성하기 쉽지 않다
- 직접 운영이 쉽지않다. 클라우드 버전 사용이 선호된다

DAG란? (Directed Acyclic Graph)
- Airflow에서 ETL을 부르는 명칭
- DAG는 태스크로 구성됨
   - ex) 3개의 태스크로 구성된다면 Extract, Transform, Load로 구성
- 태스크란?
  : Airflow의 오퍼레이터로 만들어짐
   - Airflow에서 이미 다양한 종류의 오퍼레이트를 제공
   - 경우에 맞게 사용 오퍼레이터를 결정하거나 필요하다면 직접 개발