Еще совсем недавно российские компании обычно рассматривали миграцию на отечественные продукты категории Open Source, когда требовалось оптимизировать совокупную стоимость владения (ТСО); снизить влияние привязанности к конкретному вендору (vendor lock-in) и уменьшить санкционные риски. Уход зарубежных вендоров и, как следствие, прекращение поддержки российских заказчиков заставили отечественный бизнес и госсектор сформулировать совершенно иные запросы. Так, при переходе с зарубежных СУБД вскрылись следующие проблемы:

  • необходимы решения, зарегистрированные в Едином реестре российских программ для электронных вычислительных машин и баз данных Минцифры РФ;
  • переходить куда-то страшно, так как эффективность решений не ясна и в устоявшемся коллективе нет специалистов с соответствующим опытом;
  • нет прозрачных гарантий безопасности кодовой базы приобретаемых решений;
  • SLA (Service Level Agreement — «соглашение об уровне обслуживания»), предлагаемое отечественными вендорами, не соответствуют западным SLA, к которым привык бизнес.

Анализ ситуации в рамках опроса, проведенного на конференции Arenadata «Большие данные большой страны», показал — более половины представителей российских коммерческих компаний и госсектора, комментируя ожидания от отечественных ИТ-продуктов, заявили, что им не хватает обучающих курсов от вендоров. Почти 40% респондентов считают, что разработчики должны предоставлять бизнес-ориентированный технический пресейл, а 30% ждут, что вендоры будут доносить до них преимущества своих продуктов, учитывая особенности конкретной индустрии, в которой работает заказчик. Около 30% опрошенных наиболее важным для себя считают наличие у разработчика сервисных менеджеров технической поддержки. Адекватно ответить на подобные пожелания может только отечественный производитель, имеющий пул надежных, проверенных временем и множеством инсталляций продуктов. Один из таких вендоров — компания Arenadata, предлагающая аналитическую, распределенную MPP-СУБД (Massively Parallel Processing) Arenadata DB (ADB) с открытым исходным кодом, построенную на основе СУБД Greenplum и включенную в Единый реестр российского ПО.

Назначение и задачи

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

Рис. 1. Архитектура СУБД Arenadata DB. Seg_N — сегмент, Mir_N — зеркальный сегмент

Сфера применения Arenadata DB:

  • аналитические корпоративные хранилища данных;
  • ложные запросы к большим объемам данных, в том числе содержащие сложные аналитические функции;
  • ETL/ELT;
  • объединение больших таблиц;
  • Data Science;
  • выполнение аналитических функций на процедурных языках;
  • аналитика решения конкретных разовых задач (Ad-hoc).

Большинство пользователей СУБД ADB наблюдает сегодня рост объемов своих корпоративных хранилищ данных, поэтому им требуются высокая скорость обработки, возможность горизонтального масштабирования без привязки к конкретному аппаратному обеспечению, а также отказоустойчивость. Кроме этого, им важна уверенность в отсутствии «закладок» в открытом коде ПО; доступ к опыту использования продукта в других организациях, а также к экспертизе вендора и наличие у него команды работы с клиентами (customer success team): архитекторы, инженеры, аналитики, руководители проектов и т. д. Вполне очевидно, что сейчас для заказчиков требуются доступ к опыту миграции с других решений, поддержка в режиме 24/7 со строгим SLA и возможность индивидуальных доработок под свои задачи.

Компания Arenadata строит все свои продукты на базе открытого кода, причем речь идет не только о технологии — это еще и партнерские отношения с сообществом [1]. Сегодня Arenadata — один из ключевых разработчиков Greenplum в России.

Почему именно Greenplum? По сравнению с универсальными СУБД эта технология предоставляет пользователю многочисленные преимущества: возможность работы с данными из нескольких источников при минимальной предварительной обработке; изоляция процессов разных потребителей друг от друга путем разграничения между ними ресурсов кластера. Кроме этого Greenplum поддерживает реляционную модель данных, интегрируется с СУБД PostgreSQL и другими реляционными решениями. Благодаря MPP-архитектуре эта СУБД способна быстро обрабатывать сложные аналитические запросы. Используемая в Greenplum технология предоставляет федеративный доступ к данным в смежных системах через параллельный интерфейс.

Стоит заметить, что иногда российские предприятия начинают задумываться о развитии собственной разработки на базе Greenplum (своего «ванильного» решения), но обычно вскоре приходит понимание, что растить в себе вендора — долго и дорого. Для этого потребуется накопить ту же экспертизу, которой уже обладают отечественные вендоры, прошедшие все подводные камни и создавшие сообщество заказчиков вокруг своей технологии.

Отличительные особенности ADB

Arenadata DB реализована на кластере из сотен серверов и равномерно распределяет нагрузку и данные между ними, поэтому здесь требуются особые решения организации работы с данными.

Полиморфное хранение. Данные, которые устарели и к которым редко обращаются («холодные»), обычно архивируются и помещаются в долгосрочные хранилища, такие как озеро данных на базе Arenadata Hadoop или хранилище объектов S3. Свежие, часто запрашиваемые данные («горячие») хранятся в оперативных базах данных, а данные, требующие небольшой оперативной и большей аналитической нагрузки, сохраняются в базе данных Arenadata DB («теплые»). Возможности полиморфного хранилища Arenadata DB при использовании протокола параллельного обмена данными со сторонними системами — PXF (Platform eXtension Framework) делают запросы к данным в разных температурных слоях простыми и эффективными.

Резервное копирование. Гибкая система резервирования позволяет установить и настроить кластер с заранее заданным уровнем отказоустойчивости — СУБД ADB продолжит работать даже при выходе из строя до половины серверов кластера. Большой выбор стратегий резервирования обеспечивает необходимую производительность и надежность хранения данных. Ключевые возможности создания и хранения резервных копий: параллельное выполнение создания резервных копий; сжатие резервных копий; наличие утилит с разными принципами работы (логические и бинарные бэкапы); инкрементальное копирование по разделам базы данных; поддержка бинарных бэкапов; возможность резервного копирования в облако S3.

Одно из важнейших требований к аналитической СУБД — обеспечение гибкости и производительности при обмене данными с внешними системами: другие СУБД, объектные хранилища, инструменты ETL и пр. В ADB реализован протокол PXF, обеспечивающий одновременное взаимодействие всех сегментов кластера с внешней системой. Если система-источник также представляет собой кластер, то можно использовать кластерное взаимодействие с обеих сторон, что позволяет повысить производительность, причем скорость взаимодействия будет расти по мере расширения кластеров. В ADB поддерживается интеграция с Oracle, PostgreSQL, Microsoft SQL Server, My SQL, MongoDB, SAP HANA и др., а также с решениями класса Hadoop (HDFS, Hive, Hbase), S3 (рис. 2).

Рис. 2. Интеграция ADB с внешними источниками данных

Примеры

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

Увеличение производительности хранилища

Задача. Проблема с производительностью хранилища данных и отчетности, построенной на базе классических реляционных СУБД (Oracle DB, Microsoft SQL Server, PostgreSQL).

Предпосылки: большой размер хранилища данных (от 1 Тбайт) и непрерывной рост его объема; большое время загрузки данных (ETL), исключающее попадание в рамки технологического окна; рост количества отчетов и требований к оперативности; необходимость частой миграции на более мощный сервер для обеспечения роста объемов данных и нивелирования падения производительности.

Решение. Ускорение обработки запросов — в MPP СУБД задачи распределяются по многим узлам и выполняются параллельно. Повышение скорости загрузки данных (ETL) — параллельная загрузка на множество серверов позволяет в разы ускорить процессы загрузки. Масштабирование хранилища — близкий к линейному рост производительности при добавлении в кластер новых серверов.

Уменьшение сложности администрирования озера данных

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

Предпосылки: высокие требования к квалификации администраторов Hadoop; отсутствие на рынке квалифицированных специалистов.

Hadoop — не монолитное решение, а сложная экосистема, состоящая из большого количества продуктов.

Решение. В случае использования Hadoop в качестве аналитического хранилища структурированных данных для OLAP-нагрузки можно добиться снижения сложности эксплуатации озера данных путем миграции на ADB — монолитное решение, в котором отсутствует сопряжение десятков компонентов. Решение построено на базе PostgreSQL, что снижает порог вхождения сотрудников в технологию, предоставляя аналитикам и разработчикам привычные им инструменты. Этого нельзя сказать про ПО из экосистемы Hadoop.

Импортозамещение для хранилища

Задача. Переход на отечественное ПО согласно требованиям регулятора, отсутствие поддержки и развития платформ от западных вендоров.

Предпосылки: санкции и уход западных вендоров из России; юридические проблемы с закупками иностранного ПО (ФЗ-44, ФЗ-223); «Закон о персональных данных» (ФЗ-152); техническое сопровождение только на иностранном языке.

Решение. ADB позволяет решить задачу импортозамещения для аналитических систем: включение в Единый реестр российских программ; локализация (российским пользователям предлагается поддержка на русском языке, с полным набором возможностей по автоматическому развертыванию в облаке и on-premise, детальная документация на русском языке, авторские обучающие курсы с сертификацией специалистов, техническая поддержка 24/7).

***

СУБД Arenadata DB позволяет построить отказоустойчивое, масштабируемое корпоративное хранилище больших данных, отвечающее растущим запросам пользователей. Помимо создания корпоративного хранилища, эта распределенная СУБД может применяться и для поддержки решения аналитических задач, выполнения запросов Ad-hoc и исследования данных.

Литература

Дмитрий Волков. Платформа цифровой эпохи // Открытые системы.СУБД. — 2017. — № 3. — С. 38–41. URL: https://www.osp.ru/os/2017/03/13052704 (дата обращения: 21.06.2023).

Антон Коваленко (kovalenko@arenadata.io) – руководитель направления продуктового маркетинга Arenadata (Москва).