정선생의 데이터 팡팡

airflow 2.x 부터 롤기반으로 권한관리가 일어나고, 이에 따른 퍼미션 권한이 존재한다.그런데 이게 어떤걸 의미하는건지 잘 정리가 안되서 간단히 정리하고자한다. 1. can read on DAGsDAG 를 볼 수 있는지 여부를 의미한다.리스트에 나와서 어떤 DAGS 가 있는지 조회된다의 의미일뿐 실행이나 해제같은 동작은 안된다. (진짜 목록에만 보일뿐 할 수 있는게 없음)  DAG 별로 따로 수동으로 관리하고, 기본적으로 조회가 안되게 하려면 이 옵션을 제거해주도록 하자.그러면 아래와 같이 기본적으로는 DAGS 의 목록이 조회되지 않는다.특정 DAG 만 조회 가능하게 하려면 "can read on DAG: " 형태로 부여하는것도 가능하다. 2. can edit on DAGsDAG 의 목록이 보이고,..

airflow 의 best practices 글을 읽어보면, Variable.get(키) 형태로 직접 값을 가져오지 않고, 바인딩처리해서 {{var.value.키}} 표현해서 사용하는것을 기본 가이드로 하고 있다. 그 이유는 일단 DAG 를 구성할때 top level code 에 관련된 로직이 존재한다면 DAG 실행뿐 아니라, 로딩되는 시점에서도 그 코드가 동작되기 때문에 성능에 문제가 될 수 있다. https://airflow.apache.org/docs/apache-airflow/stable/best-practices.html#airflow-variables from airflow.models import Variable # Bad example foo_var = Variable.get("foo")..

airflow 로 스케쥴 관리를 하고 있는데, logical_date 가 1초 밀리는 희안한 일이 일어났다. logical_date 의 경우 RUN_ID 값에 시간값이 붙어서 쉽게 인지가 가능한데, 정상적일땐 아래와 같이 RUN_ID 값이 00 으로 딱 떨어졌는데, 어느순간 다음과 같이 RUN_ID 의 값이 00 으로 딱 안떨어지고, 뒷 단위가 조금씩 밀리는 현상이 발견되었다. 구분 정상일때 비정상일때 RUN_ID scheduled__2003-12-07T20:00:00+00:00 scheduled__2003-12-07T21:00:01.0099+00:00 이게 문제가 되는 이유는 ExternalTaskSensor 의 경우는 앞쪽 DAG 의 의존성을 체크할때 logical_date 가 같은 이력을 참조하기 ..

airflow 에서는 code 탭에서 dag 를 구성한 python 파일을 볼 수 있다. 그런데, 이 파일과 dag 값이 다르게 로딩되서 한참 삽질한 경험을 공유하고자 한다. 결론부터 말하면 dag 를 선언한 파일에서 다른 dag 의 파일을 import 하면서 영향을 받았다. 원인 확인방법 airflow 에서는 dag 파일을 읽고, dag bag 에 담아서 관리된다. 문제는 이때 관련된 정보가 잘못 인지되었던 문제였다. dag 로딩이 잘되었는지는 airflow dags list 명령으로 확인이 가능하다. 원래 primitive.py, hour.py, day.py 3개의 파일이 따로 존재하고, dag 도 파일별로 따로 선언했는데 아래와 같이 primitive.py 경로가 아닌 hour.py 로 잘못잡히는걸..

airflow 를 기동할때 편의를 자주쓰는 유틸리티나 스크립트를 PATH 환경변수에 정의하고 데몬을 기동하여 사용하는 경우가 있다. 예를 들어, /home/user/foo/script 라는 경로에 내가 편의를 위해 만든 쉘스크립트를 넣고, PATH 환경변수에 지정해서 잘 쓰고 있었는데, BashOperator 에서 env 옵션을 사용하면 이상하게 해당 스크립트를 찾지 못하는 문제가 발생했다. # export PATH=$PATH:/home/user/foo/script 가 시스템환경변수에는 존재함 ## 이 녀석은 잘 실행되는데 BashOperator( task_id='t1', bash_command='myscript.sh', ) ## 이 녀석에서는 myscript.sh 를 찾지 못한다 BashOperator..

과거에는 execution_date 라는 명칭으로 사용하던 개념이 있는데, 이게 execution 이라는 이름이 있어서 실제 실행된 시간의 개념으로 오해하는 문제가 있었다. (특히 crontab 에 익숙한 사람이라면 더더욱더) 이런 문제때문에 Airflow 2.2 부터는 execution_date 를 쓰지 않고, logical_date 를 쓰는 방향으로 변경되었다. (하위호환성을 위해 execution_date 도 쓸수 있긴하지만 쓰지말자 용어가 헛갈리게 하는 주범이다.) https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-39+Richer+scheduler_interval 헛갈리는 개념? 논리적? 실행시간? crontab 에서는 단순히 특정 스케쥴이 실행..

ETL 작업을 구성하다보면, 배치주기가 다양하게 구성하는 경우가 많다. 특히, raw 로그를 처리하는건 10분 단위와 같이 짧게 유지하고, 뒤쪽 데이터 가공하는건 1시간이나 1일 단위로 배치 사이클을 더 넓게 가져가야하는 경우가 종종 생긴다. 만약, NamedHivePartitionSensor 를 사용하는 경우는 N개의 파티션 이름을 나열해서 쉽게 해결이 가능하다. 그렇다면 ExternalTaskSensor 에서는 이런 문제를 어떻게 해결할 수 있을까? check_event_log = NamedHivePartitionSensor( task_id='check_event_log', partition_names=[ "log.event_log/ymd={{ ymd(dag_run.logical_date) }}/hh..

airflow 의 Quick Start 웹페이지에 보면 설치하고 airflow standalone 으로 가볍게 띄우려고 할때 아래와 같은 오류가 발생될때가 존재한다. 결론부터 말하면 서버의 sqlite 버전이 낮기 때문이다. 그래서 더 상위버전으로 업데이트 재설치가 필요하다. https://airflow.apache.org/docs/apache-airflow/2.7.3/start.html (py3) $ airflow standalone Traceback (most recent call last): File "/home/myuser/py3/bin/airflow", line 5, in from airflow.__main__ import main File "/home1/myuser/py3/lib/python3..