학습주제
Backfill 하는 방법 알아보자
학습내용
백필을 인크리멘탈에서 적용
시간별-날짜별 데이터를 읽어올 때.
데일리 인크리멘탈 업데이트
여러번의 백필을 수행하야하는 상황
추천방식으로 짰으면 백필이 쉬움
하드코딩 날짜를 짜서, 할 필요없이
execution date을 7월 1일부터 31일까지 바꿔가며 수행시켜주면 됨.
만일 1년치를 돌려야 한다면 엄청난 노가다가 됨.
백필이라는 커맨드가 있고, 시작, 마지막 날짜를 지정해주면
데일리, hourly라면 매일 24번씩 돌려줄 것임.
또 다른 최적화는,
하루에 하나씩 돌리지말고 한번에 다수의 날짜를 돌릴 방법이 있나? 를 생각해 볼 수 있음.
예를들어 지난 1년치 데이터를 백필해야한다면
하루에 한번씩 365번을 돌리는 것도 방법
한번에 30개의 날짜를 12번 돌리는 것도 방법
동시에 여러개의 대그를 돌리면 몇가지 문제
데이터 소스에 들어가는 오버헤드가 클 수있음
데이터 소스가 동작을 멈출 수 있음 특히 프로덕션 DB인 경우.
사용자의 요청을 듣느라 바쁜데, 데이터 시스템에서 한번에 달라고하면
slow down 발생함.
두번째는
프로덕션 DB경우 데이터 시스템 전용 slave를 따로 만들어놓음
master있고 slave를 여러개 만들어놓고 읽기 기능만 부여
master는 모두 가능
시스템에 부하를 분산시키는 방법
유데미에서 그렇게 설정했었음.
한꺼번에 너무 많이 읽어가면 로드가 걸릴 수 있음
대그를 어떻게 구현했냐에 따라
충돌이 날 수도 있음.
항상 가능한 것은 아님.
mysql_to_Redshift의 경우 2개 동시에 돌리면 충돌남.
같은 로케이션에 대해 읽어옴
1일 2일 동시에 대그 돌면 뭐가 먼저 실행됐냐에 따라, 앞서 써놓은 것을 덮을 수도있고
COPY 작업이 동시실행되면 사실상 하나의 COPY만 수행됨.
- 한 날짜에 대해 한번씩 연달아서 실행시켜주는 것이 안전함.
한번에 대그 몇개 실행
max_active_runs
보통 이걸 1로 세팅해놓고 돌리는게 안전함.
-e의 날짜엔 실행하지 않음 7월 말까지 임 사실상
-s의 경우 맞음.
catchup True
execution date을 사용한 인크리멘탈
실행시켜보면, 랜덤하게 선택할 수도 있고, 날짜 순서대로 할수도 있음
파라미터 설정하면 됨
모든 대그가 백필을 필요로 하지않음
풀리프레쉬를 한다면 의미가 없음
요약
데이터 소스가 백필 방식을 지원해줘야 함.
execution_date으로 데이터의 날짜를 결정할 수 있어야함
catchup 을 True
-s -e로 지정해야함.
마지막으로
UPSERT를 구현하면 됨.
결국 멱등성을 보장함.
