#зачем_нужно Кастомные материализации в dbt: мощный инструмент или поворот не туда? 1/2 🔸 dbt предоставляет стандартные материализации (table, view, incremental, ephemeral), которые покрывают большинство сценариев. Но иногда возникает потребность в чем-то особенном. Как и в airflow, в dbt можно переопределить всё что угодно и написать свою имплементацию Х, подложив код в папку с проектом. 🔸 Когда стоит задуматься о кастомных материализациях? * Специфические требования к производительности * Уникальные особенности вашего DWH * Сложная бизнес-логика, выходящая за рамки стандартных подходов * Необходимость в повторяющихся паттернах, которые не покрываются существующими материализациями. Например, когда при full-refresh нужно добавить промежуточные шаги для backfill'a или хочется добавить возможность скастить поле в table без пересчёта. 🔸 Важно помнить: кастомные материализации гарантированно усложнят проект, а полезными не факт, что будут. Перед их внедрением задай себе несколько вопросов: * Действительно ли стандартные материализации не справляются с задачей? Может, я "не умею их готовить"? * Можно ли решить проблему с помощью post-hooks или pre-hooks? * Готова ли команда поддерживать кастомный код в долгосрочной перспективе? 🔸 Когда лучше воздержаться от кастомных материализаций: * Команда не имеет глубокого понимания dbt и SQL или её воротит от одной мысли поддержки pascal-like скриптов * Проект часто мигрирует между разными типами баз данных * Нет четкого плана по поддержке и обновлению кастомного кода * Кастомизация требуется только для одной или двух моделей