Как известно, DevOps является ответом на реалии IT, которые были в сфере 20–30 лет назад. Долгое время между разработчиками и сисадминами стояла высокая стена, в силу которой эти специалисты трудились практически изолированно друг от друга. Однако благодаря развитию технологий, а также их активному внедрению удалось сделать процессы взаимно проникаемыми.

Поэтому DevOps-инженер звучит как оксюморон. Тем более данным термином обычно обособляют сисадминов, которые акцентированы не на ежедневном поднятии постоянно вырубающихся МФУ, а на автоматизации развертывания и эксплуатации клиент-серверных приложений. И только совсем поехавшему дефективному менеджеру придет в голову от единственного эксперта требовать одновременно и бизнес-логику выражать кодом, и заниматься под это все инфраструктурой.

Впрочем, ажиотаж вокруг Big Data породил экспертов, которые сочетают в себе и Dev, и Ops. Знакомьтесь, речь пойдет об инженерах данных. Эти специалисты занимаются тем, что обеспечивают сбор, хранение и доставку информации, на основе которых затем функционируют ML, BI и прочие модные подобные вещи.

Почему Dev? Потому что, используя языки программирования (преимущественно связку Python и SQL; иногда Java, Scala и даже Go), пишут ETL-скрипты, которые собирают и обрабатывают данные из множества источников: как внутренних (БД, электронные таблицы), так и внешних (API, URL). Проектируют DAG’и, а также структуры хранилищ (DWH), озер (DataLake) и витрины данных (DataMart), дабы все работало целостно и бесперебойно.

Почему Ops? Оркестрируют ETL-скрипты с помощью Airflow, чтобы ETL-процессы не мешали друг другу. Настраивают брокеры задач, чтобы система не забыли ничего исполнить. Разворачивают, а потом наблюдают за функционированием DWH (скорее всего, на основе ClickHouse). Версионируют свои действия в Git. Возятся с CI/CD, чтобы изменения под капотом не нарушили стабильность потоков данных.

Как становятся инженерами данных? Вариантов много. Один из распространенных — переход из аналитики данных. В первом приближении это очевидный способ карьерного и материального роста по диагональной траектории для аналитика данных. На глубинном же уровне такого аналитика данных мотивирует понимание того, что без детального внимания к инфраструктуре прочее в виде ML и BI будет не жизнеспособно.

Увы, в мелкомасштабных конторах чаще всего инженерия данных считается чем-то само собой разумеющемся. Вследствие чего, как минимум, усилия аналитика данных на этом поприще просто не оцениваются менеджментом. Более того, могут назвать фактором, который отвлекает от исполнительства основных поручений, посвященных формированию data-driven решений в бизнес-домене. Из-за чего инженерия данных в большинстве своем является историей, близкой к крупняку.

Таким образом, инженерия данных — довольно неординарная сфера в техническом контексте. Благодаря чему, как мне кажется, неудивительно, что она оказывается точкой притяжения и оркестрации людей вне зависимости от их образовательного и карьерного анамнеза.