Airflow (3) - Caution

데이터 파이프라인 만들 때 유의점

이상 / 환상 

내가 만든 데이터 파이프라인은 문제 없이 동작하고 관리하는 것은 어렵지 않을 것이다.

 

현실 / 실상

데이터 파이프라인은 많은 이유로 실패하게 된다

버그 / 데이터 소스상의 이유 / 데이터 파이프라인들간의 의존도에 이해도 부족 /  데이터 파이프라인의 수가 늘어나면 유지보수 비용이 기하급수적으로 늘어남 / 데이터 소스간의 의존도가 생기면서 이는 더 복잡해짐. 만일 마케팅 채녈 정보가 업데이트가 안된다면 마케팅 관련 다른 모든 정보들이 갱신되지 않음

 

Best Practices (1)

가능하면 데이터가 작을 경우 매번 통채로 복사해서 테이블을 만들기 (Full Refresh)

Incremental update만이 가능하다면, 대상 데이터소스가 갖춰야할 몇 가지 조건이 있음

• 데이터 소스가 프로덕션 데이터베이스 테이블이라면 다음 필드가 필요 :
  • created (데이터 업데이트 관점에서 필요하지는 않음)
  • modified (수정)
  • deleted
• 데이터 소스가 API라면 특정 날짜를 기준으로 새로 생성되거나 업데이트된 레코드들을 읽어올 수 있어야 함

뒤에 나오는 Task에 시간이 영향을 미칠 거 같으면 Incremental update를 하고 아니면 Full refresh를 한다. 

 

Best Practices (2)

멱등성(Idenmpotency)를 보장하는 것이 중요

멱등성은 무엇인가?

• 동일한 입력 데이터로 데이터 파이프라인을 다수 실행해도 최종 테이블의 내용이 달라지지 말아야함
  • 예를 들면 중복 데이터가 생기지 말아야 함
• 중요한 포인트는 critical point들이 모두 one atomic action으로 실행이 되어야 한다는 점
  • SQL의 transaction이 꼭 필요한 기술

Best Practices (3)

실패한 데이터 파이프라인을 재실행이 쉬워야 함

과거 데이터를 다시 채우는 과정(Backfill) 이 쉬어야 함

Airflow는 이 부분(특히 backfill)에 강점을 갖고 있다

 

Best Practices (4)

데이터 파이프라인의 입력과 출력을 명확히 하고 문서화

• 비지니스 오너 명시 : 누가 이 데이터를 요청했는지를 기록으로 남길 것
• 이게 나중에 데이터 카탈로그로 들어가서 데이터 디스커버리에 사용 가능함
  • 데이터 리니지가 중요해 짐 -> 이걸 이해하지 못하면 온갖 종류의 사고 발생 

Best Practices (5)

주기적으로 쓸모없는 데이터들을 삭제

Best Practices (6)

데이터 파이프라인 사고시 마다 사고 리포트 쓰기

• 목적은 동일한 혹은 아주 비슷한 사고가 또 발생하는 것을 막기 위함
• 사고 원인을 이해하고 이를 방지하기 위한 액션 아이템들의 실행이 중요해짐
• 기술 부채의 정도를 이야기해주는 바로미터

Best Practices (7)

중요 데이터 파이프라인의 입력과 출력을 체크하기

• 아주 간단하게 입력 레코드의 수와 출력 레코드의 수가 몇개인지 체크하는 것부터 시작
• 써머리 테이블을 만들어내고 Primary Key가 존재한다면 Primary key uniqueness가 보장되는지 체크하는 것이 필요함
• 중복 레코드 체크
• 데이터 대상 유닛 테스트