v.5.177.0

Изменения

• Изменены названия бакетов сервиса Image Store по умолчанию.

  Новые имена бакетов:

  • bucket-samples — для хранения БО лиц;
  • bucket-bodies-samples — для хранения БО тел;
  • bucket-image-origin — для хранения исходных изображений;
  • bucket-objects — для хранения объектов.

  Важно! Новые названия используются только при установке LP с нуля. Изменение не затрагивает существующие бакеты при обновлении LP — их названия сохраняются.

• В результатах матчинга при выполнении запроса на генерацию событий теперь возвращается поле candidate_origin, показывающее, с каким типом кандидатов выполнялся матчинг — с лицами (faces) или с событиями (events).

• В запрос "get handlers" добавлен новый параметр фильтрации handler_ids, который позволяет получить список обработчиков с указанными идентификаторами.

• В запросы create group и replace group в секцию stream_settings добавлены поля source и event_source_group для задания источника и группы источников событий.

  Эти значения автоматически наследуются всеми потоками, связанными с группой. При изменении значения event_source_group у группы оно также обновляется у всех её потоков при условии, что параметр streams_update установлен в 1.

  Также в запросы get groups и get group count добавлены параметры фильтрации sources и event_source_groups, позволяющие получить список групп или подсчитать их количество по указанным источникам или группам источников событий.

• В запросы create group и replace group добавлен query-параметр check_agent.

  Параметр позволяет проверить, существует ли активный агент (или несколько агентов для групп с разделяемыми потоками), способный обрабатывать все указанные аналитики группы:

  • если check_agent=1 и подходящий агент отсутствует, группа не будет создана, а запрос завершится ошибкой.
  • если check_agent=0 (по умолчанию), проверка наличия агента не выполняется, и группа создаётся при условии, что остальные параметры запроса корректны.

  Примечание. Если группа создана, но у всех доступных агентов нет свободных слотов, потоки в группе получат статус pending до появления свободных слотов. (независимо от значения check_agent).

• В запрос count streams добавлен новый query-параметр event_source_groups.

  Теперь при подсчёте количества потоков можно указать список групп источников событий.

  Будут учтены только те потоки, у которых event_source_group совпадает с одним из переданных значений. Например, если передано event_source_groups=group-1,group-2, запрос вернёт количество потоков, принадлежащих группам group-1 или group-2.

• В запрос "get streams logs" добавлен новый параметр фильтрации group_ids, позволяющий получить логи обработки потоков, принадлежащих указанным группам.

  Параметр group_ids можно комбинировать с другими фильтрами. Если указаны и group_ids, и stream_ids, будут возвращены логи потоков, которые одновременно принадлежат указанным группам и перечислены в stream_ids.

• Добавлена поддержка нового механизма для организации работы лямбд в условиях ограниченных ресурсов.

  Данный функционал находится в стадии бета-тестирования.

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

  • поток задач (workflows) — это набор общих параметров (включая Docker-образ), которые наследуются всеми созданными задачами внутри него.
  • задача (job) — это экземпляр лямбды, которая работает в режиме ротации: она запускается, выполняет часть работы, останавливается и запускается снова, пока не завершит всю работу полностью. При этом разворачивается один и тот же образ с одними и теми же параметрами. Однако, набор операций, которые пользователь может выполнять с задачами, более ограничен по сравнению с обычными лямбдами.

  Принцип работы:

  • Создаётся поток задач, в котором указываются общие настройки.
  • Внутри потока задач создаются задачи. Docker-образ наследуется от потока задач и не может быть изменён для отдельной задачи. Все остальные параметры можно переопределить индивидуально для каждой задачи. Задачи должны иметь уникальные имена в рамках одного потока и выполняются по очереди.
  • Сервис Lambda автоматически управляет очередью задач в каждом пространстве имён (namespace). Количество одновременно работающих задач в каждом namespace ограничено настройками сервиса Lambda.
  • Когда ресурсы освобождаются, следующая задача из очереди запускается и продолжает обработку. Таким образом, все данные обрабатываются последовательно, без необходимости одновременного запуска всех лямбд.

  Ключевые особенности:

  • Задачи создаются только внутри потока задач.
  • Все задачи внутри одного потока используют один и тот же Docker-образ.
  • При удалении потока задач все его задачи удаляются автоматически.

  Добавлены запросы для управления потоками задач и задачами (/workflow creation и /jobs creation).

  См. подробную информацию в разделе "Jobs detailed description" руководства разработчика.

• В секцию deploy_parameters.resources добавлен новый параметр gpu_limit, который задает количество GPU-устройств, выделяемых на каждый под лямбды.

  Параметр gpu_limit доступен только при включённом GPU (enable_gpu=1) и должен быть не менее 1 (по умолчанию — 1). Если GPU не используется (enable_gpu=0), параметр должен быть равен 0. Подробнее см. в запросах create lambda, put lambda и других.

Исправленные ошибки

• Исправлена ошибка при выполнении запроса "delete faces", из-за которой фильтр по account_id не применялся при включенном флаге ignore.

• Исправлена ошибка в агрегации статистики использования эстиматоров duty_uniform, photorealistic_face, light_colored_clothes и neck_occlusion.

  Ранее в ответе на запрос "get system info" к сервису Admin могли возвращаться некорректные значения в полях batch_size и execution_time, из-за чего в пользовательском интерфейсе были недоступны кнопки создания задач. Теперь статистика для этих эстиматоров формируется корректно.

• Устранены проблемы при работе с разделяемыми потоками:

  • Исправлено поведение, когда при обработке разделяемого потока аналитики, завершавшие работу быстрее других, могли неожиданно перезапускаться. Теперь каждая аналитика завершается корректно и не влияет на состояние других в рамках одного потока.

  • Исправлен процесс обновления общего статуса разделяемого потока при изменении состояния любой из его аналитик.

  • Предотвращено избыточное переназначение аналитик при удалении агента, отвечающего за другую аналитику этого же потока.

• Исправлена ошибка, из-за которой пустые результаты матчинга сохранялись сразу в двух таблицах базы данных сервиса Events: face_match_result и event_match_result при пустом списке кандидатов или кандидатах одного типа.

  Теперь результат сохраняется только в одной таблице, соответствующей типу кандидатов.

• Исправлена ошибка, из-за которой импортированная лямбда не запускалась, несмотря на то, что сохранялась в базе данных сервиса Lambda.