rzv Data Engineering

#реклама

Обучаем IT-специалистов и берём в команду ⚡️

Лучшим участникам предложим оффер в Т1 — крупнейшую по выручке ИТ-компанию страны по версии RAEX и CNews Analytics 2023 🔝.

Зачем участвовать?

🔹 Уникальный рыночный опыт. Т1 одни из первых на рынке, кто внедряет технологии для управления данными.

🔹 Попасть в число лучших. Проекты Т1 ежегодно получают лучшие награды на ИТ-конкурсах: Global CIO, Национальная банковская премия и др.

🔹 Поддержка. Тебя ждёт команда опытных профессионалов, которые помогут расти и развиваться.

Выбирай:

📁 аналитик платформы данных (DWH)

🖥 разработчик платформы данных (DWH)

От тебя нужен только опыт работы от 6 месяцев в проектах разработки хранилищ данных и желание попасть в команду Т1.

⏰ Быстрое обучение: 1 месяц

📱 Гибкий формат: онлайн по вечерам (от 8 часов в неделю на вебинары и практику)

Подавай заявку до 5 ноября!

Реклама. ООО «Т1» ИНН: 7720484492. Erid: 2SDnjcdR3XH

#термин_дня

Кратко о видах Executor в Airflow

Экзекьютор это компонент Airflow, который определяет, где и как будет запущен таск дага.

На момент написания поста (airflow 2.10) есть 4 основных варианта:
🔸 SequentialExecutor — включён по умолчанию, очень медленный, простой как палка. Плох даже для локальных дев-стендов и пет-проектов.

🔸 LocalExecutor — работает как часть Scheduler'a и не требует отдельных сервисов-воркеров. Поддерживает параллельный запуск, отлично подходит для локальной отладки и небольших дев-стендов.

🔸 CeleryExecutor использует Redis или RabbitMQ в качестве бэкенда для координации тасков между пред-настроенными воркерами. Отлично подходит для большого объёма коротких тасок. Также есть полезный UI flower для мониторинг, который можно запустить отдельным процессом. По моему опыту, Celery воркеры обычно запускаются на виртуальных машинах.

Ограничения: все воркеры должны быть строго одинаково настроены, включая набор и версии python пакетов и всяких CLI, синхронизацию DAGS_FOLDER (обычно через гит). Есть возможность обойти, но это сильно усложнит поддержку.

🔸 KubernetesExecutor — запускает отдельный под в K8s для каждой таски, можно выделить больше ресурсов для тяжёлых задач. Под уничтожается после окончания работы таски.

Этот режим добавляет накладные расходы (десятки секунд) на запуск и остановку подов, что лучше подходит для длинных и редко запускаемых задач. Серия мелких тасок будет тормозить. Зато можно высвобождать ресурсы и не платить 24/7 за простой воркеров.

🔸 И, как со всем в Airflow, можно написать свой Executor. Но должна быть уверенность, что задачу не получится решить через стандартные.

Для дочитавших бонус: с v2.10 можно сконфигурировать несколько экзекьюторов параллельно и назначать для каждой таски свой тип — или Celery, или K8s. Есть даже гибриды вида CeleryKubernetesExecutor, но они не рекомендуются командой Airflow.

❕Напиши в комментах, какие у тебя весёлые истории встречались с K8s экзекьютором, если используешь на проде :)

Решил, пора. Ищу ассистента для помощи в управлении сообществом. Читай вакансию и откликайся по ссылке:
https://forms.gle/GViJ4WYD5JnjKvTu8

Пока не вернул настрой на регулярные посты, мидлам и сеньорам рекомендую канал Василия Трещева по техническим нюансам работы greenplum.

Он крутой инженер "старой закалки", который в любой непонятной ситуации читает исходный код.

https://t.me/GreenplumSQLClub

#видео #моксобес

Ты знаешь, что с этим делать

-> Ссылка на видео (youtube)
-> Ссылка на видео (vk video)

#зачем_нужно

Кастомные материализации в dbt: мощный инструмент или поворот не туда? 1/2

🔸 dbt предоставляет стандартные материализации (table, view, incremental, ephemeral), которые покрывают большинство сценариев. Но иногда возникает потребность в чем-то особенном. Как и в airflow, в dbt можно переопределить всё что угодно и написать свою имплементацию Х, подложив код в папку с проектом.

🔸 Когда стоит задуматься о кастомных материализациях?
* Специфические требования к производительности
* Уникальные особенности вашего DWH
* Сложная бизнес-логика, выходящая за рамки стандартных подходов
* Необходимость в повторяющихся паттернах, которые не покрываются существующими материализациями. Например, когда при full-refresh нужно добавить промежуточные шаги для backfill'a или хочется добавить возможность скастить поле в table без пересчёта.

🔸 Важно помнить: кастомные материализации гарантированно усложнят проект, а полезными не факт, что будут. Перед их внедрением задай себе несколько вопросов:
* Действительно ли стандартные материализации не справляются с задачей? Может, я "не умею их готовить"?
* Можно ли решить проблему с помощью post-hooks или pre-hooks?
* Готова ли команда поддерживать кастомный код в долгосрочной перспективе?

🔸 Когда лучше воздержаться от кастомных материализаций:
* Команда не имеет глубокого понимания dbt и SQL или её воротит от одной мысли поддержки pascal-like скриптов
* Проект часто мигрирует между разными типами баз данных
* Нет четкого плана по поддержке и обновлению кастомного кода
* Кастомизация требуется только для одной или двух моделей

Кастомные материализации в dbt: мощный инструмент или поворот не туда? 2/2

Пример базовой кастомной материализации my_project/macros/my_materialization.sql:

{% materialization custom_table, default %}
  {%- set target_relation = this.incorporate(type='table') %}

  {{ run_hooks(pre_hooks) }}

  -- в main нужно обязательно сформировать код, который отправится в `target/compile` и `target/run` директории для этой модельки
  {% call statement('main') -%}
    {{ create_table_as(target_relation, sql) }}
  {%- endcall %}

  {{ run_hooks(post_hooks) }}

  {{ return({'relations': [target_relation]}) }}
{% endmaterialization %}

Тогда модель my_project/models/my_model.sql будет выглядеть так:

{{ config(materialized='custom_table') }}

select *
from {{ source("default", "my_raw_model") }}

В реальных сценариях нужно добавить специфичную для адаптера логику (например, через макросы и adapter-dispatch) или дополнительные шаги обработки. Изучи реализации, поставленные "из коробки", прежде чем писать своё :)

❔А тебе приходилось сталкиваться с ситуациями, когда кастомные материализации реально спасли проект? Или, может быть, наоборот, усложнили его до невозможности? Поделись опытом в комментариях!

#видео #моксобес

Шестой выпуск серии мок-собесов на youtube

-> Ссылка на видео (youtube)
-> Ссылка на видео (vk video)

Александр вёл нешуточную борьбу с техническими неполадками.

Часть стрима провели в онлайне, но потом он всё же упал. Ссылка на то, что удалось спасти, в комментах.

Разошлись немного ожидания с Александром по формату, оказалось что это не совсем интервью.

Возможно проведу часть два так, как я сам это вижу. Stay tuned

Завтра, в субботу 7 сентября, в 12:00 мск будет стрим-интервью с @digitalberd

Расскажу о своём пути, почему и как пришёл в менторство и в инженерию данных, затронем ещё пару тем.

https://www.youtube.com/live/Zh5WGo18-L8?si=OicFyIX2nr6VFHmE

Стрим начинается!

#видео #моксобес

Подвёз контент под вечер. Пятый выпуск серии мок-собесов на youtube

-> Ссылка на видео (youtube)
-> Ссылка на видео (vk video)

#поразмыслим

С какими проблемами может столкнуться дата инженер, выполняя изменение схемы данных на проде (schema evolution)?

Как эти проблемы можно решить на проекте?

Ограничимся RDBMS MPP классом систем