Всем привет

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

Меня зовут Алексей, и я аналитик и архитектор данных. Работаю с большими БД, 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

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

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

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

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

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

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

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

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

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

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