Введение

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

Экстракт

Обработка ETL включает извлечение данных из исходной системы (систем). Во многих случаях это является наиболее важным этапом ETL, поскольку корректное извлечение данных закладывает основу для успешной работы последующих процессов. Большинство проектов по созданию хранилищ данных объединяют данные из различных источников. Каждая отдельная система может использовать различную организацию и/или формат данных. Распространенные форматы источников данных включают реляционные базы данных, файлы плоской структуры, XML и JSON, но также могут включать нереляционные структуры баз данных, такие как IBM Information Management System, или другие структуры данных, такие как Virtual Storage Access Method (VSAM) или Indexed Sequential Access Method (ISAM), или даже форматы, полученные из внешних источников с помощью веб-краулеров или парсинга данных. Потоковая передача извлеченных данных и загрузка в целевую базу данных "на лету" – еще один способ выполнения ETL, когда промежуточное хранение данных не требуется. Важной частью извлечения является валидация данных для подтверждения того, что извлеченные из источников данные содержат корректные/ожидаемые значения в заданной области (например, соответствуют шаблону, значению по умолчанию или входят в список допустимых значений). Если данные не проходят валидацию, они отклоняются полностью или частично. В идеале, информация об отклоненных данных возвращается в исходную систему для дальнейшего анализа с целью выявления и исправления некорректных записей или проведения очистки данных.

Нагрузка

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

Вызовы

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

Восстановление, возмещение

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

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

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

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

Уникальные ключи играют важную роль во всех реляционных базах данных, поскольку они связывают все воедино. Уникальный ключ – это столбец, идентифицирующий данную сущность, в то время как внешний ключ – это столбец в другой таблице, ссылающийся на первичный ключ. Ключи могут состоять из нескольких столбцов, в этом случае они называются составными ключами. Во многих случаях первичный ключ представляет собой автоматически генерируемое целое число, которое не имеет значения для представляемой бизнес-сущности, а существует исключительно для целей реляционной базы данных, обычно называемого суррогатным ключом. Поскольку в хранилище данных обычно загружается информация из нескольких источников, ключи – важная проблема, требующая решения. Например, информация о клиентах может быть представлена в нескольких источниках данных, где в одном источнике в качестве первичного ключа используется номер социального страхования, в другом – номер телефона, а в третьем – суррогатный ключ. Однако хранилище данных может потребовать консолидации всей информации о клиентах в одном измерении. Рекомендуемый способ решения этой проблемы – добавление суррогатного ключа хранилища, который используется в качестве внешнего ключа из таблицы фактов. Обычно обновления происходят в исходных данных измерения, которые, очевидно, должны быть отражены в хранилище данных. Если для отчетов требуется первичный ключ исходных данных, измерение уже содержит эту информацию для каждой строки. Если исходные данные используют суррогатный ключ, хранилище должно отслеживать его, даже если он никогда не используется в запросах или отчетах; это достигается путем создания таблицы соответствий, содержащей суррогатный ключ хранилища и исходный ключ. Таким образом, измерение не засоряется суррогатными ключами из различных исходных систем, при этом сохраняется возможность обновления. Таблица соответствий используется по-разному в зависимости от характера исходных данных. Следует рассмотреть 5 типов; Gartner называет этих нетехнических пользователей "гражданскими интеграторами".

ETL против ELT

Извлечение, загрузка, преобразование (ELT) — это вариант ETL, при котором извлеченные данные сначала загружаются в целевую систему. Архитектура аналитического конвейера также должна учитывать, где проводить очистку и обогащение данных. Эта проблема рассматривалась в книге Ральфа Кимбалла и Джо Касерты «The Data Warehouse ETL Toolkit» (Wiley, 2004), которая используется как учебник на курсах обучения процессам ETL в хранилищах данных. Облачные хранилища данных, такие как Amazon Redshift, Google BigQuery, Microsoft Azure Synapse Analytics и Snowflake Inc., обеспечили высокомасштабируемые вычислительные мощности. Это позволяет компаниям отказаться от предварительных преобразований и реплицировать необработанные данные в свои хранилища данных, где они могут преобразовывать их по мере необходимости с помощью SQL. После применения ELT данные могут быть дополнительно обработаны и сохранены в хранилище данных (data mart). Большинство инструментов интеграции данных ориентированы на ETL, в то время как ELT популярен в системах баз данных и хранилищ данных. Кроме того, возможно выполнение TEL (Transform, Extract, Load), когда данные сначала преобразуются в блокчейне (как способ записи изменений данных, например, сжигание токенов), а затем извлекаются и загружаются в другое хранилище данных.