Аналитические массивно-параллельные СУБД предназначены для хранения и обработки больших объемов данных, исчисляемых сотнями терабайт, и обычно используются в приложениях прогнозной аналитики, для формирования регулярной отчетности, анализа оттока клиентов и построения корпоративных хранилищ. Для построения корпоративных хранилищ и систем анализа больших данных давно используется СУБД Greenplum Database — это решение взяли на вооружение NYSE, NASDAQ, Boeing, At&T, Sony и еще около тысячи компаний, включая «Тинькофф», Sberbank CIB и «Ростелеком». Однако обычно речь шла о закрытых коммерческих решениях для состоятельных корпоративных заказчиков.
Открытие исходного кода GPDB запустило процесс демократизации аналитических массивно-параллельных СУБД. В частности, это позволило компании Arenadata начать открытый проект Arenadata DB (ADB) по созданию реляционной СУБД с массово-параллельной архитектурой без разделения ресурсов (Shared Nothing), предназначенной для хранения, обработки и анализа больших объемов структурированных и слабоструктурированных данных. Используя вычислительную мощность сотен серверов, усовершенствованный оптимизатор запросов и гибкую систему резервирования данных, ADB позволяет повысить производительность и надежность обработки, сохраняя унаследованным приложениям ANSI SQL, в частности полностью поддерживаемым в СУБД PostgreSQL, доступ к данным.
Архитектура ADB представляет собой классический кластер: несколько серверов-сегментов, один сервер-мастер и один резервный, соединенные между собой быстрыми (10-Gigabit Ethernet или Infiniband) сетями (рис. 1). Каждый сервер-сегмент содержит несколько сегментов («инстансов») PostgreSQL, содержащих данные. В случае отказа одного или нескольких сегментов они помечаются как сбойные и вместо них запускаются их зеркальные сегменты, репликация данных для которых происходит с помощью используемой в СУБД PostgreSQL технологии опережающей записи (Wright Ahead Log, WAL — все изменения таблиц и индексов записываются в файл только после их занесения в журнал).
.jpg) |
| Рис.1. Архитектура ADB |
Использование нескольких интерконнектов позволяет повысить пропускную способность канала взаимодействия сегментов между собой и обеспечить отказоустойчивость кластера за счет перераспределения трафика. Распределение сегментов по сетевым интерфейсам выбирается индивидуально и может подстраиваться под задачи кластера: например, все основные сегменты можно заставить использовать один сетевой интерфейс, а резервные сегменты будут использовать второй.
В ADB реализуется классическая схема разделения («шардирования») данных — каждая таблица состоит из N таблиц, размещаемых на N сегментах кластера. Логика разбиения таблицы на сегменты задается ключом (полем) дистрибуции. Для каждой отдельной колонки в таблице можно задать свой тип и уровень сжатия. Помимо изначально доступных в Greenplum типов компрессии — zlib (одна из наиболее популярных библиотек сжатия) и RLE delta compression (хранение изменений между значениями полей в колонке), в ADB доступен алгоритм zstandard, разработанный компанией Facebook и обеспечивающий вчетверо более высокую производительность по сравнению с zlib.
В ADB используется полиморфное хранение данных: например, одну таблицу можно разделить на вертикальные разделы (партиции), часть из которых будет храниться в виде строк, а часть — как колоночные объекты. При этом для пользователя такая таблица будет выглядеть одним объектом.
Безопасность в ADB достигается путем шифрования данных и соединений сервер-клиент по протоколу SSL на всех этапах их жизненного цикла. Кроме того, все внутренние взаимодействия компонентов СУБД ADB (сегменты, зеркала и мастера) также могут быть зашифрованы с помощью протокола SSL, а данные, хранящиеся на дисках кластера, могут быть зашифрованы с помощью ключей PGP (на уровне таблиц или колонок в таблицах). Все это позволяет исключить ситуации, когда данные находятся в незашифрованном виде.
Разграничение зон видимости данных и прав доступа обеспечивается благодаря ролевой модели доступа (Role Based Access Control, RBAC), позволяющей реализовать правила, динамически меняющиеся в процессе функционирования платформы хранения и обработки данных. Так, например, можно создать схемы ограничения доступа к таблицам и другим объектам СУБД, а также к строкам и столбцам отдельных таблиц.
Одно из важнейших качеств аналитической СУБД — гибкость и производительность при обмене данными с внешними системами. В частности, в ADB реализован протокол параллельного обмена данными со сторонними системами — PXF (Platform eXtension Framework), который обеспечивает взаимодействие с внешней системой одновременно всех сегментов кластера. Если система-источник также представляет собой кластер, то можно использовать кластерное взаимодействие с обеих сторон, что позволяет повысить производительность, причем скорость взаимодействия будет расти по мере расширения кластеров.
Возможности интеграции ADB с другими системами позволяют использовать эту СУБД для построения универсальных платформ хранения и обработки данных, таких, например, как Arenadata UDP — открытое горизонтально масштабируемое решение для хранения и обработки больших объемов данных любых типов. Платформа работает с нагрузками оперативной обработки транзакций (OLTP) и оперативной аналитической обработки (OLAP), поддерживает доступ к данным на языке SQL и работу с библиотеками на Python.
Платформа Arenadata UDP состоит из трех кластеров, тесно связанных между собой с помощью фреймворка параллельного доступа: Arenadata Hadoop, ADB и Arenadata In-memory Grid (рис. 2). В СУБД ADB создаются таблицы, источниками данных для которых служат как данные из самой СУБД, так и данные из HDFS-кластера Hadoop и из оперативной памяти кластера In-memory Grid. Для управления внутренними процессами и процессами загрузки данных используется Nifi — открытый процессор ETL/ELT, а для доступа к пользовательским данным и их аналитической обработки — Apache Zeppelin.
.jpg) |
| Рис. 2. Универсальная платформа данных |
Поскольку для эффективного использования СУБД необходимы возможности управления и мониторинга, в ADB имеется пакет средств администратора — ПО мониторинга, управления СУБД и отправки уведомлений.
***
Высокая скорость обработки сложных запросов, линейное масштабирование, отсутствие специфических требований к аппаратному обеспечению, открытый исходный код, гибкость интеграции позволяют применять ADB в качестве аналитического хранилища данных для корпоративных информационных систем, что уже оценили некоторые российские предприятия, работающие в области телекоммуникаций, электронной коммерции, финтеха, добычи полезных ископаемых и металлургии.
Дмитрий Павлов (d@arenadata.io) — руководитель направления, компания IBS (Москва).
