Виды Greenplum

Ранее
О Greenplum - Часть 1 - Почему Greenplum популярен [В России]


🔪🔪🔪🔪🔪🔪🔪🔪🔪🔪🔪
24 Мая 2024 года новый владелец платформы Tanzu - компания Broadcom - заархивировала публичные репозитории Greenplum. В списке архивированных теперь
https://github.com/greenplum-db/gpdb-archive
https://github.com/greenplum-db/gporca-archive
https://github.com/greenplum-db/pxf-archive
и другие. Код доступн только для чтения, о чем нас предупреждает GitHub.

За последние годы Greenplum и его производные стал фактически российской СУБД для больших данных по умолчанию. Альтернатив ему на нашем рынке в сегменте больших транзакцонных MPP СУБД практически нет.

К сожалению, за последние 5 месяцев российские вендоры Greenplum не смогли договориться о совместной работе по дальнейшему развитию всем так нужной платформы. Сказываются различные интересы: одним интересен он-прем в его российских реалиях, другим - публичное облако.

Давайте соберем краткую подборку, какие виды GP есть и поддерживаются разными компаниями.


Vanilla Greenplum

Никуда не ушел. По-прежнему можно скачать код-базу и собрать последнюю версию СУБД или воспользоваться собранными бинарниками. Продукт (пока что) застрял на версии 6.27 и нестабильной 7.2
Основная проблема в морально и физически устаревшем PostgreSQL 9.4

Ресурсы
Сайт - https://greenplum.org/
Github - https://github.com/greenplum-db/gpdb-archive
Документация с некоторых пор закрыта от российский IP.

Проприетарная версия доступна в составе VMware Tanzu Data Suite.


Arenadata Greenplum - Greengage

Родился как проект по развитию кодовой базы Greenplum в поставке Arenadata DB. В будущем версии Arenadata DB в редакциях Community и Enterprise перейдут на GreenGage. Заявлено, что для пользователей сборок Аренадаты переход произойдет бесшовно - просто с очередным обновлением ADB «под капотом» перейдет на Greengage.

Новые утилиты в поставке Arenadata будут называться по-другому, например, ggshrink вместо gpshrink. Возможно, со временем мы увидит ggconfig, ggperfcheck и другие внутренние утилиты.

Заявлен поэтапный переход на Postgres v.16 и такие фичи как авто-фейловер.

Ресурсы
Сайт - https://greengagedb.org/
GitHub - https://github.com/arenadata/gpdb
Telegram (анонс) -

Полезные ссылки - видео

Круглый стол (Тиньков)
https://vk.com/video-151223562_456239528

Анонс GreenGage (Аренадата)
https://vk.com/video-211969254_456239091

Круглый стол (Аренадата)
https://vk.com/video-211969254_456239092


CloudBerry Database

Наследник Greenplum 7 от конгломерата китайских разработчиков. В основе - Postgres 14. Популярен по ту сторону Великого Фаерволла, в наших краях редок

Сайт
https://cloudberrydb.org/

GitHub
https://github.com/cloudberrydb/cloudberrydb



Yandex Greenplum

Облачная версия Greenplum-6 от Яндекса. Имеет несколько значимых доработок, к примеру, драйвер Yezzey, который позволяет хранить данные БД на S3.

Документация облака.
https://yandex.cloud/ru/services/managed-greenplum

GitHub
https://github.com/open-gpdb/yezzey

Разделение Compute-Storage
https://www.youtube.com/watch?v=D22bZCLZOjQ


#Greenplum #Инструменты #DB

Коротко о потреблении памяти в #Greenplum.

Greenplum очень "жадно" выделяет оперативу для запросов. Главный параметр, на который он ориентируется, это concurrency в ресурсной группе. Если в дефолт группе стоит concurrency=10 и прилетает 2-3 тяжелых запроса, он не выделит много памяти, так как ждет еще 10 подключений.

На картинке иллюстрация прогона пака запросов из репозитория.

Прогон в 3 вариантах.

1. 32 GB памяти на сегмент concurrency=10. Выделено ок. 3 ГБ

2. 32 GB памяти на сегмент, concurrency=4. Выделено ок. 6 ГБ

3. 64 GB памяти на сегмент, concurrency=4. Выделено ок. 21 ГБ.

Пак запросов с транзакциями эфира - до 4 млрд строк.

Простое уменьшение параллелизма приводит к увеличению эффективной памяти в 2 раза. Хотя казалось бы, других запросов нет и 80% shared_quota.

Увеличение памяти ВМ в 2 раза ведет к увеличению эффективной памяти в 3,5 раза. Эффект нелинейный. Хотя казалось бы, свободной памяти более 50%

Какие выводы

Если есть тяжелые запросы, обязательно выделите ресурсную группу с малым concurrency и отдавайте их туда.
Это актуально для ELT и для Ad-Hoc.

Также полезно научиться переносить запросы внутри сессии между рес. группами.

когда отправил себе подборку облигаций от Т-Инвестиций и получил предложение закодироваться от программирования.

Писала "креатив" явно нейронка.

Пример как не надо делать. Не там и не то в попытках заработать 2 копейки.

Всем привет

Канал постепенно утрачивает статус шпаргалки к вебинарам. Пришло время представиться (и где были мои манеры раньше!).

Меня зовут Алексей, и я аналитик и архитектор данных. Работаю с большими БД, Greenplum, Clickhouse, Spark, Kafka, Trino. Строю хранилища и озера данных.

Сейчас тружусь в b2b ВК облаке, ex-Arenadata, ex -Uchiru, ex-Мвидео-Эльдорадо. Сделал порядка 10-ка проектов в AWS, Google Cloud.

Здесь делюсь бестпрактисами, лайфхаками, хинтами. Иногда записываем с командой вебинары на студии Skillbox.

Спасибо всем, кто читает и ставит реакции!

Сейчас на rubiconf на стенде облака.

Завтра буду на партнерской конференции Аренадата.

Подходите, поговорим.

Душно пост – Что есть база данных

Мы часто огульно говорим: «база данных». Часто за этим стоят разные вещи, в зависимости от контекста. Также нередко мы слышим: «Мы поддерживает 10000 баз данных». Это 10к именно логических БД или 10к СУБД или 10к серверов? Может быть любой из этих трех вариантов.

Давайте разберемся в терминологии (откройте окно, стало душно!)

БД (База Данных) – это сам массив данных. Строго говоря, это могут быть просто файлы на диске в формате csv/parquet/whatever или база данных телефонных номеров в экселе. То есть просто данные (датасеты), до которых можно как-то добраться, прочитать и извлечь полезную информацию. В идеале – к БД прилагается метаинформация о том, как именно данные стоит читать и как правильно воспринимать: телефоны в формате +7-ХХХ-ХХХХХХХ и никак иначе, а деньги в монгольских тугриках.

СУБД (Система Управления БД). Это программа, софт, который где-то запущен. Главная его задача – предоставлять доступ к БД в некоем наборе протоколов. Быть готовы, что придут пользователи и начнут что-то читать или записывать/обновлять.
Пример – кластер Postgres, принимающий подключения по JDBC с аутентификацией через LDAP.
Пример – кластер Opensearch, принимающий запросы по HTTP JSON API.

Кластер СУБД. Может быть достаточно сложносочиненной конструкцией из многих нод нескольких типов. Postgres + Patroni состоит из:
– Мастер
– Синхронная реплика
– Несинхронные реплики (в облаке их количество доходит до 15)
– Сервис patroni
– Кластер из нескольких DSC (etcd или consul)
– Балансировщики: Octavia, HAProxy и тд
– Пулеры: pgbouncer, pgpooler, odyssey

Все это может размещаться на нескольких серверах или виртуальных машинах, но точно больше чем 3-х.
Нередко в одну СУБД помещают несколько логических БД. К примеру в кластере Postgres + Patroni создается несколько независимых объектов БД:
Create database mydb owner user;

Некторые БД могут «ездить» по кластерам на разных этапах соего жизненного цикла. БД начинает как пилотная на коммунальном кластере, но по мере роста нагрузки и выведения в прод поселяется на мощном отказоустойчивом кластере Patroni.

Когда приходят и говорят: «У нас N баз данных», могут иметь в виду разное: N логических БД, N кластеров БД, N ВМ в составе кластеров. Соответственно, и масштаб проблемы может быть разным.

В качестве приложения - архитектура Patroni кластера.

Взято из:
https://postgrespro.ru/clusters/patroni

Postgres для аналитиков

PostgreSQL – пожалуй, лучшая СУБД с открытым кодом. Можно ли эту классическую OLTP базу использовать для аналитики? Как прикинуть – хватит ее или не хватит?
Давайте обсудим.

При использовании Postgres и любой СУБД со строчным хранением под OLAP запросы мы попадаем на все минусы такого подхода. Нам нужно для запроса прочитать одно поле из одной строки в 100 байт, для чего нам приходится вычитать блок данных в 32кбайт с диска, где хранятся вся целевая строка, соседние строки, а также разные версии этих строк. И еще СУБД оставляет пустое пространство, чтобы быстро проапдейтить строку. Общая эффективность легко может быть 100/32768=0.3%.

Можно ли использовать Postgres для аналитики? Конечно, сам так делал!

На входе в российский EdTech проект в команде было 3 аналитика и порядка 500ГБ данных. Можно было быстро получить от команды DevOps БД Postgres на ВМ в облаке. В нашем случае это была 16 vCPU машинка. Этого вполне хватало на ETL, на BI и ад-хоки.

А потом случился «аналитический взрыв». Как только команда строит приличный аналитический стек с нуля, мгновенно материализуется отложенный спрос от многих отделов компании. В нашем случае мы сделали простой BI, систему АБ-тестирования и закрыли несколько хороших гипотез с хорошим результатом на выручку. Сразу же пришли соседи и попросили дать им аналитиков и подключить их процессы к нашей системе.
(Практически карго-культ 😄)

И вот спустя полгода у нас уже 7 аналитиков и 1,5 ТБ данных. Также заметно выросло разнообразие данных, и команда прибавила в сложности задач, которые она может брать и успешно закрывать. БД пришлось переносить на выделенный сервер, так как переподписанные ядра и облачные диски уже не тянули нагрузку. С ростом команды до 15 человек и данных до 4 ТБ потребовался еще один переезд на мощный выделенный сервер.

Какие факторы влияют на то «тянет» простая БД аналитику или уже нет

Первое, число пользователей. 6 аналитиков создают нагрузку х2 по сравнению с 3. Каждый новый аналитик привносит с собой датасеты и процессы, которые надо обслуживать в смысле ETL, Data Quality.

Во-вторых, объем данных. Даже если набор датасетов фиксированный, то каждый день подливаются новые данные. Отдельный фактор – история изменений в SCD1,2. Больше данных процессим – больше читаем с диска и больше расходуем ресурсов сервера.

В-третьих, сложность производимых с данными манипуляций. Новые датасеты это новый ETL, новые проверки качества данных. Новые джойны старых данных с новыми. В старых датасетах собираются «низковисяцие фрукты», усложняются вопросы, задаваемые бизнесом. Это сразу же тянет замысловатые и «перекрученные» запросы от аналитиков. А вот те пользователи, которые приходили по промо акции, но не купили – с какой вероятностью они купят потом, когда скидки кончатся?

Допустим в точке старта мини-КХД у нас:
– 3 аналитика
– 500 ТБ данных
– Фактор сложности 1

После первого роста команды – точка 2:
– 6 аналитиков (фактор х2)
– 2 ТБ данных (фактор х4)
– Фактор сложности 2 (х2)
Итого рост нагрузки х16 (!)

В точке 3:
– 20 аналитиков (х3.33)
– 5 ТБ данных (х2.5)
– Фактор сложности 3 (х1,5)
Итого рост нагрузки x12.5 (!) от прежней

Каждый раз мы растем на порядок! Причем эти точки роста случаются быстрее, чем мы предполагаем.

И самое плохое в этой истории, что мы внезапно понимаем, что наша инсталляция больше не тянет. Случается это в период высокой нагрузки – а когда же еще? И в момент когда нам надо заниматься содержательной работой (высокий сезон, закрытие квартала и тд) мы вынуждены решать проблему низкой производительности или переезда на «настоящую» аналитическую БД с колоночным хранением и MPP архитектурой.
Поэтому надо все же подумать, куда мы хотим, можем, рискуем вырасти. И учитывать рост не только в данных, но и в других факторах. В нашем примере при росте данных в 10 раз мы выросли по нагрузке аж в 200.

Выводы – можно ли ограничиться простой Postgres?

Если у вас 1 ТБ данных и команда из 5 аналитиков, нет планов по существенному расширению «поляны», то, конечно, можно.

Если же вы со старта планируете амбициозные задачи, рост команды до 10+ человек, которые будут работать над несколькими предметными областями. Хорошей идеей будет начать с кластерной MPP СУБД сразу. Она станет верным подспорьем в расширении и развитии.
В критический момент, когда вы и ваши мозги будете максимально нужны компании, она не сложится под нагрузкой и ее всегда можно будет штатно нарастить по ресурсам.

Экономика MPP Базы

Сколько стоит MPP база взамен Postgres?

Прежде всего, давайте учтем что цена может быть разная. 2 самых простых примера: 1) цена непосредственно в счетах и 2) цена в неэффективно потраченном времени.

Первую цену посчитать легко. Берем конфигурацию на 1 ТБ хранимых данных в Postgres и Greenplum. Скриншоты из облака:

Видим что у MPP есть определенный оверхед по ресурсам. Надо поддерживать отдельный мастер + резервный мастер, которые слабо участвуют в обработке запросов. Но все равно – разница составляет 140 тыс.р. В месяц.

Для расчета второй цены – потерянного времени команды аналитиков можно поступить так. Реальная цена для компании даже команды из 5 человек может легко составлять 2 млн.р / месяц. Если учесть з/п + налоги + страховки + ДМС + место в офисе + выданные макбуки + съеденное печенье, то 2 миллионов скорее мало чем много.

На сколько должна повыситься эффективность команды, чтобы оправдать доп затраты на оборудование и лицензии в 140 тысяч? 140/2000 = 7%.

7% эффективности (!) нужно нарастить команде, чтобы оправдать затраты на технологию. Что легко достигается за счет того, что запросы выполняются быстрее и не нужно лишний раз оптимизировать код SQL и ETL.

После первых восторгов о Кликхаусе обычно приходят моменты вроде:

(На кластере в 2 шарда, 2 реплики).

ШАГ 1 ::
create table demo_t1_2 (
f1 Int8,
f2 String
)
Engine = MergeTree()
Order by f1
;

Как таблица только на одном сервере из 4?

ШАГ 2
create table demo_t1_2 ON CLUSTER cluster (
f1 Int8,
f2 String
)
Engine = MergeTree()
Order by f1
;

Теперь 4 независимые таблицы на 4 машинах.

ШАГ 3 :
create table if not exists demo_t3_2 ON CLUSTER cluster (
f1 Int8,
f2 String
)
Engine = ReplicatedMergeTree(
'/clickhouse/tables/{shard}/{database}/demo_t3_2',
'{replica}'
)
Order by f1
;
С каждым шагом все дальше от ANSI SQL но сейчас хотя бы что-то куда-то реплицируется.

ШАГ 4 (вдобавок к шагу 3) :
create table if not exists demo_t4_2 ON CLUSTER cluster (
f1 Int8,
f2 String
)
Engine Distributed(cluster, default, demo_t3_2, rand())
;

Во, кажется победа. Только куда теперь данные вставлять?

GLOBAL JOIN / GLOBAL IN - а ты что такое???

Никогда не пойму зачем так делать? Зачем кластер, в котором настолько анархия, пока ты явно не укажешь, что работайте-ка вы все вместе. Зачем мне командовать отдельными ногами лошади, если можно скомандовать голове: беги/стой?

Читал тут студентам лекцию "Кликхаус глазами дата инженера". Попробую развернуть в более длинный и обстоятельный материал со временем. Ставьте плюсики, если интересно.

ML at Scale!

Пятничный хабропост от коллег о том, как погрузить Catboost в Spark.

Также пошаговая инструкция, как запустить эту сложную конструкцию не выходя из Jupyter тетрадки (!) на Cloud ML Platform.

https://habr.com/ru/companies/vk/articles/868114/

Postgres – фичи, которых не хватает для КХД

Postgres как OLTP СУБД заточена под логику 1 приложение - 1 БД. Здесь речь про именно логическую базу данных. На инстансе или кластере postgres могут работать несколько логических БД под различные приложения. Когда нагрузка растет и ресурсов одного кластера не хватает, логические БД могут быть без большого труда перенесены на другой/отдельный кластер. Ситуации, когда несколько приложений делят между собой одни логическую БД редки, хотя и бывают. К примеру, это может быть основное приложение + админка.

В Корпоративном Хранилище по определению будет много пользователей и приложений. Это же единая версия данных для всех. Как раз то место, куда многие могут обратиться за единой и согласованной версией данных.

Поэтому а) будет большой и растущий параллелизм запросов, это мы частично обсудили, когда считали и планировали нагрузку и б) надо уметь большую конкурентную нагрузку грамотно распределять по пользователям.

В GreenPlum для этого есть ресурсные группы (или ресурсные очереди в старых версиях). В них как раз можно выделить нагрузку по типам и группам и нарезать ресурсы кластера на выполнение запросов. Вот эта группа пользователей – ETL, ей 30% ресурсов, вот эти – BI, им 50%, а вот эти аналитики, им 20%. Это во время рабочего дня, а ночью 80% кластера выделено для ETL, извините. В Greenplum v.7 можно дополнительно нарезать ПСП диска и сети.

Как добиться такого в Postgres (или ClickHouse), я, честно говоря, не знаю. Если знаете – подскажите в комментариях.

Postgres для аналитики - годится ли?

#postgres #analytics

Навигация по постам

1. OLTP БД в роли аналитичекой
2. Планируем рост нагрузки - пример из жизни
3. При каких ограничениях Postgres точно «хватит»
4. Экономика - сколько стоит ММР против «обычной БД»
5. Фичи КХД которых нет в Postgres