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-адаптер

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

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

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

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

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

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

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

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

  1. В ПОДД поступает запрос на получение данных из Витрины.

  2. ПОДД отправляет запрос через ПОДД-адаптер в Витрину.

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

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

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

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

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

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

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

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

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

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

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

2.2.1.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.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.7 Общая схема взаимодействия модуля «Сервис Формирования документов»

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

  1. Запрос на предоставление сформированного документа поступает через Агента ПОДД, в топик report.rq (название топика может быть изменено на этапе внедрения).

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

  3. Из содержащейся в JSON-файле информации формируется итоговая форма документа. Для этого используется pebble-шаблон для XML или PDF, предназначенный для генерации документов (см. Pebble-шаблон для формирования XML-документа) и Pebble-шаблон для формирования PDF-документа.

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. Запрос поступает в Агент ПОДД.

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

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

  5. Витрина данных обрабатывает запрос и формирует на него ответ в ПОДД-адаптер.

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

  7. Агент ПОДД отправляет полученный ответ через ПОДД Получателю данных.

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

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

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

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

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

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

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

  2. Отправка ответа с результатом запроса в Агент ПОДД.

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

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

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

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

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

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

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

  2. Запрос поступает через Агента ПОДД в ПОДД-адаптер.

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

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

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

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

  7. ПОДД-адаптер считывает ответ из временной таблицы и отправляет данные в Агент ПОДД.

  8. Агент ПОДД отправляет полученный ответ через ПОДД Получателю данных.

  9. ПОДД-адаптер - Модуль 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

  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.

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.8 Список реализованных проверок

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

Код ошибки

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

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

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

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

  • Проверка соответствия заданному значению включает в себя:
2.2.12.2.2.3. Поведение в случае таймаута валидации

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

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

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

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

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

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

Статус

Наименование

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

-1

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

Получение данных от клиента и загрузка их на сервер

0

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

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

1

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

Загружаемые данные находятся на сервере и ожидают открытия дельты в сервисе Prostore

2

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

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

3

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

Данные успешно загружены

4

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

В процессе загрузки данных возникла ошибка

5

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

Запрошен статус по неизвестному идентификатору запроса

6

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

Выполняется форматно-логический контроль загружаемых данных

7

Ошибки ФЛК

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

При возникновении ошибки можно выполнить GET запрос requests/{request_id}/report/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • набор 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 сервера

2.2.15.1.1. О системе

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

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

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

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

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

  3. Получает и последовательно обрабатывает результаты выполнения sql-запросов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  2. Сервис исполнения запросов (prostore).

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

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

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

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

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

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

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

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

2.2.15.1.6. Типизация

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

  • string;

  • number;

  • object;

  • array;

  • boolean;

  • null.

2.2.15.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.2.15.1.7. Моделирование данных

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

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

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

Примечание

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

2.2.15.1.8. Метрики

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

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

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

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

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

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

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

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

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

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

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

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

Версия

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

ПОДД Агент

3.8.0

ПОДД-Агент:3.8.0

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

1.12.0

smev3-adapter:1.12.0

printable-form-service

1.12.0

printable-form-service:1.12.0

rest-adapter

1.12.0

rest-adapter:1.12.0

rest-uploader

1.12.0

rest-uploader:1.12.0

data-uploader

1.12.0

data-uploader:1.12.0

blob-adapter

1.12.0

blob-adapter:1.12.0

podd-adapter-query

1.12.0

podd-adapter-query:1.12.0

podd-adapter-replicator

1.12.0

podd-adapter-replicator:1.12.0

podd-adapter-group-repl

1.12.0

podd-adapter-group-repl:1.12.0

podd-adapter-mppr

1.12.0

podd-adapter-mppr:1.12.0

podd-adapter-mppw

1.12.0

podd-adapter-mppw:1.12.0

podd-adapter-group-tp

1.12.0

podd-adapter-group-tp:1.12.0

podd-adapter-import-tp

1.12.0

podd-adapter-import-tp:1.12.0

podd-avro-defragmentator

1.12.0

podd-avro-defragmentator:1.12.0

smevql-server

1.12.0

smevql-server:1.12.0

csv-uploader

1.12.0

csv-uploader:1.12.0

counter-provider

1.12.0

counter-provider:1.12.0

backup-manager

1.12.0

backup-manager:1.12.0

query-execution

6.7.0

query-execution:6.7.0

status-monitor

6.7.0

status-monitor:6.7.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.11.

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

Клиент

Сервер

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

Описание

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

Prostore

TCP

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

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

Apache Kafka

Адаптер ПОДД

ETL

Prostore

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

REST API

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

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

REST-адаптер

ProStore

REST API

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

ETL

ProStore

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

JDBC

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

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

ProStore

REST API

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

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

ProStore

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

REST API

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

BLOB-адаптер

HTTP

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

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

ProStore

REST API

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

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

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

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

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

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

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

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

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

ProStore

REST API

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

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

Kafka

  • получает запросы данных ПОДД, перенаправленные Адаптером ПОДД;

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

  • передает запрошенные данные в ПОДД в формате ПОДД;

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

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

ProStore

REST API

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

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

Kafka

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

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

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

ПОДД-адаптер - Модуль импорта ТП

ProStore

REST API

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

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

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

Kafka

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

  • MPPW;

  • MPPR;

  • Адаптер ПОДД;

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

ПОДД-адаптер - Модуль Группировки данных ТП

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

Kafka

  • Получает сообщения с ТП, подготовленные Wrappers’ (из единого топика);

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

ПОДД-адаптер - Wrapper

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

Kafka

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

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

TCP

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

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

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

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

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

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

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

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

Компонент

Описание

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