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

Оглядываясь назад, я понимаю, что мой путь стать специалистом по обработке данных был смесью опытов. Моим первым языком программирования был VBA. Я изучал R в основном через Stack Overflow. Я провел слишком много фокус-групп, чтобы запомнить. Я почти получил докторскую степень по теории графов. Я никогда официально не посещал курсы информатики, а теперь программирую на Python большую часть дней недели. Есть много других специалистов по обработке данных, таких как я, и многие из них - нет.

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

Причина в следующем: специалисты по обработке данных происходят из самых разных слоев общества. Данные касаются всего.

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

Насколько данные связывали нас вместе, наш различный опыт и процессы разделяли нас. Мы привыкли делать что-то «так, как делали всегда», и для некоторых из нас это означало, что мы придерживаемся «библии git flow». Для других это означало написание 10 000 строк кода в одном файле Python на своей локальной машине.

Мы спорили о скорости (да, написать 10000 строк кода в одном файле технически быстрее, чем разбивать его на папки и файлы) и устойчивости (но нет, это плохая практика хранить этот код на ноутбуке, который вы потеряли вчера, плюс нет. можно прочитать ваш код). Мы спорили о безопасности (нет, у вас не может быть доступа администратора для установки этого случайного пакета, который вы нашли в глубинах Интернета, который не обновлялся с 1996 года). Больше всего мы спорили о совместной работе («Парное программирование - пустая трата времени!» Но вы хотите потратить дополнительную неделю, объясняя мне это, когда вам потребовалось два дня, чтобы написать?).

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

да.

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

  1. Среда «песочница» и среда разработки НЕ являются производственной средой.
  2. Фактор автобуса: если бы вас завтра сбил автобус, мог бы кто-нибудь забрать вашу работу?
  3. Как вы можете добавить наибольшую ценность? Знайте свои сильные стороны и знайте, когда обращаться за помощью. Будьте открыты для новых предложений. Осознайте, что вы не можете сделать все.

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

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

В наше время кажется, что все - это услуга. Программное обеспечение как услуга (SaaS), инфраструктура как услуга (Iaas), платформа как услуга (PaaS), контейнер как услуга ( CaaS), Function as a Service (FaaS) и мой личный фаворит: kaas. Шучу, kaas - это не сервис, но я бы хотел, чтобы это было.

Каждый раз, когда вы видите «() aaS», это означает, что они (облачные инженеры) о чем-то заботятся за вас. От безопасности до масштабирования и до полной непрерывной интеграции и платформ доставки: эти () aaS, похоже, берут на себя все большее количество задач разработчика.

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

Вернемся к основному шоу.

Концепция №1 совместной работы - это разделение «песочницы» и сред разработки от рабочих сред. Это означает, что вы можете двигаться с головокружительной скоростью во время НИОКР, но когда дело доходит до производства, все еще существуют жесткие процессы, обеспечивающие целостность продукта.

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

В среде песочницы скорость и гибкость правят королем и королевой. Нельзя отрицать скорость и контроль над собственным ноутбуком. Однако есть еще некоторые правила, которые необходимо соблюдать, например, фиксация всего кода в репозитории git и частая фиксация. Мы делаем это из-за концепции №2: фактор шины. Если завтра вас сбит автобус, по крайней мере, другие смогут получить доступ к вашей работе.

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

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

Это подводит меня к концепции №3: все службы () aaS предназначены для того, чтобы помочь вам с вещами, в которых вы, возможно, не являетесь лучшими специалистами, или просто делать это лучше, делая это в автоматизированном режиме. мода. Почему бы не позволить кому-то или чему-то позаботиться об этом за вас? Специалисты по обработке данных не одновременно являются сетевыми инженерами, инженерами DevOps, экспертами по безопасности, инженерами по обслуживанию платформ, администраторами баз данных и веб-разработчиками. Мы можем попросить о помощи с компонентами, которых мы не знаем, но нам нужно знать, в чем заключаются наши недостатки. Правильно спроектированные приложения и среды имеют ценность как в «песочнице», так и в производственной среде.

Как облачные сервисы могут помочь в совместной работе?

1. Не совсем облачный сервис, а GitHub GitHub GitHub (или любое другое ПО для контроля версий). Если его нет на GitHub, от потери небезопасно. Если вы работаете над проектом вместе с кем-то другим, нет оправдания тому, что вы не разместите свой код на GitHub, особенно если вы работаете удаленно. Я не могу сказать лучше, чем люди из Towards Data Science, поэтому вот статья о том, почему git.

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

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

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

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

4. Наконец, такие службы Azure, как DevOps, Машинное обучение, Databricks, помогают избавиться от разочарования, связанного с платформенными элементами науки о данных. Они заботятся о создании и обслуживании сред, в которых вы запускаете код, поэтому вы можете сосредоточиться на создании наилучшей модели. Благодаря интеграции с GitHub и настройке CI / CD (непрерывная интеграция / непрерывное развертывание) обновление приложения может занять всего лишь отправку кода в репозиторий. Ниже приведен пример архитектуры машинного обучения, полностью построенной в Azure, с единой точкой контакта между кодировщиком и остальной инфраструктурой: GitHub. С выпуском Действия GitHub теперь стало еще проще отправлять код во все уголки вашей облачной среды.

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

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

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

Еще впереди:
Как сотрудничать с помощью Azure DSVM (виртуальных машин для обработки данных)
Как сотрудничать с помощью машинного обучения Azure
Как сотрудничать с помощью Azure Databricks
Как сделать машинное обучение продуктивным с помощью Azure DevOps