13주차 Airflow 고급 3일차

Airflow의 기타 기능 사용해보기

 

6: 어드민 권한이 있다 해서 접근할 수 있는 api는 아니고, cfg 단에 환경 변수 노출할지 말지(expose_config)가 true로 세팅돼 있어야 가능한.

두번쨰 항목에서 ExternalTaskSensor도 결국 오퍼레이터임

세번째 항목은 대그 간 실행 순서가 아닌 테스크 실행 순서 조정할 수 있는 것들.

BranchPythonOperator: 지금 상황에 맞춰 뒤에 어떤 테스크를 호출할지, 실행할지 동적으로 결정할 수 있는.

LatestOnlyOperator: 백필할 필요성이 있다 생각하면 실행이 중단되는 오퍼레이터. 예를 들어 하나의 대그에 대해 다양한 성격의 테스크들을 갖고 있다면 앞쪽은 인크리멘탈 업뎃으로 데이터 읽어오고, 뒤쪽 테스크는 지금 시점 기준 시의성에 맞춰 오퍼레이션 하는 경우. 시의성에 맞춘 작업을 해야 하는 경우. 이를테면 뉴스레터 보낸다던지. 백필 하려고 돌렸는데 갑자기 뉴스레터 보낸다? 그런 건 큰 문제가 있을 것. 사용자에게도, 운영자에게도.

마지막은 트리거 룰이라고 하는데, 보통 태스크 여러개 구성돼있는 대그라면 뒷단 태스크들은 앞단 태스크들이 다 성공해야지만 실행될 것. 그게 일반적인데, 안그러고 앞단 실패성공 상관 없이 난 무조건 실행돼야 하는 테스크가 있을 수도 있고. 앞단에 5~6개 테스크 있는데 그 중 하나라도 ㄱ성공하면 난 실행해야 한다. 하나라도 실패하면 성공해야 한다. 다 실패하면 성공해야 한다 등 트리거 규칙이 융통성 있어야 하는 경우가 있다. 이런 경우 어케 해야 하는지에 대해 다룰 예정.

 

 

12: 템플릿 엔진이란? 프리젠테이션 로직과 애플리케이션 로직을 분리하는 것.

 

13: 사용자 인풋 기반으로 돌아가는 워크플로 만들 때 진자 템플릿 써서 만든다. 구체적으로 어디에 진자 템플릿 개념 도입해서 쓸 수 있는가? 보통 execution_date 같은 테스크 실행 시 주어지는 파라미터 같은 것을 진자 템플릿으로 쉽게 레퍼런스 할 수 있고, 에어플로 변수 및 연결 정보도 진자템플릿으로 쉽게 읽을 수 ㅇ. 또 테스크 및 대그 이름. 또 대그 런이라 해서 이 대그가 언제 마지막으로 실행 성공했었는지, 다음 대그 실행되는 시간이 언제인지를 진자 템플릿 통해 쉽게 추출 가능. 그러다 보면 약간 코딩해서 계산해야 했던 값들을 진자 템프릿으로 바로 액세스 할 수 ㅇ. 에어플로에서 태스크 작성 시 노가다 좀 덜 해도 되고, 재사용성 같은 게 늘어난다.

여기 나온 ds란 변수는 xxxx-xx-xx로 날짜 출력하는 거. 근데 ds_nodash 이렇게 변수 이름 지정하면 대시 없는 값으로 사용 가능. 그래서 어떤 정보 이용 가능한지 링크 보면 나옴~

 

15: 첫항목으로 나온 bash_command. 이건 진자 템플릿을 지원한다. env 역시 그렇다. 그래서 어느 변수에 진자 템플릿 사용할 지 모르겠으면, 레퍼런스 찾아서 꼭 확인해볼 것!

 

19: 오타 수정 "실행되었더라는" -> "~더라도"

 

21: HttpSensor - 원하는 응답 올 때까지 대기.

SqlSensor - 이를테면 특정 데베에 특정 셀렉트 문 보내 그 조건 만족할 떄까지 기다리는 거

TimeSensor - 특정 시간까지 기다림

poke란? - 주기적 체크. 파일 있는지? 그럼 기다리는 방법이 2가지로 포크와 리스케줄. 포크는 기본적으로 워커 하나 잡고 포크 하나 하고, 슬립으로 기다렸다 또 포크하고. 따라서 포크 방식으로 갔을 때 문제는 워커 하나를 낭비하는 느낌. 센서 쓸 때  워커 하나가 전담돼서. 리스케줄 방식은 워커하나 잡아서 체크하고 릴리즈하고 의 반복. 디폴트 값은 포크 모드. 명확한 주기를 보장한단 특징.

 

22: 대그 의존성 관점서 ExternalTaskSensor가 뭔지 알아보자. 트리거 대상이 되는 대그가 앞의 대그를 체크. 이 경우 schedule_interval이 동일하게 세팅돼있어야 함. Execution Date이 동일해야 하기 때문임. 이렇게 맞아야 하는 조건이 많다 보니 본인은 이거 안 쓴다. 이렇게 맞아야 하는 조건들이 까다롭고, 포크 모드 쓰는 게 일반적인데 워커 하나가 체크용으로 낭비되기 때문. 글고 대그 엥;ㅣ관점선 누가 날 기다리고 있단게 명확하지 않으므로 실수할 가능성 더 높아진다.

타임아웃 변수는 초 단위다. 한 워커를 끝까지 들고 있으면서, 5분 있다 체크 체크체크.. 를 반복. 그러다 익스터널 대그의 익스터널 테스크가 완료된게 보이면 그 때서야 워커 릴리즈 하고 뒤로 넘어감.

 

23: frequency 자체만 동일하다면 차이를 이게 어ㅗㄹ마나 더 뒤에 실행할건지 조정할 순 있으나, 그게 그리 쉽지 않고 어긋나기 쉬움. 그래서 정말로 이게 필요한게 아니라면 앞단 대그가 뒷단 대그를 명시적으로 트리거 하는 형태로 가는 게 훨 더 좋. 이렇게 프리퀀시나 스케줄 인터벌이 명확하게 안맞는 경우 조절할 수 있는 방법이 있는데 이를 실수하기 굉장히 쉽다. 그래서 ExternalTaskSensor는 웬만하면 쓰지 말라는 거.

 

24: 뒤에 트리거 할 게 많은 경우 상황따라 일부만 트리거 해주는 것. 명확하게 해줘야 함 이를테면 A 끝난 후엔 b,c를 ㄱ실해ㅐㅇ해줘야 한다던지. 그래서 아무 트리거나 제약 없이 실행할 수 있는 게 아니다. 미리 정해놓는 것 중 일부 혹은 모두를 실행하도록 동적으로 결정할 수 ㅇ. 그럼 이걸 언제 쓰느냐.. 프로덕션용 말고 개발용인 경우 등에 쓸 수 있다.

 

25: 브랜칭 태스크 끝나면 나머지 2개 실행되도록 세팅돼있다. 브랜칭 태스크 는 현재 시각 보고 12시 이전 시간이면 모닝태스크,  아니면 ~. UTC 기준으로 할 거고, 성공 실패 말고 skipped도 있다. 코드 안의 엠티오퍼레이터는 정말 아무것도 안하는 오퍼레이터.

 

26: 백필 할 때마다 뉴스레터가 간다 그럼 문제잖아? 과거 뉴스레터를 또 보내는 거니까. 이런 경우 레이티스트온리오퍼레이터를두면 뒤쪽은 시의성 작업 앞쪽은 업뎃 수행.

 

31: 앞 티원~쓰리가 모두실행되거든 나를 불러라 하는게 올던. 글고 exit 1은 의도적으로 실패하게 한 거임. 성공하면 exit 0을 함.

 

34: 프로덕션용은 물론 개발용으로마저 시퀄라이트 쓰는 게 안좋음. ㅡ그래서 마이시퀄이나 포스트그레스 쓰는 거다.

 

3-5부터 보면 된다. 그치만 내일 카페 가서 남는 시간엔 dbt 2강 어치가 아닌, 특강들을 보려고 함. 아.. 집가서 공부할 땐 에어플로를 한 번 더 볼지...

 

36: 그림에서 뒷단 에이비씨는 파일을 프로세스하는 태스크들.