Архитектура телеметрии: как собирать показания так, чтобы они пригодились через три года
Почему данные с датчиков нужно проектировать как долгосрочный актив, а не запускать как разовый пилот, который потом нельзя переиспользовать.
Когда компания запускает первый пилот с датчиками или удалённым мониторингом оборудования, фокус почти всегда на том, чтобы что-то заработало. Получить первые показания, показать руководству, убедиться, что технология работает. Это разумно.
Проблема начинается через год-два, когда выясняется, что накопленные данные нельзя использовать так, как изначально предполагалось. Структура неудобная, история неполная, форматы несовместимы с новыми задачами. Пилот стал промышленным решением случайно, без проектирования.
Чем телеметрия отличается от обычных данных
Телеметрия - это данные с физических объектов, которые меняются во времени: температура, вибрация, давление, координаты, скорость, статусы. Её специфика в том, что она непрерывна, её много, и ценность в ней накапливается со временем.
Разовый снимок показаний почти бесполезен. Ценность появляется, когда можно сравнить поведение объекта сегодня с поведением три месяца назад, или найти паттерн, который предшествует отказу. Это значит, что архитектура хранения должна быть спроектирована под временные ряды, а не под транзакционные записи.
Если телеметрия складывается в ту же реляционную базу, куда идут заказы и контрагенты, через два года эта база превратится в проблему. Это частный случай более общего паттерна: архитектурные решения, принятые неформально в начале, определяют объём переработки в будущем.
Четыре решения, которые нужно принять в начале
Когда проектируется система сбора телеметрии, есть несколько решений, которые потом почти невозможно изменить без потери данных или переработки всей архитектуры.
Гранулярность. С какой частотой снимаются показания - раз в секунду, раз в минуту, раз в час? Это надо решить под задачу, а не "побольше на всякий случай". Избыточная гранулярность создаёт объёмы, которые сложно хранить и обрабатывать, но при этом может не добавлять аналитической ценности.
Метка времени. Чьё время фиксируется - устройства или сервера? Если устройство работает офлайн и синхронизируется с задержкой, это разные вещи. Ошибки во временных метках - одна из самых распространённых проблем при последующем анализе.
Контекст объекта. Показание без привязки к объекту почти бесполезно. Какой датчик, на каком оборудовании, в каком месте, в какой конфигурации. Если оборудование меняется или перемещается, как это отражается в данных? Без этого через год нельзя будет понять, что означает конкретное значение в истории.
Схема изменений. Что происходит, когда добавляются новые типы датчиков или меняется состав метрик? Если схема жёсткая и не допускает расширения, каждое изменение в оборудовании потребует изменения структуры хранилища.
Что делает данные пригодными для анализа через три года
Через три года ценность телеметрии определяется не объёмом, а тем, можно ли задать ретроспективный вопрос и получить ответ.
Для этого нужно несколько вещей. История должна быть непрерывной - пропуски и потери данных делают временной ряд ненадёжным. Контекст должен быть сохранён вместе с показаниями - не в отдельной системе, которой может уже не существовать. Метаданные об оборудовании и его конфигурации должны храниться с историей изменений.
И главное: кто-то должен отвечать за то, что эти данные существуют и доступны. Телеметрия без владельца деградирует незаметно.
Практический фильтр для начала проекта
Перед запуском пилота телеметрии полезно задать несколько вопросов:
- Какие аналитические вопросы мы хотим задавать через два-три года?
- Какая гранулярность нужна для этих вопросов, а не "вообще"?
- Как мы будем хранить контекст объекта вместе с показаниями?
- Что произойдёт со схемой, когда состав оборудования изменится?
- Кто будет отвечать за качество этих данных?
Ответы на эти вопросы занимают несколько часов в начале проекта. Их отсутствие занимает месяцы переработки потом.