Комментарии 17
2. Почему на графике airflow у вас находиться в сложных enterprise решениях, а tableau наоборот? И почему pentaho у вас в free/opensource, когда там уже очень много всего закрытого и поприетарного?
- Идея в том, что аналитик без особого опыта в Python сразу на AirFlow писать не может, а на ViXtract — может. И в этом ему как раз помогают уже встроенные рекомендованные библиотеки. При этом никто не запрещает использовать pandas и что угодно еще, по мере развития компетенций. Что касается разработчика промышленного ETL — ему, конечно все это не нужно, ему лучше сразу писать на AirFlow. Ну и это все — идея/гипотеза, в которую мы верим, и которая пока на тестированиях подтверждается. Выстрелит ли это — рассудит сообщество.
- Этот график, конечно, субъективен, расскажу свою логику. Tableau Prep находится посередине между простыми и enterprise решениями, потому что я никогда не видел и не слышал, чтобы на нем делали тяжелые преобразования в Data Lake / DWH, которые могут даже быть никак не связаны с BI. А для Airflow — это вообще основной кейс применения, он для этого был сделан в Airbnb. Pentaho, безусловно, очень сильно коммерциализировался, но в контексте рассматриваемой задачи базовый инструмент (который особо сильно не изменился со время Kettle), по-моему, остается бесплатным — поправьте, если ошибаюсь.
Он никому ничего не должен, конечно. Просто я видел в своей практике множество случаев, когда аналитик мог решить задачу загрузки данных в 5 строчек за час времени, а вместо этого он ставил задачу ETL разработчику и начиналось: разработчик что-то сделал, аналитик увидел, что на самом деле нужно немного по-другому, разработчик снова ушел делать, в это время задача от бизнеса немного поменялась и т.д. и т.п. В итоге задача растянулась на пять дней. Наверное, это не панацея для всех задач, но на начальных этапах проекта или в исследовательских задачах точно востребовано.
Да, дублирование возникает, это минус предложенного решения. Вопрос, что в конкретном проекте более значительно — дополнительные затраты на сопровождение или потери на коммуникациях между аналитиками и разработчиками. Кроме того, есть гипотеза, что во многих проектах (не во всех, конечно) можно обойтись и чисто ViXtract. Тот же Cronicle поддерживает и работу в кластере, и может обеспечивать очень хорошие параметры по надежности. Понятно, что ключевая проблема в том, что сборка не имеет коммерческой поддержки, но, если будет серьезный интерес со стороны корпораций, это можно и исправить.
А в JupyterHub, а не в PyCharm, например, потому что:
- Интерактивно работать с кодом и постоянно его исправлять в Jupyter проще, чем работать с отладчиком (для не очень опытного человека в разработке)
- Поскольку код сразу запускается на сервере, нет вечных проблем в различии окружений на сервере и локальном компьютере (библиотеки, пути, сетевая доступность, права)
- Имея знания в 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
Это называется «каминг-аут».
Автор хорошая работа, но у вас конкуренция высокая и пока что Airflow выглядит как лидер в питоновское среде для etl.
Можно вопрос, а как обстоят дела с трансформациями данных которве не помещаются в оперативку? может ли ваше решение трансформировать сотню Гб с одного источника(постгрес) и сделать джойн с другим источгиком(мускул) размером в пару Гб?
и как быстро льются данные? можно ли лить в несколько потоков в партиционированные таблицы?
В базовой "комплектации" такие задачи сделать не получится, конечно. PETL был выбран как инструмент с минимальным порогом входа, а по производительности он уступает даже pandas (который при этом тоже грузит все данные в память). Так что для описанных задач уже нужно выбирать другие инструменты, хотя в качестве интерфейса/планировщика можно и оставить Jupyter, Python и Cronicle.
С Airflow не хотелось бы конкурировать, мы старались разделить позиционирование — Airflow для тяжелых продуктивных задач и опытных ETL разработчиков, ViXtract для простых и средних задач, пилотирования (PoC) и изучения данных аналитиками.
Бесплатный удобный ETL инструмент с открытым кодом на основе Python — фантастика или нет?