Массивно-параллельная база данных Greenplum — короткий ликбез
О технологиях

Массивно-параллельная база данных Greenplum — короткий ликбез

1894
7 минут

Для 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.

28 марта 2022
Облака как возможность: аналитика КРОК Облачные сервисы
За первые две недели марта 2022 года количество запросов на услуги КРОК Облачные сервисы увеличилось на 960%, по сравнению с тем же периодом прошлого года. Компании на фоне приостановленных поставок ИТ-оборудования ищут доступные инструменты для поддержки бизнес-процессов и модернизации инфраструктуры.
2 минуты
134
21 февраля 2022
Как мы подключили третью зону доступности в облаке и наконец-то стали деплоить сервисы в виртуалках
Третью зону доступности в облаке мы развертывали изначально для решения собственных задач — чтобы обеспечить «честный» кворум для наших внутренних распределенных сервисов. У нас было три собственных дата-центра, но лишь в двух из них были выделены зоны доступности для облака, при этом одна была основной, а вторая от нее зависела.
1 минута
130
25 февраля 2021
Свидетели DevOps: мифы и байки про девопсов и тех, кто их нанимает
Те, кто решил стать девопсом, видят в этой профессии заманчивые перспективы. Это новый уровень мышления, это творчество и возможность создавать, это безграничные просторы для самосовершенствования. Не секрет также, что девопсам хорошо платят. Вместе с тем, вокруг понятия DevOps сформировался некий культ, овеянный мифами и легендами.
1 минута
832
23 сентября 2020
Миграция систем SAP в рекордные сроки. Оптимизация затрат на хостинг и сопровождение
Компании itelligence и КРОК реализовали уникальный проект миграции ключевых SAP-систем крупнейшего российского производителя лекарственных средств, АО «Фармстандарт», с одной хостинговой площадки на другую в предельно сжатые сроки. Компания itelligence обеспечила услуги по управлению и администрированию SAP-приложений, и компания КРОК предоставила вычислительные мощности и инженерное сопровождение.
2 минуты
1227
scrollup