keberos 인증 기반의 hive 에서 맵핑을 삽질을 워낙 많이 해서 정리하고자 한다. 우선 airflow 의 connection 정보에 다음과 같이 정보 Hive Metastore Thrift 정보가 아래와 같이 입력했다고 가정한다. (참고로 테스트한 airflow 는 2.5.3 기반이었고, python 3.x 버전을 사용했다) 사실 NamedHivePartitionSensor 를 사용하기 위한 용도였고, 이때 필요한 연결이 Hive Metastore Thrift 정보였다. 테스트 방법 dag 를 만들어서 테스트하는것은 연결이 안될때 삽질하기 매우 어렵다. 그래서 NamedHivePartitionSensor 에서 사용하는 코드를 다음과 같이 직접 선언해서 정보를 가져오면 된다. (물론 AIRFLOW_..
MySQL 5.x 버전대에서 MySQL 8.x 버전대로 바뀌면서, yum 에서 MySQL 5.x 를 삭제하고, MySQL 8.x 버전을 재설치후 mysql 명령으로 접근이 가능한걸 확인후, airflow db init 을 했더니 아래와 같은 오류가 발생했다. 인터넷에서는 caching_sha2_password 에서 mysql_native_password 로 구성을 바꾸라는게 대부분의 답변이었는데, 나는 내가 dbms 를 설치한게 아니라 담당자한테 인스턴스만 제공받고 root 권한이 없는 상황이라 인프라 환경을 바꾸지 않고 해결가능한 방법이 있는지 삽질을 했고 결국은 그 원인을 찾아냈다. (py3) bash-4.2$ airflow db init [2023-04-25 11:03:35,548] {setting..
airflow.cfg 의 dbms 연결설정의 경우 아래와 같은 패턴으로 입력을 해야하는데, 문제는 암호에 @ 가 존재해서 도메인을 잘못 판단하는 문제가 발생했다. 구글링 해보면 python 코드를 통해 해결하거나, "@" 를 "%40" 형태로 치환하면 된다고 하는데, 그렇게 해결이 안되었다. 그 문제는 configparser 에서 "%" 가 또 영향을 받기 때문이었다. sql_alchemy_conn = mysql+mysqldb://:@:/airflow_db?charset=utf8 해결방법 결론부터 말하면 @ 는 %%40 으로 대체해야 설정이 정상적으로 인지된다. urllib 의 quote 로 변환한 결과가 %40 인데, configparser 에서는 또 % 를 추가로 이스케입해줘야 하는 문제가 있기 때문..
내 mac pro 에서 airflow 2.x 버전대를 빌드하면서 compile assets 를 이용한 ui 빌드를 시도하는데 다음과 같은 오류가 발생했다. 결론부터 말하면 mac 에 md5sum 바이너리가 없어서 실패난 현상이었다. (airflow) user@AL0000001 airflow % python setup.py compile_assets gitpython not found: Cannot compute the git version. /Users/user/.virtualenvs/airflow/lib/python3.8/site-packages/setuptools/installer.py:27: SetuptoolsDeprecationWarning: setuptools.installer is deprec..
Airflow 2.x 버전을 띄우려고 했는데 아래와 같은오류가 발생했다. 결론부터 말하면 sqlite 의 의존성이 3.15 보다 버전이 더 커야 작동된다는말인데, centos 의 yum 을 통해 설치 가능한 버전은 sqlite는 3.7.17 버전이 가장 최신이다. 그래서 더 상위버전으로 업데이트해야 동작한다는 말이다. 해결방법은 소스를 다운로드 받아서 빌드하면 쉽게 해결된다. $ airflow standalone Traceback (most recent call last): File "/home/airflow/py3/bin/airflow", line 5, in from airflow.__main__ import main File "/home/airflow/py3/lib/python3.9/site-pack..
DAG 를 만들었는데, 로직이 로딩되지 않았고, 로그를 뒤져보니 아래와 같은 오류가 발생했다. 오류가 나는 현상을 역추적해보니 dag 를 구성한 python 로직에 한글주석이 존재할 경우 아래와 같은 오류가 발생함을 발견했다. UnicodeEncodeError: 'charmap' codec can't encode characters in position 217-220: character maps to [2023-02-01 18:23:52,445] {logging_mixin.py:115} INFO - [2023-02-01 18:23:52,445] {dag.py:2439} INFO - Creating ORM DAG for my_test_dag [2023-02-01 18:23:52,459] {logging_m..
execution_date 이해하기 Airflow 에는 execution_date 라는 개념이 있다. 그런데 매우 헛갈리게 이름을 정한거 같다. 이름만 보면 Processing 되는 시간으로 보이지만, 사실은 스케쥴의 시작시간으로 보면 더 이해가 빠르다. 스케쥴의 간격은 10분이라고 가정하고, 특정 시점을 예로 값을 정리하면 아래와 같다. 구분값 날짜 예시 Processing Time (스케쥴된 실행시점) 2023-02-21 12:40:02 prev_execution_date 2023-02-21 12:20:00 execution_date 2023-02-21 12:30:00 next_execution_date 2023-02-21 12:40:00 왜 이런값이 나올까? crontab 을 기반으로 작업하는 사람..
airflow 2.x 버전에서는 timezone 처리가 가능하다. execution_date 를 로컬날짜 기준으로 사용하기위해서는 python 코드에서 로컬타임존 세팅후 전환하는 로직을 호출해주면 해결이 되는데, 문제는 DAG 의 실행결과를 확인하기위한 로그의 날짜가 버그가 존재한다. 어떤 상황이냐면, airflow 가 설치된 서버의 타임존은 한국기준로 세팅되어있고, 실행된 시점은 "Tue Feb 21 12:30:02 KST 2023" 이라고 가정하자. 편의상 시간만 보면 한국시간으로 12시 30분이라고 보면 된다. [2023-02-21, 21:30:02 KST] {subprocess.py:85} INFO - Output: [2023-02-21, 21:30:02 KST] {subprocess.py:92}..