Analytics Engineer: модный термин или незаменимый член команды данных?

За последние годы в мире данных появилась новая звезда — Analytics Engineer. HR-специалисты все чаще встречают эту должность в резюме и вакансиях, а в профессиональных кругах не утихают споры: кто это вообще такой и нужен ли он компаниям? Одни считают, что analytics engineer – лишь очередной маркетинговый ярлык от создателей модных инструментов (в сети пишут прямо: «аналитик-инженер – это маркетинговый термин, придуманный в кругах dbt» (источник reddit.com)).

Другие уверены, что это необходимый мост между аналитиками и инженерами данных, который закроет разрыв в компетенциях команды. Недаром на Reddit сообщество по аналитическому инжинирингу называет эту профессию «hottest job title in 2023» – «самая горячая должность 2023 года» (источник reddit.com). Давайте разберемся, откуда взялась роль Analytics Engineer, чем она отличается от привычных позиций и как оценивать специалистов на этом поприще.

Кто такой Analytics Engineer и откуда он взялся

Прежде термин analytics engineer практически не встречался – еще десять лет назад все задачи по подготовке данных для анализа выполняли Data Engineer (инженер данных) и Data Analyst (аналитик данных), каждый в своей нише. Классическая схема выглядела так: инженер данных вытаскивает и преобразует данные, загружает их в хранилище, а аналитик уже строит на основе этих данных отчеты и дашборды (источник getdbt.com). Это разделение породило постоянный бэттл некстов: аналитик ждет, пока data engineer напишет очередной ETL-пайплайн под новый запрос, инженер вечно завален очередью задач от аналитиков (источник getdbt.com). Такие циклы запросов и ожидания тормозили проекты и раздражали всех участников процесса.

Ситуация начала меняться после 2012 года с приходом облачных технологий для работы с данными. Появились мощные облачные DWH (Amazon Redshift, BigQuery, Snowflake), которые позволяют быстро хранить и обрабатывать большие объемы данных. Затем – удобные сервисы для загрузки данных (ELT-платформы вроде Stitch, Fivetran), благодаря которым данные из десятков источников можно «накидать» в хранилище парой кликов (источник habr.com). BI-системы тоже сделали шаг вперед, дав бизнес-пользователям возможность самим строить отчеты. К 2016 году загрузить сырые данные в облачный склад и сразу строить над ними визуализацию стало проще, чем когда-либо.

Но оставалась проблема: данные-то в хранилище сырые, разношерстные. Прежде их либо трансформировали заранее (классический ETL), либо аналитики выкручивались, делая сложные вычисления на лету в своих BI-инструментах (как PDT в Looker). Первый подход требовал времени и участия инженеров, второй – рождал хаос из неустойчивых одноразовых решений.

Именно тогда на сцену вышел инструмент dbt (Data Build Tool) (источник medium.com). Он позволил производить все трансформации после загрузки данных в DWH – прямо внутри хранилища, с помощью привычного SQL. Фактически, dbt стал тем самым недостающим звеном, дав аналитикам возможность самим ставить преобразование данных по расписанию, как раньше это делали только разработчики.

Идеология сместилась с ETL к ELT: Extract, Load, Transform – «сначала выгрузить и загрузить данные, а трансформировать потом, в хранилище». Этот сдвиг открыл дорогу новой породе специалистов – очень технически подкованным аналитикам, которые могут своими силами превратить сырые разрозненные данные в аккуратные таблицы для анализа. В 2018 году в сообществе вокруг Fishtown Analytics (ныне компания dbt Labs) для таких людей придумали название: Analytics Engineer. Как потом шутили, «если дата-инженер женится на дата-аналитике, у них родится дочка – аналитический инженер». Этот полушутливый образ метко описывает гибридную природу новой роли.

Стоит отметить, что термин Analytics Engineer во многом популяризировала команда создателей dbt. Некоторые отраслевые комментаторы иронизируют, мол это «гениальный ребрендинг», удачный маркетинговый ход, подхваченный индустрией. Представительница Fishtown Analytics Джанесса Лантц, впрочем, утверждала в интервью, что они не преследовали цели навязать рынку новое модное слово. Как бы то ни было, спрос на таких специалистов возник из реальной потребности: компаниям требовались специалисты, которые закроют разрыв между добычей данных и их бизнес-анализом. Так сформировалась новая роль – инженер по аналитике данных, он же analytics engineer.

Чем аналитический инженер отличается от других ролей

Analytics Engineer находится где-то посередине между классическим дата-инженером и аналитиком. Его главная зона ответственности – преобразование сырых данных в пригодный для анализа вид внутри хранилища. Если упрощенно, то data engineer обеспечивает доставку и хранение данных, а analytics engineer превращает эти данные в понятные таблицы для конечных пользователей. Один из практиков метко описал разницу: «аналитик-инженер больше заточен на BI-аспект жизненного цикла данных, а инженер данных – на всё, что касается доставки данных этому аналитику-инженеру».

Analytics engineer моделирует данные, строит из сырых схем аккуратно связанные сущности, вводит единые определения метрик. Такой специалист стремится предоставить бизнес-пользователям проверенный и понятный “источник истины” – чтобы два разных менеджера не получали две разных цифры одного показателя. По сути, AE закрывает разрыв между инженерами данных и аналитиками: он достаточно технический, чтобы понимать инфраструктуру и SQL, но при этом ориентирован на бизнес-задачи как аналитик.

В повседневной работе аналитический инженер делает многое из того, что раньше ожидалось либо от data engineer, либо от самого аналитика, но с другим подходом. Например, вместо скриптов на Python для трансформаций он пишет код SQL по шаблонам в том же dbt. Вместо разрозненных Excel-файлов он создает централизованные модели данных в хранилище. Очень важно, что AE приносит в мир аналитики лучшие практики классического программирования: хранение кода в Git, код-ревью, модульное построение моделей, автоматическое тестирование данных.

Analytics engineers не боятся «грязных» данных, потому что умеют с помощью SQL их отмыть и структурировать. Говорят, такой специалист напишет SQL-запрос лучше, чем среднестатистический аналитик и даже типовой дата-инженер (источник getdbt.com). Он заранее позаботится о проверках качества данных, о понятной документации к каждому набору – чтобы конечные аналитики и бизнес-пользователи смогли легко воспользоваться результатом его труда.

На первый взгляд кажется, что роль дублирует обязанности других членов команды данных. И правда, границы размыты: хороший data engineer тоже знает SQL и может сделать преобразование в хранилище, а опытный аналитик при наличии прав доступа иногда самостоятельно пишет сложные SQL-скрипты. Не случайно скептики заявляют, что отдельная роль аналитического инженера имеет смысл разве что в крупных компаниях с большим масштабом данных, а в небольших командах его функции распределены между другими сотрудниками. Тем не менее, практика последних лет показывает, что выделение такой специализации себя оправдывает.

Аналитический инженер разгружает дата-инженеров, позволяя им сконцентрироваться на инфраструктуре и сложных вещах (оптимизация производительности, настройка потоков данных, управление правами и т.п.), а аналитикам дает готовый “пластилин”, из которого они лепят бизнес-отчеты, не отвлекаясь на грязную работу с сырыми данными. В итоге цикл от вопроса бизнеса до ответа на основе данных сокращается в разы. По оценкам команды dbt Labs, появление в команде analytics engineer способно повысить скорость аналитического процесса до 10 раз – аналитики перестают простаивать в ожидании ETL и могут итеративно дорабатывать модели почти в реальном времени.

SQL + dbt: главные инструменты Analytics Engineer

Как понятно из всего вышесказанного, SQL – по-прежнему основной язык работы аналитического инженера. В этом смысле роль во многом эволюционировала из классического BI-аналитика, который “дорос” до инженерного стека, оставаясь приверженным SQL. Согласно опросам, SQL прочно удерживает позиции must-have навыка для всех, кто переходит из аналитиков в data engineering/analytics engineering.

Почему? SQL декларативен и понятен очень многим – найти человека, хорошо владеющего SQL, проще, чем эксперта в Java/Python, поэтому компании рады решать максимум задач средствами SQL. Современные инструменты идут навстречу: тренд последних лет – добавлять SQL-интерфейс всюду, где раньше требовался код на общем назначения языке.

Если SQL – “рабочая лошадка” analytics engineer, то dbt – его волшебный хлыст, помогающий заставить эту лошадку бежать быстро и стройно. Data Build Tool стал фактически стандартом де-факто для управления превращением данных внутри DWH. Что делает dbt особенным? Это open-source фреймворк, в котором все трансформации задаются в виде SQL-скриптов, а выполнение организовано как DAG (ориентированный ацикличный граф). Проще говоря, вы пишете SQL-запросы как модели, а dbt сам выясняет зависимости между ними (через ref()), в правильном порядке запускает их на выполнение в вашем хранилище и раскладывает результат по целевым таблицам.

Вместе с этим он обеспечивает полезные “взрослые” удобства: генерацию документации, автоматическое тестирование данных (например, на уникальность ключей, непропуски, соответствие справочникам), ведение версий в Git, интеграцию в CI/CD конвейер. По сути, dbt привносит в мир аналитики дух классической разработки, но без необходимости программировать на чем-то сложнее SQL. “dbt спроектирован так, чтобы аналитики сами могли владеть всем процессом аналитического инжиниринга данных”, отмечается в одном из обзоров. Неудивительно, что как только компания внедряет у себя dbt, она вскоре начинает целенаправленно искать специалиста под эту роль – того самого analytics engineer.

Конечно, dbt – не единственный инструмент в арсенале нашего героя. Он активно использует любые средства, облегчающие ему жизнь: системы оркестрации задач (Airflow, Prefect) для расписания запусков моделей, репозитории (GitHub/Bitbucket) для контроля версий своего кода, иногда языки вроде Python или R для сложных вычислений вне SQL. Но все же именно владение SQL и концепциями data modeling отличает по-настоящему сильного аналитического инженера. В описаниях вакансий на эту роль почти всегда можно увидеть требования: глубокое знание SQL, навыки продвинутого реляционного моделирования данных (построение схем “звезда/снежинка”, понимание нормализации/денормализации, dimensional modeling), опыт работы с хотя бы одной облачной базой данных (Redshift, BigQuery, Snowflake). Знание dbt упоминается все чаще, но рынок пока допускает, что кандидат может освоить его в ходе работы – куда важнее общее понимание принципов ELT и умение писать чистый поддерживаемый SQL-код.

Кстати, хороший способ оценить уровень аналитического инженера – посмотреть, насколько красивый и оптимизированный SQL он пишет. В сообществе шутят, что такие специалисты помешаны на “writing damn good SQL”, то есть стремятся выжать максимум из возможностей языка. Они любят использовать нетривиальные конструкции вроде оконных функций, CTE (Common Table Expressions) и макросов, избегая копипаста и неэффективных решений. Поэтому на собеседованиях для Analytics Engineer частенько просят кандидата оценить свои навыки SQL по шкале и расспрашивают, применял ли он оконные функции или рекурсивные запросы – по ответу сразу понятно, с кем имеешь дело.

Как оценить и найти хорошего Analytics Engineer

Найм Analytics Engineer – нетривиальная задача для HR, особенно если сами рекрутеры не до конца понимают, чем эта роль отличается от других. Эксперты советуют при подборе фокусироваться на конкретных навыках, а не на громком титуле. Поскольку эта должность относительно новая, у соискателей в резюме может не быть прямого титула “Analytics Engineer”.

Специалисты могут называться data analyst, BI developer, data warehouse engineer – кто угодно. Поэтому важно смотреть в суть: кандидат должен уметь структурно мыслить как инженер, понимать принципы организации данных, знать SQL от и до и проявлять стремление постоянно учиться. При найме «аналитика с задатками инженера» зачастую лучше взять любознательного новичка, готового расти, чем «опытного, но самоуверенного профи», который не захочет переучиваться под новые подходы.

С точки зрения хард скиллов, на интервью почти наверняка потребуется подтвердить высокую квалификацию в SQL. Практика многих компаний – давать техническое задание: кейс или тест, где нужно написать запросы к базам и построить модели. Например, в одной из команд кандидату на Analytics Engineer высылали домашнее задание, состоящее из двух частей: первая – спроектировать по набору сырых таблиц модель для месячного отчета (то есть написать SQL для агрегирования KPI по месяцам), вторая – выполнить небольшое аналитическое исследование по данным из CSV-файла любым удобным способом. Такое задание проверяет и навык SQL-моделирования, и умение мыслить как аналитик.

В следующем раунде собеседования соискателя могут подробно расспросить про опыт работы с dbt, про основы моделирования (чем факт отличается от измерения, какие есть слои в хранилище данных и зачем они нужны). Цель – понять, насколько кандидат знаком с лучшими практиками организации данных. Ничего запредельно сложного – вопросы касаются в основном реального опыта и понимания принципов.

Помимо SQL, работодатели ценят у analytics engineer знание инструментов командной разработки и вообще інженерный майндсет. Часто спрашивают: знакомы ли вы с системами контроля версий (Git), как вы проверяли качество данных в прошлых проектах, приходилось ли настраивать автоматизацию пайплайнов (CI/CD). Хороший признак – если кандидат в ответах упоминает, например, что писал тесты в dbt или внедрял code review для SQL-моделей. Это показывает, что человек действительно подходит к аналитике как к разработке, а не ограничивается однократным получением цифры в Excel.

Важно и то, откуда пришел потенциальный аналитический инженер. Как правило, такие специалисты вырастают либо из аналитиков, которые полюбили техническую сторону работы, либо из дата-инженеров, которым интереснее бизнес-логика, чем инфраструктура. Первые знают бизнес-домены и метрики, умеют говорить с заказчиками, но могут хромать в коде – зато быстро обучаются, потому что мотивированы избавиться от ручной рутины и автоматизировать свою работу. Вторые крепко владеют технологиями, но им может не хватать навыков аналитического мышления или коммуникации с бизнесом.

В любом случае на этапе найма стоит выяснить, каков бэкграунд кандидата и чего ему может недоставать. Если, скажем, это бывший BI-аналитик, можно задать несколько дополнительных технических вопросов, проверить понимание основ баз данных. Если же перед вами дата-инженер, стоит поинтересоваться, сталкивался ли он с задачами бизнес-анализа, метриками, работал ли плотно с аналитиками – то есть сможет ли говорить с будущими внутренними заказчиками на одном языке.

Наконец, немаловажный момент – когда компании действительно нужен Analytics Engineer. Если у вас маленький стартап и один аналитик, возможно, и без отдельной роли вы справитесь: аналитик сам напишет пару SQL-скриптов, а базовую инфраструктуру обеспечит инженеры-разработчики. Другая ситуация, если у вас уже несколько аналитиков и накапливается технический долг в виде хаотичных таблиц и скриптов. Показательный пример – компания Skyeng. Там долгое время вообще не было дата-инженеров: более 30 “фулстек-аналитиков” сами справлялись со всеми этапами, пользуясь облачными инструментами вроде Redshift, Stitch и Matillion, чтобы гнать данные из десятков источников и обновлять витрины под отчеты.

Но в какой-то момент масштаб вырос, и эффективность стала проседать – аналитики тратили все больше времени на поддержку своих самописных пайплайнов, рост инфраструктуры стал дорого обходиться. В итоге руководство признало: пора нанять профессионального инженера данных, который займется оптимизацией хранилища, пайплайнов, затрат и вообще наведет порядок под капотом. Вывод: пока объем данных небольшой, а инструменты позволяют аналитикам относительно легко делать простые конвейеры, выделенная роль может и не понадобиться. Но если у вас уже ощутимый data-масштаб – десятки источников, сотни таблиц, сложная логика обновления – без человека, отвечающего за качество и структуру данных, развитие аналитики затормозится. Таким человеком и является Analytics Engineer.

***

Нужен ли вашей компании аналитический инженер – зависит от контекста, но очевидно одно: появление этой роли – не сиюминутный тренд, а отражение глобальных изменений в подходе к данным. Мир переходит на рельсы самообслуживания и скорости в аналитике. Бизнес больше не хочет ждать месяцами, пока ИТ-отдел подготовит очередной отчёт – решения нужны здесь и сейчас, на основе свежих данных. Analytics Engineer во многом рожден этим запросом на скорость и гибкость.

Он позволяет выстроить эффективный конвейер данных: от сырых источников до красиво сервированного “стола” метрик, за который садится бизнес. Хороший аналитический инженер владеет и кухней данных, и языком бизнеса. Он знает, как из разбросанных ингредиентов сводных таблиц сварить единый Data Mart, и позаботится, чтобы по дороге ничего не прокисло и не пригорело.

Можно ли обойтись без него? Маленькой команде – возможно, да. Но практика показывает, что по мере роста данных и запросов роль analytics engineer становится практически незаменимой. Это специалист, который снимает тормоза с вашей аналитики. В итоге решения принимаются на качественных данных быстрее, а значит, бизнес движется вперед увереннее.

Маркетинговый это хайп или нет – покажет время. Но уже сейчас понятно: навык сочетать бизнес-аналитику с инженерным подходом ценится все выше. Как шутят в сообществе, “SQL никуда не денется”, и в ближайшие годы мы наверняка увидим еще больше запросов на талантливых инженеров данных с душой аналитика. А те компании, что сумеют их заполучить, окажутся на шаг впереди в новой data-реальности.