2. Структура Витрины данных

2.1. Составные части Витрины данных

Программа имеет модульную архитектуру и построена на базе отдельных компонентов (включая разработки сторонних производителей).

Общую схему взаимосвязей компонентов можно просмотреть в разделе Архитектура Витрины данных.

Основные компоненты

  • Prostore - основной компонент программы с открытым исходным кодом, обеспечивает единый интерфейс к хранилищу разнородных данных. Определяет структуры данных, запись и чтение данных Витрины. Позволяет работать со входящими в состав хранилища СУБД одинаковым образом, используя единый синтаксис запросов SQL и единую логическую схему данных. Prostore включает следующие компоненты:

    • Сервис исполнения запросов — анализирует и исполняет SQL-запросы; предоставляет REST API для JDBC-драйвера и взаимодействует с сервисом мониторинга статусов Kafka по REST API. В свою очередь состоит из следующих компонентов:

      • Коннектор Kafka-Postgres reader - считывает данные из PostgreSQL и передает их в брокер сообщений Kafka;

      • Коннектор Kafka-Postgres writer - записывает данные из брокера сообщений Kafka в PostgreSQL;

    • JDBC-driver - позволяет подключиться к Простору и выполнять SQL запросы по JDBC протоколу. JDBC-driver поставляется совместно с ПО Prostore в релизе Типового ПО «Витрина данных»;

  • Слой адаптеров - общее название логических модулей программы, которые обеспечивают подключение к СМЭВ4, как информационной системы участника взаимодействия. В зависимости от предназначения логические модули обеспечивают загрузку запросов из очереди ИС УВ в СМЭВ4 , формирование и отправку ответов в СМЭВ4, инициативное формирование уведомлений об изменении данных в экземпляре ПО «Витрина данных НСУД», отправку уведомлений в СМЭВ4, регистрацию реплики данных ИС УВ, подписки на репликацию и поддержку реплики в актуальном состоянии.

Компоненты, входящие в состав слоя адаптеров

  • СМЭВ3-адаптер - обеспечивает информационное взаимодействие через единый электронный сервис единой системы межведомственного электронного взаимодействия (далее – СМЭВ).

  • Сервис формирования документов - предназначен для обеспечения возможности формирования документов, в формате XML и PDF, на основе предварительно подготовленных pebble-шаблонов, с возможностью добавления к сформированным документам электронной подписи.

  • CSV-Uploader - программный модуль Витрины данных, предназначен для загрузки и выгрузки csv-файлов со структурой Витрины и csv-шаблонов с демо-шаблонами структуры Витрины, а также просмотра Журнала операций.

  • СМЭВ4-адаптер - Модуль исполнения запросов - предназначен для исполнения запросов СМЭВ4 (через протокол коммуникации Агент СМЭВ4).

  • СМЭВ4-адаптер – Модуль MPPR - предназначен для чтения данных в многопоточном режиме.

  • СМЭВ4-адаптер - Модуль MPPW - исполняет запросы в многопоточном режиме, записывающие данные в Prostore.

  • Модуль группировки чанков репликации - группирует фрагменты данных подписки, полученные из топика delta.in.rq и размещает их во временные топики с именем mppw.data.[hash (requestId+subscriptionId)].deltaNum.streamNum, отправляет команду в топик subscription.in модулю подписок при получении lastChunk на загрузку сгруппированных фрагментов (по каждой дельте каждого стрима).

  • СМЭВ4-адаптер - Модуль группировки данных табличных параметров - предназначен для группировки данных при выполнении запросов с табличными параметрами.

  • СМЭВ4-адаптер - Модуль импорта табличных параметров - предназначен для создания временных таблиц при выполнении временных запросов с табличными параметрами.

  • СМЭВ4-адаптер - Модуль дефрагментации чанков табличных параметров - образует пакеты с данными табличных параметров, поступающие от Агента СМЭВ4 в брокер сообщений Kafka, к формату, позволяющему обрабатывать их в многопоточном режиме.

  • СМЭВ4-адаптер - Модуль подписок - предназначен для управления подписками между Получателем данных (consumer) и Поставщиком данных (producer).

  • BLOB-адаптер - программный модуль Витрины данных, предназначен для получения доступа из Витрины данных к BLOB-объектам ведомства (BLOB-объект - это специальный тип двоичных данных, предназначенный для хранения бинарных файлов: изображений, скан-копий документов, текстовых файлов и т.д.).

  • DATA-Uploader - Модуль исполнения асинхронных заданий обеспечивает обработку очереди файлов, используя следующие функциональные особенности:

    • обработка очереди файлов производится циклами;

    • очередь файлов работает в режиме упорядочения процесса по принципу «первым пришел – первым обслужен»;

    • каждый элемент в очереди файлов содержит UUID задания, имя витрины и таблицы, содержимое CSV-файла;

    • файлы в очереди могут относится к разным витринам и/или разным таблицам одной витрины.

  • REST-Uploader - Модуль асинхронной загрузки данных из сторонних источников реализован для обеспечения параллельной загрузки данных с независимым масштабированием REST интерфейса.

  • REST-адаптер - сервис, реализующий публикацию конечных точек API для обработки запросов с использованием спецификации OpenAPI версии 3. Используется для сохранения обратной совместимости получения данных из ведомства по REST.

  • Counter-provider - Сервис генерации уникального номера (Counter-Provider) позволяет создавать неповторяющиеся уникальные порядковые номера для сквозной нумерации файлов в сервисе формирования документов Типового ПО Витрины данных конфигурации установки Стандарт.

  • СМЭВ QL Сервер - СМЭВ QL Сервер — приложение для конфигурирования и запуска типового API извлечения данных из хранилищ под управлением типового ПО «Витрина данных» от Минцифры (Ядро Prostore 6.1+). СМЭВ QL Сервер обладает характеристиками:

    • поддержка множественных источников данных Prostore;

    • выбор источника по условиям запроса;

    • защита атрибутов модели данных по их предоставлению;

    • автоматический параллелизм запросов к Prostore.

  • dtm-calcite-core - библиотека Calcite осуществляет парсинг классов, которые используются в библиотеке podd-adapter-calcite.

Дополнительные компоненты

Рекомендуемое программное обеспечение (не входит в поставку программы):

  • Агент СМЭВ4 - программное обеспечение, обеспечивающее сопряжение Типового ПО «Витрина данных» и ИС УВ с Ядром СМЭВ4.

  • СУБД Postgres (Postgres Pro) - Промышленная система управления базами данных для высоконагруженных систем. Официальный сайт разработчика приложения: https://postgrespro.ru/. Совместимость СУБД Postgres (Postgres Pro) с типовым ПО «Витрина Данных» в зависимости от версии указана на портале ЕСКС.

  • Брокер сообщений Kafka - используется для непрерывной передачи сообщений между СМЭВ4-адаптером - Модуль исполнения запросов и Агентом СМЭВ4.

  • Apache ZooKeeper - необходим для поддержки информации о конфигурации и распределенной координации между компонентами Витрины, также используется как сервисная база данных Prostore, для хранения технической информации (метаданных) от поступающих в Витрину данных запросах.

  • Docker - программное обеспечение для автоматизации развёртывания и управления программы в виртуальных средах с поддержкой контейнеризации. Используется для установки Arenadata Cluster Manager (ADCM). Официальный сайт разработчика приложения: https://www.docker.com/.

  • Elasticsearch - система поиска и аналитики, позволяет быстро в режиме реального времени хранить, искать и анализировать большие объемы данных и сохраняет их для Graylog. Для передачи сообщений в Graylog использует Filebeat. Официальный сайт разработчика приложения: https://www.elastic.co/elasticsearch/.

  • Filebeat - агент на сервере для отправки различных типов оперативных данных в Elasticsearch. Официальный сайт разработчика приложения: https://www.elastic.co/elasticsearch/.

  • Grafana - инструмент реализован в виде панели управления и мониторинга и позволяет визуализировать системные события программы на базе собираемых метрик. Официальный сайт разработчика приложения: https://grafana.com/docs/.

  • Graylog - программное обеспечение для управления лог-файлами. Официальный сайт разработчика приложения: https://www.graylog.org/;

  • МongoDB - база данных Graylog. Официальный сайт разработчика приложения: https://www.mongodb.com/.

  • Node_exporter - процессы, обеспечивающие сбор и передачу системных метрик серверу Prometheus. Также, используется для сбора метрик модулей СМЭВ4-адаптера и CSV-uploader см. https://github.com/prometheus/node_exporter.

  • Prometheus - используется как система мониторинга системных ресурсов программы. Связь компонентов реализована через HTTP. Данные хранятся локально, в собственной TSBD базе, индексы хранятся в LevelDB. Метрики представляют собой time-series данные. Каждая метрика состоит из имени метрики, временной метки и пары «ключ – значение». Визуализация осуществляется через подключение к Grafana. Официальный сайт разработчика приложения: https://prometheus.io/.

  • Redis - резидентная система управления базами данных класса NoSQL, работающая со структурами данных типа «ключ — значение».

Основные компоненты

  • Prostore - основной компонент программы с открытым исходным кодом, обеспечивает единый интерфейс к хранилищу разнородных данных. Определяет структуры данных, запись и чтение данных Витрины. Позволяет работать со входящими в состав хранилища СУБД одинаковым образом, используя единый синтаксис запросов SQL и единую логическую схему данных. Prostore включает следующие компоненты:

    • Сервис исполнения запросов — анализирует и исполняет SQL-запросы; предоставляет REST API для JDBC-драйвера и взаимодействует с сервисом мониторинга статусов Kafka по REST API. В свою очередь состоит из следующих компонентов:

      • Коннектор Kafka-Postgres reader - считывает данные из PostgreSQL и передает их в брокер сообщений Kafka;

      • Коннектор Kafka-Postgres writer - записывает данные из брокера сообщений Kafka в PostgreSQL;

    • JDBC-driver - позволяет подключиться к Простору и выполнять SQL запросы по JDBC протоколу. JDBC-driver поставляется совместно с ПО Prostore в релизе Типового ПО «Витрина данных»;

  • Слой адаптеров - общее название логических модулей программы, которые обеспечивают подключение к СМЭВ4, как информационной системы участника взаимодействия. В зависимости от предназначения логические модули обеспечивают загрузку запросов из очереди ИС УВ в СМЭВ4 , формирование и отправку ответов в СМЭВ4, инициативное формирование уведомлений об изменении данных в экземпляре ПО «Витрина данных НСУД», отправку уведомлений в СМЭВ4, регистрацию реплики данных ИС УВ, подписки на репликацию и поддержку реплики в актуальном состоянии.

Компоненты, входящие в состав слоя адаптеров

  • CSV-Uploader - программный модуль Витрины данных, предназначен для загрузки и выгрузки csv-файлов со структурой Витрины и csv-шаблонов с демо-шаблонами структуры Витрины, а также просмотра Журнала операций.

  • СМЭВ4-адаптер - Модуль исполнения запросов - предназначен для исполнения запросов СМЭВ4 (через протокол коммуникации Агент СМЭВ4).

  • СМЭВ4-адаптер – Модуль MPPR - предназначен для чтения данных в многопоточном режиме.

  • СМЭВ4-адаптер - Модуль MPPW - исполняет запросы в многопоточном режиме, записывающие данные в Prostore.

  • Модуль группировки чанков репликации - группирует фрагменты данных подписки, полученные из топика delta.in.rq и размещает их во временные топики с именем mppw.data.[hash (requestId+subscriptionId)].deltaNum.streamNum, отправляет команду в топик subscription.in модулю подписок при получении lastChunk на загрузку сгруппированных фрагментов (по каждой дельте каждого стрима).

  • СМЭВ4-адаптер - Модуль подписок - предназначен для управления подписками между Получателем данных (consumer) и Поставщиком данных (producer).

  • СМЭВ4-адаптер - Модуль группировки данных табличных параметров - предназначен для группировки данных при выполнении запросов с табличными параметрами.

  • СМЭВ4-адаптер - Модуль импорта табличных параметров - предназначен для создания временных таблиц при выполнении временных запросов с табличными параметрами.

  • СМЭВ4-адаптер - Модуль дефрагментации чанков табличных параметров - образует пакеты с данными табличных параметров, поступающие от Агента СМЭВ4 в брокер сообщений Kafka, к формату, позволяющему обрабатывать их в многопоточном режиме.

Дополнительные компоненты

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

  • Брокер сообщений Kafka — используется для непрерывной передачи сообщений между:

    • CSV-uploader и Prostore;

    • СМЭВ4-адаптером - Модуль исполнения запросов и Агент СМЭВ4.

  • Ansible — платформа удалённого управления конфигурациями программного обеспечения, предназначенная для упрощения развёртывания Компонент «Витрина данных Лайт» через создание специальных сценариев. Официальный сайт разработчика приложения: https://www.ansible.com/.

  • СУБД Postgres - Промышленная система управления базами данных для высоконагруженных систем. Официальный сайт разработчика приложения: https://postgrespro.ru/.

  • Docker — программное обеспечение для автоматизации развёртывания и управления программы в виртуальных средах с поддержкой контейнеризации. Контейнер позволяет производить изолированный запуск ОС с подключённой файловой системой из образа, изолированно разворачивать приложения и реализовывать микросервисы. Настройки среды хранятся в GitHub, обеспечивая единую точку управления конфигурациями. Может быть использован для для развёртывания тестового окружения Компонент «Витрина данных Лайт», без прерывания работы сервисов в продуктовой среде. Официальный сайт разработчика приложения: https://www.docker.com/.

  • Elasticsearch — утилита полнотекстового поиска и аналитики, которая позволяет быстро в режиме реального времени хранить, искать и анализировать большие объемы данных и сохраняет их для Graylog. Для передачи сообщений в Graylog использует Filebeat. Официальный сайт разработчика приложения: https://www.elastic.co/elasticsearch/.

  • Filebeat — агент на сервере для отправки различных типов оперативных данных в Elasticsearch. Официальный сайт разработчика приложения: https://www.elastic.co/elasticsearch/.

  • Grafana — инструмент реализован в виде панели управления и мониторинга и позволяет визуализировать системные события программы на базе собираемых метрик. Официальный сайт разработчика приложения: https://grafana.com/docs/.

  • Graylog — программное обеспечение для управления лог-файлами. Официальный сайт разработчика приложения: https://www.graylog.org/.

  • МongoDB — база данных Graylog. Официальный сайт разработчика приложения: https://www.mongodb.com/.

  • Node_exporter — процессы, обеспечивающие сбор и передачу системных метрик серверу Prometheus. Также, используется для сбора метрик СМЭВ4-адаптера и CSV-uploader см. https://github.com/prometheus/node_exporter.

  • Portainer — web-приложение для управления docker-контейнерами. Официальный сайт разработчика приложения: https://www.portainer.io/.

  • Prometheus — используется как система мониторинга системных ресурсов Компонент «Витрина данных Лайт». Связь компонентов реализована через HTTP. Данные хранятся локально, в собственной TSBD базе, индексы хранятся в LevelDB. Метрики представляют собой time-series данные. Каждая метрика состоит из имени метрики, временной метки и пары «ключ – значение». Визуализация осуществляется через подключение к Grafana. Официальный сайт разработчика приложения: https://prometheus.io/.

  • PostrgeSQL — база данных Prostore.

2.2. Состав компонентов в дистрибутиве

Состав компонентов в дистрибутиве конфигурации Стандарт версии 1.17.1 приведен в таблице ниже (см. Таблица 2.1)

Таблица 2.1 Состав компонентов в дистрибутиве программы

Наименование компонента

Версия

Техническое наименование

query-execution

6.12.2

query-execution:6.12.2

jdbc-driver

6.12.2

jdbc-driver:6.12.2

backup-manager

1.17.1

backup-manager:1.17.1

blob-adapter

1.17.1

blob-adapter:1.17.1

counter-provider

1.17.1

counter-provider:1.17.1

csv-uploader

1.17.1

csv-uploader:1.17.1

data-uploader

1.17.1

data-uploader:1.17.1

dtm-uploader

1.17.1

dtm-uploader:1.17.1

podd-adapter-group-repl

1.17.1

podd-adapter-group-repl:1.17.1

podd-adapter-group-tp

1.17.1

podd-adapter-group-tp:1.17.1

podd-adapter-import-tp

1.17.1

podd-adapter-import-tp:1.17.1

podd-adapter-mppr

1.17.1

podd-adapter-mppr:1.17.1

podd-adapter-mppw

1.17.1

podd-adapter-mppw:1.17.1

podd-adapter-query

1.17.1

podd-adapter-query:1.17.1

podd-adapter-replicator

1.17.1

podd-adapter-replicator:1.17.1

podd-avro-defragmentator

1.17.1

podd-avro-defragmentator:1.17.1

printable-form-service

1.17.1

printable-form-service:1.17.1

rest-adapter

1.17.1

rest-adapter:1.17.1

rest-uploader

1.17.1

rest-uploader:1.17.1

smevql-server

1.2.0

smevql-server:1.2.0

СМЭВ3-адаптер

1.17.1

smev3-adapter:1.17.1

dtm-tools

1.17.1

dtm-tools:1.17.1

greenplum-kafka PXF connector reader

1.3.0

pxf-kafka:1.3.0

kafka-greenplum PXF connector writer

1.2.0

pxf-kafka-greenplum:1.2.0

kafka-clickhouse-reader

3.14.0

kafka-clickhouse-reader:3.14.0

kafka-clickhouse-writer

3.14.0

kafka-clickhouse-writer:3.14.0

kafka-postgres-writer

0.11.0

kafka-postgres-writer:0.11.0

kafka-postgres-reader

0.11.0

kafka-postgres-reader:0.11.0

kafka-jet-writer

1.5.0

kafka-jet-writer:1.5.0

Дистрибутив программы версии 1.17.1 тестировался с компонентами, приведенными в Таблица 2.2

Таблица 2.2 компоненты для тестирования программы

Наименование компонента

Версия

Техническое наименование

Агент СМЭВ4

3.20.1

Агент СМЭВ4:3.20.1

kafka

2.6.0

kafka:2.6.0

PostgreSQL

13.4

postgreSQL:13.4

redis

7.0.11

redis:7.0.11

Примечание

Дополнительные компоненты не входят в дистрибутив Программы

Конкретная конфигурация Витрины данных определяется Участником взаимодействия на этапе реализации Витрины данных в составе ИТ-инфраструктуры Участника взаимодействия.

Состав компонентов в дистрибутиве конфигурации Лайт версии 1.17.1 приведен в таблице ниже (см. Таблица 2.3)

Таблица 2.3 Состав компонентов в дистрибутиве программы

Наименование компонента

Версия

Техническое наименование

graylog

4.3.15

graylog:4.3.15

prometheus

2.34.0

prometheus:2.34.0

query-execution

6.12.2

query-execution:6.12.2

jdbc-driver

6.12.2

jdbc-driver:6.12.2

podd-adapter-replicator

1.17.1

podd-adapter-replicator:1.17.1

podd-adapter-mppw

1.17.1

podd-adapter-mppw:1.17.1

podd-adapter-mppr

1.17.1

podd-adapter-mppr:1.17.1

podd-adapter-group-repl

1.17.1

podd-adapter-group-repl:1.17.1

podd-adapter-query

1.17.1

podd-adapter:1.17.1

podd-adapter-group-tp

1.17.1

podd-adapter-group-tp:1.17.1

podd-adapter-import-tp

1.17.1

podd-adapter-import-tp:1.17.1

podd-avro-defragmentator

1.17.1

podd-avro-defragmentator:1.17.1

csv-uploader

1.17.1

csv-uploader:1.17.1

kafka-jet-writer

1.5.0

kafka-jet-writer:1.5.0

grafana

9.5.2

grafana:9.5.2

node_exporter

1.3.1

node_exporter:1.3.1

filebeat

7.10.2

filebeat:7.10.2

mongo

4.4

mongo:4.4

opensearch

1.3.14

opensearch:1.3.14

kafka-postgres-writer

0.11.0

kafka-postgres-writer:0.11.0

kafka-postgres-reader

0.11.0

kafka-postgres-reader:0.11.0

postgres

13.4

postgres:13.4

kafka

2.13

kafka:2.13-2.6.0-alt-p10-r3

zookeeper

3.6.0

zookeeper:3.6.0-alt-p10-r3

portainer

2.14.0

portainer:2.14.0

2.3. Cвязи между компонентами

Cвязи между компонентами конфигурации Стандарт приведены в Таблица 2.4.

Таблица 2.4 Взаимодействие между составными частями

Клиент

Сервер

Способ взаимодействия

Описание

Сервисная база данных Prostore (PostgreSQL)

Prostore

TCP

Хранение/получение метаданных

СУБД хранилища

Apache Kafka

СМЭВ4 Адаптер

ETL

Prostore

Хранилище СУБД

REST API

в зависимости

от типа СУБД хранилища данных

Перенаправление запросов в конкретную СУБД

REST-адаптер

Prostore

REST API

Исполнение запросов

ETL

Prostore

Kafka (Диспетчер сообщений)

JDBC

Исполнение запросов

Сервис формирования документов

Prostore

REST API

Запрашивает данные для формирования ПФ

СМЭВ3-адаптер

Prostore

Kafka (Диспетчер сообщений)

REST API

Исполнение запросов

BLOB-адаптер

HTTP

Запрашивает бинарное содержимое BLOB.

СМЭВ4-адаптер - Модуль исполнения запросов

Prostore

REST API

  • исполняет полученный запрос (LLR);

  • запрашивает структуру таблиц при подписании на репликацию (источник данных);

  • создает структуру таблиц при подписании на репликацию (потребитель данных);

Диспетчер сообщений Kafka

Kafka (Диспетчер сообщений)

  • получает сообщение о закрытии новой дельты в Prostore (для репликации, источник данных);

  • обменивается управляющей информацией с модулем импорта ТП;

  • отправляет запросы, перенаправленные в Модуль MPPR.

СМЭВ4-адаптер - Модуль MPPR

Prostore

REST API

Подает запрос MPPR.

Диспетчер сообщений Kafka

Kafka

  • получает запросы данных СМЭВ4, перенаправленные СМЭВ4 Адаптером;

  • получает запрошенные данные из Prostore (в формате MPPR);

  • передает запрошенные данные в СМЭВ4 в формате СМЭВ4;

  • обменивается управляющей информацией с модулем импорта ТП.

СМЭВ4-адаптер - Модуль MPPW

Prostore

REST API

Подает запрос MPPW.

Диспетчер сообщений Kafka

Kafka

  • получает записываемые данные, подготовленные модулем Группировки данных ТП;

  • передает записываемые данные в Prostore (в формате MPPW);

  • обменивается управляющей информацией с модулем импорта ТП.

СМЭВ4-адаптер - Модуль импорта ТП

Prostore

REST API

  • создает табличный параметр (перед выполнением запроса);

  • удаляет табличный параметр (после выполнения запроса).

Диспетчер сообщений Kafka

Kafka

Обменивается управляющей информацией с модулями:

  • MPPW;

  • MPPR;

  • СМЭВ4 Адаптер;

  • Группировки данных ТП.

СМЭВ4-адаптер - Модуль Группировки данных ТП

Диспетчер сообщений Kafka

Kafka

  • Получает сообщения с ТП, подготовленные Модуль дефрагментации чанков табличных параметров (из единого топика);

  • Создает отдельные топики для каждого ТП и передает в них сообщения с данными этого ТП.

СМЭВ4-адаптер - Модуль дефрагментации чанков табличных параметров

Диспетчер сообщений Kafka

Kafka

Передает сообщения с ТП, в формате пригодном для параллельной обработки

Сервисная СУБД Zookeeper

TCP

Сохраняет список обрабатываемых сообщений ТП

Хранение метаданных о подписках на репликацию (источник данных).

Cвязи между компонентами конфигурации Лайт приведены в Таблица 2.5.

Таблица 2.5 Взаимодействие между составными частями

Клиент

Сервер

Способ взаимодействия

Описание

СМЭВ4-адаптер —

Модуль исполнения запросов

Prostore

JDBC

Брокер сообщений Kafka

Исполнение запросов.

CSV-Uploader

Prostore

JDBC

Брокер сообщений Kafka

Управление логической структурой таблиц.

Загрузка публикуемых данных в Витрину.

Prostore

СУБД PostgreSQL

JDBC

Управление логической структурой таблиц.

Исполнение запросов.

Управление загрузкой публикуемых данных в Витрину.

СМЭВ4 - адаптер — Модуль MPPR

Агент СМЭВ4

Через брокера сообщений Kafka

Предоставляет Результат запрос/подзапрос на получение публикуемых данных

(в т.ч. с использованием ТП), делегированного СМЭВ4-адаптером.

2.4. Модули Витрины данных

Примечание

Описание настроек модулей, процессы запуска и остановки модуля см. «Руководстве администратора».

2.4.1. СМЭВ4-адаптер - Модуль исполнения запросов

Примечание

Модуль входит в состав конфигурации Стандарт и Лайт

2.4.1.1. Общее описание

Логический модуль СМЭВ4-адаптер - Модуль исполнения запросов предназначен для исполнения запросов СМЭВ4 (через протокол коммуникации Агент СМЭВ4).

Установка опциональна модуля опциональна.

Обмен сообщениями между Модулем исполнения запросов и Агентом СМЭВ4 происходит через заранее согласованные топики брокера сообщений Kafka.

Формат обмена электронными сообщениями описан в разделе Спецификация Модуля исполнения запросов Приложения 1.

2.4.1.1.1. Общая схема взаимодействия через СМЭВ4-адаптер- Модуль исполнения запросов
Взаимодействие программы с СМЭВ4

Рисунок - 2.1 Взаимодействие программы с СМЭВ4

2.4.1.1.2. Процесс обработки запроса через СМЭВ4-адаптер- Модуль исполнения запросов

  1. Получатель данных отправляет через СМЭВ4 запрос к Витрине данных.

  2. Запрос поступает в Агент СМЭВ4.

  3. Модуль исполнения запросов (через заранее согласованные топики брокера сообщений Kafka) получает запрос от Агента СМЭВ4 на предоставление данных.

  4. Модуль исполнения запросов обрабатывает запрос и отправляет его в Витрину данных.

  5. Витрина данных обрабатывает запрос и формирует на него ответ в СМЭВ4-адаптер.

  6. Модуль исполнения запросов обрабатывает ответ, записывает результат в заранее согласованные топик обмена сообщениями и предоставляет ответ Агенту СМЭВ4.

  7. Агент СМЭВ4 отправляет полученный ответ через СМЭВ4 Получателю данных.

Процесс получения BLOB-объектов через Модуль исполнения запросов описан в разделе Взаимодействие через СМЭВ-адаптер.

2.4.2. СМЭВ4-адаптер - Модуль подписок

Примечание

Модуль входит в состав конфигурации Стандарт и Лайт

2.4.2.1. Общее описание

СМЭВ4-адаптер - Модуль подписок предназначен для управления подписками между Получателем данных (consumer) и Поставщиком данных (producer).

Модуль используется для получения результатов комплексных запросов из нескольких Витрин источников. Подписка позволяет автоматически загрузить и поддерживать в актуальном состоянии данные из Витрины Поставщика в специальном хранилище на стороне Потребителя - Хранилище данных по подписке. Потребитель посылает запросы напрямую в своё Хранилище данных по подписке, в результате чего сокращается продолжительность сеансов обмена и необходимость «склейки» запросов на стороне СМЭВ4.

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

Модуль решает следующие задачи:

  • запрос создания подписки (Поставщик данных);

  • запрос отмены подписки (Поставщик данных);

  • запрос дельты (Поставщик данных);

  • запрос создания структуры по подписке (Получатель данных);

  • запрос применения дельты (Получатель данных).

Формат обмена электронными сообщениями описан в разделе Спецификация Модуля исполнения запросов Приложения 1.

Потребители данных могут получать сведения из Витрин Поставщиков данных путем:

  1. отправки регламентированных запросов;

  2. подписки на изменения сведений.

Подписка позволяет автоматически загрузить и поддерживать в актуальном состоянии данные из Витрины Поставщика в специальном хранилище на стороне Потребителя (Хранилище данных по подписке) и Потребитель посылает запросы напрямую в своё Хранилище, в результате чего сокращается продолжительность сеансов обмена и необходимость «склейки» запросов на стороне СМЭВ4.

Информационный обмен по подписке состоит из следующих этапов:

  1. Регистрация подписки в Витрине Поставщика данных и создание структуры данных в Хранилище Потребителя данных.

  2. Передача снапшота из Витрины Поставщика данных в Хранилище Потребителя данных (только для подписки на репликацию). В текущей реализации снапшот не содержит историчность.

  3. Актуализация данных посредством передачи пакета дельт от Витрины Поставщика данных в Хранилище Потребителя данных в одном из режимов:

  • по расписанию (если оно указано в подписке);

  • по событию об изменении данных (если расписание не указано в подписке).

Подписка определяется следующими параметрами:

  • уникальный идентификатор подписки;

  • источник данных по подписке – мнемоника Витрины Поставщика данных;

  • адресат данных по подписке – мнемоника Витрины Потребителя данных;

  • набор SQL-выражений, каждое из которых описывает подмножество данных Витрины;

  • расписание синхронизации (может отсутствовать).

Виды подписок:

  • Подписка на репликацию - снэпшот текущего состояния витрины;

  • Подписка на уведомление - выгружаем данные только по дельте.

Реализованы два варианта подписки:

  • одиночная;

  • распределенная.

Ключевые особенности одиночных подписок:

  • подписка только на один датамарт;

  • в одиночных подписках можно создать подписку с множественными SQL-запросами к разным таблицам одной витрины.

Ключевые особенности распределенных подписок:

  • количество витрин-источников больше 1;

  • одной подписке соответствует один SQL-запрос;

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

В случае необходимости отключить подписку, осуществляется отмена подписки через ВС «Отмена подписки на репликацию или уведомлений в изменении данных».

2.4.3. СМЭВ4-адаптер – Модуль MPPR

Примечание

Модуль входит в состав конфигурации Стандарт и Лайт

2.4.3.1. Общее описание

Логический модуль СМЭВ4-адаптер - Модуль MPPR является частью СМЭВ4-адаптера и предназначен для чтения данных в многопоточном режиме (MPP - massively parallel processing).

Модуль MPPR предназначен для следующих задач:

  1. Многопоточное параллельное чтение данных.

  2. Отправка ответа с результатом запроса в Агент СМЭВ4.

  3. Удаление временных таблиц, созданных на основе табличных параметров.

Обмен сообщениями между СМЭВ4-адаптером и Модулем MPPR происходит через топик mppr.query.

Формат обмена электронными сообщениями описан в разделе Спецификация Модуля исполнения запросов Приложения 1.

2.4.3.1.1. Общая схема взаимодействия
Взаимодействие через Модуль MPPR

Рисунок - 2.2 Взаимодействие через Модуль MPPR

2.4.3.1.2. Процесс обработки запроса через Модуль MPPR

  1. Получатель данных отправляет через СМЭВ4 запрос к Витрине данных.

  2. Запрос поступает через Агент СМЭВ4 в СМЭВ4-адаптер.

  3. Если формат обработки данных предполагает MPP, то СМЭВ4-адаптер отправляет запрос через топик mppr.query в Модуль MPPR.

  4. Модуль MPPR создает временную таблицу (по результатам запроса) и временный топик с запросом для Витрины.

  5. Витрина считывает топик, обрабатывает запрос, формирует на него ответ.

  6. Модуль MPPR получает ответ и выкладывает полученные данные во временную таблицу.

  7. СМЭВ4-адаптер считывает ответ из временной таблицы и отправляет данные в Агент СМЭВ4.

  8. Агент СМЭВ4 отправляет полученный ответ через СМЭВ4 Получателю данных.

  9. Модуль MPPR удаляет временный топик и таблицу.

2.4.4. СМЭВ4-адаптер - Модуль MPPW

Примечание

Модуль входит в состав конфигурации Стандарт и Лайт

2.4.4.1. Общее описание

Модуль СМЭВ4-адаптер-Модуль MPPW исполняет запросы в многопоточном режиме, записывающий данные в Prostore.

Модуль предназначен для следующих задач:

  1. Записывать данные в базу данных Prostore при получении команд от других модулей программы.

  2. Оповещать другие модули об успешной и/или неуспешной записи данных в базу данных Prostore.

Формат обмена электронными сообщениями описан в разделе Спецификация Модуля исполнения запросов «Приложения 1.

2.4.5. СМЭВ4-адаптер - Модуль группировки чанков репликации

Примечание

Модуль входит в состав конфигурации Стандарт и Лайт

2.4.5.1. Общее описание

Модуль группировки чанков репликации на стороне Витрины потребителя при обмене по подписке группирует фрагменты данных подписки, полученные из топика delta.in.rq и размещает их во временные топики с именем mppw.data.[hash (requestId+subscriptionId)].deltaNum.streamNum, отправляет команду в топик subscription.in модулю подписок при получении lastChunk на загрузку сгруппированных фрагментов (по каждой дельте каждого стрима).

2.4.5.1.1. Интерфейсы модуля

Входящие топики

  • delta.in.rq

Исходящие топики

  • subscription.in

  • mppw.data.[hash (requestId+subscriptionId)].deltaNum.streamNum

2.4.5.1.2. Процесс обработки запроса через Модуль MPPR

  1. Модуль группировки чанков репликации считывает сообщение с фрагментом какой-то таблицы (в рамках какой-то дельты) из delta.in.rq.

  2. Модуль группировки чанков репликации отправляет полученный фрагмент в динамический топик с именем, содержащим [hash (requestId+subscriptionId)], synId (номер дельты) и streamNum - топик mppw.data.X

  3. Если полученный фрагмент является последним ( isLastChunk: true), то Модуль группировки чанков репликации отправляет сообщение (subscriptionId, synId (номер дельты), tableId) в топик subscription.in.

  4. Модуль группировки чанков репликации подтверждает обработку (committing an offset) сообщения с фрагментом в delta.in.rq.

Внимание

Для корректной работы модуля версии 1.17.0 и выше необходимо использовать Zookeeper версии не ниже 3.6.

2.4.6. CSV-Uploader

Примечание

Модуль входит в состав конфигурации Стандарт и Лайт

2.4.6.1. Общее описание

CSV-uploader - программный модуль Витрины данных, который предназначен для загрузки CSV-файлов в Витрину данных.

CSV-uploader предназначен для следующих задач:

  • загрузка CSV-файлов;

  • загрузка CSV-файлов со структурой Витрины;

  • выгрузка CSV-шаблонов с демо-шаблонами структуры Витрины;

  • автоматический запуск загрузки CSV-файлов по расписанию из выбранного каталога;

  • просмотр Журнала операций.

Внимание

Загружаемые файлы обязательно должны быть в кодировке UTF-8

2.4.6.1.1. Общая схема взаимодействия через CSV-uploader
Общая схема взаимодействия через CSV-uploader

Рисунок - 2.3 Общая схема взаимодействия через CSV-uploader

2.4.7. СМЭВ4-адаптер - Модуль импорта табличных параметров

Примечание

Модуль входит в состав конфигурации Стандарт и Лайт

2.4.7.1. Общее описание

Модуль СМЭВ4-адаптер - Модуль импорта данных табличных параметров предназначен для создания временных таблиц при выполнении временных запросов с ТП и выполняет следующие задачи:

  • создает временные таблицы в Prostore для хранения табличных параметров перед выполнением запроса;

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

2.4.8. СМЭВ4-адаптер - Модуль группировки данных табличных параметров

Примечание

Модуль входит в состав конфигурации Стандарт и Лайт

2.4.8.1. Общее описание

Модуль СМЭВ4-адаптер - Модуль группировки данных табличных параметров предназначен для группировки данных при выполнении запросов с табличными параметрами, и выполняет следующие задачи:

  • группирует поступающие пакеты каждого табличного параметра в отдельные топики;

  • подготавливает сгруппированные пакеты данных для последующей записи в Prostore (с помощью Модуля MPPW);

  • выдает команду СМЭВ4-адаптеру - Модуль импорта данных табличных параметров на запись данных во временные

  • таблицы, созданные в Prostore.

Формат обмена электронными сообщениями описан в разделе Спецификация Модуля исполнения запросов Приложения 1.

2.4.9. СМЭВ4-адаптер - Модуль дефрагментации чанков табличных параметров

Примечание

Модуль входит в состав конфигурации Стандарт и Лайт

2.4.9.1. Общее описание

Модуль СМЭВ4-адаптер - Модуль дефрагментации чанков табличных параметров преобразует пакеты с данными табличных параметров, поступающие от Агента СМЭВ4 в брокер сообщений Kafka, к формату, позволяющему обрабатывать их в многопоточном режиме.

Модуль дефрагментации чанков табличных параметров выполняет следующие функции:

  • считывает все чанки из общего топика query.tp.bin;

  • группирует их по сочетанию {requestId, subRequestId, tableParamId, streamNum};

  • накапливает чанки на локальном жестком диске;

  • при получении всех чанков одного стрима:

    • собирает из чанков одного стрима единый AVRO-объект;

    • десериализует единый AVRO-объект;

    • разделяет полученные строки на подмножества строк;

    • каждое подмножество строк сериализует в отдельный avro-объект;

    • полученные avro-объекты записывает в топик query.TP

2.4.10. DATA-Uploader - Модуль исполнения асинхронных заданий

Примечание

Модуль входит в состав конфигурации Стандарт

2.4.10.1. Общее описание

Модуль исполнения асинхронных заданий обеспечивает обработку очереди файлов, используя следующие функциональные особенности:

  • обработка очереди файлов производится циклами;

  • очередь файлов работает в режиме упорядочения процесса по принципу «первым пришел – первым обслужен»;

  • каждый элемент в очереди файлов содержит UUID задания, имя витрины и таблицы, содержимое CSV-файла;

  • файлы в очереди могут относится к разным витринам и/или разным таблицам одной витрины;

  • поддерживается удаление исторических данных.

Примечание

Заливка данных через через модуль DATA-Uploader не предусматривают параллельную заливку в датамарты вместе с другими инструментами. Параллельная заливка данных в те же датамарты вручную или средствами ETL приведет к конфликту в работе с дельтами и к ошибкам соответственно.

2.4.11. REST-Uploader - Модуль асинхронной загрузки данных из сторонних источников

Примечание

Модуль входит в состав конфигурации Стандарт

2.4.11.1. Общее описание

Модуль асинхронной загрузки данных из сторонних источников реализован для обеспечения параллельного обновления данных с независимым масштабированием REST интерфейса.

Операции с данными:

  • загрузка: отправка запроса на .../upload;

  • логическое удаление: отправка запроса на .../delete (при этом для логических таблиц данные только помечаются как удаленные);

  • удаление исторических данных: отправка запроса на .../truncate.

См. Спецификация модуля асинхронной загрузки данных из сторонних источников

Внимание

Не рекомендуется использовать персональные данные в качестве первичного ключа, т.к. первичный ключ может отображаться в логах Системы при удалении истории.

Обеспечена буферизация поступающих на загрузку данных. Буферизированные данные направляются в базу менеджером дельт с группировкой по датамартам.

Обеспечены следующие функциональные особенности:

  • идентификатор генерируется по стандарту UUID;

  • метаданные от сервера витрины кешируются механизмом, и проверяются на соответствие по количеству и по типам полей (при несоответствии загружаемых данных метаданным целевой таблицы сервис для передачи / загрузки данных возвращает статус запроса с ошибкой, без размещения данных в очереди на загрузку);

  • загруженные данные размещаются вместе с UUID в очереди с именем «queue»;

  • формируется запись с ключом «status.[UUID запроса]» и статусом 0 в очереди;

  • клиенту, отправившему запрос, возвращается успешный статус запроса вместе с UUID;

  • в логе приложения формироваться запись события получения запроса на загрузку с указанием идентификатора запроса, идентификатора ВУЗа, времени обработки и размера загруженных данных.

Внимание

Загружаемые файлы обязательно должны быть в кодировке UTF-8

Примечание

Заливка данных через через модуль REST-Uploader не предусматривают параллельную заливку в датамарты вместе с другими инструментами. Параллельная заливка данных в те же датамарты вручную или средствами ETL приведет к конфликту в работе с дельтами и к ошибкам соответственно.

Общие правила формата загружаемых CSV-файлов приведены в таблице Таблица 2.6.

Таблица 2.6 Общие правила формата загружаемых CSV-файлов

Параметр

Значение

Разделитель строк

Любой вариант из: CR/LF (0x0D0A), CR (0x0D), LF (0x0A)

Разделитель полей

по настройке csv-parser/separator (Параметры конфигурации)

Строка заголовка

да (обязательно)

Порядок полей в строке

определяется строкой заголовка

Ограничитель текстового поля

по настройке csv-parser/quote-char (Параметры конфигурации)

Символ маскировки в текстовом поле

по настройке csv-parser/escape-char (Параметры конфигурации)

Обнаружение значения null

До релиза 1.5.0 (включительно): по настройке csv-parser/field-as-null (Параметры конфигурации)

начиная с релиза 1.10.0: в текущей реализации парсера данная настройка не поддерживается

Кодирование символов

UTF-8

Десятичный разделитель

символ . (0x2E), может не указываться для целых значений

Формат даты

любой из: dd.MM.yyyy, yyyy-MM-dd

Формат времени

любой из: HH:mm:ss, H:mm:ss

Формат даты-времени

до релиза 1.5.0(включительно) любой из: yyyy-MM-dd HH:mm:ss, dd.MM.yyyy HH:mm:ss

начиная с релиза 1.10.0 любой из: yyyy-MM-dd HH:mm:ss.000000, dd.MM.yyyy HH:mm:ss.000000

2.4.11.2. Проверка форматно-логического контроля

Проверка форматно-логического контроля включает в себя:

  • обязательные проверки, выполняющиеся вне зависимости от настроек модуля в синхронном режиме;

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

Таблица 2.7 Список реализованных проверок

Наименование проверки

Код ошибки

Кирилическое описание

Проверка уникальности

dublicate

Дубликат файла/группы

Проверка парсинга файла

parsingErr

Ошибка парсинга: текст ошибки

Проверка кодирования

encodingErr

Кодировка файла не соответствует кодировке UTF-8

Проверка превышения предельного размера файла (больше 512 Мб)

tooLargeFile

Слишком большой файл

Проверка наличия данных в файле

emptyFile

Пустой файл

Проверка соответствия заголовков инфосхеме

wrongMetadata

Структура файла не соответствует схеме

Проверка соответствия числа столбцов в строке

wrongFieldsCount

Некорректное число столбцов в строке

Проверка соответствия типам полей

wrongFieldType

Значение не соответствует типу требуемый тип

Проверка уникальности полей

nonUniq

Значение не отвечает требованиям уникальности

Проверка регулярных выражений

nonMatchRegex

Значение не соответствует регулярному выражению регулярное выражение

Проверка соответствия условию

nonMatchConstant

Значение не соответствует условию условие

Таймаут валидации

validationTimeout

Истек таймаут валидации файла
2.4.11.2.1. Синхронная проверка ФЛК

Примечание

  • синхронные проверки выполняются вне зависимости от настроек модуля REST-Uploader;

  • синхронные проверки являются блокирующими;

  • ошибки синхронных проверок возвращаются в теле ответа по REST-API.

К синхронным проверкам относятся:

  • проверка соответствия инфосхеме:

    • проверка соответствия имен и количества полей в заголовках;

    • проверка типа данных;

    • проверка экранирования данных: проверка соответствия числа столбцов по каждой строке;

  • проверка соответствия файла кодировке UTF-8 , отсутствие BOM (при наличии BOM при загрузке удаляются начальные байты ef bb bf);

  • проверка размера файла и наличия данных:

    • проверка предельного размера загружаемого файла 512Мб;

    • проверка наличия данных в файле.

2.4.11.2.2. Асинхронная проверка

Примечание

  • асинхронные проверки выполняются в зависимости от настроек модуля;

  • проверки не являются блокирующими (поведение при их наличии определяется конфигурацией модуля);

  • список проверок уникален для каждой таблицы и хранится в Zookeeper в виде отдельного YAML файла.

К асинхронным проверкам относятся:

  • проверка уникальности полей:

    • по сочетанию атрибутов (для комплексных ключей);

    • по заданному атрибуту;

  • сравнение значения с константой;

  • соответствие регулярному выражению.

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

2.4.11.2.2.1. Проверка уникальности по одному или по сочетанию полей

Проверка уникальности проводится:

  • в рамках группы файлов, если заданы headers - для проверки в рамках группы обязательно заполнения всех полей:

    • group_id;

    • group_file_num;

    • group_file_count.

  • при проверке в рамках группы значения ключей для проверки уникальности в рамках группы хранится в Redis:

    • по всем файлам в рамках группы при наличии групповых атрибутов

    • по одному файлу, при отсутствии групповых атрибутов

Пример запроса для проверки уникальности по группе файлов:

--проверка по сочетанию полей
fields:
  id:
    uniq: true
    uniq-with: [type,region]
--проверка уникальности по одному полю
  snils:
    match: "/^[-\s\d]{11}$/"
    uniq: true
2.4.11.2.2.2. Проверка соответствия заданному значению

  • проверка соответствия заданному значению проводится для каждого файла вне зависимости от наличия group_id;

  • проверка осуществляется для значений каждого поля в соответствии с заданным правилом;

  • проверка соответствия заданному значению включает в себя:

2.4.11.2.2.3. Поведение в случае таймаута валидации

Период выполнения асинхронных проверок определяется конфигурационным параметром validation-timeout и по умолчанию составляет 60 минут.

В случае, если за указанное в настройках время асинхронные проверки не были выполнены, файл удаляется из очереди с обогащением отчета о найденных ошибках ошибкой validationTimeout.

В случае возникновения подобной ошибки рекомендуется:

  • проверить регулярные выражения, по которым происходит проверка, так как неверно заданное регулярное выражение кратно увеличивает скорость проверки;

  • увеличить значение validation-timeout и повторить загрузку данных.

2.4.11.3. Статусная модель

Статус запроса к модулю REST-Uploder можно получить, выполнив запрос с передачей идентификатора запроса GET '/v2/requests/:requestId/status'

В ответ возвращается три поля:

  • code - код статуса;

  • errorMessage - сообщение об ошибке, заполняется лишь в случае ошибочного статуса;

  • description - описание ошибки, заполняется лишь в случае ошибочного статуса.

Пример ответа на запрос статуса

{"code":2,"description":null,"errorMessage":null}

{"code":3,"description":"Успешно обработан","errorMessage":null}

{"code":4,"description":"Ошибка обработки запроса","errorMessage":"ru.itone.dtm.data.uploader.upload.UploadException: ru.itone.dtm.prostore.rest.api.ProstoreRestException: Error executing query [insert into univer.slots select resource_id,slot_id,tag_type,tag_age,available_date,duration,slot_create_ts,slot_update_ts,slot_status,sys_op from univer.slots_upload_ext]: All of the connectors are failed\n\tat"}

{"code":5,"description":"Идентификатор запроса не обнаружен","errorMessage":null}

{"code":7,"description":"Ошибки ФЛК","errorMessage":null}

В свою очередь, идентификатор запроса ранее был получен в ответ от REST-Uploader:

  • POST“/v2/datamarts/{datamart_name}/tables/{table_name}/upload;

  • POST“/v2/datamarts/{datamart_name}/tables/{table_name}/delete.

Таблица 2.8 Статусная модель

Код статуса

Описание статуса

Действия при получении данного статуса

-1

Загрузка данных в буффер

Данный статус клиентскому приложению не возвращается, ответ вернется после того как загружаемые данные будут сохранены приложением REST-Uploader для дальнейшей загрузки.

0

Запрос буфферизирован

Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30сек.

1

Ожидает открытия дельты

Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30сек.

2

В обработке (модулем DATA-Uploader)

Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30сек.

3

Успешно обработан

Дополнительных действий не требуется

4

Ошибка обработки запроса

Необходимо:

  • изучить содержимое вернувшегося поля description

  • если суть проблемы не ясна из предыдущего пункта, изучить содержимое логов приложений на предмет наличия ошибок:

    • REST-Uploader

    • DATA-Uploader

    • podd-adapter-mppw

    • query-execution-core

    • используемого коннектора (kafka-postgres-writer или kafka-jet-writer)

5

Идентификатор запроса не обнаружен

Использовать действующий идентификатор запроса

6

Форматно-логический контроль

Выполнить повторный запрос статуса с некоторой задержкой. Рекомендуемая задержка 30сек.

7

Ошибки ФЛК

В процессе ФЛК выявлены ошибки, необходимо запросить отчет ФЛК, обратившись к REST-Uploader c запросом GET '/v2/requests/{request_id}/report/'

Далее проанализировать и устранить выявленные недочеты в загружаемых данных или скорректировать проверки ФЛК.

2.4.12. BLOB-адаптер

Примечание

Модуль входит в состав конфигурации Стандарт

2.4.12.1. Общее описание

BLOB-адаптер, программный модуль Витрины данных, предназначен для получения доступа из Витрины данных к BLOB-объектам ведомства.

BLOB-объект - это специальный тип двоичных данных, предназначенный для хранения бинарных файлов: изображений, скан-копий документов, текстовых файлов и т.д.

BLOB-адаптер предоставляет возможность настроить доступ к BLOB-объектам расположенным в Хранилище BLOB-объектов.

Примечание

Хранилище BLOB-объектов располагается на стороне ведомства и не является частью Витрины данных.

BLOB-адаптер предназначен для следующих задач:

  • настройка доступа в Хранилище BLOB-объектов;

  • предоставление регламентированного доступа к BLOB-объектам;

  • получение и отправка запросов на получение BLOB-объектов;

  • чтение BLOB-объектов;

  • сохранение BLOB-объектов на FTP-сервере (через СМЭВ3-адаптер).

Взаимодействие с BLOB-объектами возможно через запросы из СМЭВ3 (через СМЭВ3-адаптер) или СМЭВ (через СМЭВ4-адаптер). Доступ к считыванию BLOB-объектов производится методом GET по протоколу HTTP/HTTPS (указывается в конфигурации, параметр host) .

Формат обмена электронными сообщениями через BLOB-адаптер описан в разделе Спецификация модуля «BLOB-адаптер» Приложения 1.

2.4.12.2. Общая схема взаимодействия через BLOB-адаптер

Общая схема взаимодействия через BLOB-адаптер

Рисунок - 2.4 Общая схема взаимодействия через BLOB-адаптер

2.4.12.3. Взаимодействие через СМЭВ-адаптер

2.4.12.3.1. Схема взаимодействия через СМЭВ-адаптер

Общая схема получения BLOB-объектов через СМЭВ-адаптер выглядит следующим образом:

Взаимодействие BLOB-адаптера через СМЭВ4-адаптер

Рисунок - 2.5 Взаимодействие BLOB-адаптера через СМЭВ4-адаптер

2.4.12.3.2. Процесс обработки запроса на получение BLOB-объекта (СМЭВ4-адаптер)

  1. В СМЭВ4 поступает запрос на получение данных из Витрины.

  2. СМЭВ4 отправляет запрос через СМЭВ4-адаптер в Витрину.

  3. Витрина данных обрабатывает запрос.

  4. СМЭВ4-адаптер считывает данные полученные от Витрины и отправляет ответ в Kafka, на стороне СМЭВ4. В случае, если в теле запроса содержится ссылка на BLOB-объект (например, изображение) Kafka, на стороне СМЭВ4 , отправляет запрос в BLOB-адаптер на получение этого BLOB-объекта. BLOB-адаптер, считывает ссылку на BLOB-объект и обращается в Хранилище BLOB-объектов на стороне ведомства. После получения BLOB-объекта, возвращает его в СМЭВ4.

2.4.12.4. Взаимодействие через СМЭВ3-адаптер

2.4.12.4.1. Схема взаимодействия через СМЭВ3-адаптер
Взаимодействие BLOB-адаптера через СМЭВ4

Рисунок - 2.6 Взаимодействие BLOB-адаптера через СМЭВ4

2.4.12.4.2. Процесс обработки запроса на получение BLOB-объекта (через СМЭВ3-адаптер)

  1. Из внешней ИС в СМЭВ4 поступает запрос на получение данных из Витрины.

  2. СМЭВ3-адаптер получает запрос и отправляет его в Витрину.

  3. Витрина обращается к БД, подготавливает ответ на запрос. Если в запросе есть ссылка на BLOB-объект, BLOB-адаптер обращается к Хранилищу BLOB-объектов, копирует BLOB-объект, выкладывает его на FTP-сервер СМЭВ4 и отправляет ссылку на BLOB-объект в Витрину.

  4. После того как BLOB-объект загружен на FTP-сервер СМЭВ4, Витрина отправляет ответ на запрос в СМЭВ4, в котором содержится ссылка на BLOB-объект (сохраненный на FTP-сервере).

  5. После получения ответа внешняя ИС может обратиться по ссылке и скачать BLOB-объект с FTP-сервера СМЭВ4.

2.4.12.5. Требования к серверу BLOB-адаптера

  1. Cледующие файлы не должны контролироваться системой управления конфигурации (при ее наличии), поскольку они должны быть доступны процессу установки для создания и модификации:

  • /etc/hosts

  • /etc/selinux/config

  • /etc/sysctl.conf

  • файлы директории /usr/lib/systemd/system/

  • /etc/sysconfig/iptables\*

  • /etc/firewalld/\*

  • /etc/docker/\*

  1. Снаружи сервер должен быть доступен по следующим портам:

  • 22 (SSH).

2.4.12.6. Требования к Хранилищу BLOB-объектов

Хранилище BLOB-объектов должно поддерживать регламентированный витриной интерфейс доступа к BLOB-объектам по запросу (см. раздел Спецификация модуля «BLOB-адаптер» Приложения 1).

Для корректной работы с Хранилищем BLOB-объектов, необходимо выполнить следующие условия:

  • Предоставить доступ:

    • к таблицам с метаданными по документам, хранилища ведомства;

    • к ссылкам на BLOB-объекты (изображения, архивы, pdf-файлы и т.д.) в хранилище ведомства, соответствующие метаданным.

  • Предоставить связь между ссылками и метаданными, если они разнесены по разным хранилищам.

Примечание

Все обновления ссылок на документы происходят только через ETL, т.е. от Поставщика данных (ведомства) к Витрине. Обновление самих BLOB через витрину, с последующей проливкой в ведомства, не предусмотрено.

2.4.12.7. Требования к предоставляемому интерфейсу Хранилища BLOB-объектов (API-интерфейс)

API-интерфейс реализованный соответственно данной спецификации должен предоставляться Хранилищем BLOB-объектов для возможности успешного взаимодействия с Витриной.

API-интерфейс Хранилища BLOB-объектов должен использовать метод GET, который поддерживается Витриной для получения тела BLOB-объекта из Хранилища BLOB-объектов.

С помощью API-интерфейса отправляется запрос на получение BLOB-объектов.

Считывание BLOB-объекта производится по протоколу HTTP (допустимо HTTPS, указывается в конфигурации файла application.yml, параметр host (см. раздел Конфигурация BLOB-адаптера (application.yml) в документе «Руководство администратора ПО «Витрина данных НСУД»)).

2.4.13. Сервис формирования документов

Примечание

Модуль входит в состав конфигурации Стандарт

2.4.13.1. Общее описание

Сервис Формирования документов предназначен для обеспечения возможности формирования документов, в формате XML и PDF, на основе предварительно подготовленных pebble-шаблонов, с возможностью добавления к сформированным документам электронной подписи.

Внимание

Максимальный размер формируемого отчета не должен превышать 2Гб!

Сервис Формирования документов предназначен для решения следующих задач:

  • формировать документ, на основе поступившего в Витрину запроса, в формате:

    • XML;

    • PDF.

  • отправлять сформированные документы на подпись в сервис Notarius;

  • отправлять сформированные и подписанные документы в СМЭВ4 в виде ответа на пришедший запрос.

Формат обмена электронными сообщениями описан в разделе Спецификация модуля «Сервис Формирования документов» Приложения 1.

2.4.13.1.1. Процесс обработки запроса через модуль «Сервис Формирования документов»

  1. Запрос на предоставление сформированного документа поступает через Агента СМЭВ4, в топик procedure.query.rq.

  2. СМЭВ4-адаптер считывает запрос из топика и передает его в Сервис Формирования документов. Сервис Формирования документов запускает соответствующий пришедшему типу документа pebble-шаблон, собирает данные из Витрины (Prostore) и формирует на основании этих данных JSON-файл.

  3. Из содержащейся в JSON-файле информации формируется итоговая форма документа. Для этого используется Шаблон generate_xml.peb и Шаблон generate_pdf.peb, предназначенные для генерации документов.

  4. В случае, если электронная подпись не требуется, то PDF-документ сразу пересылается в топик report.rs.

  5. Если требуется электронная подпись:

  • PDF-документ и публичная часть SSH-ключа (pub) будут отправлены в Сервис электронной подписи. Сервис электронной подписи сформирует для этого PDF-документа файл подписи (p7s) и вернет его в Сервис Формирования документов.

  • Полученный XML или PDF-файл Сервис Формирования документов отправляет в СМЭВ4-адаптер, в топик report.rs Kafka СМЭВ4-адаптер.

  1. Агент СМЭВ4 проверяет топик и забирает сформированные документы для передачи в СМЭВ4.

Внимание

Следует обратить внимание, что при формировании XML-документов используется - присоединенная подпись (подпись содержится в самом XML-документе).

Для PDF-документов - отсоединенная подпись (подпись документа формируется отдельным файлом), т.е. при формировании PDF-документа сгенерируется два файла: PDF-документ и файл электронной подписи для этого документа.

2.4.13.1.2. Компоненты
Компоненты модуля «Сервис Формирования документов»

Рисунок - 2.7 Компоненты модуля «Сервис Формирования документов»

2.4.13.1.3. Общая архитектура решения
Общая схема взаимодействия модуля «Сервис Формирования документов»

Рисунок - 2.8 Общая схема взаимодействия модуля «Сервис Формирования документов»

2.4.13.1.4. Назначение параметров QueryRequest.parameters[]
Таблица 2.9 Назначение параметров QueryRequest.parameters[]

Индекс параметра в QueryRequest.parameters[]

Тип QueryRequest.parameters[].type

Значение QueryRequest.parameters[].value

0

string

публичная часть сертификата (формат PKCS#7) в кодировке BASE64

1

string

Список запрошенных форматов ПФ (через запятую, без учета регистра).

Допустимые значения (без кавычек):

  • «XML» - файл xml;

  • «PDF» - pdf без ЭП (содержимое «штампика об ЭП» - на усмотрение разработчика шаблона для pdf-файла);

«PDF_SIG» - pdf с открепленной ЭП (содержимое «штампика об ЭП» - на ответственности разработчика шаблона для pdf-файла).

2

параметры для формирования запрашиваемой ПФ, зависят от логики формирования ПФ.
2.4.13.1.5. Примеры шаблонов
2.4.13.1.5.1. Шаблон extract_data.peb
{#формируем sql запрос в переменную passengersquery#}
{% var passengersquery %}
    {% if _0 is empty %}
        select * from auto_db.passenger limit 10
    {% else %}
        select * from auto_db.passenger limit {{ _0 }}
    {% endif %}
{% endvar %}
{# выполняем sql запрос и помещаем результат выполнения в переменную rows.searchpassenger #}
{{ sql("searchpassenger", passengersquery) }}

{% var json_data %}
{
    "passengers": [
    {% for p in rows.searchpassenger %}
    {#  формируем json динамически  #}
        {% if loop.first %}
        {% else %}
            ,
        {% endif %}
        {
            "id": "{{ p.id }}",
            "firstname": "{{ p.firstname }}",
            "middlename": "{{ p.middlename }}",
            "lastname": "{{ p.lastname }}",
            "birthday": "{{ p.birthday }}"
        }
    {% endfor %}
    ]
}
{% endvar %}

{#выведем полученный json в неэкранированной форме#}
{{ json_data | raw }}
2.4.13.1.5.2. Шаблон generate_xml.peb
{#соберем xml документ#}
<passengers>
{% for p in _0.passengers %}
    <passenger id="{{ p.id }}">
        <firstname>{{ p.firstname }}</firstname>
        <middlename>{{ p.middlename }}</middlename>
        <lastname>{{ p.lastname }}</lastname>
        <birthday>{{ p.birthday }}</birthday>
    </passenger>
{% endfor %}
</passengers>
2.4.13.1.5.3. Шаблон generate_pdf.peb
{#соберем html документ#}
<html>
    <head>
    <style>
        table, th, td {
            border: 1px solid black;
        }
    </style>
</head>
    <body>
        <h3>Passengers</h3>
        <table>
            <tr>
                <th>id</th>
                <th>firstname</th>
                <th>middlename</th>
                <th>lastname</th>
                <th>birthday</th>
            </tr>
{% for p in _0.passengers %}
            <tr>
                <td>{{ p.id }}</td>
                <td>{{ p.firstname }}</td>
                <td>{{ p.middlename }}</td>
                <td>{{ p.lastname }}</td>
                <td>{{ p.birthday }}</td>
            </tr>
{% endfor %}
        </table>
    <body>
</html>
2.4.13.1.6. REST запрос к сервису
2.4.13.1.6.1. Запрос

Endpoint: /report

Request type: GET

Headers:

  • Content-type: application/json

content schema

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "docGenRequest",
  "type": "object",
  "properties": {
    "docName": {
      "type": "string"
    },
    "customerId": {
      "type": [
      "null",
      "string"]
    },
    "customerOgrn": {
      "type": [
      "null",
      "string"]
    },
    "queryMnemonic": {
      "type": [
      "null",
      "string"]
    },
    "parameters": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
        "name": {
            "type": "string"
        },
        "value": {
            "type": [
            "string",
            "number",
            "boolean",
            "null"
            ]
        },
        "mandatory": {
            "type": [
            "boolean",
            "null"
            ]
        },
        "regExp": {
            "type": [
            "string",
            "null"
            ]
        }
      },
      "required": [
        "name",
        "value"
        ]
      }
    }
  },
  "required": [
    "docName",
    "parameters"
  ]
}
2.4.13.1.6.2. Ответ

Ответ должен содержать заголовок с HTTP-кодом ответа и n частей:

  1. Ответ на запрос:

    Код ошибки: (200 OK)

    Content-type: multipart/mixed

  2. Часть, содержащая сгенерированный XML

    Content-Disposition: attachment; name=»xml»; filename=»result.xml»

    Content-type: application/xml

  3. Часть, содержащая metadata для XML

    Content-Disposition: attachment; name=»xml»; filename=»metadata»

    Content-type: text/plain; charset=utf-8

  4. Часть, содержащая сгенерированный PDF

    Content-Disposition: attachment; name=»pdf»; filename=»result.pdf»

    Content-type: application/pdf

2.4.14. СМЭВ QL Сервер

Примечание

Модуль входит в состав конфигурации Стандарт

2.4.14.1. Назначение СМЭВ QL сервера

2.4.14.1.1. О системе

СМЭВ QL сервер - это компонент взаимодействия с витриной данных, который реализует её типовое API согласно внутренней спецификации СМЭВ QL.

Основным назначением СМЭВ QL сервера является обработка REST-запросов на получение данных от Потребителей и формирование оптимальных (простых) SQL-запросов к витрине для получения запрашиваемых данных.

Для Потребителя взаимодействие со СМЭВ QL сервера равнозначно виду информационного обмена - Обмен с использованием регламентированных запросов типа «Rest-сервис».

Основной принцип работы СМЭВ QL сервера заключается в следующем:

  1. СМЭВ QL принимает на вход REST-запрос, который содержит перечень запрашиваемых ресурсов, условий выбора данных, требуемые атрибуты ответа и пр. После чего определяет данные каких объектов и из каких источников необходимо извлечь. При этом определение источников происходит на основании заранее описанных моделей данных, которые хранятся на сервере в файлах вида model.yaml (что извлекать) и source.yaml (откуда извлекать).

  2. Далее формирует, в определенной последовательности (на основании плана выполнения запросов), столько SQL-запросов к источникам данных, сколько ресурсов было запрошено в исходном запросе от клиента. При этом запросы могут выполняться как последовательно, в случае если в запросе ресурсы имеют вложенность (иерархию) или параллельно, если ресурсы указаны на одном уровне. Это позволяет значительно упростить sql-выражения и уменьшить сложность запроса к БД.

  3. Обрабатывает результаты выполнения SQL-запросов по мере их поступления от источников.

  4. Затем формирует и передает комплексный ответ клиенту.

Схема СМЭВ QL Сервера

Рисунок - 2.9 Схема СМЭВ QL Сервера

2.4.14.1.2. Цели СМЭВ QL сервера

Целями создания СМЭВ QL сервера являются:

  1. Повышение скорости предоставления ответов от витрины данных Поставщика по сравнению с типовым видом взаимодействия Агент-Витрина.

  2. Защита витрины данных Поставщика от неоптимальных запросов.

  3. Сокращение объёма ответов.

  4. Сокращение количества передаваемых запросов от Потребителей.

  5. Повышение скорости развития услуг ЕПГУ.

2.4.14.1.3. Задачи СМЭВ QL сервера

Основные задачи СМЭВ QL сервера:

  1. Формирование API и модели данных витрины .

  2. Приём REST-запросов от Потребителей через Агент СМЭВ4.

  3. Формирование простых SQL-запросов к витрине.

  4. Формирование распределенных запросов к нескольким витринам.

  5. Формирование и передача ответа Потребителю.

  6. Проверка и формирование цифровых подписей ответов.

  7. Описание и исполнение при вызове модели машины состояний.

  8. Нотификация подписчиков при изменении данных витрины.

  9. Предоставление внешним клиентам OpenAPI для управления.

2.4.14.1.4. Место СМЭВ QL сервера в ИТ-ландшафте

СМЭВ QL сервер взаимодействует со следующими компонентами СМЭВ4:

  1. Агент СМЭВ4.

  2. Сервис исполнения запросов ядра витрины данных.

  3. Сервер криптографии (Notarius).

  4. Сервис формирования документов.

Схема взаимодействия СМЭВ QL Сервера с компонентами СМЭВ4

Рисунок - 2.10 Схема взаимодействия СМЭВ QL Сервера с компонентами СМЭВ4

2.4.14.1.5. Язык и синтаксис
2.4.14.1.5.1. Моделирование

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

2.4.14.1.5.2. Запросы и ответы

Для написания запросов, а также в качестве сериализатора ответов, спецификация определяет использование JSON.

2.4.14.1.6. Типизация

Фактические типы данных наследуют типы данных JSON (включая NULL):

  • string;

  • number;

  • object;

  • array;

  • boolean;

  • null.

2.4.14.1.6.1. Типы данных в модели и приведение типов

В описании модели допускается указание фактического типа данных атрибута ресурса вторым элементом массива type. Указание является опциональным, по умолчанию подразумевается неограниченный STRING.

Пример из описания модели:

fields:
  id:
    name: Идентификатор записи
    type:
      - number
      - SHORT
    length: 20
    nullable: not NULL
    key: PRIMARY

В качестве второго уточняющего типа следует применять типы НСУД:

  • STRING;

  • DOUBLE;

  • FLOAT;

  • BOOLEAN;

  • BYTE (не поддерживается на витрине);

  • BINARY;

  • BIG_DECIMAL (не поддерживается на витрине);

  • LONG;

  • INTEGER;

  • SHORT;

  • DATE;

  • TIME;

  • TIMESTAMP.

2.4.14.1.7. Моделирование данных

Модели данных описываются в формате YAML в папке проекта models согласно спецификации СМЭВ QL.

Структура базовой модели приведена в Базовая модель данных.

Структура базовой модели приведена в Модель данных.

Примечание

Заливка данных через через модуль RESt-Uploader и DATA-Uploader не предусматривают параллельную заливку в датамарты вместе с другими инструментами. Параллельная заливка данных в те же датамарты вручную или средствами ETL приведет к конфликту в работе с дельтами и к ошибкам соответственно.

2.4.14.1.8. Метрики

Для обеспечения возможности сбора информации о работе СМЭВ QL Сервера реализован набор метрик, обеспечивающий формирование показателей:

  • время исполнения входящих запросов;

  • количество успешных / не успешных выполнений входящих запросов;

  • время исполнения исходящих запросов или обращений к СПО;

  • количество успешных / не успешных выполнений исходящих запросов или обращений к СПО.

2.4.15. СМЭВ3-адаптер

Примечание

Модуль входит в состав конфигурации Стандарт

2.4.15.1. Общее описание

Модуль CМЭВ3-адаптер обеспечивает информационное взаимодействие через единый электронный сервис единой системы межведомственного электронного взаимодействия (далее – СМЭВ).

С помощью CМЭВ3-адаптер Витрина данных выступает участником взаимодействия в роли Поставщика данных, а именно:

  • получает запросы из очереди СМЭВ;

  • отправляет ответы на запросы из очереди СМЭВ;

  • формирует и отправляет уведомления в СМЭВ об изменении данных в экземпляре Витрины данных.

Внимание

Отправляемые через СМЭВ3-адаптер файлы, не должны быть нулевыми (не содержать никаких данных)!

2.4.15.2. Схема взаимодействия

Подключение к СМЭВ

Рисунок - 2.11 Подключение к СМЭВ

  1. Внешняя ИС выполняет запрос к СМЭВ 3 на получение данных от Поставщика данных.

  2. Запрос через CМЭВ3-адаптер отправляется в СМЭВ.

  3. Адаптер СМЭВ 3 на стороне Поставщика данных принимает запрос из СМЭВ и отправляет его в Витрину данных поставщика.

  4. В Витрине Поставщика данных формируется ответ на поступивший запрос.

2.4.16. REST-адаптер

Примечание

Модуль входит в состав конфигурации Стандарт

2.4.16.1. Схема взаимодействия через СМЭВ3-адаптер

REST-адаптер представляет возможность подключения Внешней ИС к Витрине данных через REST-адаптер (см. Рисунок - 2.12).

Взаимодействие Внешней ИС через REST-адаптер

Рисунок - 2.12 Взаимодействие Внешней ИС через REST-адаптер

Внешняя ИС формирует REST-запрос и отправляет его в REST-адаптер.

REST-адаптер:

  • На основании своих настроек преобразует полученный REST-запрос в SQL-запрос.

  • Отправляет сформированный SQL-запрос в Витрину данных.

  • Преобразует полученный от Витрины данных ответ на SQL-запрос в REST-ответ.

  • Отправляет сформированный REST-ответ Внешней ИС.

При взаимодействии через REST-адаптер Программа выполняет следующие основные операции по обработке данных:

  • предоставляет программный интерфейс к конечным точкам API по протоколу HTTP;

  • конечная точка доступа поддерживает конфигурирование, которое позволяет: - с использованием атрибутов HTTP-запроса построить и выполнить SQL-запросы из Внешней ИС к программе; - с использованием атрибутов HTTP-запроса и результатов SQL-запросов построить и отправить ответ на HTTP-запрос из программы к Внешней ИС; - документировать сконфигурированный API с использованием спецификации OpenAPI версии 3.

2.4.17. Сервис генерации уникального номера (Counter-Provider)

Примечание

Модуль входит в состав конфигурации Стандарт

2.4.17.1. Общее описание

Сервис генерации уникального номера позволяет создавать неповторяющиеся уникальные порядковые номера для сквозной нумерации файлов в сервисе формирования документов Типового ПО Витрины данных конфигурации Стандарт.

В сервисе реализованы функции:

  • долговременного хранения неограниченного списка счетчиков;

  • атомарного изменения счетчика при параллельном использовании этой функции.

2.4.18. ETL - Модуль загрузки/ удаления данных

Примечание

Модуль входит в состав конфигурации Стандарт

Базовый сервис загрузки данных предоставляет возможность асинхронного приёма данных из сторонних источников с целью последующей загрузки их в Витрину данных. Загрузка/обновление данных осуществляется в соответствии с заранее подготовленными Avro-схемами.

Сервис загрузки данных реализуется компонентом ETL, предоставляющей REST API. Доступ к REST API должен осуществляться через Proxy API Datamart Studio. Перед загрузкой необходимо получить токен Proxy API, который в дальнейшем используется для авторизации при операциях, описанных в разделах ниже. При получении ошибки авторизации необходимо повторить авторизацию, получить новый токен и использовать его для дальнейшей загрузки.

Для взаимодействия с REST API (через Proxy API) в продуктивной среде на стороне источника данных требуется использовать сертифицированную версию ОС, а также механизмы, соответствующие требованиям безопасности, установленным для эксплуатации системы (например, через программный продукт Postman).

На стороне источника данных должны соблюдаться следующие требования к механизму взаимодействия:

  1. Запрещается хранение логина и пароля в открытом виде на диске. Логин и пароль должны выгружаться из безопасного хранилища в память ВМ (или контейнера) при старте взаимодействия с Proxy API для дальнейшего использования, сама ВМ должна находиться в закрытом контуре ИС или ведомства.

  2. Рекомендуется реализовать механизм стирания логина и пароля из памяти после успешной аутентификации через Proxy API.

В целях тестирования взаимодействия на тестовой среде может использоваться утилита curl.

2.4.19. Backup manager - утилита резервного копирования

Примечание

Утилита входит в состав конфигурации Стандарт

2.4.19.1. Общее описание

Утилита Backup manager разработана для реализации механизма резервного копирования Витрины данных и восстановления из резервной копии.

Backup manager используется для оркестрации процесса резервного копирования слоя адаптеров и утилиты DTM-tools, осуществляющей резервное копирование логической модели базы данных и физических данных СУБД, входящих в инсталляцию.

Подробное описание утилиты и работы с ней приведено в разделе Бекапирование Витрины данных НСУД Руководства администратора ПО «Витрина данных НСУД».

2.5. Связи с другими программами

Взаимодействие с другими программами происходит путем вызова соответствующих модулей программы:

Связи программы с другими программами приведены в Таблица 2.10 .

Таблица 2.10 Связи с другими программами

Клиент

Сервер

Способ взаимодействия

Описание

Сервис формрования документов

Агент СМЭВ4

REST

Передает сформированные документы для формирования ЭП.

СМЭВ4-адаптер - Модуль исполнения запросов

Агент СМЭВ4

Через брокера сообщений Kafka

Получает запросы и предоставляет ответы на них согласно протоколу СМЭВ4:

  • запрос/подзапрос на получение публикуемых данных (в т. ч. с использованием ТП или в режиме оценки запроса);

  • предоставление структуры таблиц при подписании на репликацию (источник данных);

  • создание структуры таблиц при подписании на репликацию (потребитель данных);

  • предоставление реплицируемых данных (источник данных);

  • получение реплицируемых данных (потребитель данных);

  • запрос генерации ПФ.

СМЭВ4-адаптер - Модуль MPPR

Агент СМЭВ4

Через брокера сообщений Kafka

Предоставляет Результат запрос/подзапрос на получение публикуемых данных

(в т. ч. с использованием ТП), делегированного СМЭВ4-адаптером.

СМЭВ4-адаптер - Модуль дефрагментации чанков табличных параметров

Агент СМЭВ4

Через брокера сообщений Kafka

Получает сообщения с ТП, подготовленные Агентом СМЭВ4

BLOB-адаптер

Агент СМЭВ4

Через брокера сообщений Kafka

  • Получает запрос на предоставление содержимого BLOB-объекта;

  • Передает бинарное содержимое запрошенного BLOB-объекта.

Хранилище BLOB

HTTP

Запрашивает бинарное содержимое BLOB.

СМЭВ3-адаптер

СМЭВ3

SOAP

  • Получает запрос вида сведений от СМЭВ3;

  • Передает Результат запроса вида сведений;

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

FTP-сервер СМЭВ3

FTP

Загружает на сервер бинарное содержимое запрошенных BLOB-объектов.

VipNet

REST

  • Проверяет ЭП получаемых от СМЭВ3 сообщений;

  • Формирует ЭП для отправляемых в СМЭВ сообщений.

ETL

Файловое хранилище ведомства

S3, FTP и т.п.

Считывание CSV файлов с данными, импортируемыми в витрину

БД ведомства

JDBC Driver

Считывание данных, импортируемых в витрину

Внутренняя ИС Ведомств

Сервер конечных точек

REST API

Имитация поведения, существующего REST API

Внутренняя ИС Ведомств

Ядро витрины

JDBC Driver

Доступ к БД ведомства

Взаимодействие с другими программами происходит путем вызова соответствующих модулей программы:

  • Внутренняя ИС Ведомства взаимодействует с Prostore через JDBC-driver.

  • СМЭВ4-адаптер - Модуль исполнения запросов для взаимодействия с ИС участников взаимодействия через Агента СМЭВ4.

  • CSV-uploader для взаимодействия с ИС участников взаимодействия для передачи файлов в формате XML и CSV.

Связи программы со сторонними программами приведены в см. Таблица 2.11.

Таблица 2.11 Связи с другими программами

Клиент

Сервер

Способ взаимодействия

Описание

Внутренняя ИС Ведомств

CSV-uploader

Файловый обмен (CSV)

REST

Загрузка публикуемых данных в Витрину

Prostore

JDBC

Брокер сообщений Kafka

Управление логической структурой таблиц.

Исполнение запросов.

Загрузка публикуемых данных в Витрину.

СМЭВ4-адаптер — Модуль исполнения запросов

Агент СМЭВ4

Брокер сообщений Kafka

Kafka

Исполнение запросов.

2.6. Карта портов

Карта портов компонентов программы представлена в Таблица 2.12.

Таблица 2.12 Карта портов

Компонент

Описание

podd-adapter-query

Порт: 8083

Протокол: HTTP

Описание: Взаимодействие с СМЭВ4-адаптером

query-execution

Порт: 8080

Протокол: HTTP

Описание: номер порта сервиса метрик

Порт: 9090

Протокол: TCP

Описание: номер порта сервиса исполнения запросов

prometheus

Порт: 9090

Протокол: HTTP

Описание: Подключение к Prometheus WEB UI

grafana

Порт: 3000

Протокол: HTTP

Описание: WEB-интерфейс для работы c Grafana

node_exporter

Порт: 9100

Протокол: HTTP

Описание: Порт для загрузки метрик

filebeat

Порт: нет открытых портов

Протокол: -

Описание: -

mongodb

Порт: 27017

Протокол:TCP

Описание: Подключение к MongoDB. Порт по умолчанию для экземпляров mongod и mongos.

Вы можете изменить этот порт с помощью port или --port.

Порт: 27018

Протокол: TCP

Описание: Подключение к MongoDB. Порт по умолчанию для mongod при запуске с

параметром командной строки --shardsvr или значением shardsvr для параметра clusterRole в файле конфигурации

elasticsearch

Порт: 9200

Протокол: HTTP

Описание: Подключение к Elasticsearch.

kafka_postgres_writer

Порт: 8096

Протокол: HTTP

Описание: Порт используется для записи топиков Kafka в Prostore

kafka_postgres_reader

Порт: 8094

Протокол: HTTP

Описание: Порт используется для чтения топиков Kafka из Prostore

postgres

Порт: 5432

Протокол: TCP PostgresSQL Protocol

Описание: Источник данных SQL

kafka

Порт: 9092

Протокол: Порт используется для

Описание: TCP

zookeeper

Порт: 2181

Протокол: TCP

Описание: Порт используется для доступа к Zookeeper

portainer

Порт: 9000

Протокол: HTTP

Описание: Web-интерфейс для работы c Portainer