[실날데] 실리콘밸리에서 날아온 데이터 엔지니어링 스타터 키트 - 3주차: 데이터 파이프라인을 만들 때 고려해야 할 점

데이터 파이프라인을 만들 때 고려해야 할 점

이상과 현실 간의 괴리

• 이상 혹은 환상
  • 내가 만든 데이터 파이프라인은 문제 없이 동작할 것이다
  • 내가 만든 데이터 파이프라인을 관리하는 것은 어렵지 않을 것이다
• 현실 혹은 실상
  • 데이터 파이프라인은 많은 이유로 실패함
    • 코드 버그
    • 데이터 소스상의 이슈
    • 데이터 파이프라인들 간의 의존도에 이해도 부족
  • 데이터 파이프라인의 수가 늘어나면 유지보수 비용이 기하급수적으로 늘어남
    • 데이터 소스 간의 의존도가 생기면서 더 복잡해짐. 만일 마케팅 채널 정보가 업데이트가 안 된다면 마케팅 관련 모든 정보들이 갱신되지 않음
    • more tables needs to be managed (source of truth, search cost, …)

 

Best Practice 1

• 가능하면 데이터가 작을 경우 매번 통채로 복사해서 테이블을 만들기 (Full Refresh)
• Incremental Update만 가능하다면 대상 데이터 소스가 갖춰야 할 몇 가지 조건 존재
  • 데이터 소스가 프로덕션 데이터베이스 테이블이라면 다음 필드가 필요
    • created, modified, deleted
  • 데이터 소스가 API라면 특정 날짜를 기준으로 새로 생성되거나 업데이트 된 레코드들을 읽어올 수 있어야 함

 

Best Practice 2

• 멱등성(Idempotent)을 보장하는 것이 중요
  • 동일한 입력 데이터로 데이터 파이프라인을 다수 실행해도 최종 테이블의 내용이 달라지지 않아야 함
  • 예를 들면 중복 데이터가 생기면 안 됨

 

Best Practice 3

• 실패한 데이터 파이프라인을 재실행하기 쉬어야 함
• 과거 데이터를 다시 채우는 과정(Backfill)이 쉬워야 함
  • Airflow는 이 부분에 강점을 가지고 있음
    • DAG의 catchup 파라미터가 True가 되어있어야 하고, start_date와 end_date가 적절하게 설정되어 있어야 함
    • 대상 테이블이 incremental update 되는 경우에만 의미 있음 - execution_date 파라미터를 사용해서 업데이트되는 날짜 혹은 시간을 알아내게 코드를 작성해야함, 현재 시간을 기준으로 업데이트 대상을 선택하는 것은 안티 패턴

 

Best Practice 4

• 데이터 파이프라인의 입력과 출력을 명확히 하고 문서화
  • 주석으로라도 누가 언제 왜 요청했는지 적기
  • 데이터 디스커버리 문제
• 주기적으로 쓸모없는 데이터들을 삭제
  • Kill unused tables and data pipelines proactively
  • Retain only necessary data in DW and move past data to DL (or storage)

 

Best Practices 5

• 데이터 파이프라인 사고시 마다 사고 리포트(post-mortem) 쓰기
  • 목적은 동일한 혹은 아주 비슷한 사고가 또 발생하는 것을 막기 위함
• 중요 데이터 파이프라인의 입력과 출력을 체크하기
  • 아주 간단하게 입력 레코드의 수와 출력 레코드의 수가 몇 개인지 체크하는 것부터 시작
  • 써머리 테이블을 만들어내고 Primary key가 존재한다면 Primary key uniqueness가 보장되는지 체크하는 것이 필요함
  • 중복 레코드 체크