[Перевод] Что такое аналитический инжиниринг?
Будучи единственным аналитиком в быстрорастущем сиднейском стартапе, Клэр испытала на себе все тяготы традиционного рабочего процесса аналитика — застревание в «хомячьем колесе», постоянно растущий бэклог и цифры, которые никогда не сходились. Поэтому она освоила 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, чтобы быть опасными. Если вы когда-нибудь бывали на совещании, где два руководителя получали разные цифры по одной и той же метрике, то значит вам приходилось сталкиваться с таким результатом.
Решение: преобразовать необработанные данные в форму, готовую к аналитике. В то время существовало только два широко используемых варианта:
Первый вариант был достаточно прост, чтобы им мог управлять любой человек с навыками 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».
