Skip to main content
Version: 1.2.0

Взаимодействие компонентов

В данном разделе схематично описаны основные взаимодействия компонентов системы, которые происходят при тех или иных операциях выполняемых пользователями в системе.

Работа с настройками компании​

С помощью 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. Общий алгоритм взаимодействия реализован согласно схеме: