В качестве приложения - архитектура 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

О шкафах Икеа и облачном PaaS

Часто возникает вопрос: Зачем нам облачный PaaS, который и дороже, и с некоторыми ограничениями. Можно же просто взять ВМ и настроить все там как-тебе-надо!

Хороший вопрос. Чтобы ответить на хороший вопрос, нужна хорошая аналогия.

Есть на свете шкаф Икеа ПАКС. Это не то чтобы самый идеальный шкаф в мире, тем не менее, популярностью пользуется. Его можно кастомизировать в некоторых пределах. Для этого в нем насверлено много лишних отверстий, и эстетика от этого выходит так себе. Он стандартных размеров и оставляет зазоры. Он плохо терпит любую кривизну стен и полов. Он недешевый. Вы его заказываете, и вам приезжает готовый набор для сборки плюс супер-детальная инструкция. На выходе - при помощи шуруповерта вы за один вечер решаете вашу проблему. А что не так – звоните в поддержку и вам помогают.

А можно поехать в строительный гипермаркет, купить там отдельно доски и фурнитуру – какие вам надо – и изготовить идеальный для вас шкаф. Под вашу геометрию стен, под ваши предпочтения, и скорее всего, выйдет даже дешевле.

Обе опции имеют право на существование.

Облачный PaaS это как раз тот самый Икеа Пакс. Есть некое наилучшая конфигурация для среднего заказчика. Вместо шифоньера – СУБД или Кубернетис, БигДата или ML платформа. Вдобавок есть поддержка, инструкция, гарантия качества в рамках продукта.

В случае ИТ и Облака это работает в большем масштабе. Представьте что вам нужен не только шкаф, но и кухня и сантехника, да еще не на одну квартиру, а на двадцать. А то и на небольшой отель. Представьте что вам надо программно задавать количество и характеристики каждой инсталляции под каждый проект.

Не так-то плохо, что можно поехать в Икею и накупить готовых сборок. Какие бы «фе» не выдавались на эти, казалось бы, кондовые и квадратно-гнездовые конструкции.

Как ваши reading lists на праздники? Уже начинаем?

Душно пост - Облако - IaaS PaaS SaaS

Хорошие ярлыки, но все сложнее чем кажется.

IaaS – Infrastructure as a Service.

Кажется, что все просто, и это тупо виртуальная машина. Но на самом деле нет.

Виртуальная машина это CPU и Память, окей. А какой тип виртуализации? Это влияет на то, сколько будет порезана мощность относительно «железа».

А какая реальная переподписка? На 10 физических ядер сколько «подсажено» запущенных виртуальных машин. Ни для кого же не секрет, что облака зарабатывают на том, что пик нагрузки разных ВМ разных заказчиков не совпадают по времени. Можно на 80 физических ядер подсадить 200-300 виртуальных, и по-прежнему иметь реальную нагрузки на физический ЦПУ 50-70%.

А диск какой? Локальный или облачный, нарезанный с систем хранения? Можно ли «на горячую» расширять диски или подключать/отключать новые к ВМ?

А сеть как виртуализированна? Есть ли облачный фаерволл?

Аренда GPU все больше пользуется популярностью. GPU как виртуализировано? Какой модели? Карты, подключенные к одной ВМ как друг с другом умеют общаться: через ЦПУ или NV-Link? Это прокинутые GPU или vGPU?

Что будет если гипервизору станет плохо? Какие условия миграции ВМ с гипервизора на гипервизор и дисков со стоража на стораж? Будет ли «мигание», будет ли ребут?

Можно ли на-лету поднять ресурсы виртуалки, добавив памяти и ЦПУ?

Как организованы бекапы ВМ и дисков? В S3? На ленту? По какой технологии?

Сколько в облаке ЦОДов? Что будет если откажет целый ЦОД? Можно ли быстро достать оттуда ресурсы и переразвернуть в другом ЦОД? В целом, как организована отказоустойчивость в том числе Control Plain самого облака? Виртуальная сеть на несколько ЦОД растянутая?

Есть ли вспомогательные системы, такие как IaM, аудит доступа, логирование, алертинг? Можно ли получить емейл или SMS о том что сервер упал? А можно ли собрать кастомные метрики приложений и получать алерты по ним?

Как можно программно поднимать инфраструктуру? Есть ли Infra-as-Code провайдеры, Terraform? Что можно делать через API?

Как видите, не так все просто, и IaaS другому IaaSу рознь.

Также привет всем тем, которые поднимают NextCloud или OpenStack / OpenShift на 5 арендованных серверах и думают, что получили аналог большого публичного облака.

AWS, GSC, Azure, Yandex, VK, MTS и другие не просто так берут свою маржу, не правда ли?

#Облако #Душно #IaaS

PaaS – Platform as a Service, Что это за платформа такая?

Чуть выше обсуждали на примере шкафа из Икеи. Не просто виртуалка, а виртуалка, на которой что-то расположено. И поддерживается как что-то целостное. Можно сделать и самому, но придется повозиться. Иногда сильно повозиться.

Как насчет Greenplum / Arenadata, в котором 6 типов ВМ и 8 сервисов? Или Spark-on-k8s, который умеет сам масштабироваться в зависимости от падающей в него нагрузки, а без нагрузки засыпать и не тратить деньги?
Тут еще больше вопросов к каждому типу платформы.

Если это СУБД, то какая в ней отказоустойчивость, какие бекапы: снапшоты или Point-in-time? Как управляются пользователи? Если ли шифрование данных? Есть ли Мульти-ЦОД репликация? Как оно реплицируется и шардится, если оно умеет реплицироваться и шардиться?
Реплики добавить и удалить на лету можно? А диск расширить или добавить ресурсы на ВМ по мере роста?

Если это Кубернетис, то там какие потроха? Какая сеть? Есть ли мульти-мастер? Можно ли в разные нод-группы?

А бывает матрешка: Trino-over-k8s + S3 + Catalog. И там оно как?

Очень много вариантов.

#Облако #PaaS

SaaS - Software as a Service.

Тут проще всего, как ни странно. Не приложение на десктопе/планшете/телефоне а сервис в браузере. Или одно + другое бесшовно. Онлайн документами все пользуемся – вот типичный пример SaaS.

Может быть чем угодно еще. PowerBI Cloud. DBT Cloud, CRM (например, Bitrix).

#Cloud #SaaS@analyticsfromzero

DBT – Шуруповерт из мира данных

Продолжая метафору со сборкой мебели.

Есть облачные PaaS как готовые наборы мебели а-ля Ikea Paks и кастомные решения для платформ данных а-ля мебель на заказ под размеры и требования заказчика. Где-то рядом должны быть инструменты для сборки и наладки мебели. На роль шуруповерта, облегчая каждодневный труд мастера, отлично подходит DBT.

Скажут, наши деды успешно справлялись и без шуруповертов. Некоторые добавят, что рукой и отверткой оно как-то вернее и проще. Но едва ли кто-то будет отрицать, что в руках умелого мастера простой аккумуляторный инсрумент сильно ускоряет работу и упрощает труд.
При этом намного важнее чтО крутится, а не чем крутится.

Кратко возможности DBT разбирали чуть раньше.

Также был вебинар-воркшоп.
+ Видео на ВК

5 и 6 января подключайтесь на стрим с Димой Аношиным в канале @rockyourdata.

Совместно мы расскажем о построении платформ данных на базе DBT и о возможностях VK CLOUD для облачных PaaS решений.

Все гениальное просто.

#DBT

Запись 1 дня вебинара по DBT совместно с @rockyourdata

VK Видео