Диаграммы последовательностей#
В этой главе описаны общие запросы к LP и показано взаимодействие между сервисами при обработке запроса.
Более подробную информацию о запросах можно найти в справочном руководстве сервиса API.
Диаграммы создания биометрических образцов#
Диаграмма создания биометрического образца#
С помощью этого запроса можно определять лица на исходных фотографиях. Фотографии можно отправлять в стандартных форматах изображений (JPEG, PNG и т.д.) или в формате BASE64.
Более подробная информация приведена в запросе "detect faces" в справочном руководстве сервиса API.
| Запрос | Описание | Тип |
|---|---|---|
| detect faces | Обнаруживать лица на входных изображениях, оценивать свойства лиц, извлекать биометрические образцы и сохранять их в Image Store. | POST |
Результат запроса содержит параметры обнаруженных лиц и идентификаторы всех созданных биометрических образцов.
Общая схема обработки запроса:
1․ Запрос на обнаружение лиц отправляется в API.
2․ API получает запрос, обрабатывает его и отправляет задачу в сервис Remote SDK.
3․ Сервис Remote SDK обрабатывает задачу в соответствии с заданными параметрами.
4․ Сервис Remote SDK отправляет полученные биометрические образцы в Image Store.
5․ С помощью Image Store биометрические образцы сохраняются в хранилище.
6․ Из хранилища выдается результат сохранения биометрического образца.
7․ Image Store выдает идентификаторы биометрических образцов и URL-адреса.
8․ Сервис Remote SDK отправляет идентификаторы биометрических образцов и полученные параметры лиц в сервис API.
9․ API генерирует и отправляет ответ.
Получение информации о биометрических образцах и их сохранение#
С помощью запроса, приведенного ниже, внешние биометрические образцы добавляются в Image Store.
Более подробная информация приведена в запросе "save samples" в справочном руководстве сервиса API.
| Запрос | Описание | Тип |
|---|---|---|
| save samples | Сохранить внешний биометрический образец в Image Store | POST |
С помощью следующих запросов можно управлять уже существующими биометрическими образцами.
Более подробная информация приведена в разделе "samples" в справочном руководстве сервиса API.
| Запрос | Описание | Тип |
|---|---|---|
| get sample | Получить биометрический образец по его sample_id | GET |
| remove sample | Удалить биометрический образец по его sample_id | DELETE |
| check to exist sample | Проверить наличие биометрического образца по его sample_id | HEAD |
Все вышеперечисленные запросы обрабатываются с помощью сервиса Image Store.
Схема обработки запросов:
1․ Запрос отправляется в сервис API.
2․ API отправляет запрос в Image Store.
3․ Image Store выполняет необходимые действия с хранилищем.
4․ Из хранилища выдаются необходимые данные.
5․ Сервис Image Store выдает результат в сервис API.
6․ API генерирует и отправляет ответ.
Более подробную информацию о запросах можно найти в документе "APIReferenceManual.html" в разделе "Samples".
Диаграммы атрибутов#
Диаграмма извлечения временных атрибутов#
Сервис Handlers получает биометрические образцы из Image Store и извлекает из них информацию.
Более подробная информация приведена в запросе"extract attributes" в справочном руководстве сервиса API.
Необходимо указать массив идентификаторов биометрических образцов.
| Запрос | Описание | Тип |
|---|---|---|
| extract attributes | Извлечь атрибуты: БШ и базовые атрибуты (возраст, пол, этническая принадлежность) | POST |
Общая схема обработки запроса:
1․ Запрос на извлечение отправляется в API.
2․ Сервис API получает запрос, обрабатывает его и отправляет запрос в сервис Remote SDK.
3․ Сервис Remote SDK запрашивает биометрические образцы из Image Store.
4․ Сервис Image Store запрашивает биометрические образцы из хранилища.
5․ Из хранилища отправляются биометрические образцы.
6․ Сервис Image Store отправляет биометрические образцы в сервис Remote SDK.
7․ Сервис Remote SDK обрабатывает задачу в соответствии с заданными параметрами.
8․ Сервис Remote SDK отправляет БШ и базовые атрибуты в сервис Faces.
9․ Сервис Faces отправляет запросы на хранение временных атрибутов в базе данных Redis.
10․ Из базы данных Redis отправляется ответ в Faces.
11․ Сервис Faces отправляет ответ в сервис Remote SDK.
12․ Сервис Remote SDK отправляет полученные идентификаторы атрибутов, базовые атрибуты, URL-адреса атрибутов, результаты фильтрации и оценку по шкале GS в сервис API.
13․ Сервис API отправляет ответ.
Диаграмма создания атрибута по внешним данным#
На диаграмме показано создание атрибутов с использованием данных из внешней базы данных.
Более подробная информация приведена в разделе "attributes" в справочном руководстве сервиса API.
| Запрос | Описание | Тип |
|---|---|---|
| create temporary attribute | Создать новые временные атрибуты. | POST |
1․ Запрос на добавление новых атрибутов (биометрических шаблонов и/или базовых атрибутов) отправляется в сервис API. Все необходимые данные для создания атрибутов отправляются вместе с запросом. Дополнительно. В сервис Image Store отправляется запрос, если биометрические образцы предоставляются с БШ и/или атрибутами;
2․ Сервис API отправляет запрос в сервис Image Store для сохранения полученных биометрических образцов.
3․ Сервис Image Store запрашивает биометрические образцы из хранилища.
4․ Из хранилища отправляются биометрические образцы.
5․ Сервис Image Store отправляет биометрические образцы в сервис API.
6․ Сервис API отправляет БШ и базовые атрибуты в сервис Faces.
7․ Сервис Faces отправляет запросы на хранение временных атрибутов в базе данных Redis.
8․ Из базы данных Redis отправляется ответ в Faces.
9․ Сервис Faces отправляет ответ в сервис API.
10․ Сервис API отправляет ответ.
Диаграммы получения информации об атрибутах#
С помощью следующих запросов можно получить данные об уже существующих атрибутах или удалить их.
| Запрос | Описание | Тип |
|---|---|---|
| get temporary attributes | Получить все идентификаторы атрибутов и время их создания в соответствии с целевыми полями | GET |
| get temporary attribute | Получить информацию о временном атрибуте по его attribute_id | GET |
| check temporary attribute | Проверить наличие атрибута по его attribute_id | HEAD |
| delete attributes | Удалить атрибут по его attribute_id | DELETE |
| get temporary attribute samples | Получить все биометрические образцы временных атрибутов по attribute_id | GET |
Общая схема обработки запроса:
1․ Запрос отправляется в сервис API.
2․ API отправляет запрос в сервис Faces.
3․ Сервис Faces отправляет запрос в базу данных Redis на получение информации о временных атрибутах.
4․ Из базы данных Redis выдается запрошенная информация.
5․ Сервис Faces выдает результат.
6․ Сервис API выдает информацию пользователю. Если TTL атрибута истек, выдается ошибка.
Диаграммы лиц и списков#
Все запросы в этом разделе обрабатываются с помощью сервиса Faces.
Более подробная информация приведена в разделе "faces" в справочном руководстве сервиса API.
Диаграмма создания лица#
| Запрос | Описание | Тип |
|---|---|---|
| create face | Создать новое лицо с указанным идентификатором атрибута, данными пользователя, аватаром и списками | POST |
Общая схема обработки запроса:
1․ Запрос отправляется в сервис API.
2․ API отправляет запрос в сервис Faces.
3․ Сервис Faces отправляет запрос в базу данных Redis на получение временных атрибутов; Дополнительно. Запрос в базу данных Redis не отправляется, если для лица указаны внешние атрибуты или не установлены атрибуты..
4․ Из базы данных Redis выдается запрошенная информация.
5․ Сервис Faces выдает результат.
6․ Сервис Faces отправляет запрос в базу данных Faces для создания нового лица с использованием указанных данных.
7․ В базе данных Faces сохраняются данные.
8․ Сервис Faces выдает информацию о созданном лице.
9․ Сервис API выдает информацию пользователю.
Информация о лицах и списках#
Все последующие запросы имеют похожие диаграммы последовательности.
С помощью следующих запросов можно создать лицо, получить информацию об уже существующих лицах или удалить их.
| Запрос | Описание | Тип |
|---|---|---|
| get faces | Получить массив всех существующих лиц и их данных: face_id, external_id, user_data, create_time, avatar, account_id и списки list_id, к которым прикреплено лицо | GET |
| delete faces | Удалить несколько лиц по их face_id | DELETE |
| get face count | Получить количество существующих лиц по заданному фильтру | GET |
| get count of faces with attributes | Получить количество лиц с атрибутами | GET |
| get face | Получить данные о лице (face_id, external_id, user_data, create_time, avatar, account_id и списки list_id, к которым прикреплено лицо) по указанному face_id | GET |
| patch face | Обновить лицо указанными данными: user_data, event_id, external_id, avatar | PATCH |
| remove face | Удалить указанное лицо | DELETE |
| check to exist a face | Проверить наличие лица по его face_id | HEAD |
| put face attribute | Установить атрибут лица, изменив все данные атрибута, соответствующие указанному лицу | PUT |
| get face attribute | Получить атрибуты указанного лица: пол, возраст, этническую принадлежность, время создания | GET |
| delete face attribute | Удалить атрибут лица по его face_id | DELETE |
| get face attribute samples | Получить информацию о биометрических образцах (по sample_id), соответствующих указанному лицу | GET |
С помощью следующих запросов можно создать списки, получить информацию об уже существующих списках или удалить их.
| Запрос | Описание | Тип |
|---|---|---|
| create list | Создать новый пустой список. Можно указать для него user_data | POST |
| get lists | Получить массив всех существующих списков со следующими данными: list_id, user_data, account_id, create_time, last_update_time | GET |
| delete lists | Удалить несколько списков по их list_id | DELETE |
| get list count | Получить количество существующих списков | GET |
| get list | Получить информацию (list_id, user_data, account_id, create_time, last_update_time) о списке по list_id | GET |
| check list existence | Проверить наличие списка с list_id | HEAD |
| update list | Обновить поле user_data списка | PATCH |
| delete list | Удалить список с указанным list_id | DELETE |
| attach/detach faces to the list | Обновить список, прикрепив или открепив от него указанные лица | PATCH |
Ниже на диаграмме представлен процесс работы для всех перечисленных выше запросов к сервису Faces.
Общая схема обработки запроса:
1․ Запрос отправляется в сервис API.
2․ API отправляет запрос в сервис Faces.
3․ Сервис Faces отправляет запрос в базу данных Faces для получения информации или управления имеющимися данными.
4․ Из базы данных Faces выдается запрошенная информация или информация об изменениях в базе данных.
5․ Сервис Faces выдает результат.
6․ Сервис API выдает результат пользователю.
Диаграммы сравнения#
Необходимо указать эталоны и кандидаты для сравнения. Можно ограничить количество кандидатов с наибольшим значением схожести.
| Запрос | Описание | Тип |
|---|---|---|
| matcher/faces | Позволяет сравнить указанные эталоны с указанными кандидатами. В результате будет получен уровень схожести для каждого кандидата и дополнительная информация о кандидатах | POST |
| human body matching | Задачи могут отправляться в сервис, который путем сравнения ищет тела, похожие на заданные эталоны | POST |
| raw matching | Можно производить расчеты схожести для входных БШ | POST |
Подробная информация приведена в разделах "matching faces", "human body matching" и "raw matching" в "APIReferenceManual.html".
Сравнение с помощью Python Matcher#
Сравнение по базе данных#
Ниже приведен пример сравнения событий (эталонов) с лицами (кандидатами).
1․ Запрос на сравнение отправляется в сервис API.
2․ Сервис API отправляет запрос в сервис Python Matcher.
3․ Сервис Python Matcher запрашивает эталоны из базы данных Events.
4․ Из базы данных Events выдаются данные.
5․ Сервис Python Matcher отправляет запросы на сравнение базы данных Faces.
6․ Сравнение выполнено.
7․ Из базы данных Faces выдаются соответствующие результаты.
8․ Сервис Python Matcher запрашивает дополнительные данные для кандидатов.
9․ Из базы данных Faces выдаются данные.
10․ Сервис Python Matcher выдает результаты в сервис API.
11․ Сервис API отправляет ответ.
Сравнение по списку#
Ниже приведен пример сравнения лиц (эталонов) со списком лиц (кандидатов).
1․ Запрос на сравнение отправляется в сервис API.
2․ Сервис API отправляет запрос в сервис Python Matcher.
3․ Сервис Python Matcher запрашивает эталоны из базы данных Faces.
4․ Из базы данных Faces выдаются данные.
5․ Сравнение выполняется в сервисе Python Matcher. Используются кешированные БШ.
6․ Сервис Python Matcher запрашивает дополнительные данные для кандидатов.
7․ Из базы данных Faces выдаются данные.
8․ Сервис Python Matcher выдает результаты в сервис API.
9․ Сервис API отправляет ответ.
Диаграммы обработчиков#
Запросы на управление обработчиками#
Обработчик определяет логику обработки входного изображения. Необходимо указать обработчик при создании нового события.
Запросы, приведенные ниже, относятся к обработчику.
| Запрос | Описание | Тип |
|---|---|---|
| create handler | Создать обработчик | POST |
| get handlers | Получить обработчики по заданным фильтрам | GET |
| get handler count | Получить количество существующих обработчиков | GET |
| get handler | Получить политики обработчика по handler_id | GET |
| replace handler | Обновить поля обработчика. Необходимо указать handler_id. Необходимо указать более детальную информацию обо всех соответствующих политиках в теле запроса. Обновление индивидуальных параметров обработчика не допускается | PUT |
| check to exist a handler | Проверить наличие обработчика с указанным handler_id | HEAD |
| remove handler | Удалить обработчик по его handler_id | DELETE |
Общая диаграмма создания обработчика представлена на рисунке ниже. Все запросы обработчика имеют похожие диаграммы последовательности.
1․ Запрос на создание нового обработчика отправляется из сервиса API в сервис Handlers.
2․ Сервис Handlers обрабатывает запрос и создает обработчик.
3․ Сервис Handlers сохраняет обработчика в базе данных API.
4․ Из базы данных сервиса Handlers выдается результат.
5․ Сервис Handlers выдает идентификатор созданного обработчика.
Обработчик используется при создании события. Пример его использования описан в разделе "Events". Все результаты хранятся в базе данных событий Events.
Диаграммы событий#
Общая диаграмма создания события#
Событие создается после обработки изображения в соответствии с обработчиком.
| Запрос | Описание | Сервис |
|---|---|---|
| generate events | Создать событие. Необходимо указать соответствующий ID обработчика (handler_id) или указать политики для динамического обработчика и указать обрабатываемые изображения. Необходимо установить дополнительные параметры и данные для созданного события. | POST |
Диаграмма последовательности для создания нового события будет отличаться в зависимости от указанных политик обработчика.
На приведенной ниже диаграмме последовательности показан общий процесс создания нового события и приведены только общие точки входа для выполнения политик.
1․ Сервис API отправляет запрос на создание нового события в сервис Handlers.
2․ Сервис Handlers получает соответствующий обработчик из базы данных Handlers.
3․ База данных Handlers отправляет обработчик в сервис Handlers.
4․ "detect_policy" и "extract_policy" обрабатываются сервисом Remote SDK. Полученные биометрические образцы и атрибуты хранятся в ОЗУ.
5․ "match_policy" обрабатывается в соответствии с установленными фильтрами. Биометрические шаблоны, полученные при выполнении "extract_policy", предоставляются в виде эталонов для сравнения. Сравнение можно выполнить несколькими способами:
- Лица установлены в качестве кандидатов. Сравнение выполняется с использованием БД Faces. В фильтрах можно указать необходимые списки с лицами.
- События устанавливаются в качестве кандидатов. Сравнение выполняется с использованием БД Events.
- Атрибуты устанавливаются в качестве кандидатов. Сравнение выполняется с использованием БД Redis.
6․ "conditional_tags_policy" обрабатывается сервисом Handlers.
7․ "storage_policy" обрабатывается в соответствии с указанными данными:
- Биометрические образцы лиц, тел и исходные изображения хранятся в сервисе Image Store;
- Атрибуты создаются и сохраняются в базе данных Redis сервисом Faces;
- Лица создаются и сохраняются в базе данных Faces сервиса Faces. Их также можно привязать к спискам с помощью политики "link_to_lists_policy";
- События сохраняются в базе данных Events сервисом Events;
- Уведомления отправляются через pub/sub в Redis (см. раздел "Сервис Sender").
8․ Сервис Handlers выдает результаты в сервис API.
Получение статистики по событиям и информации о событиях#
| Политика | Описание | Сервис |
|---|---|---|
| get statistics on events | Получить статистику по событиям. С помощью группы целевых полей (target) можно агрегировать события в соответствии с указанными агрегаторами: количество элементов, максимальное или минимальное значение, среднее значение, группировка. Также можно применять фильтры и периоды для выбора событий, которые следует агрегировать. Также возможна группировка по частоте или по временным интервалам. | POST |
| get events | Получить все события, удовлетворяющие указанным фильтрам. В фильтрах вы можете установить значения одного или нескольких полей событий. С помощью параметра target можно выбрать поля, которые необходимо получить в ответ. Можно оставить пустым поле запроса target. В этом случае будут показаны все данные о событиях. Также можно установить параметры сортировки, количество событий на странице и количество страниц. Если create_time__gte не задано, по умолчанию устанавливается один месяц |
GET |
| get event | Получить все поля для события. Для запроса необходимо указать event_id. | GET |
| check event existence | Проверить наличие указанного события. Для запроса необходимо указать event_id. | HEAD |
На диаграмме последовательности показана обработка запроса.
1․ API получает запрос к сервису Events.
2․ API отправляет запрос к сервису Events.
3․ Сервис Events получает необходимые данные из базы данных.
4․ Из базы данных выдается результат.
5․ Сервис Events выдает результаты.
6․ Сервис API выдает результаты.
Диаграммы задач#
В данном разделе приведены диаграммы последовательности выполнения задач.
В разделе "Общая диаграмма создания и выполнения задачи" приведен общий процесс обработки задач. Для некоторых задач процесс может отличаться. Например, для задачи Clustering создается только одна подзадача и используется только один "рабочий процесс". Для таких задач приведены отдельные комментарии.
Общая диаграмма создания и выполнения задачи#
Диаграмма общего процесса создания и выполнения задачи представлена ниже.
Обратите внимание, что "рабочий процесс" Tasks постоянно находится в ожидании получения каких-либо данных. У сервиса есть определенный приоритет выполнения работ, а именно:
1․ Проверка не нужно ли отменить текущую задачу/подзадачу (не отражено в диаграмме).
2․ Запросы на разделение на подзадачи.
3․ Запросы на объединение результатов.
4․ Запросы на обработку подзадач.
Это означает, что "рабочий процесс" Tasks не будет обрабатывать запрос на подзадачу, пока не выполнит проверку отмены текущей задачи.
Начало создания задачи#
В данном разделе описан процесс начала создания задачи.
1․ Сервис API получает запрос на создание задачи.
2․ Сервис API отправляет запрос в сервис Tasks.
3․ Сервис Tasks выполняет валидацию задачи, создает её и готовится к её обработке. На данном этапе сервис Tasks может выполнить дополнительные действия, например, получить "descriptor_id" для выполнения задачи "Additional extraction".
4․ Сервис Tasks отправляет данные о создаваемой задаче в БД Tasks.
5․ Сервис Tasks получает ответ.
6․ Сервис Tasks отправляет идентификатор задачи "task_id" в сервис API.
7․ Пользователь получает идентификатор задачи, т.е. сервис API выдает идентификатор созданной задачи и не дожидается завершения выполнения задачи. По данному идентификатору пользователь может оценить статус выполнения задачи.
Для получения отчета со статусом выполнения задачи и выполнения других действий с задачей необходимо использовать идентификатор задачи. Соответствующие запросы перечислены в разделе "Информация о задачах".
Разбиение задачи на подзадачи#
В данном разделе описан процесс разбиения задачи на подзадачи. Если для какой-то задачи предполагается только одна подзадача (например, задача Clustering), то задача разобьется на одну подзадачу согласно нижеописанному процессу.
8․ Сервис Tasks отправляет данные в Redis.
Сервис Tasks начинает ожидать появления подзадач в Redis.
"Рабочий процесс" Tasks ожидает появления данных в Redis для разбиения их на подзадачи.
9․ "Рабочий процесс" Tasks получает данные из Redis.
10․ "Рабочий процесс" Tasks выполняет процесс разделения на подзадачи.
11․ "Рабочий процесс" Tasks отправляет подзадачи обратно в Redis.
12․ Сервис Tasks получает подзадачи.
13․ Сервис Tasks сохраняет информацию о подзадачах в БД Tasks.
14․ Сервис Tasks отправляет подзадачи в Redis.
Обработка каждой подзадачи#
В данном разделе описан общий процесс обработки подзадачи. Для каждой задачи свой процесс обработки, описанный в соответствующем разделе ниже.
Сервис Tasks начинает ожидать появления сообщения о начале обработки подзадачи в Redis.
"Рабочий процесс" Tasks ожидает появления данных в Redis для обработки подзадачи.
15․ "Рабочий процесс" Tasks получает данные из Redis.
16․ "Рабочий процесс" Tasks начинает обрабатывать подзадачу.
17․ "Рабочий процесс" Tasks отправляет сообщение в Redis о том, что обработка началась.
18․ Сервис Tasks получает сообщение о начале обработки.
19․ Сервис Tasks обновляет информацию о задаче БД Tasks.
Сервис Tasks начинает ожидать появления результата.
20․ "Рабочий процесс" Tasks сохраняет отчет о задаче в сервис Image Store.
21․ Сервис Image Store отправляет запрос в хранилище на сохранение отчета.
Если сервис Image Store отключен, то отчет сохраняться не будет.
22․ Сервис Image Store получает ответ от сохранении.
23․ Сервис Image Store возвращает ответ "рабочему процессу".
24․ "Рабочий процесс" Tasks отправляет сообщение в Redis о том, что подзадача была обработана или о том, что во время обработки произошла какая-то ошибка.
25․ Сервис Tasks считывает соответствующее сообщение из Redis.
26․ Сервис Tasks обновляет информацию о задаче БД Tasks.
27․ После обработки последней подзадачи, сервис Tasks обновляет информацию о задаче БД Tasks.
Объединение результатов и завершение обработки#
В данном разделе описан общий процесс объединения результатов и завершения обработки. Если для какой-то задачи предполагается только одна подзадача (например, задача Clustering), то объединение результатов выполняться не будет. См. раздел "Завершение обработки задачи" для определенной задачи.
28․ Сервис Tasks создает внутреннюю задачу на объединение всех результатов и отправляет эту задачу в Redis.
Сервис Tasks начинает ожидать появления результата.
"Рабочий процесс" Tasks ожидает появления задачи на объединение.
29․ "Рабочий процесс" Tasks получает данные задачи на объединение.
30․ "Рабочий процесс" Tasks объединяет результаты всех подзадач.
31․ "Рабочий процесс" сохраняет отчет о задаче в сервис Image Store.
32․ Сервис Image Store отправляет запрос в хранилище на сохранение отчета.
Если сервис Image Store отключен, то отчет сохраняться не будет.
33․ Сервис Image Store получает ответ от сохранении.
34․ Сервис Image Store возвращает ответ сервису "рабочему процессу".
35․ "Рабочий процесс" Tasks отправляет результат объединения в Redis.
36․ Сервис Tasks считывает результат объединения из Redis.
37․ Сервис Tasks обновляет данные о задаче в БД Tasks.
38․ Сервис Tasks обновляет статус задачи в БД Tasks.
Общая диаграмма отмены задач#
Диаграмма общего процесса отмены задачи представлена ниже.
1․ Пользователь отправляет запрос на отмену задачи в сервис API.
2․ Сервис API направляет запрос на отмену задачи в сервис Tasks.
3․ Сервис API возвращает ответ, что был активирован процесс отмены задачи.
4․ Сервис Tasks обновляет статус задачи и её незавершенных подзадач на "cancelled" в БД Tasks.
5․ Сервис Tasks получает ответ.
6․ Сервис Tasks удаляет записи в Redis, которые относятся к отменяемой задаче.
7․ Сервис Tasks добавляет запись в Redis Stream о том, что задача должна быть отменена, если есть задачи, статус которых находится в "in_progress".
8․ "Рабочий процесс" Tasks обнаруживает запись на отмену в Redis Streams и удаляет её.
"Рабочий процесс" Tasks выполняет проверку наличия записей на протяжении всей обработки.
9․ "Рабочий процесс" Tasks отменяет обработку задачи.
10․ Сервис Tasks получает результат отмены из Redis.
Redis используется для хранения данных, включая записи, которые представлены как потоки событий в Redis Streams.
На данном этапе задача считается полностью отмененной, т.е. в ответах на запросы типа "get task" будет возвращен статус "2" ("cancelled").
Диаграмма задачи Clustering#
| Запрос | Описание | Метод |
|---|---|---|
| clustering task | Создать задачу Clustering для лиц или событий в соответствии с заданными фильтрами. | POST |
Создание задачи Clustering#
Создание задачи выполняется стандартным способ, описанным в разделе "Начало создания задачи" в разделе с общей диаграммой работы сервиса Tasks.
Разбиение задачи Clustering на подзадачу#
Для этого типа задач создается одна подзадача. Подзадача содержит фильтры, в соответствии с которыми выбираются лица или события. Подзадача обрабатывается одним "рабочим процессом".
См. "Разделение задачи на подзадачи" в разделе с общей диаграммой работы сервиса Tasks.
Обработка подзадачи Clustering#
Обработка подзадачи Clustering зависит от объектов (лиц или событий), указанных в запросе.
Общий процесс работы для обработки подзадачи показан ниже.
1․ "Рабочий процесс" Tasks получает данные из Redis.
2․ Лица: "Рабочий процесс" Tasks отправляет запрос в сервис Faces. "Рабочий процесс" запрашивает все необходимые идентификаторы атрибутов в соответствии с фильтрами, указанными в подзадаче.
3․ Лица: Сервис Faces отправляет запрос в БД Faces.
4․ Лица: Сервис Faces получает ответ.
5․ Лица: Сервис Faces отправляет идентификаторы "рабочему процессу" Tasks.
6․ События: "Рабочий процесс" Tasks отправляет запрос в сервис Events. "Рабочий процесс" запрашивает все необходимые идентификаторы атрибутов в соответствии с фильтрами, указанными в подзадаче.
7․ События: Сервис Events отправляет запрос в БД Events.
8․ События: Сервис Events получает ответ.
9․ События: Сервис Events отправляет данные "рабочему процессу" Tasks.
10․ Запрос на сравнение "рабочего процесса" Tasks. Обработка запросов выполняется по одной из схем, описанных в разделе "Диаграммы сравнения".
11․ Сервис Python Matcher отправляет результаты "Рабочему процессу" Tasks.
12․ Сервис Tasks сохраняет отчет о задаче в сервис Image Store.
13․ Сервис Image Store отправляет запрос в хранилище на сохранение отчета.
14․ Сервис Image Store получает ответ от сохранении.
15․ Сервис Image Store возвращает ответ сервису Tasks.
16․ "Рабочий процесс" Tasks отправляет результат в Redis.
Завершение обработки задачи Clustering#
Далее сервис Tasks получает результат из Redis и обновляет статус задачи в БД Tasks.
Диаграммы задачи Linker#
| Запрос | Описание | Метод |
|---|---|---|
| linker task | Создать задачу Linker. | POST |
Создание задачи Linker#
Задачу Linker можно создать для объектов лиц и событий. Процесс создания задачи Linker зависит от типа объекта.
Прикрепление лиц к списку
1․ Сервис API получает запрос на создание задачи.
2․ Сервис API отправляет запрос в сервис Tasks.
3․ Сервис Tasks создает задачу.
4․ Сервис Tasks отправляет информацию в базу данных Tasks.
5․ Из базы данных Tasks выдается идентификатор задачи.
6․ Идентификатор задачи отправляется в сервис API.
7․ Сервис API отправляет в ответ идентификатор задачи.
8․ Дополнительно. При указании в запросе идентификатора списка, сервис Tasks проверяет наличие списка.
9․ Дополнительно. Сервис Faces проверяет наличие списка в базе данных Faces.
10․ Дополнительно. Из базы данных Faces отправляется ответ.
11․ Дополнительно. Сервис Faces отправляет ответ в сервис Tasks.
12․ Дополнительно. Если указанный список не существует или в запросе указано создание нового списка, сервис Tasks отправляет запрос на создание нового списка.
13․ Дополнительно. Faces создает список в базе данных Faces.
14․ Дополнительно. Из базы данных Faces отправляется ответ.
15․ Дополнительно. Сервис Faces отправляет ответ в сервис Tasks.
16․ Сервис Tasks отправляет данные в Redis.
Прикрепление лиц, созданных на основе событий, к списку
1․ Сервис API получает запрос на создание задачи.
2․ Сервис API отправляет запрос в сервис Tasks.
3․ Сервис Tasks создает задачу.
4․ Сервис Tasks отправляют информацию в базу данных Tasks.
5․ Из базы данных Tasks выдается идентификатор задачи.
6․ Идентификатор задачи отправляется в сервис API.
7․ Сервис API отправляет в ответ идентификатор задачи.
8․ Дополнительно. При указании в запросе идентификатора списка, сервис Tasks проверяет наличие списка.
9․ Дополнительно. Сервис Faces проверяет наличие списка в базе данных Faces.
10․ Дополнительно. Из базы данных Faces отправляется ответ.
11․ Дополнительно. Сервис Faces отправляет ответ в сервис Tasks.
12․ Дополнительно. Если указанный список не существует или в запросе указано создание нового списка, сервис Tasks отправляет запрос на создание нового списка.
13․ Дополнительно. Faces создает список в базе данных Faces.
14․ Дополнительно. Из базы данных Faces отправляется ответ.
15․ Дополнительно. Сервис Faces отправляет ответ в сервис Tasks.
16․ Сервис Tasks получает идентификаторы лиц и идентификаторы атрибутов из сервиса Events.
17․ Сервис Events получает данные из базы данных Events.
18․ Из базы данных отправляется ответ.
19․ Сервис Faces отправляет идентификаторы в сервис Tasks.
20․ Сервис Tasks проверяет наличие лиц в сервисе Faces;
21․ Сервис Faces отправляет запрос в базу данных Faces.
22․ Из базы данных Faces отправляется информация о существовании лиц.
23․ Сервис Faces отправляет данные в сервис Tasks.
24․ Наличие лиц в базе данных Faces При наличии лица для события сервис Tasks проверяет, чтобы идентификатор атрибута лица совпадал с идентификатором атрибута события.
25․ Сервис Faces отправляет запрос в базу данных Faces.
26․ Из базы данных Faces отправляются идентификаторы атрибутов.
27․ Сервис Faces отправляет идентификаторы атрибутов в сервис Tasks. Если идентификаторы атрибутов для существующего лица и события не совпадают, выдается ошибка "28009: Attribute is not equal".
28․ Лица отсутствуют в базе данных Faces Если в базе данных Faces нет лиц с указанными идентификаторами, сервис Tasks отправляет запрос на создание новых лиц в базе данных Faces.
29․ Сервис Faces отправляет запрос в базу данных Faces.
30․ Из базы данных Faces отправляются результаты создания лиц.
31․ Сервис Faces отправляет ответ в сервис Tasks.
32․ Сервис Tasks отправляет данные в Redis.
Разбиение задачи Linker на подзадачи#
Для выполнения задачи может использоваться несколько "рабочих процессов". См. "Разделение задачи на подзадачи" в разделе с общей диаграммой работы сервиса Tasks.
Обработка подзадач Linker#
Общий процесс работы для обработки каждой подзадачи показан ниже.
1․ "Рабочий процесс" Tasks получает данные из Redis.
2․ "Рабочий процесс" Tasks запрашивает лица в сервисе Faces в соответствии с полученными идентификаторами лиц.
3․ Сервис Faces запрашивает лица в базе данных Faces.
4․ Из базы данных отправляются лица в сервис Faces.
5․ Сервис Faces отправляет лица "рабочему процессу" Tasks.
6․ "Рабочий процесс" Tasks отправляет запросы на прикрепление лиц к указанному списку.
7․ Сервис Faces отправляет запросы на прикрепление к базе данных.
8․ Из базы данных отправляется результат прикрепления в сервис Faces.
9․ Сервис Faces отправляет результат "рабочему процессу" Tasks.
10․ "Рабочий процесс" Tasks формирует отчет на основании результатов подзадачи и сохраняет его в сервисе Image Store.
11․ Сервис Image Store сохраняет отчет в хранилище.
12․ Из хранилища отправляется результат хранения. Результат имеет свой идентификатор.
13․ Сервис Image Store выдает результат "рабочему процессу" Tasks.
14․ "Рабочий процесс" Tasks отправляет результат в Redis.
Завершение обработки задачи Linker#
Далее выполняется объединение результатов подзадач и отправка общего отчета в Image Store. См. "Объединение результатов и завершение обработки" в разделе с общей диаграммой работы сервиса Tasks.
Диаграмма задачи Garbage collection#
| Запрос | Описание | Метод |
|---|---|---|
| garbage collection task | Создать задачу на удаление атрибутов, по заданному фильтру времени создания. Удаляются только те атрибуты, которые не прикреплены ни к одному лицу. С помощью этой задачи можно удалить неиспользуемые данные из базы данных Faces. | POST |
Создание задачи Garbage collection#
Создание задачи выполняется стандартным способ, описанным в разделе "Начало создания задачи" в разделе с общей диаграммой работы сервиса Tasks. Единственным отличием является то, что задачу Garbage collection можно создать не только через сервис API, но и через сервис Admin или Tasks.
Разбиение задачи Garbage collection на подзадачи#
Далее выполняется разделение задачи на подзадачи. Каждая подзадача содержит массив идентификаторов атрибутов. См. "Разделение задачи на подзадачи" в разделе с общей диаграммой работы сервиса Tasks.
Обработка подзадачи Garbage collection#
Общий процесс работы для обработки каждой подзадачи показан ниже.
1․ "Рабочий процесс" Tasks получает данные из Redis.
2․ Удаление лиц или БШ лиц. В "рабочем процессе" Tasks есть массив идентификаторов атрибутов, которые необходимо удалить. "Рабочий процесс" Tasks запрашивает удаление временных атрибутов и соответствующих БШ в сервисе Faces.
3․ Сервис Faces отправляет запрос в базу данных Faces на удаление атрибутов с указанными идентификаторами.
4․ Сервис Faces получает ответ.
5․ Сервис Faces отправляет ответ "рабочему процессу" Tasks.
6․ Удаление событий или БШ событий. В "рабочем процессе" Tasks есть массив идентификаторов атрибутов, которые необходимо удалить. "Рабочий процесс" Tasks запрашивает удаление временных атрибутов и соответствующих БШ в сервисе Events.
7․ Сервис Events отправляет запрос в базу данных Events на удаление атрибутов с указанными идентификаторами.
8․ Сервис Events получает ответ.
9․ Сервис Events отправляет ответ "рабочему процессу" Tasks.
10․ "Рабочий процесс" Tasks формирует отчет на основании результатов подзадачи и сохраняет его в сервисе Image Store.
11․ Сервис Image Store сохраняет отчет в хранилище.
12․ Из хранилища отправляется результат хранения. Результат имеет свой идентификатор.
13․ Сервис Image Store выдает результат "рабочему процессу" Tasks.
14․ "Рабочий процесс" Tasks отправляет результат в Redis.
Завершение обработки задачи Garbage collection#
Далее выполняется объединение результатов подзадач и отправка отчета в Image Store. См. "Объединение результатов и завершение обработки" в разделе с общей диаграммой работы сервиса Tasks.
Диаграмма задачи Reporter#
| Запрос | Описание | Метод |
|---|---|---|
| reporter task | Создать отчет для задачи Clustering. Отчет в формате CSV. Можно указать столбцы, которые необходимо добавить в отчет. Отчет находится в ZIP-архиве и содержит изображения аватаров для каждого объекта в кластере. | POST |
Создание задачи Reporter#
Создание задачи выполняется стандартным способ, описанным в разделе "Начало создания задачи" в разделе с общей диаграммой работы сервиса Tasks.
Разбиение задачи Garbage collection на подзадачу#
Для этого типа задач создается одна подзадача. Подзадача содержит фильтры для данных, которые необходимо получить для включения в отчет. См. "Разделение задачи на подзадачи" в разделе с общей диаграммой работы сервиса Tasks.
Обработка задачи Reporter#
Обработка запроса зависит от данных, хранящихся в отчете о кластеризации. Если отчет был создан для лиц, данные лица будут запрошены из сервиса Faces и добавлены в отчет. Если отчет был создан для событий, данные события будут запрошены из сервиса Events и добавлены в отчет.
Общий процесс работы для обработки подзадачи показан ниже.
1․ "Рабочий процесс" Tasks получение данных из Redis.
2․ "Рабочий процесс" Tasks запрашивает отчет о кластеризации в Image Store.
3․ Сервис Image Store запрашивает отчет из хранилища.
4․ Из хранилища отправляется ответ.
5․ Сервис Image Store отправляет отчет.
6․ Отчет по лицам. "Рабочий процесс" Tasks получает все идентификаторы лица из кластера и запрашивает дополнительные данные лица из сервиса Faces. Запрошенные данные зависят от столбцов, указанных в запросе.
7․ Сервис Faces запрашивает данные из базы данных Faces.
8․ Из базы данных Faces отправляются необходимые данные.
9․ Сервис Faces отправляет данные "рабочему процессу" Tasks.
10․ Отчет по событиям. "Рабочий процесс" Tasks запрашивает дополнительные данные о событиях из сервиса Events. Запрошенные данные зависят от столбцов, указанных в запросе.
11․ Сервис Events запрашивает данные из базы данных Events.
12․ Из базы данных Events отправляются необходимые данные.
13․ Сервис Events отправляет данные "рабочему процессу" Tasks.
14․ "Рабочий процесс" запрашивает изображение аватара для каждого лица или события. Изображение для лица указывается в поле "аватар" базы данных Faces. Его можно хранить в хранилище Image Store или любом другом. Изображение для события – это соответствующий биометрический образец из хранилища Image Store.
15․ Image Store запрашивает изображение из хранилища.
16․ Из хранилища отправляется изображение.
17․ Из сервиса Image Store отправляется изображение.
18․ Из "рабочего процесса" отправляется отчет в Image Store.
19․ С помощью Image Store отчет сохраняется в хранилище.
20․ Хранилище отправляет ответ о сохранении.
21․ Сервис Image Store отправляет ответ "рабочему процессу" Tasks.
22․ "Рабочий процесс" Tasks отправляет результат в Redis.
Завершение обработки задачи Reporter#
Далее сервис Tasks получает результат из Redis и обновляет статус задачи в БД Tasks.
Диаграмма задачи Exporter#
| Запрос | Описание | Метод |
|---|---|---|
| exporter task | Собрать данные о событиях/лицах и экспортировать в файл CSV. Экспортированный CSV файл находится в ZIP-архиве и содержит изображения аватаров для каждого объекта. | POST |
Создание задачи Exporter#
Создание задачи выполняется стандартным способ, описанным в разделе "Начало создания задачи" в разделе с общей диаграммой работы сервиса Tasks.
Разбиение задачи Exporter на подзадачу#
Для этого типа задач создается одна подзадача. См. "Разделение задачи на подзадачи" в разделе с общей диаграммой работы сервиса Tasks.
Обработка подзадачи Exporter#
Общий процесс работы для обработки подзадачи показан ниже.
1․ "Рабочий процесс" Tasks получение данных из Redis.
2․ Экспорт данных для лиц. "Рабочий процесс" Tasks получает все идентификаторы лица и запрашивает дополнительные данные лица из сервиса Faces. Запрошенные данные зависят от столбцов, указанных в запросе.
3․ Сервис Faces запрашивает данные из базы данных Faces.
4․ Из базы данных Faces отправляются необходимые данные.
5․ Сервис Faces отправляет данные "рабочему процессу" Tasks.
6․ Экспорт данных для событий. "Рабочий процесс" Tasks запрашивает дополнительные данные о событиях из сервиса Events. Запрошенные данные зависят от столбцов, указанных в запросе.
7․ Сервис Events запрашивает данные из базы данных Events.
8․ Из базы данных Events отправляются необходимые данные.
9․ Сервис Events отправляет данные "рабочему процессу" Tasks.
10․ "Рабочий процесс" запрашивает изображение аватара для каждого лица или события. Изображение для лица указывается в поле "аватар" базы данных Faces. Его можно хранить в хранилище Image Store или любом другом. Изображение для события – это соответствующий образец из хранилища Image Store.
11․ Image Store запрашивает изображение из хранилища.
12․ Из хранилища отправляется изображение.
13․ Из сервиса Image Store отправляется изображение.
14․ С "рабочего процесса" отправляются экспортированные данные в Image Store.
15․ С помощью Image Store отчет сохраняются экспортированные данные в хранилище.
16․ Хранилище отправляет ответ о сохранении.
17․ Сервис Image Store отправляет ответ "рабочему процессу" Tasks.
18․ "Рабочий процесс" Tasks отправляет результат в Redis.
Завершение обработки задачи Exporter#
Далее сервис Tasks получает результат из Redis и обновляет статус задачи в БД Tasks.
Диаграмма задачи Cross-matching#
| Запрос | Описание | Метод |
|---|---|---|
| cross-matching task | Создать задачу Cross-matching. С помощью данной задачи можно сравнить события и лица по заданным фильтрам. Лица и события могут быть указаны как эталоны и как кандидаты. Можно задать дополнительные фильтры, как для эталонов, так и для кандидатов. | POST |
Создание задачи Cross-matching#
Создание задачи выполняется стандартным способ, описанным в разделе "Начало создания задачи" в разделе с общей диаграммой работы сервиса Tasks.
Разбиение задачи Cross-matching на подзадачу#
Для этого типа задач создается одна подзадача. Подзадача содержит все необходимые фильтры эталонов и кандидатов. См. "Разделение задачи на подзадачи" в разделе с общей диаграммой работы сервиса Tasks.
Обработка подзадач Cross-matching#
Выполнение подзадач Cross-matching может варьироваться в зависимости от указанных эталонов и кандидатов.
Их можно указать с помощью лиц и/или событий. Далее на диаграммах запросы к сервисам Faces и Events отмечены как альтернативные. Запросы к сервису Faces используются, когда лица заданы в качестве эталонов или кандидатов. Запросы к сервису Events используются, когда события заданы в качестве эталонов или кандидатов.
Обработка задачи Clustering зависит от выбранных объектов (лиц или событий).
Общий процесс работы для обработки каждой подзадачи показан ниже.
1․ "Рабочий процесс" Tasks получение данных из Redis.
2․ Лица заданы в качестве эталонов или кандидатов. "Рабочий процесс" Tasks отправляет запрос в сервис Faces для получения идентификаторов атрибутов для лиц. Лица отбираются согласно заданным фильтрам;
3․ Сервис Faces запрашивает идентификаторы в базе данных Faces.
4․ Из базы данных Faces отправляются идентификаторы атрибутов.
5․ Сервис Faces отправляет идентификаторы атрибутов "рабочему процессу" Tasks.
6․ События заданы в качестве эталонов или кандидатов. "Рабочий процесс" Tasks отправляет запрос в сервис Events для получения идентификаторов атрибутов для событий. События отбираются согласно заданным фильтрам;
7․ Сервис Events запрашивает идентификаторы событий в базе данных Events.
8․ Из базы данных отправляются необходимые идентификаторы.
9․ Сервис Events отправляет идентификаторы "рабочему процессу" Tasks.
10․ Запрос на сравнение "рабочего процесса" Tasks. Обработка запросов выполняется по одной из схем, описанных в разделе "Диаграммы сравнения".
11․ Сервис Python Matcher отправляет результаты.
12․ Из "рабочего процесса" отправляется отчет в Image Store.
13․ С помощью Image Store отчет сохраняется в хранилище.
14․ Хранилище отправляет ответ о сохранении.
15․ Сервис Image Store отправляет ответ "рабочему процессу" Tasks.
16․ "Рабочий процесс" Tasks отправляет результат в Redis.
Завершение обработки задачи Cross-matching#
Далее сервис Tasks получает результат из Redis и обновляет статус задачи в БД Tasks.
Диаграмма задачи Estimator#
| Запрос | Описание | Метод |
|---|---|---|
| estimator task | Создать задачу Estimator. С помощью данной задачи можно выполнять пакетную обработку изображений с указанием заданных политик. | POST |
Создание задачи Estimator#
Создание задачи выполняется стандартным способ, описанным в разделе "Начало создания задачи" в разделе с общей диаграммой работы сервиса Tasks.
Разбиение задачи Estimator на подзадачу#
Для этого типа задач создается одна подзадача. Подзадача содержит все необходимые данные. См. "Разделение задачи на подзадачи" в разделе с общей диаграммой работы сервиса Tasks.
Обработка подзадачи Estimator#
Общий процесс работы для обработки подзадачи показан ниже.
1․ "Рабочий процесс" Tasks получение данных из Redis.
2․ "Рабочий процесс" запрашивает пакет изображений из следующих источников:
- сервиса Image Store в ZIP-архиве если в качестве источника изображений выбран тип "zip";
- хранилища S3 если в качестве источника изображений выбран тип "s3";
- FTP-сервера если в качестве источника изображений выбран тип "ftp";
- хранилища Samba если в качестве источника изображений выбран тип "samba";
- директории сетевого диска, которая смонтирована на локальный диск и синхронизирована с директорией в контейнерах сервиса Tasks и его "рабочего процесса" (см. подробное описание в разделе "Задача Estimator").
3․ Обработка параметров, указанных в запросе — авторизация, использование префиксов и т.п.
4․ Image Store/S3/Сетевой диск/FTP-сервер/Samba отправляет изображения "рабочему процессу" Tasks.
5․ Есть handler_id. "Рабочий процесс" Tasks отправляет запрос на получение идентификатора существующего обработчика в базу данных Handlers.
6․ Есть handler_id. Из базы данных Handlers "рабочему процессу" приходит ответ с идентификатором handler_id.
7․ Есть handler_id. "Рабочий процесс" отправляет запрос в сервис Handlers для обработки handler_id.
8․ Есть handler_id. Сервис Handlers обрабатывает пакет изображений по полученному handler_id в соответствии с заданными политиками (см. диаграмму создания события).
9․ Есть handler_id. Полученный ответ возвращается "рабочему процессу" Tasks.
10․ Нет handler_id. "Рабочий процесс" Tasks отправляет запрос на обработку политик, указанных прямо в запросе, в сервис Handlers.
11․ Нет handler_id. Сервис Handlers обрабатывает пакет изображений в соответствии с заданными политиками (см. диаграмму создания события).
12․ Нет handler_id. Полученный ответ возвращается "рабочему процессу" Tasks.
13․ Из "рабочего процесса" отправляется отчет в Image Store.
14․ С помощью Image Store отчет сохраняется в хранилище.
15․ Хранилище отправляет ответ о сохранении.
16․ Сервис Image Store отправляет ответ "рабочему процессу" Tasks.
17․ "Рабочий процесс" Tasks отправляет результат в Redis.
Завершение обработки задачи Estimator#
Далее сервис Tasks получает результат из Redis и обновляет статус задачи в БД Tasks.
Диаграммы задачи Additional extraction#
| Запрос | Описание | Метод |
|---|---|---|
| create additional extraction task | Извлечь все существующие биометрические шаблоны с использованием новой версии нейросети. | POST |
Создание задачи Additional extraction#
Запрос отправляется с помощью сервиса Admin. Диаграмма создания задачи приведена ниже.
1․ Администратор отправляет запрос в сервис Admin с помощью пользовательского интерфейса администратора или любого другого приложения.
2․ Сервис Admin отправляет запрос в сервис Tasks.
3․ Сервис Tasks отправляет запрос к сервису Faces на получение идентификаторов биометрических шаблонов, которые не были извлечены с помощью новой нейросети.
4․ Сервис Faces запрашивает необходимые идентификаторы.
5․ Сервис Faces получает необходимые идентификаторы.
6․ Сервис Faces отправляет идентификаторы в сервис Tasks.
7․ Сервис Tasks отправляет данные о создаваемой задаче в базу данных Tasks
8․ Сервис Tasks получает "task_id".
9․ Сервис Tasks отправляет идентификатор задачи в сервис Admin.
10․ Сервис Admin отправляет созданный идентификатор задачи в пользовательский интерфейс или приложение, используемое администратором.
11․ Сервис Tasks отправляет данные в Redis, откуда "рабочий процесс" заберет задачу на дальнейшую обработку.
Разделение задачи Additional extraction на подзадачи#
Далее выполняется разделение задачи на подзадачи. Каждая из подзадач содержит массив идентификаторов атрибутов. См. "Разделение задачи на подзадачи" в разделе с общей диаграммой работы сервиса Tasks.
Обработка подзадач Additional extraction#
Общий процесс работы для обработки каждой подзадачи показан ниже.
1․ "Рабочий процесс" Tasks получает данные из Redis.
2․ "Рабочий процесс" Tasks отправляет запрос в сервис Faces на получение всех требуемых биометрических шаблонов в соответствии с их идентификаторами.
3․ Сервис Faces отправляет запрос в базу данных.
4․ Из базы данных отправляются обратно необходимые БШ.
5․ Сервис Faces отправляет БШ "рабочему процессу" Tasks.
6․ Запрос на извлечение БШ отправляется в сервис Handlers.
7․ Сервис Handlers запрашивает биометрические образцы для извлечения из Image Store.
8․ Сервис Image Store запрашивает биометрические образцы из хранилища.
9․ Сервис Image Store получает биометрические образцы из хранилища.
10․ Сервис Image Store отправляет биометрические образцы в сервис Handlers.
11․ Сервис Handlers отправляет запрос на извлечение БШ в сервис Remote SDK.
12․ Сервис Remote SDK извлекает биометрические шаблоны.
13․ Из сервиса Remote SDK отправляются извлеченные БШ.
14․ Сервис Handlers отправляет БШ и базовые атрибуты в сервис Faces.
15․ Сервис Faces отправляет запрос на сохранение данных в базу данных.
16․ Из базы данных выдается результат сохранения данных.
17․ Сервис Faces выдает результат сохранения данных.
18․ Сервис Handlers отправляет результат выполнения задачи в сервис Tasks.
19․ "Рабочий процесс" Tasks отправляет результат в Redis.
Описанная последовательность выполняется для каждого "рабочего процесса" Tasks.
Завершение обработки задачи Additional extraction#
Далее выполняется объединение результатов подзадач и отправка отчета в Image Store. См. "Объединение результатов и завершение обработки" в разделе с общей диаграммой работы сервиса Tasks.
Диаграммы предоставления информации о задачах#
С помощью запросов, приведенных ниже, предоставляется информация о статусе существующих задач.
| Запрос | Описание | Метод |
|---|---|---|
| cancel task | Отменить выполнение задачи по ее task_id. | PATCH |
| get tasks | Получить информацию о задачах. Можно установить фильтры для задач. | GET |
| get tasks count | Получить количество задач по заданным фильтрам. | GET |
| get task | Получить информацию о задаче по её task_id | GET |
| get subtasks | Получить информацию обо всех подзадачах заданной задачи. | GET |
С помощью запросов, приведенных ниже, можно предоставить информацию об ошибках, возникших при обработке задач.
| Запрос | Описание | Метод |
|---|---|---|
| get errors of task | Получить информацию обо всех ошибках заданной задачи по task_id. | GET |
| get errors | Получить информацию обо всех ошибках по заданным фильтрам. | GET |
| get errors count | Получить количество ошибок по заданному фильтру. | GET |
| get error | Получить информацию об ошибке по task_id. | GET |
Соответствующая диаграмма представлена ниже.
1․ Запрос отправляется в API.
2․ Сервис API отправляет запрос в сервис на получение требуемых данных или выполнение требуемых действий.
3․ Сервис Tasks отправляет запрос в базу данных Tasks на получение требуемых данных или выполнение требуемых действий.
4․ Из базы данных отправляется ответ в сервис Tasks.
5․ Сервис Tasks отправляет ответ в сервис API.
6․ Сервис API выдает информацию.
| Запрос | Описание | Метод |
|---|---|---|
| delete task | Удалить заданную задачу и ее результаты. | DELETE |
| get task result | Получить результаты заданной задачи. | GET |
1․ Запрос отправляется в API.
2․ Сервис API отправляет запрос в сервис Tasks на получение требуемых данных задачи или удаление задачи.
3․ Сервис Tasks отправляет запрос в базу данных Tasks на получение требуемых данных или удаление задачи.
4․ Из базы данных отправляется ответ в сервис Tasks.
5․ Сервис Tasks отправляет запрос в Image Store для получения или удаления результатов заданной задачи.
6․ Сервис Image Store отправляет запрос в хранилище.
7․ Из хранилища отправляется ответ в сервис Image Store.
8․ Сервис Image Store выдает результат в сервис Tasks.
9․ Сервис Tasks отправляет ответ в сервис API.
10․ Сервис API отправляет ответ.
Диаграммы lambda#
Диаграмма создания lambda#
Данная диаграмма описывает общий процесс создания lambda.
| Запрос | Описание | Метод |
|---|---|---|
| create lambda | Создать lambda. | POST |
Общая схема обработки запроса:
1․ Пользователь определяет какой тип lambda ему будет нужен — Handlers-lambda, Standalone-lambda, Tasks-lambda.
2․ Пользователь пишет Python-код в соответствии с типом будущей lambda и требованиями к коду.
3․ Пользователь переносит модуль в архив в соответствии с требованиями к архиву.
4․ Пользователь выполняет запрос "create lambda" к сервису API.
5․ Сервис API отправляет запрос в сервис Lambda.
6․ Сервис Lambda отправляет запрос на проверку лицензии в сервис Licenses.
7․ Сервис Lambda получает ответ.
8․ Сервис Lambda записывает данные в БД Lambda, обновляя статус создания lambda на "waiting".
9․ Сервис Lambda получает ответ.
Во время создания lambda доступна возможность получения статуса её создания с помощью запроса "get lambda status".
10․ Сервис Lambda возвращает сервису API идентификатор "lambda_id".
11․ Сервис API возвращает пользователю идентификатор "lambda_id".
12․ Сервис Lambda добавляет дополнительные файлы и формирует новый архив.
13․ Сервис Lambda сохраняет новый архив в хранилище S3.
Создание образа
14․ Сервис Lambda оправляет запрос на создание образа в Kubernetes.
15․ Сервис Lambda обновляет статус создания образа на "in_progress".
16․ Сервис Lambda начинает отслеживать статус создания образа в Kubernetes.
Пользователь может получить статус и логи создания образа с помощью запросов "get lambda image creation status" и "get lambda image creation logs".
17․ Kubernetes получает архив из хранилища S3.
18․ Kubernetes создает образ.
19․ Kubernetes публикует образ в Docker registry.
Настройки S3, Docker registry и Kubernetes задаются в настройках сервиса Lambda.
20․ Сервис Lambda фиксирует публикацию образа.
21․ Сервис Lambda обновляет статус создания образа на "completed".
Создание lambda в кластере Kubernetes
22․ Сервис Lambda отправляет запрос на создание lambda в кластере Kubernetes.
23․ Сервис Lambda начинает отслеживать статус создания lambda в Kubernetes.
Во время создания lambda невозможно получить статус и логи создания образа. Статус создания и логи создания lambda можно получить с помощью запросов "get lambda status" и "get lambda logs".
24․ Kubernetes получает образ из Docker registry.
25․ Kubernetes разворачивает полученный образ.
26․ Сервис Lambda фиксирует состояние развернутого образа.
27․ Сервис Lambda обновляет статус lambda на "running" в БД Lambda.
28․ Сервис Lambda получает ответ.
Далее можно приступить к отправке запросов lambda.
Диаграмма обработки lambda#
Данная диаграмма описывает общий процесс обработки lambda. Процесс обработки lambda зависит от её типа — Standalone-lambda, Handlers-lambda или Tasks-lambda.
Обработка типа Tasks-lambda не отражена на данной диаграмме. Она выполняется согласно общему процессу создания задач, за исключением того, что вместо "рабочего процесса" Tasks используется сервис Lambda.
Для типов Handlers-lambda и Standalone-lambda можно выполнять запросы "proxy post request to lambda" для прямого взаимодействия с Kubernetes. Если Handlers-lambda может имитировать ответ классического обработчика, то можно выполнить запрос "generate events".
Общая схема обработки запроса:
Handlers-lambda
1․ Пользователь выполняет запрос "create handler" к сервису API, указывая "handler_type" = "2" и полученный "lambda_id" (см. "Диаграмма создания lambda").
2․ Сервис API отправляет запрос в сервис Handlers.
3․ Сервис Handlers выполняет проверку работоспособности (healthcheck) lambda, развернутой в Kubernetes, и создает обработчик.
4․ Сервис Handlers получает ответ.
5․ Сервис API получает идентификатор "handler_id".
6․ Пользователь получает идентификатор "handler_id".
Запрос на генерацию события
7․ Пользователь выполняет запрос "generate events" к сервису API, указывая полученный на предыдущем шаге "handler_id".
8․ Сервис API отправляет запрос в сервис Handlers.
9․ Сервис Handlers отправляет запрос на обработку в Kubernetes.
10․ В кластере Kubernetes обрабатывается пользовательский код.
Во время работы Handlers-lambda будет выполнено взаимодействие с некоторыми сервисами LUNA PLATFORM. См. раздел "Handlers-lambda" для дополнительной информации.
11․ Сервис Handlers получает ответ.
12․ Сервис API получает ответ.
13․ Пользователь получает ответ.
Прокси-запрос
14․ Пользователь выполняет запрос "proxy post request to lambda" к сервису API.
15․ Сервис API отправляет запрос в сервис Lambda.
16․ Сервис Lambda отправляет запрос на обработку в Kubernetes.
17․ В кластере Kubernetes обрабатывается пользовательский код.
Во время работы Handlers-lambda будет выполнено взаимодействие с некоторыми сервисами LUNA PLATFORM. См. раздел "Handlers-lambda" для дополнительной информации.
18․ Сервис Lambda получает ответ.
19․ Сервис API получает ответ.
20․ Пользователь получает ответ.
Прокси-запрос для Standalone-lambda
21․ Пользователь отправляет запрос "proxy post request to lambda" к сервису API.
22․ Сервис API отправляет запрос в сервис Lambda.
23․ Сервис Lambda отправляет запрос на обработку в Kubernetes.
24․ В кластере Kubernetes обрабатывается пользовательский код.
Во время работы Handlers-lambda будет выполнено взаимодействие с некоторыми сервисами LUNA PLATFORM. См. раздел "Standalone-lambda" для дополнительной информации.
25․ Сервис Lambda получает ответ.
26․ Сервис API получает ответ.
27․ Пользователь получает ответ.