Проекты Data Science в промышленной эксплуатации

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Всем привет, меня зовут Андрей Старжинский, я сооснователь стартапа a-Gnostics, статья написана в соавторстве с Ярославом Недашковским, сооснователем и CTO.

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

При работе с индустриальными данными, основными вызовами с которыми мы сталкиваемся, является разнообразность данных, их источников, а также необходимость наличия гибкой инфраструктуры, которая может линейно масштабироваться. Кроме того, дополнительная сложность заключается в повышенных требованиях к безопасности, а также соблюдения правил управления набором данных (data governance) и моделями (model governance). Все эти требования послужили базовым ТЗ для проектирования системы a-Gnostics.

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

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

Систему a-Gnostics, логически можно разделить на четыре основных компонента:

1. Storage;
2. DataOps;
3. ModelOps;
4. API.

Один из ключевых принципов — развертывание и запуск сервисов, является инфраструктурно независимым, так как корпоративные вычислительные мощности, могут быть развернуты как в Облаках, так и в локальной инфраструктуре. Мы также предусмотрели возможность подключения к моделям a-Gnostics по SaaS, или точнее Model-as-a-Service.

В видео коротко дается обзор тех задач, которые нужно решить, чтобы разработать автоматизированную цепочку для анализа промышленных данных при помощи методов машинного обучения: youtu.be/5sp7pHEhUMw

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

Стоит отметить, что в последнее время обозначился тренд на кардинальное улучшение ситуации с точки зрения получения доступа к данным: многие компании начали процесс интеграции/миграции своей «наземной» инфраструктуры с облачными провайдерами, в основном это Azure и AWS. Особенно, наличие таких сервисов как AWS IoT Greengrass, AWS IoT SiteWise, Azure IoT Edge дает нам четкий сигнал в будущее, что постепенно затраты и время на интеграцию, а также сбор данных будут уменьшаться, и можно будет больше фокусироваться на построении моделей и сервисов.

Data

Данные, которые поступают в систему, можно разделить на четыре типа:

1. исторические данные — в большинстве своем это csv, excel, txt файлы, кроме того, могут присутствовать файлы специфического формата, в зависимости от доменной области (например, формат АСКУЭ для обмена информацией о потреблении электроэнергии). Для специфических форматов необходимо разрабатывать отдельные модули по обработке;
2. данные поступающие в реальном времени — обычно, это показатели с датчиков оборудования. В данной ситуаций нет одного стандарта, в большинстве случаев, приходится иметь дело с промежуточным звеном в виде облачного окружения (AWS S3, AWS Kinesis, Azure Blob, Azure FileShare и тд.) или отдельного стоящего сервера (например, FTP), куда происходит выгрузка данных. Наличие такого звена, продиктовано мерами безопасности для защиты от внешнего вмешательства. Слать прямые запросы на оборудование критической инфраструктуры никто не разрешит, можно только наладить процесс выгрузки данных изнутри во вне. В этом есть определенный плюс, так как отпадает необходимость тратить время на разработку кастомных коннекторов для обработки специфических протоколов (например, Modbus), хотя бывают исключения из правил. Представление о том, что внешнему пользователю можно будет подключиться по условному MQTT и начать читать показатели, является скорее исключением, чем реальностью (если конечно речь не идет о лампочке или кофеварке);
3. открытые данные — любая полезная информация из открытых источников, которая улучшит обучающую выборку или дополнит визуализацию, например погодные данные;
4. проприетарные данные — информация, которой нет ни в открытых источниках ни у заказчика. В некоторых задач, нам приходилось уточнять открытые погодные признаки (облачность), или же дополнять их новыми (солнечное излучение).

Практически все данные с которыми мы работаем — это временные ряды.

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

DataOps

Если сильно упростить — по сути это автоматизированные конвейеры по обработке данных, в варианте старого доброго ETL (Extract Transform Load) или же более модернового и местами более гибкого подхода ELT (Extract Load Transform).

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

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

С точки зрения управления данными (data governance), в базе данных хранится метаинформация о версиях данных, кем, когда из каких источников, а также для какой задачи конкретный набор данных был сделан.

Хранилище данных

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

1. метаинформация;
2. сырые данные;
3. обработанные данные;
4. наборы данных готовые для обучения;
5. модели;
6. результаты работы моделей (прогнозы, предсказания поломок и т.д.).

В качестве хранилища данных для метаинформации, результатов работы моделей, а также некоторых обработанных наборов данных используется PostgreSQL. В остальных случаях, данные представлены файлами разных форматов, которые хранятся в файловой системе или сервисах типа AWS S3, Azure Blob, Azure FileShare и т.д. Есть исключения, когда оптимальнее real-time данные складывать в специализированные хранилища для работы с временными рядами (time series database).

Модели

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

Чтобы иметь возможность тиражировать модели на сотни объектов, а также обучать тысячи моделей, очень важно автоматизировать все этапы построения модели: подготовки данных, обучения модели, ее хранения и использования в промышленной эксплуатации. Мы стараемся по максимуму использовать подход ModelOps, для управления жизненным циклом задач машинного обучения. При этом, стараемся использовать готовые фреймворки, насколько это является возможным. Например, для реестра моделей у нас написан свой сервис, который внутри взаимодействует с MLflow.

a-Gnostics из коробки содержит уже готовые конвейеры для обучения и разворачивания моделей. В качестве методов могут использоваться уже готовые решения (например, LSTM, XGBoost, Random Forest), уникальные модели или сложные цепочки, по аналогии со стекингом. Для автоматизации процесса выбора модели-чемпиона в задачах регрессии, мы разработали специальный алгоритм walking forward, принимающий на вход датасет (набор данных) и набор моделей, а в качестве результата возвращается победитель с детальными метриками по каждой модели.

На скриншоте выше — факт и пример нескольких прогнозов потребления электроэнергии.

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

Дополнительным толчком к автоматизации обучения и разворачивания моделей послужила задача прогнозирования потребления электроэнергии. С математической точки зрения, это задача регрессии для временного ряда. В теории, переобучать модель для временного ряда надо как можно чаще, чтобы модель оставалась актуальной для входного потока данных. Свежие данные (факты потребления электроэнергии) поступают каждый день. Проведя серию экспериментов мы определили, что если играть «в долгую» — выгоднее переобучать модель каждый день (при этом еще нужно иметь возможность время от времени изменять длину обучающей выборки). В итоге, имея N объектов для прогнозирования, а также М разных моделей, каждый день нам нужно обучить N*M моделей. Даже при небольших значениях M и N, выполнение данной задачи в ручном режиме не представляется возможным.

Использование модели в реальной жизни происходит по принципу Model-as-a-Service (MaaS). Например, для того получить прогноз электроэнергии, нужно обратиться через REST API к соответсвующему модулю (ElectirictyService). При необходимости, модули можно использовать отдельно от API.

API

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

Для этого был разработан a-Gnostics.API, содержащий разные наборы вызовов для разных задач, например api/forecast дает доступ к вызовам прогнозов, а /api/v1/equipment открывает дорогу в мир промышленного оборудования.

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

На скриншоте выше — пример сервиса по прогнозированию поломок и определению аномалий в работе промышленного оборудования.

Безопасность

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

Если запуск сервисов происходит в Облаке, лучше избегать запуска на виртуальных машинах, а использовать соответствующие сервисы (AWS ECS, AWS EKS, Azure AKS, Azure App Service и т.д.).

Заключение

Основной язык разработки — Python, система состоит из модулей на базе которых запускаются микросервисы. Каждый сервис — это отдельный Docker контейнер.

По состоянию на апрель 2021, в промышленной эксплуатации использовалось больше 100,000 обученных моделей, сделано более 1,000,000 прогнозов.

Продолжение следует... Будем рады комментариям и с удовольствием ответим на вопросы.