"Рабочие часы"

Создание успешной организации по науке о данных

Как создать эффективную группу по анализу данных!

Введение

Это обзорная статья о том, как создать эффективную группу по анализу данных на основе моих ›10 лет работы в программировании,› 5 лет работы в области науки о данных и работы в различных отделах и компаниях. В моей статье Веб-фреймворки для специалистов по обработке данных и почему вам следует заботиться о них я указал, что такие компании, как VentureBeat, Redapt и другие, сообщают, что ~ 90% проектов машинного обучения не попадают в производство . Другими словами, многие группы по анализу данных изо всех сил пытаются обеспечить ценность. Эта статья представляет собой обзор качеств, которые (я обнаружил) делают группы по анализу данных более эффективными. Из рассмотренных концепций отсутствие только одного элемента приводит к более медленной доставке (если доставка вообще есть).

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

Что такое наука о данных?

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

Это подводит нас к следующему (и потенциально более проницательному) вопросу: чем занимается команда специалистов по анализу данных?

Чем занимается команда специалистов по анализу данных?

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

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

Мы можем разделить обязанности команд по анализу данных на 2 схожие области.

  • Исследование

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

Если ваша команда по анализу данных не тратит какое-то время на анализ данных, вы можете упустить половину потенциальной ценности своей команды!

  • Эксплуатация

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

Если ваша команда по анализу данных не внедряет какие-либо продукты для обработки данных, вы можете упустить половину потенциальной ценности своей команды!

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

Что такое продукты для науки о данных?

  • Отчетность

Обычно это происходит в форме инструментов бизнес-аналитики, таких как Tableau, Power BI, Apache Superset, Plotly Dash, RShiny, Microsoft Excel и даже Microsoft Powerpoint.

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

Если это повторяющийся отчет, вы можете использовать инструмент панели мониторинга, например Tableau или Plotly Dash.

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

  • Новые системы

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

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

В любом случае вот несколько общих систем \ продуктов:

  1. REST API. Возможно, у вашей компании есть веб-продукт, и пока клиент использует веб-приложение, вы хотите, чтобы приложение вызывало ваш REST API и возвращало результат пользователю. Как правило, вам нужно что-то, что можно масштабировать при необходимости. Некоторые распространенные коммерческие решения включают AWS Lambda, приложение Azure Functions и Algorithmia. Некоторые решения с открытым исходным кодом включают Kubernetes, Flask, plumber и т. Д. Ожидаемый объем трафика будет определять, насколько масштабируемым должен быть ваш REST API.
  2. Модель пакетного скоринга. Допустим, у вас есть система для определения приоритетности клиентов при проверке мошенничества. Возможно, эта система обновляется каждый день, и вы используете модели машинного обучения, чтобы расставлять приоритеты для клиентов. Это ситуация, когда модель должна соответствовать вашему конвейеру ETL. Некоторые распространенные облачные решения включают Databricks, конвейеры Azure ML Studio и пакетную службу Azure. Некоторые решения с открытым исходным кодом включают Apache Airflow и Luigi.
  3. Веб-приложение. Возможно, вы размещаете приложение для мошенничества в дополнение к реальным моделям мошенничества. Вы можете разместить это приложение с помощью такой системы, как Heroku или Azure Web Apps. Вы также можете разместить его локально, используя сервер Linux. Ожидаемый объем трафика будет определять, насколько масштабируемым должно быть ваше веб-приложение.

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

Затем нам нужно спросить себя, какие инструменты необходимы, чтобы эти конечные продукты стали реальностью?

Какие инструменты нужны команде специалистов по анализу данных?

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

  • Разработчик Data Science

Я написал более подробную статью на эту тему под названием Известные платформы для обработки данных в 2020 году. Тем не менее, вот краткое изложение:

  1. Лучшее, что вы можете сделать, - это получить облачную среду. Это даст вашей команде инструменты и масштаб, необходимые для анализа данных и построения моделей. Это будет ваш лучший вариант. Он должен быть более надежным и, скорее всего, более дешевым, чем другие варианты. Если вы уже находитесь в облаке, это должно быть решающим моментом. Если вы используете локальную систему, тогда вы можете использовать гибридную инфраструктуру для передачи данных между облаком и локально.
  2. Если вы используете локальную систему, а гибридная технология не используется, вы можете взять трубку и попробовать позвонить поставщику платформы обработки данных (DSP) . Некоторые поставщики развертывают что-то либо локально, либо могут развернуть это в облачной среде, которой они управляют (в этом случае вам все равно нужно выяснить, как подключиться к вашим данным). Обратной стороной DSP является то, что они, как правило, дороже.

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

Когда у вас есть среда разработки, в которой ваши специалисты по данным могут анализировать данные и строить модели, мы еще не закончили! Нам еще многое нужно учесть, чтобы принести пользу нашей компании!

  • Отчетность

Одноразовые отчеты не требуют особого обслуживания. Такие инструменты, как Excel и Powerpoint, бесполезны.

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

  1. Автоматизация. Если у вас есть кто-то, кто вручную запускает один и тот же отчет каждую неделю, значит, вы упустили один трюк. Аналитикам следует тратить свое время на анализ данных или построение моделей, а не на выполнение действий вручную. Вы могли бы сказать: «Ну, мы хотели бы разослать по электронной почте отзыв с обзором последнего отчета». Это нормально, и вы все еще можете это сделать, но это займет час, а не 30% времени вашего специалиста по данным.
  2. Сложные конвейеры ETL. Вы должны уметь запускать сложные конвейеры ETL. У вас должна быть возможность быстро связать данные из различных источников и сохранить эти данные в таблице, которая может поддерживать панель мониторинга. Если вы не включили это в своей инфраструктуре Dashboarding, забудьте об этом, выбросьте полотенце, потому что вы упустили огромную часть своей ценности Dahboarding.
  3. Хранилище базы данных - обработка данных панели управления должна быть перенесена в базу данных. Это позволит вашей панели инструментов работать быстрее и даст ей возможность работать в режиме реального времени. Медленные дашборды никому не нужны. Пользователи должны иметь возможность быстро взаимодействовать с вашей приборной панелью, а это означает наличие надлежащей базы данных для поддержки вашей приборной панели.
  4. Неограниченная визуализация данных. Вы должны ограничиваться только своим воображением, а не своими инструментами. Это делает инструменты инструментальной панели на основе кода, такие как Plotly Dash и RShiny, очень желательными.
  5. Контроль версий. Если ваша панель управления изменится, вы сможете отслеживать свои изменения. Это делает инструменты инструментальной панели на основе кода, такие как Plotly Dash и RShiny, очень желательными.

Для базы данных выберите ваш выбор. Для ETL и автоматизации существуют варианты с открытым исходным кодом, такие как Apache Airflow, Apache Spark, Luigi и т. Д., А также множество коммерческих предложений. Если вы находитесь в облаке, вы можете использовать такие облачные сервисы, как Azure Data Factory и AWS Batch. Если вы работаете локально, вы можете использовать для начала отдельные серверы, а затем можете масштабировать их по мере необходимости. В конце концов, вам может понадобиться универсальный кластер, который вы могли бы построить самостоятельно или называть такую ​​компанию, как Cloudera.

  • Машинное обучение и эксплуатация приложений

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

  1. База данных. У вас должна быть возможность хранить данные для создания отчетов и любых других приложений. Это также полезно для разработки моделей и настройки конвейеров данных, необходимых для моделирования, анализа и развертывания.
  2. ETL. Вам нужен надежный инструмент ETL, который может организовать сложные конвейеры данных для работы ваших приложений и подготовить данные для потенциального анализа.
  3. Интеграция модели ETL. Выбранный вами инструмент ETL должен уметь интегрироваться с конвейерами оценки модели (и запускать их).
  4. Хостинг REST API. У вас должна быть возможность размещать модели и приложения как REST API для любых случаев использования в реальном времени.
  5. Хостинг веб-приложений. Возможно, ваша команда не размещает какие-либо веб-приложения, но вы должны быть открыты для размещения веб-инструментов.
  6. Контроль версий и DevOps. Это стандартная практика, которая должна быть очевидной.
  7. Мониторинг моделей. Вы должны следить за своими опубликованными моделями на предмет дрейфа данных, общих проблем и указаний на необходимость обновления вашей модели.

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

Как выглядит команда специалистов по анализу данных?

Группа по науке о данных должна быть союзом между 3 подгруппами.

  • Наука о данных

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

  • Инженерия данных

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

  • DevOps и разработчики приложений

Эти люди отвечают за модульное тестирование, думают о CI / CD и следят за надежностью всего, что вы запускаете. Они также несут ответственность за работу с другими ИТ-группами и за управление всеми решениями, которые запускаются в производство. Если в вашем решении есть ошибка, кто по вызову сможет ее исправить? Ваши специалисты по данным? Первой линией защиты в этой области должны быть разработчики приложений.

  • MLOps

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

Приведенный выше рисунок взят из известного технического документа Google под названием Скрытый технический долг в системах машинного обучения. Графика показывает, что наука о данных - это гораздо больше, чем просто построение моделей. Маленький черный квадрат представляет код машинного обучения, а остальное - необходимая инфраструктура для того, чтобы извлечь выгоду из кода машинного обучения. Поддержка науки о данных требует ресурсов, разнообразной команды и приверженности бизнеса.

В другом документе Google под названием Машинное обучение: высокопроцентная кредитная карта технического долга говорится:

Академическое сообщество может удивиться, узнав, что лишь крошечная часть кода во многих системах машинного обучения фактически выполняет «машинное обучение». Когда мы осознаем, что зрелая система может в конечном итоге состоять (максимум) на 5% из кода машинного обучения и (как минимум) на 95% из связующего кода, повторная реализация, а не повторное использование неуклюжего API, выглядит намного лучшей стратегией.

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

Это подводит нас к следующему пункту - мы много рассказали о командах, инструментах и ​​продуктах, занимающихся анализом данных; но как насчет корпоративной культуры? Какая культура компании требуется, чтобы эти конечные продукты стали реальностью? Несомненно, корпоративная культура играет важную роль в успехе команды по анализу данных.

Какие социальные / бизнес-требования необходимы для успешной работы команды по анализу данных?

  • Сотрудничество со всей организацией, и особенно с командой MLOps \ DevOps, требует прочных связей с ИТ-отделом.

Вам необходимо сотрудничество со стороны остальной части вашей организации. Высшее руководство несет ответственность за признание того, что наука о данных является делом компании и требует, чтобы вся компания при необходимости взаимодействовала с группой по анализу данных. Также команде MLOps \ DevOps необходимы прочные связи с ИТ-отделом. Это поможет вам быстрее вывести продукты на рынок, потому что у вас уже налажены отношения!

  • Гибкая разработка программного обеспечения и отслеживание проектов

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

  • Инновационная культура с правильными командными ключевыми показателями эффективности и ожиданиями

Что это значит? Это означает, что в компанию нужно вкладывать средства, пытаясь делать что-то своими силами! Время от времени брать телефон и звонить поставщику - это нормально, но компанию нужно вкладывать во внутренние данные. наука. Какие инструменты использует компания? Всегда ли компания стремится быть на переднем крае? Некоторые компании стремятся пробовать что-то новое, в то время как другие предпочитают перестраховаться.

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

Компания должна быть уязвимой.

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

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

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

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

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

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

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

  • Осведомленность об этике данных

И последнее, но не менее важное: для группы важно установить некую основу (или руководящие принципы) этики данных. Большая часть этого относится к MLOps и тестированию конкретных баз, но также ответственность всей группы (и всей компании) - думать об этике данных. Fast Book от Fast.ai содержит список замечательных вопросов, которые вы можете задать своей команде при каждом обзоре спринта. Загляните в раздел Fast Book, Глава 3: Этика,« Анализ проекта, над которым вы работаете ». Первые 2 вопроса являются лучшими - Стоит ли нам вообще этим заниматься? и Какая предвзятость в данных?. Если вы спрашиваете себя, как это связано с успешной группой по науке о данных? Ответ - это не даст вам создать монстра, который расстроит клиентов и похоронит вашу компанию (и вас самих) в скандале. Кроме того, само собой разумеется, что мы все несем ответственность за создание продуктов, которые улучшают общество, а не разрушают и не наносят ему вреда. Это приведет к положительному впечатлению клиентов и к бренду, который олицетворяет качество.

Резюме

Итак, что необходимо для эффективной группы по анализу данных?

Основные инструменты:

  • База данных команды.
  • Инструмент ETL с автоматизацией, планированием и возможностью вызова конвейеров оценки модели.
  • Инструменты развертывания моделей для REST API и пакетной оценки (т. Е. Интеграция с вашим инструментом ETL).
  • Гибкий инструмент отчетности.
  • Контроль версий кода, документов и данных.
  • Гибкое программное обеспечение для управления проектами.
  • Гибкая среда разработки науки о данных.

Основные члены команды:

  • Data Science
  • Инженерия данных
  • DevOps и разработка приложений

Основные потребности организации:

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

Конец

Вот и все! Большое спасибо за чтение и надеюсь, что вы нашли это проницательным!

Отличные отраслевые ресурсы

Вот несколько отличных ресурсов и видео. Spark + AI Summit и TWIML AI Podcast - потрясающие ресурсы для просмотра реальных MLOps и реальных ML на практике от крупных компаний, таких как Facebook, LinkedIn, Comcast, Capital One и других.

Еще раз спасибо за чтение!