Открытая аналитическая СУБД¶

Arenadata DB (ADB) – распределенная СУБД, использующая концепцию MPP (massively parallel processing, массивно-параллельные вычисления) и основанная на СУБД с открытым исходным кодом – Greenplum.

Аналитические массивно-параллельные СУБД предназначены для хранения и обработки больших объемов данных – от единиц до сотен терабайт данных. Такие СУБД чаще всего используются для предиктивной аналитики, регулярной отчетности, анализа оттока клиентов, построения корпоративных хранилищ данных.

До недавнего времени рынок аналитических массивно-параллельных СУБД делили между собой четыре игрока (Vertica, Teradata, Netezza и Greenplum), существовавшие вне сообщества Open Source, однако ситуация изменилась в 2017 году, когда проект Greenplum перешел в категорию открытых.

Открытие исходного кода позволило команде Arenadata начать проект Arenadata DB (ADB) – реляционная СУБД, имеющая массово-параллельную архитектуру без разделения ресурсов (Shared Nothing) и предназначенную для хранения, обработки и анализа больших объемов структурированных и слабоструктурированных данных. Используя вычислительную мощность сотен серверов, продвинутый оптимизатор запросов и гибкую систему резервирования данных, ADB позволяет существенно повысить производительность и надежность, сохраняя унаследованным приложениям ANSI SQL (полностью совместимый с PostgreSQL) доступ к данным.

Рис. 2. Консоль администратора ADB

Архитектура ADB – классический кластер: несколько серверов-сегментов, один сервер-мастер и один резервный, соединенные между собой быстрыми сетями (10G Ethernet или Infiniband). В каждом сервер-сегменте есть несколько сегментов (инстансов) PostgreSQL, содержащих данные. В случае отказа одного или нескольких сегментов они помечаются как сбойные и вместо них запускаются их зеркальные сегменты, репликация данных для которых происходит с помощью используемой в СУБД PostgreSQL технологии опережающей записи (Wright Ahead Log, WAL – все изменения таблиц и индексов записываются в файл только после их занесения в журнал).

Рис. 3. Архитектура ADB. Seg_N – сегмент, Mir_N – зеркальный сегмент

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

В ADB реализуется классическая схема разделения (шардирования) данных – каждая таблица состоит из N таблиц, размещаемых на N сегментах кластера. Логика разбиения таблицы на сегменты задается ключом (полем) дистрибуции. Для каждой отдельной колонки в таблице можно задать свой тип и уровень сжатия. Помимо изначально доступных в Greenplum типов компрессии – zlib (одна из самых широко используемых библиотек сжатия, в частности, используется в дистрибутивах Linux) и RLE delta compression (хранение изменений между значениями полей в колонке) – в ADB доступен алгоритм zstandard, разработанный компанией Facebook и имплементированный командой Arenadata, который обеспечивает почти в четыре раза более высокую производительность по сравнению с zlib.

В ADB используется полиморфное хранение данных, например, одну таблицу можно разделить на вертикальные разделы (партиции), часть из которых будет храниться в виде строк, а часть – как колоночные объекты. При этом для пользователя такая таблица будет выглядеть одним объектом.

Рис. 4. Управление распределением данных в ADB

Безопасность в ADB достигается путем шифрования данных и соединений сервер-клиент по протоколу SSL на всех этапах их жизненного цикла. Кроме этого все внутренние взаимодействия компонентов СУБД ADB (сегменты, зеркала и мастера) также могут быть зашифрованы с помощью протокола SSL, а данные, хранящиеся на дисках кластера, могут быть зашифрованы с помощью ключей PGP (на уровне таблиц или колонок в таблицах). Все это позволяет исключить ситуации нахождения данных в незашифрованном виде.

Разграничения зон видимости данных и прав доступа обеспечивается благодаря ролевой модели доступа (Role Based Access Control, RBAC), позволяющей реализовать гибкие, изменяющиеся динамически в процессе функционирования платформы хранения и обработки данных правила разграничения доступа. Так, например, можно создать схемы ограничения доступа к таблицам и другим объектам СУБД, а также к строкам и столбцам отдельных таблиц.

Одно из важнейших качеств аналитической СУБД – гибкость и производительность при обмене данными с внешними системами. В частности, в ADB реализован протокол параллельного обмена данных со сторонними системами – PXF (Platform eXtension Framework), который обеспечивает взаимодействие с внешней системой одновременно всех сегментов кластера. Если система-источник также представляет собой кластер, то можно использовать кластерное взаимодействие с обеих сторон, что позволяет повысить производительность, причем скорость взаимодействия будет расти по мере расширения кластеров.

Гибкая система резервирования позволяет развернуть кластер с заранее заданным уровнем отказоустойчивости, позволяя СУБД работать даже при выходе из строя половины серверов из кластера. А больший выбор стратегий хранения данных в ADB обеспечивает необходимую производительность на всех этапах жизненного цикла данных – от получения новых онлайн-данных, хранения основных данных с разным уровнем компрессии до экспорта архивных данных в кластер Hadoop.

Рис. 5. Мониторинг в ADB

Ключевые преимущества ADB:

Вся поддержка и экспертиза по внедрению доступна в России и на русском языке;
Разработан пакет утилит для оффлайн-установки (без доступа к сети Интернет);
Дистрибутив создан на базе Open-source ядра СУБД Greenplum;
Полностью российское программное обеспечение;
Поддержка доступна как удаленно, так и на месте (on-site). Есть набор доступных пакетных сервисов по планированию, установке, аудиту системы;
Есть возможность доработки и кастомизации продукта под конкретные потребности заказчика;
Доступна реализация как на “голом железе”, так и в облаке.

Возможности интеграции ADB с другими системами позволяют использовать эту СУБД для построения универсальных платформ хранения и обработки данных, таких, как Arenadata Enterprise Data Platfrom (Arenadata EDP) – открытое горизонтально масштабируемое решение для хранения и обработки больших объемов данных любых типов.

Рис. 6. Arenadata Enterprise Data Platfrom

Для эффективного использования СУБД необходимы средства управления и мониторинга – в ADB имеется пакет средств администратора: ПО мониторинга, управления СУБД и отправки уведомлений.

Высокая скорость обработки сложных запросов, линейное масштабирование, отсутствие специфических требований к аппаратному обеспечению, открытый исходный код, гибкость интеграции – вполне позволяют применять Arenadata DB в качестве аналитического хранилища данных корпоративных информационных систем, что по достоинству оценили как компании, близкие к ИТ-бизнесу (телеком, e-commerence, финтех), так и более традиционные отрасли (нефтегазовая и металлургическая промышленности).

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

Оглавление: