Автор перевода: Снежана Киселева (ТГК: Анализ данных и BI)

В чём же настоящая разница?

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

Дилемма, которая изменила мою карьеру

Несколько лет назад я задумался о смене компании. Как и многие люди, работающие на быстро развивающихся технических должностях, я столкнулся с на удивление сложным вопросом:

Какую роль я на самом деле выполняю? На какие вакансии мне следует откликаться?

На бумаге я был аналитиком данных. Но в действительности моя роль охватывала несколько функций: написание SQL-пайплайнов, создание дашбордов, определение KPI и глубокий анализ продуктовой аналитики. Я не был уверен, стоит ли мне подавать заявки на роли аналитика, BI-специалиста или на что-то совершенно другое.

Что ещё хуже, тогда названия должностей были расплывчатыми, а описания вакансий были перегружены модными словечками. Можно было найти объявление под названием «Аналитик данных», которое содержало такие требования:

• Создавать ML-пайплайны

• Писать сложные ETL-скрипты

• Поддерживать озёра данных

• Создавать дашборды

• Представлять инсайты на уровне топ-менеджмента

• И, кстати, отлично справляться с управлением стейкхолдерами

Это было ошеломляюще и сбивало с толку. И я знаю, что я не одинок в этом.

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

Реальный сценарий: знакомьтесь, Quikee

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

Клиенты размещают заказы через приложение или веб-сайт. За кулисами находятся микро-склады (также называемые «тёмными магазинами») по всему городу и парк курьеров, которые осуществляют молниеносные доставки.

Теперь давайте рассмотрим потребности этой компании в данных — от момента размещения заказа до дашбордов, которые руководители используют на своих утренних совещаниях в понедельник.

Шаг 1: Сбор и хранение необработанных данных

В момент размещения заказа клиентом генерируются транзакционные данные:

• Дата и время заказа

• ID заказа

• Заказанные товары

• Стоимость

• Коды скидок

• Местоположение клиента

• Метод оплаты

• Назначенный партнёр для доставки

Предположим, Quikee использует Amazon Kinesis для потоковой передачи этих данных в реальном времени в озеро данных S3. Этот поток является высокообъёмным, чувствительным ко времени и критически важным для отслеживания бизнес-показателей.

Но есть подвох: необработанные данные грязные. Их нельзя использовать напрямую для принятия решений.

Что же происходит дальше?

Шаг 2: Создание конвейеров данных

На сцену выходят инженеры данных.

Они отвечают за:

• Поглощение данных в реальном времени

• Проверку согласованности схем

• Обработку сбоев и повторных попыток

• Написание конвейеров для перемещения данных из S3 в хранилище данных (например, Snowflake или Redshift)

Здесь в игру вступают ETL (Extract, Transform, Load) или ELT конвейеры. Инженеры данных очищают, форматируют и структурируют данные, чтобы сделать их пригодными для запросов.

Например, таблица заказов может быть разделена на:

• Orders → Одна строка на заказ

• Order_Items → Одна строка на товар в заказе

• Payments → Одна строка на попытку платежа

На этом этапе необработанные логи превращаются в структурированные таблицы, с которыми могут работать аналитики.

Шаг 3: Проектирование измерений и OLAP

Когда руководство начинает задавать стратегические вопросы, такие как:

• «Какой город приносит наибольший доход?»

• «Какой магазин работает хуже?»

• «Каково наше среднее время доставки по зонам?»

...становится ясно, что прямой запрос транзакционных данных не будет масштабироваться.

Вот тут-то и приходит на помощь проектирование измерений.

Вместо плоских, необработанных таблиц данные структурируются в таблицы фактов и измерений.

? Таблицы фактов

• Большие, количественные таблицы данных, содержащие внешние ключи, а также показатели и метрики (Ну, в большинстве случаев. Существуют также бессмысленные таблицы фактов, которые не содержат никаких показателей).

• Примеры: fact_orders, fact_payments, fact_deliveries

• Содержат метрики, такие как выручка, количество заказов, время доставки

? Таблицы измерений

• Маленькие, описательные таблицы, которые помогают понять данные в таблице фактов

• Примеры: dim_store, dim_product, dim_customer, dim_delivery_agent

• Помогают фильтровать, группировать и объединять факты для получения более глубоких инсайтов

Эта структура позволяет использовать OLAP — быстрое аналитическое выполнение запросов по нескольким измерениям. Например, теперь вы можете выполнять такие запросы, как:

«Покажите мне среднее время доставки по магазинам и часам дня за последние 7 дней».

Этот шаг выполняется инженерами данных в большинстве организаций, но я строил несколько таблиц измерений и фактов, когда работал инженером бизнес-аналитики в Amazon.

Шаг 4: Определение KPI и метрик

Здесь проявляют себя инженеры-аналитики (или BI-разработчик).

Они находятся между техническим уровнем данных и бизнес-пользователями. Их обязанности часто включают:

• Определение KPI (например, уровень оттока, % повторных покупок, время выполнения)

• Написание логики для сложных метрик (например, удержание когорт, активные пользователи)

• Создание семантических моделей или слоев метрик в таких инструментах, как dbt, PowerBI, Looker, Tableau и тд.

• Обеспечение единообразных определений по всей компании

Например, в Amazon наша команда не запрашивала необработанные данные для расчета выручки каждый раз. Вместо этого мы создавали предварительно агрегированные таблицы фактов с дневным, недельным и месячным уровнем детализации. Таким образом, дашборды загружались быстрее, а метрики оставались согласованными между командами.

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

Шаг 5: Анализ, отчетность и повествование

Теперь наступает роль аналитика данных.

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

• «Почему уровень удержания клиентов в Бангалоре снизился в прошлом месяце?»

• «Какие купоны привлекают больше всего новых пользователей?»

• «Какие продукты чаще всего заказывают повторно в течение первых 30 дней?»

Они создают дашборды в таких инструментах, как Tableau, Power BI или Looker и тд. Они выполняют нерегламентированные SQL-запросы. Они погружаются в результаты A/B-тестов, тенденции поведения пользователей и эффективность кампаний.

Но, прежде всего, они рассказывают истории с помощью данных, делая сложные числа понятными и пригодными для использования заинтересованными сторонами.

Кто есть кто?

Короче говоря: где ваше место?

Вот как я это вижу:

• Нравится создавать надёжные пайплайны и решать проблемы масштабируемости? → Вы — инженер данных.

• Нравится определять бизнес-метрики и организовывать сложные наборы данных? → Вы — инженер-аналитик / BI разработчик.

• Нравится находить инсайты и рассказывать истории с помощью данных? → Вы — аналитик данных.

Конечно, реальные роли часто сочетают в себе эти функции. Особенно в небольших компаниях вы можете выполнять несколько ролей. И это нормально.

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

Заключительные мысли

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

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