Архитектор Данных – Telegram
Архитектор Данных
1.37K subscribers
178 photos
13 videos
2 files
143 links
Алексей, архитектор данных из ВК.

Большие данные и облака.

Для связи @alexbelozersky
Download Telegram
Эти ребята пользуются популярностью у детей (6, 6 и 8).

ВК бы мультики про них снимать
12😁4👍2
Что не так с постом от OpenAI про PostgreSQL на 800 млн пользователей

Недавно вышла статья про 800 миллионов юзеров ChatGPT на одном постгресе. Помимо очевидного пиара размера ChatGPT и достоинств Azure очевиден мессадж “А слыхали, постгрес крут — миллиард юзеров держит”. И действительно, в статье есть интересное, но в целом это не только ода PostgreSQL 😉 Ниже — саммари и комментарии в критическом, провокацонном ключе! Nuff said, погнали.

🤩 1 один primary + ~50 read-replicas по миру. OpenAI держит один мастер (Azure PostgreSQL Flexible Server) и почти 50 реплик чтения в разных регионах, при этом заявляет миллионы QPS на read-heavy нагрузке от 800 млн пользователей.

🤩 Главный враг — каскады аварий. Сценарий: сбой выше → промах кэша → лавина чтения; или всплеск дорогих join’ов → умираем по CPU; или write-storm от релиза/маркетинга → деградация. Дальше таймауты и ретраи раскручивают “петлю смерти”. Тут мы понимаем, что львиная доля запросов оседает в кеше, что если б кеша не было - постгресу приходит кабзда, и собственно можно расходиться со всем заявлением о могуществе PostgreSQL.

🤩 Postgres “упирается” в MVCC на записи — write-heavy уводят в шардированные системы. MVCC причиной write amplification / bloat / сложностей autovacuum и постепенно мигрируют шардируемые write-heavy нагрузки в Azure Cosmos DB, а в текущий Postgres даже не разрешают добавлять новые таблицы (новые ворклоады по умолчанию — в шардированные хранилища). Тут мы понимаем, что где-то ещё есть какой-то шардированный сторадж, это космос, и грустнеем ещё больше.

🤩 Главный анти-паттерн: джойнус гигантус вульгарис, особенно из ORM. Приводят пример запроса с join 12 таблиц, пики которого приводили к серьёзным инцидентам. Рецепт: ломать сложные join’ы, часть логики переносить в приложение, ревьюить SQL. Тюнить аймауты вроде idle_in_transaction_session_timeout, чтобы “idle in transaction” не блокировали vacuum.

🤩 Интересные моменты “уличной магии”
🤩 PgBouncer для защиты от connection storms и лимитов (в Azure упоминают 5000 коннектов на инстанс). В их бенчмарках коннект-латентность упала примерно с 50 ms до 5 ms.
🤩Workload isolation: разделяют high-priority и low-priority трафик на разные инстансы (борьба с noisy neighbor).
🤩Caching + locking/leasing: при промахах по одному ключу в БД ходит только один “победитель”, остальные ждут — защита от cache-miss storm.
🤩Rate limiting на нескольких слоях (приложение/пулер/прокси/запросы) + возможность блокировать конкретные “query digests”, чтобы быстро гасить дорогие паттерны.
Отличные советы, но почему баунсер, он же херово скейлится по ядрам? Впрочем, можно по-дедовски много инстансов наподнимать - да всё нагрузку-то оказывается уже унесли.

🤩 Много реплик: привет, Релей. Primary стримит WAL на каждую реплику; с ростом их числа растёт нагрузка на сеть/CPU и риск лагов. Поэтому они вместе с Azure делают каскад (промежуточные реплики, или релеи, ретранслируют WAL дальше), чтобы масштабироваться до “сотни+” реплик без убийства primary, но отмечают усложнение failover. Тут я подумал, что я будто машине времени лет на 20 назад переместился.

🤩Минное поле альтеров. Даже маленький ALTER может вызвать полный table rewrite. Разрешают только лёгкие операции, вводят таймаут 5 секунд на schema changes, индексы — только CONCURRENTLY, а backfill’ы — под строгими лимитами.

Ну! Надавали по рукам программистам со своими ORM, увели writes в волшебный космос, наставили релеев, чтобы репликация не убивала систему, немного уличной магии — и можно и порадоваться: p99 на клиенте “низкие десятки миллисекунд”, five-nines availability и всего один SEV-0 за 12 месяцев (вирусный запуск ImageGen, пришло +100 млн пользователей за неделю).

Так-то! Статья супер, но много вопросов к постгресу при чтении “между строк” 🙂

🔥всё правильно пишешь
👍и всё равно постгрес - вещь!


обучение devhands
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17🔥554
Media is too big
VIEW IN TELEGRAM
Во вторник 3-го февраля выбираем снаряжение для покорения айсбергов!

С первого взгляда кажется, что Лейкхаус - это чудовищный зоопарк решений, компонентов и сервисов. И так оно и есть ) Для демонстрации и курса я собрал небольшой стенд на одной виртуальной машинке. Хватает простой Убунты на 6 ядрах, чтобы запустить полноценную функциональную сборку и посмотреть, как работает этот класс решений.

На открытом воркшопе покажу компонентный состав, а по итогу - дам ссылку на ГитХаб, с помощью которого можно собрать стенд за пару скриптов.

Забирайте в комментарии файлик со встречей, и забукайте время - 3 февраля в 18:00 МСК!

—————————————————
—— Архитектор Данных ——-
—————————————————
1🔥19👀32
Лакмусовая бумажка

Это такое занятие, которое почти бесполезное по сути, но в которое тянет. И которое можешь себе объяснить, зачем ты там. То есть не листание ленты в Тик-Токе.

Для меня это проверка инвест счета. Там ничего не происходит значимого, просто падают купоны и осциллируют котировки.

Когда понимаю, что неделю туда не заходил - молодец, значит неделя прошла в хорошем ритме.
👍1362
Тут накопилось несколько событий.

1️⃣Во вторник 3го февраля по Москве в 6 вечера будет вебинар про Iceberg и Lakehouse, вот детали:

Ссылка:
https://us06web.zoom.us/j/84412299387?pwd=0nAeguTrx40NPv7Ny7rGaVhyvUBvqa.1

Пост:
https://news.1rj.ru/str/analyticsfromzero/435 (в комментах есть ссылка календарь)

Описание
С первого взгляда кажется, что Лейкхаус - это чудовищный зоопарк решений, компонентов и сервисов. И так оно и есть ) Для демонстрации и курса Алексей собрал небольшой стенд на одной виртуальной машинке. Хватает простой Убунты на 6 ядрах, чтобы запустить полноценную функциональную сборку и посмотреть, как работает этот класс решений.

На открытом воркшопе Алексей покажет компонентный состав, а по итогу - даст ссылку на GitHub, с помощью которого можно собрать стенд за пару скриптов.

Об авторе
Алексей Белозерский - самый главный по BigDataстроению @ VK Cloud 🤩

———

2️⃣Недавно собрались отцы основатели отечественного дашбордостроения (скорей всего они уже строят свои дашборды на весь мир) и обсудили изменения в индустрии - Dashboardless Analytics - Алексей Колоколов, Дмитрий Некрасов, Роман Бунин.

Описание тут: https://news.1rj.ru/str/jetmetrics/370 | https://news.1rj.ru/str/analyst_club/2726
Запись тут: https://insba.getcourse.ru/after_web_23-01-26

PS Никого не забыл упомянуть?!🟢
Please open Telegram to view this post
VIEW IN TELEGRAM
11👍82
Репо со вчерашнего вебинара можно посмотреть тут!

Автоматизация через содержимое папки noscripts.

https://github.com/alex-belozersky/local_lakehouse

Не забудьте поставить GitHub звездочку!
10👍54👀2
Last Call на курс по Lakehouse + Iceberg + Modern Data Stack

Изучим как делать современный дата стек в облаке и он-преме. Глубоко погрузимся в современные форматы данных Iceberg, Paimon. Практика на Python, Trino, Airflow, DBT, Spark. Подготовленные шаблоны для развертывания собственных инсталляций на ваших машинах.

Записывайтесь скорее на 2-й поток - на этой неделе еще можно!

https://devhands.ru/lakehouse
👍106👀3
Обновление плейлиста Lakehouse!

Выложили доклад маэстро Озерова (@cedrusdata) на Smart Data 2025.

Владимир здесь делает обзор на стейт и развитие экосистемы Iceberg. Часть материалов была здесь на канале раньше в этом перезаливе. Там же можно посмотреть и само видео от создателей и контрибьюторов Айсберга на английском с таймкодами.

Это про Variant, geo data, row lineage, row_id.

Потом Владимир идет дальше и касается уже предполагаемых фич Iceberg v4/v5.

Что есть нового:

1️⃣ Внесение вьюх в стандарт Айсберга. Сейчас вьюшка это просто хранимая строка SQL, и проблема в том, что в разных движках SQL разный. Вьюха записанная в Spark SQL не будет работать в Trino или StarRocks. Поэтому сообществу нужно изобрести промежуточный сериализованный стандарт хранения вьюхи, которая будет хранить что-то вроде плана ее выполнения.

2️⃣ Материализованные вьюшки. Тут не легче - нет способа валидировать что таблицы, от которых зависит матвью, обновились.

3️⃣ UDF. Есть гиганский документ с очень сложным пропозалом, как сделать стандартизированный вид хранимых UDF. Интересно, что в спаке-то справились с этой задачей!

4️⃣ Iceberg Wide Tables. Сейчас под айсбергом лежит одномерный массив паркетов. То есть каждый паркет содержит примерно все колонки таблицы. Но что делать, если в таблице 1000 или 10000 колонок! Такие приложения уже вполне есть, например в области фиче сторов для МЛ. Было бы неплохо уметь разбивать массив колонок таблицы на несколько логических блоков и хранить их в разных паркетах.

5️⃣❗️Транзакции! Многостейтовые и много-объектные транзакции.

6️⃣ Securable Objects или по-простому RBAC. Сейчас в стандарте Айсберга нет единого способа сделать ролевую модель, и разные движки, команды и метасторы колхозят что-то свое. Цитата: "Добавлять это в стандарт - это форма безумия. Надеюсь не сделают"

7️⃣ FGAC - Fine Grained Access Control. Маскирование, колоночные гранты и так далее. Строчные авто-фильтры - Васе можно смотреть только строки по своему региону/отделу. Идея в том, что права отправляется на движок, и движок его применяет. Или не применяет, потому что не умеет. От этого движки делятся на Trusted / Non Trusted. Ах да, снова надо придумать универсальный метод описания пермишенов.

8️⃣ Disaster Recovery на уровне логических объектов айсберга: таблиц, манифестов, снапшотов и т.д. Первое, что надо сделать - научить метадату работать по относительным путям. Здесь я вообще не понимаю, как так вышло, что я не могу перенести Айсберг таблицу в соседний бакет S3 или с S3 на папку и оно перестанет работать потому что во всей метадате прописано s3://myonebucket/

9️⃣ REST Planning. Как насчет сделать функционал в Iceberg REST каталоге для того, чтобы можно было кинуть в него запрос и получить план. Или хотя бы список паркетов которые он реально будет читать по запросу SELECT SUM(rev) FROM SALES WHERE [my-filter]. Как было бы удобно разрабатывать движки. И это почти готово!

Интересных идей, очень много, жаль, что многое находится хронически на этапе пространных обсуждений.

Из зала мой первый вопрос - что нужно сделать S3 как софту, чтобы Iceberg экосистеме было комфортно с ним общаться.
Ответ: STS, Vended Credentials.


———————————————————————-

Приглашаю ознакомиться с плейлистом по Лейкхаус на ВК, и подписаться на него. Туда я добавляю свои стримы и интересные доклады ведущих экспертов. А также на канал Архитектор Данных на ВК Видео.

———————————————————————-
Please open Telegram to view this post
VIEW IN TELEGRAM
👍85👏21
This media is not supported in your browser
VIEW IN TELEGRAM
Набор в «Летово» завершается 9 февраля: успейте подать заявку на поступление

Ещё думаете? Стоит обратить внимание — с нового учебного года в «Летово» стартует первый в России профиль обучения по разработке ИИ. Это направление с углубленным изучением анализа данных, машинного обучения и математики.

Почему «Летово»?
🔶уникальное оборудование (сервер с 4 картами H200 и класс ноутбуков с GPU Nvidia 5090)
🔶сильная олимпиадная подготовка
🔶индивидуальный профиль обучения Математика+ с 8-го класса
🔶возможность учиться бесплатно


 <...>
Please open Telegram to view this post
VIEW IN TELEGRAM
1🤷‍♂51