Комментарии 28
А что Вы используете, если нужно передавать файлы между тасками внутри одного дага?
Если честно, такой необходимости еще не возникало.
Но если возникнет, то тут очевидное решение — использовать шару (S3, WebDAV, NFS, SMB, FTP, Gopher — что вам больше нравится), к которой имеют доступ все воркеры.
Мы решили что гонять по сети — не очень.
Передаём данные пиклами.
Почему «не очень»? Какой у вас объем файлов?
Совсем крохотный. Десятки мегабайт. Почему решили что не очень
— это дополнительная система, ещё одно место где что-то может пойти не по плану.
Всё зависит от задач: когда в тасках — запуск спарка с обработкой гигабайт и терабайт данных, то без скидывания файлов в s3 уже сложнее обойтись.
А что-то совсем маленькое можно через XCom передавать. Или ссылку на данные.
Почему перезапускаете таски руками, а не с помощью retries?
Легко:
- Всегда есть поиск по дагам и Cmd+F по странице.
- Аналитики видят только те даги, которые их беспокоят.
- Сейчас завезут теги и вообще заживем.
Да и вообще, зачем с ними «жить»? Работают и ладно. Изредка можно прокрутить экран и убедиться, что всё «зелёное».
Подскажите плис, можно ли в аирфлоу «даги» обновлять на лету как CI\CD? Как пример — разработчик обновил код Дага в гите и… опс… аирфлоу имеет у себя новую версию Дага. Это возможно?
Конечно, возможно. Любая CI-система вам в помощь.
У нас, например, трудится вот такой нехитрый .gitlab-ci.yml
:
.deploy: &deploy
stage: deploy
tags:
- airflow
script:
- rsync -avh --delete --omit-dir-times --exclude ".*/" --exclude "__*/" . /home/airflow/dags/
deploy-master:
<<: *deploy
only:
- master
deploy-mr:
<<: *deploy
when: manual
except:
- master
А воркеры забирают папку с дагами по NFS. (Уж не знаю, насколько это здравое решение, но ведь работает!)
бывали ли моменты когда воркер хотел забрать папку в момент когда в ней все было удалено?
М-м-м, папка пустой не бывает: смотрите, сначала Gitlab Runner ссыпает репку во временную папку, потом rsync
синхронизирует её с папкой с дагами — сравнивает файлы, заменяет обновленные, добавляет новые, параллельно удаляя лишние. Получается эдакий мёрдж.
А аирфлоу при каждом запуске дага считывает его (скрипт) заново?
AF проходится по папке с дагами каждые dagbag_import_timeout
секунд и складывает их в кэш.
Добрый день!
Попробовал запустить предлагаемый docker-compose.yml. Имею в цикле такие вот ошибки:
worker_3 | Could not open requirements file: [Errno 21] Is a directory: '/requirements.txt'
worker_3 | You are using pip version 19.0.2, however version 22.0.3 is available.
worker_3 | You should consider upgrading via the 'pip install --upgrade pip' command.
airflow_worker_3 exited with code 1
worker_2 | Could not open requirements file: [Errno 21] Is a directory: '/requirements.txt'
worker_2 | You are using pip version 19.0.2, however version 22.0.3 is available.
worker_2 | You should consider upgrading via the 'pip install --upgrade pip' command.
airflow_worker_2 exited with code 1
airflow_1 | Could not open requirements file: [Errno 21] Is a directory: '/requirements.txt'
airflow_1 | You are using pip version 19.0.2, however version 22.0.3 is available.
airflow_1 | You should consider upgrading via the 'pip install --upgrade pip' command.
worker_1 | Could not open requirements file: [Errno 21] Is a directory: '/requirements.txt'
worker_1 | You are using pip version 19.0.2, however version 22.0.3 is available.
worker_1 | You should consider upgrading via the 'pip install --upgrade pip' command.
airflow_airflow_1 exited with code 1
airflow_worker_1 exited with code 1
worker_3 | Could not open requirements file: [Errno 21] Is a directory: '/requirements.txt'
worker_3 | You are using pip version 19.0.2, however version 22.0.3 is available.
worker_3 | You should consider upgrading via the 'pip install --upgrade pip' command.
Как от них избавится?
Apache Airflow: делаем ETL проще