Машинному обучению нужны DataOps
(это перепечатано из моего оригинального блога здесь)
Темный секрет науки о данных
Интересный вопрос: что общего у следующих проектов?
1. Джиму поручено прогнозировать отказы промышленных компрессоров с помощью обширной телематической системы. Он знает, что это случается с рекуррентными нейронными сетями (RNN), но обучение моделей требует больших вычислительных ресурсов и требует быстрых сетей и хранилища. На выделение этой вычислительной мощности могут уйти месяцы. К тому времени, когда он получил необходимые разрешения, его защитник по внутреннему бизнесу ушел.
2. Сьюзен разрабатывает решения для видеоаналитики для контроля безопасности на производстве. Ее модель сверточной нейронной сети (CNN) построена, обучена и протестирована и превосходит высокоскоростную классификацию изображений. Вывод в реальном времени должен побуждать к действию без задержки облака. Из-за нехватки периферийных вычислительных мощностей проект никогда не переходит из экспериментальной демонстрации в реальный мир.
3. Модель инспекционной робототехники Amit была разработана, протестирована и внедрена в производство. Он работает настолько хорошо, что на газопроводах размещается целый парк роботов для выявления неисправностей оборудования. Однако несколько месяцев спустя роботы не могут выявить ни одного потенциально катастрофического дефекта. К тому времени Амит был назначен на новые проекты, и парк роботов был припаркован.
Ответ на простой вопрос: все три проекта были мотивированы четкими бизнес-целями и продемонстрировали участие высококвалифицированных специалистов по данным (оба важнейших компонента); но, к сожалению, все три проекта также потерпели неудачу из-за несогласованности организационных структур и процессов предоставления технологий.
Темный секрет науки о данных состоит в том, что лишь небольшой процент проектов больших данных когда-либо выходит на свет в повседневных деловых операциях. И это несмотря на шумиху и зачастую значительные усилия ИТ-специалистов и бизнес-групп. Хотя в некоторых случаях это может быть приемлемым (например, в случае разовых исследований), в большинстве случаев это означает потраченные впустую инвестиции (в ИТ и людей) и (что еще более важно) упущенные возможности для бизнеса.
Данные - это новый код
Учитывая возможности, предоставляемые «искусственным интеллектом» (ИИ), неспособность эффективно производить науку о данных становится главным препятствием для успеха в бизнесе. Это проблема машинного обучения (ML) и, в частности, глубокого обучения (DL) (учитывая его огромный интерес к обучающим данным).
Подумайте об этом: с стремительным ростом глубинного обучения акцент может все больше смещаться с программируемой вручную логики и правил программного обеспечения на обучение моделей. Программная инженерия заменяется (по крайней мере, в некоторых случаях) инженерией данных. Фактически данные становятся новым кодом, открывая новые возможности в таких отраслях, как финансы, здравоохранение, производство, транспорт и другие.
Итак, должны ли мы заменить инженеров-программистов инженерами и аналитиками данных, чтобы войти в дивный новый мир? Не так быстро. Во-первых, неудивительно, что дисциплина программной инженерии очень жива и здорова, отнюдь не обреченная. Во-вторых, создание сложных систем никогда не сводилось только к кодированию. Индустрия программного обеспечения извлекла тяжелые уроки, с которыми мир науки о данных только начинает справляться.
Традиционные «водопадные» подходы к доставке программного обеспечения столкнулись в середине 90-х с двумя важными осознаниями: во-первых, очень сложно планировать и масштабировать сложные проекты с множеством зависимостей, а во-вторых, реальные жизненные ситуации почти наверняка не будут соответствовать запланированным сценариям. или ожидания пользователей.
Если данные - это новый код, чему наука о данных может извлечь уроки из информатики? Давайте углубимся в память и посмотрим, как развивались разработка и внедрение программного обеспечения за эти годы.
От водопада к DevOps
Бережливое производство произвело революцию в физических производственных процессах в 80-х годах. Методы, популяризированные производственной системой Toyota (TPS), доказали, что вы можете существенно увеличить производительность при одновременном улучшении общего качества продукции. Центральным в этом подходе было (и остается) постоянное устранение потерь («муда», или 無 駄), обусловленное прозрачностью процессов, автоматизацией и наделенными полномочиями служащими (например, позволяющими брать на себя риски и «быстро терпеть неудачу», вытаскивая Канбан канбан на производственной линии).
Перенесемся на двадцать лет вперед, и гибкая разработка программного обеспечения вошла в полную силу (с Agile Manifesto, опубликованным в 2001 году). Переняв уроки промышленных производственных процессов, индустрия программного обеспечения обнаружила недостатки традиционных водопадных моделей и приняла свои собственные «быстрые отказы», основанные на (опять же) прозрачности, автоматизации, частых выпусках и автономии решений.
Но гибкая разработка и непрерывная интеграция (частое объединение кода в общие репозитории) не решают «последней мили» внедрения программного обеспечения в производство. Чтобы сделать доставку программного обеспечения по-настоящему быстрым и надежным процессом, необходимо было объединить заинтересованные стороны из разных организаций, бросить вызов общепринятым представлениям и разрушить традиционные структуры власти.
Перенесемся еще раз на десять лет, и DevOps стал общепринятым (хотя и не всегда понятным или хорошо реализованным) подходом к поставке программного обеспечения. Центральным элементом DevOps является совместное владение разработкой программного обеспечения (Dev) и корпоративными ИТ (Ops) за предоставление услуг в поддержку цифровых инициатив. Инженеры отвечают за доставку кода, который может быть развернут в производственной среде, и несут эту ответственность далеко за пределами развертывания. ИТ, в свою очередь, обеспечивают предоставление инфраструктуры и услуг на основе совместно взятых соглашений об уровне обслуживания (SLA).
От DevOps к DataOps
Уроки, извлеченные из информатики, должны хорошо применяться в науке о данных - интуитивно это имеет смысл. Сходства много, и кроме того: большая часть науки о данных включает в себя написание кода, например для инженерии данных, для разработки моделей и для реализации модели.
Философия и принципы Agile Manifesto готовы к применению в науке о данных: ориентированность на результат клиента; принятие изменяющихся требований; частые роды; межфункциональное сотрудничество. В равной степени применимы философия и принципы менее известного DevOps Manifesto Jez Humble (основанного на Agile Manifesto).
Это подводит нас к DataOps (Операции с данными). Хотя этот термин не обязательно является новым, в последнее время он стал более заметным в беседах с практиками из разных отраслей (см., Например, Вакансии в LinkedIn), поставщиками технологий и решений (например, Hitachi Vantara) и отраслевыми наблюдателями и аналитиками (например, Gartner). .
Итак, если философия и принципы DataOps так похожи на DevOps, зачем нам нужен новый термин и дисциплина? Что ж, несмотря на сходство, есть несколько принципиальных отличий, особенно когда дело касается реализации. Основные дисциплины и заинтересованные стороны разные, процессы разные, инструменты и ИТ-потребности тоже разные. DataOps - это не просто DevOps, применяемый в науке о данных. Давайте подробнее рассмотрим ключевые принципы DevOps (взятые из DevOps Manifesto) и то, как они могут быть реализованы для DataOps.
Итеративный и инкрементный
В DevOps программное обеспечение доставляется посредством повторяющихся циклов (итеративно) и небольшими частями за раз (инкрементально). В каждом приращении часть функциональности предоставляется через междисциплинарную работу, от требований до развертывания.
В DataOps модели также доставляются через итерационные и инкрементные циклы. Однако, кроме того, обучение модели происходит посредством инженерии данных с помощью итерационных и инкрементных циклов. Итак, то, что представляет собой одиночный цикл в DevOps, становится двойным циклом в DataOps - усложнение.
Непрерывный и автоматизированный
В DevOps доставка программного обеспечения - это непрерывный и в идеале высокоавтоматизированный процесс. Код фиксирует триггерную сборку, модульное тестирование, развертывание и тестирование, а в идеале - автоматическое развертывание в производственной среде. Фазы обычно описываются как непрерывная интеграция, непрерывная доставка и непрерывное развертывание. Достаточно зрелая индустрия инструментальных средств развивалась для удовлетворения потребностей в доставке программного обеспечения.
В DataOps этапы схожи на макроуровне: разработка и обучение моделей науки о данных; проверка точности и эффективности модели; развертывание моделей в производстве; и повторное обучение моделей по мере появления новых данных испытаний. Однако для инструментов DataOps не существует «магического квадранта» (а традиционные инструменты DevOps не всегда применимы, особенно с отсутствием возможностей управления данными).
Самообслуживание и совместная работа
В DevOps самообслуживание - это расширение прав и возможностей разработчиков и операторов для уменьшения проблемных или неправильных передач, ускорения вывода на рынок и повышения организационного потенциала. Самообслуживание достигается за счет расширения прав и возможностей организации, а также за счет возможности автоматического предоставления: например, тестовых сред, основанных на конкретных потребностях кода, который необходимо создать и интегрировать.
В DataOps самообслуживание позволяет специалистам по данным использовать свои инструменты и фреймворки для разработки моделей (например, Python / Jupyter, PyCharm, RStudio), а также дает возможность команде создавать и развертывать конвейеры данных для обучения моделей и инжиниринг данных, а также предоставление инфраструктуры для обучения и производственного вывода нажатием кнопки.
Пять (5) важнейших факторов успеха технологии
DataOps - это не технология. Как бы ни утверждали некоторые поставщики, вы можете «купить DataOps» - вы не можете. Это философия и практика, требующие организационной согласованности и культурной готовности. Тем не менее, для успеха инициатив DataOps критически важным является определенный уровень технологической зрелости.
Давайте посмотрим, что могло помочь Джиму, Сьюзан и Амиту (см. Викторину этого блога) добиться успеха.
1. Гибкая инфраструктура данных
DataOps зависит от гибкой инфраструктуры данных, что означает способность организации гибко распределять и масштабировать вычислительную инфраструктуру по мере необходимости. В нашем вводном случае Джима замедлила его неспособность быстро предоставить вычислительную инфраструктуру.
Хотя в некоторых случаях решением могут быть облачные сервисы, в действительности все не так однозначно. Данные могут быть распределены по локальным и мультиоблачным платформам; Требования соответствия и регулярности могут повлиять на то, где и когда развертывать вычисления для DataOps. Рекомендуется согласованная стратегия управления данными и инфраструктура управления технологиями.
2. Автоматизированные конвейеры данных
Инфраструктура данных и конвейеры данных должны поддерживать самообслуживание или автоматическую инициализацию в зависимости от потребностей специалистов по данным. Чтобы остаться с Джимом, как специалистом по обработке данных, он на самом деле не хочет развивать ИТ-инфраструктуру: все, что он хочет, - это обучать свои модели RNN, и делать это так быстро.
Конвейеры данных, которые предоставляет специалист по данным (или инженер по данным), должны автоматически, негласно, масштабировать инфраструктуру, чтобы она соответствовала задаче, и отменять предоставление там, где она больше не нужна. Например. конвейеры данных должны понимать рецепты масштабирования с помощью Hadoop и Spark.
3. Рабочие процессы развертывания модели
После разработки с использованием предпочтительных инструментов (а часто и инструментов с открытым исходным кодом) модели данных необходимо обернуть, развернуть и внедрить в сквозные аналитические рабочие процессы. У Сьюзан не было возможности развернуть модель там, где это действительно было необходимо - на «краю» инфраструктуры Интернета вещей.
Часто эти аналитические рабочие процессы хотят быть встроенными в бизнес-приложения для поддержки таких процессов, как входящие звонки, продажи или производство; Кроме того, выполнение модели может потребоваться в облаке или на «границе Интернета вещей». Например, для быстрого развертывания следует рассмотреть удобную для контейнеров периферийную архитектуру Интернета вещей.
4. Модельное тестирование
Даже со 100% точными данными наука о данных не является точной наукой. Обычно существует несколько подходов к решению данной проблемы. В конце проекта Амит узнал, что модель не совсем подходит для поставленной задачи.
Несколько моделей необходимо сравнивать и тестировать не только с точки зрения точности при различных сценариях, но и с точки зрения стоимости вычислительной инфраструктуры и затрат на обслуживание. Существуют технологии, позволяющие сравнить и определить наиболее точную модель для конкретной задачи.
5. Измерение
Вы не можете управлять тем, что не можете измерить. Эта старая поговорка, безусловно, применима к науке о данных. Джим, Сьюзан и Амит могли бы извлечь пользу из показателей, измеряющих успех проекта в реальном времени, а также из предупреждений, указывающих на потенциальные или фактические узкие места.
Точность модели, потребление вычислительной инфраструктуры, скорость обучения моделей и вывода результатов - системы DataOps должны учитывать соответствующие метрики. В этом могут помочь научные системы измерения, инструменты и информационная панель.
Заключение
Наука о данных, машинное обучение и глубокое обучение никуда не денутся и будут продолжать оказывать огромное влияние на прибыльность и прибыльность организаций во всех отраслях. Чем быстрее организации смогут внедрить рабочие модели в производство (и со временем продолжать их улучшать), тем лучше они будут подготовлены к успеху в бизнесе. Хотя DataOps все еще является довольно ранней дисциплиной, сегодня уже существуют передовые практики и проверенные технологии, позволяющие выпускать более частые выпуски с более высоким качеством и, в конечном итоге, улучшать бизнес-результаты.
Присоединяйтесь к нашему сообществу Slack и читайте наши еженедельные темы о Фавнах ⬇
