데이터 레이크
- 구조화 데이터 + 비구조화 데이터 (로그파일)
- 보존 기한이 없는 모든 데이터를 원래 형태로 보존
ETL
- 데이터 레이크와 데이터하우스 바깥에서 안으로 데이터를 가져오는 것
ELT
- 데이터 레이크와 데이터하우스 안에서 데이터 처리
데이터 소스
- 프로덕션 데이터베이스의 데이터, 이메일 마케팅 데이터, 세일즈, 이벤트 로그, 크레딧 카드...
Airflow (ETL 스케줄러)
- 가장 많이 사용하는 프레임 워크
- 다수의 ETL이 존재할 경우, 이를 스케줄해주고 의존관계를 정의
- 특정 ETL이 실패하면 에러 메시지를 받고 재실행 기능(Backfill)
데이터 플랫폼 발전 단계
- 초기 단계: 데이터 웨어하우스 + ETL
- 발전 단계: 데이터 양 증가
- Spark 빅데이터 처리 시스템 도입
- 데이터 레이크 도입
- 데이터 소스 -> 데이터 파이프라인 -> 데이터 웨어하우스
- 데이터 소스 -> 데이터 파이프라인 -> 데이터 레이크
- 데이터 레이크 -> 데이터 파이프라인 -> 데이터 웨어하우스, 데이터 크기가 크기 때문에 Spark/Hadoop 도입
- 성숙 단계: 데이터 활용 증대
- ELT 단이 더 중요해지면서 dbt등의 analytics engneering 도입
- 품질 중요, ML 도입 가속화
데이터 파이프라인
- 데이터를 소스로부터 목적지로 복사하는 작업
- 대부분의 경우 목적지는 데이터 웨어하우스가 됨
- 데이터 소스 예: 프로덕션 데이터베이스, 로그 파일, API..
- 데이터 웨어하우스, 캐시 시스템, 프로덕션 데이터베이스
종류
Raw Data ETL Jobs
- 외부와 내부 데이터 소스에서 데이터를 읽어다가 적당한 포맷 후 데이터 웨어하우스 로드
- 데이터 엔지니어가 보통 함
Summary/Report Jobs
- DW(혹은 DL)로부터 데이터를 읽어 다시 DW에 쓰는 ETL
- Raw Data를 읽어 일종의 리포트나 써머리 형태의 테이블 만들기
Production Data Jobs
- DW로부터 데이터를 읽어 다른 Storage로 쓰는 ETL
- 써머리 정보가 프로덕션 환경에서 성능 이유로 필요한 경우
- 혹은 머신러닝 모델에서 필요한 피쳐들을 미리 계산해두는 경우
만들 때 고려할 점
Best Practice #1
- 가능하면 데이터가 작을 경우, 매번 통채로 복사해서 테이블 만들기(Full Refresh)
- Incremental update만이 가능하다면, 대상 데이터 소스가 갖춰야할 조건들
- 데이터 소스가 프로덕션 데이터베이스 테이블이라면 다음 필드가 필요
- 데이터 소스가 API라면 특정 날짜를 기준으로 새로 생성되거나 업데이트된 레코드들을 읽을 수 있어야함
Best Practice #2 - 멱등성
- 여러번 반복해도 동일한 결과가 나와야함
- 모두 one atomic action으로 실행이 되어야함
Best Practice #3 - Backfill
- 실패한 데이터 파이프라인 실패 시 재실행이 쉬어야함
Best Practice #4 - 명확한 입출력과 문서화
- 누가 요청했는 지 기록으로 남기고 문서화한다.
Best Practice #5 - 테스트
- 중요 데이터 파이프라인 입출력 체크하기
- 출력 레코드 수가 몇개인지
- 써머리 테이블을 만들고, Primary key가 유일무이한지
- 중복 레코드 체크
