Практическое руководство, как превзойти ожидания на вашей первой работе в области Data Science.

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

Содержание:
1. Чего мне не хватало, когда я начинал
2. Навыки и инструменты, которые нужно изучить
3. Какие навыки изучать в первую очередь
4. Советы на рабочем месте

Чего мне не хватало, когда я начинал (и вам тоже)

На то, чтобы понять, что означает «Прод», у меня ушло намного больше времени, чем я хотел бы признать. Это был действительно момент лампочки, когда я наконец понял это, ведь ответы на многие годы вопросы были даны в считанные минуты.

Я никогда особо не заботился о разработке программного обеспечения и считаю, что CSV и соревнования Kaggle сделали меня грязным. Когда я начинал, я чувствовал себя неподготовленным к работе в «реальной среде», где вам не нужно каждый раз загружать Parquet и загружать его в PySpark, чтобы что-то сделать.

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

Я не знал, и, вероятно, вы тоже!

Здесь я собрал уроки (а значит, и ошибки) моего первого года работы в качестве единственного специалиста по Data Science в SmartServ, SaaS-стартапе для неофициальных сотрудников в США и Канаде. Некоторые из них не ожидаются от вас - только что закончивших колледж - но поскольку эта статья посвящена тому, чтобы «выделяться», я включаю все, что знаю. Я ничего об этом не знал до того, как начал, наверное, вам стоит.

В произвольном порядке:

Производство. Знакомство с производственной средой - это смена парадигмы. Вы всегда задавались вопросом, как все должно работать в Netflix, поскольку они не могут разумно зависеть от загрузки и скачивания CSV-файлов каждый раз, когда нужно давать рекомендации по фильму. Но Kaggle и AnalyticsVidhya подготовили вас только к последним 10–20% растяжения, то есть к чтению предварительно обработанных данных и их использованию для соответствия моделям машинного обучения. Это тоже разовые процессы - ни многоразового, ни масштабируемого. Data & Pipeline Engineering - это то, как это делается в реальном мире.

  • Более крупные компании нанимают на определенные должности. Однако в стартапе вы беретесь за проект от начала до конца. И это (примерно) включает:
    - Получение данных
    - Получение (из озер данных или OLTP)
    - ETLing (денормализация, очистка и подготовка к использованию)
    - Перенос в OLAP
    - Настройка склада
    - Создание модели ML
    - Подача ее в модели или отчеты ML / DL или панели инструментов
    ПРИМЕЧАНИЕ: все работает в производственной среде (т. е. на сервере) без вмешательства человека. Простое введение в среды:


  • Docker: после того, как вы закончите Как мне запустить его в производство?, вы увидите Почему он не запущен в производственной среде? Он работает на моей машине !! . Управление зависимостями между средами - это головная боль, и знание базовых реализаций Docker / Kubernetes может пройти долгий путь. Контейнеры Docker аналогичны виртуальным средам (например, virtualenv в Python3), и они замораживают текущее состояние вашей среды (включая все зависимости), на которой будет выполняться ваше приложение. Затем он развертывается в производственной среде, где он остается неизменным по сравнению с обновлениями и устареванием включенных переменных среды.
  • В более крупных организациях вы можете найти для этого специальный персонал DevOps, но всегда лучше работать в полном составе. Докеры могут намного больше, чем я уже говорил, но я оставлю это экспертам.
    Совет: докеры также могут помочь вам создать портативную среду индивидуальной разработки для себя. что вы можете использовать в пути. Пошаговое руководство по Docker:


  • Базы данных: усвойте функциональные концепции БД. Ожидается, что вы будете знать как минимум по одному реляционному (MySQL / PostgreSQL) и по одному нереляционному языку запросов (MongoDB / CassandraDB). Как только вы определитесь с одним, остальные станут легко доступны. Ведение журнала запросов и оптимизация, безусловно, являются плюсом, однако вряд ли они будут признаны или оценены. Есть много статей, которые помогут вам начать работу с СУБД.

  • ETL: я не обращал внимания на ETL до тех пор, пока меня не осенило. Если в вашем продукте не используется преднамеренная передача данных (IDT), этого не избежать. ETL - это аббревиатура от Extract-Transform-Load, процесса, который вам придется выполнять неоднократно, возможно, сотни раз в неделю для сотен различных задач. Приложения ETL позволяют вам создавать шаблоны для всего процесса (называемого конвейером, используя код или графический интерфейс) и даже планировать его запуск через определенные промежутки времени без вмешательства.
  • Мой руководитель отдела разработки указал мне на Pentaho DI Community Edition (ранее Kettle), и это довольно красивое приложение. Альтернативы включают Matillion (широкая поддержка облачных источников данных), Talend и Informatica. Опытные специалисты по данным предпочитают использовать Bash для низкоуровневых элементов управления, так что выбирайте сами. Путеводитель по Pentaho DI:




Совет. Со временем вы захотите перейти на полноценную систему управления рабочим процессом (например, Luigi, Apache Airflow). Сейчас я пытаюсь использовать Airflow, и это очень больно. Но похоже, это того стоит, универсальное решение.

  • Сценарии: создание отчетов - это не то, из чего вы когда-либо вырастете. Хотя SQL сам по себе достаточно мощный, знание языка сценариев часто бывает полезным. Языки сценариев позволяют выполнять указанные задачи в среде выполнения, интерпретируя их последовательно.
  • Python - это де-факто, и это то, что я использую для отчетности (и для управления рабочим процессом). Я перешел с R (мой личный фаворит) на Python, потому что:
    - Люди не знакомы с R. Следовательно, они сопротивляются ему.
    - R имеет ограничения распараллеливания (плохая масштабируемость) и не является удобство развертывания.
    - Это очень сложно. Поэтому отладка быстро усложняется.
    - Каждый может прочитать код Python3. Повышается возможность повторного использования, и становится проще передать его новым людям.

  • ML / DL / Визуализация: Это ваша сила. Вы будете продолжать накапливать другие навыки по ходу дела, но в глубине души вы всегда будете мастером ML / DL или поклонником визуализации. Однако в первые годы проекты могут не всегда реализовываться так, как вам хотелось бы. Возможно, вам не удастся создать статистические модели или причудливые механизмы рекомендаций. Вам придется почесать свой зуд, работая над личными проектами или участвуя в проектах с открытым исходным кодом. А когда вы найдете окно, в котором ваши навыки могут быть полезны продукту / компании, поторопитесь, чтобы войти в него. См. «Обучение на рабочем месте» ниже. Ваша готовность гарантирует, что вы выделитесь, когда в этом возникнет необходимость.
  • Вы уже должны быть знакомы с TensorFlow, MXNet или Torch для ML / DL и ggPlot2, Bokeh, Plotly для визуализации. Вот отличный проект NVIDIA с открытым исходным кодом, в который вы можете внести свой вклад:


  • Облачные вычисления: * НАИЛУЧШИЙ * навык, который должен быть в вашем арсенале для любого аналитика данных / ученого. Большинству разработчиков и персонала DevOps неудобно работать с приложениями, управляемыми данными (помните, что вы можете быть первым или только пятым сотрудником Data Science; команде потребуется время, чтобы привыкнуть к вашим потребностям), поэтому вы хотите начать изучая веревки CC как можно скорее.
  • К счастью, существует множество управляемых платформ (AWS, GCP, Azure, DataBricks), которые значительно упрощают создание, тестирование и развертывание приложений машинного обучения. Кроме того, управляемые службы машинного обучения (например, SageMaker) могут помочь вам сократить вспомогательную работу, которую вы, возможно, не захотите выполнять.

Вот мои личные заметки о решениях AWS Cloud Computing для науки о данных:



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


tl; dr: Что вам следует изучить в первую очередь

На мой взгляд:
Обязательные навыки: СУБД и сценарии ›› Git
Отличные навыки: [Cloud Computing, ETL] ›› Docker ›› твоя крепость

Обучение на рабочем месте:

  1. С умом используйте статистику: авторитетных людей убеждает только то, что они понимают (именно поэтому они принимают решения). Если вы переборщите с числами или составными метриками, вы рискуете их потерять, а если откажетесь от цифр, вы не сможете поддержать себя. Уравновешивание чисел и рассуждений на основе первых принципов - это ремесло, которым я еще не овладел, возможно, вы сможете начать им заниматься раньше.
  2. Вы не можете избежать тяжелой работы. Существует бесчисленное множество причин, по которым вы не можете этого сделать, просто примите это и попытайтесь сделать это. Если вы специально не выполняете роль инженера по машинному обучению (что было бы бессмысленно для выпускника), вам придется делать все понемногу. Вы будете нести ответственность за все задачи, связанные с данными. Отказ от науки о науке о данных иногда помогает облегчить боль.
  3. Будьте непреклонны: для достижения цели вам понадобятся люди в вашем углу, желательно старшие, которые поддержат вас и ваши идеи. Если в вашей команде его нет, найдите чемпиона снаружи. В первые несколько месяцев мне было трудно что-либо делать из-за вышеупомянутого. Другие продвигались со своими идеями, а я стоял и ждал, пока что-то придет мне в голову (они никогда не делали этого). Будьте немного небрежным и более чем непреклонным. Сделай свое дерьмо!

Вывод

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

Это все для этой статьи. Я постараюсь осветить каждый из этих моментов отдельно в других публикациях. Дайте мне знать, если у вас есть какие-либо отзывы или что-нибудь, что вы хотите, чтобы я осветил в моих следующих публикациях. Я работаю в SmartServ, где мы всегда ищем новые таланты. Ищите доступные вакансии или поздоровайтесь!