Данные загрузились — всё ли сошлось? Как мы обеспечиваем согласованность в аналитическом хранилище

В видеоаналитике важно не только распознать объект, но и правильно связать его с контекстом: временем, местом, камерой и результатом обработки. Если данные рассинхронизированы, даже точная модель машинного зрения может привести к ошибочному выводу. Рассказываем, как мы выстроили архитектуру данных, которая помогает сохранять целостность событий — от камеры до аналитического отчёта.

Привет, Хабр! Это Григорий Тарасов, руководитель направления данных и инфраструктуры из команды «Фалькон Тех». Мы уже более 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. Сбой надо исправить в течение суток, пока он не перешёл в инцидент. Дежурный должен обнаружить проблему с помощью алертов, отреагировать, починить или завести постмортем, чтобы аналогичных кейсов больше не было.

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

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