Привет! Updates + ideas sharing за последние несколько недель:
🟡 Мгновенные универсальные и идентичные среды разработки на базе devcontainers 🟡
Я фанат devcontainers, ранее неоднократно писал о них, напоминаю:
— Декларативно задал окружение для разработки (например, dbt-проекта)
— Установил все зависимости и библиотеки (python, dbt-snowflake, dbt-clickhouse)
— Указал необходимые features (e.g. docker-outside-of-docker, aws-cli, terraform)
— Задал Extensions (e.g. vscode-dbt-power-user, gitlens, vscode-pull-request-github)
— Дополнительные сервисы (например, Cube, Metabase в соседних контейнерах)
Ниже новые результаты:
— Давай делать регулярный image prebuild где-то на сервере, а на клиентах делать только pull, что сократит время сборки на порядок и позволит избежать ошибок
— Давай создадим репо, где в одном месте соберем набор универсальных devcontainers под мои нужды
— В качестве postCreateCommand давай проверим наличие всех утилит:
dbt -v, docker version, yc -v— Автоматически запустим набор инициализирующих команд как postStartCommand:
dbt deps, dbt run-operation initialize_dwh, obsutil config -i=$OBS_ACCESS_KEY_ID -k=$OBS_SECRET_ACCESS_KEY -e=$OBS_ENDPOINT🔵 Data Integration Pipelines via dlt orchestrated by Github Actions 🔵
Работал над интеграцией данных одного из популярных сервисов через API.
— Изучил API, доступные методы и структуру данных
— Подготовил скрипт на Python, который осуществляет регулярные выгрузки данных
— В структурированный файловый формат .parquet с типизацией
— Доступны режимы: 'incremental' and 'historical' (any specified time period)
— Запускаю по расписанию как workflow в Github Actions
— Сам код и зависимости выполняются в контейнере (конечно, devcontainers)
— Уведомления об ошибках отправляет Tg-bot в указанную группу
Появилась идея писать универсальные интеграции с использованием некоего фреймворка. Рассматриваю dlt - data load tool.
Кто работал с dlt? Насколько интересный и качественный тул?
🟢 dbt deployment (CD) with Github Actions - единый универсальный workflow 🟢
Проблема:
— В наличии множество Github Actions Workflows, которыми трудно управлять по-отдельности
— Workflows едва связаны между собой, привязка ко времени расчета (0 минут, 15 минут, 30 минут каждого часа)
— Сборка docker image осуществляется принудительно, не запускается автоматически при изменении в содержимое
— Сборка docker image игнорирует cache (docker layers)
— Примеры: собрать и опубликовать docker image, собрать DWH: dbt build, опубликовать документацию: dbt docs, проверить актуальность данных: dbt source freshness
Решение:
— Собрать связанные задачи и действия в единый workflow
— Всегда актуализировать среду выполнения (docker image) опираяюсь на изменения в коде
— Оптимизировать подготовительные шаги (docker build) с помощью использования cache
Ключевые результаты:
— Единый workflow-файл для всех задач dbt PROD deployment
— Актуализация среды исполнения кода как предварительный шаг для каждого запуска
— Возможность reusing workflow files (т.е. использовать один шаблон)
🩷 dbt sources + Database Engine features (Clickhouse, Snowflake) 🩷
Проблема:
— В dbt зарегистрировано множество источников, но порядка и полноценного понимания что есть что нет
— Невозможность указать схему данных вручную приводит к невозможности читать источник данных
— Некоторые схемы-источники доступны только в одном экземпляре (сразу для DEV, TEST, PROD), а необходима возможность каждому иметь свою версию
Решение:
— Использовать STAGES (Snowflake), NAMED COLLECTIONS (Clickhouse) для создаваемых интеграций (S3, PostgreSQL, MySQL, etc.)
— Поддержка схемы данных (список таблиц, колонок, типов данных)
— Возможность для каждого пользователя создавать свои экземпляры таблиц-источников данных для интеграций с помощью dbt macro
Ключевые результаты: