powered by simpleCommunicator - 2.0.44     © 2025 Programmizd 02
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / ETL vs ELT
4 сообщений из 4, страница 1 из 1
ETL vs ELT
    #40068413
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Заявленная выше тема велика и необъятна, а потому хотел бы начать, поделившись своим впечатлением от The Essential Guide to Data Integration - How to thrive in an age of infinite data . Прежде всего я отметил, что автор четко отделяет analysts от data engineers . Казалось бы, все так и есть - но оказывается, что первые программируют трансформации на SQL для ELT. Таким образом, analysts в переводе на великий и могучий оказываются вовсе не аналитиками, а программистами SQL. Автор считает подход ETL устаревшим и указывает на его недостатки (в моем кратком изложении)
  • Создание процесса ETL сложно, изменения исходной или целевой модели данных ломают процесс ETL, делая данные недоступными для программистов SQL.
  • Из-за не-SQL программирования ETL усложнен, чувствителен к изменениям, требует выделенных инженеров данных и отдельной инфраструктуры.
и приводит следующие преимущества ELT (опять же, в моем кратком изложении) :
  • Дата инженеры программируют только упрощенный процесс Extract-Load (инициализирующий или инкрементальный Copy-Paste из источников в ХД), хорошо поддающийся автоматизации
  • Программисты SQL программируют трансформации и решают большинство проблем с данными без помощи дата инженеров; такие проблемы не ломают процесс получения данных из источников.
Сравнительно высокое потребление ресурсов процессами ELT автор призывает решать посредством облаков; единственную заслуживающую упоминания проблему он видит на вводе больших объемов данных в облако и выводе их оттуда. Со своей стороны, находя немало здравых мыслей у автора, я все же не могу согласиться с предлагаемыми им решениями (полностью осознавая, что тем самым отхожу от мейнстрима современных ХД) , по следующим причинам:
    Исполнение большинства трансформаций на SQL неустранимо медленнее по сравнению с ЯВУ типа джавы или C#, на которых основано большинство средств ETL. Процесс ELT сначала сохраняет данные в БД, а затем считывает их для этапа трансформаций. Это заведомо менее эффективно, чем прямая (потоковая) передача данных, которую SQL не поддерживает. Данную проблему давно решают посредством всяких ODS и лямбда-архитектур, которые в разы повышают сложность ХД. SQL не шардируется, а имитация SQL посредством хадуп-экосистемы (Hive, Spark) повышает сложность ХД на порядки.
    Сохранение данных источников возле ХД Стандартизация загрузки и маппинга данных в целевую модель ХД
...
Рейтинг: 0 / 0
ETL vs ELT
    #40068529
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторSQL не шардируется
ты бы почитал про редшифт или сноуфлейк для начала.
Или хотябы как в спарк уже переписывают медленное ява легаси на спаркsql
https://habr.com/ru/company/otus/blog/529684/

Остальной бред что у тебя написан коментировать даже лень.

Единственный минус голого sql - нету lineage, который у многих ETL тулов существует.
По производительности ETL уже давно мертв
...
Рейтинг: 0 / 0
ETL vs ELT
    #40068609
Бумбараш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan Durak
авторSQL не шардируется



Единственный минус голого sql - нету lineage, который у многих ETL тулов существует.
По производительности ETL уже давно мертв
В целом всё так. Уже давно тут на форуме ETL/ELT обсуждался и я тоже писал длиннопосты на эту тему.
Последние ETL хоронилища помню в 2009 году. После уже одни ELT.

Просто видимо есть какая-то область средне-малых эмэссикуэль хоронилищ, в которых работают некоторые участники и там до сих пор активно применяется ETL. И видимо мир этих легаси-хранилищ несколько отделен от реальности.
...
Рейтинг: 0 / 0
ETL vs ELT
    #40069977
Фотография a_voronin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
.Евгений
  • Процесс ELT сначала сохраняет данные в БД, а затем считывает их для этапа трансформаций. Это заведомо менее эффективно, чем прямая (потоковая) передача данных, которую SQL не поддерживает. Данную проблему давно решают посредством всяких ODS и лямбда-архитектур, которые в разы повышают сложность ХД.

  • ELT применяется в совокупности с якорной моделью, где запись на диск минимизирована и оптимальна. Меняется только то, что поменялось и используется только вставка.

    Я поработал 7 месяцев на кластере Гринплама 24 ноды. Так вот пересоздать всю партицию занимает не так много времени, по сравнению с обновлением строк. При 0.3% процента изменений строк в партиции ее уже быстрее полностью пересоздать. Это партиционированный колумстор с настройками сжатия колонок. На вертики ситуация похожа.

    В общем ELT это для массово-параллельных архитектур.
    ...
    Рейтинг: 0 / 0
    4 сообщений из 4, страница 1 из 1
    Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / ETL vs ELT
    Целевая тема:
    Создать новую тему:
    Автор:
    Закрыть
    Цитировать
    Найденые пользователи ...
    Разблокировать пользователей ...
    Читали форум (0):
    Пользователи онлайн (0):
    x
    x
    Закрыть


    Просмотр
    0 / 0
    Close
    Debug Console [Select Text]