Аргументы, которые вы привели имеют место быть. Питон довольно обманчив в плане своей лёгкости для разработки. Но назвать его чем то ужасным у меня язык не поворачивается. Писать плохой и неэффективный код можно на любом языке.
Теперь о конкретно нашем случае, стояла проблема следующего характера - была реализована аналитика на некотором clickhouse + доставка данных до него с помощью проекта на java(все inhouse). Через некоторое время количество данных увеличилось значительно, также аналитикам были поставлены задачи на довольно сложный анализ происходящего. Решение оказалось крайней сложно масштабируемым до новых запросов.
Запрос бизнеса был такой - максимальная скорость перехода на новое решение.
Собственно здесь было принято решение уйти в облако. Это быстрее, чем инхаус развернуть. Здесь же принято решение писать на питоне.
Блок оправданий за питон:
дата инженеров было буквально несколько, а аналитиков было (относительно дата инженеров) много;
дата инженеры стали ботлнеком;
Найм новых дата инженеров шел медленно;
Почти у всех дата инженеров, в том числе у меня, опыта разработки на питоне было мало, до этого мы писали на scala и java почти все. Мы пошли на следующий трюк - мы можем не только своими силами организовать переезд, но и максимально привлечь к этому аналитиков(по крайней мере кодить бизнес логику или писать dag в Composer, он же airflow), ведь они умеют писать код. Правда только на питоне. Это и дало нам некоторое ускорение переезда.
После того, как основная часть аналитики переехала, мы оформляем этот код как отдельную либу, которой могут пользоваться аналитики и стараемся максимально облегчить ее использование(конфигурации yaml вместо кода). И освобождаем наши руки для сложных инженерных задач, где требуется в том числе scala + поддержка и развитие этой либы как self service постановки простых ETL в прод. Собственно код этой либы и является героем статьи.
Аргументы, которые вы привели имеют место быть. Питон довольно обманчив в плане своей лёгкости для разработки. Но назвать его чем то ужасным у меня язык не поворачивается. Писать плохой и неэффективный код можно на любом языке.
Теперь о конкретно нашем случае, стояла проблема следующего характера - была реализована аналитика на некотором clickhouse + доставка данных до него с помощью проекта на java(все inhouse). Через некоторое время количество данных увеличилось значительно, также аналитикам были поставлены задачи на довольно сложный анализ происходящего. Решение оказалось крайней сложно масштабируемым до новых запросов.
Запрос бизнеса был такой - максимальная скорость перехода на новое решение.
Собственно здесь было принято решение уйти в облако. Это быстрее, чем инхаус развернуть. Здесь же принято решение писать на питоне.
Блок оправданий за питон:
дата инженеров было буквально несколько, а аналитиков было (относительно дата инженеров) много;
дата инженеры стали ботлнеком;
Найм новых дата инженеров шел медленно;
Почти у всех дата инженеров, в том числе у меня, опыта разработки на питоне было мало, до этого мы писали на scala и java почти все. Мы пошли на следующий трюк - мы можем не только своими силами организовать переезд, но и максимально привлечь к этому аналитиков(по крайней мере кодить бизнес логику или писать dag в Composer, он же airflow), ведь они умеют писать код. Правда только на питоне. Это и дало нам некоторое ускорение переезда.
После того, как основная часть аналитики переехала, мы оформляем этот код как отдельную либу, которой могут пользоваться аналитики и стараемся максимально облегчить ее использование(конфигурации yaml вместо кода). И освобождаем наши руки для сложных инженерных задач, где требуется в том числе scala + поддержка и развитие этой либы как self service постановки простых ETL в прод. Собственно код этой либы и является героем статьи.