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

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

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

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

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

Функционально, программа состоит из следующих частей:

2.1.1. Основные компоненты

ProStore — основной компонент программы с открытым исходным кодом, обеспечивает единый интерфейс к хранилищу разнородных данных. Определяет структуры данных, запись и чтение данных Витрины. Позволяет работать со входящими в состав хранилища СУБД одинаковым образом, используя единый синтаксис запросов SQL и единую логическую схему данных. ProStore включает следующие компоненты:
- Сервис исполнения запросов — анализирует и исполняет SQL-запросы; предоставляет REST API для JDBC-драйвера и взаимодействует с сервисом мониторинга статусов Kafka по REST API. В свою очередь состоит из следующих компонентов:
  Коннектор Kafka-Postgres reader - считывает данные из PostrgeSQL и передает их в брокер сообщений Kafka.
  
  Коннектор Kafka-Postgres writer - записывает данные из брокера сообщений Kafka в PostrgeSQL.
- Сервис мониторинга статусов Kafka — отслеживает состояние топиков брокера сообщений Kafka; предоставляет REST API для сервиса исполнения запросов.
PostrgeSQL — база данных ProStore.
Apache ZooKeeper — необходим для поддержки информации о конфигурации и распределенной координации между компонентами Витрины, также используется как сервисная база данных ProStore, для хранения технической информации (метаданных) от поступающих в Витрину данных запросах.
Брокер сообщений Kafka — используется для непрерывной передачи сообщений между:
- CSV-uploader и ProStore;
- ПОДД-адаптер-Модуль исполнения запросов и Агент СМЭВ4.
CSV-uploader — модуль программы, который предназначен для загрузки и выгрузки csv/xml-файлов.
ПОДД-адаптер — общее название логических модулей программы, которые обеспечивают подключение к ПОДД СМЭВ, как информационной системы участника взаимодействия. В зависимости от предназначения логические модули обеспечивают загрузку запросов из очереди ИС УВ в ПОДД СМЭВ, формирование и отправку ответов в ПОДД СМЭВ, инициативное формирование уведомлений об изменении данных в экземпляре ПО «Витрина данных НСУД», отправку уведомлений в ПОДД СМЭВ, регистрацию реплики данных ИС УВ, подписки на репликацию и поддержку реплики в актуальном состоянии.

ПОДД-адаптер состоит из следующих логических модулей:

ПОДД-адаптер-Модуль исполнения запросов — предназначен для подключения программы к ПОДД СМЭВ (через протокол коммуникации Агент ПОДД), как информационной системы участника взаимодействия;

ПОДД-адаптер – Модуль MPPR — предназначен для загрузки данных табличных параметров в многопоточном режиме (massively parallel processing, MPP);

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

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

Дополнительное программное обеспечение для администрирования и мониторинга:

Prometheus — используется как система мониторинга системных ресурсов Компонент «Витрина данных Лайт». Связь компонентов реализована через HTTP. Данные хранятся локально, в собственной TSBD базе, индексы хранятся в LevelDB. Метрики представляют собой time-series данные. Каждая метрика состоит из имени метрики, временной метки и пары «ключ – значение». Визуализация осуществляется через подключение к Grafana. Официальный сайт разработчика приложения: https://prometheus.io/.
Grafana — инструмент реализован в виде панели управления и мониторинга и позволяет визуализировать системные события программы на базе собираемых метрик. Официальный сайт разработчика приложения: https://grafana.com/docs/.
Ansible — платформа удалённого управления конфигурациями программного обеспечения, предназначенная для упрощения развёртывания Компонент «Витрина данных Лайт» через создание специальных сценариев. Официальный сайт разработчика приложения: https://www.ansible.com/.
Docker — программное обеспечение для автоматизации развёртывания и управления программы в виртуальных средах с поддержкой контейнеризации. Контейнер позволяет производить изолированный запуск ОС с подключённой файловой системой из образа, изолированно разворачивать приложения и реализовывать микросервисы. Настройки среды хранятся в GitHub, обеспечивая единую точку управления конфигурациями. Может быть использован для для развёртывания тестового окружения Компонент «Витрина данных Лайт», без прерывания работы сервисов в продуктовой среде. Официальный сайт разработчика приложения: https://www.docker.com/.
Portainer — web-приложение для управления docker-контейнерами. Официальный сайт разработчика приложения: https://www.portainer.io/.
Graylog — программное обеспечение для управления лог-файлами. Официальный сайт разработчика приложения: https://www.graylog.org/.
МongoDB — база данных Graylog. Официальный сайт разработчика приложения: https://www.mongodb.com/.
Elasticsearch — утилита полнотекстового поиска и аналитики, которая позволяет быстро в режиме реального времени хранить, искать и анализировать большие объемы данных и сохраняет их для Graylog. Для передачи сообщений в Graylog использует Filebeat. Официальный сайт разработчика приложения: https://www.elastic.co/elasticsearch/.
Filebeat — агент на сервере для отправки различных типов оперативных данных в Elasticsearch. Официальный сайт разработчика приложения: https://www.elastic.co/elasticsearch/.
Node_exporter — процессы, обеспечивающие сбор и передачу системных метрик серверу Prometheus. Также, используется для сбора метрик ПОДД-адаптера и CSV-uploader см. https://github.com/prometheus/node_exporter.

2.1.3. Операционная система

Операционная система устанавливается на сервер, где будет развернута программа.

Программа может функционировать под одной из следующих операционных систем:

CentOS 7.9 (далее - CentOS);
РЕД ОС версии 7.2 (далее - РЕД ОС);
АЛЬТ Сервер 8 СП (далее - АЛЬТ ОС);
Astra Linux 1.7 (уровень защищенности «Воронеж»).

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

Перечень состава компонентов программы версии 1.13.1 приведен в таблице ниже (см. lite_gd_tab_2)

Состав компонентов в дистрибутиве программы
Наименование компонента	Версия	Техническое наименование
graylog	4.3.15	graylog:4.3.15
prometheus	2.34.0	prometheus:2.34.0
podd-adapter-replicator	1.13.1	podd-adapter-replicator:1.13.1
podd-adapter-mppw	1.13.1	podd-adapter-mppw:1.13.1
podd-adapter-mppr	1.13.1	podd-adapter-mppr:1.13.1
kafka-jet-writer	1.2.0	kafka-jet-writer:1.2.0
podd-adapter-group-repl	1.13.1	podd-adapter-group-repl:1.13.1
podd-adapter-query	1.13.1	podd-adapter:1.13.1
csv-uploader	1.13.1	csv-uploader:1.13.1
query-execution	6.8.1	query-execution:6.8.1
grafana	9.2.15	grafana:9.2.15
node_exporter	1.2.1	node_exporter:1.2.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.8.0	kafka-postgres-writer:0.8.0
kafka-postgres-reader	0.8.0	kafka-postgres-reader:0.8.0
postgres	13.4	postgres:13.4
kafka	2.13	kafka:2.13-2.6.0-alt-p10-r3
zookeeper	3.5.7	zookeeper:3.5.7-alt-p10-r3
portainer	2.14.0	portainer:2.14.0

2.3. Cвязи между составными частями

Взаимосвязи между составными частями программы приведены в lite_gd_tab_3.

Взаимодействие между составными частями
Клиент	Сервер	Способ взаимодействия	Описание
ПОДД-адаптер — Модуль исполнения запросов	ProStore	JDBC Брокер сообщений Kafka	Исполнение запросов.
CSV-Uploader	ProStore	JDBC Брокер сообщений Kafka	Управление логической структурой таблиц. Загрузка публикуемых данных в Витрину.
ProStore	СУБД PostgreSQL	JDBC	Управление логической структурой таблиц. Исполнение запросов. Управление загрузкой публикуемых данных в Витрину.
ПОДД- адаптер — Модуль MPPR	Агент ПОДД	Через брокера сообщений Kafka	Предоставляет Результат запрос/подзапрос на получение публикуемых данных (в т.ч. с использованием ТП), делегированного ПОДД-адаптером.

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

2.4.1. ПОДД-адаптер — Модуль исполнения запросов

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

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

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

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

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

2.4.1.1.1. Общая схема взаимодействия через ПОДД-адаптер- Модуль исполнения запросов

2.4.1.1.2. Процесс обработки запроса через ПОДД-адаптер- Модуль исполнения запросов

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

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

2.4.2. ПОДД-адаптер — Модуль MPPR

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

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

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

Многопоточное параллельное чтение данных.
Отправка ответа с результатом запроса в Агент СМЭВ4.
Удаление временных таблиц, созданных на основе табличных параметров.

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

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

2.4.2.1.1. Общая схема взаимодействия

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

Получатель данных отправляет через ПОДД запрос к Витрине данных.
Запрос поступает через Агент СМЭВ4 в ПОДД-адаптер.
Если формат обработки данных предполагает MPP, то ПОДД-адаптер отправляет запрос через топик mppr.query в Модуль MPPR.
Модуль MPPR создает временную таблицу (по результатам запроса) и временный топик с запросом для Витрины.
Витрина считывает топик, обрабатывает запрос, формирует на него ответ.
Модуль MPPR получает ответ и выкладывает полученные данные во временную таблицу.
ПОДД-адаптер считывает ответ из временной таблицы и отправляет данные в Агент СМЭВ4.
Агент СМЭВ4 отправляет полученный ответ через ПОДД Получателю данных.
Модуль MPPR удаляет временный топик и таблицу.

2.4.3. ПОДД-адаптер — Модуль MPPW

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

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

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

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

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

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

2.4.4. Модуль подписок

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

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

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

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

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

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

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

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

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

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

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

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

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

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

уникальный идентификатор подписки;
источник данных по подписке – мнемоника Витрины Поставщика данных;
адресат данных по подписке – мнемоника Витрины Потребителя данных;
набор SQL-выражений, каждое из которых описывает подмножество данных Витрины;
расписание синхронизации (может отсутствовать).

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

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

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

одиночная;
распределенная.

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

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

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

количество витрин-источников больше 1;
одной подписке соответствует один SQL-запрос;
один датамарт может фигурировать в нескольких подписках витрины потребителя.

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

2.4.5. Модуль группировки чанков репликации

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

Модуль группировки чанков репликации считывает сообщение с фрагментом какой-то таблицы (в рамках какой-то дельты) из delta.in.rq.
Модуль группировки чанков репликации отправляет полученный фрагмент в динамический топик с именем, содержащим [hash (requestId+subscriptionId)], synId (номер дельты) и streamNum - топик mppw.data.X
Если полученный фрагмент является последним ( isLastChunk: true), то Модуль группировки чанков репликации отправляет сообщение (subscriptionId, synId (номер дельты), tableId) в топик subscription.in.
Модуль группировки чанков репликации подтверждает обработку (committing an offset) сообщения с фрагментом в delta.in.rq.

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

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

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

Внутренняя ИС Ведомства взаимодействует с ProStore через JDBC-driver.
ПОДД-адаптер - Модуль исполнения запросов для взаимодействия с ИС участников взаимодействия через Агента ПОДД.
CSV-uploader для взаимодействия с ИС участников взаимодействия для передачи файлов в формате XML и CSV.

Связи программы со сторонними программами приведены в см. lite_gd_tab_4.

Связи с другими программами
Клиент	Сервер	Способ взаимодействия	Описание
Внутренняя ИС Ведомств	CSV-uploader	Файловый обмен (CSV) REST	Загрузка публикуемых данных в Витрину
	ProStore	JDBC Брокер сообщений Kafka	Управление логической структурой таблиц. Исполнение запросов. Загрузка публикуемых данных в Витрину.
ПОДД-адаптер — Модуль исполнения запросов	Агент ПОДД	Брокер сообщений Kafka Kafka	Исполнение запросов.

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

Карта портов
Компонент	Описание
podd-adapter	Порт: 8083 Протокол: HTTP Описание: Взаимодействие с ПОДД-адаптером
csv-uploader	Порт: 8080 Протокол: HTTP Описание: Взаимодействие с CSV-uploader
query-execution	Порт: 8080 Протокол: HTTP Описание: номер порта сервиса метрик Порт: 9090 Протокол: TCP Описание: номер порта сервиса исполнения запросов
status_monitor	Порт: 9095 Протокол: HTTP Описание: сетевой адрес и путь для получения информации о статусе сервиса
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