2. Структура программы

2.1. Составные части программы

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

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

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

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

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

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

СМЭВ3-адаптер - обеспечивает информационное взаимодействие через единый электронный сервис единой системы межведомственного электронного взаимодействия (далее – СМЭВ).
Сервис формирования документов - предназначен для обеспечения возможности формирования документов, в формате XML и PDF, на основе предварительно подготовленных pebble-шаблонов, с возможностью добавления к сформированным документам электронной подписи.
CSV-Uploader - программный модуль Витрины данных, предназначен для следующих задач: - загрузка csv-файлов; - загрузка csv-файлов со структурой Витрины; - выгрузка csv-шаблонов с демо-шаблонами структуры Витрины; - автоматический запуск загрузки csv-файлов по расписанию из выбранного каталога; - просмотр Журнала операций.
ПОДД-адаптер - Модуль исполнения запросов - предназначен для исполнения запросов ПОДД СМЭВ (через протокол коммуникации Агент ПОДД).
ПОДД-адаптер – Модуль MPPR - предназначен для чтения данных в многопоточном режиме.
ПОДД-адаптер - Модуль MPPW - исполняет запросы в многопоточном режиме, записывающие данные в Prostore.
ПОДД-адаптер - Модуль группировки данных табличных параметров - предназначен для группировки данных при выполнении запросов с табличными параметрами.
ПОДД-адаптер - Модуль импорта табличных параметров - предназначен для создания временных таблиц при выполнении временных запросов с табличными параметрами.
ПОДД-адаптер - Wrapper - образует пакеты с данными табличных параметров, поступающие от Агента ПОДД в брокер сообщений Kafka, к формату, позволяющему обрабатывать их в многопоточном режиме.
ПОДД-адаптер - Модуль подписок - предназначен для управления подписками между Получателем данных (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.

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

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

Grafana - инструмент реализован в виде панели управления и мониторинга и позволяет визуализировать системные события программы на базе собираемых метрик. Официальный сайт разработчика приложения: https://grafana.com/docs/
Prometheus - используется как система мониторинга системных ресурсов программы. Связь компонентов реализована через HTTP. Данные хранятся локально, в собственной TSBD базе, индексы хранятся в LevelDB. Метрики представляют собой time-series данные. Каждая метрика состоит из имени метрики, временной метки и пары «ключ – значение». Визуализация осуществляется через подключение к Grafana. Официальный сайт разработчика приложения: https://prometheus.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.
Docker - программное обеспечение для автоматизации развёртывания и управления программы в виртуальных средах с поддержкой контейнеризации. Используется для установки Arenadata Cluster Manager (ADCM). Официальный сайт разработчика приложения: https://www.docker.com/

2.2. Модули программы

2.2.1. BLOB-адаптер

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

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

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

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

Примечание

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

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

настройка доступа в Хранилище BLOB-объектов;
предоставление регламентированного доступа к BLOB-объектам;
получение и отправка запросов на получение BLOB-объектов;
чтение BLOB-объектов;
сохранение BLOB-объектов на FTP-сервере (через СМЭВ3-адаптер).

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

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

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

2.2.1.3. Взаимодействие через ПОДД-адаптер

2.2.1.3.1. Схема взаимодействия через ПОДД-адаптер

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

Рисунок - 2.5 Взаимодействие BLOB-адаптера через ПОДД-адаптер

2.2.1.3.2. Процесс обработки запроса на получение BLOB-объекта (ПОДД-адаптер)

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

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

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

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

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

Из внешней ИС в СМЭВ поступает запрос на получение данных из Витрины.
СМЭВ3-адаптер получает запрос и отправляет его в Витрину.
Витрина обращается к БД, подготавливает ответ на запрос. Если в запросе есть ссылка на BLOB-объект, BLOB-адаптер обращается к Хранилищу BLOB-объектов, копирует BLOB-объект, выкладывает его на FTP-сервер СМЭВ и отправляет ссылку на BLOB-объект в Витрину.
После того как BLOB-объект загружен на FTP-сервер СМЭВ, Витрина отправляет ответ на запрос в СМЭВ, в котором содержится ссылка на BLOB-объект (сохраненный на FTP-сервере).
После получения ответа внешняя ИС может обратиться по ссылке и скачать BLOB-объект с FTP-сервера СМЭВ.

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

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

/etc/hosts
/etc/selinux/config
/etc/sysctl.conf
файлы директории /usr/lib/systemd/system/
/etc/sysconfig/iptables\*
/etc/firewalld/\*
/etc/docker/\*

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

22 (SSH).

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

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

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

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

Примечание

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

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

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

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

Считывание BLOB-объекта производится по протоколу HTTP (допустимо HTTPS, указывается в конфигурации файла application.yml, параметр host (см. раздел Конфигурация BLOB-адаптера (application.yml) )).

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

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

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

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

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

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

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

XML;

PDF.

отправлять сформированные документы на подпись в Сервис электронной подписи (например, КриптоПро).
отправлять сформированные и подписанные документы в ПОДД в виде ответа на пришедший запрос.

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

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

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

Запрос на предоставление сформированного документа поступает через Агента ПОДД, в топик report.rq (название топика может быть изменено на этапе внедрения).
ПОДД-адаптер считывает запрос из топика и передает его в Сервис Формирования документов. Сервис Формирования документов запускает соответствующий пришедшему типу документа pebble-шаблон, собирает данные из Витрины (Prostore) и формирует на основании этих данных JSON-файл.
Из содержащейся в JSON-файле информации формируется итоговая форма документа. Для этого используется pebble-шаблон для XML или PDF, предназначенный для генерации документов (см. Pebble-шаблон для формирования XML-документа) и Pebble-шаблон для формирования PDF-документа.
В случае, если электронная подпись не требуется, то PDF-документ сразу пересылается в топик report.rs Kafka ПОДД-адаптера.
Если требуется электронная подпись:

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

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

Агент ПОДД проверяет топик и забирает сформированные документы для передачи в ПОДД.

Внимание

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

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

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

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

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

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

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

Внимание

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

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

Внешняя ИС выполняет запрос к СМЭВ 3 на получение данных от Поставщика данных.
Запрос через CМЭВ3-адаптер отправляется в СМЭВ.
Адаптер СМЭВ 3 на стороне Поставщика данных принимает запрос из СМЭВ и отправляет его в Витрину данных поставщика.
В Витрине Поставщика данных формируется ответ на поступивший запрос.

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

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

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

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

Установка опциональна

Обмен сообщениями между ПОДД-адаптера - Модуль исполнения запросов и Агент ПОДД происходит через заранее согласованные топики брокера сообщений Kafka.

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

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

Рисунок - 2.9 Взаимодействие программы с ПОДД

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

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

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

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

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

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

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

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

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

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

Формат обмена электронными сообщениями описан в разделе Спецификация модуля ПОДД-адаптера - Модуль исполнения запросов Технического описания программы.

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

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

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

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

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

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

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

2.2.7. ПОДД-адаптер - Модуль группировки данных табличных параметров

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

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

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

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

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

2.2.8. ПОДД-адаптер - Модуль импорта табличных параметров

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

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

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

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

2.2.9. ПОДД-адаптер - Wrapper

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

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

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

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

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

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

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

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

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

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

delta.in.rq

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

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

2.2.10.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.2.11. DATA-Uploader - Модуль исполнения асинхронных заданий

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

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

обработка очереди файлов производится циклами;
очередь файлов работает в режиме упорядочения процесса по принципу «первым пришел – первым обслужен»;
каждый элемент в очереди файлов содержит UUID задания, имя витрины и таблицы, содержимое CSV-файла;
файлы в очереди могут относится к разным витринам и/или разным таблицам одной витрины.

Примечание

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

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

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

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

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

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

идентификатор генерируется по стандарту UUID;
метаданные от сервера витрины кешируются механизмом, и проверяются на соответствие по количеству и по типам полей (при несоответствии загружаемых данных метаданным целевой таблицы сервис для передачи / загрузки данных возвращает статус запроса с ошибкой, без размещения данных в очереди на загрузку);
загруженные данные размещаются вместе с UUID в очереди с именем «queue»;
формируется запись с ключом «status.[UUID запроса]» и статусом 0 в очереди;
клиенту, отправившему запрос, возвращается успешный статус запроса вместе с UUID;
в логе приложения формироваться запись события получения запроса на загрузку с указанием идентификатора запроса, идентификатора ВУЗа, времени обработки и размера загруженных данных.

Внимание

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

Примечание

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

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

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

Таблица 2.6 Список реализованных проверок
Наименование проверки	Код ошибки	Кирилическое описание
проверка уникальности	dublicate	дубликат файла/группы
Проверка парсинга файла	parsingErr	ошибка парсинга: текст ошибки
проверка кодирования	encodingErr	кодировка файла не соответствует кодировке UTF-8
Проверка превышения предельного размера файла (больше 512 Мб)\|	tooLargeFile	слишком большой файл
Проверка наличия данных в файле	emptyFile	пустой файл
проверка соответствия заголовков инфосхеме	wrongMetadata	структура файла не соответствует схеме
проверка соответствия числа столбцов в строке	wrongFieldsCount	некорректное число столбцов в строке
проверка соответствия типам полей	wrongFieldType	значение не соответствует типу требуемый тип
проверка уникальности полей	nonUniq	значение не отвечает требованиям уникальности
проверка регулярных выражений	nonMatchRegex	значение не соответствует регулярному выражению регулярное выражение
проверка соответствия условию	nonMatchConstant	значение не соответствует условию условие
Таймаут валидации	validationTimeout	истек таймаут валидации файла

2.2.12.2.1. Синхронная проверка ФЛК

Примечание

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

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

проверка соответствия инфосхеме:
- проверка соответствия имен и количества полей в заголовках;
- проверка типа данных;
- проверка экранирования данных: проверка соответствия числа столбцов по каждой строке;
проверка соответствия файла кодировке UTF-8 , отсутствие BOM (при наличии BOM отрезаем при загрузке начальные байты ef bb bf);
проверка размера файла и наличия данных:
- проверка предельного размера загружаемого файла 512Мб;
- проверка наличия данных в файле.

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

Примечание

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

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

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

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

2.2.12.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.2.12.2.2.2. Проверка соответствия заданному значению

Проверка соответствия заданному значению проводится для каждого файла вне зависимости от наличия group_id
Проверка осуществляется для значений каждого поля в соответствии с заданным правилом
Проверка соответствия заданному значению включает в себя:
- проверку сравнения с константой („>“, „<“, ‘> =“, „<=“, „=“, „!=“ );
- проверку соответствия регулярному выражению (должна выполняться на основе Java Util Regexp https://docs.oracle.com/javase/7/docs/api/java/util/regex/package-summary.html )

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

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

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

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

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

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

Таблица 2.7 Статусная модель
Статус	Описание

-1	Загрузка данных в буффер
0	Запрос буфферизирован
1	Ожидает открытия дельты
2	В обработке (модулем DATA-Uploader)
3	Успешно обработан
4	Ошибка обработки запроса
5	Идентификатор запроса не обнаружен
6	Форматно-логический контроль
7	Ошибки ФЛК

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

2.2.13. ПОДД-адаптер - Модуль подписки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.14. REST-адаптер

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

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

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

REST-адаптер:

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

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

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

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

2.2.15. СМЭВ QL Сервер

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

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

2.2.15.1.1. Реализованные функции СМЭВ QL Сервера

СМЭВ QL Сервер является компонентом Типового ПО Витрина данных, создающим типовое API витрины согласно спецификации СМЭВ QL.
Поддержка множественных источников данных:
- Витрины под управлением Prostore;
- Другие СМЭВ QL Сервера;
Выбор источника по условиям запроса;
Защищаемые атрибуты модели данных;
- На извлечение по предоставлению «защитников»;
- На поиск;
Автоматический параллелизм запросов к источникам;
Ответ — готовый к использованию иерархический JSON-объект;
Документная модель данных с генератором из текущей логической модели Prostore;
Связи между ресурсами модели;
Сжатие ответов с данными (gzip);
Рекомендации индексов в БД;
Постраничные запросы и ответы;
Поддержка СМЭВ QL запросов компонентами витрины:
- Сервис печатных форм;
- СМЭВ3 адаптер;
Стейт-машина для СМЭВ QL объектов (бронирования, блокировки, разрешения).

Примечание

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

2.2.15.2. Быстрый старт

2.2.15.2.1. Создание и конфигурация

Создать новое приложение СМЭВ QL Сервера командой:

java -jar smevql-server-all.jar new <new-app-name>

Данная команда создаст структуру папок сервера внутри <new-app-name> и исполняемый файл smevql.

2.2.15.2.2. Запуск и управление

Запуск СМЭВ QL Сервера осуществляется командой:

./smevql start -e <environment>

Где environment - это указание окружения. Без указания окружения сервер будет запущен в development.

Остановка СМЭВ QL Сервера осуществляется командой:

./smevql stop

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

./smevql restart

2.2.15.2.3. Работа с сервером

2.2.15.2.3.1. Генераторы

Генераторы создают папки и файлы-шаблоны с начальными значениями. Для запуска генератора можно использовать полную команду ./smevql generate или короткий алиас ./smevql g.

Новый пустой источник генерируется командой:

./smevql g source <source-name>

Пример источника на основе Prostore:

prostore_source:
type: rest
version: '1.0'
adapter: prostore
protocol: http
host: smevql-dtm-prostore01.ru-central1.internal
port: 9090
path: api/v1/datamarts/query?format=json
headers:
    - content-type: application/json
threads-count: 4
connection-timeout: 30

Новая модель генерируется командой:

./smevql g model <model-name>

Пример модели:

resources:
- mo: *base_model
    name: Медицинская организация
    description: Логическая таблица "Медицинская организация"
    fields:
    <<: *default_fields
    parent_id:
        <<: *ds
        name: parent_id
    update_ts:
        <<: *dts
        name: update_ts
    address:
        <<: *ds
        name: address
    address_fias_guid:
        <<: *ds
        name: address_fias_guid
    enabled:
        <<: *ds
        name: enabled
    name:
        <<: *ds
        name: name
    region_okato:
        <<: *ds
        name: region_okato
    create_ts:
        <<: *dts
        name: create_ts
    id:
        <<: *pks
        name: id
    rmis_id:
        <<: *ds
        name: rmis_id
    phone:
        <<: *ds
        name: phone
    connections:
    has_many: []
    belongs_to:
    - attachment:
        primary_key: [ mo_id ]
        foreign_key: [ id ]
    - resource:
        primary_key: [ mo_id ]
        foreign_key: [ id ]
    extract:
    source:
        - name: prostore
        table: misdm02.mo
- profilecode_resource: *base_model
- resource: *base_model
- observation: *base_model
- book: *base_model
- slot: *base_model
- monitoring: *base_model
- referral: *base_model
- attachment: *base_model
- patient: *base_model
- service: *base_model
- unaccessible_period: *base_model

Из существующего Prostore модель генерируется командой:

./smevql schema-gen test -h localhost -p 9090 -d demo_view

test - имя директории, куда будет выгружена модель;
-d demo_view - это витрина (схема);
-h localhost -p 9090 - это хост и порт Prostore.

2.2.15.2.4. Стейт-машина СМЭВ QL

СМЭВ QL содержит встроенную машину состояний для изменения объектов модели внутри витрин данных. Одновременно с этим Стейт машина может, в качестве подтверждения перехода состояния, использовать внешний источник (например ИС Электронной очереди).

Карта состояний и переходов описывается в виде YAML-файла state.yaml располагаемого в папке states/<имя-модели>/<х.х версия модели> инстанса СМЭВ QL Сервера.

При наличии заполненных состояний машины СМЭВ QL Сервер генерирует API c набором HTTP-методов, отвечающих за изменение и просмотр состояний объектов:

GET /states — получить карту переходов
GET /states/<model-name> — получить карту переходов конкретной модели
POST /states/<model-name>/<event-name> — выполнить переход состояний для модели

2.2.15.2.5. Сборка проекта

Собрать проект можно с помощью gradle:

./gradlew clean build

2.2.15.3. Метрики

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

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

Пример по подключению журналирования.

Пример по подключению мониторинга.

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

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

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

Таблица 2.8 Состав компонентов в дистрибутиве программы
Наименование компонента	Версия	Техническое наименование
ПОДД Агент	3.8.0	ПОДД-Агент:3.8.0
СМЭВ3-адаптер	1.11.1	smev3-adapter:1.11.1
printable-form-service	1.11.1	printable-form-service:1.11.1
rest-adapter	1.11.1	rest-adapter:1.11.1
rest-uploader	1.11.1	rest-uploader:1.11.1
data-uploader	1.11.1	data-uploader:1.11.1
blob-adapter	1.11.1	blob-adapter:1.11.1
podd-adapter-query	1.11.1	podd-adapter-query:1.11.1
podd-adapter-replicator	1.11.1	podd-adapter-replicator:1.11.1
podd-adapter-group-repl	1.11.1	podd-adapter-group-repl:1.11.1
podd-adapter-mppr	1.11.1	podd-adapter-mppr:1.11.1
podd-adapter-mppw	1.11.1	podd-adapter-mppw:1.11.1
podd-adapter-group-tp	1.11.1	podd-adapter-group-tp:1.11.1
podd-adapter-import-tp	1.11.1	podd-adapter-import-tp:1.11.1
podd-avro-defragmentator	1.11.1	podd-avro-defragmentator:1.11.1
smevql-server	1.11.1	smevql-server:1.11.1
csv-uploader	1.11.1	csv-uploader:1.11.1
counter-provider	1.11.1	counter-provider:1.11.1
backup-manager	1.11.1	backup-manager:1.11.1
query-execution	6.5.0	query-execution:6.5.0
status-monitor	6.5.0	status-monitor:6.5.0
kafka	2.6.0	kafka:2.6.0
zookeeper	3.5.7	zookeeper:3.5.7
redis	7.0.11	redis:7.0.11
fdw	0.10.2	fdw:0.10.2
pxf	1.0	pxf:1.0

«Установка опциональна» означает - что необходимость установки компонента определяется из схемы развертывания витрины в конкретном ведомстве.

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

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

Взаимосвязи между составными частями программы приведены в Таблица 2.9.

Таблица 2.9 Взаимодействие между составными частями
Клиент	Сервер	Способ взаимодействия	Описание
Сервисная база данных Prostore (PostgreSQL)	Prostore	TCP	Хранение/получение метаданных
	СУБД хранилища
	Apache Kafka
	Адаптер ПОДД
	ETL
Prostore	Хранилище СУБД	JDBC REST API в зависимости от типа СУБД хранилища данных	Перенаправление запросов в конкретную СУБД
REST-адаптер	ProStore	JDBC	Исполнение запросов
ETL	ProStore	Kafka (Диспетчер сообщений) JDBC	Исполнение запросов
Сервис формирования документов	ProStore	Через JDBC-драйвер по REST	Запрашивает данные для формирования ПФ
СМЭВ3-адаптер	ProStore	Kafka (Диспетчер сообщений) JDBC	Исполнение запросов
	BLOB-адаптер	HTTP	Запрашивает бинарное содержимое BLOB.
ПОДД-адаптер - Модуль исполнения запросов	ProStore	Через JDBC-драйвер по REST	исполняет полученный запрос (LLR); запрашивает структуру таблиц при подписании на репликацию (источник данных); создает структуру таблиц при подписании на репликацию (потребитель данных);
	Диспетчер сообщений Kafka	Kafka (Диспетчер сообщений) JDBC	получает сообщение о закрытии новой дельты в ProStore (для репликации, источник данных); обменивается управляющей информацией с модулем импорта ТП; отправляет запросы, перенаправленные в Модуль MPPR.
ПОДД-адаптер - Модуль MPPR	ProStore	Через JDBC-драйвер по REST	Подает запрос MPPR.
	Диспетчер сообщений Kafka	Kafka	получает запросы данных ПОДД, перенаправленные Адаптером ПОДД; получает запрошенные данные из ProStore (в формате MPPR); передает запрошенные данные в ПОДД в формате ПОДД; обменивается управляющей информацией с модулем импорта ТП.
ПОДД-адаптер - Модуль MPPW	ProStore	Через JDBC-драйвер по REST	Подает запрос MPPW.
	Диспетчер сообщений Kafka	Kafka	получает записываемые данные, подготовленные модулем Группировки данных ТП; передает записываемые данные в ProStore (в формате MPPW); обменивается управляющей информацией с модулем импорта ТП.
ПОДД-адаптер - Модуль импорта ТП	ProStore	Через JDBC-драйвер по REST	создает табличный параметр (перед выполнением запроса); удаляет табличный параметр (после выполнения запроса).
	Диспетчер сообщений Kafka	Kafka	Обменивается управляющей информацией с модулями: MPPW; MPPR; Адаптер ПОДД; Группировки данных ТП.
ПОДД-адаптер - Модуль Группировки данных ТП	Диспетчер сообщений Kafka	Kafka	Получает сообщения с ТП, подготовленные Wrappers’ (из единого топика); создает отдельные топики для каждого ТП и передает в них сообщения с данными этого ТП.
ПОДД-адаптер - Wrapper	Диспетчер сообщений Kafka	Kafka	Передает сообщения с ТП, в формате пригодном для параллельной обработки
	Сервисная СУБД Zookeeper	TCP	Сохраняет список обрабатываемых сообщений ТП Хранение метаданных о подписках на репликацию (источник данных).

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

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

Связи программы с другими программами приведены в Раздел 2.6.

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

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

Таблица 2.10 Карта портов
Компонент	Описание
podd-adapter-query	Порт: 8083 Протокол: HTTP Описание: Взаимодействие с ПОДД-адаптером
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