Вопросы на собеседовании: Analytics Engineer / Инженер аналитики

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

• Staging-модели переименовывают, приводят типы и слегка стандартизируют одну исходную таблицу без бизнес-агрегаций.
• Intermediate-модели выражают переиспользуемые соединения или преобразования, которые слишком специализированы для прямой публикации в BI.
• Mart-модели публикуют факты и измерения в стабильном бизнес-гранулярном виде с тестами, документацией и контрактами.
• Потребители должны зависеть от mart-моделей, а не от staging-моделей в форме источника, чтобы изменения исходной схемы оставались локальными.

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

• View подходит для легкой логики, которая всегда должна отражать актуальные входные данные, но переносит вычисления на каждый запрос потребителя.
• Table подходит для дорогих преобразований, когда полная пересборка приемлема, а быстрые downstream-чтения важны.
• Incremental ограничивает обработку изменившимися данными, но требует надежной границы изменений и идемпотентной логики обновления.
• Ephemeral встраивает переиспользуемый SQL как CTE, не занимая хранилище, но может порождать крупные скомпилированные запросы.

Ephemeral-модель будет плохим выбором, если встраивание скрывает lineage, дублирует дорогие вычисления или создает громоздкий скомпилированный запрос.

• Каждый зависимый узел получает SQL ephemeral-модели как CTE, поэтому общая дорогая логика может вычисляться многократно.
• Глубокие цепочки могут превысить ограничения сложности запросов в хранилище и затруднить чтение планов выполнения.
• Ephemeral-модель нельзя запросить напрямую для проверки или передать инструменту, которому нужна физическая таблица.
• View или table предпочтительнее, когда переиспользование, наблюдаемость или независимый доступ важнее экономии хранилища.

Jinja рендерит SQL и строит граф до того, как получившийся запрос выполняется в хранилище.

• Функции ref, source, var и config разрешаются во время компиляции модели в dbt.
• Вызову run_query нужно активное соединение с хранилищем, поэтому его следует ограждать execute для безопасного парсинга.
• SQL-выражения в отрендеренном результате вычисляет хранилище, а не Jinja.
• Смешение этих фаз может породить зависящие от окружения манифесты или макросы, падающие в командах только с парсингом.

Хороший dbt-макрос централизует устойчивый шаблон преобразования, сохраняя явными входы, выходной SQL и побочные эффекты.

• Он должен устранять существенное дублирование, а не скрывать короткое выражение, которое понятнее написать напрямую.
• Параметры должны отражать различия бизнеса или адаптеров без приема произвольных фрагментов, которые трудно проверять.
• Скомпилированный SQL должен оставаться читаемым, поскольку ревьюеры и оптимизаторы хранилища работают с итоговым запросом.
• Поведение макроса следует покрывать репрезентативными моделями или unit-тестами и документировать, если его контракт неочевиден.

Adapter dispatch выбирает специфичную для хранилища реализацию макроса за единым общим интерфейсом.

• Вызывающий код использует общее имя макроса, а dbt ищет реализацию в настроенных пространствах имен и текущем адаптере.
• Реализация по умолчанию может содержать переносимый SQL, а варианты BigQuery или Snowflake нужны только при различиях синтаксиса или поведения.
• Dispatch убирает условные проверки адаптера из бизнес-моделей и позволяет проектам осознанно переопределять поведение пакета.
• Переносимость все равно требует тестов на каждом поддерживаемом адаптере, поскольку эквивалентный синтаксис может различаться типами или семантикой null.

К пакету dbt следует относиться как к версионируемому production-коду с узкой и проверенной причиной внедрения.

• Нужно оценить, решают ли его макросы повторяющиеся задачи, эффективно ли компилируются на целевом адаптере и имеют ли стабильные интерфейсы.
• Совместимые версии следует фиксировать в зависимостях и читать release notes перед обновлением, чтобы избежать неожиданных изменений SQL.
• Обновления пакета нужно проверять в CI на репрезентативных моделях и просматривать скомпилированный SQL важных макросов.
• Локальный код проекта предпочтительнее, если зависимость велика, плохо поддерживается или нужна ради одного простого преобразования.

dbt seeds подходят для небольших, редко меняющихся справочных наборов данных, которым место в системе контроля версий.

• Хорошие примеры включают маппинг стран, управляемые списки категорий и тестовые фикстуры, ревьюимые вместе с проектом.
• Типы столбцов следует задавать явно, если вывод хранилища может изменить коды, даты или ведущие нули.
• Крупные, чувствительные, часто обновляемые или внешне управляемые данные должны поступать через ingestion-процесс, а не CSV-коммит.
• Seed все равно требует владельца, тестов и процесса изменений, поскольку downstream-модели могут считать его контрактом.

Стратегия timestamp обнаруживает изменения по надежному столбцу updated_at, а check сравнивает выбранные столбцы источника.

• Timestamp проще и хорошо масштабируется, если каждое значимое изменение продвигает достоверную временную метку источника.
• Check полезна без такой метки, но требует осознанного выбора check_cols и большего объема сравнений.
• Включение изменчивых или незначимых столбцов в check_cols создает ненужные исторические версии.
• Ни одна стратегия не безопасна, если исправления источника приходят без изменения временной метки или сравниваемых значений.

dbt snapshot хранит интервалы версий через dbt_valid_from и dbt_valid_to с настраиваемой обработкой удаленных исходных строк.

• Новая обнаруженная версия закрывает предыдущий интервал и вставляет текущее состояние для того же уникального ключа.
• Уникальный ключ должен стабильно определять одну логическую сущность, иначе история ошибочно разделится или перезапишется.
• Физические удаления можно игнорировать, инвалидировать или представлять новыми записями в зависимости от конфигурации snapshot и версии dbt.
• Downstream-соединения должны сопоставлять время события с интервалом действия, если нужна историческая атрибуция.

Incremental-модель идемпотентна, если повторная обработка одного входного окна дает те же целевые строки без дублей и дрейфа.

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

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

• Append только вставляет выбранные строки, поэтому дешевле всего для неизменяемых данных и небезопасен при обновлениях или повторной обработке.
• Merge обновляет совпавшие уникальные ключи и вставляет новые, а delete plus insert заменяет совпавшие ключи с более широкой поддержкой адаптеров.
• Insert overwrite заменяет целые партиции и хорошо работает, когда партиции служат надежными единицами пересчета.
• Microbatch делит временной диапазон на ограниченные пакеты, улучшая возобновляемость и параллелизм для очень крупных событийных наборов.

Incremental-модель должна повторно обрабатывать осознанно выбранное перекрытие или получать изменения из надежного сигнала обновления, а не фильтровать только по последнему времени события.

• Окно lookback захватывает задержанные события, но его длина должна отражать измеренное опоздание и допустимую стоимость.
• updated_at или последовательность CDC точнее выделяют изменения, если источник гарантирует полноту.
• Merge или замена партиций должны согласовывать повторно обработанные строки на гранулярности модели, чтобы не создавать дубли.
• Периодическая полная сверка может ограничить остаточный дрейф за пределами выбранного окна изменений.

on_schema_change определяет, как dbt согласует выбранные столбцы модели с существующей incremental-таблицей, но не выполняет backfill значений.

• ignore оставляет целевую схему без изменений, а fail останавливает запуск при обнаружении различия.
• append_new_columns добавляет новые выбранные столбцы, не удаляя старые.
• sync_all_columns синхронизирует добавления, удаления и поддерживаемые изменения типов, но может быть дорогим в некоторых хранилищах.
• В существующих строках новые столбцы могут остаться пустыми или старыми, поэтому full refresh или явный backfill остается отдельным решением.

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

• Примеры включают изменение исторической бизнес-логики, исправленную историю источника или новый столбец, требующий значений для всех прошлых строк.
• Перед пересборкой крупной таблицы команда должна оценить время, стоимость хранилища, блокировки и доступность для downstream-потребителей.
• Пересчет отдельных партиций предпочтительнее, если он восстанавливает корректность без замены всей таблицы.
• Защита от full refresh предотвращает случайные пересборки, а документированная процедура делает намеренный запуск воспроизводимым.

Контракт модели dbt при построении проверяет объявленные имена выходных столбцов и поддерживаемые типы данных.

• Он дает downstream-потребителям явный структурный интерфейс и заставляет несовместимые изменения схемы завершаться ошибкой заранее.
• Ограничения можно объявить, но фактическое принудительное применение зависит от хранилища и типа ограничения.
• Контракты не доказывают семантическую корректность, свежесть, уникальность или допустимые значения без дополнительных тестов и SLA.
• Версионированные модели подходят, когда намеренно несовместимый интерфейс должен временно сосуществовать с текущим для миграции потребителей.

Полезный dbt exposure описывает реальный downstream-артефакт, его зависимости, владельца, тип и бизнес-критичность.

• depends_on должен ссылаться на модели или метрики, действительно питающие дашборд, ноутбук, приложение или reverse-ETL-синхронизацию.
• Владелец и maturity делают lineage применимым, показывая, кто согласует изменения и насколько тщательно нужно защищать артефакт.
• Ссылки на статус или URL связывают сгенерированную документацию с потребителем и его поверхностью мониторинга.
• Покрытие exposures приносит пользу, когда CI использует lineage для определения затронутых потребителей, а не когда записи остаются декоративными.

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

• warn_after может обозначать раннее ухудшение, а error_after представляет нарушенное обязательство и должен проваливать соответствующую проверку.
• loaded_at_field должен отражать доступность после загрузки, а не несвязанное время бизнес-события.
• Пороги должны учитывать частоту источника, часовой пояс, выходные и известные окна доставки вместо одного глобального значения.
• Exposures связывают каждое правило freshness с дашбордами, анализами Hex или reverse-ETL-аудиториями, чьи SLA от него зависят.

Slim CI сравнивает текущий проект с предыдущим манифестом, строит измененные узлы и выбранных потомков, а неизмененные ссылки направляет в существующее окружение.

• State-селекторы вроде state:modified находят изменения графа или конфигурации, записанные в артефактах.
• Оператор plus может включить downstream-потомков, чье поведение способно измениться из-за измененного предка.
• defer разрешает ref для непостроенных моделей через стабильное окружение сравнения, избегая полной пересборки хранилища в CI.
• CI должен использовать совместимые манифесты и учитывать макросы, seeds, переменные и косвенный выбор тестов, способные расширить область влияния.

dbt Core предоставляет CLI-фреймворк преобразований, а dbt Cloud добавляет управляемый control plane для разработки, расписаний, метаданных и контролируемого выполнения.

• Core дает гибкость развертывания, но оставляет команде оркестрацию, учетные данные, хранение артефактов и среду разработки.
• Cloud предоставляет управляемые jobs, IDE, контроль окружений, логи и платформенные функции, доступность которых зависит от тарифа.
• Оба запускают dbt-проекты в хранилище, поэтому дизайн моделей и производительность SQL остаются ответственностью команды.
• Выбор должен учитывать governance, интеграции, стоимость и операционный ownership, а не предположение, что один вариант меняет семантику dbt.