Важно: Данный раздел актуален для Платформы данных в Публичном облаке и On-Premise.
¶ 1. Назначение документа
Настоящий документ включает описание RT.WareHouse и описание его компонент.
¶ 2. Общие положения
¶ 2.1 Наименование и условные обозначения
Наименование системы: RT.WareHouse.
¶ 2.2 Область применения
RT.WareHouse — реляционная СУБД, имеющая массово-параллельную архитектуру (MPP, Massively Parallel Processing) без разделения ресурсов (Shared Nothing) и предназначенная для хранения, обработки и анализа больших объёмов структурированных и слабоструктурированных данных.
¶ 2.3 Термины, определения и сокращения
В настоящем документе использованы и определены следующие термины и сокращения:
| Термин/ Сокращение | Определение |
|---|---|
| Atomicity, Consistence, Isolation, Durability, ACID | Атомарность, целостность, изолированность, постоянство. |
| Business Intelligence, BI | Набор IT-технологий для сбора, хранения и анализа данных, позволяющих предоставлять пользователям достоверную аналитику в удобном формате, на основе которой можно принимать эффективные решения для управления бизнес-процессами компании. |
| Extract, Transform, Load, ETL | Дословно «извлечение, преобразование и загрузка». То есть процесс, с помощью которого данные из нескольких систем объединяют в единое хранилище данных. |
| Massive Parallel Processing, MPP | Массово-параллельная архитектура, особенностью которой является физическое разделение памяти узлов, объединённых в кластер. В случае MPP-СУБД каждый узел кластера работает со только своими жёсткими дисками, распараллеливая операции чтения и записи данных. После того, как каждый из узлов закончит свои вычисления и отсортирует их в нужном порядке, ему нужно получить необходимые данные от остальных серверов. Для этого каждый узел отправляет свою порцию данных на все остальные сервера по быстрой обособленной сети (интерконнект). Поскольку информация уже отсортирована, то на каждом узле при получении данных происходит отбор только тех записей, которые нужны для обработки, а остальные сразу отсеиваются и не занимают места в оперативной памяти. В итоге чтение с жёстких дисков происходит быстрее, обработка результатов — тоже, и общее суммарное время выполнения операции оказывается меньше, чем в традиционных СУБД. |
| Platform eXtension Framework, PXF | Инструмент, позволяющий выполнять операции шифрования и цифровой подписи сообщений, файлов и другой информации, представленной в электронном виде, в том числе прозрачное шифрование данных на запоминающих устройствах, например, на жёстком диске. |
| Role Based Access Control, RBAC | Управление доступом на основе ролей, т.е. развитие политики избирательного управления доступом, при этом права доступа субъектов системы на объекты группируются с учётом специфики их применения, образуя роли. |
| Secure Sockets Layer, SSL | Дословно «уровень защищённых cокетов». Криптографический протокол для безопасной связи. |
| Shared Nothing | Распределённая вычислительная архитектура, в которой каждый хост независим и самостоятелен, отсутствует единая для всей системы точка подключения. |
| Wright Ahead Log, WAL | Журнал опережающей записи, который гарантирует, что до занесения на диск записи, связанной с журналом, никакие изменения данных записаны не будут. Таким образом обеспечиваются свойства ACID для транзакции. |
| Интерконнект | Сеть, предназначенная для взаимодействия мастера и сегментов между собой. |
| Кластер | Группа серверов и координирующего программного обеспечения, объединённых логически, способных обрабатывать идентичные запросы и использующихся как единый ресурс. |
| Мастер | Точка входа в систему RT.WareHouse. Мастер принимает клиентские соединения и обрабатывает команды SQL, содержит системный каталог (набор системных таблиц с метаданными о системе), однако мастер не содержит никаких пользовательских данных. |
| Метаданные | Субканальная информация об используемых данных. Структурированные данные, представляющие собой характеристики описываемых сущностей для целей их идентификации, поиска, оценки, управления ими. |
| Репликация | Механизм синхронизации содержимого нескольких копий объекта (например, содержимого базы данных). |
| Сегмент | Инстанс PostgreSQL, запущенный на одном из серверов сегментов, хранящий и обрабатывающий свою часть данных. Пользователи не взаимодействуют напрямую с сегментами, но делают это через мастера. |
| Транзакция | Группа последовательных операций с базой данных. Транзакция может быть выполнена либо целиком и успешно, соблюдая целостность данных и независимо от параллельно идущих других транзакций, либо не выполнена вообще, и тогда она не должна произвести никакого эффекта. |
| Хост | Устройство, соединённое с другими устройствами через сеть. По сути, хост — это устройство, имеющее свой IP-адрес, и способное совершать обмен данными. Хостами могут быть компьютеры, мобильные телефоны, а также специальные сетевые устройства, такие как маршрутизатор, коммутатор. |
| Хост сегмента | Сервер, на котором запущен один или несколько сегментов. |
| Шардирование | Техника масштабирования при работе с данными. Суть его в разделении (партиционирование) базы данных на отдельные части так, чтобы каждую из них можно было вынести на отдельный сервер. |
¶ 3. Назначение RT.WareHouse
Основным назначением RT.WareHouse является:
- Загрузка и хранение структурированных данных.
- Анализ данных.
- Работа с Business Intelligence (BI) приложениями.
- Использование алгоритмов машинного обучения.
RT.WareHouse может выполнять автоматизацию следующих бизнес-процессов:
- Использование RT.WareHouse в аналитике и машинном обучении, т.к. система обеспечивает хранение большого объёма данных, с которыми можно производить операции (например, сложные запросы) в быстрые сроки.
- Использование RT.WareHouse в банковской сфере, в сферах ритейла и прочих за счёт устойчивого хранения большого объёма постоянно изменяющихся данных в строгой структуре.
- Выстраивание мощного корпоративного хранилища благодаря интеграции с дополнительными решениями (например, Hadoop, ETL-компонентами, BI-инструментами и прочими).
RT.WareHouse обладает следующими особенностями:
- Линейная масштабируемость — за счёт увеличения количества хостов при росте объёма данных.
- Высокая пропускная способность — использование нескольких интерконнектов позволяет повысить пропускную способность канала взаимодействия сегментов между собой и обеспечить отказоустойчивость кластера за счёт перераспределения трафика.
- Высокая устойчивость к отказам — в случае отказа одного или нескольких сегментов они помечаются как сбойные и вместо них запускаются их зеркальные сегменты, репликация данных для которых происходит с помощью используемой в СУБД PostgreSQL технологии опережающей записи (WAL).
- Безопасность — достигается путём шифрования данных и соединений сервер-клиент по протоколу SSL на всех этапах их жизненного цикла. Кроме этого все внутренние взаимодействия компонент RT.WareHouse (мастера и резервного мастера, основных и резервных сегментов) также могут быть зашифрованы с помощью протокола SSL, а данные, хранящиеся на дисках кластера, могут быть зашифрованы с помощью ключей PGP (на уровне таблиц или колонок в таблицах). Все это позволяет исключить ситуации нахождения данных в незашифрованном виде. Безопасность также реализована благодаря разграничению зон видимости данных и прав доступа, которые обеспечиваются за счёт ролевой модели доступа (RBAC). Она позволяет реализовать гибкие, изменяющиеся динамически в процессе функционирования платформы хранения и обработки данных правила разграничения доступа. Так, например, можно создать схемы ограничения доступа к таблицам и другим объектам СУБД, а также к строкам и столбцам отдельных таблиц.
- Гибкость и производительность при обмене данными с внешними системами — за счёт использования протокола параллельного обмена данных со сторонними системами PXF, который обеспечивает взаимодействие с внешней системой одновременно всех сегментов кластера. Если система-источник также представляет собой кластер, то можно использовать кластерное взаимодействие с обеих сторон, что позволяет повысить производительность, причём скорость взаимодействия будет расти по мере расширения кластеров.
- Высокая мощность вычислений — за счёт реализации классической схемы разделения (шардирования) данных, т.е. каждая таблица состоит из N таблиц, размещаемых на N сегментах кластера. Логика разбиения таблицы на сегменты задаётся ключом (полем) дистрибуции. Выполнение запросов производится сразу к нескольким сегментам, на которых размещены данные.
- Надёжность хранения данных — за счёт использование разного типа и уровня сжатия для каждой отдельной колонки в таблице. В системе используются типы компрессии zlib (одна из самых широко используемых библиотек сжатия, в частности, используется в дистрибутивах Linux) и RLE delta compression (хранение изменений между значениями полей в колонке).
¶ 4. Описание RT.WareHouse
Компоненты RT.WareHouse представлены ниже (Рисунок 1).
Рисунок 1 — Компоненты RT.WareHouse
RT.WareHouse включает в себя следующие функциональные компоненты:
1. Мастер (основной мастер) — инстанс RT.WareHouse, который выполняет следующие функции:
- является точкой входа в систему для пользователей — аутентифицирует клиентские соединения, обрабатывает входящие SQL-команды и возвращает результаты их обработки сегментами обратно клиентской программе;
- координирует работу сегментов — распределяет рабочую нагрузку между сегментами, координирует результаты работы, возвращаемые сегментами;
- хранит метаданные системы — ведёт системный каталог (набор системных таблиц, содержащих метаданные о системе RT.WareHouse), но при этом не хранит пользовательских данных.
2. Резервный мастер — инстанс RT.WareHouse, который выполняет функции основного мастера, если тот становится недоступным. Переключение на резервный мастер осуществляется вручную.
3. Сегмент (основной сегмент) — инстанс RT.WareHouse, который выполняет следующие функции:
- хранит данные — пользовательские данные и их индексы распределены по сегментам, т.е. каждый сегмент содержит часть хранимых в системе данных;
- обрабатывает данные в соответствии с получаемыми запросами;
- передаёт результат обработки данных мастеру.
4. Резервный сегмент (сегмент-зеркало) — инстанс RT.WareHouse, который выполняет функции основного сегмента, когда тот становится недоступным. Для основного сегмента может быть только один резервный сегмент.
5. Интерконнект — соединение всех инстансов RT.WareHouse на сетевом уровне с помощью обособленных сетей. Использование нескольких интерконнектов может обеспечить более высокую пропускную способность между сегментами и отказоустойчивость системы (если отказывает одна сеть, нагрузка перераспределяется на доступные).
¶ 5. Описание компонент RT.WareHouse
¶ 5.1 Мастер
Мастер (основной мастер) — управляющий инстанс PostgreSQL в кластере. Мастер является точкой входа в систему базы данных RT.WareHouse. Он принимает клиентские соединения и обрабатывает команды SQL, которые передают ему пользователи системы. Пользователи подключаются к RT.WareHouse через мастера с помощью совместимой с PostgreSQL клиентской программы, например, psql или ODBC-совместимое приложение.
Мастер содержит системный каталог (набор системных таблиц, содержащих метаданные о самой системе RT.WareHouse), однако мастер не содержит никаких пользовательских данных. Данные хранятся только на сегментах. Мастер аутентифицирует клиентские соединения, обрабатывает входящие команды SQL, распределяет рабочую нагрузку между сегментами, координирует результаты, возвращаемые каждым сегментом, и представляет конечные результаты для клиентской программы.
Поскольку мастер не содержит никаких пользовательских данных, он имеет небольшую нагрузку на диск. При этом мастер нуждается в быстром, выделенном ЦПУ для загрузки данных, обработки соединений и планирования запросов.
¶ 5.2 Резервный мастер
При необходимости можно развернуть резервную копию (или зеркало) основного мастера. Резервный мастер находится в режиме ожидания и берёт на себя функции мастера в случае, если основной мастер становится неработоспособным. Резервный мастер можно развернуть на назначенном хосте или на одном из хостов сегмента.
Резервный мастер поддерживается в актуальном состоянии с помощью процесса репликации журнала транзакций, который выполняется на резервном мастере и синхронизирует данные между основным мастером и резервным мастером. Если основной мастер выходит из строя, процесс репликации журнала завершается, и администратор может активировать резервный мастер вместо него. Когда резервный мастер активен, реплицированные журналы используются для восстановления состояния основного мастера на момент последней успешно зафиксированной транзакции.
Поскольку мастер не содержит никаких пользовательских данных, необходимо синхронизировать только таблицы системного каталога между основной и резервной копиями. Когда эти таблицы обновятся, изменения автоматически будут скопированы на резервный мастер, поэтому он всегда синхронизирован с основным.
Рисунок 2— Синхронизация резервного мастера с основным
¶ 5.3 Сегмент
Сегменты хранят данные и обрабатывают большинство запросов. Пользовательские таблицы и их индексы распределяются по доступным сегментам в RT.WareHouse. Каждый сегмент содержит отдельную часть данных.
Сегменты — инстансы PostgreSQL. Пользователи не взаимодействуют напрямую с сегментами в RT.WareHouse, а делают это через мастера.
Количество инстансов сегментов на сегмент-хосте определяется потоков ЦПУ или доступной памятью. Количество сегментов на сегмент-хосте задаётся при инициализации базы и является очень важным параметром при работе RT.WareHouse.
¶ 5.4 Резервный сегмент
При инициализации базы данных RT.WareHouse можно настроить зеркальные сегменты, которые принимают на себя нагрузку в случае, если основной сегмент становится недоступен.
Зеркальный сегмент всегда должен находиться на другом хосте, нежели его основной сегмент.
Зеркальные сегменты могут быть расположены по хостам в системе в одной из двух стандартных конфигураций или в пользовательской конфигурации, которую вы создаёте.
Конфигурация по умолчанию, называемая групповым зеркалированием, размещает зеркальные сегменты для всех основных сегментов одного хоста на другом хосте. Ниже показана конфигурация группового зеркалирования.
Рисунок 3— Конфигурация группового зеркалирования
Другой вариант, называемый распределённым зеркалированием, распределяет зеркала для основных сегментов каждого хоста по остальным хостам. Распределённое зеркалирование требует, чтобы в системе было больше хостов, чем основных сегментов на хосте. На хостах с несколькими сетевыми интерфейсами основной и зеркальный сегменты равномерно распределяются между интерфейсами.
Рисунок 4— Конфигурация распределённого зеркалирования
¶ 5.5 Интерконнект
Интерконнект представляет собой сеть (или несколько сетей), предназначенную для взаимодействия мастера и сегментов между собой. Когда пользователь подключается к базе данных и запускает SQL-запрос, на каждом из сегментов создаются процессы для обработки данного запроса. Интерконнект является как связью сегментов внутри одного хоста, так и между сегментами на разных серверах.
В качестве интерконнекта крайне желательно использовать одно или несколько 10-гигабитных Ethernet-подключений. По умолчанию интерконнект базы данных RT.WareHouse использует протокол UDP (User Datagram Protocol) с управлением потока данных для отправки сообщений по сети. Программное обеспечение RT.WareHouse выполняет дополнительную проверку пакетов, не выполненную UDP, поэтому надёжность передачи эквивалентна TCP (Transmission Control Protocol), а производительность и масштабируемость значительно превосходят показатели TCP.
Резервность интерконнекта может быть достигнута путём развёртывания двух коммутаторов 10 Gigabit Ethernet на сети и дополнительным 10-гигабитным подключением к мастер-серверу и сегмент-серверам.
При использовании нескольких коммутаторов 10 Gigabit Ethernet в массиве базы данных RT.WareHouse равномерно разделяется количество подсетей между каждым коммутатором.
В этом примере конфигурации, если бы у нас было два коммутатора, NIC 1 и NIC 2 на каждом хосте использовали бы коммутатор 1, а NIC 3 и NIC 4 на каждом хосте использовали бы коммутатор 2. Для хоста мастера имя хоста, привязанное к NIC 1 (и, следовательно, с помощью коммутатора 1) — это эффективное имя хоста мастера для массива.
Таким образом, при развёртывании сервера резервного мастера для целей резервирования он должен отображаться на NIC, который использует другой коммутатор, чем основной мастер.
Рисунок 5— Настройка резервного интерконнекта