В видеоаналитике важно не только распознать объект, но и правильно связать его с контекстом: временем, местом, камерой и результатом обработки. Если данные рассинхронизированы, даже точная модель машинного зрения может привести к ошибочному выводу. Рассказываем, как мы выстроили архитектуру данных, которая помогает сохранять целостность событий — от камеры до аналитического отчёта.
Привет, Хабр! Это Григорий Тарасов, руководитель направления данных и инфраструктуры из команды «Фалькон Тех». Мы уже более 8 лет разрабатываем решения для видеоаналитики на основе ИИ и машинного зрения. Наша система обрабатывает 1 петабайт данных каждый месяц, и мы выработали свои подходы к управлению ими. Делимся практическими инструментами, которые помогают отражать полную картину событий.
Фиксация события — больше чем просто видеокадр, если у неё есть набор атрибутов
Сама по себе фиксация события не имеет ценности: она не даёт контекста, из которого бизнес может делать выводы. Чтобы информация стала более полезной, видеокадры надо дополнить другими атрибутами. Это может быть:
время съёмки кадра и формирования события;
идентификатор камеры, комплекса и зоны наблюдения;
координаты камеры, направление и параметры её установки;
зоны интереса: проезжая часть, парковочное место, вход, стоп-линия;
результаты детекции: класс объекта, рамка объекта, уверенность модели;
распознанные атрибуты: номер автомобиля, тип транспорта, цвет;
ссылки на исходные и обработанные изображения;
версия модели и конфигурации, которыми событие было получено;
правила обработки, которые действовали в момент события;
статусы камер, каналов связи и вычислительных узлов;
географические и справочные данные объекта.
Ценность кадра появляется, когда он связан со временем, местом, объектом, правилом обработки и результатом доставки. Это большие массивы данных, которые лежат в разных структурах. Сначала фиксации поступают в бэкенд, откуда отправляются заказчикам, менеджменту и другим потребителям.
Чтобы объединить источники данных и управлять ими, мы разработали аналитический контур. Точка входа — холодное хранилище S3. Мы стандартизируем разные источники и типы данных бэкенда в единые parquet-файлы для удобной «раскладки» и обработки в аналитике.
Проблемы в синхронизации данных часто выявляются, когда бизнес уже получил ущерб
В видеоаналитике сложности возникают не только из-за потери фиксаций событий, но и из-за правдоподобных несоответствий. Запись существует, выглядит корректно, но относится не к тому времени или объекту.
При синхронизации данных чаще всего возникают следующие проблемы:
Временные: различаются часы и часовые пояса, происходят задержки сети, установлено неправильное время на устройстве.
Структурные: поле переименовали, изменили тип или формат сообщения.
Семантические: одинаковое поле в двух системах означает разные вещи.
Идентификационные: один объект имеет разные ID или один ID использован повторно.
Количественные: встречаются пропуски, дубли, частично загруженные пакеты.
Порядковые: более позднее событие приходит раньше предыдущего.
Пространственные: камеры используют разные системы координат или неверно откалиброваны.
Версионные: событие обработано старой моделью, а справочник уже обновлен.
Заметить ошибки заранее практически невозможно. Обычно их выявляют и разрабатывают решение, когда бизнес уже столкнулся с последствиями.
Выстроили архитектуру, чтобы агрегировать большие массивы данных и не терять их при передаче
Внутри аналитического контура мы используем разные инструменты, которые помогают синхронизировать данные. Основных — девять.
Единая временная шкала (UTC). Она есть у каждой записи. Внутри системы мы используем единый мировой стандарт UTC+0. Заказчикам показываем данные в московском часовом поясе: локальное время применяется при отображении фиксаций и отчётности.
Event time и Ingest time. У каждой записи, которая попадает из бэкенда в аналитический контур, есть три даты: когда событие произошло, когда записано в бэкенд и когда появилось в аналитическом контуре. Эта информация хранится отдельно.
Например, фиксация появилась 30 июля — это фактическое время события. Она записана 31 июля, что считается датой попадания в бэкенд. В аналитическом контуре фиксация появится 1 августа. Все три значения критичны: если нужно отследить путь записи от одной точки к другой, даты помогут синхронизировать данные.
Устойчивые идентификаторы. В базе сотни миллиардов строк информации. Поэтому в любом хранилище важно определить уникальную единицу, которую всегда можно найти вне зависимости от объёма. У нас это уникальный идентификатор, и он есть у каждой фиксации.
Система ID работает так: заказчик открывает интерфейс и видит фотографию с автомобилем. На ней написан номер фиксации — это уникальный идентификатор. Мы спрашиваем его у заказчика, чтобы найти нужное событие в системе и разобрать критичный случай.
Очередь сообщений. Между камерой и бэкендом есть шина, которая накапливает фиксации. Если произойдет сбой, например из-за проблемы с сервером или бэкендом, то шина сохранит данные и не потеряет их. Как только сервер снова начнёт принимать фиксации, накопленная очередь будет поступать в систему, и она придёт в штатное состояние.
Дата-контракты. Они позволяют синхронизировать обмен данными между бэкендом и аналитическим контуром, так как эти базы используют и поставляют данные в разных форматах. Дата-контракты фиксируют состав полей, типы и точность временных меток.
Дата-контракты содержат информацию о том, из какой базы и таблицы пришли данные, кто поставщик, потребитель и владелец пайплайна. Ещё указываются детали: структура таблицы, названия колонок, типы данных и таймзона.
В дата-контрактах есть два вида критериев для изменения данных:
Compatible-условия: данные можно изменить без согласования, так как это не повлияет на другие системы.
Breaking-условия: изменения данных требуют согласования с другой стороны. Например, таблица лежит в бэкенде, но аналитический контур — её важный потребитель. С ним надо согласовывать любые изменения критичных полей.
Промежуточное объектное хранилище. Камеры поставляют данные в бэкенд, откуда они каждый день отправляются в аналитику, заказчику и другим потребителям. Но при сбоях важно не потерять фиксации, поэтому бэковые базы — промежуточные. Они хранят данные за три месяца. При любой неполадке есть возможность временно подержать данные в бэкенде перед отправкой — повторно обращаться к камерам не нужно.
Аналитическое хранилище. Часто в бэкенде есть ненормализованные данные, которые сложно анализировать с помощью Excel и BI-инструментов. Поэтому мы создали отдельное аналитическое хранилище ClickHouse. Оно берёт данные из бэковских баз и превращает неагрегированные тонны информации в удобные таблицы. Дальше их можно селектить.
В таблице содержатся разные данные по отправленным фиксациям, например:
дата доставки фиксации;
дупло и протокол, через которые произошла отправка;
уникальный ID фиксации;
контракт, к которому относится фиксация;
дата записи и отправки.
Мы подключаем BI-систему Superset к аналитическому хранилищу. В ней можно получить информацию о собранных и отправленных фиксациях в виде отчётов и графиков — для этого не нужно открывать базу бэкенда.
Оркестратор. Он позволяет координировать большое количество процессов и переменных. Система по расписанию запускает загрузку данных, управляет доставкой и повторной сверкой. Мы для этих целей используем Airflow.
Реконсиляция. В бэкенде фиксации появляются каждую секунду, и раз в час мы собираем их и поставляем в аналитику. Но при сбое часть данных может задержаться и появиться в базе задним числом. Поэтому мы регулярно запускаем процесс сверки и сравнения источника и приёмника за закрытый период.
Как работает реконсиляция: бэкенд присылает данные, и мы каждый час загружаем их в течение 24 часов. Затем ещё раз одним запуском собираем фиксации за эти сутки, чтобы ничего не потерять.
Если подытожить, то наш аналитический контур имеет следующую структуру:
Чтобы извлекать из фиксаций контекст событий, надо следить за качеством синхронизации данных
Мы измеряем метрики с помощью каналов с алертами — они подсвечивают проблемы в системе. Закладываем в пайплайны индикаторы, и они каждый день проверяют, например, количество созданных фиксаций.
Чтобы отследить полноту и синхронизацию данных, можно проверять такие метрики:
Плотность данных. Надо посмотреть, какая доля ожидаемых событий дошла. Например, из 24 часов фиксации были только в течение 10 часов. Это аномалия — система направит алерт, чтобы мы начали проверку данных.
Уникальность значений. Система проверяет, все ли идентификаторы фиксации уникальные. Если есть дубли, мы получим алерт и начнём разбираться в причинах.
Временное смещение между источниками. Например, за сутки есть данные только за 22 часа. После проверки оказалось, что 2 часа бэкенд был недоступен и фиксации в него не попали. Мы не могли получить их в аналитический контур. Из-за этого возник рассинхрон по времени между системами, разошлось количество записей между источником и приёмником.
Свежесть данных. Важно, чтобы они не отставали от реального времени или отставали, но на согласованные промежутки.
Время восстановления после сбоя. У нас регламентирован срок реагирования на падение пайплайнов в LSA. Сбой надо исправить в течение суток, пока он не перешёл в инцидент. Дежурный должен обнаружить проблему с помощью алертов, отреагировать, починить или завести постмортем, чтобы аналогичных кейсов больше не было.
Доля событий, которые исправлены повторной сверкой. Должно быть минимум реконсайлов загрузок. Если их количество растёт, это говорит о проблеме со стороны тех, кто поставляет или принимает данные.
Можно добиться почти идеального распознавания объектов. Но если событие потеряет время, идентификатор или связь с другими данными, ценность всей аналитики снижается. Поэтому надёжность систем определяется не только качеством моделей машинного зрения, но и тем, насколько последовательно выстроен путь данных — от камеры до аналитической витрины.