3. ОПИСАНИЕ ЗАДАЧИ

3.1. Определение задачи

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

  • Описание логической модели данных.

  • Загрузка и хранение данных.

  • Извлечение данных из внешних систем.

  • Поддержка языка SQL.

  • Поддержка протокола коммуникации агента ПОДД.

  • Подключение к СМЭВ3 как информационной системы участника взаимодействия.

  • Обработка запросов с использованием стандарта JDBC.

  • Публикация конечных точек API для обработки запросов с использованием спецификации OpenAPI версии 3.

  • Восстановление данных в непротиворечивое состояние после сбоев.

  • Журналирование событий функциональных блоков.

  • Мониторинг информации о работоспособности экземпляра Программы.

В разделе Методы решения задачи представлено описание задач и методов их решения. Описание процедур вызова программы (способы передачи управления и параметров данных) описаны в документе «Руководство программиста», раздел 3 «Обращение к программе».

3.2. Методы решения задачи

3.2.1. Описание логической модели данных

3.2.1.1. Задача «Создание логической модели данных «ЕИП НСУД – Поставщик данных»

Задача представляет собой возможность создания логической модели данных в ЕИП НСУД и ее последующую выгрузку в Витрину поставщика данных.

Результатом решения данной задачи, представлен процесс выполнения следующих действий см. Рисунок - 3.12:

Создание логической модели данных «ЕИП НСУД – Поставщик данных»

Рисунок - 3.12 Создание логической модели данных «ЕИП НСУД – Поставщик данных»

  1. В ЕИП НСУД создается логическая модель данных для Витрины поставщика данных.

  2. ЕИП НСУД отправляет модель через ПОДД в Агент ПОДД.

  3. Агент ПОДД, через ПОДД-адаптер передает модель в Витрину данных, в которой создается логическая модель данных.

3.2.1.2. Задача «Создание логической модели данных «Внешняя ИС – Поставщик данных»

Задача представляет собой возможность создания логической модели данных в Витрине данных поставщика средствами Внешней ИС. В качестве Внешней ИС может выступать любое ПО, способное:

  1. Использовать JDBC-драйвер для подключения к Витрине данных.

  2. Через JDBC-драйвер выполнять SQL-запросы к Витрине данных для создания логической модели данных.

Внешняя ИС напрямую подключается к Витрине данных Поставщика данных.

В этом случае процесс выглядит следующим образом см. fig_gost_op_3

Создание логической модели данных «Внешняя ИС – Поставщик данных»

Рисунок - 3.13 Создание логической модели данных «Внешняя ИС – Поставщик данных»

3.2.1.3. Задача «Создание логической модели данных «ЕИП НСУД – Потребитель данных»

Задача представляет собой возможность создания логической модели в Витрине потребителя данных в случае подписания его в ЕИП НСУД на репликацию данных (предоставляемых Поставщиком данных). В этом случае процесс в части, касающейся создания логической модели данных, выглядит следующим образом см. Рисунок - 3.14

Создание логической модели данных «ЕИП НСУД – Потребитель данных»

Рисунок - 3.14 Создание логической модели данных «ЕИП НСУД – Потребитель данных»

  1. В ЕИП НСУД регистрируется подписка на репликацию.

  2. ЕИП НСУД через ПОДД и Агент ПОДД отправляет подписку на репликацию в Витрину Поставщика данных и в ответ от Витрины получает структуру данных.

  3. ЕИП НСУД через ПОДД и Агент ПОДД отправляет в Витрину Потребителя данных структуру таблиц.

  4. Витрина Потребителя данных создает у себя таблицы для хранения реплицируемых данных.

3.2.1.4. Задача и методы решения

Задача включает возможность описания логической модели данных.

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

  • схема;

  • таблица;

  • столбцы;

  • уникальные ключи (первичные и альтернативные);

  • внешние ключи;

  • индексы;

  • типы данных.

При реализации указанного метода программа поддерживает возможность обработки SQL-запросов:

  • SQL+ DDL. Поддерживаются инструкции CREATE/DROP DATABASE, CREATE/ DROP TABLE, CREATE/ DROP VIEW.

  • SQL+ EDDL. Поддерживаются инструкции CREATE/ DROP DOWNLOAD EXTERNAL TABLE, CREATE/ DROP UPLOAD EXTERNAL TABLE.

  • Формирование логической модели с использованием типов: BOOLEAN, INT, BIGINT, FLOAT, DOUBLE, VARCHAR, UUID, DATE, TIME, TIMESTAMP.

3.2.2. Загрузка и хранение данных

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

Загрузка данных, представляет собой часть процесса:

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

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

  • Загрузки и хранения данных.

  • Версионирование загружаемых данных на уровне записей.

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

  • Создание новой версии записи.

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

3.2.3. Извлечение данных из внешних систем

3.2.3.1. Задача «Извлечение и преобразование данных из внешних ИС»

Задача представляет собой возможность извлечения и преобразования данных из Внешних ИС (внешних по отношению к Витрине данных НСУД) и загрузку обработанных данных в Витрину данных.

Извлечение данных из внешних информационных систем состоит из трех этапов см. Рисунок - 3.15

  1. Извлечение данных.

  2. Преобразование данных.

  3. Загрузка данных в «Витрину данных НСУД» (см. раздел 3.2.2).

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

Извлечение и преобразование данных из внешних ИС

Рисунок - 3.15 Извлечение и преобразование данных из внешних ИС

Общая схема процесса извлечения, преобразования и загрузки данных в витрину выглядит следующим образом см. Рисунок - 3.16

Схема обработки данных из внешних систем

Рисунок - 3.16 Схема обработки данных из внешних систем

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

  1. ETL извлекает информацию из:

  • СУБД Внешней ИС (используя стандарт JDBC и язык SQL).

  • Загружает файлы выложенные в файловом хранилище ведомства (формат xml и csv).

  1. Полученные данные обрабатываются в ETL (см. fig6), в соответствии с настроенными правилами обработки данных (последовательность и правила обработки данных настраиваются в DAG-файле).

  2. Обработанные данные загружаются в Kafka-loader.

  3. Через JDBC-драйвер происходит загрузка данных в Витрину данных. Например, передается SQL-запрос на создание в Витрине данных таблиц и наполнением их данными из выбранных топиков Kafka-loader.

3.2.3.2. Задача и методы решения

Задача включает следующие действия:

  • Чтение данных из внешних (по отношению к «Витрине данных НСУД») источников с использованием стандарта JDBC и языка SQL.

  • Чтение данных из файлов формата:

  • csv;

  • xml.

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

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

  • трансформация и сохранение данных;

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

  • обработки и трансформации данных;

  • сохранение информации о выданных управляющих воздействиях в лог-файле;

  • выдача программным средствам управляющих воздействий для возможности чтения данных из файла xml, csv;

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

3.2.4. Поддержка языка SQL

3.2.4.1. Задача «SQL-запрос через ПОДД»

Задача представляет собой возможность отправки SQL-запросов на получение данных от Внешней ИС через ПОДД в Витрину Поставщика данных.

В результате решения данной задачи создан процесс обработки данных, который выглядит следующим образом см. Рисунок - 3.17

SQL-запрос через ПОДД

Рисунок - 3.17 SQL-запрос через ПОДД

  1. Внешняя ИС формирует SQL-запрос и отправляет его через Агент ПОДД.

  2. SQL-запрос доставляется из ПОДД в Агент ПОДД Поставщика данных.

  3. Агент ПОДД на стороне Поставщика данных принимает запрос и отправляет его в Витрину данных через ПОДД-адаптер.

  4. В Витрине данных формируется ответ на SQL-запрос (он отправляется по описанной цепочке в обратном направлении).

3.2.4.2. Задача «SQL-запрос через СМЭВ 3»

Задача представляет собой возможность отправки SQL-запросов на получение данных от Внешней ИС через СМЭВ3 в Витрину Поставщика данных

В результате решения данной задачи создан процесс обработки данных, который выглядит следующим образом см. Рисунок - 3.18

SQL-запрос через СМЭВ 3

Рисунок - 3.18 SQL-запрос через СМЭВ 3

  1. Внешняя ИС формирует SQL-запрос и отправляет его через CМЭВ3-адаптер в СМЭВ 3.

  2. SQL-запрос доставляется из СМЭВ 3 в CМЭВ3-адаптер Поставщика данных.

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

  4. В Витрине данных формируется ответ на SQL-запрос (он отправляется по описанной цепочке в обратном направлении).

3.2.4.3. Задача «Прямой SQL-запрос от Внешней ИС»

Задача представляет собой возможность выполнения SQL-запроса непосредственно от Внешней ИС к Витрине данных.

В результате решения данной задачи создан процесс обработки данных, который выглядит следующим образом см. Рисунок - 3.19

Прямой SQL-запрос из Внешней ИС

Рисунок - 3.19 Прямой SQL-запрос из Внешней ИС

  1. Внешняя ИС формирует SQL-запрос.

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

3.2.4.4. Задача и методы решения

Задача включает следующие действия:

  • поддержка языка SQL.

Выполнение SQL-запросов в программеВыполнение SQL-запросов в программе

Рисунок - 3.20 Выполнение SQL-запросов в программеВыполнение SQL-запросов в программе

Для решения задачи применяются методы:

  • метод обработки данных.

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

  • Использование SQL``+ ``DML как базовый способ доступа к данным в экземпляр Программы. Поддерживаются инструкции SELECT и USE.

  • Запрос к архивным состояниям, идентифицируемым номером или датой загруженного пакета, с использованием SQL-инструкции FOR SYSTEM\_TIME AS OF.

  • Использование SQL``+ ``EDML как способ доступа к данным в экземпляре Программы. Поддерживаются инструкции UPLOAD и DOWNLOAD.

Получение данных для Внешних ИС возможно выполнить с помощью:

  • SQL-запрос через ПОДД.

  • SQL-запрос через СМЭВ.

  • Прямой SQL-запрос к Поставщику данных.

3.2.5. Поддержка протокола коммуникаций Агента ПОДД

3.2.5.1. Задача «Поддержка протокола коммуникации ПОДД»

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

Для решения задачи был разработан ПОДД-адаптер, в котором была реализована возможность обмена сообщениями с Агент ПОДД через заранее согласованные топики (службы обмена сообщениями Apache Kafka).

В результате решения задачи Витрина данных имеет возможность взаимодействовать через Агент ПОДД и решать следующие задачи:

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

  • регистрировать подписку на репликацию данных;

  • принимать и сохранять реплицируемые из других Витрин данные;

  • предоставлять хранимые данные по запросам Потребителей данных.

Результатом решения задачи, стал следующий процесс:

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

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

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

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

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

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

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

3.2.5.2. Задача и методы решения

Задача включает следующие действия:

  • обработка поступающих запросов от ПОДД.

Для решения задачи применяются методы:

  • метод обработки данных;

  • метод межведомственного взаимодействия.

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

  • Поддержка протокола коммуникации агента ПОДД, устроенного в виде обмена сообщениями через заранее согласованные топики службы обмена сообщениями Apache Kafka.

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

  • Создание и хранение актуальных копий данных витрин поставщиков на стороне потребителя данных (создание и сохранение копий происходит путем взаимодействия с Агентом ПОДД через протокол коммуникаций).

  • Формирование по запросу инкремента реплицируемого набора данных на стороне Поставщика данных.

  • Чтение данных из реплик с использованием SQL на стороне потребителя данных.

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

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

3.2.6. Подключение к СМЭВ 3 как информационной системе участника взаимодействия

3.2.6.1. Задача «Подключение к СМЭВ 3»

Задача представляет собой возможность взаимодействия с «Витринной данных НСУД» через СМЭВ3.

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

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

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

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

3.2.6.2. Задача и методы решения

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

Задача включает следующие действия:

  • подключение к СМЭВ;

  • обмен данными.

Схема подключения к СМЭВ3

Рисунок - 3.21 Схема подключения к СМЭВ3

Для решения задачи применяются методы:

  • метод обработки данных;

  • метод межведомственного взаимодействия.

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

  • загрузка запросов из очереди ИС УВ (Информационная система Участника Взаимодействия) в СМЭВ 3;

  • формирование и отправку ответов в СМЭВ 3;

  • инициативное формирование уведомлений об изменении данных в экземпляре Программы и отправку уведомлений в СМЭВ 3 в соответствии с описанием вида сведений, разработанным для формирования таких уведомлений;

  • поддержка конфигурирования, которое предоставляет возможность использовать атрибуты запросов СМЭВ 3 для того, чтобы:

  • формировать и выполнять SQL-запросы к программе;

  • формировать и отправлять ответы на SQL-запросы в очередь ответов СМЭВ.

3.2.7. Обработка запросов с использованием стандарта JDBC

3.2.7.1. Задача «Обработка запросов с использованием стандарта JDBC»

Задача представляет собой возможность подключения к БД «Витрины данных НСУД» с использованием стандарта JDBC.

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

Подключение через JDBC-драйвер к БД «Витрины данных НСУД» используется в следующих компонентах программы:

  • ПОДД-адаптер.

  • CМЭВ3-адаптер.

  • ETL.

  • REST-адаптер.

В результате подключения к Витрине данных, Получатель данных имеет возможность отправлять прямые SQL-запросы к БД «Витрины данных НСУД и получать на них ответы.

Результатом решения задачи, стал следующий процесс:

  1. Получатель данных загружает и устанавливает JDBC-драйвер.

  2. JDBC-драйвер устанавливает соединение с БД Поставщика данных.

  3. Получатель данных создает SQL-запрос на получение данных.

  4. JDBC-драйвер отправляет запрос в БД Витрины данных.

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

Обработка запросов с использованием стандарта JDBC

Рисунок - 3.22 Обработка запросов с использованием стандарта JDBC

3.2.7.2. Задача и методы решения

Задача включает следующие действия:

  • обработка запросов с использованием стандарта :JDBC.

Для решения задачи применяются методы:

  • метод обработки данных;

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

  • Отправка запросов к Программе в соответствии со стандартом JDBC.

JDBC-драйвер поддерживает следующие SQL-запросы:

 1CREATE/DROP DATABASE
 2CREATE/DROP/ALTER TABLE
 3CREATE/DROP/ALTER VIEW
 4BEGIN/COMMIT/ROLLBACK DELTA
 5SELECT
 6USE
 7CREATE/DROP DOWNLOAD EXTERNAL TABLE
 8CREATE/DROP UPLOAD EXTERNAL TABLE
 9UPLOAD
10DOWNLOAD

3.2.8. Публикация конечных точек API для обработки запросов с использованием спецификации OpenAPI версии 3

3.2.8.1. Задача «Подключение Внешней ИС через Сервер конечных точек (REST-адаптер)»

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

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

  2. REST-адаптер:

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

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

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

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

3.2.8.2. Задача и методы решения

Задача включает следующие действия:

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

Для решения задачи применяются методы:

  • метод обработки данных;

  • метод публикации данных в формате API (спецификация OpenAPI версии 3).

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

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

  • конечная точка доступа поддерживает конфигурирование, которое позволяет:

  • с использованием атрибутов HTTP-запроса построить и выполнить SQL-запросы из Внешней ИС к программе;

  • с использованием атрибутов HTTP-запроса и результатов SQL-запросов построить и отправить ответ на HTTP-запрос из программы к Внешней ИС;

  • документировать сконфигурированный API с использованием спецификации OpenAPI версии 3.

3.2.9. Восстановление данных в непротиворечивое состояние после сбоев

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

В рамках решения задачи установлены возможные точки нарушения целостности данных:

  1. При загрузке данных в Витрину данных.

  2. При загрузке данных в ETL.

  3. При репликации через ПОДД (репликации данных между ведомствами).

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

  1. Метод контроля дельты, в этом случае непротиворечивость данных контролируется тем, что все транзакции (дельты), которые были завершены в процессе выполнения репликации или загрузке данных в Витрину данных, применяются, а все транзакции, которые не были завершены, например, при сбое оборудования, считаются не консистентными и подвергаются откату (восстановлению) до актуальной синхронизированной дельты.

Контроль дельты, вычисляется хэш-функцией использующей алгоритм MD5 для всей дельты. При передаче данных через Kafka дельта может делиться на несколько пакетов. В последнем пакете при передаче от Поставщика данных к Получателю передается контрольная хэш-сумма дельты. После получения последнего пакета происходит сравнение хэш-суммы переданных пакетов и контрольной хеш-суммы всей дельты. Если суммы не совпадают, то передача дельты полностью отменяется.

  1. Метод контроля передачи пакетов Kafka, в этом случае поврежденный пакет не сможет десериализоваться т.к. в каждом пакете передается схема данных по которой проверяются данные.

Актуальное состояние дельты контролируется хэш-суммой состояния данных.

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

  • поддержка топологии кластеров БД, включающей в себя в том числе определение правил репликации и степени избыточности.

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

  • загрузка дельт происходит строго последовательно – новая дельта строго после подтверждения загрузки предыдущей.

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

3.2.10. Журналирование событий функциональных блоков

*Мониторинг и журналирование событий в системе*

Рисунок - 3.23 Мониторинг и журналирование событий в системе

Задача включает следующие действия:

  • журналирование событий функциональных блоков:

  • Ядро витрины (Prostore);

  • Брокер сообщений;

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

  • ADCM;

  • CМЭВ3-адаптер (включает собственную сервисную БД); :

  • REST-адаптер;

  • ETL;

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

  • ADB;

  • ADQM;

  • ADG.

Для решения задачи применяются методы:

  • метод обработки данных;

  • метод журналирования событий.

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

  • запись системных событий (отдельно по каждому функциональному блоку) осуществляется в лог-файлы ( см. Рисунок - 3.23 ).

  • предоставление возможности просмотра журнала событий (лог-файла).

Инструкция о порядке просмотра лог-файлов описана в «Руководстве оператора».

Настройку детализации лог-файлов осуществляет системный программист.

3.2.11. Мониторинг информации о работоспособности экземпляра Программы

Задача включает следующие действия:

  • Мониторинг информации о работоспособности экземпляра Программы.

Для решения задачи применяются методы:

  • метод обработки данных;

  • метод журналирования событий.

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

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

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

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

  • Сеть

  • Переданные пакеты/байты

  • Ошибочные/отброшенные пакеты

  • Коллизии

  • CPU

  • Load average (усредненная загрузка)

  • Простой/использование CPU

  • Данные утилизации CPU по отдельным процессам

  • Память

  • Свободная/использованная память

  • Утилизация swap/файла подкачки

  • Диск

  • Свободное/занятое дисковое пространство

  • I/O чтения и записи

  • Служба

  • Состояние процесса

  • Использование памяти процессом

  • Состояние службы (ssh, ntp, ldap, smtp, ftp, http, pop, nntp, imap)

  • Разрешение DNS

  • Работоспособность TCP

  • Время ответа TCP

  • Файл

  • Размер/время файла

  • Существование файла

  • Контрольная сумма

  • MD5 хеш

  • Поиск по регулярному выражению

  • Журнал

  • Текстовый журнал

  • Другое

  • Время работы системы

  • Системное время

  • Подключенные пользователи

Мониторинг осуществляется методом просмотра лог-файлов следующих компонентов «Витрины данных НСУД» ( см. Рисунок - 3.23 )

  • Ядро витрины (Prostore);

  • Брокер сообщений (ADS);

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

  • ADCM;

  • REST-адаптер;

  • ETL;

  • CМЭВ3-адаптер (включает собственную сервисную БД);

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

  • ADB;

  • ADQM;

  • ADG.

Расположение и относительные пути к лог-файлам описаны в документе «Руководство системного программиста», раздел 7.2 «Логирование».

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

* Более подробное описание инструкций, типов, форматов и т. п. приведено в документе «Руководство программиста».