Комментарии 11
А зачем писать большие проекты на Пайтон?
модно? да
скорость выполнения? нет
время реакции? нет
скорость разработки? нет
легкость поддержки? нет
Одно преимущество. Курсы питона за 2 недели "и вы программист".
Зря спорите с этими людьми. Это не пробиваемо. Вот вам минусов накидали с ходу без аргументов.
Скорость разработки, лёгкость поддержки? Да, однозначно. Батарейки на любой вкус и цвет, код читается легко, поддерживать читаемый код тоже в целом не сложно с линтерами, аннотациями, тестами.
Скорость выполнения? В 2022 почти на любой чих есть инструмент, написанный на более пригодном для этого языке - редисы, рэббиты, постгресы, нжинксы и прочее, необходимости писать то, что раньше зачастую писали руками сегодня почти нет, только в редких случаях. Сейчас в большинстве проектов основной язык это клей между инструментами, а питон был таким считайте с рождения. Для сети с асинхронкой нынешней питона тоже в большинстве случаев достаточно.
ну ладно питон.. но раз уж питон, то где Airflow ??
А не проще ли использовать язык с компилятором вместо линтера и аннотаций? В чем фишка? Если глянуть, например, на код использующий OpenCV, C++ и Python выглядят практически одинаково, но… на C++ код обертки можно распараллелить, а на Python? Добро пожаловать в мультизадачность с shared memory - это даже не хочется комментировать… Для написании небольших кусков кода при разработке алгоритмов, использование Python может быть удобно, но не более того. Понятность Python весьма условна, особенно большая кодовая база на Python. По моему опыту, проще разобраться в обьемном коде написанном на компилируемом языке чем на Python - при одинаковом владении 2 языками.
Аргументы, которые вы привели имеют место быть. Питон довольно обманчив в плане своей лёгкости для разработки. Но назвать его чем то ужасным у меня язык не поворачивается. Писать плохой и неэффективный код можно на любом языке.
Теперь о конкретно нашем случае, стояла проблема следующего характера - была реализована аналитика на некотором clickhouse + доставка данных до него с помощью проекта на java(все inhouse). Через некоторое время количество данных увеличилось значительно, также аналитикам были поставлены задачи на довольно сложный анализ происходящего. Решение оказалось крайней сложно масштабируемым до новых запросов.
Запрос бизнеса был такой - максимальная скорость перехода на новое решение.
Собственно здесь было принято решение уйти в облако. Это быстрее, чем инхаус развернуть. Здесь же принято решение писать на питоне.
Блок оправданий за питон:
дата инженеров было буквально несколько, а аналитиков было (относительно дата инженеров) много;
дата инженеры стали ботлнеком;
Найм новых дата инженеров шел медленно;
Почти у всех дата инженеров, в том числе у меня, опыта разработки на питоне было мало, до этого мы писали на scala и java почти все. Мы пошли на следующий трюк - мы можем не только своими силами организовать переезд, но и максимально привлечь к этому аналитиков(по крайней мере кодить бизнес логику или писать dag в Composer, он же airflow), ведь они умеют писать код. Правда только на питоне. Это и дало нам некоторое ускорение переезда.
После того, как основная часть аналитики переехала, мы оформляем этот код как отдельную либу, которой могут пользоваться аналитики и стараемся максимально облегчить ее использование(конфигурации yaml вместо кода). И освобождаем наши руки для сложных инженерных задач, где требуется в том числе scala + поддержка и развитие этой либы как self service постановки простых ETL в прод. Собственно код этой либы и является героем статьи.
Кейс 1. Навигация в проекте
Кейс 2. Помоги себе сам (Тиипизация)
Кейс 3. Сложная схема зависимостей
Кейс 4. А у меня локально запускается
Все 4 кейса совершенно не связаны с конкретно Питоном. Это общие вопросы разработки. Они применимы для (почти) всех языков программирования. И решаются эти вопросы везде плюс-минус одинаково.
Мне кажется, вы бы встретили все эти проблемы с любым новым для вас языком.
Airbyte + dbt + на некоторые ноды обработки python. Оркестрация через Airflow.
Личное мнение, python плох для DWH. Очень много вариантов написания одного и того же кода. SQL читается лучше. Какие-то отдельные преобразования можно на python.
Не хочу показываться душным, но, может быть, Пайтон?
В DWH только Python