Какие бывают аналитики. Часть 2

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


1) сбор данных (SQL, Big Data-хранилища, API различных продуктов, логи и т.д.);

2) очистка и структурирование собранных данных;

3) проверка гипотез и нахождение решений поставленных задач с помощью (сюрприз-сюрприз) анализа данных, математики и в частности статистики, а также, возможно, инструментов и методов машинного обучения;

4) представление и визуализация результатов, например, в Excel/Гугл-таблицах или создание отчетов и дашбордов в BI-инструментах.


Продуктовый аналитик. Как и со многими пунктами в этой классификации, невозможно обозначить четкие границы той или иной специальности. Можно сказать, что продуктовый аналитик - это вышеописанный аналитик данных, но специализирующийся на более узком круге продуктовых задач. Это влечет за собой необходимость разбираться в смысле и влиянии на продукт кучи терминов и аббревиатур, за которыми скрываются основные продуктовые метрики (LTV, Churn rate, Retention rate, DAU/WAU/MAU, NPS, Conversion rate - и кучи других), владеть методиками проведения и расчета результатов АБ-тестов и работать в тесном сотрудничестве с product-командой.



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


Естественно, данная классификация строится исключительно на личном опыте автора. В каких-то компаниях (как правило, очень больших) Аналитики данных и Data Scientist-ы не занимаются сбором и структурированием данных. На себя этот объемный и значительный кусок работ берут Дата-инженеры, организующие сбор, очистку, перемещение и хранение подготовленных данных (ETL-процессы). Нет в этой статье Финансовых аналитиков, Инвестиционных аналитиков и прочих, так как это специалисты радикально иного профиля

К каналу подключен чат. Начиная с этого поста появится возможность обсуждать там все, что душе угодно )

Разбор задачи SQL №1

#SQL_trainer1

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

Что будет по теме SQL далее на этом канале? Я возьму сайт-тренажер (на всякий случай, это не реклама, если она когда-либо в будущем и будет, то это будет явно отмечено), и пойду по порядку заданий от элементарнейших к сложным, попутно объясняя нюансы запросов и проектирования БД. Преимущество этого тренажера в том, что писать запросы и получать результаты могут даже незарегистрированные юзеры. Правда, я в нем до этого ничего не делал, но на первый взгляд все довольно наглядно.

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

Задача 1 про пассажиров авиакомпаний. Есть вот такая структура в БД, состоящая из 4-х таблиц,

Задача - Вывести имена всех когда-либо обслуживаемых пассажиров авиакомпаний.

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

Таблица Trip содержит общую информацию о рейсах, Pass_in_trip - о пассажирах на конкретном рейсе, Company содержит наименования авиакомпаний и, наконец, Passenger - имена пассажиров.

Такие структуры баз данных могут рассказать не только состав полей в таблицах и связи между ними: например, по иконке ключика около полей id можно сделать вывод о том, что поля id являются первичным ключом (PRIMARY KEY) этих таблиц, а это в свою очередь означает, что поля id уникальны. То есть в таблице Passenger один пассажир не встретится более одного раза. Такие нюансы важно понимать при анализе БД и последующих запросах, т.к. они напрямую могут повлиять на результат.

Задача - Вывести имена всех когда-либо обслуживаемых пассажиров авиакомпаний. Это, очевидно, осуществляется самым элементарным запросом к БД:

SELECT name FROM Passenger

При этом нужно отметить, что по условию не до конца понятно, если есть два разных пассажира (с разными id) по имени Ivan Ivanov, в результате должно быть две строки Ivan Ivanov или одна? Запрос выше выдаст две строки.

Следующий запрос может вывести только уникальные значения имен пассажиров:

SELECT DISTINCT name FROM Passenger

[DISTINCT позволяет получить список из уникальных значений]

Но все-таки задача в том, чтобы вывести имена уникальных пассажиров, а не уникальные имена пассажиров, поэтому используем первый запрос SELECT name FROM Passenger. А вообще заказчикам нужно ставить задачи без возможных двойных толкований )

Сколько зарабатывают аналитики данных?

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

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

1. Интересные задачи. Сортировка данного списка, конечно, предполагает логику "от более важных к менее важным", но, во-первых, (как и все здесь) эта сортировка сугубо субъективна, а во-вторых, отсутствие хотя бы одного из факторов нивелирует наличие других. Так вот, интересные задачи - они в аналитике данных, несомненно, важны. Если вакансия предлагает попробовать себя в каждодневном составлении регулярной отчетности по строго обозначенному шаблону - это точно не работа мечты. Очень круто, когда компания предлагает поучаствовать в разработке принципиально нового продукта. Хорошо, если появляется шанс стать автором чего-то нового на своей небольшой вотчине и проявить свои креативные амбиции, будь то разработка и внедрение ML-модели, проведение сногсшибательного исследования, разработка самого невероятного отчета в BI и далее по списку. Понятно, что рутина и каждодневная операционная деятельность есть везде, но если несколько раз в месяц вы чувствуете, что сами искренне хотите что-то сделать, не замечаете, как проходят рабочие дни и засыпаете с мыслями о проекте - вы на нужном месте.

2. Уровень зарплаты. Ну от этого все-таки не уйти ) Но тактика "где предложат больше - там я" со стороны аналитика будет крайне опрометчивой, думающие люди (коими в большинстве случаев являются представители профессии) понимают, что всегда можно найти компанию, где предложат на 10-20% больше. В краткосрочной перспективе это принесет выгоду, но в долгосрочной - сомневаюсь. Человек, который по полгода работает в каждой компании и уходит, так толком и не завершив ни один большой проект, у меня никогда бы не вызвал доверия.

3. Команда и структура процессов в компании. Это особенно важно начинающим аналитикам, т.к. от команды в широком смысле - и от руководителя, и от коллег, и от наставника, и от того, насколько четко все понимают обязанности друг друга - сильно зависит скорость развития и правильность направления этого развития. Если в компании сильная команда Дата-саентистов, которые обеспечены ресурсами и инфраструктурой, то придя на позицию начинающего DS, вы в рабочем процессе в короткие сроки получите тонну полезного и правильного опыта. Если в компании только зарождается работа с ML и никто еще толком не понимает, что это такое и с чем его едят, идти туда на начальных этапах не стоит.

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

5. Чувство значимости и пользы от работы. Это касается как конкретно вашей работы как аналитика, так и компании в целом. Несомненно, приятнее чувствовать себя частью компании, которая несет какую-либо пользу. Ох, вечереет уже, абзацы становятся все короче )

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

К чему все эти пункты? Я хочу донести мысль, что предложение о работе нужно рассматривать не только по уровню вознаграждения, а комплексно. Разница в 10-20% может с лихвой компенсироваться другими ценностями.

Теперь непосредственно о зарплатах

Тема сложная, не только потому что чувствительная для каждого, но и потому что в разных регионах, в разных сферах и разных компаниях цифры могут различаться в разы. В банках - больше, где-то - меньше. Работа в офисе, как правило, дороже, удаленка - дешевле. Поэтому приведу примерные вилки, на которые сам ориентируюсь и при найме сотрудников и при оценке своего положения на рынке. А, да, в данном конкретном случае речь о Москве, прошу извинить, другого опыта у меня не было. Тут стоит добавить, что особенно в последний год удаленную вакансию аналитика найти можно, находясь не то что в любом городе России и СНГ, но и в любой точке мира.


Стражер-аналитик данных (0 опыта, студент, выпускник) - 0-50 т.р.

[Списки в скобках не стремятся показать все зоны ответственности аналитиков, они очень примерные и приведены для наглядности различий]

Junior-аналитик данных (небольшой опыт или нет опыта, но есть теоретическая база, умеет писать простые запросы в SQL, делить, умножать и, возможно, считать производную сложной функции, самостоятельно решает простые задачи) - 50-90 т.р.

Middle-аналитик данных (опыт 1г и более, отлично владеет SQL, на хорошем уровне владеет Питоном, есть опыт работы с BI-инструментами, самостоятельно решает задачи средней сложности) - 90-150т

Senior-аналитик данных (опыт 3г и более, отлично владеет SQL, отлично владеет Питоном, есть опыт работы с BI-инструментами, опыт работы с инструментами Big Data, опыт настройки ETL-процессов, сильная математическая база, решает все задачи без помощи сверху, автономная единица) - 150-250т

Senior-аналитик с опытом ML (то же что и сверху, но есть опыт разработки и доведения до продакшена моделей машинного обучения) - 200-300т


Цифры, повторюсь, могут отличаться. Но на сегодняшний день такие коридоры мне лично кажутся адекватными и соответствующими рынку. Абсолютно не исключаю, что я ошибся в каждом пункте, и все совсем не так, если это случилось - буду рад вашим комментариям )

Ключевой навык аналитика данных (и не только)

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

Парадокс этого навыка в том, что чем больше опыта приобретает человек, тем больше вероятность утратить этот навык. А навык простой - говорить "Я этого не умею/я это не знаю".

Нужно отчетливо понимать, что опыт каждой компании и каждого человека субъективен и уникален. И нет никакого стыда в том, что там, где человеку пришлось работать, не было Hadoopa и, соответственно, нет опыта работы с ним.

Например, так вышло, что там, где работал/работаю я, аналитики данных и даже веб-аналитики никогда не ставили цели в Яндекс Метрике, эта задача была в зоне ответственности продакт-менеджеров. И совершенно ничего страшного нет в том, что я это не умею. А еще я не работал в Apache Spark, никогда не видел интерфейс Qlick BI и, о господи, плохо разбираюсь, как работает Slack. Главное, что я уверен, что при необходимости освою все инструменты/методики/формулы, которые необходимы для решения конкретной задачи в отдельно взятой компании.

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

Разбор задачи SQL №3

#SQL_trainer2

Напомню, что в одной из предыдущих статей я начал разбирать задачи из этого онлайн-тренажера. Тренажер содержит 66 задач, но разбирать их по-порядку я не буду, какие-то буду определенно пропускать. Так, Задача №1 и Задача №2 не отличаются ничем, кроме таблицы, к которой происходит запрос. Поэтому сразу перепрыгиваем на третье упражнение.


Сегодня разберем задачу №3. Вывести все рейсы, совершенные из Москвы.

Где искать рейсы? Думаю, в таблице Trip. Рядом с постановкой задачи в тренажере есть подсказка "Поля в результирующей таблице: *". Значок * означает "все поля". Давайте рассмотрим структуру самого простого SQL- запроса (вывести набор полей из таблицы с условиями) :

SELECT

поле1,
...
полеN
[если нужны все поля, то перечисление заменяется значком *]

FROM table

WHERE

условие1 AND/OR
...
условиеN

По условию задачи необходимо вывести все рейсы из Москвы. Очевидно, пункт отправления лежит в таблице Trip в поле town_from. Но как нам узнать, как в этой таблице обозначается Москва? Может, "moscow", может, "MOS" или "msc"? Один из способов - написать простой запрос к таблице Trip и найти там Москву:

SELECT * FROM Trip LIMIT 10

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

Видим, что Москва в поле town_from имеет значение "Moscow"

Полдела сделано, осталось написать запрос, чтобы Вывести все рейсы, совершенные из Москвы.

SELECT *

FROM Trip
WHERE

town_from = 'Moscow'

Разбор задачи SQL №4

#SQL_trainer3

Продолжаем цикл статей, обозначенный хештэгом #SQL_trainer, с разбором задач из онлайн-тренажера. На очереди четвертая задача, в рамках которой познакомимся с оператором LIKE.

LIKE позволяет искать данные в таблице по вхождению подстроки в строку. Допустим, в таблице Passenger есть значение "Ivan Ivanov", которое мы пытаемся найти. Как его найти?

Если мы точно знаем, что ищем, все просто: SELECT * FROM Passenger WHERE name = 'Ivan Ivanov'

Если мы помним только начало, то нам поможет LIKE: SELECT * FROM Passenger WHERE name LIKE 'Iva%'

Если помним только конец: SELECT * FROM Passenger WHERE name LIKE '%vanov'

Помним серединку - не беда: SELECT * FROM Passenger WHERE name LIKE '%van Ivan%'

Вот блин! Забыли одну букву - то ли "Ivan Ivanov", то ли "Lvan Ivanov", LIKE и тут выручит: SELECT * FROM Passenger WHERE name LIKE '_van Ivanov'

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

Задача - Вывести имена людей, которые заканчиваются на "man". Никаких сложностей не видно: SELECT name FROM Passenger WHERE name LIKE '%man'

Разбор задачи SQL №5

#SQL_trainer4

Продолжаем цикл статей с разбором задач из онлайн-тренажера. На очереди пятая задача.

В SQL, помимо прочего, работают многие операторы, знакомые каждому школьнику с уроков информатики - SUM, COUNT, AVG, MIN/MAX, ROUND, ABS и прочие.

В пятой задаче нам как раз потребуется оператор COUNT для того, чтобы вывести количество рейсов, совершенных на TU-134.

Для начала, как и в предыдущей задаче, найдем обозначение TU-134 в таблице Trip с помощью запроса SELECT * FROM Trip LIMIT 10.

Никаких сюрпризов. Нужный нам самолет обозначен банально 'TU-134'. Нужно обратить внимание, что в задаче просят, чтобы результирующее поле носило имя count, что достигается использованием конструкции AS в блоке SELECT. Поэтому результирующий запрос будет таким: