какие задачи в субд greenplum решает мастер
Какие задачи в субд greenplum решает мастер
Greenplum – open-source продукт, массивно-параллельная реляционная СУБД для хранилищ данных с гибкой горизонтальной масштабируемостью и столбцовым хранением данных на основе PostgreSQL. Благодаря своим архитектурным особенностям и мощному оптимизатору запросов, Гринплам отличается особой надежностью и высокой скоростью обработки SQL-запросов над большими объемами данных, поэтому эта MPP-СУБД широко применяется для аналитики Big Data в промышленных масштабах [1].
История разработки и развития
Отметим наиболее значимые вехи развития проекта Greenplum [2]:
Как устроена Greenplum: архитектура и принципы работы
СУБД Greenplum представляет собой несколько взаимосвязанных экземпляров базы данных PostgreSQL, объединенных в кластер по принципу массивно-параллельной архитектуры (Massive Parallel Processing, MPP) без разделения ресурсов (Shared Nothing). При этом каждый узел кластера, взаимодействующий с другими для выполнения вычислительных операций, имеет собственную память, операционную систему и жесткие диски.
Для повышения надежности к типовой топологии master-slave добавлен резервный главный сервер. Так в состав кластера Greenplum входят следующие компоненты [1]:
Мастер взаимодействует с сегментами Гринплам следующим образом [1]:
Подробнее архитектуру Greenplum и основные принципы работы этой MPP-СУБД мы рассматриваем здесь. Зеркалирование сегментов обусловливает повышенную надежность, однако приводит к избыточному потреблению ресурсов и удорожанию кластера. О других достоинствах и недостатках Гринплам читайте в нашей отдельной статье. А подробно, чем Greenplum отличается от PostgreSQL, мы рассказываем в этом материале.
Основные сценария использования в Big Data и примеры внедрения
Благодаря надежности, масштабируемости и высокой скорости обработки данных, наиболее востребованными сценариями применения Гринплам в Big Data считаются следующие:
Массивно-параллельная база данных Greenplum — короткий ликбез
Для Hadoop и Greenplum есть возможность получить готовый SaaS. И если Хадуп — известная штука, то Greenplum (он лежит в основе продукта АrenadataDB, про который далее пойдёт речь) — интересная, но уже менее «на слуху».
Arenadata DB — это распределённая СУБД на базе опенсорсного Greenplum. Как и у других решений MPP (параллельной обработки данных), для массивно-параллельных систем архитектура облака далека от оптимальной. Это может снижать производительность аж до 30 % (обычно меньше). Но, тем не менее, эту проблему можно нивелировать (о чём речь пойдёт ниже). Кроме того, стоит покупать такую услугу из облака, часто это удобно и выгодно в сравнении с развёртыванием собственного кластера.
В гайдах явно указывается on-premise, но сейчас многие осознают масштаб удобства облака. Все понимают, что некая деградация производительности будет, но это настолько всё равно супер по удобству и скорости, что уже есть проекты, где этим жертвуют на каких-то этапах вроде проверки гипотез.
Если у вас есть хранилище данных больше 1 ТБ и транзакционные системы — не ваш профиль по нагрузке, то ниже — рассказ, что можно сделать как вариант. Почему 1 ТБ? Начиная с этого объёма использование MPP эффективнее по соотношению производительность/стоимость, если сравнивать с классическими СУБД.
Когда использовать?
Когда классическая single-node СУБД по архитектуре не подходит для ваших объёмов. Частый случай — новое хранилище данных объёмом больше 1 ТБ. MPP СУБД сейчас в тренде, и Greenplum — один из лучших на рынке по соответствию современным задачам. Особенно с учётом его опенсорсности. Есть ещё куча проприетарных систем с большим количеством фич из коробки: Террадата, Сап Хана, Экзадата, Вертика. Поэтому, если вы не можете позволить себе ананасов и рябчиков, то берите сливу.
Второй случай — когда у вас есть уже существующее хранилище данных на чём-то универсальном типа Оракла или Постгресса, но пользователи регулярно жалуются на медленные отчёты. И когда стоят новые задачи типа Big Data — когда пользователи хотят все данные и сразу, а что они с ними будут делать, они предсказать не могут. Есть много ситуаций, когда на действующем бизнесе нужны отчёты, которые актуальны только один день, а за сутки они не успевают рассчитаться. То есть нужных данных в принципе нет. В этом случае тоже удобно брать базы MPP и пробовать с SaaS в облаке.
Третий случай — когда у вас кто-то следует моде на Хадуп и решает стандартные задачи пакетной обработки структурированных данных, но не очень хорошо собрал кластер. Мы часто видим, что технология применяется немного и даже совсем не так, как должна. Например, на Хадупе не надо строить реляционную базу данных. Тем не менее, если в вашем Хадупе вдруг нет обработки в реальном времени либо она предполагалась, но админ и разработчик в ужасе сбежали, то тоже можно смотреть в сторону Greenplum в облаке: поддержка будет очень простой при сохранении возможности обработки огромных массивов данных.
Почему мало кто пробует?
Любые MPP СУБД требуют много мощностей. То есть много железа. По факту люди боятся пробовать до уровня proof of concept просто из-за цены входа. Не могут этого физически сделать. Одна из основных идей нашего SaaS — дать возможность поиграть со всем этим, не покупая кластер железа.
И регулярно встречаем заказчиков, которые говорят, что самостоятельно сопровождать, эксплуатировать и так далее не хотелось бы. А хотелось бы аутсорс. Это система аналитическая, и чаще всего она business-critical, но не mission-critical. Многие на Западе аутсорсят, у нас тоже началось недавно.
Что лучше всего делать на MPP?
Классическое корпоративное хранилище данных: по всем источникам данных вы получаете инкрементальные данные, а дальше из этого строятся витрины пользователям. Пользователи над этими витринами строят свои отчёты. «Я каждый день хочу видеть, как идут дела в бизнесе» — это оно.
Ещё пара слов про облачное решение
Раньше считалось, что инфраструктуры подобного плана слабо предназначены для облаков. Но на деле всё больше и больше заказчиков выходят в облака. Работа требует высокой производительности, так как в ней крутится очень много больших аналитических запросов, которые потребляют много ЦПУ, требуют много памяти и предъявляют высокие требования к дискам и сетевой инфраструктуре. Как результат, когда клиенты разворачивают распределённые СУДБ в облаке, они могут столкнуться с несколькими проблемами.
Первая — это недостаточная производительность сети. Так как это всё в облаке крутится в виртуальной среде, на одном гипервизоре может быть много машин. Виртуальные машины могут быть разбросаны по разным гипервизорам. Более того, в какие-то моменты они могут быть вообще разбросаны по разным дата-центрам, супервизоры на них могут крутиться виртуально. И из-за этого очень сильно страдает сеть. При переработке миллиарда записей в таблице нужно, скажем, 10 серверов, и он гоняет эти данные между всеми серверами. Внутри работает подвид, и даже внутри одного сервера работает много таких подвидов. Их может быть 10–20, и вот они все начинают во время выполнения запроса гонять данные по сети. Сеть падает, как озимые. Какой вывод из этого можно сделать? Используйте облака с высокой пропускной способностью каналов, например, Облако КРОК, которое на Infiniband даёт 56 Гб.
Вторая проблема — на всё это очень косо смотрят файрволы и DDoS-защиты. Накололись, решили. Перед использованием рекомендуем запланировать лишний час на перепроверку всех настроек.
Ещё важны незаметная живая миграция и обновление. Чтобы перетащить машину на другой гипервизор, а потом обратно, нужно не потерять пакеты. Необходимо шаманить с настройками в итоге. К примеру, мы почти сразу полезли за увеличением буфера обмена. MTU подняли до «джамбофрейма» 9 000.
Конечно, диски, которые HDD. Они очень не любят такую запись, особенно когда это очень-очень случайные сектора в очереди с остальными запросами. Решили разделением хранилища на сегменты: один — только для Greenplum, другой — общий. Нужно это для ситуаций, когда с десяток заказчиков разворачивает параллельно инсталляции Greenplum. MPP максимально утилизируют именно дисковую подсистему, облачные сервисы имеют интерконнект к хранилищу, и производительность там почти такая же, как у канала. Если все клиенты облака не делают расчёт MPP, то можно получить очень существенный выигрыш. Эффективное распределение мощностей в таких нагрузках очень хорошо работает.
И из-за собственной архитектуры Greenplum в облаке показывает себя по КПД лучше, чем Redshift, BigQuery и Snowflake.
Как выглядит развёртывание:
Архитектура «дышащая», то есть можно быстро развернуть простым множителем в конфигурации. Как пример — днём у нас работает пять ЦПУ, а вечером у нас поднимается 1 000 обработчиков, и работает десять ЦПУ. При этом не нужно делать баланс данных, потому что они лежат внутри одного хранилища. Из коробки доступно расширение, быстрое сжатие ещё нужно немного допиливать.
Сейчас для заказчика есть единая точка управления. Он приходит в одно место, кидает туда запрос вроде: «Разверните мне кластерный план на таких-то машинах», и наша поддержка развёртывает машины в облаке (у нас или у заказчика), располагает там Greenplum, запускает, настраивает и все настройки делает. То же самое касается мониторинга, управления, обновления. По мере автоматизации это будет уходить с поддержки на кнопки в личном кабинете.
Мы сначала поняли всё удобство такого подхода на внутренних проектах, а потом начали давать как SaaS заказчикам. У нас глубокая интеграция с S3 — это позволяет использовать Greenplum как систему с разделёнными слоями вычисления и хранения, или использовать S3 для бекапов, а Greenplum как ядро в составе КХД в облаке. Есть гибкое развёртывание сред для enterprise с помощью API КРОК и API ADCM.
Greenplum 5: первые шаги в Open Source
Вот уже два года как одна из лучших распределённых аналитических СУБД enterprise-уровня вышла в open source. Что изменилось за это время? Что дало открытие исходников проекту? Как дальше будет развиваться Greenplum?
Под катом я расскажу о том, что нового появилось в первом мажорном open source релизе СУБД, как развивается проект в текущих минорных версиях и каких нововведений стоит ждать в будущем.
Если вы ещё не знакомы с СУБД Greenplum, начать своё знакомство можно с этой обзорной статьи.
Релиз 5.0.0 состоялся 7-го сентября. Это первый релиз, который включает в себя доработки, внесённые сторонними разработчиками (community). Релизы версии 4.3, хотя и выкладывались в открытый репозиторий, разрабатывались только специалистами Pivotal.
Релиз принёс много нововведений, как мне кажется, основная причина этого в том, что пользователи, работающие с Greenplum достаточно давно, наконец-то получили возможность реализовать все свои хотелки, которые компания Pivotal не могла реализовать и которые копились так долго. Я приведу краткое описание, на мой взгляд, самых важных изменений в новом мажорном релизе и в последующих минорных апдейтах, так как изменений слишком много для того, чтобы рассказать про все. В конце статьи я приведу ссылки на Release Notes нового релиза и его минорных апдейтов.
Условно все нововведения можно разделить на три группы:
1. Новые возможности, портированные из свежих версий PostgreSQL
Это нововведение было перетянуто из PostgreSQL без изменений. Не самая важная (блок кода всегда можно было обернуть в функцию), но так давно ожидаемая администраторами и разработчиками доработка.
Механизм позволяет выполнять запросы во внешних сторонних СУБД и забирать результат. Казалось бы, этот механизм сильно расширяет возможности Greenplum, позволяя забирать данные в аналитическую СУБД напрямую из источников, однако применимость DBlink очень ограничена — ввиду архитектуры Greenplum передача данных при использовании DBlink осуществляется не сегментами впараллель, а однопоточно через мастер. Этот факт заставляет использовать DBlink только для управляющих запросов в сторонние базы, избегая передачи непосредственно данных. Справедливости ради стоит отметить, что с параллельным забором данных из сторонних СУБД поможет справиться ещё одно нововведение 5-ки, о котором мы поговорим в третьей части обзора новых функций.
Теперь при запросе SELECT возможно задать блок [NULLS
Также портировано из PostgreSQL без изменений. Теперь именно этот механизм используется для создания, удаления и обновления различных сторонних расширений. По сути выражение CREATE EXTENSION выполняет указанный SQL-скрипт.
2. Нововведения Greenplum
В Greenplum уже существует механизм управления нагрузкой — Resource queues (ресурсные очереди), однако он позволяет только ограничить запуск запросов исходя из их стоимости. Новый же механизм позволяет ограничивать запросы по потреблению памяти и CPU (но, увы, не по нагрузке на дисковую подсистему);
В и так не маленьком полку параллельных загрузок и выгрузок данных из Greenplum прибыло — теперь стандартная команда выгрузки данных из таблицы в плоский локальный файл поддерживает конструкцию ON SEGMENT — с ней данные выгружаются на всех сегментах БД в локальную файловую систему. Также появилась конструкция PROGRAM — забрать и отдать данные во внешнюю bash-команду. Кстати, эти две опции можно использовать вместе:
3. Новые сервисы и расширения
По моему мнению, это наиболее важная доработка Greenplum в новом релизе. PXF — фреймворк, позволяющий Greenplum параллельно обмениваться данными со сторонними системами. Это не новая технология, изначально он разрабатывался для форка Greenplum — HAWQ, работающего поверх кластера Hadoop. В Greenplum уже была параллельная реализация коннектора для кластера Hadoop, PXF же привносит в копилку интеграций гораздо большую гибкость и возможность подключать произвольные сторонние системы, написав свой коннектор.
Фреймворк написан на Java и представляет собой отдельный процесс на сервере-сегменте Greenplum, с одной стороны общающийся с сегментами Greenplum через REST API, с другой — использующий сторонние Java-клиенты и библиотеки. Так, например, сейчас имеется поддержка основных сервисов стека Hadoop (HDFS, Hive, Hbase) и параллельная выгрузка данных из сторонних СУБД через JDBC.
При этом сервис PXF должен быть запущен на каждом сервере в кластере Greenplum.
Схема взаимодействия PXF с HDFS
Как мне кажется, наиболее интересна возможность интеграции Greenplum со сторонними СУБД через JDBC. Так, например, добавив в CLASSPATH JDBC-thin-драйвер для Oracle Database, мы сможем запрашивать данные из таблиц одноимённой СУБД, при этом каждый сегмент Greenplum впараллель будет запрашивать свою шарду данных, исходя из логики, заданной во внешней таблице:
Популярный PostgreSQL-клиент теперь поддерживает расширенное взаимодействие с Greenplum. На борту поддержка DDL партиционированных таблиц, AO и Heap таблиц. DDL внешних таблиц пока не поддерживается.
Обобщить нововведения двухгодового пребывания в open source можно следующим:
Что дальше?
Не так давно в официальном репозитории был тегирован релиз 6.0.0. Этот релиз должен выйти в сентябре следующего года, и вот какие (как минимум) нововведения в нём точно будут:
Немного о нас: проект Arenadata был основан выходцами из компании Pivotal (компании-разработчика Greenplum и Pivotal Hadoop) в 2015 году, его целью было создание собственных дистрибутивов Greenplum и Hadoop enterprise-уровня для построения современных платформ хранения и обработки данных.
В начале 2017 года проект был приобретён компанией IBS.
Сейчас в портфеле проекта три собственных дистрибутива и все необходимые сервисы. В частности, по направлению Greenplum мы:
Как работает Greenplum: аналитическая база данных для big data и больших проектов
Greenplum — система управления данными из мира big data. Она нужна тем, кто анализирует и обрабатывает десятки терабайтов информации и кому тесно и некомфортно работать с обычными СУБД. Расскажем о том, что это за система, где и как ее использовать и в чем ее отличие от других систем, работающих с большими данными.
Самое главное: как устроена Greenplum
В основе Greenplum две вещи:
Про PostgreSQL в Greenplum более-менее все известно, в работе инженеров она встречается часто, а вот MPP упоминается реже.
MPP — massively parallel processing, или массивно-параллельная обработка данных. Такая архитектура весьма сложно устроена под капотом, но ее можно свести к простому концептуальному описанию. Это умная автоматическая разбивка данных по разным серверам (шардинг) с умной автоматической системой выполнения запросов к этим данным. Всё вместе это позволяет хранить петабайты записей и выполнять запросы к ним за вполне разумный срок.
Каждый процессор в системе имеет собственную память, операционную систему и диски. Источник
Конечно, разбивку большого количества данных по серверам базы данных (шардинг) можно сделать и руками, например, первый миллион записей хранится на первом сервере, а второй на втором. Решение выглядит простым, но есть куча минусов. Если сразу всем клиентам системы понадобится прочитать записи с одного сервера — этот сервер может не выдержать. Масштабировать такую систему тоже очень сложно.
Greenplum берет на себя все эти заботы и организует шардирование своими силами, заботясь обо всех нюансах. А еще Greenplum можно настраивать на различные стратегии выполнения запросов, ориентируясь на количество записей, количество процессоров и памяти на каждой машине.
Сама система за хранение данных не отвечает, для этих целей она использует PostgreSQL.
Кому нужна СУБД Greenplum
О самом очевидном применении мы уже поговорили — такая система незаменима, когда данных слишком много. Если 2-4 терабайта можно как-то втиснуть на один-три сервера и даже обращаться к этим данным, то миллиард терабайт в обычную СУБД поместить весьма проблематично.
То есть Greenplum нужна тем, у кого данных больше, чем очень много, то есть для работы с большими данными.
Кроме того, хранить данные — часть дела. Если к записям нельзя обращаться за адекватное время и выполнять над ними нужные операции — толку от таких данных нет.
Поэтому Greenplum нужна тем, кто не только хранит огромные объемы информации, но и активно с ними работает.
Конечно, проблемы работы с большими объемами появились не вчера, инструменты под эти задачи на рынке есть: ClickHouse, Cassandra и другие. Но после чтения документации можно заметить, что несмотря на общую сферу применения, у Greenplum есть особенности, которые четко определяют, когда точно нужна эта система, а когда стоит выбрать другую.
Сейчас мы поговорим о конкретных случаях и отличиях Greenplum от аналогов.
Чем Greenplum отличается от других СУБД для работы с большими данными
Greenplum поддерживает реляционную модель данных, сохраняет неизменность данных, поэтому ее можно применять для данных, чувствительных к точности и структурности. Например, для финансовых операций. Greenplum — хороший выбор для банков, ритейла и других компаний, где проводят большое число транзакций и их нельзя потерять.
От систем типа ClickHouse Greenplum отличается сферой применения. Если Clickhouse больше подходит для статистики, то Greenplum намного ближе к полноценной СУБД с индексами и хитрыми запросами. Это позволяет быстрее обращаться к определенным записям. При этом Greenplum справляется с аналитическими нагрузками от бизнес-аналитики до машинного обучения.
Также Greenplum поддерживает различные виды репликации и шардинга, оставляя далеко позади все аналоги. Это дает хорошую производительность, но требует очень тонкой настройки и множества серверов, если вы хотите развернуть такую систему on-premise.
Близкие по функциональности СУБД с похожей архитектурой часто сложнее внедрить. Например, этот аргумент может стать решающим при сравнении Greenplum и Teradata. Также Greenplum построена на базе PostgreSQL, поэтому проще найти специалистов для работы с ней.
Какие задачи в субд greenplum решает мастер
Поскольку Greenplum и Arenadata DB основаны на популярной open-source СУБД PostgreSQL, сегодня разберем, чем они отличаются от этой объектно-реляционной базы данных. Далее вас ждет краткий и понятный ответ на вопрос Greenplum vs PostgreSQL: сходства и отличия этих систем с учетом аналитики больших данных и практических кейсов дата-инженерии.
Что общего между Greenplum и PostgreSQL: 7 главных сходств
Напомним, PostgreSQL – это свободная ORM-СУБД с поддержкой стандарта SQL:2011 и множества языков программирования (pgSQL, Perl, Python, Java, PHP, R, Ruby, sh, C). Дополнительным преимуществом являются быстрые и надёжные механизмы транзакций, репликации, возможность индексации слабоструктурированных данных в формате JSON, а также гибкая расширяемость: разработчик создавать новые типы данных, индексов, подключать различные языки программирования, модули расширения, любые внешние источники данных. Благодаря отсутствию ограничений на максимальный размер базы данных и количество индексов в таблице, а также а также большую емкость таблиц и полей (до 32 ТБ и 1 ГБ соответственно), PostgreSQL часто используется во многих Big Data проектах [1].
Именно этот фокус на аналитику больших данных лежит в основе Greenplum, которая является адаптацией PostgreSQL с технологией массивно-параллельной обработки данных (MPP, Massive Parallel Processing). Проще говоря, Greenplum – это несколько взаимосвязанных экземпляров PostgreSQL, объединенных в кластер по принципу без разделения ресурсов (Shared Nothing). При этом каждый узел кластера, взаимодействующий с другими для выполнения вычислительных операций, имеет собственную память, операционную систему и жесткие диски. Это позволяет намного ускорить аналитическую обработку данных благодаря распараллеливанию вычислений. Помимо параллельного выполнения SQL-запросов, Greenplum включает автоматическое партиционирование данных, а также расширенные возможности их хранения и сжатия [2].
Таким образом, главными сходствами Greenplum и PostgreSQL с позиции архитектора DWH, аналитика данных и дата-инженера являются следующие:
Кроме того, обе СУБД считаются эффективными при долгосрочной настройке и развертывании приложений, что актуально в проектах промышленной аналитики больших данных. Однако, назвать Greenplum просто расширенным вариантом PostgreSQL не совсем корректно: эти системы имеют целый ряд отличий, которые мы рассмотрим далее.
И все-таки они разные: 3 ключевых отличия
При том, что PostgreSQL допустимо использовать в OLAP-сценариях, эта СУБД отлично подходит для OLTP-кейсов с небольшими базами данных. В частности, PostgreSQL может подключиться к сотням тысяч систем обработки транзакций. Но в случаях высокой OLAP-нагрузки использование PostgreSQL является не лучшим вариантом, т.к. эта система не обеспечивает функции сжатия данных, колоночного хранилища, автоматического партиционирования и распараллеливания запросов для глубокой аналитики больших данных. К примеру, PostgreSQL использует один многоядерный сервер обработки во время обработки запросов.
MPP-архитектура Greenplum обеспечивает возможность параллельной обработки запросов, ускоряя их выполнение на целые порядки. Производительность Greenplum зависит от количества запросов, которые необходимо прочитать и ответить на них.
При этом MPP-архитектура Greenplum реализует концепцию без разделения ресурсов, разделяя между узлами только сетевую инфраструктуру. А PostgreSQL работает по принципу «клиент-сервер» с совместным использованием памяти, областей хранения и операционных систем. Поэтому Greenplum можно использовать как колоночное хранилище данных, оптимизированное для добавления. Это позволяет рассматривать Greenplum как СУБД с функциями сжатия для всех оптимизированных append-таблиц в реляционных базах данных. А базовая архитектура PostgreSQL позволяет легко их модифицировать и дополнять для обеспечения параллельной структуры запросов.
Специальное быстрое обособленное сетевое соединение для связи между отдельными экземплярами PostgreSQL (Interconnect) в Greenplum обеспечивает их унифицированное поведение, позволяя рассматривать как единый образ базы данных. Кроме того, Greenplum можно оптимизировать для обработки больших наборов данных, задав декларативные разделы и подразделы. Внутренние элементы PostgreSQL были модифицированы и дополнены для поддержки параллельной структуры Greenplum: изменены системный каталог, оптимизатор, исполнитель запросов и компоненты диспетчера транзакций. Это позволяет выполнять запросы одновременно во всех параллельных экземплярах PostgreSQL, которые ведут себя как одна логическая база данных благодаря быстрым interconnect-соединениям [2].