Pull to refresh

Comments 11

Почему нельзя было использовать один из стандартных движков? Из описания выглядит как наколеночная поделка ради поделки. Про текстовые параметры подключения которые куда то вводятся и сохраняются... Если я правильно понял о чем это, так же просто нельзя делать...

Моя практика показывает, что все существующие движки клика далеки от совершенства

"один из стандартных движков "

А можно пример?
Мне в голову кроме Informatica и dbt больше ничего не приходит.

Ух ты). Опять помесь гпт с бредом студента для набора текста для реферата. Как настроить хабр, чтобы уведомления о новых "статьях" этого автора не приходили?

Ну раз вы так активно пишите гневные комментарии, хотя бы тут, попробуйте свою позицию хоть чуть-чуть аргументировать

А вы как автор статьи отрицаете, что она сгенерирована нейронкой?

И независимо от этого вопроса, хотелось бы понять ваши мотивы публикации такого материала. Напоминает "тени на стене пещеры" Платона, описание кода без самого кода...

давайте по аргументам:

  1. Оформление – посмотрите, как оформляют статьи. Это огромный труд. Нельзя писать абзац на 100500 строк, в котором всё смешано и люди, и кони.,

  1. Код – пишите про «движок», а код то где? Ни примеров в статье, ни ссылки на гитхаб.

  1. Движок – исходя из текста Вы используете Jupyter Notebook и поверх виджеты ipywidgets для ввода параметров, чтобы в коде не писать их (хз что мешает пользователям заполнить эти параметры в коде, учитывая то, что они и так открывают ноутбук), а потом отправляете этот единственный даг в Airflow, то есть используете огромный ETL оркестратор потоков в роли планировщика для запуска одного дага :) даже не знаю как комментировать такой «движок»-генератор дага. Получается Вы забиваете гвоздь микроскопом :) чем например крон хуже в роли планировщика?

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

 

Резюме: статья написана не о etl-движке, а о какой-то форме генератора дага для запуска в airflow по расписанию. А может всё неправильно понял, так как без примеров кода не понятно, о чем вообще Вы пишите.

а где сам движок, описание классов, хотя бы ссылка на гитхаб?

сделать import hive, clickhouse_connect, pd.read_sql(), insert_dataframe() можно без всего вышеперечисленного, нужен только py-файл и cron

pd.read_sql(), insert_dataframe() тоже с большой долей вероятности не нужны. большую часть трансформаций всеже можно внутри бд сделать.

Hive это не бд, это движок позволяющий работать со структурированными файлами как с таблицами - писать к ним sql-запросы

Т.е. сама суть статьи это как взять файл и записать его в CH (а не как подключить файл внутри CH в качестве источника)

Любопытно было бы вгзлянуть на реализацию, не думали выложить код в githib/gitverse ?

Sign up to leave a comment.

Articles