Будучи единственным аналитиком в быстрорастущем сиднейском стартапе, Клэр испытала на себе все тяготы традиционного рабочего процесса аналитика — застревание в "хомячьем колесе", постоянно растущий бэклог и цифры, которые никогда не сходились. Поэтому она освоила dbt, командную строку, контроль версий и привнесла в свою команду всю скрупулезность аналитического инжиниринга. Попутно она так полюбила dbt, что в итоге собрала вещи и переехала в США, чтобы возглавить активно развивающееся сообщество dbt.

Инженеры-аналитики предоставляют конечным пользователям чистые наборы данных, моделируя их таким образом, чтобы конечные пользователи могли сами отвечать на свои вопросы. Сегодня мы с вами поговорим о тенденциях рынка, которые привели к появлению этой новой роли в современных командах по работе с данными.

Год назад я готовила презентацию для одного мероприятия, и на титульном слайде меня попросили указать мою должность. Меня наняли на должность "аналитика данных", и когда я приступила к работе, то проводила время, занимаясь обычными для аналитика данных задачами. Я собирала данные по финансам и маркетингу, анализировала тенденции и делала выводы, проводя много времени в Excel и Looker.

Но моя роль кардинально менялась. Финансы и маркетинг получили возможность создавать собственные отчеты. Поэтому обычный рабочий день для меня состоял из подготовки данных к анализу, написания кода для трансформации и тестирования, а также составления хорошей документации. Моими инструментами больше не были Excel и Looker, ими стали iTerm, GitHub и Atom.

Я все еще была аналитиком данных?

На какое-то время я оставила слайд пустым, а перед самым мероприятием заполнила его: "Клэр Кэрролл — Делаю что-то с данными".

С тех пор в индустрии появилось четкое название для того, что я пыталась описать, — инженер-аналитик.

Что такое инженер-аналитик?

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

Когда появилась аналитическая инженерия?

Традиционная команда по работе с данными

Если вы работали в "традиционной команде работы с данными" до 2012 года, вашим первым коллегой, нанятым для работы с данными, вероятно, был бы скорее всего дата-инженер. Он был нужен для создания инфраструктуры: извлечения данных из базы данных Postgres и SaaS-инструментов, с помощью которых велся бизнес, преобразования этих данных и загрузки их в хранилище данных.

Затем нужно было нанимать аналитика данных, чтобы он создавал на основе этих данных информационные дашборды и отчеты. Аналитики, как и я, оперировали беспорядочной кучей SQL-файлов с именами типа monthly_revenue_final.sql или, возможно, просто делали закладки для своих запросов в веб-редакторе SQL. Часто нам приходилось дополнять данные в хранилище причудливыми выкрутасами в Excel.

Люди, потребляющие данные, — генеральные директоры, вице-президенты по маркетингу, финансовые директора — получали ежемесячные отчеты, запрашивали специальный анализ по мере необходимости и отправляли аналитикам нескончаемый поток запросов "сегментировать по этому", "сократить по тому" или "эй, мы обновили наше определение "аккаунта"".

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

Что случилось с традиционной командой по работе с данными?

С 2012 года в сфере инструментов для работы с данными произошли огромные изменения:

• Облачные хранилища данных (Redshift, а затем BigQuery и Snowflake) сделали хранение и обработку данных доступными и быстрыми.

• Сервисы конвейерной обработки данных (например, Stitch, Fivetran) превратили извлечение данных в работу, которая требует всего несколько кликов.

• Инструменты бизнес-аналитики (BI) (например, Looker, Mode, Chartio) расширяют возможности заинтересованных лиц по самообслуживанию.

К 2016 году стало как никогда просто получить данные в хранилище в необработанном виде, а заинтересованным лицам — построить отчеты на их основе.

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

Решение: преобразовать необработанные данные в форму, готовую к аналитике. В то время существовало только два широко используемых варианта:

• Постоянные производные таблицы Looker

• Привлечение дата-инженера

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

Именно тогда на рынок вышла компания dbt.

Современная команда по работе с данными

dbt - это слой преобразования, созданный для современных инструментов хранения и ввода данных. Построенный на базе SQL, dbt делает слой преобразования полностью подконтрольным аналитикам данных.

Сегодня, если вы являетесь "современной командой по работе с данными", вашим первым сотрудником, нанятым для работы с данными, будет тот, кто в конечном итоге будет владеть всем стеком данных. Этот человек может настроить Stitch или Fivetran для начала ввода данных, поддерживать хранилище данных в порядке, писать сложные преобразования данных на SQL с помощью dbt и создавать отчеты поверх чистого слоя данных в Looker, Mode, Redash и т. д.

Эта работа не является ни проектированием, ни анализом данных. Она находится где-то посередине, и ей нужно было новое название. Начиная с 2018 года мы и несколько наших друзей из сообщества Locally Optimistic стали называть эту роль инженером-аналитиком.

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

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

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

Вот как я представляю себе различные роли в современных командах по работе с данными в крупных организациях:

Границы между этими ролями размыты — некоторые инженеры-аналитики могут тратить время на аналитическую работу, например, глубокие погружения, а другие могут с комфортом писать код на Python для продакшена, но понимают, что это часто не самое эффективное использование их времени.

Термин "инженер-аналитик" довольно новый, и многие люди, занимающиеся аналитикой, не носят это звание (еще год назад и я не его носила!). Так как же узнать, являетесь ли вы инженером-аналитиком?

На первый взгляд, инженера-аналитика часто можно узнать по набору технологий, которые он использует (dbt, Snowflake/BigQuery/Redshift, Stitch/Fivetran). Но, заглянув глубже, вы заметите, что они увлечены решением другого класса проблем, чем другие члены команды по работе с данными. Инженеров-аналитиков волнуют такие проблемы, как:

• Можно ли создать единую таблицу, которая позволит нам ответить на весь этот набор бизнес-вопросов?

• Каково наиболее четкое соглашение об именовании таблиц в нашем хранилище?

• Что, если бы я мог получать уведомления о проблемах с данными до того, как бизнес-пользователь обнаружит неработающий график в Looker?

• Что аналитики или другие бизнес-пользователи должны понимать об этой таблице, чтобы использовать ее быстро?

• Как повысить качество данных на этапе их создания, а не последующей очистки?

Куда это все идет?

На недавней встрече в Нью-Йорке, где собрались 100 профессионалов в области данных, чтобы поговорить об аналитике, один из докладчиков сравнил инженера по аналитике с библиотекарем — человеком, который хранит данные организации и выступает в качестве ресурса, который хочет их использовать. Мне нравится эта метафора: инженер-аналитик — это хранитель организационных знаний, а не исследователь, отвечающий на конкретный вопрос. Инженер-аналитик ведет каталог, чтобы исследователи могли выполнять свою работу более эффективно.

Инструментарий, практика и организационная роль инженера-аналитика очень быстро развиваются в режиме реального времени. Год назад такого названия не существовало. Сегодня, когда мы утвердили эту тему в качестве темы встречи, на нее пришло более 100 участников, и с каждым месяцем мы видим все больше и больше объявлений о вакансиях на эту должность. Итак, в индустрии существует множество вариантов этой идеи и этой роли, но мы все вместе выясняем это в режиме реального времени.

Хотя год назад я, возможно, не могла подобрать правильные слова для описания своей роли, я знал десятки других людей в сообществе dbt, чьи роли совпадали с моими, и у них были невероятно умные мнения о пространстве. Вот почему сообщество dbt так ценно для меня лично и для всех его членов. Все мы, вместе взятые, изобретаем новое.

В заключение приглашаем на открытый урок OTUS, на котором обсудим, как проходить интервью на позицию DWH-аналитика для Middle+ специалистов, разберём практические кейсы и ответим на все вопросы в режиме реального времени. Записаться на встречу можно на странице курса "Data Warehouse Analyst".