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

А чем тогда пользуетесь? Вы меня сейчас просто в тупик поставили, я все делаю неправильно. :) Проблематику Вы описали совершенно правильно, но какие альтернативы? Сразу писать мегапакеты на жабе?

Господа, а кстате. А за что вы так ETL-тулзы не любите?

Конкретно этот ETL написан на SQL, выполнение которого занимает до 29 часов. То же самое на Python выполняется за 20 минут.

Конкретно этот ETL написан на SQL, выполнение которого занимает до 29 часов. То же самое на Python выполняется за 20 минут.

Это задачка с литкода, где надо найти максимально неоптимальное решение?

Ему просто было лень переписывать код при добавлении новых полей.

жёстко

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

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

А чем тогда пользуетесь? Вы меня сейчас просто в тупик поставили, я все делаю неправильно. :) Проблематику Вы описали совершенно правильно, но какие альтернативы? Сразу писать мегапакеты на жабе?

Область data engineering это разработка и сопровождение решений которые строят даталейки, хранилища, витрины и специальные аналитические решения.. классика ETL имеет ряд родовых ограничений которые делают их нишу очень узкой, первый пример - структура данных источника фиксируется на этапе разработки и не может меняться в рантайме (то есть Avro schema evolution уже не работает)

А как без фиксации ? Есть примеры ?

Во время обратно совместимой эволюции авро схемы для сообщений в топике последующие пайплайны не должны ломаться, и должны тащить новые поля