Кто такой Data Scientist. Обзор изнутри от Арсения Кравченко
dev.by запускает цикл материалов про ИТ-специальности. Каждую из них опишет «типичный представитель» — опытный специалист. Мы надеемся, что цикл поможет школьникам, студентам, переквалификантам, джуниорам и сочувствующим выбрать специальность в ИТ, оценить свои перспективы или просто сверить часы с авторитетным коллегой. Можно обсуждать и дополнять материал в комментариях, чтобы сделать его ещё полезней. Автор поддержит дискуссию и ответит на вопросы.
Сегодня представитель сообщества Open Data Science, ML инженер и автор Telegram-канала partially unsupervised Арсений Кравченко рассказывает про Data Scientist.
— Классическое полушуточное определение звучит примерно так: Data Scientist (далее DS) — это человек, который знает статистику лучше, чем средний software engineer, и умеет программировать лучше, чем средний статистик.
Это определение далеко не новое, достаточно правдивое, но недостаточно полное. И, чтобы как-то его расширить, я начну как раз со статистики.
Оценивая какую-то случайную величину, человек часто не может охватить все распределение и потому смотрит на какие-то ключевые агрегаты — среднее, медиану и так далее, и на основании этих данных уже делает свои выводы. Например, средняя зарплата в IT — $X в месяц, следовательно, быть айтишником довольно выгодно. Иногда агрегат выбран неверно, и выводы получаются странными (например, пресловутая средняя температура по больнице).
Если в вашем распределении есть ярко выраженное большинство (можно назвать такое распределение унимодальным, т. е. в нем одна мода), то несколько агрегатов вроде среднего, медианы, минимума и максимума довольно хорошо описывают такое распределение для понимания человеком. Но если распределение неоднородное, имеет несколько мод и вообще отличается высокой дисперсией, так легко отделаться не получится.
К чему вообще все эти рассуждения, которым место скорее в книжке «Статистика для младших школьников»? К тому, что довольно сложно объективно описать термин, под которым многие группы людей подразумевают какое-то свое представление (вот она, мультимодальность!). Но давайте попробуем и обозначим какие-то основные моды профессии.
Data Analyst / Аналитик
Большинство data science вакансий в Минске — это аналитик на стероидах. Обычно ожидается, что аналитик будет проверять гипотезы, извлекать информацию из слабо структурированных данных и доносить ее до коллег (иногда это означает необходимость делать ad hoc отчеты для менеджеров 90% рабочего времени).
Если такую позицию назвать data scientist, можно добиться нескольких эффектов:
- Показать, что от этого человека ожидается хоть какое-то умение программировать;
- Хайпануть («мы передовая компания, а не рядовая унылая галера!»)
- Убедить кандидата поработать на менее интересных ему условиях за модные слова в резюме.
Аналитик действительно должен уметь хоть как-то программировать, знать статистику, уметь разговаривать с людьми и хорошо понимать предметную область. Обычно аналитики нужны продуктовым компаниям, в том числе относительно небольшим.
Хороший аналитик в компании, где есть культура работы с данными — на вес золота, приносит много пользы, влияет на ключевые решения. В обратном случае, человек ковыряет эксельки в своем углу и унывает.
Такой человек может заниматься и машинным обучением, но обычно на это уходит меньшая часть его времени, да и сами модели зачастую не слишком сложные — важнее чувствовать предметную область, чем уметь отлично подкручивать гиперпараметры градиентного бустинга. Пресловутые soft skills тоже часто перевешивают какие-то технические способности.
Data Engineer
В отличие от аналитика, который должен бодро рассказывать свои выводы коллегам, типичный дата инженер как раз может без проблем сидеть в своем уголке и шатать очередной Spark кластер. Его задача — делать так, чтобы данные, порождаемые тут и там, не просто сыпались в бездну, а осознанно собирались, опционально агрегировались, хранились и были доступны нужным людям (например, тем самым аналитикам) или другим сервисам.
Спрос на дата инженеров был порожден предыдущим хайпом, когда многие бредили пресловутой big data. Сейчас обычно дата инженеры работают в средних и крупных компаниях, где в том или ином виде data science функция выполняется несколькими людьми, а то и несколькими командами.
Так как дата инженер обычно работает с достаточно большими наборами данных, ему следует более или менее знать классику computer science, ведь на многих терабайтах данных неоптимальность алгоритма становится заметна очень быстро. Кроме того, в дата инженерии есть свой набор фреймворков (отличается от компании к компании), знакомство с которыми может потребоваться. Пожалуй, роль data engineer больше всего похожа на классическую роль software engineer.
Machine Learning Engineer (MLE)
Как можно догадаться, основная разница с предыдущим подвидом инженера как раз связана с машинным обучением. Пока дата инженер больше работает с подготовкой данных, обычно больших, и собственно модели не обучает, для Machine Learning Engineer это важная часть работы. Вкратце — это software engineer с уклоном в машинное обучение, который может выполнить полный цикл — от сбора данных для модели до деплоймента ее как части продакшен-приложения.
Следовательно, требования к MLE чем-то похожи на требования к дата инженеру: в первую очередь, это просто компетентный разработчик, знающий и алгоритмы, и инженерные практики (может ответить, зачем нужен CI, и рассказать пару баек, почему выкатываться в пятницу может быть плохой идеей). При этом он более или менее понимает теорию машинного обучения (например, понимает bias-variance tradeoff и может написать градиентный спуск с нуля). Хороший MLE знает современные алгоритмы машинного обучения, но не спешит использовать самые горячие новинки. Ему обычно не нужно изобретать что-то с нуля, но слегка адаптировать существующий подход под свою задачу — довольно часто.
В зависимости от домена, у MLE могут быть специфические навыки. Например, для обработки видео на телефоне в реальном времени нужно уметь написать сколько-то быстрый код на C++, а для разработки классического бэкенд-приложения обычно полезно быть «на ты» с Docker.
ML Researcher
Зато ML Researcher как раз должен знать новинки. Более того, не просто знать, но и изобретать новые, двигать науку вперед. Такие исследователи — редкая птица в наших краях, обычно они работают или в лабораториях университетов, или в крупных компаниях (наверное, в Беларуси таким может похвастаться только Яндекс).
ML Researcher должен быть хорош в теории, нормально программировать, а вот знанием хороших инженерных практик может похвастаться не всегда. «Академический код» — своего рода мем. Впрочем, ситуация улучшается: на сайте https://paperswithcode.com/, где выкладываются имплементации последних статей, уже довольно часто можно видеть приличный код.
О размытости границ
Следует понимать, что эти четыре подвида не встречаются в сферическом виде в вакууме, зачастую в разных командах и разных компаниях нужны свои комбинации этих архетипов. Например, если компания делает достаточно инновационный продукт, то MLE должен быть немного исследователем, чтобы сделать что-то по-настоящему новое (пример — ребята из AIMatter, чей фреймворк для инференса смог впечатлить Google). Или data scientist в небольшой компании не может сидеть и ждать, пока данные автомагически появятся на его компьютере — придется засучить рукава и самому сделать базовый ETL.
Также в силу этих нечетких границ полезно почитать/посмотреть и другие точки зрения, которые могут в чем-то отличаться, а в чем-то дополнять вышесказанное:
- https://events.yandex.ru/events/ds/21-oct-2018/?openTalkDescription=1767-1
- https://www.youtube.com/watch?v=GcxFo7nFUj0
- https://www.springboard.com/blog/machine-learning-engineer-vs-data-scientist/
- https://workera.ai/candidates/report/ (нужно заполнить форму, зато и обзор там самый обширный)
От бизнес-метрик до sticky sessions
В силу этого разнообразия вопросы на интервью тоже иногда удивляют. Я не могу похвастаться большим количеством пройденных интервью, но дисперсия вопросов успела впечатлить. Спрашивают всякое: аксиоматику Колмогорова, как написать LRU-cache на салфетке, способы реализации sticky-сессий в распределенных приложениях, методы оценки экономического эффекта от внедрения ML модели в продукт, задачи про гномов и шапки…
Если позиция предполагает какой-то deep learning, то обязательно спросят, как устроен Adam и зачем нужен Batch Normalization. Тестовые задания, которые я видел, в основном двух типов: «выжми из этого датасета метрику получше» (здесь могут оценивать и саму метрику, и способ подачи результатов) и «напиши эту несложную функцию» (в этом случае обязательно будут смотреть на чистоту кода, тесты и прочие хорошие практики).
В целом, все те же проблемы, которые часто обсуждаются касательно найма разработчиков, касаются и DS с поправкой на общую незрелости роли (т.е. в среднем все еще хуже). Ситуации, в которых интервьюер что-то недавно узнал/опробовал, и теперь ожидает от кандидата ответ, совпадающий с его собственным опытом — не редкость даже в крупных компаниях.
Впрочем, все это дикое разнообразие в чем-то и хорошо: практически любой набор скиллов, от умения болтать и рисовать графики до опыта тренировки GAN-ов в итоге будет высоко оценен хоть кем-то из нанимателей. Как следствие, ответ на вопрос «так и что мне учить, чтобы легко найти работу в DS» очень расплывчатый — «зависит от твоих личных склонностей».
Вместо вывода
Data Science в очень общем смысле вышел на плато продуктивности, умение работать с данными навсегда останется востребованным, если не случится чего-то совсем близкого к апокалипсису. Зрелости все еще не хватает: мода меняется часто, технологии взлетают и угасают. Тем не менее, уже можно найти какое-то более или менее стабильное подмножество навыков, которые будут нужны индустрии в среднесрочной перспективе.
Читать на dev.by