КАК НАЗЫВАЕТСЯ DS DA И SAC ЧТО ОТЛИЧАЕТ ИХ ОТ ДРУГИХ ВИДОВ АНАЛИЗА

Опыт работы с данными или с чем может столкнуться аналитик

Время на прочтение

В этой статье хотелось бы погрузить вас в мир данных и вспомнить:

Но вначале придется разобрать извечные вопросы: кто же такие аналитики, что такое данные и понять – должны ли они быть вместе?

Вопрос 1: Кто такие аналитики?

Аналитик – это специалист по изменениям.

Любое изменение должно быть осмыслено.

Долго искала это определение для себя и вот несколько причин почему оно мне нравится:

В моем случае все сошлось: люблю осмысливать свои данные (и чужие тоже, если предоставляется такая возможность) и считаю, что анализ данных (АД) – это равноценная область, наравне с бизнес-анализом (БА) и системным анализом (СА).

Бизнес анализ – исследование изменений системы, чаще всего результатом является процесс. Отвечает на вопрос “Что делать?”.

Системный анализ – проектирование изменений системы – то есть результат, некий конечный продукт. Отвечает на вопрос “Как делать?”.

Анализ данных – неожиданно, но это анализ данных, образующихся в процессе работы системы. Отвечает на вопрос “Что происходит?”. Результатом нашей деятельности будет поток. Важно понять, что это не конечный фиксированный продукт, это не процесс, который когда-либо заканчивается, а это именно постоянно меняющийся поток.

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

Вопрос 2: Что такое данные?

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

Характеристик очень много, но рассмотрим наиболее  часто встречаемые и что будет, если их не обеспечить:

Вопрос 3: Какие встречались проекты, связанные с хранилищами и данными?

Небольшое отступление. Проект – это командная работа, и даже если написано “проработка архитектурных схем”, это значит, что аналитик мог быть участником архитектурного комитета и брейнстормить, предоставлять “черновые” модели или согласовывать их. Это не значит, что он полностью берет на себя роль архитектора, тем не менее вышеназванную задачу он решает. То же самое с написанием скриптов или запуском ETL-процессов.

Перетекающие данные

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

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

Неубиваемые данные

Мне нравится такое сравнение: “Данные – почти как люди. Они рождаются, взрослеют, женятся. Только не умирают – их убивают.” Не всё так печально: на самом деле никто на моей практике никогда не убивал данные, потому что люди уже вложили ресурсы в их сохранение и преобразование и удалять их – невыгодно. Чаще всего их архивируют. Иногда из них выделяют более эффективные легковесные данные, которые при этом также информативны. На некоторых ресурсах такие данные называют Smart Data. Старые сырые родители, извините, в дом архивирования, пожалуйста. Вы уже не так ценны.

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

Температура данных

Иногда сложно понять, кто в данных старый и редко используемый, а кто – молодой и полезный. Тут по паспорту не посмотришь и по времени создания тоже. Например, есть название компании, которое мы давно сохранили, но используем каждый день. А есть вчерашний прогноз погоды, который никто не захочет еще раз перечитывать.  Для таких случаев существует показатель: температура данных. Горячие данные хранятся в оперативном хранилище – они должны максимально быстро изыматься, затраты на их хранение большие. Холодные данные можно хранить дешево, но время доступа к ним будет увеличиваться.

К сожалению, какой-то обобщенной формулы для определения температуры нет. Бывают подобные проекты по настройке процесса очистки хранилищ от холодных данных. Работа аналитика – понять ту индивидуальную формулу, относительно которой будет происходить разделение и сохранение данных в максимально эффективных для них условиях.

Расселение данных

В распределенных системах есть такие процессы как:

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

Нереальные данные

Следующая тема – виртуализация данных, и при первом слове DevOps-ы начинают активно шевелиться :). Успокоим их, так как у нас несколько другая история. Виртуализация данных – представление данных в абстрактном виде, независимо от систем управления и хранения данных, а также их структуры.

То есть обычный проект – 30-50 источников, которые физически хранятся в разных местах и в разном виде. Обычно всем предлагают мигрировать или реплицировать данные в единое хранилище. Долго, дорого, требуется столько же узконаправленных специалистов, сколько у вас разных систем. В какой-то момент, видимо, кому-то это надоело и предложили просто создать виртуальную модель данных и подтягивать к ней все необходимые данные из источников. Аналитик заходит в таблицу «Клиент” и работает с множеством  записей и ему совершенно необязательно знать, что часть этих записей система подтянула из Oracle, а часть пришла из озера данных на Hadoop или (никогда так не делайте) из файла на рабочем столе бухгалтера. Просто нарисуйте удобную модель  для аналитиков (при этом  каждому можно предоставить доступ только к нужной ему информации) и найдите в команде администратора системы виртуализации, который настроит для вас поступление данных.

Начальные навыки аналитиков для работы в подобных системах – это понимание логической модели данных и SQL.

Экспертиза данных

Тема профилирования, качества данных – актуальна на всех проектах, потому что иногда  приходят подозрительные или усеченные данные  в виде “скелета”. Тут кроме стандартных характеристик, таких как полнота, согласованность, актуальность, доступность и прочее, важно определить еще и бизнес-метрики от заказчика. К ним могут относится, например, лимит на определенную финансовую операцию или ограничения на диапазон значений. Такая экспертиза поддерживается постоянно, есть целые системы мониторинга, на которых отображаются критичные для заказчика метрики. При стандартных подходах помогут знания специальных инструментов DQ иили языки для анализа данных (Python, R, SQL), иили BI инструменты для визуализации.

Поддельные данные

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

Обогащение данных

Прежде чем использовать данные, сначала их профилируют и анализируют. После этого, возможно, выгодно их “обогатить”. Обогащение – процесс изменения сырых данных с целью увеличения ценности.

Изменения могут быть такими:

Тут аналитику помогут базовые знания статистики и знание инструментов для профилированияанализа данных (Python, R, SQL).

Вопрос 4:  Нужны ли друг другу данные и аналитики?

Много интересного сейчас творится в данных и есть где развернуться аналитику: искать унифицированные подходы, прорабатывать процессы, создавать регламенты работы с данными и многое другое. Не хватает синхронизированных определений, базовых методик, методологии работы с данными. Безусловно, стек технологий огромный и каждый день появляются интересные инструменты. Но для вхождения приветствуется SQL, базовые понятия типов и способов хранения данных, также не помешают и основы статистики. Это настолько “горячая” тема, что опыт работы с данными сделает аналитика более ценным сотрудником. Поэтому призываю к тому, что данные и аналитики должны быть вместе.

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

Автор статьи: Татьяна Половинкина, аналитик в компании Neoflex.

Привет, Хабр! На связи отдел аналитики данных X5 Tech.

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

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

Поэтому вопрос «Так кто же такой этот ваш дата-аналитик?» мы слышим часто и хотим сегодня об этом поговорить.

Цель данной статьи — ответить на вопросы:

Что ожидается от разных ролей в Data Science?

Для того чтобы разобраться в этом вопросе, обратимся к известной условной концепции деления ролей в DS:

MLE — Machine Learning Engineer, специалист по работе с моделями машинного обучения. От него, как правило, ожидается:

Помимо разработки, от MLE специалистов ждут:

DE — Data Engineer, специалист по внедрению продуктивных аналитических решений. От таких специалистов ожидается умение обеспечить работу технических компонентов продукта (регулярный расчёт продуктовых витрин, корректный обмен артефактами между компонентами системы, логирование, мониторинг и т.д.), которая будет бесперебойной, оптимальной и укладываться в SLA.

DA — Data Analyst, специалист по анализу данных. Иными словами, это специалист, который обладает следующими группами навыков:

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

Задачи DA в X5 Tech

Если попытаться структурировать деятельность дата-аналитиков в X5, то можно выделить 4 области.

Продуктовая аналитика

Эта область особенно актуальна на этапе зарождения продукта, когда в продукте ещё отсутствует сложившаяся практика работы с данными, а решения принимаются на уровне бизнес-экспертизы. Эти задачи включают:

Машинное обучение

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

Дата инженерия

Периодически каждому дата-аналитику встречаются задачи, где необходимо добыть данные, преобразовать их, обогатить из других источников. Поэтому мы ждём от своих сотрудников, что они могут самостоятельно подготовить продуктовую витрину для своих исследований, гипотез, моделей. В этом случае используется традиционный арсенал инструментов аналитика Python/SQL (или PySpark, мы писали об одном способе организации проекта на PySpark).

Продуктивный код

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

Таким образом, деятельность аналитиков в X5 может быть достаточно обширна. Это подводит дата-аналитика к возможности как углубляться в экспертизу в направлении DATA/ML-инженерии, так и развиваться в сторону бизнес-экспертизы и менеджмента.

Матрица компетенций и должностные обязанности

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

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

Наконец, приведём компетенции, которые соответствуют потребностям продуктов в X5. Для удобства развернём матрицу в виде списка по уровням Junior/Middle/Senior.

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

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

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

Помимо набора компетенций, разным грейдам соответствуют разные зоны ответственности. Распределение таких зон в отделе аналитики X5 представлено ниже:

Данная схема используется для определения должностных обязанностей. Отметим, что на практике может случиться так, что Senior выполняет задачи Middle/Junior, если в команде ещё нет этих ролей. А вот если Junior занимается задачами Senior, то это значит, что состав команды определён неверно.

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

Связь с наймом

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

И в начале, хотелось бы привести список проблем найма, с которым столкнулись мы на своей практике.

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

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

Масштабируемость. Исходя из информации первого пункта, становится понятным, что компетентных в проведении собеседования «от А до Я» сотрудников будет немного. Эта малочисленность приводит к проблемам, когда потребности продуктов резко возрастают и нужно проводить волны найма, или необходимо обработать большое количество кандидатов на стажировку/обучение.

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

Подводя итог вышесказанному, есть две основные задачи, которые нужно решить:

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

Теперь давайте разберёмся со сложностью оценки тех или иных критериев. Глобально критерии оценивания можно разделить на две области:

1. Базовые технические навыки, мышление.

2. Опыт, креативность, soft-skills.

Для оценки первой части не требуется глубокого знания процесса проведения собеседований, и они поддаются автоматизации. При наличии банка задач и вопросов, а также возможных вариантов ответов, к такой оценке можно привлекать людей без длительного процесса подготовки. Главным критерием является наличие соответствующих технических навыков у самих собеседующих. При этом первый этап может значительно сузить воронку путём отсева людей, недотягивающих по необходимым навыкам для конкретной позиции. Например, это может быть Python/SQL или Python/математика и т.д.

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

Итак, процесс собеседований дата-аналитиков в X5 на момент написания статьи выглядит следующим образом:

Посмотрим, как такая схема собеседований и систематизация критериев помогают решить поставленные выше вопросы:

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

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

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

Затраты. Затраты на подготовку специалистов и «стоимость» интервью также существенно снижаются при наличии отлаженной системы найма.

Заключение

Итак, подведём итог вышесказанному и ответим на основной вопрос статьи.

Дата-аналитик в X5 Tech это специалист, который:

Главным образом, дата-аналитик — это специалист, который на неструктурированный запрос бизнеса может предоставить обоснованный ответ на основе данных и достаточно хорошее рабочее решение (по сути, решение 20-80).

Но напомним, что здесь идёт речь про DA именно в X5 Tech, в других компаниях от дата-аналитика могут ожидать другого.

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

Надеемся, статья была полезна, и будем рады дельным комментариям и замечаниям!

Над статьёй работали Антон Денисов, Никита Сурков, Юрий Исаков.