WikiDer > Извлечь, преобразовать, загрузить

Extract, transform, load

В вычисление, извлечь, преобразовать, загрузить (ETL) - это общая процедура копирования данных из одного или нескольких источников в целевую систему, которая представляет данные иначе, чем источник (и), или в другом контексте, чем источник (ы). Процесс ETL стал популярной концепцией в 1970-х годах и часто используется в хранилище данных.^[1]

Извлечение данных включает извлечение данных из однородных или разнородных источников; преобразование данных обрабатывает данные очистка данных и преобразование их в надлежащий формат / структуру хранения для целей запросов и анализа; наконец, загрузка данных описывает вставку данных в окончательную целевую базу данных, такую как хранилище операционных данных, а витрина данных, озеро данных или хранилище данных.^[2]^[3]

Правильно спроектированная система ETL извлекает данные из исходных систем, обеспечивает соблюдение стандартов качества и согласованности данных, согласовывает данные, чтобы отдельные источники можно было использовать вместе, и, наконец, доставляет данные в формате, готовом к презентации, чтобы разработчики приложений могли создавать приложения и конечные пользователи. может принимать решения.^[4]

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

Системы ETL обычно объединяют данные из нескольких приложений (систем), которые обычно разрабатываются и поддерживаются разными поставщиками или размещаются на отдельном компьютерном оборудовании. Отдельные системы, содержащие исходные данные, часто управляются разными сотрудниками. Например, система учета затрат может объединять данные из расчета заработной платы, продаж и закупок.

Обычная диаграмма ETL^[4]

Извлекать

Первая часть процесса ETL включает извлечение данных из исходной системы (систем). Во многих случаях это является наиболее важным аспектом ETL, поскольку извлечение данных правильно создает основу для успеха последующих процессов. Большинство проектов хранилищ данных объединяют данные из разных исходных систем. Каждая отдельная система может также использовать другую организацию данных и / или формат. Общие форматы источников данных включают реляционные базы данных, XML, JSON и плоские файлы, но может также включать нереляционные структуры базы данных, такие как Система управления информацией (IMS) или другие структуры данных, такие как Метод доступа к виртуальному хранилищу (VSAM) или же Индексированный метод последовательного доступа (ISAM), или даже форматы, полученные из внешних источников такими способами, как веб-паук или же скребок экрана. Потоковая передача извлеченного источника данных и загрузка «на лету» в целевую базу данных - это еще один способ выполнения ETL, когда промежуточное хранилище данных не требуется. В общем, этап извлечения направлен на преобразование данных в единый формат, подходящий для обработки преобразования.

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

Преобразовать

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

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

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

Выбор только определенных столбцов для загрузки: (или выбор ноль столбцы не загружать). Например, если исходные данные имеют три столбца (также известные как «атрибуты»), roll_no, age и salary, тогда выбор может включать только roll_no и salary. Или механизм выбора может игнорировать все записи, в которых отсутствует зарплата (salary = null).
Перевод кодированных значений: (например, если исходная система кодирует мужской пол как "1" и женский как "2", но склад кодирует мужской как "M", а женский как "F")
Кодирование значений в произвольной форме: (например, сопоставление "Мужской" с "M")
Получение нового расчетного значения: (например, sale_amount = qty * unit_price)
Сортировка или упорядочение данных на основе списка столбцов для повышения эффективности поиска.
Присоединение данные из нескольких источников (например, поиск, слияние) и дедупликация данные
Агрегирование (например, сведение - суммирование нескольких строк данных - общий объем продаж для каждого магазина, для каждого региона и т. Д.)
Создание суррогатный ключ значения
Транспонирование или же поворот (превращение нескольких столбцов в несколько строк или наоборот)
Разделение столбца на несколько столбцов (например, преобразовывая список, разделенный запятыми, заданную как строку в одном столбце, на отдельные значения в разных столбцах)
Разбивка повторяющихся столбцов
Поиск и проверка соответствующих данных из таблиц или справочных файлов
Применение любой формы проверки данных; неудавшаяся проверка может привести к полному отклонению данных, частичному отклонению или отсутствию отклонения вообще, и, таким образом, никакие, некоторые или все данные не передаются на следующий этап в зависимости от дизайна правила и обработки исключений; многие из вышеупомянутых преобразований могут привести к исключениям, например, когда преобразование кода анализирует неизвестный код в извлеченных данных

Нагрузка

На этапе загрузки данные загружаются в конечную цель, которой может быть любое хранилище данных, включая простой плоский файл с разделителями или хранилище данных.^[5] В зависимости от требований организации этот процесс сильно различается. Некоторые хранилища данных могут заменять существующую информацию совокупной информацией; обновление извлеченных данных часто выполняется ежедневно, еженедельно или ежемесячно. Другие хранилища данных (или даже другие части того же хранилища данных) могут добавлять новые данные в исторической форме через равные промежутки времени, например ежечасно. Чтобы понять это, рассмотрим хранилище данных, которое требуется для ведения записей о продажах за последний год. Это хранилище данных перезаписывает любые данные старше года новыми данными. Однако ввод данных для любого окна за один год осуществляется в историческом порядке. Сроки и объем замены или добавления являются стратегическим выбором дизайна, зависящим от имеющегося времени и бизнес потребности. Более сложные системы могут вести историю и контрольный журнал всех изменений данных, загруженных в хранилище данных.^[6]

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

Например, финансовое учреждение может располагать информацией о клиенте в нескольких отделах, и в каждом отделе информация об этом клиенте может быть указана по-разному. Отдел членства может перечислить клиента по имени, а бухгалтерия - по номеру. ETL может объединять все эти элементы данных и объединять их в единое представление, например, для хранения в базе данных или хранилище данных.
Еще один способ использования ETL компаниями - это постоянное перемещение информации в другое приложение. Например, новое приложение может использовать другого поставщика базы данных и, скорее всего, совсем другую схему базы данных. ETL можно использовать для преобразования данных в формат, подходящий для использования в новом приложении.
Примером может быть Система возмещения расходов и затрат (ECRS) например, используемый бухгалтерия, консультации, и юридические фирмы. Данные обычно попадают в время и биллинговая система, хотя некоторые предприятия могут также использовать необработанные данные для отчетов о производительности сотрудников для отдела кадров (отдела кадров) или отчетов об использовании оборудования для управления оборудованием.

Реальный цикл ETL

Типичный реальный цикл ETL состоит из следующих этапов выполнения:

Начало цикла
Строить справочные данные
Выписка (из источников)
Подтвердить
Преобразовать (чистый, подать заявление бизнес правила, проверить целостность данных, Создайте агрегаты или дезагрегирует)
Stage (загрузить в постановка таблицы, если используются)
Аудиторские отчеты (например, на соблюдение бизнес-правил. Также при выходе из строя помогает диагностировать / ремонтировать)
Опубликовать (в целевые таблицы)
Архив

Вызовы

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

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

Хранилища данных обычно собираются из множества источников данных с разными форматами и назначениями. Таким образом, ETL является ключевым процессом для объединения всех данных в стандартной однородной среде.

Анализ дизайна^[7] следует установить масштабируемость системы ETL на протяжении всего срока ее использования, включая понимание объемов данных, которые необходимо обработать в соглашения об уровне обслуживания. Время, доступное для извлечения из исходных систем, может измениться, что может означать, что такой же объем данных, возможно, придется обработать за меньшее время. Некоторые системы ETL должны масштабироваться, чтобы обрабатывать терабайты данных, чтобы обновлять хранилища данных десятками терабайт данных. Для увеличения объемов данных могут потребоваться проекты, которые можно масштабировать ежедневно. партия к многодневным микропакетам для интеграции с очереди сообщений или сбор данных об изменениях в реальном времени для непрерывного преобразования и обновления.

Спектакль

Поставщики ETL сравнивают свои системы записи со скоростью несколько ТБ (терабайт) в час (или ~ 1 ГБ в секунду), используя мощные серверы с несколькими процессорами, несколькими жесткими дисками, несколькими гигабитными сетевыми соединениями и большим объемом памяти.

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

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

Тем не менее, даже при использовании массовых операций доступ к базе данных обычно является узким местом в процессе ETL. Вот некоторые распространенные методы, используемые для повышения производительности:

Раздел таблицы (и индексы): старайтесь, чтобы разделы были одинакового размера (следите за ноль значения, которые могут исказить разбиение)
Выполните всю проверку на уровне ETL перед загрузкой: отключите честность проверка (отключить ограничение ...) в таблицах целевой базы данных во время загрузки
Запрещать триггеры (отключить триггер ...) в таблицах целевой базы данных во время загрузки: моделируйте их действие как отдельный шаг
Создавать идентификаторы на уровне ETL (не в базе данных)
Отбросьте индексы (в таблице или разделе) перед загрузкой - и воссоздать их после загрузки (SQL: падение индекса ...; создать индекс ...)
По возможности используйте параллельную массовую загрузку - хорошо работает, когда таблица разделена на разделы или нет индексов (Примечание: попытка выполнить параллельную загрузку в одну и ту же таблицу (раздел) обычно вызывает блокировки - если не для строк данных, то для индексов)
Если существует потребность в вставке, обновлении или удалении, выясните, какие строки и каким образом следует обрабатывать на уровне ETL, а затем обработайте эти три операции в базе данных отдельно; вы часто можете выполнять массовую загрузку вставок, но обновления и удаления обычно проходят через API (с помощью SQL)

Выполнение определенных операций в базе данных или вне ее может потребовать компромисса. Например, удаление дубликатов с помощью отчетливый может быть медленным в базе данных; таким образом, имеет смысл делать это снаружи. С другой стороны, при использовании отчетливый значительно (x100) уменьшает количество извлекаемых строк, тогда имеет смысл как можно раньше удалить дубликаты в базе данных перед выгрузкой данных.

Распространенный источник проблем в ETL - это большое количество зависимостей между заданиями ETL. Например, задание «Б» не может начаться, пока задание «А» не завершено. Обычно можно добиться лучшей производительности, визуализируя все процессы на графике и пытаясь уменьшить график, максимально используя параллелизм, и сделать «цепочки» последовательной обработки как можно короче. Опять же, действительно может помочь разделение больших таблиц и их индексов.

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

Источники
Центральный слой ETL
Цели

Такой подход позволяет обработке максимально использовать преимущества параллелизма. Например, если вам нужно загрузить данные в две базы данных, вы можете запускать загрузки параллельно (вместо загрузки в первую, а затем репликации во вторую).

Иногда обработка должна происходить последовательно. Например, размерные (справочные) данные необходимы, прежде чем можно будет получить и проверить строки для основных таблицы фактов.

Параллельная обработка

Недавний^{[Обновить]} разработка в программном обеспечении ETL - это реализация параллельная обработка. Он позволил ряду методов улучшить общую производительность ETL при работе с большими объемами данных.

В приложениях ETL реализуются три основных типа параллелизма:

Данные: путем разделения одного последовательного файла на более мелкие файлы данных для обеспечения параллельный доступ
Трубопровод: позволяет одновременно запускать несколько компонентов на одном поток данных, например поиск значения в записи 1 одновременно с добавлением двух полей в записи 2
Компонент: одновременный запуск нескольких процессы в разных потоках данных в одном задании, например сортировка одного входного файла при удалении дубликатов в другом файле

Все три типа параллелизма обычно работают вместе в одном задании или задаче.

Дополнительная трудность связана с обеспечением относительной согласованности загружаемых данных. Поскольку несколько исходных баз данных могут иметь разные циклы обновления (некоторые могут обновляться каждые несколько минут, а другие могут занимать дни или недели), от системы ETL может потребоваться удерживать определенные данные до тех пор, пока все источники не будут синхронизированы. Аналогичным образом, если склад может потребоваться согласовать содержимое в исходной системе или с главной бухгалтерской книгой, становится необходимым создание точек синхронизации и согласования.

Возможность повторного запуска, восстанавливаемость

Процедуры хранилища данных обычно подразделяют большой процесс ETL на более мелкие части, выполняемые последовательно или параллельно. Чтобы отслеживать потоки данных, имеет смысл пометить каждую строку данных «row_id» и пометить каждую часть процесса «run_id». В случае сбоя наличие этих идентификаторов поможет откатить и перезапустить отказавший кусок.

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

Виртуальный ETL

По состоянию на 2010 г.^{[Обновить]}, виртуализация данных начал продвигать обработку ETL. Применение виртуализации данных к ETL позволило решить самые распространенные задачи ETL в перенос данных и интеграция приложений для нескольких разрозненных источников данных. Виртуальный ETL работает с абстрактным представлением объектов или сущностей, собранных из различных реляционных, полуструктурированных и неструктурированные данные источники. Инструменты ETL могут использовать объектно-ориентированное моделирование и работать с представлениями сущностей, постоянно хранящимися в централизованно расположенном ступица и спица архитектура. Такая коллекция, которая содержит представления сущностей или объектов, собранных из источников данных для обработки ETL, называется репозиторием метаданных и может находиться в памяти.^[8] или быть настойчивым. Используя постоянный репозиторий метаданных, инструменты ETL могут переходить от разовых проектов к постоянному промежуточному программному обеспечению, выполняя согласование данных и профилирование данных последовательно и практически в реальном времени.^[9]

Работа с ключами

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

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

Рекомендуемый способ решения проблемы включает добавление суррогатного ключа хранилища, который используется в качестве внешнего ключа из таблицы фактов.^[10]

Обычно обновления происходят в исходных данных измерения, которые, очевидно, должны быть отражены в хранилище данных.

Если для создания отчетов требуется первичный ключ исходных данных, измерение уже содержит эту информацию для каждой строки. Если в исходных данных используется суррогатный ключ, хранилище должно отслеживать его, даже если он никогда не используется в запросах или отчетах; это делается путем создания Справочная таблица который содержит суррогатный ключ хранилища и исходный ключ.^[11] Таким образом, измерение не загрязняется суррогатами из различных исходных систем, а возможность обновления сохраняется.

Таблица подстановки используется по-разному в зависимости от характера исходных данных. Можно рассмотреть 5 типов;^[11] сюда включены три:

Тип 1: Строка измерения просто обновляется, чтобы соответствовать текущему состоянию исходной системы; склад не фиксирует историю; таблица поиска используется для определения строки измерения для обновления или перезаписи
Тип 2: Добавляется новая размерная строка с новым состоянием исходной системы; назначается новый суррогатный ключ; исходный ключ больше не уникален в таблице поиска
Полностью зарегистрирован: Новая строка измерения добавляется с новым состоянием исходной системы, тогда как предыдущая строка измерения обновляется, чтобы отразить, что она больше не активна, и время деактивации.

Инструменты

Используя установленную структуру ETL, можно увеличить свои шансы на улучшение связи и масштабируемость.^{[нужна цитата]} Хороший инструмент ETL должен уметь взаимодействовать со множеством различных реляционные базы данных и прочитать различные форматы файлов, используемые в организации. Инструменты ETL начали мигрировать в Интеграция корпоративных приложений, или даже Корпоративная служебная шина, системы, которые теперь охватывают гораздо больше, чем просто извлечение, преобразование и загрузку данных. Многие поставщики ETL теперь имеют профилирование данных, Качество данных, и метаданные возможности. Обычный вариант использования инструментов ETL включает преобразование файлов CSV в форматы, читаемые реляционными базами данных. Типичный перевод миллионов записей облегчается с помощью инструментов ETL, которые позволяют пользователям вводить потоки / файлы данных в формате csv и импортировать их в базу данных с минимальным количеством кода.

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

Хотя инструменты ETL традиционно предназначались для разработчиков и ИТ-персонала, новая тенденция состоит в том, чтобы предоставлять эти возможности бизнес-пользователям, чтобы они могли сами создавать соединения и интеграции данных при необходимости, а не обращаться к ИТ-персоналу.^[12] Gartner называет этих нетехнических пользователей гражданскими интеграторами.^[13]

Против. ELT

Извлечь, загрузить, преобразовать (ELT) - это вариант ETL, при котором извлеченные данные сначала загружаются в целевую систему.^[14]Архитектура аналитического конвейера также должна учитывать, где очищать и обогащать данные.^[14] а также как согласовать размеры.^[4]

Облачные хранилища данных, такие как Amazon Redshift, Google BigQuery, и Snowflake Computing смогли обеспечить высокую масштабируемость вычислительной мощности. Это позволяет предприятиям отказаться от преобразований с предварительной загрузкой и реплицировать необработанные данные в свои хранилища данных, где они могут преобразовывать их по мере необходимости, используя SQL.

После использования ELT данные могут быть обработаны и сохранены на витрине данных.^[15]

У каждого подхода есть свои плюсы и минусы.^[16] Большинство инструментов интеграции данных склоняются к ETL, в то время как ELT популярен в устройствах баз данных и хранилищ данных. Точно так же можно выполнить TEL (преобразование, извлечение, загрузка), когда данные сначала преобразуются в цепочке блоков (как способ записи изменений в данных, например, сжигания токена) перед извлечением и загрузкой в другое хранилище данных.^[17]

Navigation