Кто такой Data Scientist. Обзор изнутри от Арсения Кравченко
dev.by запускает цикл материалов про ИТ-специальности. Каждую из них опишет «типичный представитель» — опытный специалист. Мы надеемся, что цикл поможет школьникам, студентам, переквалификантам, джуниорам и сочувствующим выбрать специальность в ИТ, оценить свои перспективы или просто сверить часы с авторитетным коллегой. Можно обсуждать и дополнять материал в комментариях, чтобы сделать его ещё полезней. Автор поддержит дискуссию и ответит на вопросы.
— Классическое полушуточное определение звучит примерно так: 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 с уклоном в машинное обучение, который может выполнить полный цикл — от сбора данных для модели до деплоймента ее как части продакшен-приложения.
Me at career day in middle school, brightly: Okay, kids. I’m a 'machine learning engineer', which is just a fancy word for — Kid in the back: Yeah, we know what you do. PyTorch or Tensorflow? Me: Well, I, uh, don’t do deep learn- Kids: BOOOO GO HOME I BET YOU ONLY USE ONE CORE
Следовательно, требования к MLE чем-то похожи на требования к дата инженеру: в первую очередь, это просто компетентный разработчик, знающий и алгоритмы, и инженерные практики (может ответить, зачем нужен CI, и рассказать пару баек, почему выкатываться в пятницу может быть плохой идеей). При этом он более или менее понимает теорию машинного обучения (например, понимает bias-variance tradeoff и может написать градиентный спуск с нуля). Хороший MLE знает современные алгоритмы машинного обучения, но не спешит использовать самые горячие новинки. Ему обычно не нужно изобретать что-то с нуля, но слегка адаптировать существующий подход под свою задачу — довольно часто.
В зависимости от домена, у MLE могут быть специфические навыки. Например, для обработки видео на телефоне в реальном времени нужно уметь написать сколько-то быстрый код на C++, а для разработки классического бэкенд-приложения обычно полезно быть «на ты» с Docker.
ML Researcher
Зато ML Researcher как раз должен знать новинки. Более того, не просто знать, но и изобретать новые, двигать науку вперед. Такие исследователи — редкая птица в наших краях, обычно они работают или в лабораториях университетов, или в крупных компаниях (наверное, в Беларуси таким может похвастаться только Яндекс).
I saw a guy debugging his model today. No idpb. No unittest. No visualization. No disabling regularization. He just sat there staring at every line of code and cursing TensorFlow. Like every machine learning researcher I know.
ML Researcher должен быть хорош в теории, нормально программировать, а вот знанием хороших инженерных практик может похвастаться не всегда. «Академический код» — своего рода мем. Впрочем, ситуация улучшается: на сайте https://paperswithcode.com/, где выкладываются имплементации последних статей, уже довольно часто можно видеть приличный код.
О размытости границ
Следует понимать, что эти четыре подвида не встречаются в сферическом виде в вакууме, зачастую в разных командах и разных компаниях нужны свои комбинации этих архетипов. Например, если компания делает достаточно инновационный продукт, то MLE должен быть немного исследователем, чтобы сделать что-то по-настоящему новое (пример — ребята из AIMatter, чей фреймворк для инференса смог впечатлить Google). Или data scientist в небольшой компании не может сидеть и ждать, пока данные автомагически появятся на его компьютере — придется засучить рукава и самому сделать базовый ETL.
Также в силу этих нечетких границ полезно почитать/посмотреть и другие точки зрения, которые могут в чем-то отличаться, а в чем-то дополнять вышесказанное:
В силу этого разнообразия вопросы на интервью тоже иногда удивляют. Я не могу похвастаться большим количеством пройденных интервью, но дисперсия вопросов успела впечатлить. Спрашивают всякое: аксиоматику Колмогорова, как написать LRU-cache на салфетке, способы реализации sticky-сессий в распределенных приложениях, методы оценки экономического эффекта от внедрения ML модели в продукт, задачи про гномов и шапки…
Если позиция предполагает какой-то deep learning, то обязательно спросят, как устроен Adam и зачем нужен Batch Normalization. Тестовые задания, которые я видел, в основном двух типов: «выжми из этого датасета метрику получше» (здесь могут оценивать и саму метрику, и способ подачи результатов) и «напиши эту несложную функцию» (в этом случае обязательно будут смотреть на чистоту кода, тесты и прочие хорошие практики).
В целом, все те же проблемы, которые часто обсуждаются касательно найма разработчиков, касаются и DS с поправкой на общую незрелости роли (т.е. в среднем все еще хуже). Ситуации, в которых интервьюер что-то недавно узнал/опробовал, и теперь ожидает от кандидата ответ, совпадающий с его собственным опытом — не редкость даже в крупных компаниях.
Впрочем, все это дикое разнообразие в чем-то и хорошо: практически любой набор скиллов, от умения болтать и рисовать графики до опыта тренировки GAN-ов в итоге будет высоко оценен хоть кем-то из нанимателей. Как следствие, ответ на вопрос «так и что мне учить, чтобы легко найти работу в DS» очень расплывчатый — «зависит от твоих личных склонностей».
Вместо вывода
Data Science в очень общем смысле вышел на плато продуктивности, умение работать с данными навсегда останется востребованным, если не случится чего-то совсем близкого к апокалипсису. Зрелости все еще не хватает: мода меняется часто, технологии взлетают и угасают. Тем не менее, уже можно найти какое-то более или менее стабильное подмножество навыков, которые будут нужны индустрии в среднесрочной перспективе.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.