Я попытался запланировать выполнение ETL-процесса. Вот чего я не ожидал.

То, что я считал проблемой с расписанием, сначала оказалось проблемой с возможностью переноса.

Делиться

В своей последней статье я упоминал, что планирование — это следующая преграда, к которой мне предстоит стремиться.

Так что, полагаю, вот я иду к нему.

Но прежде чем я расскажу о том, что произошло, позвольте мне немного рассказать о контексте для тех, кто сталкивается с этим впервые.

Я системный аналитик, решивший перейти в область инженерии данных. Вместо того чтобы просто посещать курсы и получать сертификаты, я решил учиться на собственном опыте и публично рассказывать о своих проектах. Каждая статья в этой серии документирует что-то, что я действительно создал, принятые мной решения, возникшие проблемы и то, чему я научился.

Первая статья представляла собой мой 12-месячный план самообучения, в котором я изложил, как буду подходить к этому переходу. Вторая статья была посвящена созданию моего первого ETL-конвейера с нуля, используя API GitHub, будучи полным новичком. В третьей статье я взял тот же конвейер и сделал его более готовым к использованию в производственной среде, добавив хранилище SQLite, обработку идемпотентности и сохранение данных в Google Drive, и все это в Google Colab.

Эта статья — четвёртая по счёту. И она начинается ровно с того места, где закончилась предыдущая.

Я ожидал, что большую часть времени потрачу на выбор инструмента планирования и его настройку. Но я не ожидал, что прежде чем я смогу даже подумать о планировании, мне придётся столкнуться с чем-то более фундаментальным. Мой конвейер не мог работать вне Google Colab. И пока это не изменится, ни один планировщик в мире не сможет мне помочь.

Это история о том, что произошло на самом деле.

Первая стена: Мой конвейер обработки данных работал в Colab.

Прежде чем приступить к планированию, я хотел понять, что на самом деле потребуется для автоматического запуска моего конвейера. Поэтому я впервые как следует проанализировал свой код, задав себе именно этот вопрос.

Вот как выглядел грузовой отсек:

 conn = sqlite3.connect('/content/drive/MyDrive/github_repos.db')

Путь /content/drive/MyDrive/ существует только внутри Google Colab. Это путь к смонтированному Google Диску, который Colab предоставляет при подключении Диска к ноутбуку. За пределами Colab этот путь не существует. Если бы какой-либо планировщик задач попытался запустить этот скрипт, он бы тут же завершился с ошибкой.

Интересно, что в моём коде не было импортов google.colab . Никаких библиотек, специфичных для Colab. Только один жёстко закодированный путь, который я набирал, особо не задумываясь. Этот путь был зависимостью, а не кодом.

Это было первое, чего я не ожидал. Я думал, что сложность будет заключаться в освоении инструмента планирования. Вместо этого, первым уроком стало то, что моя среда была частью моего конвейера, а я этого не замечал.

Решение оказалось простым. Вместо того чтобы жестко прописывать путь к Colab, я сделал путь к базе данных настраиваемым с помощью переменной окружения:

 import os DB_PATH = os.environ.get('DB_PATH', 'github_repos.db') conn = sqlite3.connect(DB_PATH)

Теперь скрипт использует тот путь, который задан в переменных окружения. Если ничего не задано, он возвращается к созданию локального файла github_repos.db в той же папке. Одно изменение, и конвейер больше не был привязан к Colab.

Впервые запускаю приложение вне Colab.

Прежде чем настраивать какой-либо планировщик, я хотел убедиться, что скрипт действительно работает сам по себе. Поэтому я сохранил его как pipeline.py и создал requirements.txt с указанием двух необходимых ему библиотек:

 requests pandas

И запустил его из терминала:

Сообщение вывело: Pipeline complete. Duplicates handled.

И в моей папке появился файл с именем github_repos.db . Тот же самый конвейер, который я запускал в Colab, теперь работал как обычный скрипт на Python, где угодно.

Это оказалось гораздо более серьезным событием, чем я ожидал. Не потому, что изменение было сложным, оно таковым не было. А потому, что я понял, что представлял свой конвейер как блокнот, тогда как на самом деле у меня был скрипт, который случайно оказался внутри него.

Выбор инструмента планирования

К этому моменту у меня уже был автономный скрипт. Теперь мне нужно было что-то, что запускало бы его по расписанию.

Я рассмотрел несколько вариантов. APScheduler позволяет определять расписания внутри кода на Python, которые работают во время выполнения сессии, но останавливаются в момент закрытия терминала. Это не совсем планирование, это просто цикл. Airflow — это отраслевой стандарт для оркестрации конвейеров, но он требует запуска сервера, базы данных метаданных и веб-интерфейса. Это довольно большая инфраструктура для моего текущего уровня.

GitHub Actions занял промежуточное положение. Он бесплатный, работает на серверах GitHub, расписание определяется в коде, и мне не нужно поддерживать какую-либо инфраструктуру. Компромисс заключается в том, что он разработан для рабочих процессов CI/CD, а не для оркестрации конвейеров, поэтому у него есть ограничения в отношении сложных зависимостей и мониторинга. Но для конвейера на моем этапе это практичный выбор.

Я также хочу быть честным: такие инструменты, как Airflow, существуют не просто так. Когда конвейер разрастается, когда у вас есть зависимости между задачами, когда вам нужна прозрачность того, что выполнилось, а что завершилось с ошибкой, вам необходима полноценная оркестрация. GitHub Actions этого не обеспечивает. Но это хороший первый шаг, и понимание того, почему он ограничен, является частью изучения того, какие задачи на самом деле решают более серьезные инструменты.

Настройка GitHub Actions

GitHub Actions работает через файлы рабочих процессов, которые представляют собой YAML-файлы, размещаемые в определенной папке вашего репозитория. Структура папок выглядит следующим образом:

 github-etl/ ├── .github/ │ └── workflows/ │ └── schedule.yml ├── pipeline.py └── requirements.txt

Вот полный файл рабочего процесса, который я создал:

 name: Run ETL Pipeline on: schedule: - cron: '0 9 * * *' workflow_dispatch: jobs: run-pipeline: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Set up Python uses: actions/setup-python@v5 with: python-version: '3.11' - name: Install dependencies run: pip install -r requirements.txt - name: Run pipeline run: python pipeline.py

Позвольте мне пояснить, для чего предназначена каждая часть.

• cron: '0 9 * * *' — это фактическое расписание. Cron — это формат планирования заданий по времени, существующий в системах Unix уже несколько десятилетий. Пять значений представляют собой минуту, час, день месяца, месяц и день недели. Таким образом 0 9 * * * означает: в 0-ю минуту 9-го часа, каждый день, каждый месяц, каждый день недели. Другими словами, в 9 утра по UTC каждый день.
• workflow_dispatch добавляет возможность ручного запуска. Это означает, что вы можете запустить рабочий процесс, нажав кнопку в GitHub, не дожидаясь запланированного времени. Это полезно для тестирования.
• runs-on: ubuntu-latest указывает GitHub запускать новую машину Linux для каждого запуска. Каждый раз, когда запускается рабочий процесс, GitHub создает чистую среду, устанавливает ваши зависимости, запускает ваш скрипт, а затем все отключается. Нет постоянно работающей машины, на которой бы выполнялся ваш код. Она эфемерна.

Последовательность действий проста. Команда `checkout` загружает ваш код из репозитория в среду выполнения. Команда `Setup Python` устанавливает указанную вами версию. Команда `install dependencies` запускает pip install -r requirements.txt . Затем команда `Run Pipeline` выполняет ваш скрипт.

Что произошло, когда я это запустил?

После загрузки файла рабочего процесса на GitHub я перешел на вкладку «Действия» в своем репозитории и запустил его вручную с помощью кнопки workflow_dispatch.

Всё заработало. От начала до конца — двадцать семь секунд. Конвейер извлёк данные из API GitHub, преобразовал их и загрузил в SQLite, всё на сервере GitHub, без каких-либо действий с моей стороны после нажатия кнопки.

При первом запуске я получил одно предупреждение:

 Node.js 20 actions are deprecated...

Это произошло из-за того, что я использовал более старые версии действий checkout и setup-python. Решение заключалось в обновлении actions/checkout@v3 до actions/checkout@v4 и actions/setup-python@v4 до actions/setup-python@v5 . После этого рабочий процесс заработал без проблем.

Что я на самом деле узнал

Изначально я думал, что планирование — это просто выбор подходящего инструмента. Но оказалось, что планирование заставило меня задуматься о том, о чём я раньше не задумывался: о мобильности.

Конвейер, работающий только в одной конкретной среде, на самом деле не является конвейером. Это скрипт, привязанный к платформе. Чтобы сделать его планируемым, сначала нужно было сделать его переносимым, а переносимость подразумевала понимание того, от чего он на самом деле зависит.

Заранее заданный путь был мелочью. Но то, что я это обнаружил, изменило мой подход к написанию кода для конвейеров обработки данных. Теперь каждый раз, когда я указываю путь, учетные данные или значение, специфичное для конкретной среды, я спрашиваю себя, будет ли эта информация существовать вне контекста, в котором я создаю конвейер.

Ещё я понял, что планирование и оркестровка — это разные задачи. GitHub Actions хорошо справляется с планированием. Но он не решает такие задачи, как повторная попытка выполнения неудачных операций с задержкой, оповещения о сбоях, визуализация зависимостей конвейера или управление несколькими конвейерами, зависящими друг от друга. Это задачи оркестровки, и именно для их решения созданы такие инструменты, как Airflow.

Я ещё не достиг этого уровня. Но теперь я понимаю, зачем нужны эти инструменты, чего раньше не понимал.

Что дальше?

Теперь конвейер обработки данных запускается ежедневно в 9:00 UTC. Данные собираются. И я начинаю замечать кое-что: когда конвейер работает ежедневно, начинаешь по-другому относиться к получаемым данным.

Все ли записи чистые? Есть ли репозитории, в которых отсутствуют поля? Действительно ли важен флаг вирусности, или я определил его таким образом, что почти всё становится «нет»?

Это вопросы качества данных. И это следующая преграда, к которой я иду.

Это часть моей продолжающейся серии статей, посвященных моему переходу от системного аналитика к инженеру данных. Если вы следите за моими публикациями, спасибо. Если это ваша первая статья в серии, ссылки на предыдущие статьи приведены ниже.

От аналитика данных до инженера данных: мой 12-месячный план самостоятельного обучения.

Я создал свой первый ETL-конвейер, будучи полным новичком. Вот как это было.

Я думал, что разработка данных — это просто написание скриптов. Я ошибался.

Свяжитесь со мной в LinkedIn, YouTube и Twitter.

Ибрагим Салами. Все материалы от Ибрагима Салами.

Источник: towardsdatascience.com