ETL

ETL расшифровывается как извлечение, преобразование, загрузка и описывает процесс извлечения данных из исходных систем, преобразования их в согласованную структуру и загрузки в целевое хранилище, например, в хранилище данных. Это основа аналитики, и от её надёжности зависит, можно ли доверять отчётам, построенным на её основе.

Каждый этап сопряжен с определенными трудностями. На этапе извлечения данных необходимо получить информацию из систем, не предназначенных для внешних запросов, обработать ограничения скорости запросов API, обеспечить поэтапное обнаружение изменений и использовать источники, не предоставляющие надежного способа идентификации изменений. На этапе преобразования необходимо согласовать несогласованные форматы, различающиеся идентификаторы, противоречащие определения и отсутствующие значения. На этапе загрузки необходимо обрабатывать большие объемы данных, сохранять историю и работать с записями, поступающими с задержкой или в неправильном порядке.

Вариант ELT меняет местами два последних этапа: необработанные данные загружаются в целевую систему, а преобразование происходит там же. Это стало распространенным явлением, поскольку современные платформы хранилищ данных обладают достаточной вычислительной мощностью для эффективного преобразования на месте, а сохранение необработанных данных позволяет пересматривать и повторно применять преобразования без повторного извлечения данных из источников. Это также означает, что ошибки в логике преобразования являются исправимыми, а не необратимыми.

Поэтапная обработка — это практическая необходимость, которая усложняет большинство реализаций. Переобработка всех исторических данных при каждом запуске проста, но становится нецелесообразной по мере роста объёма данных, поэтому конвейеры должны определять, что изменилось с момента последнего запуска. Источники без надёжных меток времени изменений, записи, обновляемые ретроспективно, и удаления, не оставляющие следов, — всё это усложняет задачу, а некорректная логика поэтапной обработки приводит к незаметному получению неполных данных.

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

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

Планирование и управление зависимостями определяют, будет ли результат согласованным. Конвейеры редко работают изолированно, и задача, запущенная до завершения исходной задачи, выдает частичные результаты, которые выглядят полными. Существуют инструменты оркестровки, позволяющие явно выражать эти зависимости, и конвейеры, объединенные на основе предположений о времени выполнения, а не на основе объявленных зависимостей, периодически дают сбои, которые трудно воспроизвести.

Документация и отслеживание происхождения данных имеют значение, потому что конвейеры обработки данных переживают тех, кто их создает. Знание происхождения каждого поля, примененных преобразований и закодированных бизнес-правил необходимо для ответа на вопросы о том, почему число выглядит именно так, и для оценки влияния изменений в исходной системе. Недокументированные конвейеры обработки данных превращаются в системы, которые никто не осмеливается модифицировать, и именно поэтому в организациях возникают параллельные конвейеры, выдающие противоречивые данные.

Поскольку ценность, обеспечиваемая системой, определяется скорее надежностью, чем ее сложностью, инженерный подход к проектированию и эксплуатации трубопроводов должен соответствовать подходу к разработке производственного программного обеспечения. На практике трубопроводы строятся и эксплуатируются... разработка продукта или ИТ отделЛогика преобразования, кодирующая определения бизнес-процессов, задается с помощью аналитика данныхПравила проверки лучше согласовать до создания первого конвейера обработки данных, а не добавлять после первого инцидента.