Не секрет, что мы живем в быстро меняющемся мире, генерируя все больше и больше машинных данных. Наступила новая эра больших данных и прочее, что вы слышали сотни раз. Множество компаний хотят увеличить свою прибыль, используя анализ данных. Become data-driven стало новым трендом и девизом для многих Естественно, на этом фоне появилось много новых инструментов и проектов с открытым кодом.
Как они могут упростить эти задачи, и как сделать выбор между коммерческими продуктами и решениями с отрытым исходным кодом? Или разрабатывать и дорабатывать самостоятельно?
Я не дам однозначного ответа, скорее поделюсь мыслями.
И прежде всего, стоит сказать, что каждый случай/компания довольно уникальны, хотя безусловно каждый сталкивается с похожими проблемами и потребностями. К примеру, практически каждое современное описание вакансии содержит слова Airflow, Python, SQL, Redshift/Snowflake/Bigquery, Tableau/Looker.
Абсолютно ясно, почему два последних пункта в этом списке, но как насчёт Airflow и Python? Поймите меня правильно, я действительно люблю Airflow и писать на Питоне, это замечательный инструменты, но всё же - могут ли дата-инженеры позволить себе сосредоточиться на более интересных задачах, чем написание очередного коннектора к очередному API? В этом свете интересно выглядят современные инструкменты вроде Fivetran, Stitch, dbt.
Итак, мы подошли к вопросу о том, в каком случае имеет смысл держать команду инженеров, которые будут поддерживать все DAGи, пайплайны и сопутствующий код. На мой взгляд это актуально в следующих случаях:
- количество источников невелико, и они меняются и добавляются нечасто
- особые требования к безопасности
- особые источники данных, которые не поддерживаются упомянутыми провайдерами
Любой другой сценарий потенциально выиграет от использования облачных провайдеров, просто потому что это будет более надёжное решение. В любом случае никто не запрещает взять лучшее из обоих миров и использовать как Airflow, так и облачных провайдеров.
Важный момент: у читателя может возникнуть вопрос, а чем тогда будет заниматься дата инженер? Не стоит бояться, что у кого-то отнимают работу, это просто упрощение рутины, и освобождение времени и ресурсов для более важных задач. Кроме того, лично я бы не хотел становиться особо ценным сотрудником для компании, просто потому что я знаю, как работает сложный участок кода, который грузит данные в хранилище.
В то же время есть ещё один немаловажный фактор - профессионализм команды. Я склонен полагать, что команды, обладающий сильной экспертизой, больше выиграют от использования собственных решений. Просто потому что, они будут достаточно гибкие и заточенные именно на нужды компании. Довольно часто подобные команды активно участвуют в разработке Open-Source продуктов, внося свой вклад в их развитие.
Это особенно актуально в свете современных концепций организации дата-команд - таких как Data Mesh, когда вечно перегруженная запросами команда дата-инженеров, передаёт часть функций непосредственно командам, которые используют эти данные. И позволяет создавать новые загрузки данные, предоставляя общую платформу для работы с данными.
Большое спасибо, если вы дочитали до конца. Буду очень рад, если вы поделитесь вашим мнением и опытом.