чем отличается etl и elt
ETL и ELT: разница в том, как…
В течение последних нескольких десятилетий ETL (извлечение, преобразование, загрузка) был традиционным подходом, который использовался в хранилищах данных и аналитике. Подход ELT (извлечение, загрузка, преобразование) меняет старую парадигму. Но что на самом деле происходит, когда меняются местами буквы «T» и «L»?
ETL и ELT решают одну и ту же задачу:
Компаниям необходимо собирать, обрабатывать и анализировать гигабайты данных и событий. Данные должны быть чистыми, управляемыми и готовыми к анализу. Их нужно обогатить, формировать и трансформировать, прежде чем они станут значимыми.
Но то «как» это сделано в этих подходах отличается. Новый подход открывает новые возможности во многих современных проектах обработки данных. Есть определенные различия в том, как обрабатываются необработанные данные, когда выполняется обработка и как анализ.
В этой статье мы покажем технологические различия ETL и ELT, покажем примеры инженерии данных и анализа двух подходов и рассмотрим 10 плюсов и минусов ETL и ELT.
Технологические различия: давайте сначала разберем три ключевых этапа E, T, L:
ETL и ELT: что такое ETL?
ETL требует управления необработанными данными, включая извлечение необходимой информации и выполнение правильных преобразований, чтобы в конечном итоге удовлетворить потребности бизнеса. Каждый этап: извлечение, преобразование и загрузка, требует взаимодействия инженеров и разработчиков данных и работы с ограничениями емкости традиционных хранилищ данных. Используя ETL, аналитики и другие пользователи BI привыкли ждать, поскольку простой доступ к информации невозможен до тех пор, пока не будет завершен весь процесс ETL.
Что такое ELT?
При ELT после завершения извлечения данных вы сразу же начинаете этап загрузки – перемещение всех источников данных в единое централизованное хранилище данных. Благодаря сегодняшним инфраструктурным технологиям, в которых используются облака, системы могут поддерживать большие хранилища и масштабируемые вычисления. Следовательно, большой, расширяющийся пул данных и быстрая обработка практически бесконечны для сохранения всех извлеченных необработанных данных.
Таким образом, подход ELT представляет собой современную альтернативу ETL. Однако он все еще на этапе развития. Поэтому структуры и инструменты для поддержки процесса ELT не всегда подходят для облегчения загрузки и обработки больших объемов данных. Потенциал роста очень многообещающий – предоставление неограниченного доступа ко всем вашим данным в любое время и экономия усилий и времени разработчиков для пользователей и аналитиков BI.
Практический пример
Вот пример, который показывает технологические различия между ETL и ELT, он поможет нам вникнуть в детали.
В нашей демо-версии будут использоваться две таблицы данных: одна для покупок, а другая для валют, как показано ниже:
ТАБЛИЦА ПОКУПОК
Сумма
валюта
ТАБЛИЦА ВАЛЮТ
валюта
Курс
Чтобы разобрать основы, мы рассмотрим, как эти данные обрабатывается в ETL и ELT. Для каждого из них мы покажем, как рассчитать единую сводную таблицу с использованием этих двух таблиц, включая среднюю покупку в каждой стране (на основе предоставленного IP-адреса).
Преобразование ETL в извлеченных данных
В процессе ETL к ряду правил или функций для извлеченных данных и создания таблицы, которая будет загружена применяется этап преобразования.
Вот код, который показывает процесс предварительного преобразования данных для ETL:
Используя этот скрипт, мы сопоставляем IP-адреса с соответствующей страной. Мы выводим новое рассчитанное значение «сумма», умножая значения обеих исходных таблиц в группе на атрибут валюты. Затем мы сортируем данные по столбцу страны, объединяем данные из таблиц покупок и валют и суммируем средние значения по странам.
Это преобразование данных приводит к новой таблице со средней суммой по стране:
СРЕДНЯЯ СУММА ПО СТРАНЕ
страна
сумма
Преобразование данных ELT во время выполнения запроса
В отличие от ETL, в ELT все данные уже загружены и могут использоваться в любой момент времени.
Следовательно, преобразование выполняется во время выполнения запроса:
В запросе мы выбираем IP-адрес по стране, умножая сумму из таблицы покупок на курс из таблицы валют, чтобы вычислить среднюю сумму. Затем объединение обеих таблиц на основе общих столбцов обеих таблиц и группировка по странам.
Это приведет к той же самой выходной таблице, что и в описанном выше процессе ETL. Однако в этом случае, поскольку все необработанные данные уже загружены, нам будет проще продолжить выполнение других запросов в той же среде для тестирования и определения лучших возможных преобразований данных, соответствующих бизнес-требованиям.
Итог этого практического примера
В разработке кода ELT более эффективен, чем ETL. Кроме того, ELT более гибок, чем ETL. С помощью ELT пользователи могут запускать новые преобразования, тестировать и улучшать запросы непосредственно на необработанных данных по мере необходимости – без лишних времени и сложности, к которым мы привыкли с ETL.
Управление хранилищами данных и озерами данных
Согласно Gartner, потребности компаний в управлении данными и интеграции данных сегодня требуют как малых, так и больших, неструктурированных и структурированных объемов данных. Вот что они предлагают изменить в способе работы:
«Традиционная команда бизнес-аналитики должна продолжать разрабатывать четкие передовые практики с хорошо понятными бизнес-целями… существует второй режим бизнес-аналитики, который является более гибким и. очень итеративным, с непредвиденным обнаружением данных, допускающим быстрый сбой».
Такие мысли вызвали много разговоров о хранилищах и озерах данных. Концепция озера данных – это новый взгляд на большие объемы неструктурированных данных, предназначенный для бесконечного масштабирования с использованием таких инструментов, как Hadoop, для реализации второго режима работы бизнес-аналитики, описанного Gartner. Хотя компании по-прежнему используют хранилища данных для поддержки традиционной парадигмы, такой как ETL, масштабируемые современные хранилища данных, такие как Redshift и BigQuery, могут использоваться для реализации современной парадигмы ELT со всеми присущими ей преимуществами, упомянутыми выше.
IBM рассказывает о 5 вещах, которые требуются для современных проектов на основе больших данных, о необходимости новых концепций данных, таких как озеро данных. Это «5 V»:
ETL по-прежнему хорошо подходит для работы с устаревшими хранилищами данных, при рассмотрении более мелких подмножеств и их перемещении в хранилище данных. Но трудно предоставить решение с ETL для «5 V», когда вы идете вниз по списку – как работать с объемами? Неструктурированными данными? Скорость? и т.п.
Подход ELT открывает возможности для работы в более гибкой итеративной среде бизнес-аналитики благодаря своей эффективности и гибкости. ELT позволяет реализовать множество концепций хранилищ данных и распространяется на концепции озера данных, что позволяет включать неструктурированные данные в свое решение бизнес-аналитики.
Подводя итоги: 10 плюсов и минусов ETL и ELT
Обобщая эти два подхода, мы сгруппировали различия по 10 критериям:
1. Время – Загрузка
ETL: использует промежуточную область и систему, дополнительное время для загрузки данных
ELT: все в одной системе, загрузка только один раз
2. Время – Преобразование
ETL: нужно подождать, особенно для больших объемов данных – по мере роста данных время преобразования увеличивается
ELT: все в одной системе, скорость не зависит от размера данных
3. Время – Обслуживание
ETL: высокий уровень обслуживания – выбор данных для загрузки и преобразования; необходимо сделать все снова, если данные удалены или вы хотите улучшить основное хранилище данных.
ELT: низкие эксплуатационные расходы – все данные всегда доступны
4. Сложность реализации
ETL: на ранней стадии требует меньше места, и результат будет чистый
ELT: требует глубоких знаний инструментов и экспертного проектирования основного большого хранилища.
5. Анализ и стиль обработки
ETL: основан на нескольких сценариях для создания представлений – удаление представления означает удаление данных
ELT: создание специальных представлений – низкие затраты на создание и обслуживание
6. Ограничение данных или ограничение на поставку
ETL: предполагая и выбирая данные априори
ELT: По HW (нет) и политике хранения данных
7. Поддержка хранилищ данных
ETL: преобладающая устаревшая модель, используемая для локальных и реляционных структурированных данных.
ELT: адаптировано для использования в масштабируемой облачной инфраструктуре для поддержки структурированных и неструктурированных источников больших данных.
8. Поддержка озера данных
ETL: не является частью подхода
ELT: позволяет использовать озеро с поддержкой неструктурированных данных
9. Удобство использования
ETL: фиксированные таблицы, фиксированная временная шкала, используется в основном ИТ
ELT: ситуативность, гибкость, доступность для всех, от разработчика до гражданского интегратора
10. Рентабельность
ETL: нерентабельно для малого и среднего бизнеса
ELT: масштабируемость и доступность для бизнеса любого размера с использованием онлайн-решений SaaS
Заключительные мысли об ETL и ELT
ETL устарел. Он помог справиться с ограничениями традиционных жестких инфраструктур центров обработки данных, но сегодня это больше не является проблемой. В организациях с большими наборами данных, в масштабе нескольких терабайт, время загрузки может занять часы, в зависимости от сложности правил преобразования.
ELT – важная часть будущего хранилищ данных. С ELT компании любого размера могут извлечь выгоду из современных технологий. Анализируя большие пулы данных с большей гибкостью и меньшими затратами на обслуживание, компании получают ключевые идеи для создания реальных конкурентных преимуществ в своем бизнесе.
Архитектура хранилищ данных: традиционная и облачная
Привет, Хабр! На тему архитектуры хранилищ данных написано немало, но так лаконично и емко как в статье, на которую я случайно натолкнулся, еще не встречал.
Предлагаю и вам познакомиться с данной статьей в моем переводе. Комментарии и дополнения только приветствуются!
Введение
Итак, архитектура хранилищ данных меняется. В этой статье рассмотрим сравнение традиционных корпоративных хранилищ данных и облачных решений с более низкой первоначальной стоимостью, улучшенной масштабируемостью и производительностью.
Хранилище данных – это система, в которой собраны данные из различных источников внутри компании и эти данные используются для поддержки принятия управленческих решений.
Компании все чаще переходят на облачные хранилища данных вместо традиционных локальных систем. Облачные хранилища данных имеют ряд отличий от традиционных хранилищ:
Традиционная архитектура хранилища данных
Следующие концепции освещают некоторые из устоявшихся идей и принципов проектирования, используемых для создания традиционных хранилищ данных.
Трехуровневая архитектура
Довольно часто традиционная архитектура хранилища данных имеет трехуровневую структуру, состоящую из следующих уровней:
Kimball vs. Inmon
Два пионера хранилищ данных: Билл Инмон и Ральф Кимбалл предлагают разные подходы к проектированию.
Подход Ральфа Кимбалла основывается на важности витрин данных, которые являются хранилищами данных, принадлежащих конкретным направлениям бизнеса. Хранилище данных — это просто сочетание различных витрин данных, которые облегчают отчетность и анализ. Проект хранилища данных по принципу Кимбалла использует подход «снизу вверх».
Подход Билла Инмона основывается на том, что хранилище данных является централизованным хранилищем всех корпоративных данных. При таком подходе организация сначала создает нормализованную модель хранилища данных. Затем создаются витрины размерных данных на основе модели хранилища. Это известно как нисходящий подход к хранилищу данных.
Модели хранилищ данных
В традиционной архитектуре существует три общих модели хранилищ данных: виртуальное хранилище, витрина данных и корпоративное хранилище данных:
Звезда vs. Снежинка
Схемы «звезда» и «снежинка» — это два способа структурировать хранилище данных.
Схема типа «звезда» имеет централизованное хранилище данных, которое хранится в таблице фактов. Схема разбивает таблицу фактов на ряд денормализованных таблиц измерений. Таблица фактов содержит агрегированные данные, которые будут использоваться для составления отчетов, а таблица измерений описывает хранимые данные.
Денормализованные проекты менее сложны, потому что данные сгруппированы. Таблица фактов использует только одну ссылку для присоединения к каждой таблице измерений. Более простая конструкция звездообразной схемы значительно упрощает написание сложных запросов.
Схема типа «снежинка» отличается тем, что использует нормализованные данные. Нормализация означает эффективную организацию данных так, чтобы все зависимости данных были определены, и каждая таблица содержала минимум избыточности. Таким образом, отдельные таблицы измерений разветвляются на отдельные таблицы измерений.
Схема «снежинки» использует меньше дискового пространства и лучше сохраняет целостность данных. Основным недостатком является сложность запросов, необходимых для доступа к данным — каждый запрос должен пройти несколько соединений таблиц, чтобы получить соответствующие данные.
ETL vs. ELT
ETL и ELT — два разных способа загрузки данных в хранилище.
ETL (Extract, Transform, Load) сначала извлекают данные из пула источников данных. Данные хранятся во временной промежуточной базе данных. Затем выполняются операции преобразования, чтобы структурировать и преобразовать данные в подходящую форму для целевой системы хранилища данных. Затем структурированные данные загружаются в хранилище и готовы к анализу.
В случае ELT (Extract, Load, Transform) данные сразу же загружаются после извлечения из исходных пулов данных. Промежуточная база данных отсутствует, что означает, что данные немедленно загружаются в единый централизованный репозиторий.
Данные преобразуются в системе хранилища данных для использования с инструментами бизнес-аналитики и аналитики.
Организационная зрелость
Структура хранилища данных организации также зависит от его текущей ситуации и потребностей.
Базовая структура позволяет конечным пользователям хранилища напрямую получать доступ к сводным данным, полученным из исходных систем, создавать отчеты и анализировать эти данные. Эта структура полезна для случаев, когда источники данных происходят из одних и тех же типов систем баз данных.
Хранилище с промежуточной областью является следующим логическим шагом в организации с разнородными источниками данных с множеством различных типов и форматов данных. Промежуточная область преобразует данные в обобщенный структурированный формат, который проще запрашивать с помощью инструментов анализа и отчетности.
Одной из разновидностей промежуточной структуры является добавление витрин данных в хранилище данных. В витринах данных хранятся сводные данные по конкретной сфере деятельности, что делает эти данные легко доступными для конкретных форм анализа.
Например, добавление витрин данных может позволить финансовому аналитику легче выполнять подробные запросы к данным о продажах, прогнозировать поведение клиентов. Витрины данных облегчают анализ, адаптируя данные специально для удовлетворения потребностей конечного пользователя.
Новые архитектуры хранилищ данных
В последние годы хранилища данных переходят в облако. Новые облачные хранилища данных не придерживаются традиционной архитектуры и каждое из них предлагает свою уникальную архитектуру.
В этом разделе кратко описываются архитектуры, используемые двумя наиболее популярными облачными хранилищами: Amazon Redshift и Google BigQuery.
Amazon Redshift
Amazon Redshift — это облачное представление традиционного хранилища данных.
Redshift требует, чтобы вычислительные ресурсы были подготовлены и настроены в виде кластеров, которые содержат набор из одного или нескольких узлов. Каждый узел имеет свой собственный процессор, память и оперативную память. Leader Node компилирует запросы и передает их вычислительным узлам, которые выполняют запросы.
На каждом узле данные хранятся в блоках, называемых срезами. Redshift использует колоночное хранение, то есть каждый блок данных содержит значения из одного столбца в нескольких строках, а не из одной строки со значениями из нескольких столбцов.
Redshift использует архитектуру MPP (Massively Parallel Processing), разбивая большие наборы данных на куски, которые назначаются слайсам в каждом узле. Запросы выполняются быстрее, потому что вычислительные узлы обрабатывают запросы в каждом слайсе одновременно. Узел Leader Node объединяет результаты и возвращает их клиентскому приложению.
Клиентские приложения, такие как BI и аналитические инструменты, могут напрямую подключаться к Redshift с использованием драйверов PostgreSQL JDBC и ODBC с открытым исходным кодом. Таким образом, аналитики могут выполнять свои задачи непосредственно на данных Redshift.
Redshift может загружать только структурированные данные. Можно загружать данные в Redshift с использованием предварительно интегрированных систем, включая Amazon S3 и DynamoDB, путем передачи данных с любого локального хоста с подключением SSH или путем интеграции других источников данных с помощью API Redshift.
Google BigQuery
Архитектура BigQuery не требует сервера, а это означает, что Google динамически управляет распределением ресурсов компьютера. Поэтому все решения по управлению ресурсами скрыты от пользователя.
BigQuery позволяет клиентам загружать данные из Google Cloud Storage и других читаемых источников данных. Альтернативным вариантом является потоковая передача данных, что позволяет разработчикам добавлять данные в хранилище данных в режиме реального времени, строка за строкой, когда они становятся доступными.
BigQuery использует механизм выполнения запросов под названием Dremel, который может сканировать миллиарды строк данных всего за несколько секунд. Dremel использует массивно параллельные запросы для сканирования данных в базовой системе управления файлами Colossus. Colossus распределяет файлы на куски по 64 мегабайта среди множества вычислительных ресурсов, называемых узлами, которые сгруппированы в кластеры.
Dremel использует колоночную структуру данных, аналогичную Redshift. Древовидная архитектура отправляет запросы тысячам машин за считанные секунды.
Для выполнения запросов к данным используются простые команды SQL.
Panoply
Panoply обеспечивает комплексное управление данными как услуга. Его уникальная самооптимизирующаяся архитектура использует машинное обучение и обработку естественного языка (NLP) для моделирования и рационализации передачи данных от источника к анализу, сокращая время от данных до значения как можно ближе к нулю.
Интеллектуальная инфраструктура данных Panoply включает в себя следующие функции:
По ту сторону облачных хранилищ данных
Облачные хранилища данных — это большой шаг вперед по сравнению с традиционными подходами к архитектуре. Однако пользователи по-прежнему сталкиваются с рядом проблем при их настройке:
ETL и ELT: 5 основных отличий
Пять важнейших отличий ETL от ELT:
Разницу между ETL и ELT можно объяснить довольно легко, но для понимания общей картины, и потенциальных преимуществ ETL по сравнению с ELT, требуется более глубокое понимание того, как ETL работает с хранилищами данных и как ELT работает с озерами данных.
Обзор ETL и ELT
ETL и ELT необходимы в анализе о данных, потому что источники информации, независимо от того, используют ли они структурированную базу данных SQL или неструктурированную базу данных NoSQL, редко используют одинаковые или совместимые форматы. Следовательно, вам необходимо очистить, обогатить и преобразовать свои источники данных, прежде чем объединить их в анализируемое целое. Таким образом, ваша платформа бизнес-аналитики сможет анализировать данные для получения аналитических сведений.
Независимо от того, используете ли вы ETL или ELT, процесс преобразования/интеграции данных включает следующие три этапа:
Как мы уже установили, ETL и ELT выполняют те же операции, но в разном порядке. Возникает вопрос: следует ли преобразовывать данные до или после загрузки в хранилище? Чтобы ответить на этот вопрос, вам нужно понимать ETL и ELT.
Подробно о процессе ETL
Хранилища данных для онлайн-аналитической обработки (OLAP), облачные или локальные, должны работать с реляционными структурами данных на основе SQL. Следовательно, любые данные, которые вы загружаете в хранилище данных OLAP, должны преобразоваться в реляционный формат, прежде чем хранилище данных сможет их принять. В рамках этого процесса преобразования данных также может потребоваться сопоставление данных для объединения нескольких их источников на основе коррелирующей информации (чтобы ваша платформа бизнес-аналитики могла анализировать информацию как единое интегрированное устройство).
Вот почему хранилища данных требуют ETL. Потому что преобразования должны происходить до загрузки. Вот некоторые подробности, которые нужно понять об ETL:
Важнейшие преимущества ETL
Одно из крупнейших преимуществ ETL перед ELT связано с преструктурированной природой хранилища данных OLAP. После структурирования/преобразования данных ETL позволяет проводить ускоренный, более эффективный и стабильный анализ данных. А вот ELT не так идеален, когда задача требует быстрого анализа.
Еще одно существенное преимущество ETL перед ELT связано с соответствием. Часто компаниям, работа которых регулируется GDPR, HIPAA или CCPA, необходимо удалить, замаскировать или зашифровать определенные поля данных для защиты конфиденциальности своих клиентов. Сюда может входить преобразование электронных писем только в домен или удаление последней части IP-адреса. ETL обеспечивает более безопасный способ выполнения этих преобразований, поскольку он преобразует данные перед их помещением в хранилище данных.
А вот ELT требует, чтобы вы сначала загрузили конфиденциальные данные. Это приводит к тому, что эти данные будут отображаться в журналах, где системные администраторы могут получить к ним доступ. Кроме того, использование ELT для преобразования данных может непреднамеренно нарушить стандарты соответствия GDPR ЕС, если при загрузке в озеро данных, некоторые из них покидают территорию ЕС. В конечном итоге ETL снижает риск нарушения нормативных требований, поскольку несоответствующие данные никогда случайно не попадут в хранилище данных или отчеты за пределами ЕС.
Ну и наконец, ETL, как процесс интеграции/преобразования данных существует уже более двух десятилетий, а это означает, что есть множество проверенных временем инструментов и платформ ETL, которые помогут в извлечении, преобразовании и загрузке данных. Кроме того, вы сможете легко найти инженеров по обработке данных, обладающих навыками и опытом настройки конвейеров ETL.
Подробное описание процесса ELT
Что такое ELT?
ELT означает «Извлечь, загрузить и преобразовать». В этом процессе данные для основных преобразований используются через хранилище данных. Это означает, что нет необходимости в промежуточном размещении данных. Для всех типов данных, включая структурированные, неструктурированные, полуструктурированные и даже необработанные данные ELT использует облачные решения для их хранения.
Процесс ELT также работает рука об руку с озерами данных. «Озера данных» – это особые виды хранилищ данных, которые, в отличие от хранилищ OLAP, принимают любые структурированные или неструктурированные данные. Озера данных не требуют преобразования данных перед их загрузкой. Вы можете сразу загрузить в озеро данных любой тип необработанной информации, независимо от формата или его отсутствия.
Перед анализом данных с помощью платформы бизнес-аналитики все еще необходимо преобразование данных. Однако очистка, обогащение и преобразование данных происходят после загрузки данных в озеро данных. Вот некоторые подробности о работе ELT и озерах данных для общего понимания процесса:
Самые значительные преимущества ELT
Основное преимущество ELT перед ETL связано с гибкостью и простотой хранения новых неструктурированных данных. С помощью ELT вы можете хранить любой тип информации, даже если у вас нет времени или возможности сначала преобразовать и структурировать ее, обеспечивая немедленный доступ ко всей вашей информации, когда вы этого захотите. Кроме того, вам не нужно разрабатывать сложные процессы ETL перед загрузкой данных, что экономит время разработчиков и аналитиков данных при работе с новой информацией.
Вот еще несколько преимуществ ELT:
ПРЕИМУЩЕСТВО №1: Высокая скорость
Когда дело доходит до доступности данных, ELT – более быстрый вариант. ELT позволяет всем данным немедленно поступать в систему, и оттуда пользователи могут определять точные данные, которые им необходимы для преобразования и анализа.
ПРЕИМУЩЕСТВО №2: низкие эксплуатационные расходы
С ELT пользователям, как правило, не нужно иметь план обслуживания с высокой степенью сложности. Поскольку ELT является облачным, он использует автоматизированные решения вместо того, чтобы полагаться на пользователя, инициирующего обновления вручную.
ПРЕИМУЩЕСТВО №3: Более быстрая загрузка
Поскольку этап преобразования не происходит до тех пор, пока данные не поступят в хранилище, это сокращает время, необходимое для загрузки данных в их финальное место хранения. Нет необходимости ждать, пока данные очистятся или иным образом будут изменены, и им нужно только один раз войти в целевую систему.
Лучшие способы использования ELT
Как указано в этой статье, обсуждение преимуществ ETL и ELT все еще продолжается. Итак, при каких обстоятельствах вы могли бы рассмотреть возможность использования ELT вместо ETL? Вот некоторые из возможных случаев:
СЛУЧАЙ ИСПОЛЬЗОВАНИЯ №1:
Компания с огромным объемом данных. ELT лучше всего работает с огромными объемами данных, как структурированных, так и неструктурированных. Если целевая система – облачная, вы, вероятно, сможете быстрее обрабатывать эти огромные объемы данных с помощью решений ELT.
СЛУЧАЙ ИСПОЛЬЗОВАНИЯ №2:
Организация, располагающая ресурсами для необходимой вычислительной мощности. При использовании ETL большая часть обработки происходит на этапе, пока данные еще находятся в конвейере, до того, как они попали в ваше хранилище. ELT выполняет действие после того, как данные поступили в озеро данных. В зависимости от того, что нужно сделать с данными согласно вашим целям, у небольших компаний может не быть достаточной финансовой гибкости для разработки или изучения обширных технологий, необходимых для получения всех преимуществ озера данных.
СЛУЧАЙ ИСПОЛЬЗОВАНИЯ №3:
Компания, которой нужны все данные в одном месте как можно скорее. Когда преобразования происходят в конце процесса, ELT отдает приоритет скорости передачи почти всему остальному, а это означает, что все данные, хорошие, плохие и другие, попадают в озеро данных для последующего преобразования.
Сравнение ETL и ELT
Внедрение технологии и наличие инструментов и экспертов
ETL – это хорошо отлаженный процесс, который используется более 20 лет, и эксперты по ETL всегда под рукой.
ELT – это новая технология, поэтому может быть сложно найти экспертов, и разработать конвейер ELT тоже сложнее, по сравнению с конвейером ETL.
Доступность данных в системе
ETL преобразует и загружает только те данные, которые (по вашему мнению) будут необходимы при создании хранилища данных и процесса ETL. Следовательно, будет доступна только эта информация.
ELT может сразу загрузить все данные, а пользователи смогут позже определить, какие данные из них преобразовать и проанализировать.
Можно ли добавить вычисления?
Вычисления либо заменят существующие столбцы, либо вы можете добавить набор данных, чтобы передать результат вычислений в целевую систему данных.
ELT добавляет вычисляемые столбцы непосредственно в существующий набор данных.
Совместимы ли данные с озерами данных?
ETL не является популярным решением для озер данных. Оно преобразует данные для интеграции с системой структурированного реляционного хранилища данных.
ELT предлагает конвейер для озер данных для приема неструктурированных данных. Затем он по мере необходимости преобразует данные для анализа.
ETL может редактировать и удалять конфиденциальную информацию, прежде чем помещать ее в хранилище данных или облачный сервер. Это упрощает соблюдение стандартов GDPR, HIPAA и CCPA. Это также защищает данные от взлома и непреднамеренного воздействия.
ELT требует, чтобы вы загрузили данные перед редактированием/удалением конфиденциальной информации. Это может нарушить стандарты GDPR, HIPAA и CCPA. Конфиденциальная информация будет более уязвима для взлома и непреднамеренного раскрытия. Вы также можете нарушить некоторые стандарты соответствия, если облачный сервер находится в другой стране.
Размер данных и сложность преобразований
ETL лучше всего подходит для работы с небольшими наборами данных, требующими сложных преобразований.
ELT лучше всего подходит для работы с огромными объемами структурированных и неструктурированных данных.
Поддержка хранилищ данных
ETL работает с облачными и локальными хранилищами данных. Оно требует реляционного или структурированного формата данных.
ELT работает с облачными хранилищами данных для поддержки структурированных, неструктурированных, полуструктурированных и необработанных типов данных.
Требования к оборудованию
Облачные ETL-платформы не требуют специального оборудования.
Наследованные локальные процессы ETL требуют обширных и дорогостоящих решений по оборудованию, но сегодня они не так популярны.
Процессы ELT основаны на облаке и не требуют специального оборудования.
Чем отличаются агрегаты?
Агрегация усложняется по мере увеличения размера набора данных.
Если у вас есть мощная облачная целевая система данных, вы можете быстро обрабатывать огромные объемы данных.
При создании конвейера ETL легко найти экспертов по ETL. Для облегчения этого процесса доступны высокоразвитые инструменты ETL.
Как новая технология, инструменты для реализации решения ELT все еще развиваются. Более того, бывает сложно найти экспертов с необходимыми знаниями и навыками ELT.
Требования к обслуживанию
Автоматизированные облачные решения ETL, не требуют значительного обслуживания. Однако локальное решение ETL, использующее физический сервер, потребует частого обслуживания.
ELT основан на облаке и, как правило, включает автоматизированные решения, поэтому требуется очень немного обслуживания.
Порядок извлечения, преобразования, загрузки
Преобразование данных происходит сразу после извлечения в промежуточной области. После преобразования данные загружаются в хранилище данных.
Данные извлекаются, а затем загружаются в целевую систему данных. Только после этого некоторые данные преобразуются «по мере необходимости» для аналитических целей.
Облачные платформы SaaS ETL, которые выставляют счет по модели ценообразования с оплатой за сеанс, они предлагают гибкие планы, которые начинаются примерно от 100 долларов и затем увеличиваются в зависимости от требований использования. Между тем, локальное ETL-решение на уровне компании, такое как Informatica, может обойтись даже в 1 миллион долларов в год!
Платформы SaaS ELT на основе облачных вычислений, которые выставляют счет по модели ценообразования с оплатой за сеанс, предлагают гибкие планы, которые начинаются примерно с 100 долларов США, а затем постепенно растут. Ценовое преимущество ELT заключается в том, что вы можете загружать и сохранять свои данные без больших комиссий, а затем преобразовывать их по мере необходимости. Это может сэкономить вам деньги на первоначальных затратах, если вы просто хотите загрузить и сохранить информацию. Однако финансово ограниченные компании могут никогда не позволить себе вычислительную мощность, необходимую для получения всех преимуществ своего озера данных.
Преобразования происходят в промежуточной области за пределами хранилища данных.
Преобразования происходят внутри самой системы данных, и промежуточной области не требуется.
Поддержка неструктурированных данных
ETL можно использовать для структурирования неструктурированных данных, но нельзя использовать для передачи неструктурированных данных в целевую систему.
ELT – это решение для загрузки неструктурированных данных в озеро данных и предоставления неструктурированных данных системам бизнес-аналитики.
Время ожидания для загрузки информации
Время загрузки ETL превышает ELT, потому что это многоступенчатый процесс: (1) загрузка данных в промежуточную область, (2) преобразования, (3) загрузка данных в хранилище данных. После загрузки данных анализ информации происходит быстрее, чем у ELT.
Загрузка данных происходит быстрее, потому что нет ожидания преобразований, и данные загружаются в целевую систему данных только один раз. Однако анализ информации происходит медленнее, чем ETL.
Время ожидания для выполнения преобразований
Преобразование данных изначально занимает больше времени, потому что каждый фрагмент данных перед загрузкой требует преобразования. Кроме того, по мере увеличения размера системы данных преобразования занимают больше времени. Однако после преобразования в систему анализ выполняется быстро и эффективно.
Поскольку преобразования происходят после загрузки по мере необходимости, а вы преобразовываете только данные, которые нужно анализировать в данный момент, преобразования происходят намного быстрее. Однако необходимость постоянного преобразования данных снижает общее время, необходимое для запросов/анализа.