학습주제
데이터 파이프라인을 만들 때 고려할 점
best practice
그 외 좋은 팁
학습내용
이상
- 내가 만든 데이터 파이프라인은 문제 없다.
- 관리가 어렵지 않다.
현실
- 여러가지 이유로 실패함
- 모든 프로그램 이슈: 버그. 코드 5줄만 넘어가도.
- 데이터 소스가 내가 컨트롤러를 갖고 있지 않기에 그쪽에도 버그가 있을 수 있음. 네트워크, 시스템 불안정으로 데이터 소스가 동작을 안함. 말도 안하고 포맷을 바꾸기도 함.
- 의존도 이해 부족? 파이프라인이 스무개 백개 넘어가면, A가 만들어줘야 B가 실행 가능. 내가 A를 바꾸었을 때 뒷단이 어떻게 바뀔지 명확하게 보이지 않는 이슈가 생김. 테이블 이름, 컬럼 드랍 수행. 이에 의존하는 파이프라인들이 실패하기 시작함. 파이프라인 수가 늘어나면 유지보수 비용이 기하급수적으로 증가.
- 비용 업데이트 파이프라인이 동작 안되면, 그 뒷단의 파이프라인이 다 돌아도, 채널별 비용이 없으니 리포트가 불완전함.
가능하면 매번 통째로 복사해서 테이블 생성 (Full Refresh)
풀리프레쉬를 하면 바로 통으로 가져오면 됨.
불필요하게 옵티마이즈 하지 말고, 바로 가져오기
이게 어느 시점에는 피지컬하게 불가능해짐. 너무 커서 시간적, 경제적으로 어려움
incremental update를 해야함. 소스를 봤을 때. 이게 하루 한번 업데이트된다면, 업데이트 된 부분만 테이블에 적재.
이렇게 가면 효율성은 높아지지만, 운영이 어려워짐. 만에 하나 이날 파이프라인이 동작을 안하고, 내가 모르고 넘어갔다면,
과거 데이터에 포맷이 바뀌었다면 다시 다 읽어야함.
코드를 바꾸던지, 하루씩 읽어오던 코드를. 과거에서부터 하루씩 다시 읽어오는 복잡도가 생김. 불필요하게 인크리멘탈 업데이트 하지말고 가능하면 풀리프레쉬 업데이트
그럼 언제 풀리프레쉬? 언제 인크리멘탈 업데이트?
내가 하루 한번 업데이트를 해야한다면, 풀리프레쉬를 하는데 12시간이 걸린다면, 자정에 돌려 다음날 정오에 카피가 완료되어 뒷단에 문제가 없다면 풀리프레쉬
적어도 오전 9시 전에 업데이트가 끝나야한다면 인크리멘탈로 가야함
어떻게 할지는 각자가 알아서, 풀리프레시 소요시간 확인, 기다리는 파이프 라인 수와 소요시간 고려.
항상 인크리멘탈이 가능한건 아님. 어떤 시점으로 변경된 값만 리턴할 수 있을 때만.
API를 기준으로 읽어올 텐데, 일정 시간 이후의 값을 가져올 수 있어야함.
레코드에 변경 시간이 기록, 물리적으로 삭제가 아닌 deleted로 불린 타입으로 표시하고 레코드 자체가 테이블에 남아있는지.
데이터 소스가 변하지 않았다는 전제 하에, 데이터 소스 읽어다 웨어하우스에 적재 파이프라인을 한번이든 백번을 실행하던, 소스단, DW단 정보가 동일해야함.
멱등성 = 데이터 소스가 변하지 않았다는 전제 하에, 파이프라인 백번 실행하든 결과가 같아야 함.
깨지면 중복이 10개 데이터 웨어하우스 단에 생김. ETL, 트랜스폼에서 버그가 생김. DW 테이블이 정합성이 깨진다면 소스, 목적지와의 불일치가 생김.
멱등성이 보장된다. 파이프라인이 실패하면 깔끔하게 실패해야함. 물론 문제는 좋지 않지만 문제가 있는 경우, 데이터 정합성이 깨지지 않는 상태로 실패하는 것.
풀리프레쉬 하는 과정. 모든 레코드 가져와 DW에서 리플레이스, 기존 레코드 삭제, 새로운 레코드 적재. 이 오퍼레이션 2개가 있음. 두개의 오퍼레이션 사이에 버그가 있다면, DW 테이블이 비어있는 상태로 끝남 -> 이러면 안됨.
SQL의 트랜젝션기술. 중요한 오퍼레이션들을 묶어서 하나의 오퍼레이션 처럼 수행. 다같이 성공하거나, 다같이 실패시켜 이전 상태 유지.
다양한 이유로 파이프라인이 실패할 수 있음. 재실행을 해야하는데 이를 백필이라 함.
풀리프레쉬는 굉장이 간단. 돌리면 복구됨. 인크리멘탈은 복잡. 특정 날짜가 실패하면 비어있음. 앞단 소스쪽에서 바뀌었다면 일일히 카피해와야함. 멱등성을 보장시켜야함.
이 백필 때문에 데이터 엔지니어가 고생을 많이함. airflow는 이를 잘 보장해줌.
입력과 출력을 문서화.
파이프라인 수가 몇개 없을 땐 별 문제가 없음. 몇백개가 되면 파이프라인이 뭔 기능이 있는지도 모름.
두가지 오너가 있음. 테크니컬 오너, 비즈니스 오너.
테크니컬 오너 : 데이터 엔지니어 중 한사람
비스니스 오너: 데이터를 요청한 사람.(굉장히 중요한 정보) 문제 생기면 소통할 수 있어야함. 의존성 때문에 생기는 문제를 최소화 할 수 있음. A 파이프라인 정보를 B에서 사용. A를 모르고 수정하면 B가 실패.
이러한 흐름도를 명확히 해놔야 함.
데이터 카탈로그를 통해 정보로 들어가면, 아 내가 이 테이블을 고치면 누가 영향을 받는지 알 수 있음.
이게 잘 안되면 온갖 종류의 사고 발생. 데이터 시스템이 고도화되면 문제가 됨.
많은 사람들이 데이터 필요로 할땐 요청함. 필요하지 않을 때는 얘기를 안함. 우리 데이터 파이프라인이 어떤것들이 있고, 주기적으로 누구에 의해 소비되는지 확인.
카탈로그 -> 데이터 디스커버리 툴에 물어봄. 지난 90일 동안 한번도 사용되지 않은 파이프라인은 무엇인지. 확인 후 제거
유데미 있을 땐 쿼터에 한번. 안쓰는 테이블 뭔지 보고, 파이프라인 삭제.
사고는 막을 수 없음. 실패를 당연히 여기고, 중요 파이프라인이 실패했을 때, 그 사고 이후를 살펴보기.
왜 일어났고, 재발을 방지하는 방법을 찾아 실행하기 위함.
리포트에서 나온 문제점을 해결함으로써 재발을 막는데 초점. 매니지먼트 서포트 없이는 힘듦. post-mortem의 트렌드를 보면 기술 부채를 알 수 있음. 사고가 심해지고 정도가 빈번해지면, 아 기술부채를 해소할 때가 됐구나.
입력이 몇갠지 체크, 출력이 믿을만하지 체크. 이를 확인하는 코드 작성.
데이터 대사 유닛 테스트라 볼 수 있음.
입력 데이터가 어떤 상황에 있는지.
중복 데이터가 있는지. 인풋 아웃풋 PK uniqueness 보장되는지.
편하게 해주는 툴들이 있음.
