Как стать автором
Обновить

Бесплатный удобный ETL инструмент с открытым кодом на основе Python — фантастика или нет?

Время на прочтение 13 мин
Количество просмотров 17K
Всего голосов 17: ↑16 и ↓1 +15
Комментарии 17

Комментарии 17

1. Я правильно понимаю, что вы изобрели свой airflow, который, помимо кучи технических проблем, накладывает ограничение на легкость внедрения из-за узкоспециализированных либ?
2. Почему на графике airflow у вас находиться в сложных enterprise решениях, а tableau наоборот? И почему pentaho у вас в free/opensource, когда там уже очень много всего закрытого и поприетарного?
  1. Идея в том, что аналитик без особого опыта в Python сразу на AirFlow писать не может, а на ViXtract — может. И в этом ему как раз помогают уже встроенные рекомендованные библиотеки. При этом никто не запрещает использовать pandas и что угодно еще, по мере развития компетенций. Что касается разработчика промышленного ETL — ему, конечно все это не нужно, ему лучше сразу писать на AirFlow. Ну и это все — идея/гипотеза, в которую мы верим, и которая пока на тестированиях подтверждается. Выстрелит ли это — рассудит сообщество.
  2. Этот график, конечно, субъективен, расскажу свою логику. Tableau Prep находится посередине между простыми и enterprise решениями, потому что я никогда не видел и не слышал, чтобы на нем делали тяжелые преобразования в Data Lake / DWH, которые могут даже быть никак не связаны с BI. А для Airflow — это вообще основной кейс применения, он для этого был сделан в Airbnb. Pentaho, безусловно, очень сильно коммерциализировался, но в контексте рассматриваемой задачи базовый инструмент (который особо сильно не изменился со время Kettle), по-моему, остается бесплатным — поправьте, если ошибаюсь.
Про субъективность понятно, а почему у вас аналитик должен писать etl в jpyterhub, я так и не понял?

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

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

Да, дублирование возникает, это минус предложенного решения. Вопрос, что в конкретном проекте более значительно — дополнительные затраты на сопровождение или потери на коммуникациях между аналитиками и разработчиками. Кроме того, есть гипотеза, что во многих проектах (не во всех, конечно) можно обойтись и чисто ViXtract. Тот же Cronicle поддерживает и работу в кластере, и может обеспечивать очень хорошие параметры по надежности. Понятно, что ключевая проблема в том, что сборка не имеет коммерческой поддержки, но, если будет серьезный интерес со стороны корпораций, это можно и исправить.

Понятно, спасибо за разъяснение

А в JupyterHub, а не в PyCharm, например, потому что:


  1. Интерактивно работать с кодом и постоянно его исправлять в Jupyter проще, чем работать с отладчиком (для не очень опытного человека в разработке)
  2. Поскольку код сразу запускается на сервере, нет вечных проблем в различии окружений на сервере и локальном компьютере (библиотеки, пути, сетевая доступность, права)
  3. Имея знания в Python и Jupyter, аналитику уже гораздо проще сделать шаг в сторону Data Science, а это логичный путь развития для аналитика
Ведь в сущности, мы все пользуемся плюс-минус одними и теми же системами: от 1С до SAP, Oracle, AmoCRM, Google Analytics.

Я написал за свою практику порядка 100 интеграций — т.е. тех самых ETL, и ни разу не сталкивался ни с одной из упомянутых систем (ну, плюс-минус с поправкой на то, что я не знаю, кто такой этот ваш Oracle). Что я делаю не так?

На мой взгляд, автор тут выдает свой (наверное вполне релевантный) опыт за универсальный факт. И кроме того, считает заранее, что питон это хорошо (что в общем-то вполне может быть правдой с учетом опыта разработчиков), и в итоге не рассматривает вообще некоторый класс решений типа Apache Camel (существует c 2008), Spring Integration (чуть поменьше, но тоже солидно), и другие из мира Java.

Спасибо за наводку на Java-based решения, изучим! По Python попробую еще раз объяснить логику выбора. Поскольку целевая аудитория ViXtract — это не разработчики, а именно аналитики, нужно было выбрать язык с минимальным порогом входа. Python в этом плане лидер, по крайней мере, в общественном мнении. Ну и еще у Python есть большой плюс именно для аналитиков — он является основным инструментом для Data Scientist, поэтому если аналитик решает развиваться в этом направлении (что логичнее, чем в сторону разработчика), то он может переиспользовать полученные опыт и знания.

Да не, ну это все понятно. И нормально. Я тоже про некоторые решения от вас тут прочитал. Как бы я даже не в порядке критики, а именно с целью обратить внимание на целый пласт других технологий.
я не знаю, кто такой этот ваш Oracle

Это называется «каминг-аут».
Очень смешно. Oracle — это компания. Может вы не в курсе, что они выпускают огромную кучу софта. Я лишь тонко намекнул что база данных -далеко не единственный их софт.

Автор хорошая работа, но у вас конкуренция высокая и пока что Airflow выглядит как лидер в питоновское среде для etl.


Можно вопрос, а как обстоят дела с трансформациями данных которве не помещаются в оперативку? может ли ваше решение трансформировать сотню Гб с одного источника(постгрес) и сделать джойн с другим источгиком(мускул) размером в пару Гб?
и как быстро льются данные? можно ли лить в несколько потоков в партиционированные таблицы?

В базовой "комплектации" такие задачи сделать не получится, конечно. PETL был выбран как инструмент с минимальным порогом входа, а по производительности он уступает даже pandas (который при этом тоже грузит все данные в память). Так что для описанных задач уже нужно выбирать другие инструменты, хотя в качестве интерфейса/планировщика можно и оставить Jupyter, Python и Cronicle.


С Airflow не хотелось бы конкурировать, мы старались разделить позиционирование — Airflow для тяжелых продуктивных задач и опытных ETL разработчиков, ViXtract для простых и средних задач, пилотирования (PoC) и изучения данных аналитиками.

А почему у вас нет Luigi в ETL? И почему вы смешиваете написание ETL логики (DAG действий) и непосредственную обработку данных?
Зарегистрируйтесь на Хабре , чтобы оставить комментарий