ETL-процесс: извлечение, преобразование, загрузка и границы ELT

Автор: Ai Flowi · Опубликовано

ETL-процесс — это конвейер данных, который извлекает записи из источника, преобразует их в согласованное представление и загружает принятый результат в целевую систему. ELT меняет порядок: извлечённые записи загружаются до преобразования в целевой среде. Существенно то, на какой границе выполняются проверка, обработка отклонённых записей и восстановление, а не просто каким инструментом перемещаются данные.

Что означают три этапа

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

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

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

Вымышленный пакет с зафиксированными решениями

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

Исходные значения и предлагаемые решения по преобразованию
Исходная строкаИсходный ID товара / количествоРешениеЗапись для загрузки
A“0017” / “4”Сохранить ID; проверить и преобразовать количество.“0017” / 4
B“0021” / “0”Ноль соответствует заявленному контракту.“0021” / 0
C“0032” / “many”Изолировать: значение количества не представляет целое число.Записи для загрузки нет.
D“” / “2”Изолировать: обязательный ID пуст.Записи для загрузки нет.

Извлечены четыре строки; при преобразовании две приняты и две отклонены. Если подтверждена запись только A, загрузка не завершена: одна принятая строка подтверждена, другая ожидает обработки или имеет неизвестный результат. Не сообщайте о двух загруженных строках лишь потому, что преобразование подготовило две записи.

Запись об отклонении должна сохранять ссылку на источник, исходные значения и конкретную причину. Исправление C создаёт новое проверенное решение, связанное с C, а не стирает сведения о первой попытке. Подробную конфигурацию переноса смотрите в руководстве по импорту CSV в Google Sheets.

Чем ETL отличается от ELT на одних и тех же записях?

Один пакет складских данных, разное место преобразования
ГраницаETLELT
Начальное содержимое целевой системыВ целевую таблицу попадают только проверенные записи для загрузки.Четыре исходные строки попадают в контролируемую промежуточную область.
ПреобразованиеКоличество проверяется до загрузки в целевую таблицу.Количество проверяется в исходных записях промежуточной области.
Отклонённые записиСохраняются отдельно от принятых записей целевой системы.Сохраняются в промежуточной области с решением об отклонении.
Сведения для восстановленияСнимок источника, решения и подтверждённые записи.Промежуточный пакет, версия преобразования и опубликованное состояние целевой системы.

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

По теме: Обратный ETL: применение данных и границы записи.

Контрольные точки, отметки прогресса и повторное выполнение

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

Если несколько записей имеют одинаковое время обновления, одна временная метка может не определять полную границу. Задайте стабильный дополнительный критерий порядка либо чтение с перекрытием и явной обработкой дубликатов. Для запоздавших изменений нужна отдельная политика сверки: более новая отметка прогресса не доказывает, что старые записи больше не изменятся.

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

Как представить границы обработки складских данных в конструкторе

Справочники Load CSV, JSON Operations и записи в Google Sheets описывают интерфейсы чтения, сопоставления и целевой системы для этого примера пакета.

Ключевое решение конвейера — когда исходная строка допускается к записи. A и B соответствуют складскому контракту; C и D остаются в журнале отклонённых записей. Не передавайте все четыре строки компоненту записи в расчёте на проверку средствами форматирования целевой системы. Для предлагаемого складского конвейера Load CSV, JSON Operations и Append Rows описаны в каталоге; не протестированы Ai Flowi в производственной среде. Совместная конфигурация чтения, сопоставления и записи не тестировалась.

Пример конфигурации, а не зафиксированный тест

  1. Передайте вымышленный экспорт через поле csv_file компонента Load CSV; проверьте его строки JSON до выбора полей.
  2. Для пробного запуска с проверенной схемой сопоставления передайте проверенный исходный JSON в поле data компонента JSON Operations и выберите "JQ Expression" в поле operations. Укажите в поле query проверенное выражение валидации и сопоставления строк; отдельно сохраните отклонённые записи до выбора записей для загрузки.
  3. Передайте утверждённые массивы в поле values компонента Append Rows; выберите "RAW" в поле value_input_option, чтобы сохранить проверенное представление ячеек при предлагаемой записи. Свяжите range_name со складским диапазоном, spreadsheet_id с его документом, а google_account с авторизованным подключением.
  4. Сравните записанные значения с журналом принятых строк, прежде чем помечать пакет завершённым.

Для сверки нужны идентификаторы строк и итоговые показатели. Если целевая система содержит A дважды, в ней две строки, но A и B загружены неправильно. Сравните множество ссылок принятых исходных записей с множеством ссылок на подтверждённые записи целевой системы, затем проверьте количества по проверенным записям для загрузки. Оставьте B в ожидании, если её запись не подтверждается. Итог по пакету может совпасть, хотя один товар отсутствует, а другой продублирован.

Смотрите руководство по настройке импорта CSV в таблицу для требований к аккаунту и подключению; для этого примера передайте конструктору разрешённый экспорт складских остатков. Складской контракт использует явные правила и не вызывает модель; любые расходы на услуги провайдера не включены в подписку Flowi.

Изменение схемы и ограничения

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

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

Связанные термины

Очистка данных объясняет исправления и неразрешённые значения при преобразовании. Интеграция API описывает границу сервиса, через которую могут происходить извлечение или загрузка.