Симулейтив

⭐️ Уже сегодня: как ML-инженер учит компьютер находить смысл в тексте

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

Эфир подойдёт новичкам: предварительное погружение в ML не требуется!

📆 Сегодня, 29 сентября, 19:00 МСК

➡️ Не пропустить вебинар

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

Сегодня собираем ETL-пайплайн на данных GitHub — от источника до дашборда

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

Валерия Елпатьевская, инженер данных в Альфа-Банке, разберёт:

➖ Extract — как получить данные о репозиториях, коммитах и языках программирования;
➖ Transform — как их очистить и преобразовать;
➖ Load — как загрузить результат в локальную базу DuckDB;
➖ Как собрать из этого дашборд и какие выводы можно сделать по данным GitHub.

Пройдём весь пайплайн не в виде схемы на слайде, а через работающий код и конкретный результат — заодно разберём, чем рабочий пайплайн отличается от кода в одном Jupyter Notebook.

Эфир подойдёт тем, кто хочет познакомиться с Data Engineering, и аналитикам, которым интересно научиться самостоятельно собирать данные для анализа!

📆 Сегодня, 25 сентября, в 19:00 МСК
➡️ Не пропустить вебинар

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

Что происходит между вопросом бизнеса и готовым дашбордом?

Сегодня в 19:00 покажем этот путь изнутри на примере аналитического контура eLama.

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

Посмотрим на реальный стек в eLama: ClickHouse, PostgreSQL, Airflow, Python, SQL, DataLens и внутренние инструменты команды.

Эфир подойдёт новичкам, которые хотят понять, что ждёт их после трудоустройства, и действующим аналитикам, которым интересно сравнить свой подход с процессами внутри eLama.

📆 Сегодня, 23 сентября, в 19:00 МСК
➡️ Не пропустить вебинар

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

💻 Ошибки при использовании джоинов

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

🔑 Сохранение данных в приоритете

При написании запросов с джоинами, особенно с транзитивными связями, всегда задавайте себе вопрос:

❓ Какие данные мне важно не потерять?

Выбор правильного типа джоина имеет огромное значение, потому что неверный выбор может привести к некорректным результатам. Часто бывает так:

1️⃣ Вы выбираете джоин, который кажется логичным;
2️⃣ Вы не замечаете потенциальных проблем.

Давайте рассмотрим этот момент на примере:

SELECT *
FROM problem p
JOIN page p2
ON p.page_id = p2.id
JOIN company c
ON p.company_id = c.id

На первый взгляд, этот запрос кажется корректным, и результаты выглядят нормально. Однако если внимательно проанализировать, вы увидите, что множество записей из таблицы problem просто исчезли 😱

❓ Почему так произошло?

Что, если в таблице problem есть строки, в которых company_id = NULL? Тогда такие строки будут исключены из результата, ведь в таблице company поле id — первичный ключ и не содержит NULL.

❗️ Чтобы избежать потери данных, всегда помните о выборе правильного типа джоина:

SELECT *
FROM problem p
JOIN page p2
ON p.page_id = p2.id
LEFT JOIN company c
ON p.company_id = c.id

Используя LEFT JOIN, вы сохраните все записи из problem и соответствующие им записи из company, где problem.company_id=NULL, будут иметь пустые значения.

Помните об этом важном аспекте при работе с джоинами, чтобы получать точные и полные результаты! И ставьте 🔥, если было полезно!

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS

📌 Вызовы в работе аналитика данных

Привет! На связи Павел Беляев — автор канала Тимлидское об аналитике и ментор Симулейтив 👋🏻

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

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

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

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

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

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

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

Поэтому полезно завести привычку ничему не доверять и постоянно всё проверять.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

📈 Узнать больше о курсе

📈 Симулейтив | 📱 ВК | 📱 YouTube | 📱 Канал о DS