Вроде никто и не обещал полноценную OLTP-транзакционность в хранилищах S3. Если ее изобрести, то получится просто БД, дорогая и неэффективная для больших данных. Вы сами упомянули, что транзакционность того же Iceberg ограничена отдельными таблицами и она при этом эффективно реализует атомарные операции без потери согласованности. А большего и не надо.
В лейках не было ACID, а в лейкхаусах поддержка появилась, пусть и в рамках одной таблицы. Для инженеров данных уже это во благо - того уровня ACID, который есть в базах данных, тут никто не ждет.
Дагстер это оркестратор нового поколения, который позволяет вместо написания DAG строить пайплайны из ассетов. Плюс с ним проще работать, поэтому его и выбирают часто для новых проектов.
Кстати, в Airflow 3.0 тоже появились ассеты, как в дагстере, так что они сблизились.
Я думаю, нет большой разницы, с чего начать изучение, потому что для работодателя важно, чтобы человек понимал подходы и умел строить пайплайны. А особенности конкретного инструмента быстро осваиваются.
Запускать и отлаживать FastAPI локально можно безо всяких проблем. Ни докер, ни удаленные интерпретаторы не нужны. Все отлично разрабатывается даже на винде, а потом деплоится в линуксовый контейнер.
Тяжёлая конда тоже не нужна. Достаточно uv или просто pip.
Полностью переключиться с poetry на uv оказалось проще, чем просто настроить очередной проект на poetry. Такое ощущение, что этот пакетный менеджер будет жить только по инерции.
А мне надоело тащить в каждый проект монструозный dictConfig. Все оказалось намного проще и приятнее с loguru, который также интегрируется с logfire и тогда все логи с полпинка отравляются в облако.
Джуни это расширение для их AI, которое не просто даёт чат, а умеет решать задачи по ключ, создавать новые файлы и редактировать имеющиеся. Работает не быстро, потому что выполняет много рассуждений. В целом пока страшновато применять в сложных проектах, чата достаточно для таргетированных доработок.
Третий год сижу на дагстере, полет нормальный. Хоть и пришлось написать много кода, зато вся оркестрация действительно выглядит как центр управления данными, в отличие от Airflow, который все еще управляет лишь задачами...
А SQLModel пробовали? Он объединяет Sqlalchemy с Pydantic. В моих проектах на fastapi хорошо заходит, но бывают некоторые неудобства из-за абстракции поверх алхимии.
Это интересные фантазии, но на практике основная проблема вовсе не в питоне, а в нехватке управляемости и наблюдаемости пайплайнов.
Дагстер здесь принес много интересных подходов вроде использования качестве ассетов и накопления метаданных, за это его и выбирают. Это airflow и пытается у него позаимствовать в следующей версии.
Ну и ещё дагстер легко запустить локально для отладки и тестирования пайплайнов. Привет отделке в эйрфлоу путем коммитов в репозиторий.
Он из коробки работает с любимыми моделями, которые поддерживает LangChain, в том числе и с локальными.
Вроде никто и не обещал полноценную OLTP-транзакционность в хранилищах S3. Если ее изобрести, то получится просто БД, дорогая и неэффективная для больших данных.
Вы сами упомянули, что транзакционность того же Iceberg ограничена отдельными таблицами и она при этом эффективно реализует атомарные операции без потери согласованности. А большего и не надо.
В лейках не было ACID, а в лейкхаусах поддержка появилась, пусть и в рамках одной таблицы. Для инженеров данных уже это во благо - того уровня ACID, который есть в базах данных, тут никто не ждет.
Такое лучше постить 1 апреля, кто-то ведь реально может поверить в эту "аналитику" уровня Ленин-гриб.
Дагстер это оркестратор нового поколения, который позволяет вместо написания DAG строить пайплайны из ассетов. Плюс с ним проще работать, поэтому его и выбирают часто для новых проектов.
Кстати, в Airflow 3.0 тоже появились ассеты, как в дагстере, так что они сблизились.
Я думаю, нет большой разницы, с чего начать изучение, потому что для работодателя важно, чтобы человек понимал подходы и умел строить пайплайны. А особенности конкретного инструмента быстро осваиваются.
А я нигде картинку под спойлер не прятал... Это уже хабр что-то мутит. А что он спрятал?
А потом ХОБА
Да нет, конечно, где мы и где он. Похулиганили немного не в ущерб самому Линусу.
Не знаю, какие там были проблемы, но я спокойно использую alembic в проекте с sqlmodel.
Все из коробки работает на винде, WSL не нужен. Когда деплоится в linux-контейнер, работает ровно так же.
Запускать и отлаживать FastAPI локально можно безо всяких проблем. Ни докер, ни удаленные интерпретаторы не нужны. Все отлично разрабатывается даже на винде, а потом деплоится в линуксовый контейнер.
Тяжёлая конда тоже не нужна. Достаточно uv или просто pip.
Полностью переключиться с poetry на uv оказалось проще, чем просто настроить очередной проект на poetry. Такое ощущение, что этот пакетный менеджер будет жить только по инерции.
А мне надоело тащить в каждый проект монструозный dictConfig. Все оказалось намного проще и приятнее с loguru, который также интегрируется с logfire и тогда все логи с полпинка отравляются в облако.
Джуни это расширение для их AI, которое не просто даёт чат, а умеет решать задачи по ключ, создавать новые файлы и редактировать имеющиеся. Работает не быстро, потому что выполняет много рассуждений. В целом пока страшновато применять в сложных проектах, чата достаточно для таргетированных доработок.
Третий год сижу на дагстере, полет нормальный. Хоть и пришлось написать много кода, зато вся оркестрация действительно выглядит как центр управления данными, в отличие от Airflow, который все еще управляет лишь задачами...
Ну кстати в корпблогах бывает, что почитать. А статьи из серии "Хабр не торт" хоть и развлекательные, но никакого отношения к миссии хабра не имеют.
Пусть каждый пишет, что хочет. Очевидно, что жёсткой модерации здесь уже не будет.
Бот для изучения Docker через стимуляцию айтишного чата. Потому что учиться лучшего всего на практике
https://t.me/docker_ai_game_bot
Роли тимлида и проджекта исполняет AI.
И ещё вопрос, почему requirements.txt, а не pyproject.toml, где можно гибко управлять зависимостями?
А SQLModel пробовали? Он объединяет Sqlalchemy с Pydantic. В моих проектах на fastapi хорошо заходит, но бывают некоторые неудобства из-за абстракции поверх алхимии.
Это интересные фантазии, но на практике основная проблема вовсе не в питоне, а в нехватке управляемости и наблюдаемости пайплайнов.
Дагстер здесь принес много интересных подходов вроде использования качестве ассетов и накопления метаданных, за это его и выбирают. Это airflow и пытается у него позаимствовать в следующей версии.
Ну и ещё дагстер легко запустить локально для отладки и тестирования пайплайнов. Привет отделке в эйрфлоу путем коммитов в репозиторий.
В любительской робототехнике, например, так и настраивают, че уж тут выпендриться.