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

이상과 현실간의 괴리

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

현실 : 버그 , 데이터 소스 상의 이유 What if data sources are not available or change its data format, 데이터 파이프라인들 간의 의존도에 이해도 부족

만약에 어떤 테이블의 열을 업데이트하거나 이름을 바꿨다면 그 뒷단의 파이프라인이 모두 변경되어야 하기 때문에 문제가 생김...(장고 하면서 경험해봤다ㅠㅠ)

Best practices

1. 가능하면 데이터를 통채로 복사해서 테이블 만들기 (Full refresh)
   문제가 생겨도 해결 방법이 간단.
   이게 어느시점부터는 불가능할텐데, 그럼 incremental update를 해야함
   
   소스를 봤을 떄 하루에 한번 업데이트를 하는 파이프라인이라면,
   어제 하루 업데이트 된것만 DW에 저장
   효율성은 올라가지만, operation이 복잡해짐
   만약 하루씩 데이터가 올라가는데, 어떤날 데이터가 안올라갔다 = 빵꾸생김
   과거 데이터가 바꼈다 = 다 다시 읽어와야 함. 코드를 바꿔야 함
   이런 복잡도가 생김.따라서 가능하면 full refresh를 해라.
   언제 그럼? - 이 데이터를 하루에 한번 업데이트를 해야한다? - full refresh를 하는데 12시간이 걸린다면 대략 정오쯤 데이터가 다 카피됨. 그래도 문제 없으면 full 쓰고, 적어도 오전 9시부터는 해야한다 = incremental refresh해야함.

2. 멱등성을 보장해야함. Idempotency
   몇번을 실행하나 결과가 동일해야함.
   내가10번 실행하면 10번 중복이 된다 ? = 멱등성이 깨진 것.

3. 백필이 쉬워야 함.
   실패한걸 다시 채우는게 쉬워야 함.

4. 데이터 파이프라인의 입력과 출력을 명확히 하고 문서화
   비즈니스 오너 명시 - 누가 요청했는지 (필요 없으면 지우고 해야하니까)
   데이터 리니지 (A라는 테이블이 뒷단에서 어떻게 소비되는지) 명확히 있어야 스키마를 바꾸면 누가 영향을 받는지 알게 됨. 이걸 이해하지 못하면 온갖 종류의 사고 발생

5. 주기적으로 쓸모 없는 데이터들을 삭제
   지난 90일동안 사용되지 않은것 등등.. 유데미에서는 쿼터에 한번정도 주기적으로 했다고 함.

6. 데이터 파이프라인의 실패는 당연시 여기고, 그 사고 보고서를 잘 써야함.
   사고 원인을 이해하고, 이를 방지하기 위한 액션 아이템들의 실행이 중요해짐.
   사고의 정도를 보고 기술부채를 갚아야 할지..말지..

7. 중요 데이터 파이프라인의 입력과 출력을 체크하기
   입력 레코드 수와 출력 레코드 수가 몇개인지 체크하는 것부터 시작됨.
   써머리 테이블을 만들어내고 primary key 가 존재한다면 primary key uniqueness가 보장되는지 체크하는 것이 필요함.
   중복 레코드 체크

장고 업데이트 사항 - 1. full refresh를 페이지 누를때마다 하지 말것.