--- title: ETL questionDates: q-transfer-0191: '2026-10-01' q-transfer-0192: '2026-10-01' q-transfer-0193: '2026-10-01' q-transfer-0194: '2026-10-01' q-transfer-0288: '2026-10-01' q-transfer-0289: '2026-10-01' q-transfer-0290: '2026-10-01' q-transfer-0316: '2026-10-01' q-transfer-0317: '2026-10-01' q-transfer-0318: '2026-10-01' seo: description: >- Тема «ETL» для собеседования Data Engineer. ETL - с какими инструментами работали? Какие платформы ETL вы знаете? title: ETL — Data Engineer --- [Все темы Data Engineer](/prep/data-engineer) ## ETL - с какими инструментами работали? [#q-14bee738d69b810092ace047906cf716] ETL (Extract, Transform, Load) - это процесс извлечения данных из источников, их преобразования и загрузки в целевую базу данных или хранилище данных. Некоторые из популярных инструментов ETL включают Apache NiFi, Talend, Informatica PowerCenter, Microsoft SQL Server Integration Services (SSIS), Apache Airflow, AWS Glue и Google Cloud Dataflow. каждый из них имеет свои особенности и предоставляет различные функции для автоматизации и управления процессом ETL. :::note[Ссылки для изучения] 1. [EL-инструменты: Hevo Data, Fivetran, Airbyte и критерии выбора](https://habr.com/ru/companies/otus/articles/699498/) ::: --- ## Какие платформы ETL вы знаете? [#q-14bee738d69b81fa9f9fed348088edbf] Некоторые из популярных платформ ETL включают Apache NiFi, Talend, Informatica PowerCenter, Microsoft SQL Server Integration Services (SSIS), Apache Airflow, AWS Glue и Google Cloud Dataflow. Каждая из этих платформ предоставляет средства для извлечения, преобразования и загрузки данных из различных источников в целевые системы хранения. :::note[Ссылки для изучения] 1. [EL-инструменты: Hevo Data, Fivetran, Airbyte и критерии выбора](https://habr.com/ru/companies/otus/articles/699498/) ::: --- ## Какие этапы включает в себя процесс ETL? [#q-14bee738d69b81abaaf6e7acc1b3f357] Процесс ETL (Extract, Transform, Load) включает три основных этапа: {/* prettier-ignore */} 1. Извлечение (Extract): - Сбор данных из различных источников, таких как базы данных, файлы, API и др. - Удостоверение, что данные извлекаются корректно и полностью. 1. Трансформация (Transform): - Очистка данных (удаление дубликатов, обработка пропусков). - Преобразование данных в нужный формат. - Агрегация и обогащение данных. - Применение бизнес-правил. 1. Загрузка (Load): - Загрузка преобразованных данных в целевое хранилище данных. - Обеспечение целостности и согласованности данных в хранилище. :::note[Ссылки для изучения] 1. [Этапы ETL: извлечение, очистка, преобразование и загрузка](https://aws.amazon.com/ru/what-is/etl/) ::: --- ## Как вы справляетесь с проблемой качества данных в процессе ETL? [#q-14bee738d69b8120adece05c9448922e] Для обеспечения качества данных в процессе ETL используются следующие методы: {/* prettier-ignore */} 1. Очистка данных: - Удаление дубликатов и обработка пропусков. - Корректировка ошибок и приведение данных к единому формату. 1. Валидация данных: - Проверка данных на соответствие заданным правилам и требованиям. - Использование автоматических тестов и проверок для выявления аномалий. 1. Мониторинг и логирование: - Настройка систем мониторинга и логирования для отслеживания качества данных. - Анализ логов и метрик для своевременного обнаружения и устранения проблем. 1. Использование ETL-инструментов с функциями контроля качества: - Использование ETL-инструментов, таких как Apache NiFi, Talend, Informatica, которые поддерживают функции контроля качества данных. :::note[Ссылки для изучения] 1. [ETL: очистка, дедупликация и преобразование данных](https://aws.amazon.com/ru/what-is/etl/) 1. [dbt: модели, автоматические тесты качества и документация](https://habr.com/ru/articles/959846/) ::: --- ## Какие инструменты ETL вы используете и почему? [#q-14bee738d69b811c8649c238339db4f5] Используемые инструменты ETL включают: {/* prettier-ignore */} 1. Apache NiFi: - Преимущества: Легкость настройки потоков данных, гибкость и масштабируемость. - Использование: Реализация сложных ETL-процессов и интеграция различных источников данных. 1. Talend: - Преимущества: Богатый набор коннекторов, визуальный интерфейс для проектирования ETL-процессов. - Использование: Универсальное решение для ETL-задач и интеграции данных. 1. Informatica: - Преимущества: Высокая производительность, масштабируемость, поддержка большого количества источников данных. - Использование: Большие корпоративные проекты с высокими требованиями к надежности и производительности. 1. Apache Airflow: - Преимущества: Управление сложными ETL-пайплайнами, гибкость и возможность интеграции с различными системами. - Использование: Автоматизация и оркестрация ETL-процессов. :::note[Ссылки для изучения] 1. [EL-инструменты: Hevo Data, Fivetran, Airbyte и критерии выбора](https://habr.com/ru/companies/otus/articles/699498/) ::: --- ## Как сделать ETL-процесс идемпотентным? [#q-transfer-0191] Идемпотентный ETL дает один итог при повторе того же интервала. Для этого используют устойчивый бизнес-ключ или event ID, `MERGE`/`UPSERT`, атомарную замену партиции и checkpoint, который фиксируется только после успешной публикации. Частично записанный результат не должен считаться завершенным. Свойство проверяют практично: запускают один вход дважды и сравнивают строки, агрегаты и побочные эффекты. Повторный запуск той же партии и сбой посередине входят в приемку, иначе восстановление остается непроверенным. :::note[Ссылки для изучения] 1. [Идемпотентный ETL: повторный запуск, транзакционная перезапись и дедупликация событий](https://habr.com/ru/companies/otus/articles/1058824/) ::: --- ## Как безопасно пережить изменение схемы источника? [#q-transfer-0192] Сначала изменение схемы обнаруживают и классифицируют: добавление nullable-поля обычно совместимее удаления, переименования или сужения типа. Контракт и владельцы показывают затронутых потребителей. Несовместимое изменение проводят в несколько фаз: добавить новую форму, научить читателей принимать обе, выполнить backfill, переключить запись и лишь затем удалить старое. На каждом этапе проверяют данные и мониторят ошибки разбора и пропуски. Повторный запуск той же партии и сбой посередине входят в приемку, иначе восстановление остается непроверенным. :::note[Ссылки для изучения] 1. [Эволюция схем: совместимость и порядок обновления производителей и потребителей в Kafka](https://platformv.sbertech.ru/docs/public/KFK/11.340.0/KFKA/11.340.0/documents/schema-registry/sr-update.html) ::: --- ## Как снизить нагрузку ETL на источник? [#q-transfer-0193] Основной прием: читать только изменения по надежному watermark или CDC, а не сканировать источник целиком. Запросы делают пакетами, поддерживают нужными индексами и ограничивают частоту и параллелизм. Аналитическое чтение по возможности направляют на реплику, учитывая ее lag, и запускают в согласованное окно. Таймауты, метрики нагрузки и возможность остановить pipeline важнее фиксированной рекомендации по размеру batch. Повторный запуск той же партии и сбой посередине входят в приемку, иначе восстановление остается непроверенным. :::note[Ссылки для изучения] 1. [Как выбирать чтение из источника: full refresh, инкремент по курсору и CDC](https://habr.com/ru/companies/otus/articles/699498/) ::: --- ## Чем dbt отличается от хранимых процедур? [#q-transfer-0194] dbt компилирует модели и зависимости в SQL и выполняет их в целевом хранилище; рядом хранит тесты, документацию и lineage в коде проекта. Хранимая процедура живет в СУБД, может содержать процедурную логику и теснее связана с ее диалектом и правами. dbt удобен для управляемых преобразований наборами данных, процедура для атомарной серверной операции. Их можно сочетать, явно фиксируя границу ответственности. Повторный запуск той же партии и сбой посередине входят в приемку, иначе восстановление остается непроверенным. :::note[Ссылки для изучения] 1. [dbt 101: модели, зависимости, тесты и документация в проекте](https://habr.com/ru/articles/959846/) 1. [Хранимые процедуры PostgreSQL: создание, языки реализации и права](https://postgrespro.ru/docs/postgresql/18/sql-createprocedure) ::: --- ## Как проектировать инкрементальную загрузку в OLAP? [#q-transfer-0288] Инкремент хранит подтвержденный watermark, но читает с перекрытием, если события могут опаздывать. Партия получает стабильный ключ, дедуплицируется и пишется batch-операцией через `MERGE`, замену партиции или append с последующей консолидацией. Watermark продвигают только после атомарной публикации и проверок. Стратегия зависит от OLAP-системы: некоторые предпочитают immutable inserts и фоновое слияние вместо частых row updates. Повторный запуск той же партии и сбой посередине входят в приемку, иначе восстановление остается непроверенным. :::note[Ссылки для изучения] 1. [Инкрементальные витрины: опоздавшие события, окно перезаписи и безопасный повтор](https://habr.com/ru/companies/otus/articles/1058824/) ::: --- ## Как CDC помогает мигрировать без долгого простоя? [#q-transfer-0289] Сначала делают согласованный initial snapshot, запоминая позицию журнала. CDC затем переносит все изменения после этой позиции в порядке, достаточном для ключа или транзакции. Источник и приемник работают параллельно, пока lag не станет приемлемым; перед cutover сверяют counts, hashes и бизнес-агрегаты. Переключение имеет явную точку, период наблюдения и план возврата, а consumer CDC должен быть идемпотентным. Повторный запуск той же партии и сбой посередине входят в приемку, иначе восстановление остается непроверенным. :::note[Ссылки для изучения] 1. [Миграция PostgreSQL: копирование, непрерывная репликация и переключение после нулевого lag](https://yandex.cloud/ru/docs/tutorials/dataplatform/postgresql-versions) ::: --- ## Как вести инкрементальные загрузки в S3? [#q-transfer-0290] Объекты S3 лучше считать immutable: каждую партию пишут в новый префикс или партицию с уникальным run ID. Manifest или metadata table перечисляет опубликованные файлы, а watermark продвигается после их проверки; одним rename атомарность каталогов S3 не получают. Повторный запуск заменяет manifest либо дедуплицирует ключи. Периодическая compaction объединяет мелкие файлы без изменения уже опубликованного снимка. Повторный запуск той же партии и сбой посередине входят в приемку, иначе восстановление остается непроверенным. :::note[Ссылки для изучения] 1. [Публикация порций данных в S3: снапшоты и атомарные метаданные на примере Iceberg](https://habr.com/ru/companies/selectel/articles/1071768/) ::: --- ## Как организовать миграцию витрины между платформами? [#q-transfer-0316] Сначала инвентаризируют SQL, зависимости, расписание, grain и владельцев метрик, отдельно фиксируя различия диалектов SAS и Greenplum. Новую витрину считают параллельно на одинаковых срезах, сверяют row counts, ключи, суммы и известные исключения. Backfill делают идемпотентным. Cutover переключает потребителей по плану, после периода наблюдения; rollback возвращает старую публикацию без потери поступивших данных. Повторный запуск той же партии и сбой посередине входят в приемку, иначе восстановление остается непроверенным. :::note[Ссылки для изучения] 1. [Миграция витрины Teradata → Greenplum: перенос SQL, параллельный расчёт и сверка](https://habr.com/ru/companies/oleg-bunin/articles/821045/) ::: --- ## Где запускать проверки Great Expectations или Soda? [#q-transfer-0317] Great Expectations или Soda запускают после приема, после значимых преобразований и перед публикацией набора. Правила являются версионированным data contract: схема, null, uniqueness, ranges и сверки. Нарушения делят на blocking и warning по влиянию, результаты сохраняют с run ID и примерами. Инструмент не заменяет мониторинг freshness и объема; проверки должны укладываться в SLA и не сканировать весь lake без необходимости. Повторный запуск той же партии и сбой посередине входят в приемку, иначе восстановление остается непроверенным. :::note[Ссылки для изучения] 1. [Проверки Soda внутри пайплайна: источник, трансформации, витрины и пороги warn/fail](https://habr.com/ru/companies/banki/articles/822601/) ::: --- ## Как версионировать изменения схемы через Liquibase? [#q-transfer-0318] Liquibase хранит упорядоченный changelog из changeSet с устойчивыми `id`, `author` и путем файла. Примененные наборы и checksums записываются в служебную таблицу, поэтому один changeSet не редактируют задним числом, а добавляют новый. CI проверяет changelog, deploy применяет его один раз. Rollback нужно проектировать и тестировать отдельно: потерю данных или несовместимый type change автоматически обратить нельзя. Повторный запуск той же партии и сбой посередине входят в приемку, иначе восстановление остается непроверенным. :::note[Ссылки для изучения] 1. [Основы Liquibase: changelog, changeSet, порядок миграций и DATABASECHANGELOG](https://habr.com/ru/articles/557706/) :::