Как аналитику стать инженером данных и что вообще он должен знать? 🧐

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

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

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

А о том, как из аналитики перейти в инженерию данных, поговорим уже завтра, 3 сентября в 19:00 МСК.

Вебинар проведет Георгий Семенов — Chief Data Officer и новый ментор курса «Инженер данных». Что разберём:

😶Пути становления и развития дата-инженера;
😶Необходимые скиллы для прохождения собеседования;
😶Ситуацию на рынке со стороны нанимателя: компании, грейды и зарплаты.

Роадмап придет вам в бот в формате pdf сразу после регистрации на вебинар.

Всем привет! На связи Павел Беляев 👋

Сегодня мог быть анонс очередного эфира со мной, но у меня есть новости поинтереснее! В сентябре я стану ментором на новом потоке курса-симулятора «Аналитик данных».

😶Немного обо мне для тех, кто ещё со мной не знаком:
Я уже более 5 лет руковожу командой аналитиков в компании Яндекс eLama, а также веду телеграм-канал «Тимлидское об аналитике».

Команда аналитиков eLama под моим руководством выполняет следующие задачи:
— разработка и поддержка витрин данных (Clickhouse, SQL);
— автоматизация и оптимизация процессов, связанных с данными: обновление витрин, мониторинг качества данных, чистка устаревшего и т.д.;
— разработка внутренних сервисов аналитики: модель данных, self service и др.;
— настройка веб-аналитики;
— прогнозирование метрик;
— поддержка различных отделов компании требуемыми данными;
— содействие другим аналитикам в сборе, визуализации и интерпретации данных;
— консалтинг и обучение конечных пользователей.

За время работы в сфере аналитики я успел побывать в разных ролях: бизнес-аналитик, веб-аналитик, дата-инженер, дата-аналитик, BI-аналитик, тимлид. Поэтому на личном опыте понимаю, как выглядит в бизнесе вся цепочка обработки данных от потребности до выводов.

Уверен, что мой опыт поможет студентам привязать полученные знания к реальным бизнес-задачам из деловой жизни!

‼️Новый поток курса-симулятора «Аналитик данных» стартует уже в сентябре. А до 12 сентября на курс действуют ранние цены -25%.

➡️ Узнать подробнее и забронировать место на потоке

О значимости времени и стандартов

Всем привет! На связи Георгий Семенов, Chief Data Officer и ментор нового потока курса «Инженер данных».

Давным-давно, еще в доковидные времена, нам понадобилось настроить сбор ежедневных статистик наших мобильных приложений из личного кабинета Apple Developer.

Настроили импорт через API — миссия выполнена. Но не тут-то было. Данные не сходились с другим источником, который мы использовали для учета установок и сессий приложений (Appsflyer).

Довольно быстро выяснили, что Apple отдает даты в таймзоне Pacific Time, который меньше UTC на 7 часов летом и на 8 зимой, тогда как мы всегда использовали UTC. Сейчас Apple уже умеет в UTC, но тогда это стало для нас проблемой, ведь мы не могли сверить свои финансовые и продуктовые отчеты. Хорошо, что нам было с чем сверять. Иначе ошибка могла пройти незамеченной — и такое случается.

А ведь большинство табличных данных — это time-series.

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

И да — для этого недостаточно указать дефолтную timezone в настройках вашей Базы Данных.

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

И дело не только во времени. Другие поля (идентификаторы, денежные суммы, категории и прочее) часто имеют в разных источниках разные названия, типы данных и форматы значений даже для одних и тех же реальных объектов. Все это серьезно осложняет задачу получения ценности из данных.

Во многом, именно поэтому считается, что 80% работы аналитика — это очистка и подготовка данных. Но качественная работа архитекторов и инженеров данных может в несколько раз упростить аналитику жизнь.

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

Структура вашего хранилища должна быть максимально понятной. Чтобы ваши коллеги даже без обращения к документации понимали где какие данные искать.

И что, например, поле business_dttm во всех time-series таблицах является первичным ключом партиции и имеет тип timestamp с таймзоной UTC, а колонка product_id во всех таблицах означает одну и ту же сущность (по крайней мере, в рамках одного бизнес-домена, но это уже отдельная история).

Так они совершат меньше ошибок и зададут вам меньше вопросов. Особенно, если среди них есть неискушенные бизнес-пользователи, а у вас self-service BI.

⁉️ Так как же мы решили этот кейс?

Поскольку date, в отличие от datetime, нельзя конвертировать в наш стандартный часовой пояс, то надо явно дать понять пользователю о нестандартной ситуации. И если мы называли поле с датой business_date, то это назвали business_date_pacific_time.

💬 А как бы сделали вы? Пишите в комментариях)
И если у вас были похожие истории — тоже обязательно поделитесь!

Уже через пару часов встречаемся на вебинаре! Приходите, буду рад всех видеть 🧡

Обсудим:
😶Какие навыки нужны для работы в ДЕ
😶Необходимые скиллы для прохождения собеседования
😶Ситуацию на рынке со стороны нанимателя: компании, грейды и зарплаты
😶Пути развития дата инженера

➡️ Зарегистрироваться на вебинар

Привет! На связи Павел Беляев — автор канала Тимлидское об аналитике и ментор курса «Аналитик данных» 👋

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

Ценность аналитики заключается в том, что представитель бизнеса может принимать решения на её основе.

А для этого данные следует прогнать через несколько процессов и стадий. Я называю этот путь конвейером данных.

Конвейер данных включает в себя следующие основные этапы:

1️⃣Формирование вопросов

Сначала определяется потребность в информации, подбираются метрики и методы анализа, а также составляется перечень необходимых данных.

2️⃣Сбор данных

Сырые, необработанные данные собираются из источников в аналитическое хранилище (АХ), где и производится всяческая аналитическая «магия».

В качестве АХ могут использоваться различные системы управления базами данных (СУБД), например, Clickhouse или PostgreSQL.

Запросы к СУБД выполняются на языке SQL. А процессы сбора и транспорта данных осуществляются специальными инструментами, например, Airflow, который «дирижирует» Python-скриптами.

3️⃣Преобразование данных

Сырые данные «готовятся», а блюдом являются витрины данных: таблицы, содержащие отфильтрованные строки, рассчитанные метрики, сгруппированные сегменты и прочие результаты реализации бизнес-логики.

С данными производятся операции фильтрации, объединения, расчета, приведения к нужному виду и т.д. Обычно для этого используются языки SQL или Python.

4️⃣Визуализация

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

Визуализация делается с помощью соответствующих инструментов: Power BI, Data Lens, Looker Studio, Metabase и др.

5️⃣Анализ

Собственно, процесс изучения, осознания ситуации, а также формирования выводов, ответов на поставленные вопросы.

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

6️⃣Решение

На основе выводов решается —достигнуты ли цели, что делать дальше, работает ли новая фича и т.п.

Путь данных весьма насыщен приключениями и этим он интересен!

Курс «Аналитик данных» достаточно комплексно составлен и затрагивает все эти этапы, чем меня и впечатлил.

❗️И напоминаю, что до 12 сентября у вас есть возможность попасть на курс со скидкой -25%. Успевайте ей воспользоваться и желаю успехов в аналитике, коллеги!

➡️ Узнать больше о курсе и забронировать скидку

Задумываетесь о том, чтобы стать инженером данных?

На последнем вебинаре мы как раз обсуждали самый актуальный стек дата-инженера. А ещё выяснили, зачем инженеру данных нужен Python для анализа данных и сделали небольшой обзор на наш курс-симулятор «Инженер данных». Спойлер, программа Георгию, спикеру вебинара, понравилась!

Оставляем вам саму интересную часть записи для всех, кто не успел посмотреть вчерашний эфир в live-формате:

😶Смотреть в YouTube
😶Смотреть в ВК

‼️Кстати, сегодня последний день, когда действуют ранние цены на поток курса «Инженер данных» с Георгием Семеновым, Chief Data Officer ex VK, Wildberries, СТС, ЦУМ, ВТБ — поэтому если вы думали об обучении, советуем больше не откладывать!

➡️ Оставить заявку на курс

⚡️Что должен уметь хороший аналитик данных: взгляд тимлида из Яндекс eLama

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

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

Всё это мы обсудим уже в следующий вторник на вебинаре с Павлом Беляевым, руководителем команды аналитиков в Яндекс eLama, а также автором телеграм-канала «Тимлидское об аналитике».

Павел регулярно нанимает аналитиков в команду, поэтому поделится с нами качествами, на которые обращает внимание при отборе кандидатов.

На вебинаре обсудим:
🟠Как и для чего используются в реальных бизнес-задачах SQL, Python, Airflow;
🟠Какие хард- и софт-скиллы ждет от своей команды тимлид;
🟠Чем занимаются аналитики в eLama и как выглядит типичный рабочий день.

❗️Встречаемся 9 сентября в 19:00 МСК

💬 Обязательно ждем вас в лайве – вы сможете напрямую задать свои вопросы Павлу Беляеву и получить консультацию крутого практика.

➡️ Регистрация на вебинар

🔥 Проектируем хранилища данных с нуля

Спроектированное DWH — основа качественной аналитики, точно также, как и инженер данных — незаменимый игрок любой в DS-команде.

Чтобы заложить фундамент для одного из важнейших скиллов инженера данных, приходите 11 сентября на следующий вебинар от Георгия Семенова, Chief Data Officer и ментора нового потока курса «Инженер данных».

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

🟠Зачем нужны хранилища данных;
🟠Какие есть технологии хранилищ данных;
🟠Как выбирать и выстраивать модель данных;
🟠Как доставлять и обрабатывать данные;
🟠Как делать данные качественными и доступными.

❗️Встречаемся 11 сентября в 19:00 МСК

➡️ Регистрация на вебинар

Привет всем! На связи Павел Беляев — ментор курса «Дата аналитик», тимлид аналитиков в Яндекс eLama и автор канала «Тимлидское об аналитике». 👋

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

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

1️⃣Формулировка требований

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

Они могут выразить интуитивное желание получить некую ясность, а вам придется помочь им облечь его в конкретные метрики и продумать, как их вычислить. Это потребует от вас некоей «эмпатии», умения интервьюировать, и, конечно, знания метрик.

2️⃣ Качество данных

Причин недостоверности данных много: технические, организационные, человеческие... Конвейер длинный — на каждом шагу может что-то пойти не так.

Например: пользователь накосячил с вводом, отвалилось API третьестепенных данных, на которых, внезапно, завязаны расчеты, кто-то что-то закостылил, а аналитикам не сказали — всё это требует постоянного неустанного слежения за качеством данных, желательно автоматического.
Поэтому полезно завести привычку «ничему не доверять и постоянно всё проверять».

3️⃣ Техническая реализуемость

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

Бывает, что заказчики прямо фонтанируют идеями — громкими, но сомнительными. Я не сторонник того, чтобы «обламывать» такие порывы. Но долг аналитика — выслушать, оценить, внести коррективы, которые позволят исполнить более удобное или недорогое решение.

4️⃣ Внезапные изменения в источниках

Работа аналитиков сильно завязана на источниках данных: база данных, сторонние сервисы и др. Если база данных находится в ведении других команд (у разработчиков приложения, например), то нужно иметь в виду, что у них свои цели и процессы. Вы им не нужны, это они вам нужны 🙂
Из-за этого они могут просто забыть сообщить вам, что, например, у них изменилась структура таблицы, которую вы привычно тянете, или что база вовсе переезжает, причем, послезавтра.

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

5️⃣ Как себя проверить?

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

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

6️⃣ Как это работает?!

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

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

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

В общем, будни дата-аналитика — штука весёлая. И всё же, в эту сферу войти проще, чем в хардкорное программирование.
Начать свой путь до оффера в аналитике можно после обучения на курсе-симуляторе «Аналитик данных», где я буду вашем ментором. Узнать больше о курсе можно по по ссылке.

🧡 А я жду вас завтра на вебинаре, где расскажу о задачах, инструментах и навыках, необходимых и желательных для дата-аналитика.

😶 Если не успели зарегистрироваться, то сейчас самое время!

Привет! На связи снова Павел Беляев, тимлид группы аналитиков в Яндекс eLama и ментор курса «Аналитик данных» 👋

Основная задача моей команды — разрабатывать и поддерживать витрины данных. Желательно, чтобы было быстро и качественно. Делюсь с вами своей статьей, в которой описал 7 лайфхаков SQL, которые мы с командой используем на реальной практике.

❗️И напоминаю, что уже сегодня, в 19:00 жду вас всех на вебинаре, где расскажу, что должен уметь хороший аналитик.

А ещё подробно разберём эти темы:
🟠Как и для чего используются в реальных бизнес-задачах SQL, Python, Airflow;
🟠 Какие хард- и софт-скиллы ждёт от своей команды тимлид;
🟠 Чем занимаются аналитики в eLama и как выглядит типичный рабочий день.

‼️Важный момент: запись и материалы вебинара будут доступны только тем, кто зарегистрируется. Но я очень жду вас в лайве, чтобы ответить на ваши вопросы!

➡️ Регистрация на вебинар

🧡 Друзья, уже через пару часов, в 19:00 МСК, ждём всех на вебинаре с Павлом Беляевым.

Тема: Что должен уметь хороший аналитик данных: взгляд тимлида из Яндекс eLama

😶 Зарегистрироваться

‼️ Вебинар с Павлом Беляевым переносится

Друзья, к сожалению, у нас возникли технические неполадки.

Сегодняшний вебинар переносится на завтра, так же в 19:00 МСК.

Приносим извинения и будем очень рады видеть вас всех завтра!

Ссылка на подключение придёт завтра от бота.

Привет! Это Павел Беляев, тимлид группы аналитиков в Яндекс eLama и ментор курса «Аналитик данных».

Продолжаю делиться лайфхаками SQL и сегодня принёс ещё шесть! В статье рассказал, как посичтать важный фин. показатель — ARPPU, сегментировать новых и старых пользователей, построить простейший отчет-воронку и еще несколько интересных приёмов.

😶 Читать статью

Сегодня на вебинаре как раз поговорим про SQL а ещё Python и Airflow — как и для чего используются в реальных бизнес-задачах эти инструменты.

Ещё поделюсь секретами рабочего дня группы аналитиков из Яндекс eLama и расскажу про свой подход к найму сотрудников в команду.

✨ Приходите, будет классно и полезно!

Всем привет! На связи Георгий Семенов, Chief Data Officer и ментор курса «Инженер Данных» 👋

На заре карьеры довелось мне участвовать в постройке маленького локального хранилища данных. Подняли Clickhouse, настроили ETL в Airflow. Всё круто. Но через пару месяцев пришлось пересобирать хранилище заново.

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

Во-первых, при выборе технологии (Error #1). Хайпанули. Clickhouse нам не очень подходил. С одной стороны, мы теряли ACID, функциональность внешних ключей и контролировать согласованность данных приходилось самостоятельно. С другой стороны, мы особо не использовали основное преимущество OLAP Clickhouse — колоночное хранение, т.к. объемы данных ожидались небольшие, а для них подойдет и OLTP с индексами.

Во-вторых, при проектировании модели данных (Error #2). Мы очень плохо понимали предметную область. Каждая таблица загружалась нами как независимая, без какой-либо нормализации и осознания, что с этими данными будут дальше делать. В данных постоянно встречалась несогласованность. Аналитики пытались справляться с этими проблемами на своем уровне, тогда как лучшая практика — приводить это в порядок на уровне хранилища.

В-третьих, при написании кода пайплайнов (Error #3). Было много самоповторов. Но это можно было отрефакторить, не пересобирая хранилище, если бы не первые 2 ошибки.

Но в этой бочке дегтя была одна ложка мёда — мы сохраняли сырые данные!
Бережно складывали их неподалёку, в файловой системе (не object storage, но хоть так).

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

❗️О том как не допускать элементарных ошибок, мы поговорим уже сегодня, 11 сентября, в 19:00, на бесплатном вебинаре «Проектируем хранилища данных с нуля».

➡️ Регистрация на вебинар

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

Жду ваши ответы в комментариях)