4. Настройка программы

4.1. Настройка на состав технических средств

4.1.1. Общие требования

Предъявляются следующие общие обязательные требования:

созданы все виртуальные машины согласно схеме развертывания;
операционная система на базе Linux (kernel 3.10 и yum/rpm). В данном документе описание на примере CentOS 7.8;
организован доступ к пользователю root/технологическому пользователю с правами sudo на серверах;
имена хостов (FQDN) серверов могут взаимно получать IP по имени со всех машин;
на всех серверах установлены пакеты:

«Python 2» (version 2.7);
«libselinux-python».

на всех серверах установлен сервис синхронизации времени;
хранилище «centos-extras» включено;
в случае работы с RHEL/CentOS 7.8 со всех машин в кластере обеспечен доступ к официальному репозиторию «CentOS Extras» (например, http://centos-mirror.rbc.ru/pub/centos/7/extras/x86_64/ или создано локальное зеркало);
в случае работы с RHEL/CentOS 7.8 со всех машин в кластере обеспечен доступ к официальному репозиторию «CentOS Updates» (например, http://centos-mirror.rbc.ru/pub/centos/7/updates/x86_64/ или создано локальное зеркало);
в случае работы с RHEL/CentOS 7.8 со всех машин в кластере обеспечен доступ к официальному репозиторию «CentOS Base» (например, http://centos-mirror.rbc.ru/pub/centos/7/os/x86_64/ или создано локальное зеркало).
смонтирован диск большого объема (выделенный под данные) на тех серверах, для которых требуется большой объем данных. По умолчанию диск монтируется в /opt.

4.1.2. Общие требования для развертывания ProStore

наличие одной или нескольких выделенных и обособленных одноранговых Interconnect-сетей под цели внутренней коммуникации кластера;
все сервера кластера должны быть подключены к Interconnect-сетям, для серверов должны быть назначены адреса, и должно быть настроено соединение между всеми серверами кластера;
скорость Ethernet от 1 Гб/с (стандартом является 10 Гб/с);
отсутствие firewalls и другого ПО, блокирующего или замедляющего трафик;
внутри кластера должна быть открыта коммуникация по всем портам;
доступность проверки целостности и качества соединений (Ping) для всех серверов (ICMP);
сервисы firewalld и SELinux не должны контролироваться системой управления конфигурации (при ее наличии), поскольку они должны быть доступны процессу установки ADS, ADB и ADQM для остановки и выключения;
создание новых сервисов не должно контролироваться системой управления конфигурации (при ее наличии), поскольку оно должно быть доступно процессу установки ADS, ADB и ADQM.

При установке с подключением к сети Интернет предъявляются дополнительные требования:

наличие доступа для серверов ADS и ADB к ПО ADCM, предварительно развернутому в сети организации на выделенном сервере;
наличие доступа для серверов ADB к следующим официальным репозиториям Arenadata или созданным локальным зеркалам:

ADB: https://downloads.arenadata.io/ADB/<ADB_version>/centos/7/community/$basearch;
Arenadata Monitoring: https://downloads.arenadata.io/ADM/<ADM_version>/centos/7/community/$basearch/.

наличие доступа для серверов кластера ADQM к следующим официальным репозиториям Arenadata или созданным локальным зеркалам:

наличие доступа для серверов кластера ADG к официальному репозиторию Arenadata ADG или созданному локальному зеркалу;
наличие доступа для сервера ProStore к официальному репозиторию Arenadata ProStore или созданному локальному зеркалу.

4.1.3. Требования к серверу ProStore

Необходимо не менее 20ГБ свободного пространства.

4.1.4. Требования к серверу «Менеджер кластера ADCM»

Требуется виртуальная или физическая машина с операционной системой на базе Linux (kernel 3.10 и yum/rpm). В данном документе описание на примере CentOS 7.8;

Необходимо не менее 5 ГБ свободного пространства в директории /home.

4.1.5. Требования к кластеру серверов «ADQM»

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

22 (ssh);
8123 (HTTP-интерфейс Clickhouse);
8000 (ADCM).

Clickhouse-cервера должны быть доступны по портам 9000, 8123, 9009 внутри кластера;
для отправки метрик на сервер мониторинга к нему должно быть разрешено подключение серверов кластера (по умолчанию 2015/tcp, 2016/udp);
для отправки статусов компонентов кластера в ADCM к нему должно быть разрешено подключение серверов кластера (по умолчанию порт 8000).

4.1.6. Требования к кластеру серверов «ADS»

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

/etc/hosts
/etc/selinux/config
/etc/sysctl.conf
файлы директории /usr/lib/systemd/system/;

в кластерe должны быть открыты порты, представленные в таблице ниже (см. Таблица 4.23).

Таблица 4.23 Перечень сетевых портов, используемых серверами ADS
Номер порта	Описание использования порта
22	SSH
81	(при установке ADS без подключения к сети Интернет) TCP-порт репозиториев Arenadata Enterprise Tools
2015	TCP-порт для отправки метрик на сервер мониторинга
2016	Udp-порт для отправки метрик на сервер мониторинга
8000	TCP-порт для отправки статусов компонентов кластера в ADCM
2181	Порт доступа к сервису ZooKeeper
2888	Порт межсерверного взаимодействия для компонентов кворума ZooKeeper
3888	Порт межсерверного взаимодествия для компонентов кворума ZooKeeper
9092	HTTP-порт доступа к сервису Kafka
9093	HTTPS-порт доступа к сервису Kafka
8081	Порт доступа к сервису Schema-Registry
8082	Порт доступа к сервису Kafka REST Proxy
8088	Порт доступа к компоненту KSQL Server
9898	Порт доступа к сервису Kafka-Manager
9997	JMX-порт для доступа к метрикам сервисa Schema-Registry
9998	JMX-порт для доступа к метрикам сервисa Kafka REST Proxy
9999	JMX-порт для доступа к метрикам сервиса Kafka

4.1.7. Требования к кластеру серверов «ADB»

Снаружи кластер должен быть доступен по следующим портам:
- 22 (ssh);
- 5432 (входящий интерфейс postgresql);
для доступа к серверам точного времени для мастер-серверов должен быть открыт доступ по порту 123/udp;
для отправки метрик на сервер мониторинга к нему должно быть разрешено подключение серверов кластера (по умолчанию 2015/tcp, 2016/udp);
для отправки статусов компонентов кластера в ADCM к нему должно быть разрешено подключение серверов кластера (по умолчанию порт 8000/tcp);
следующие файлы не должны контролироваться системой управления конфигурации (при ее наличии), поскольку они должны быть доступны процессу установки для создания и модификации:
- /etc/fstab;
- /etc/hosts;
- /etc/hostname;
- /etc/chrony.conf;
- /etc/ssh/sshd_config;
- /etc/selinux/config;
- /etc/security/limits.conf;
- файлы директории /usr/lib/systemd/system/;
- файлы директории /etc/cgconfig.d/.

4.1.8. Требования к кластеру серверов «ADG»

для отправки метрик на сервер мониторинга к нему должно быть разрешено подключение серверов кластера (по умолчанию 2015/tcp, 2016/udp);
снаружи кластер должен быть доступен по порту 22 (ssh);
наличие библиотеки glibc версии 2.17-260.el7_6.6 или выше.

4.1.9. Требования к серверу «СМЭВ3 коннектор»

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

/etc/hosts;
/etc/selinux/config;
/etc/sysctl.conf;
/usr/lib/systemd/system/;
/etc/sysconfig/iptables\*;
/etc/firewalld/\*;
/etc/docker/\*.

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

22 (ssh);

Необходим сетевой доступ до сервера СМЭВ. Например, если используется адрес http://smev3-n0.test.gosuslugi.ru:5000/transport_1_0_2/, необходимо организовать доступ
Если для шифрования и подписи сообщений используется КриптоПро JCP 2.0.41618.
Необходимо так же подготовить ключи (контейнер) для КриптоПро и лицензию на JCP. В случае отсутствия лицензии будет использоваться пробная лицензия.
Если для оформления цифровой подписи используется VipNet PKI необходимо обеспечить сетевой доступ до его сервера.

4.1.10. Требования к серверу «Агент ПОДД»

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

/etc/hosts;
/etc/selinux/config;
/etc/sysctl.conf;
/usr/lib/systemd/system/;
/etc/sysconfig/iptables\*;
/etc/firewalld/\*;
/etc/docker/\*.

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

22 (ssh);

Необходим сетевой доступ до сервера ПОДД. Например, если
используется адрес http://smev3-n0.test.gosuslugi.ru:5000/transport_1_0_2/, необходимо организовать доступ до хоста smev3-n0.test.gosuslugi.ru по порту 5000.

4.1.11. Требования к серверу «ETL»

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

/etc/hosts;
/etc/selinux/config;
/etc/sysctl.conf;
/usr/lib/systemd/system/;
/etc/sysconfig/iptables\*;
/etc/firewalld/\*;
/etc/docker/\*.

Должны быть открыты порты, представленные в таблице ниже (см. Таблица 4.24).

Таблица 4.24 Перечень сетевых портов, используемых серверами ETL
Номер порта	Описание использования порта
22	SSH
8080	TCP-порт, WEB - интерфейс для Apache Spark master
6066	TCP-порт, отправка задач в кластер через rest api для Apache Spark master
7077	TCP-порт, отправка задач в кластер регистрация исполнителей Apache Spark worker для spark master
8081	TCP-порт, WEB-интерфейс Apache Spark worker
8080	TCP-порт, WEB – интерфейс Apache Airflow
5555	TCP-порт, мониторинг задач Apache Airflow
5432	TCP-порт, Airflow Postgres для хранения метаданных
6379	TCP-порт, Redis для хранения очередей

4.1.12. Требования к серверу конечных точек

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

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

Снаружи сервер должен быть доступен по следующим портам:
- 22 (ssh)
- 8080

4.2. Настройка на состав программных средств

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

4.2.1. Создание технологического пользователя

Для корректной работы в процессе установки программного обеспечения необходимо:

Создать технологического пользователя с правами «sudo» на всех серверах.
Выдать технологическому пользователю на всех серверах право выполнять через «sudo» команды от имени пользователей root и gpadmin.
Выдать технологическому пользователю право без пароля использовать «sudo». Если такой возможности нет, необходимо создать одинаковый пароль. В этом случае при запуске ansible-playbook ``необходимо будет указать ключ ``-K и задавать пароль пользователя для использования sudo.
На сервере ADCM сгенерировать пару закрытого и открытого ключа для данного пользователя.
Разместить на остальных серверах открытый ключ

4.2.2. Установка Менеджера кластера ADCM

Сервер «Менеджер Кластера» – сервер, с которого будет централизованно производиться установка почти всех компонентов витрины. Данный компонент обязателен для установки.

ADCM – программное обеспечение, распространяемое в виде образа докеров. У вас должен быть Докер или совместимый движок контейнеров, чтобы запустить ADCM. Текущая версия программного обеспечения не совместима с SELinux.

Подробная инструкция по установке Менеджера кластера ADCM приведена в документации к ПО Менеджера кластера ADCM (https://docs.arenadata.io/adcm/user/install.html ). Список основных объектов ADCM приведен в приложении 1. Таблица 8 – Основные объекты ADCM

Установка ПО ADCM осуществляется технологическим пользователем согласно следующим этапам:

Выключить selinux. В файле /etc/selinux/config установить значение SELINUX=disabled, перезапустить сервер командой reboot now

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

yum-config-manager --add-repo
https://download.docker.com/linux/centos/docker-ce.repo
yum install -y containerd.io
yum install -y docker-ce-3:18.09.1-3.el7
systemctl enable docker
systemctl start docker

Установить ПО ADCM в докере командами:

docker pull arenadata/adcm:latest

docker create --name adcm -p 8000:8000 -v /opt/adcm:/adcm/data
arenadata/adcm:latest

Запустить ADCM командой:
```
docker start adcm
```
Открыть браузер и перейти по адресу http: // <ip_of_your_server>: Пользователь по умолчанию - admin, пароль - admin.

4.2.3. Установка ADQM

Подробная инструкция по установке СУБД ADQM приведена в документации к СУБД ADQM и СУБД ClickHouse (https://docs.arenadata.io/adqm/install/adcm/ru/index.html , https://clickhouse.tech/docs/ru/getting-started/install/ ).

Создать не менее трёх виртуальных машин для кластера ClickHouse (используйте гипервизор (монитор виртуальных машин)).
Установить ClickHouse на каждом узле кластера под профилем пользователя root с помощью команд:

rpm --import https://repo.clickhouse.tech/CLICKHOUSE-KEY.GPG
yum-config-manager --add-repo https://repo.clickhouse.tech/rpm/stable/x86_64
yum install -y clickhouse-server-20.4.4.18-2 clickhouse-client-20.4.4.18-2

Запустить сервер следующей командой:
```
systemctl start clickhouse-server
```
Выполнить настройку среды

В конфигурационный файл каждого сервера ClickHouse, размещенным по относительному пути /etc/clickhouse-server/config.xml, внести описание конфигурации кластера ClickHouse и Zookeeper в следующем формате (на примере конфигурации ClickHouse из одного шарда и двух реплик):

<remote_servers incl="clickhouse_remote_servers" >
         <cluster>
           <shard>
               <replica>
                   <host>bdv-adqm-1.ru-central1.internal</host>
                   <port>9000</port>
               </replica>
           </shard>
           <shard>
               <replica>
                   <host>bdv-adqm-2.ru-central1.internal</host>
                   <port>9000</port>
               </replica>
           </shard>
       </cluster>
   </remote_servers>

Пример конфигурации ClickHouse из двух шардов и двух реплик:

<remote_servers incl="clickhouse_remote_servers" >
    <!-- Test only shard config for testing distributed storage -->
    <cluster>
        <shard>
            <replica>
                <host>bdv-adqm-1.ru-central1.internal</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>bdv-adqm-2.ru-central1.internal</host>
                <port>9000</port>
            </replica>
        </shard>
        <shard>
            <replica>
                <host>bdv-adqm-3.ru-central1.internal</host>
                <port>9000</port>
            </replica>
            <replica>
                <host>bdv-adqm-4.ru-central1.internal</host>
                <port>9000</port>
            </replica>
        </shard>
      </cluster>
    </remote_servers>

Пример указания кластера Zookeeper из трёх нод:

<zookeeper>
    <node index="1">
        <host>bdv-zookeeper-1.ru-central1.internal</host>
        <port>2181</port>
    </node>
    <node index="2">
        <host>bdv-zookeeper-2.ru-central1.internal</host>
        <port>2181</port>
    </node>
    <node index="3">
        <host>bdv-zookeeper-3.ru-central1.internal</host>
        <port>2181</port>
    </node>
    <session_timeout_ms>30000</session_timeout_ms>
</zookeeper>

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

Например, доступ с любого адреса (IPv4, IPv6):

<yandex>
   <listen_host>::</listen_host>
</yandex>

Перезапуск СУБД командой:
```
systemctl restart clickhouse-server
```

Проверить успешность завершения установки СУБД ADQM:

Проверить логи СУБД ADQM по относительному пути:

/var/log/clickhouse-server/
Проверить удалённое подключение с помощью http-запроса:
```
curl 'http://10.92.3.13:8123/ping'
```
Проверить работу СУБД ADQM работает в кластерном режиме, путём запуска клиента командной строки ClickHouse, создания тестовой таблицы SQL-запросом через клиента:
```
$ clickhouse-client
CREATE DATABASE test1 ON CLUSTER <имя_кластера>
```

Результатом выполнение команды будет сообщения об успешном выполнении запроса Настройка ПО ADQM ~~~~~~~~~~~~~~~~~

Инструкция по настройке СУБД ADQM приведена в официальной документации к СУБД ADQM и СУБД Clickhouse (https://docs.arenadata.io/adqm/expand/adcm/ru/index.html , https://clickhouse.tech/docs/ru/operations/configuration-files/ ).

4.2.4. Установка Диспетчера сообщений ADS

ПО Диспетчера сообщений ADS разворачивается на кластере с помощью ADCM из загруженного установочного пакета (бандла).

Скачать установочный пакет (версия: ads_v1.6.0.0-1) можно с сайта разработчика: https://store.arenadata.io/#products/arenadata_streaming.

Подробная инструкция по установке Диспетчера сообщений приведена в официальной документации к ПО Диспетчера сообщений (https://docs.arenadata.io/DTM/Install/ADS.html , https://docs.arenadata.io/ads/Install/index.html ). В данной инструкции описывается установка кластера Kafka и импорт уже установленного кластера Zookeeper. Установка ПО Zookeeper на кластер приведена в инструкции по установке ADQM.

Для создания кластера необходимо иметь предварительно загруженный бандл (версия: ads_v1.6.0.0-1). В графическом интерфейсе ADCM осуществить переход в раздел CLUSTERS -> Create cluster.
В разделе Services графического интерфейса ADCM необходимо добавить сервисы в созданный кластер.
В случае, если Kafka и Zookeeper разворачивается в одном кластере, необходимо добавить сервис Zookeeper.
В разделе Hosts графического интерфейса ADCM указать серверы созданного кластера, на которых будет развёрнуто ПО ADS.
В разделе Hosts - Components указать три узла (ноды) Kafka.
Указать кластер Zookeeper в разделе Import, в случае если Zookeeper находится на другом кластере.
Нажатием программной кнопки InstalL инициировать процесс установки. В новом окне с дополнительными параметрами – нажатием программной кнопки Run запустить установку.
Проверить успешность завершения установки:

Проверить лог-файл Zookeeper по относительному пути:
```
/var/log/zookeeper/.
```
Проверить лог-файл Kafka по относительному пути:

/var/log/kafka/.
Проверить настройки подключения к кластеру Zookeeper с помощью сторонней утилиты KafkaTool.
Проверить корректность разрешения имен серверов для автоматического определения bootstrap-серверов Kafka. При отсутствии DNS-севера прописать в локальный hosts адреса Kafka.
Определить путь chroot path, запустив на любом сервере Zookeeper команду:
```
/usr/lib/zookeeper/bin/zkCli.sh
```

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

ls     /arenadata/cluster.

При проверке, в данном руководстве, использовался графический интерфейс приложения Offset Explorer 2.1 (https://www.kafkatool.com/download.html).

4.2.5. Настройка Диспетчера сообщений ADS

Инструкция по настройке Диспетчера сообщений ADS через Менеджер кластера ADCM приведена в официальной документации к ПО Менеджера кластера ADCM (https://docs.arenadata.io/ads/AdminGuide/Config_ADCM.html ).

4.2.6. Установка ПО ADB

Подробная инструкция по установке СУБД ADB приведена в документации к СУБД ADB (https://docs.arenadata.io/DTM/Install/ADB.html).

Для установки кластера ADB посредством ADCM необходимо выполнить следующие шаги:

Установить ADCM (см. п.3.2.3);
Создать хосты для кластера ADB:
Загрузить выбранный бандл хоста (версия: ADB 6.15, ссылка для скачивания https://store.arenadata.io/#products/arenadata_db ).
Открыть в графическом интерфейсе ADCM раздел “BUNDLES”. Нажать программную кнопку “Upload bundle” и в открывшейся экранной форме выбрать файл бандла ADB. Проверить отображение факта успешной загрузки в общем списке бандлов на вкладке “BUNDLES”.

Для установки понадобится один или более хост для размещения мастера, резервного мастера и сегментов.

В графическом интерфейсе ADCM перейти в раздел CLUSTERS -> Create cluster. Создать кластер.
Добавить сервисы ADB и PXF на созданный кластер.

Примечание

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

В диалоговом окне Add service указать сервис PXF (данный сервис доступен только в версии «Arenadata Enterprise») как подлежащий к установке;
В диалоговом окне Add service не указывать сервис ADB to Kafka (данный сервис доступен только в версии «Arenadata Enterprise») как подлежащий установке.

В разделе Hosts указать серверы, на которых будет развёрнут кластер ADB.
В разделе Hosts - Components указать назначение узлов: master ставится на один узел, segment на два других узла,
PXF - на все узлы.
При необходимости указать количество зеркал и сегментов на узлах в разделе конфигурации сервиса ADB. По умолчанию, количество сегментов на хост = (CPU cores)/2.
Через графический интерфейс ADCM в разделе Configuration установить флажок Set up EPEL repo, необходимый для установки kafka fwd.
Выполнить предварительную проверку кластерной конфигурации и необходимых условий путём нажатия программной кнопки Precheck.
Осуществить отслеживание статуса проверки в разделе JOBS.
В случае успешности проверки выполнить установку ADB путём нажатия программной кнопки Install. После установки осуществить перезагрузку серверов.
Выполнить актуализацию установленного PXF-сервиса для кластера ADB:

собрать из репозитория http://github.com/arenadata/kafka-pxf-connector актуальную версию PXF-сервиса (см. документацию по коннектору GreenPlum: https://gpdb.docs.pivotal.io/6-8/pxf/sdk/build_conn.html#demo_buildjar);
при необходимости развернуть актуальную версию PXF-сервиса (см. документацию по коннектору GreenPlum: https://gpdb.docs.pivotal.io/6-8/pxf/sdk/deploy_conn.html)
На каждом хосте сегмента с PXF-сервисом заменить соответствующий этому сервису jar-file на актуальную версию, собранную из репозитория

cp <project>/pxf-kafka/env/pxf-profiles.xml $PXF_CONF/conf/
cp <project>/pxf-kafka/build/libs/pxf-kafka-*.jar $PXF_CONF/lib/
cp <project>/pxf-kafka/build/libs/kafka-clients-*.jar $PXF_CONF/lib/
cp <project>/pxf-kafka/build/libs/avro-1.9.2.jar $PXF_CONF/lib/shared
pxf cluster sync

посредством SQL-консоли кластера ADB выполнить проверочные запросы

CREATE WRITABLE EXTERNAL TABLE kafka_tbl (a TEXT, b TEXT, c TEXT)
LOCATION ('pxf://<topic>?PROFILE=kafka&BOOTSTRAP_SERVERS=<server>')
FORMAT 'CUSTOM' (FORMATTER='pxfwritable_export');
insert into kafka_tbl values ('a', 'b,c', 'd'), ('x', 'y', 'z');
drop external table kafka_tbl;

При отсутствии автоматического встраивания и настройки PXF в кластер ADB через Менеджер кластера ADCM осуществить запуск и настройку PXF в кластере ADB, управляемом ADCM.

В графическом интерфейсе ADCM в разделе CLUSTERS выбрать требуемый кластер ADB.
В графическом интерфейсе ADCM для выбранного кластера перебрать все хосты и в разделе Actions выбрать Install rng-tools (для устранения ошибки ADBDEV-306: PXF fail with timeout on start).
В графическом интерфейсе ADCM для выбранного кластера в разделе Services добавить PXF, в разделе Hosts - Components добавить PXF на каждый хост.
Выполнить проверку того, что PXF установился в /usr/lib/pxf под отдельным пользователем pxf.
Выполнить следующие операции на каждом хосте в силу ограничений работы команд cluster в таком окружении.
Выполнить:

sudo su - pxf
mkdir /var/lib/pxf/servers/<name>
vi /var/lib/pxf/servers/<name>/jdbc-site.xml
PXF_HOME=/usr/lib/pxf /usr/lib/pxf/bin/pxf restart

Сконфигурировать jdbc-site.xml:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <property>
        <name>jdbc.driver</name>
        <value>org.postgresql.Driver</value>
    </property>
    <property>
        <name>jdbc.url</name>
        <value>jdbc:postgresql://10.92.3.31:5432/postgres</value>
    </property>
    <property>
        <name>jdbc.user</name>
        <value>postgres</value>
    </property>
    <property>
        <name>jdbc.password</name>
        <value>postgres</value>
    </property>
</configuration>

Выполнить запрос в SQL-консоли ADB:

CREATE WRITABLE EXTERNAL TABLE sample ( id int, name varchar )

LOCATION ('pxf://sample?PROFILE=Jdbc&SERVER=<name>')

FORMAT 'CUSTOM' (FORMATTER='pxfwritable_export');

insert into sample values (100,'qwe');

Проверить наличие ошибок, записанных лог-файл в /var/lib/pxf/logs/.

Выполнить установку kafka-fwd после успешной установки кластера ADB. Зайти на каждый узел кластера по протоколу ssh и через профиль пользователя root выполнить пакет команд

yum install -y wget epel-release libcsv-devel
wget https://ci.arenadata.io/artifactory/ADB/6.13.0_arenadata13/centos/7/enterprise/x86_64/kafka-fdw-0.10-377.git3fe5e36.el7.x86_64.rpm
yum install -y kafka-fdw-0.10-377.git3fe5e36.el7.x86_64.rpm
cd /usr/lib/gpdb/lib/postgresql
sudo chown gpadmin:gpadmin kadb_fdw.so

Выполнить настройку удалённого доступа для возможности подключения к СУБД извне. Прописать правила доступа в файле pg_hba.conf. Формат доступа подробно описан в документации по postgresql. Добавить правило доступа через графический интерфейс ADCM в конфигурации кластера ADB. Проверить на мастер-узле файл /data1/master/gpseg-1/pg_hba.conf на наличие запрещающих правил выше добавленного правила доступа. При наличии запрещающих правил удалить их. Добавляемые правила доступа имеют вид:

host all all 10.92.3.33/32 md5 # доступ для всех пользователей на все БД из указанной подсети
host all test 0.0.0.0/0 md5 # доступ ко всем БД из любой подсети пользователю test

Выполнить настройку среды путём создания вручную или при добавлении сервиса ADB до его инициализации.

Для создания базы вручную после установки кластера: подключиться к мастер-узлу по ssh; подключиться в качестве пользователя pgadmin su - gpadmin; подключиться к СУБД командой:

psql adb

Выполнить в СУБД SQL-запрос:

CREATE DATABASE <имя среды>.

Подключить коннектор kafka-greenplum следующими инструкциями:

CREATE EXTENSION IF NOT EXISTS kadb_fdw

для подключения kafka-greenplum connector writer

CREATE EXTENSION IF NOT EXISTS pxf

для подключения kafka-greenplum connector reader

Создать профиль пользователя через графический интерфейс ADCM в разделе сервиса ADB - Create role с установкой флажка Make role superuser, или создать профиль вручную через подключение к СУБД psql <имя среды> и выполнения SQL-запроса:

ALTER USER <имя пользователя> WITH SUPERUSER.

Выполнить следующие проверки:

проверку статуса сегментов с помощью SQL-запроса

select \* from gp_segment_configuration

проверку установленной версии с помощью команд:

postgres --gp-version
postgres -V

проверку прав пользователя на создание схемы:

Create schema IF NOT EXISTS test; Drop schema test;

4.2.7. Настройка ПО ADB

Инструкция по настройке СУБД ADB приведена в официальной документации к СУБД ADB (https://docs.arenadata.io/adb/adminguide/managetools.html).

4.2.8. Установка ПО ADG

Установку ПО ADG рекомендуется производить на хост или виртуальную машину (или на группу - кластер) под управлением ОС Linux, дистрибутив CentOS 7, Red Hat Enterprise Linux 7 или производных. Пользователь, выполняющий установку, должен находиться в группе sudo.

Подготовка управляющего хоста

Для установки ADG необходимо подготовить управляющий хост или виртуальную машину, с которой будет осуществляться установка ПО ADG на целевой кластер. Для этого на управляющий хост необходимо установить ПО удалённого управления (Ansible) из репозитория RPM-пакетов Extra Packages for Enterprise Linux (далее - EPEL). Допускается установка данного ПО непосредственно на целевой хост:

sudo yum -y install epel-release

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

*Installed:*
*epel-release.noarch 0:7-11*
*Complete!*

Далее, необходимо обновить список пакетов из репозитория EPEL и установить ПО удалённого управления:

sudo yum update
sudo yum install -y ansible

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

.. code-block:: bash

rpm -qa ansible»

Примечание

Версия пакета может отличаться.

rpm -qa ansible
ansible-2.9.23-1.el7.noarch

Для ПО удалённого управления необходимо установить роль tarantool.cartridge (дополнительный программный модуль). Необходим доступ к сайту github.com. Приведен полный вывод успешного процесса установки:

ansible-galaxy install tarantool.cartridge
downloading role 'cartridge', owned by tarantool
downloading role from https://github.com/tarantool/ansible-cartridge/archive/1.10.0.tar.gz
extracting tarantool.cartridge to /home/vagrant/.ansible/roles/tarantool.cartridge*
tarantool.cartridge (1.10.0) was installed successfully

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

ansible-galaxy role list

в выводе должна быть строка с ролью tarantool.cartridge:

ansible-galaxy role list
tarantool.cartridge, 1.10.0

Установка зависимостей ПО ADG

Для корректной работы ПО AGD на целевой хост необходимо установить дополнительные зависимости доступные в официальном репозитории CentOS 7:

sudo yum install -y snappy zip unzip

Также необходимо установить дополнительные зависимости из RPM-пакетов. Перед выполнением команд установки данные файлы необходимо предварительно скопировать на целевой хост (ссылки для скачивания указаны в Таблица 2 - Состав типового ПО ведомственной витрины данных НСУД):

sudo rpm -i rpm/avroc-1.10.0-1.el7.x86_64.rpm
sudo rpm -i rpm/libzstd-1.4.5-3.el7.x86_64.rpm
sudo rpm -i rpm/librdkafka-1.5.0-1.el7.x86_64.rpm

Для проверки выполнить следующую команду:

rpm -qa snappy zip unzip avroc libzstd librdkafka

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

Примечание

Версии пакетов могут отличаться.

rpm -qa snappy zip unzip avroc libzstd librdkafka
zip-3.0-11.el7.x86_64
libzstd-1.4.5-3.el7.x86_64
snappy-1.1.0-3.el7.x86_64
avroc-1.10.0-1.el7.x86_64
librdkafka-1.5.0-1.el7.x86_64
unzip-6.0-22.el7_9.x86_64

Далее, устанавливается основная зависимость - платформа in-memory вычислений Tarantool:

curl -L https://tarantool.io/yDNXllJ/release/2.6/installer.sh \| bash
sudo yum install -y tarantool

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

rpm -qa tarantool
rpm -qa tarantool
tarantool-2.6.3.0-1.el7.x86_64

4.2.9. Установка ПО ADG

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

Пример файла adg.yml смотри в Приложении 1.

В файле adg.yml перед запуском роли необходимо изменить ряд параметров:

IP-адрес 192.168.99.9 на адрес целевого хоста.
Параметры доступа ansible_user, ansible_password могут быть заполнены на валидные или убраны, при указании корректного ключа в параметре ansible_ssh_private_key_file.
Параметр cartridge_cluster_cookie следует заменить на свой. Он служит меткой для определения «своих» экземпляров кластера ADG, если в одном контуре будет установлено более 1 кластера.
В файл config.yml (пример файла config.yml смотри в Приложении 1) необходимо изменить kafka_server_ip на реальный IP до kafka сервера. Если серверов несколько, можно указать через запятую.
После внесения настроек в adg.yml установка производится командой:

ansible-playbook -i adg.yml cartridge.yml

из папки в, которой расположен файл adg.yml, например, если файл расположен в папке inventory, команда будет выглядеть следующим образом:

cd inventory
ansible-playbook -i adg.yml cartridge.yml

Пример файла cartridge.yml (см. Приложение 1.)

В конце работы команды ansible-playbook выводится итоговая таблица. В столбце со счетчиками ошибок их количество должно быть равно нулю:

failed=0 у всех экземпляров ADG.
*PLAY RECAP
\**********************************************************\**
*api-1 : ok=57 changed=9 unreachable=0 failed=0 skipped=30 rescued=0
ignored=0*
*c-1 : ok=26 changed=3 unreachable=0 failed=0 skipped=17 rescued=0
ignored=0*
*ip-1 : ok=26 changed=3 unreachable=0 failed=0 skipped=17 rescued=0
ignored=0*
*out-task-1 : ok=26 changed=3 unreachable=0 failed=0 skipped=17
rescued=0 ignored=0*
*sch-1 : ok=26 changed=3 unreachable=0 failed=0 skipped=17 rescued=0
ignored=0*
*state-1 : ok=26 changed=3 unreachable=0 failed=0 skipped=17 rescued=0
ignored=0*
*storage-1 : ok=26 changed=3 unreachable=0 failed=0 skipped=17 rescued=0
ignored=0*

Настройка конфигурации для доступа к kafka

Откройте в Web-браузере адрес целевого хоста, с указанием HTTP-порта. Например: http://192.168.99.9:8181/.

Выбрать раздел Configuration files и загрузить файл конфигурации config.yml с корректно указанным в нем адресом Kafka-сервера. Нажать кнопку Save и получить корректный ответ о загрузке конфигурации.

Перейдите на вкладку Code убедитесь, что конфигурация загрузилась .

Далее необходимо провести перезапуск сервисов для принятия настроек конфигурации. Для этого выполните в ssh-консоли следующую команду:

sudo systemctl restart memstorage@\*

Откройте в Web-браузере адрес целевого хоста, с указанием HTTP-порта. Например: http://192.168.99.9:8181/ и перейдите в раздел Cluster.

На кнопке Issues количество ошибок должно быть равно нулю, как в примере: «Issues: 0». В случае отсутствия ошибок нужно нажать красную кнопку Bootstrap vshard. Это действие выполняется однократно после успешной установки.

Проверка-2: выполнить команду:

systemctl status memstorage@*

Ниже приведен полный вывод работы этой команды:

systemctl status memstorage@\

memstorage@state-1.service - Tarantool Cartridge app

memstorage@state-1
Loaded: loaded (/etc/systemd/system/memstorage@.service; enabled;
vendor preset: disabled)
Active: active (running) since Пн 2021-07-19 16:20:18 UTC; 28min ago
Main PID: 18638 (tarantool)
CGroup:
/system.slice/system-memstorage.slice/memstorage@state-1.service
└─18638 tarantool init.lua <running>: memstorage@state-1

memstorage@c-1.service - Tarantool Cartridge app memstorage@c-1
Loaded: loaded (/etc/systemd/system/memstorage@.service; enabled;
vendor preset: disabled)*
Active: active (running) since Пн 2021-07-19 16:20:18 UTC; 28min ago

Main PID: 18665 (tarantool)

CGroup: /system.slice/system-memstorage.slice/memstorage@c-1.service

└─18665 tarantool init.lua <running>: memstorage@c-1

memstorage@sch-1.service - Tarantool Cartridge app memstorage@sch-1

Loaded: loaded (/etc/systemd/system/memstorage@.service; enabled;
vendor preset: disabled)

Active: active (running) since Пн 2021-07-19 16:20:18 UTC; 28min ago

Main PID: 18635 (tarantool)

CGroup: /system.slice/system-memstorage.slice/memstorage@sch-1.service

└─18635 tarantool init.lua <running>: memstorage@sch-1

memstorage@ip-1.service - Tarantool Cartridge app memstorage@ip-1

Loaded: loaded (/etc/systemd/system/memstorage@.service; enabled;
vendor preset: disabled)

Active: active (running) since Пн 2021-07-19 16:20:18 UTC; 28min ago

Main PID: 18649 (tarantool)

CGroup: /system.slice/system-memstorage.slice/memstorage@ip-1.service

└─18649 tarantool init.lua <running>: memstorage@ip-1

memstorage@out-task-1.service - Tarantool Cartridge app

memstorage@out-task-1

Loaded: loaded (/etc/systemd/system/memstorage@.service; enabled;
vendor preset: disabled)
Active: active (running) since Пн 2021-07-19 16:20:18 UTC; 28min ago

Process: 18920 ExecStartPre=/bin/sh -c mkdir -p
/var/lib/tarantool/memstorage.%i (code=exited, status=0/SUCCESS)

Main PID: 18923 (tarantool)

CGroup:
/system.slice/system-memstorage.slice/memstorage@out-task-1.service

└─18923 tarantool init.lua <running>: memstorage@out-task-1

memstorage@api-1.service - Tarantool Cartridge app memstorage@api-1

Loaded: loaded (/etc/systemd/system/memstorage@.service; enabled;
vendor preset: disabled)

Active: active (running) since Пн 2021-07-19 16:20:18 UTC; 28min ago

Main PID: 18547 (tarantool)

*CGroup: /system.slice/system-memstorage.slice/memstorage@api-1.service*

└─18547 tarantool init.lua <running>: memstorage@api-1

memstorage@storage-1.service - Tarantool Cartridge app
memstorage@storage-1

Loaded: loaded (/etc/systemd/system/memstorage@.service; enabled;
vendor preset: disabled)

Active: active (running) since Пн 2021-07-19 16:20:18 UTC; 28min ago

Main PID: 18880 (tarantool)

CGroup:
/system.slice/system-memstorage.slice/memstorage@storage-1.service

└─18880 tarantool init.lua <running>: memstorage@storage-1

4.2.10. Настройка ПО ADG

Инструкция по настройке СУБД ADG приведена в официальной документации к СУБД ADG и СУБД Tarantool (https://docs.arenadata.io/adg/install_adcm/ru/source/manage_tools/index.html).

4.2.11. Установка ПО ProStore

Установка ядра витрины как ПО ProStore осуществляется после установки Менеджера кластера ADCM, СУБД ADQM, ADS , СУБД ADG, СУБД ADB

Установка ПО ProStore из репозитория

Для установки ПО ProStore необходимо:

Клонировать репозиторий с исходным кодом проекта ProStore из репозитория: https://g.info.gov.ru/datamart/nsud-datamarts/-/blob/master/%D0%94%D0%B8%D1%81%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82%D0%B8%D0%B2%D1%8B%20%D0%9F%D0%9E%20%D0%92%D0%B8%D1%82%D1%80%D0%B8%D0%BD%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85%20%D0%9D%D0%A1%D0%A3%D0%94/%

Примечание

Актуальная версия на момент написания данного руководства 3.4.0

Собрать проект ProStore с помощью Maven (команда mvn package);
Создать на сервере ProStore папки: /opt/query-execution и /opt/status-monitor.
В файлах сборки adtm-3.4.0-master@c3279ff89d8 перейти в папку dtm-query-execution-core.
Скопировать файл из сборки target/dtm-query-execution-core-3.4.0.jar и загрузить в папку /opt/query-execution на сервере.
Скопировать файл из сборки config/application-default.yml и загрузить в как /opt/query-execution/application.yml на сервере.
Перейти в папку dtm-status-monitor.
Скопировать файлы из сборки target/dtm-status-monitor-4.1.0.jar и dtm-status-monitor/src/main/resources/application.yml в папку /opt/status-monitor на сервере.
Создать файлы /opt/query-execution/logback.xml и /opt/status-monitor/logback.xml. Содержимое файлов:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appender name="FILE"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>application.log</file>
<rollingPolicy
class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- daily rollover -->
<fileNamePattern>application.%d{yyyy-MM-dd}.log</fileNamePattern>
<!-- keep 30 days' worth of history capped at 3GB total size -->
<maxHistory>30</maxHistory>
<totalSizeCap>3GB</totalSizeCap>
</rollingPolicy>
<encoder>
<pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{35} -
%msg%n</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="FILE"/>
</root>
</configuration>

Создать файл /etc/systemd/system/query-execution.service со следующим содержимым:

[Unit]
Description="Core service"
After=syslog.target
[Service]
Type=simple
WorkingDirectory=/opt/query-execution
User=root
Group=root
ExecStart=/usr/bin/java \\
-Dlogback.configurationFile=/opt/query-execution/logback.xml \\
-jar dtm-query-execution-core-3.4.0.jar \\
--logging.config=/opt/query-execution/logback.xml

Создать файл /etc/systemd/system/status-monitor.service со следующим содержимым:

[Unit]
Description="Status monitor service"
After=syslog.target
[Service]
Type=simple
WorkingDirectory=/opt/status-monitor
User=root
Group=root
ExecStart=/usr/bin/java \\
-Dlogback.configurationFile=/opt/status-monitor/logback.xml \\
-jar dtm-status-monitor-4.1.0.jar \\
--logging.config=/opt/status-monitor/logback.xml

Включить автозапуск сервисов:

sudo systemctl enable query-execution status-monitor

Получить драйвер в папке dtm-jdbc-driver;
Настроить подключения к JDBC-клиентам типа DataGrip и DBeaver (см. «Руководство оператора» раздел 3.1.1 и 3.1.1.3);
Клонировать репозиторий https://github.com/arenadata/kafka-clickhouse-connector/tree/release-3.4.0
Перейти в директорию kafka-clickhouse-reader
Собрать при помощи команды:

mvn clean package

Перейти в директорию kafka-clickhouse-writer
Собрать при помощи команды:

mvn clean package

Создать на сервере ProStor папки: /opt/kafka-clickhouse-writer и /opt/kafka-clickhouse-reader
Скопировать файлы из сборки kafka-clickhouse-reader/src/main/resources/application.yml и kafka-clickhouse-reader/target/kafka-clickhouse-reader-3.4.0.jar в /opt/kafka-clickhouse-reader
Скопировать файлы из сборки kafka-clickhouse-writer/src/main/resources/application.yml и kafka-clickhouse-writer/target/kafka-clickhouse-writer-3.4.0.jar в /opt/kafka-clickhouse-writer
Создать файл /etc/systemd/system/kafka-clickhouse-reader.service со следующим содержимым:

[Unit]
Description="kafka-clickhouse-reader"
After=syslog.target
[Service]
Type=simple
WorkingDirectory=/opt/kafka-clickhouse-reader
User=root
Group=root
ExecStart=/usr/bin/java \\
-Dspring.config.location=classpath:application.yml \\
-jar kafka-clickhouse-reader-3.4.0.jar

Создать файл /etc/systemd/system/kafka-clickhouse-writer.service со следующим содержимым:

[Unit]
Description="kafka-clickhouse-writer"
After=syslog.target
[Service]
Type=simple
WorkingDirectory=/opt/kafka-clickhouse-writer
User=root
Group=root
ExecStart=/usr/bin/java \\
-Dspring.config.location=classpath:application.yml \\
-jar kafka-clickhouse-writer-3.4.0.jar

Настроить ProStore (см. раздел 3.2.11)
Запустить ProStore (см. раздел 4.5.1)
Проверить корректность функционирования ProStore путём подачи произвольного SQL- запроса к ProStore и сопоставления ожидаемого эталонного и полученного результатов.
Пример тестового запроса

SELECT 1;

Ответ: 1.

4.2.12. Настройка ПО ProStore

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

Настройка Сервиса исполнения запросов (query-execution)

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

Настройки журналирования сервиса исполнения запросов

io.arenadata.dtm.query.execution- задание уровня важности сообщений, журналируемых в лог-файл; По умолчанию установлен в TRACE;
DTM_METRICS_PORT- номер порта, используемого Сервисом исполнения запросов для отправки и получения метрик;
DTM_METRICS_ENABLED- настройка генерации метрик со стороны ProStore;
DTM_METRICS_SCOPE- состав метрик, видимых через веб-соединения

Настройка ProStore:

CORE_PLUGINS_ACTIVE- перечень используемых плагинов для доступа к СУБД ADB, ADG, ADQM
DTM_CORE_PLUGINS_RELATIONAL - настройка профилей приоритетности СУБД для общих реляционных запросов
DTM_CORE_PLUGINS_ANALYTICAL - настройка профилей приоритетности СУБД для запросов аналитики
DTM_CORE_PLUGINS_DICTIONARY - настройка профилей приоритетности СУБД для запросов ключ-значение
DTM_CORE_PLUGINS_UNDEFINED - настройка профилей приоритетности СУБД для не указанной категории запросов
DTM_CORE_HTTP_PORT - номер порта, на который Сервис исполнения запросов ожидает входящие запросы от JDBC-драйвера;
DTM_NAME - имя среды для формирования полного наименования датамартов;
CORE_TIME_ZONE - настройки временной зоны;
DTM_CORE_METRICS_ENABLED - настройки генерации метрики Сервиса исполнения запросов;
DTM_CORE_TASK_POOL_SIZE - максимальный объем пула задач в cервисе исполнения запросов;
DTM_CORE_TASK_TIMEOUT - интервал времени завершения задачи, выполняемой в Сервисе исполнения запросов;

Оптимизация работы сокета TCP_NODELAY:

DTM_CORE_HTTP_TCP_NODELAY - настройка режима оптимизации работы сокета TCP_NODELAY;
DTM_CORE_HTTP_TCP_FAST_OPEN - настройка режима TCP FAST_OPEN;
DTM_CORE_HTTP_TCP_QUICK_ACK - настройка режима оптимизации работы сокета TCP_QUICKACK;

Настройки для EDML операторов:

EDML_DATASOURCE - тип СУБД-источника (ADB, ADQM, ADG);
EDML_DEFAULT_CHUNK_SIZE – размер chunk по умолчанию;
EDML_STATUS_CHECK_PERIOD_MS - период проверки статуса плагина в миллисекундах;
EDML_FIRST_OFFSET_TIMEOUT_MS - интервал времени ожидания до таймаута в миллисекундах при работе с первым смещением;
EDML_CHANGE_OFFSET_TIMEOUT_MS - интервал времени ожидания до таймаута в миллисекундах при работе с первым смещением в топике Kafka;

Настройка Zookeeper-серверов:

ZOOKEEPER_DS_ADDRESS - сетевой адрес хоста Zookeeper для служебной БД;
ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS - интервал времени ожидания (в миллисекундах) соединения с хостом Zookeeper для служебной БД до достижения таймаута;
ZOOKEEPER_DS_SESSION_TIMEOUT_MS – интервал времени бездействия (в миллисекундах) соединения с хостом Zookeeper для служебной БД до достижения таймаута;
ZOOKEEPER_DS_CHROOT - корневой путь к хосту Zookeeper для служебной БД;
ZOOKEEPER_KAFKA_ADDRESS - сетевой адрес хоста Zookeeper для брокера сообщений Kafka;
ZOOKEEPER_KAFKA_CONNECTION_TIMEOUT_MS - интервал времени ожидания (в миллисекундах) соединения с хостом Zookeeper для брокера сообщений Kafka до достижения таймаута;
ZOOKEEPER_KAFKA_SESSION_TIMEOUT_MS - интервал времени бездействия (в миллисекундах) соединения с хостом Zookeeper для брокера сообщений Kafka до достижения таймаута;
ZOOKEEPER_KAFKA_CHROOT - корневой путь к хосту Zookeeper для брокера сообщений Kafka;

Настройка Kafka-серверов:

KAFKA_INPUT_STREAM_TIMEOUT_MS – интервал времени ожидания (в миллисекундах) входного потока данных для брокера сообщений Kafka до достижения таймаута;
KAFKA_STATUS_EVENT_ENABLED - разрешение на публикацию событий;
KAFKA_STATUS_EVENT_TOPIC - наименование топика Kafka, в который публикуются события;
STATUS_MONITOR_URL - сетевой адрес, порт и путь к Сервису мониторинга статусов Kafka;

Настройки кэширования запросов:

CACHE_INITIAL_CAPACITY - начальная емкость кэша;
CACHE_MAXIMUM_SIZE - максимальный размер кэша;
CACHE_EXPIRE_AFTER_ACCESS_MINUTES - время (в минутах) устаревания кэша после последнего момента доступа к нему;

Настройки для плагина ADB:

ADB_USERNAME - имя пользователя/логин для авторизации в СУБД ADB;
ADB_PASS - пароль для авторизации в СУБД ADB;
ADB_HOST - сетевой адрес хоста со СУБД ADB;
ADB_PORT - сетевой адрес порта на хосте с СУБД ADB;
ADB_MAX_POOL_SIZE - максимальный размер пула подключений к СУБД ADB;
ADB_FETCH_SIZE - максимальный размер возвращаемого результата по FETCH-запросу к СУБД ADB;
ADB_LOAD_GROUP – наименование консьюмер-группы СУБД ADB для взаимодействия с брокером сообщений Kafka;

Настройки механизма MPPW загрузки данных для плагина ADB:

ADB_MPPW_POOL_SIZE - максимальный размер пула подключений к СУБД ADB для операций MPPW;
ADB_MPPW_STOP_TIMEOUT_MS - интервал времени остановки таймаута в миллисекундах при операции MPP-загрузки в СУБД ADB;
ADB_MPPW_DEFAULT_MESSAGE_LIMIT - предельный размер сообщения по умолчанию для операции MPP-загрузки в СУБД ADB;
ADB_MPPW_FDW_TIMEOUT_MS – интервал времени ожидания до таймаута в миллисекундах при операции MPP-загрузки в СУБД ADB;

Настройки для СУБД ADG / Tarantool:

TARANTOOL_DB_HOST - сетевой адрес хоста с СУБД ADG;
TARANTOOL_DB_PORT - сетевой адрес порта на хосте с СУБД ADG;
TARANTOOL_DB_USER - имя пользователя/логин для авторизации в СУБД ADG;
TARANTOOL_DB_PASS - пароль для авторизации в СУБД ADG;
TARANTOOL_DB_OPER_TIMEOUT - максимальный интервал времени ожидания выполнения операции СУБД ADG до тайм-аута;
TARANTOOL_DB_RETRY_COUNT - максимальное количество повторных попыток выполнения операции;
TARANTOOL_CATRIDGE_URL - сетевой адрес и порт картриджа с графическим интерфейсом к СУБД ADG;
ADG_CONSUMER_GROUP - consumer-группа СУБД ADG для взаимодействия с брокером сообщений Kafka;
ADG_MAX_MSG_PER_PARTITION – максимальное количество сообщений на раздел СУБД ADG.
ADG_CB_FUNC_IDLE – время простоя (в секундах) callback-функции;
ADG_ROLLBACK_OPERATION_BATCH_SIZE - размер пакета операций при откате операции;
ADG_CIRCUIT_BREAKER_MAX_FAILURES - максимальное количество отказов ADG по паттерну circuitbreaker;
ADG_CIRCUIT_BREAKER_TIMEOUT - интервал времени фиксации отказа при пропадании отклика ADG;
ADG_CIRCUIT_BREAKER_FALLBACK_ON_FAILURE - использование паттерна fallback при отказе;
ADG_CIRCUIT_BREAKER_RESET_TIMEOUT - интервал времени до сброса по паттерну timeout;
ADG_WEB_CLIENT_MAX_POOL_SIZE - максимальный размер пула подключений веб-клиентов к СУБД ADG;

Настройки для плагина ADQM:

ADQM_DB_NAME - наименование СУБД ADQM;
ADQM_USERNAME - имя пользователя/логин для авторизации в СУБД ADQM;
ADQM_PASS - пароль для авторизации в СУБД ADQM;
ADQM_HOSTS - сетевой адрес хоста с СУБД ADQM и номер порта на хосте;
ADQM_SOCKET_TIMEOUT - интервал времени ожидания отклика соединения с СУБД ADQM до таймаута;
ADQM_DATA_TRANSFER_TIMEOUT - интервал времени ожидания завершения обмена данными с СУБД ADQM до таймаута;
ADQM_CLUSTER - наименование кластера СУБД ADQM;

Настройки MPPR для СУБД ADQM:

ADQM_MPPR_CONNECTOR_HOST - сетевой адрес коннектора MPP-выгрузки данных из ADQM;
ADQM_MPPR_CONNECTOR_PORT - сетевой порт коннектора MPP-выгрузки данных из ADQM;
ADQM_MPPR_CONNECTOR_URL - сетевой путь к коннектору MPP-выгрузки данных из ADQM;

Настройки MPPW для СУБД ADQM:

ADQM_CONSUMER_GROUP - наименование консьюмер-группы СУБД ADQM для взаимодействия с брокером сообщений Kafka;
ADQM_BROKERS - сетевой адрес брокера сообщений Kafka;
ADQM_MPPW_LOAD_TYPE - тип интерфейса для MPPW-загрузки данных в СУБД ADQM;
ADQM_REST_START_LOAD_URL - сетевой адрес и путь к REST-интерфейсу для старта загрузки данных в СУБД ADQM;
ADQM_REST_STOP_LOAD_URL - сетевой адрес и путь к REST-интерфейсу для остановки загрузки данных в СУБД ADQM;
ADQM_WEB_CLIENT_MAX_POOL_SIZE - максимальный размер пула подключений веб-клиентов к СУБД ADQM;

Настройка Сервиса мониторинга Kafka (status-monitor)

Настройка Сервиса мониторинга Kafka осуществляется путём указания в соответствующем конфигурационном текстовом yml-файле параметров отслеживания файлов-топиков брокера сообщений Kafka, таких как: смещения consumer, содержания последнего сообщения и времени появления последнего сообщения.

STATUS_MONITOR_BROKERS - сетевые адреса и порты брокеров сообщений Kafka, которые отслеживает монитор статусов Kafka
STATUS_MONITOR_CONSUMERS - количество потребителей (consumer) Сервиса мониторинга Kafka

Настройка Сервиса kafka-clickhouse-reader

Настройка Сервиса kafka-clickhouse-reader осуществляется путём указания в соответствующем конфигурационном текстовом yml-файле параметров:

CLICKHOUSE_DB_NAME – наименование базы данных в ADQM
CLICKHOUSE_HOSTS – имя одно их хостов ADQM
CLICKHOUSE_PASS – пароль пользователя для доступа к ADQM
CLICKHOUSE_USERNAME – имя пользователя для доступа к ADQM
ZOOKEEPER_HOSTS - Подключение к Zookeeper ProStore
KAFKA_CLUSTER_ROOTPATH - Путь хранения информации о Kafka ProStore в Zookeeper

Настройка Сервиса kafka-clickhouse-writer

Настройка Сервиса kafka-clickhouse-writer осуществляется путём указания в соответствующем конфигурационном текстовом yml-файле параметров:

CLICKHOUSE_DB_NAME – наименование базы данных в ADQM
CLICKHOUSE_HOSTS – имя одно их хостов ADQM
CLICKHOUSE_PASS – пароль пользователя для доступа к ADQM
CLICKHOUSE_USERNAME – имя пользователя для доступа к ADQM
KAFKA_BOOTSTRAP_SERVERS - Подключение к ProStore Kafka
ENV - Название окружения

4.2.13. Установка СМЭВ3-адаптера

Установка СМЭВ3-адаптер возможна, только если были добавлены ключи.

Действия по установке выполняются через SSH консоль технологического пользователя.

Установка КриптоПро

В случае использования для электронной подписи сервиса КриптоПро, необходимо предварительно скачать КриптоПро CSP (https://www.cryptopro.ru/download?pid=1417) и КриптоПро JCP (https://www.cryptopro.ru/download?pid=129) для Java JDK на компьютер, где будет устанавливаться СМЭВ3-адаптер. Установить, следуя инструкции и документации на официальном сайте. После чего получить сертификат для установки от уполномоченных лиц и установить его в КриптоПро.

Установка сервиса

Подготовка конфигурации

Для подготовки конфигурации необходимо отредактировать переменные в файле application.yml (пример application.yml приведен в Приложении 1) дистрибутива СМЭВ3-адаптер:

Указать корректный путь до СМЭВ. Переменная endpoint_url во всех вертиклах.
Указать корректный путь до ядра ProStore. Блок ProcessorVerticle:

jdbcUrl – строка подключения по JDBC в формате jdbc:postgresql://localhost:5432/smev3;
username – логин для подключения;
password – пароль для подключения;
readOnly – доступ только на чтение;

Если для цифровой подписи используется VipNet, указать переменные для доступа к VipNet:

keystoreType - тип хранилища, VIPNETPKI для VipNet
keystoreFile - URL Vipnet сервера
keystorePass - имя пользователя и пароль, выдается администратором Vipnet PKI
privateKeyAlias - токен, полученный от администратора VIPNet
certificateAlias - дублирование токена, полученного от администратора VIPNet

Если для цифровой подписи используется КриптоПро:

keystoreType - тип хранилища, JCP для КриптоПро
keystorePass - пароль хранилища ключей
privateKeyAlias - алиас приватного ключа
certificateAlias - алиас сертификата
privateKeyPass - пароль приватного ключа
signatureURI, signatureAlgorithm, digestMethod оставить аналогично указанным в примере Приложения 1.

Если используется механизм отправки дельт по расписанию и установлена сервисная БД, заполнить следующие параметры:

Для вертикла SchedulerVerticle:

interval - интервал между отправкой дельт;
template - pebble-шаблон/

Для вертикла DeltaStorageVerticle

jdbcUrl – строка подключения к сервисной БД по JDBC в формате jdbcUrl: jdbc:postgresql://127.0.0.1:5432/smev3_connector;
username – логин для подключения;
password – пароль для подключения;

Список параметров, которые необходимо настроить для обработки собственно запросов, их назначения и pebble шаблоны приведены в документе «Руководство программиста» п.3.1.2

Установка

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

Скопировать jar-файл СМЭВ3-адаптер, конфигурационный файл application.yml, jar-файл JDBC-драйвер ДТМ, сконфигурированные pebble-шаблоны на целевую машину.
В консоли перейти в каталог, в который были скопированы описанные в п.1 файлы:

Например:

cd ~/direct

Запустить jar-файл командой:

java -cp smev3-connector-x.x.x-fat.jar:dtm-jdbc-3.4.0.jar
-Dconfig.location=application.yml io.vertx.core.Launcher yml

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

INFO: Succeeded in deploying verticle

4.2.14. Установка ПОДД-адаптера

4.2.15. Процесс установки

Внимание

Данное руководство описывает процесс установки ПОДД-адаптера - Модуль исполнения запросов в «Витрину данных НСУД», для «Витрины данных Лайт» модуль будет добавлен автоматически при первоначальной установке программы.

Действия по установке выполняются через SSH консоль технологического пользователя.

Общий процесс установки состоит из следующих действий:

Настроить конфигурацию модуля.
Создать на сервере директорию для загрузки файлов модуля.
Загрузить файлы модуля в созданную директорию.
Запустить модуль.
Проверить установку модуля.

4.2.15.1. Настройка конфигурации

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

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

Примечание

Значения настроек MYSQL_USER для MariaDB и SUBSCR_DB_USER для Модуля исполнения запросов, а также MYSQL_PASSWORD и SUBSCR_DB_PASS, должны совпадать.

4.2.15.2. Кластеризация модуля

Кластеризация модуля достигается путем запуска копии экземпляра данного модуля. Оптимальным вариантом является использование оркестраторов, например:

Kubernetes;
Openshift;
Docker-swarm;
Nomad.

4.2.16. Настройка ПОДД-адаптера

4.2.16.1. Конфигурация ПОДД-адаптера - Модуль исполнения запросов (application.yml)

Файл application.yml – основной конфигурационный файл ПОДД-адаптера - Модуль исполнения запросов, в котором задана логика и порядок работы адаптера:

получение и обработка входящих запросов;
подключение к Сервису формирования документов (секция: printable-forms-service);
настройки логирования (секция: logging), а также другие настройки необходимые для корректной работы адаптера.

Хинт пагинации FORCE_LLR определен в переменных среды.

4.2.16.1.1. Пример файла application.yml

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

http-server:
  port: ${HTTP_PORT:8090}

environment:
  name: ${ENVIRONMENT_NAME:test}

executor:
  reader-pool-size: ${EXECUTOR_READER_POOL_SIZE:20}
  max-execute-time: ${EXECUTOR_MAX_EXECUTE_TIME:600}
  log-pool-size: ${EXECUTOR_LOG_POOL_SIZE:20}

send:
  channel-size: ${SEND_CHANNEL_SIZE:1}
  compress: ${SEND_COMPRESS:none}
  max-message-size: ${SEND_MAX_MESSAGE_SIZE:800000}

query:
  data-source-type:
    for-listagg: ${DATA_SOURCE_TYPE_LISTAGG:ADP}
    statistics-request: ${DATA_SOURCE_TYPE_STATISTIC:ADP}
  force-llr-for-order: ${FORCE_LLR_FOR_ORDER:true}
  force-llr-for-all: ${FORCE_LLR_FOR_ALL:false}
  llr-rows-limit: ${LLR_ROWS_LIMIT:200}
  fetch-size: ${FETCH_SIZE:1000}

zookeeper:
  connection-string: ${ZOOKEEPER_DS_ADDRESS:localhost}
  connection-timeout-ms: ${ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000}
  session-timeout-ms: ${ZOOKEEPER_DS_SESSION_TIMEOUT_MS:86400000}
  chroot: ${ZOOKEEPER_DS_CHROOT:/adapter}

prostore-rest-client:
  host: ${PS_HOST:localhost}
  port: ${PS_PORT:9195}
  http:
    max-pool-size: ${PS_MAX_POOL_SIZE:8}

printable-forms-service:
  host: ${PFS_HOST:localhost}
  port: ${PFS_PORT:8080}
  pool-size: ${PFS_POOL_SIZE:10}
  timeout: ${PFS_TIMEOUT:30}

kafka:
  agent.topic.prefix: ${AGENT_TOPIC_PREFIX:}
  max-concurrent-handle: ${KAFKA_MAX_CONCURRENT_HANDLE:1000}
  commit-interval: ${KAFKA_COMMIT_INTERVAL:5s}
  external:
    bootstrap.servers: ${KAFKA_BOOTSTRAP_SERVERS:localhost:9092}
    topic.prefix: ${EXTERNAL_TOPIC_PREFIX:${agent.topic.prefix}}
  internal:
    bootstrap.servers: ${PS_KAFKA:localhost:9092}
    topic.prefix: ${INTERNAL_TOPIC_PREFIX:${agent.topic.prefix}}
  consumer:
    query-request:
      topic: ${kafka.external.topic.prefix}query.rq
      max-concurrent-handle: ${kafka.max-concurrent-handle}
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}query.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    query-cancel-request:
      topic: ${kafka.external.topic.prefix}cancel.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}cancel.query.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    metadata-request:
      topic: ${kafka.external.topic.prefix}metadata.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}metadata.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    metadata-new-data-request:
      topic: ${kafka.external.topic.prefix}metadata.newdata.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}metadata.newdata.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    statistics-request:
      topic: ${kafka.external.topic.prefix}statistics.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}statistics.rq.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    report-request:
      topic: ${kafka.external.topic.prefix}procedure.query.rq
      max-concurrent-handle: ${kafka.max-concurrent-handle}
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}report.rq.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
  producer:
    query-result: ${kafka.external.topic.prefix}query.rs
    query-error: ${kafka.external.topic.prefix}query.err
    query-estimation-result: ${kafka.external.topic.prefix}query.estimation.rs
    query-cancel-result: ${kafka.external.topic.prefix}cancel.rs
    query-cancel-error: ${kafka.external.topic.prefix}cancel.err
    metadata-result: ${kafka.external.topic.prefix}metadata.rs
    metadata-error: ${kafka.external.topic.prefix}metadata.err
    metadata-newdata-result: ${kafka.external.topic.prefix}metadata.newdata.rs
    metadata-newdata-error: ${kafka.external.topic.prefix}metadata.newdata.err
    statistics-result: ${kafka.external.topic.prefix}statistics.rs
    statistics-error: ${kafka.external.topic.prefix}statistics.err
    report-result: ${kafka.external.topic.prefix}query.rs
    report-error: ${kafka.external.topic.prefix}query.err
    property:
      bootstrap.servers: ${kafka.external.bootstrap.servers}
    internal:
      mppr-query-request: ${kafka.internal.topic.prefix}mppr.delegate.rq
      tp-delete-tmp: ${kafka.internal.topic.prefix}tp.delete.tmp
      property:
        bootstrap.servers: ${kafka.internal.bootstrap.servers}

statistics:
  enabled: ${STATISTICS_ENABLED:false}
  timeout-min: ${STATISTICS_TIMEOUT_MIN:60}
  datamarts:
    - name: demo_dev
      tables:
        - name: all_types
          columns:
            - varchar_c
            - char_c
            - bigint_c

logging:
  request-response:
    query-request: ${QUERY_REQUEST_LOG_ENABLED:false}
    query-response: ${QUERY_RESPONSE_LOG_ENABLED:false}
    pf-request: ${PF_REQUEST_LOG_ENABLED:false}
    pf-response: ${PF_RESPONSE_LOG_ENABLED:false}

metrics:
  port: ${METRICS_PORT:9837}

4.2.16.2. Параметры конфигурации

Настройка конфигурации ПОДД-адаптера - Модуль исполнения запросов осуществляется путем редактирования параметров настроек в файле application.yml, где настраиваются секции:

http-server - указывается порт для подключения;
environment - указывается название окружения (test, prod и т.д.);
executor - настраивается размер пула для запросов;
send - настраиваются ограничения на размер загружаемого файла;
query - настройка выполнения запросов;
zookeeper - подключения в Zookeeper;
prostore-rest-client - блок параметров конфигурирования взаимодействия с ProStore;
prostore- указываются настройки подключения к ProStore;
printable-forms-service - настройки подключения к Сервис формирования документов;
kafka - настройки параметров подключения к шине данных Apache Kafka;
statistics - управление статистикой;
logging - настройка сохранения лог-файла;
metrics - настройка получения метрик.

4.2.16.2.1. Секция http-server

В секции http-server указывается порт веб-сервера.

Например:

http:
  port: ${HTTP_PORT:8090}

Параметры настроек

port - порт веб-сервера, например: HTTP_PORT:8090.

4.2.16.2.2. Секция environment

Секция environment предназначена для настройки параметров окружения.

Например:

environment:
  name: ${ENVIRONMENT_NAME:test}

Параметры настроек

name - название окружения (test, prod и т.д.), например: ENVIRONMENT_NAME:test.

4.2.16.2.3. Секция executor

Секция executor предназначена для указания размера пула для чтения Kafka и времени выполнения задач.

Например:

executor:
  reader-pool-size: ${EXECUTOR_READER_POOL_SIZE:20}
  max-execute-time: ${EXECUTOR_MAX_EXECUTE_TIME:600}
  log-pool-size: ${EXECUTOR_LOG_POOL_SIZE:20}

Параметры настроек

reader-pool-size - размер пула для чтения Kafka, например EXECUTOR_READER_POOL_SIZE:20;
max-execute-time - максимальное время выполнения задачи (сек), например EXECUTOR_MAX_EXECUTE_TIME:600;
log-pool-size - размер используемого пула для журналирования запросов и ответов, например EXECUTOR_LOG_POOL_SIZE:20.

4.2.16.2.4. Секция send

В секции send настраиваются ограничения на размер загружаемого файла.

Например:

send:
  channel-size: ${SEND_CHANNEL_SIZE:1}
  compress: ${SEND_COMPRESS:none}
  max-message-size: ${SEND_MAX_MESSAGE_SIZE:800000}

Параметры настроек

channel-size - размер канала на отправку сообщения, например SEND_CHANNEL_SIZE:10;
compress - сжатие выгружаемых сообщений (none или zstd), например SEND_COMPRESS:none;
max-message-size - максимальный размер отправляемого сообщения, например SEND_MAX_MESSAGE_SIZE:800000.

4.2.16.2.5. Секция query

В секции query выполняется настройка выполнения запросов.

Например:

query:
  data-source-type:
    for-listagg: ${DATA_SOURCE_TYPE_LISTAGG:ADP}
    statistics-request: ${DATA_SOURCE_TYPE_STATISTIC:ADP}
  force-llr-for-order: ${FORCE_LLR_FOR_ORDER:true}
  force-llr-for-all: ${FORCE_LLR_FOR_ALL:false}
  llr-rows-limit: ${LLR_ROWS_LIMIT:200}
  fetch-size: ${FETCH_SIZE:1000}

Параметры настроек

data-source-type - выполнение запроса с LISTAGG на (ADB/ADP), например DATA_SOURCE_TYPE:ADB;
force-llr-for-order - выполнение ORDER BY запроса c использованием пагинации, например FORCE_LLR_FOR_ORDER:true;
force-llr-for-all - выполнение всех запросов через LLR, например FORCE_LLR_FOR_ALL:false;
llr-rows-limit - ограничение выгрузки через ЛЛР, при использовании в запросе лимита со значением меньшим, чем указанное значение, например LLR_ROWS_LIMIT:200, будет использован режим LLR;
fetch-size - размер выгрузки через JDBC, например FETCH_SIZE:1000.

Внимание

Для опции force-llr-for-order параметр false можно устанавливать только при развертывании витрины на единственной БД ADP.

4.2.16.2.6. Секция zookeeper

Секция zookeeper определяет настройки подключения к Zookeeper DS.

Например:

zookeeper:
  connection-string: ${ZOOKEEPER_DS_ADDRESS:t5-adsp-01.ru-central1.internal}
  connection-timeout-ms: ${ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000}
  session-timeout-ms: ${ZOOKEEPER_DS_SESSION_TIMEOUT_MS:86400000}
  chroot: ${ZOOKEEPER_DS_CHROOT:/adapter}

Параметры настроек

connection-string - подключение в Zookeeper DS, например ZOOKEEPER_DS_ADDRESS:t5-adsp-01.ru-central1.internal;
connection-timeout-ms - Zookeeper DS таймаут подключения, например ZOOKEEPER_DS_CONNECTION_TIMEOUT_MS:30000;
session-timeout-ms - Zookeeper DS таймаут сессии, например ZOOKEEPER_DS_SESSION_TIMEOUT_MS:86400000;
chroot - Zookeeper DS chroot path, например ZOOKEEPER_DS_CHROOT:/adapter.

4.2.16.2.7. Секция prostore-rest-client

В секции prostore-rest-client реализован блок параметров конфигурирования взаимодействия с ProStore.

Например:

prostore-rest-client:
  host: ${PS_HOST:localhost}
  port: ${PS_PORT:9195}
  http:
    max-pool-size: ${PS_MAX_POOL_SIZE:8}

Параметры настроек

host - адрес Prostore, например PS_HOST:localhost;
port - порт Prostore, например PS_PORT:9195;
max-pool-size - максимальное число подключений к Prostore, например PS_MAX_POOL_SIZE:8.

4.2.16.2.8. Секция printable-forms-service

Секция printable-forms-service определяет настройки подключения к Сервис формирования документов.

Например:

printable-forms-service:
  host: ${PFS_HOST:localhost}
  port: ${PFS_PORT:8080}
  pool-size: ${PFS_POOL_SIZE:10}
  timeout: ${PFS_TIMEOUT:30}

Параметры настроек

host - адрес сервера формирования документов, например PFS_HOST:localhost;
port - порт сервера формирования документов, например PFS_PORT:8080;
pool-size - размер пула соединений для ПФ, например PFS_POOL_SIZE:10;
timeout - таймаут переподключения к сервису формирования документов (секунды), например PFS_TIMEOUT:30.

4.2.16.2.9. Секция kafka

В секции kafka настраиваются параметры подключения к шине данных Apache Kafka.

Например:

kafka:
  agent.topic.prefix: ${AGENT_TOPIC_PREFIX:}
  max-concurrent-handle: ${KAFKA_MAX_CONCURRENT_HANDLE:1000}
  commit-interval: ${KAFKA_COMMIT_INTERVAL:5s}
  external:
    bootstrap.servers: ${KAFKA_BOOTSTRAP_SERVERS:localhost:9092}
    topic.prefix: ${EXTERNAL_TOPIC_PREFIX:${agent.topic.prefix}}
  internal:
    bootstrap.servers: ${PS_KAFKA:localhost:9092}
    topic.prefix: ${INTERNAL_TOPIC_PREFIX:${agent.topic.prefix}}
  consumer:
    query-request:
      topic: ${kafka.external.topic.prefix}query.rq
      max-concurrent-handle: ${kafka.max-concurrent-handle}
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}query.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    query-cancel-request:
      topic: ${kafka.external.topic.prefix}cancel.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}cancel.query.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    metadata-request:
      topic: ${kafka.external.topic.prefix}metadata.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}metadata.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    metadata-new-data-request:
      topic: ${kafka.external.topic.prefix}metadata.newdata.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}metadata.newdata.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    statistics-request:
      topic: ${kafka.external.topic.prefix}statistics.rq
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}statistics.rq.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
    report-request:
      topic: ${kafka.external.topic.prefix}procedure.query.rq
      max-concurrent-handle: ${kafka.max-concurrent-handle}
      commit-interval: ${kafka.commit-interval}
      property:
        bootstrap.servers: ${kafka.external.bootstrap.servers}
        group.id: ${kafka.external.topic.prefix}report.rq.consumer
        auto.offset.reset: earliest
        enable.auto.commit: false
  producer:
    query-result: ${kafka.external.topic.prefix}query.rs
    query-error: ${kafka.external.topic.prefix}query.err
    query-estimation-result: ${kafka.external.topic.prefix}}query.estimation.rs
    query-cancel-result: ${kafka.external.topic.prefix}cancel.rs
    query-cancel-error: ${kafka.external.topic.prefix}cancel.err
    metadata-result: ${kafka.external.topic.prefix}metadata.rs
    metadata-error: ${kafka.external.topic.prefix}metadata.err
    metadata-newdata-result: ${kafka.external.topic.prefix}metadata.newdata.rs
    metadata-newdata-error: ${kafka.external.topic.prefix}metadata.newdata.err
    statistics-result: ${kafka.external.topic.prefix}statistics.rs
    statistics-error: ${kafka.external.topic.prefix}statistics.err
    report-result: ${kafka.external.topic.prefix}query.rs
    report-error: ${kafka.external.topic.prefix}query.err
    property:
      bootstrap.servers: ${kafka.external.bootstrap.servers}
    internal:
      mppr-query-request: ${kafka.internal.topic.prefix}mppr.delegate.rq
      tp-delete-tmp: ${kafka.internal.topic.prefix}tp.delete.tmp
      property:
        bootstrap.servers: ${kafka.internal.bootstrap.servers}

Параметры конфигурации

topic - префикс для топиков Агента СМЭВ4, например AGENT_TOPIC_PREFIX.

4.2.16.2.10. Секция statistics

Секция statistics предназначена для управления статистикой.

Например:

statistics:
  enabled: ${STATISTICS_ENABLED:false}
  timeout-min: ${STATISTICS_TIMEOUT_MIN:60}
  datamarts:
    - name: demo_dev
      tables:
        - name: all_types
          columns:
            - varchar_c
            - char_c
            - bigint_c

Параметры конфигурации

enabled - включение (true)/ выключение (false) расчета статистики, например STATISTICS_ENABLED:false;
timeout-min - время обновления статистики (минуты), например STATISTICS_TIMEOUT_MIN:60.

4.2.16.2.11. Секция logging

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

Например:

logging:
  request-response:
    query-request: ${QUERY_REQUEST_LOG_ENABLED:false}
    query-response: ${QUERY_RESPONSE_LOG_ENABLED:false}
    pf-request: ${PF_REQUEST_LOG_ENABLED:false}
    pf-response: ${PF_RESPONSE_LOG_ENABLED:false}

Параметры конфигурации

query-request - журналирование query запросов, например QUERY_REQUEST_LOG_ENABLED:false;
query-response - журналирование query ответов, например QUERY_RESPONSE_LOG_ENABLED:false;
pf-request - журналирование запросов на сервис формирования документов, например PF_REQUEST_LOG_ENABLED:false;
pf-response - журналирование ответов от сервиса формирования документов, например PF_RESPONSE_LOG_ENABLED:false.

4.2.16.2.12. Секция metrics

Секция metrics предназначена для настройки параметров метрик.

Например:

metrics:
  port: ${METRICS_PORT:9837}

Параметры конфигурации

port - Порт для метрик, например METRICS_PORT:9837.

4.2.17. Установка ETL

Установка Apache Airflow

Подготовка конфигурации

Клонировать репозиторий Apache Airflow из официального репозитория:
```
git clone https://github.com/apache/airflow.git
```
Перейти в папку airflow

Создать в папке файл Dockerfile.custom со следующим содержимым:

FROM ${BASE_AIRFLOW_IMAGE}
SHELL ["/bin/bash", "-o", "pipefail", "-e", "-u", "-x", "-c"]
USER 0
# Install Java
RUN mkdir -pv /usr/share/man/man1 \\
&& mkdir -pv /usr/share/man/man7 \\
&& curl -fsSL
https://adoptopenjdk.jfrog.io/adoptopenjdk/api/gpg/key/public \|
apt-key add - \\
&& echo 'deb https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/ buster
main' > \\
/etc/apt/sources.list.d/adoptopenjdk.list \\
&& apt-get update \\
&& apt-get install --no-install-recommends -y \\
adoptopenjdk-8-hotspot-jre \\
&& apt-get autoremove -yqq --purge \\
&& apt-get clean \\
&& rm -rf /var/lib/apt/lists/\*
# Установка JDR 1.8
ENV JAVA_HOME=/usr/lib/jvm/adoptopenjdk-8-hotspot-jre-amd64
USER ${AIRFLOW_UID}
# Установка компонента apache.spark
RUN pip install --upgrade pip \\
&& pip install --no-cache-dir --user 'apache-airflow[apache.spark]'

Установка

Установка docker описана в разделе 3.3.2. Установка Менеджера кластера ADCM.

Создать новый образ в докере, в той же директории, где расположен файл Dockerfile.custom:

docker build . \ –build-arg BASE_AIRFLOW_IMAGE=»apache/airflow:2.0.1-python3.8» \ -f Dockerfile.java8 \ -t airflow:2.0.1-python3.8-custom
Скачать файл docker-compose.yaml с официального сайта Airflow https://Airflow.apache.org/docs/apache-airflow/2.0.1/docker-compose.yaml
Установить docker-compose.yaml через SSH-консоль технологического пользователя.

Выдать права на исполнение файла:
```
sudo chmod +x /usr/local/bin/docker-compose
```

Запустить sudo:

ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose

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

$ docker-compose --version
docker-compose version 1.28.6, build 1110ad01

Перейти в директорию с файлом docker-compose.yml

Например:

cd ~/direct

Инициализировать компоненты:
```
docker-compose up airflow-init
```

Запустить сервисы с новым образом:

docker-compose up
AIRFLOW_IMAGE_NAME=apache/airflow:2.0.1-python3.8-custom

Установка Apache Spark

Установка docker описана в разделе 3.3.2. Установка Менеджера кластера ADCM.

Подготовка конфигурации
Клонировать репозиторий Apache Airflow из официального репозитория:

git clone https://github.com/big-data-europe/docker-spark.git
Перейти в директорию docker-spark

Пример:

cd ~/direct
Выполнить скрипт ./build.sh или вручную последовательно запустить следующие команды:
- сборка базового образа
  
  docker build -t bde2020/spark-base:3.1.1-hadoop3.2
- сборка образа мастер
  
  docker build -t bde2020/spark-master:3.1.1-hadoop3.2
- сборка образа воркера
  
  docker build -t bde2020/spark-worker:3.1.1-hadoop3.2
Проверить наличие собранных образов:

Выполнить команду docker images:

REPOSITORY TAG IMAGE ID CREATED SIZE

bde2020/spark-worker 3.1.1-hadoop3.2 05c349b4646f 4 minutes ago 460MB

bde2020/spark-master 3.1.1-hadoop3.2 7918c5357d6d 4 minutes ago 460MB

bde2020/spark-base 3.1.1-hadoop3.2 5430434220d2 4 minutes ago 460MB
1. Установка
Перейти в директорию docker-spark, где располагается файлом docker-compose.yml

Пример:

cd ~/direct
Поднять Apache Spark командой:

docker-compose up
Проверить командой:

docker ps

В списке запущенных образов должны присутствовать spark-worker и spark-master

Установка Apache Hadoop

Установка docker описана в разделе 3.3.2. Установка Менеджера кластера ADCM.

Подготовка конфигурации
Клонировать репозиторий Apache Hadoop из официального репозитория:
```
git clone https://github.com/big-data-europe/docker-hadoop.git
```

Перейти в папку docker-hadoop

Наример:

cd ~/direct

Выполнить скрипт make build или вручную последовательно запустить следующие команды:

сборка базового образа:

docker build -t bde2020/hadoop-base:master ./base

сборка остальных образов:

docker build -t bde2020/hadoop-namenode:master ./namenode
docker build -t bde2020/hadoop-datanode:master ./datanode
docker build -t bde2020/hadoop-resourcemanager:master
./resourcemanager
docker build -t bde2020/hadoop-nodemanager:master ./nodemanager
docker build -t bde2020/hadoop-historyserver:master
./historyserver
docker build -t bde2020/hadoop-submit:master ./submit

Проверить наличие собранных образов:

Выполнить команду docker images:

REPOSITORY TAG IMAGE ID CREATED SIZE

bde2020/hadoop-submit master 665a424edc23 9 minutes ago 1.37GB

bde2020/hadoop-historyserver master ff53bf6835e2 9 minutes ago 1.37GB

bde2020/hadoop-nodemanager master c48c47bc840f 9 minutes ago 1.37GB

bde2020/hadoop-resourcemanager master 74fc55d664d2 9 minutes ago 1.37GB

bde2020/hadoop-datanode master f69c6460a292 9 minutes ago 1.37GB

bde2020/hadoop-namenode master 7a8250da8510 9 minutes ago 1.37GB

bde2020/hadoop-base master aeb6500ab4b5 10 minutes ago 1.37GB

Установка

Перейти в директорию docker-hadoop, где располагается файл docker-compose.yml

Наример:

cd ~/direct

Поднять Apache Hadoop командой:
```
docker-compose up
```
Проверить командой:
```
docker ps
```

В списке запущенных образов должны присутствовать hadoop-resourcemanager, hadoop-historyserver, hadoop-datanode, hadoop-nodemanager, hadoop-namenode

Установка СУБД Tarantool

Установка docker описана в разделе 3.3.2. Установка Менеджера кластера ADCM.

Подготовка конфигурации

Клонировать репозиторий Tarantool из официального репозитория:
```
git clone https://github.com/tarantool/docker.git
```
Выполнить сборку согласно инструкции:

https://github.com/tarantool/docker#how-to-push-an-image-for-maintainers

Перейти в клонированную папку docker

Например:

cd ~/direct

Выполнить сборку образа docker для Tarantool:

export TAG=2 export OS=alpine DIST=3.9 VER=2.8.0 PORT=5200 make -f .gitlab.mk build

Проверить наличие собранных образов командой docker images:

REPOSITORY TAG IMAGE ID CREATED SIZE
tarantool/tarantool 2 27f80564ecce 2 minutes ago 298MB

Создать в клонированной директории docker файл docker-compose.yml со следующим содержимым:

version: "3"
services:
tarantool1:
image: tarantool/tarantool:2
container_name: tarantool1
restart: always
networks:
- tarantool_network
ports:
- "3301:3301"
volumes:
- tarantool1_volume:/opt/tarantool
environment:
# https://github.com/tarantool/docker#environment-variables
TARANTOOL_REPLICATION: "tarantool1,tarantool2"
tarantool2:
image: tarantool/tarantool:2
container_name: tarantool2
restart: always
networks:
- tarantool_network
ports:
- "3302:3301"
volumes:
- tarantool2_volume:/opt/tarantool
environment:
TARANTOOL_REPLICATION: "tarantool1,tarantool2"
volumes:
tarantool1_volume:
tarantool2_volume:
networks:
tarantool_network:
driver: bridge

Установка

Перейти в директорию docker, где располагается файл docker-compose.yml

Напимер:

cd ~/direct

Пример запуска мастер-мастер репликации:

https://github.com/tarantool/docker#start-a-master-master-replica-set

Поднять Tarantool командой:
```
docker-compose up
```
Проверить командой:
```
docker ps
```

В списке запущенных образов должны присутствовать tarantool1 и tarantool2

4.2.18. Установка REST-адаптера

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

Внимание

Установка данных сервисов выполняется после установки «Core Services».

Действия по установке выполняются на сервере ADCM через SSH-консоль технологического пользователя.

Установка docker-образов

Установка docker описана в разделе 3.3.2. Установка Менеджера кластера ADCM. Установить образ сервера конечных точек API, файл образа .tar должен быть загружен через docker. (ссылки для скачивания указаны в Таблица 2 - Состав типового ПО ведомственной витрины данных НСУД в строке «Сервер конечных точек API).

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

docker image load -i <image_file>

Подготовка конфигурации

Для подготовки скриптов необходимо выполнить следующие действия:

Отредактировать переменные в файле application.yml для вашей среды. Пример файла приведен в Приложении 1. Файл необходимо поместить в папку config:

Указать корректный путь до целевой БД. Переменная jdbc_url.

Например:

jdbc:{drv_name}://{IP_Host}:{Port}/{db_name}

, где:

drv_name - имя драйвера , берется из описания драйвера базы
IP_Host - ip или имя хоста с базой;
Port - порт, на котором будет слушать сервис . По умолчанию 8080;
db_name - имя базы данных.
Указать driver-class-name - имя класса , берется из описания драйвера базы
Указать переменную file_path - наименование файла с описанием запросов, по умолчанию sample.yaml.
Указать переменные execquery - сопоставление operationId из файла с описанием запросов c файлом обработчиком, по умолчанию sample.peb.

Установка

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

Перейти в директорию с файлом docker-compose.yml

Наример:

cd ~/direct

Поднять сервис конечных точек командой:
```
docker-compose up -d
```
Проверить установку следующей командой:

docker ps

В списке запущенных образов должен присутствовать rest-adapter

4.2.19. Настройка сервера конечных точек API

Детальные примеры описания REST API и pebble-шаблонов приведены в документе «Руководство программиста».

Kонфигурационный файл с конечными точками

Для доступа к конечным точкам необходим отредактировать файл sample.yaml, описав все необходимые API в соответствии с приведенным в файле шаблоном (шаблон соответствует спецификации OpenAPI 3.0 https://swagger.io/specification/ ).

Секция: servers:

url: / - корневой путь сервера.

Секция: paths

/test/query - путь запроса;
тип запроса - get , post и т.д. ;
operationId - определение operationId для связки с темплейт файлом;
responses - описание параметров ответа.

Шаблоны

Для парсинга и обогащениe запросов используются шаблоны.

В качестве языка шаблонов используется pebble. С дополнениями:

функция xpath(expression) - возвращает вычисленное выражение на входящем документе;
тэг {% mtom %} some content {% endmtom %} - отправляет внутренность вложением;
функция sql(var, sql, param1, param2, ...) - выполняет sql с параметрами, результат записывается в переменную var.

Пример формирования шаблона приведен в файле sample.peb.