#greenplum

Сходства и различия популярных реляционных аналитических СУБД с открытым исходным кодом: что общего у Greenplum с ClickHouse, чем они отличаются, что и когда выбирать.Greenplum и Clickhouse: обзор возможностей для аналитики больших данныхОбе СУБД являются реляционными и относятся к классу OLAP-систем, т.е. ориентированы на аналитические варианты использования, т.е. чтение превалирует над записью. В OLAP-СУБД можно быстро записывать огромные объемы данных и считывать их. Однако, точечные изменения отдельных записей выполняются медленнее, чем в OLTP-системах. Поскольку OLAP-сценарии предусматривают соединения данных по очень большому количеству записей, колоночный способ хранения данных на диске предпочтителен для этих вариантов использования. Напомним, в СУБД, ориентированных на столбцы, данные хранятся на диске так, что каждый фрагмент данных представляет собой целый столбец. Поэтому все значения одного атрибута сущности будут сгруппированы вместе.Таким образом, Greenplum и ClickHouse имеют следующие сходства:- являются реляционными СУБД с открытым исходным кодом;- ориентированы на аналитику больших данных, т.е. аналитические сценарии (OLAP) чтения больших массивов информации;- поддерживают колоночный способ хранения данных;- имеют массивно-параллельную архитектуру (MPP, Massively Parallel Processing) без разделения ресурсов. Эта архитектура отлично подходит для OLAP-сценариев, поскольку аналитические СУБД работают с огромными объёмами данных, которые постоянно растут. Чтобы быстро и экономично горизонтально масштабировать такую систему, ее лучше проектировать как сеть независимых серверов. Скорость вычислений в MPP-системе прямо пропорциональна числу узлов в кластере. Также MPP-архитектура обеспечивает высокую отказоустойчивость: кластер БД отвечает на запросы даже при отказе некоторых узлов.Однако, при том, что Greenplum и ClickHouse обе являются реляционными MPP-СУБД, они существенно отличаются друг от друга. Например, в отличие от Greenplum, ClickHouse не поддерживает ACID-требования к транзакциям. Кроме того, ClickHouse не поддерживает ANSI SQL, который допускает произвольное неявное приведение между числовыми типами. А ClickHouse полагается на функции, имеющие несколько перегрузок вместо неявного приведения. Тем не менее, в официальной документации отмечено, что ClickHouse поддерживает декларативный SQL-подобный язык запросов, включая такие операторы, как GROUP BY, ORDER BY, подзапросы в разделах FROM, IN, JOIN, оконные функции и скалярные подзапросы. Зависимые подзапросы пока не поддерживаются. Greenplum же, буду основанной на PostgreSQL, полностью соответствует ACID-требованиям к транзакциям и поддерживает ANSI SQL.С архитектурной точки зрения один экземпляр ClickHouse на несколько серверов, к которым напрямую приходят запросы пользователей. Для репликации данных и выполнения распределённых SQL-запросов в ClickHouse используется сервис синхронизации метаданных ClickHouse Keeper, аналогичный по функция Apache Zookeeper, но написанный на C++.Greenplum представляет собой несколько экземпляров PostgreSQL, работающих как единая СУБД благодаря мастер-хосту, на котором развёрнут главный экземпляр PostgreSQL, называемый мастер-сегмент. Именно к мастер-сегменту подключаются пользователи и отправляют на него все SQL-запросы. Мастер-сегмент не содержит данных, а только принимает входящие подключения, собирает и систематизирует запросы, чтобы маршрутизировать их по сегментам, которые содержат фактические данные и выполняют запросы.Таким образом, централизованная архитектура Greenplum работает медленнее, чем ClickHouse, из-за промежуточной маршрутизации запросов с мастер-сегмента на сегменты с данными. Впрочем, это не единственная причина очень быстрой работы ClickHouse. Дополнительное ускорение получается за счет физической сортировки данных по первичному ключу и векторному движку обработки запросов, оптимизированному для современных ЦП, а также распределенной и параллельной обработки запросов.Данные в ClickHouse располагаются на разных сегментах, называемых шардами (shard). Шард – это группа копий данных (реплик) для обеспечения отказоустойчивости СУБД. SQL-запрос выполняется параллельно, т.е. одновременно на всех сегментах. Скорость работы ClickHouse на порядок выше, чем у Greenplum. Например, ClickHouse может обрабатывать до 1 миллиарда строк в секунду на одном сервере и до двух ТБ в секунду на кластере из 400 узлов. Примеры подобного тестирования производительности смотрите в нашей новой статье.Вспомнив ключевые характеристики и принципы работы Greenplum и ClickHouse, сравним их по ключевым критериям, оформив таблицу.Таким образом, архитектурные отличия рассмотренных СУБД обусловливают разные сценарии применения. Greenplum отлично работает в качестве корпоративного хранилища данных, позволяя оперативно загружать в него огромные объемы информации и анализировать их. Однако, эти SQL-запросы выполняются не настолько быстро, как в колоночной СУБД от Яндекса – ClickHouse, которая может обрабатывать несколько десятков ГБ в секунду. Поэтому эта СУБД отлично подходит для построения DWH, критичного к малейшим задержкам, обеспечивая аналитику больших данных в реальном времени.Освойте администрирование и эксплуатацию ClickHouse и Greenplum с Arenadata DB для аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:- Clickhouse как основа DWH- Greenplum для инженеров данных- Администрирование Greenplum / Arenadata DBИсточники1. https://arenadata.tech/about/blog/subd-dlya-analitiki-greenplum-ili-clickhouse/2. https://db-engines.com/en/system/ClickHouseGreenplum3. https://clickhouse.com/docs/ru/development/architecture

Что такое VMware Greenplum Command Center, как использовать этот инструмент для эффективного управления MPP-СУБД и чем он отличается от Arenadata Command Center для Arenadata DB.Что такое центр управления Greenplum от VMwareVMware Greenplum Command Center — это инструмент управления, который отслеживает показатели производительности системы, анализирует состояние кластера и позволяет администраторам баз данных выполнять задачи управления в среде VMware Greenplum. Этот центр управления предоставляет веб-GUI в виде встроенного в браузер графической консоли HTML5 для просмотра системных показателей Greenplum и выполнения определенных задач по администрированию, включая следующие функциональные возможности:- интерактивный обзор системных показателей в реальном времени и синхронизированные диаграммы истории;- подробная статистика в реальном времени по кластеру и по серверам;- мониторинг SQL-запросов (все выполняемые запросы, ожидающие выполнения и заблокированные блокировками, удерживаемыми другими запросами) с их метриками и планами выполнения;- управление рабочей нагрузкой, параллелизмом и распределением ресурсов ЦП и памяти;- управление разрешениями, чтобы просматривать или отменять свои или чужие SQL-запросы;- просмотр и редактирование файла конфигурации pg_hba.conf для аутентификации на основе хоста;- просмотр статуса любого сегмента со сводками и подробностями;- просмотр использования хранилища со сводными данными и подробностями по каталогу данных сегмента.Веб-сервер Greenplum Command Center и серверное приложение могут работать на хосте координатора или резервном хосте координатора, что более предпочтительно. Веб-сервер gpccws — это собственный HTTP-сервер, разработанный специально для Command Center. Веб-приложение написано на языке Go.Архитектура VMware Greenplum Command CenterВеб-сервер Command Center выполняет аутентификацию пользователей с помощью системы аутентификации VMware Greenplum. Администраторы Greenplum могут редактировать файл аутентификации на основе хоста pg_hba.conf в консоли центра управления или настроить аутентификацию пользователей в среде Kerberos.Command Center определяет четыре уровня авторизации пользователей для управления доступом пользователей к инструменту мониторинга SQL-запросов (Query Monitor), а также к административной информации и операциям. Авторизация пользователя осуществляется в административной области пользовательского веб-интерфейса командного центра.Центр управления отображает информацию, полученную из нескольких источников:- база данных мониторинга производительности VMware Greenplum (gpperfmon);- учет процессов операционной системы;- таблицы системного каталога VMware Greenplum;- расширение сбора метрик запросов в реальном времени;- расширение для управления рабочей нагрузкой.VMware Greenplum позволяет собирать показатели производительности и отслеживать выполнение SQL-запросов. Базу данных мониторинга производительности и расширение сбора метрик запросов развертывают агенты — процессы, выполняемые на каждом хосте для сбора метрик. Агенты gpperfmon пересылают собранные данные агенту координатора VMware Greenplum. Агенты метрик запросов в реальном времени отправляют собранные данные непосредственно в RPC-порт центра управления. Агенты также собирают данные из операционной системы хоста, чтобы можно было соотнести производительность SQL-запросов с использованием ЦП и памяти, а также отслеживать потребление дискового пространства в центре управления. Как это работает, рассмотрим далее.Особенности работы VMware Greenplum Command CenterКак уже было отмечено ранее, в базе данных мониторинга производительности gpperfmon хранятся текущие и исторические состояния запросов, а также системная информация, полученная от агентов, работающих на узлах координатора и сегмента. Центр управления Greenplum использует gpperfmon только для исторических данных вместе с актуальными метриками запросов в реальном времени. VMware Greenplum отправляет UDP-пакеты на различных этапах выполнения SQL-запроса. На каждом узле сегмента работает процесс gpsmon, который собирает данные и периодически, по умолчанию каждые 15 секунд, пересылает их gpmmon-агенту на узле-координаторе. Агент на хосте-координаторе получает данные и добавляет их в базу данных gpperfmon.База данных Командного центра состоит из трех наборов таблиц:- текущие данные (now) о текущих системных метриках, таких как активные запросы;- исторические таблицы (history) хранят данные об исторических показателях;- переходные таблицы (tail) предназначены для данных в процессе перехода. Эти таблицы предназначены только для внутреннего (системного) использования и не должны запрашиваться пользователями.Данные now и tail хранятся в виде текстовых файлов в файловой системе хоста координатора, а база данных командного центра получает к ним доступ через внешние таблицы. Таблицы истории — это обычные таблицы в базе данных gpperfmon, к которым можно выполнять SQL-запросы через центр управления Greenplum.Веб-интерфейс VMware Greenplum Command CenterЧтобы создать базу данных gpperfmon и включить агенты gpperfmon на узлах координатора и сегмента, в VMware Greenplum есть утилита управления gpperfmon_install. Однако, она доступна лишь в 6-ой версии MPP-СУБД и не доступна в VMware Greenplum 7. Также утилита gpperfmon_install не поддерживается в операционной системе Red Hat Linux 8.Данные, собранные с помощью сбора метрик запросов в реальном времени, являются более подробными и актуальными, чем статистика, записанная в базе данных gpperfmon. Благодаря актуальному мониторингу SQL-запросов пользователи центра управления Greenplum могут наблюдать за их выполнением и, при наличии достаточных разрешений, отменять проблемные запросы, чтобы позволить другим запросам завершиться.Расширение метрик запросов VMware Greenplum и агент сбора метрик работают вместе для сбора метрик в реальном времени и обновления приложения Command Center. VMware Greenplum вызывает расширение метрик запроса при первой отправке запроса, при изменении его статуса, а также при инициализации, запуске или завершении узла в его плане выполнения. Расширение метрик SQL-запроса отправляет метрики агенту сбора метрик, работающему на каждом узле сегмента. Расширение также собирает информацию об удержанных запросах блокировок, позволяя видеть, какие запросы содержат блокировки, блокирующие другие запросы. Агент отправляет метрики в RPC-порт центра управления Greenplum.Расширение metrics_collection входит в состав VMware Greenplum и включается в параметре gp_enable_query_metrics конфигурации сервера с перезапуском кластера. Агент сбора метрик устанавливается на каждый хост при установке Greenplum Command Center. Приложение Command Center контролирует агент и при необходимости перезапускает его.Рабочие нагрузки устанавливают ограничения на параллелизм, память и ресурсы ЦП для транзакций базы данных, которыми они управляют. Рабочая нагрузка Greenplum Command Center соответствует группе ресурсов VMware Greenplum, но добавляет дополнительные возможности, недоступные для групп ресурсов. В частности, центр управления предоставляет администраторам большую гибкость в назначении транзакций рабочим нагрузкам. Каждая роль VMware Greenplum назначается одной группе ресурсов, и по умолчанию транзакции управляются группой ресурсов этой роли. С помощью управления рабочей нагрузкой Command Center администраторы могут определять критерии назначения транзакций рабочим нагрузкам на основе атрибутов, отличных от роли, отправляющей транзакцию. В настоящее время критерии назначения могут оценивать теги и роли запроса в сочетании с тегами запроса.Тег запроса (query) — это пара ключ-значение, определенная в параметре сеанса базы данных gpcc.query_tags. Параметр имеет формат =;=, где теги и значения являются значениями, определяемыми пользователем. Например, если нужно запускать ETL-операции в рабочей нагрузке с названием etl, можно определить тег с названием xact-type и установить для него значение etl: xact-type=etl. Параметр gpcc.query_tags можно установить как параметр подключения на клиентах VMware Greenplum или с помощью команды SET внутри сеанса после установления соединения, например:SET gpcc.query_tags='xact-type=etl'Расширение gp_wlm обеспечивает поддержку рабочих нагрузок Command Center. Изначально VMware Greenplum использует очереди ресурсов для управления ресурсами. Для использования рабочих нагрузок Command Center необходимо включить группы ресурсов в VMware Greenplum. Группы ресурсов основаны на службе контрольных групп управления Linux (cgroups), которую сначала необходимо включить в операционной системе.Контрольная группа cgroups – это группа процессов в Linux, для которой механизмами ядра наложена изоляция и установлены ограничения на некоторые вычислительные ресурсы (ЦП, сеть, память, дисковый ввод-вывод). Механизм позволяет образовывать иерархические группы процессов с заданными ресурсными свойствами и обеспечивает программное управление ими.В заключение рассмотрим сходства и различия VMware Greenplum Command Center с Arenadata Command Center (ADCC) для Arenadata DB – MPP-СУБД от российского вендора, основанная на Greenplum. Как и центр управления Greenplum от VMware, ADCC предназначена для мониторинга состояния СУБД. Однако, в ADCC для хранения метрик используется отдельная база данных и нет привязки к кластеру при обработке метрик, благодаря чему можно наблюдать в одном веб-интерфейсе несколько кластеров Arenadata DB. Кроме того, ADCC поддерживает горизонтальное масштабирование сервера по обработке метрик.Освойте администрирование и эксплуатацию Greenplum с Arenadata DB для эффективного хранения и аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:- Greenplum для инженеров данных- Администрирование Greenplum / Arenadata DBИсточники1. https://docs.vmware.com/en/VMware-Greenplum-Command-Center/7.0/greenplum-command-center/topics-overview.html2. https://habr.com/ru/companies/arenadata/articles/564552/