Взаимодействие компонентов
В данном разделе схематично описаны основные взаимодействия компонентов системы, которые происходят при тех или иных операциях выполняемых пользователями в системе.
Работа с настройками компании
С помощью Back-end и Front-end выполняются настройки инстанса, маркетплейса и минимальных атрибутов матчинга. Для хранение данных о настройках компании, таких как:
- Наименование организации для отображения в маркетплейсе;
- Размера аудитории;
- Индустрии организации;
- Списка организация для взаимодействия;
- Списка минимальных полей матчинга;
Используются Redis и Blockchain, основным хранилищем настроек компании является Blockchain. Далее на схемах показано как происходит взаимодействие всех компонентов системы для чтения и редактирования этих настроек.
Отображение информации о настройках компании
Редактирование информации о настройках компании
Синхронизация и обновление метаданных
Синхронизация ClickHouse + Apache Atlas
Для обеспечения актуальных данных о структуре датасетов и поддержания структур данных между Apache Atlas и ClickHouse был реализован контейнер MetaDataSeed. Этот контейнер запускается по расписанию и выполняет обновление метаданных о датасетах в Apache Atlas. Схема работы этого процесса изображена на схеме:
Синхронизация Apache Atlas + ADCP + ADCP партнера
Для обеспечения актуальности данных используемых в рамках платформы и Apache Atlas был реализован набор микросервисов предназначенный для обновления данных как в собственном инстансе, так и в инстансах партнеров. Более подробно алгоритм их работы описан на схеме:
Загрузка excel-шаблона семантического слоя в Apache Atlas
В рамках платформы реализована возможность загрузки всего семантического слоя с помощью excel-файла, для этого реализован сервис MetaDataSeed и реализована возможность вызова этого сервиса через Back-end API. Общая схема реализации этого функционала описана в схеме:
Получение данных о бизнес-терминах и метаданных датасетов
Непосредственно Back-end API не хранит данные о датасетах и бизнес-терминах в собственной БД, хранением и обработкой занимается DataService, поэтому все запросы на получение справочной информации о датасетах и бизнес-терминах реализована с использованием DataService. Общий алгоритм взаимодействия описан в аналогичном процессе в DataService
Создание проекта DataLab
Проект - ключевая объединяющая сущность в системе. Сам проект содержит мало информации, но к нему привязаны другие объекты системы, такие как Группы матчинга, Виртуальные машины и Модели. Далее на схеме показан алгоритм создания проекта:
Матчинг и обработка данных
Создание матчинг-группы
Матчинг группы, фильтры датасетов в группах, атрибуты и веса атрибутов матчинга первоначально создаются и редактируются с помощью Back-end API. При их создании Back-end API сверяется с Blockchain и DataService о доступности датасетов, запрашиваемых полей, соответствие запрашиваемых полей и весов матчинга минимальным требованиям матчинга. При редактировании матчинг группы выполняется полностью аналогичный процесс. Более детально процесс описан на схеме:
Алгоритм матчинга
При расчете матчрейта, выгрузки данных на VM и исполнении модели в CleanRoom всегда используется сматченный датасет. Более подробно изучить работу алгоритма матчинга можно в соответствующем разделе пользовательских инструкций ссылке.
Матчинг групп в конструкторе
Матчинг датасетов в рамках группы происходит по упрощенному сценарию, по сравнению с выгрузкой данных, поскольку:
1) На этапе матчинга запрашиваются только аттрибуты матчинга
2) Результирующий датасет, в помощью которого рассчитывался матч-рейт удаляется и не выгружается на VM
Алгоритм матчинга в конструкторе выглядит следующим образом:
Создание запроса на данные
Для того чтобы совершить выгрузку данных, все участники обмена данными должны дать своё разрешение на обработку данных.
Алгоритм запроса данных выглядит следующим образом:
Подтверждение запроса данные
Для того чтобы при обработке данных была возможность получить данные для обработки, все участники обмена данных должны дать своё согласие на их обработку. В рамках согласования запроса на данные формируется JWT-токен для доступа к данным. Тип: одноразовый Формат кодирования: JWT Алгоритм подписи: HS256 Ключ: случайно сгенерированный секрет, хранящийся в файлах конфигурации DataService-модуля.
Алгоритм передачи согласования на обработку данных описан в следующей схеме:
Подтверждение скрипта
Для того, чтобы скрипт можно было запускать в Cleanroom, он должен быть согласован владельцами данных.
В рамках согласования скрипта на стороне анклава формируется подпись по алгоритму HMAC(hashScript,providerSecret).
Ниже представлен процесс согласования скрипта:
Согласование модели
Для того, чтобы иметь возможность исполнять модель, она должна быть согласована. То есть все компоненты витрина и скрипт модели должны получить статус Согласован.
Алгоритм согласования описан ниже:
Выгрузка матчинг-групп на VM / в Cleanroom
Выгрузка датасетов на VM или процесс получения датасета для обработки в CleanRoom похож на расчет на матчрейт за исключением того что:
1) При выгрузке получаются все поля которые запрашивались партнером
2) Результирующий датасет выгружается на VM или передается в CleanRoom для обработки скриптом
Алгоритм получения результирующего датасета выглядит следующим образом:
Исполнение модели Cleanroom
В рамках запуска модели выделяется 2 типа запуска:
- Отладка
- Продакшн
Основное отличие режимов состоит в том, будет ли записан результат исполнения модели в ClickHouse или нет.
Создание и передача лога об обращении к данным
При каждом обращении к данным датасета система формирует лог сообщение которое позволяет понять кто из партнеров получал доступ к данным, в каком виде и в рамках какого проекта. Алгоритм формирования сообщений выглядит следующим образом:
Поддержание структуры данных в актуальном состоянии при установке обновлений
Поскольку процесс обновление версии модулей в рамках системы осуществляется с обязательной перезагрузкой модуля, был реализован отдельный контейнер для применение миграций данных в MongoDB. Данный процесс запускается при каждой перезагрузке и проверяет необходимость обновления структуры данных в MongoDB. Общий алгоритм взаимодействия реализован согласно схеме: