Архитектор Данных
Kanalga Telegram’da o‘tish
Алексей, архитектор данных из ВК. Большие данные и облака. Для связи @alexbelozersky
Ko'proq ko'rsatish1 813
Obunachilar
+1324 soatlar
+117 kunlar
+4630 kunlar
Postlar arxiv
1 814
Обновление плейлиста 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.
———————————————————————-
Приглашаю ознакомиться с плейлистом по Лейкхаус на ВК, и подписаться на него. Туда я добавляю свои стримы и интересные доклады ведущих экспертов. А также на канал Архитектор Данных на ВК Видео.
———————————————————————-
1 814
Last Call на курс по Lakehouse + Iceberg + Modern Data Stack
Изучим как делать современный дата стек в облаке и он-преме. Глубоко погрузимся в современные форматы данных Iceberg, Paimon. Практика на Python, Trino, Airflow, DBT, Spark. Подготовленные шаблоны для развертывания собственных инсталляций на ваших машинах.
Записывайтесь скорее на 2-й поток - на этой неделе еще можно!
https://devhands.ru/lakehouse
1 814
Репо со вчерашнего вебинара можно посмотреть тут!
Автоматизация через содержимое папки scripts.
https://github.com/alex-belozersky/local_lakehouse
Не забудьте поставить GitHub звездочку!
1 814
Repost from Инжиниринг Данных
Тут накопилось несколько событий.
1️⃣Во вторник 3го февраля по Москве в 6 вечера будет вебинар про Iceberg и Lakehouse, вот детали:
Ссылка:
https://us06web.zoom.us/j/84412299387?pwd=0nAeguTrx40NPv7Ny7rGaVhyvUBvqa.1
Пост:
https://t.me/analyticsfromzero/435 (в комментах есть ссылка календарь)
Описание
С первого взгляда кажется, что Лейкхаус - это чудовищный зоопарк решений, компонентов и сервисов. И так оно и есть ) Для демонстрации и курса Алексей собрал небольшой стенд на одной виртуальной машинке. Хватает простой Убунты на 6 ядрах, чтобы запустить полноценную функциональную сборку и посмотреть, как работает этот класс решений.
На открытом воркшопе Алексей покажет компонентный состав, а по итогу - даст ссылку на GitHub, с помощью которого можно собрать стенд за пару скриптов.
Об авторе
Алексей Белозерский - самый главный по BigDataстроению @ VK Cloud 🤩
———
2️⃣Недавно собрались отцы основатели отечественного дашбордостроения (скорей всего они уже строят свои дашборды на весь мир) и обсудили изменения в индустрии - Dashboardless Analytics - Алексей Колоколов, Дмитрий Некрасов, Роман Бунин.
Описание тут: https://t.me/jetmetrics/370 | https://t.me/analyst_club/2726
Запись тут: https://insba.getcourse.ru/after_web_23-01-26
PS Никого не забыл упомянуть?!🟢
1 814
Лакмусовая бумажка
Это такое занятие, которое почти бесполезное по сути, но в которое тянет.
Для меня это проверка инвест счета. Там ничего не происходит значимого, просто падают купоны и осциллируют котировки.
Когда понимаю, что неделю туда не заходил - молодец, значит неделя прошла в хорошем ритме.
1 814
Во вторник 3-го февраля выбираем снаряжение для покорения айсбергов!
С первого взгляда кажется, что Лейкхаус - это чудовищный зоопарк решений, компонентов и сервисов. И так оно и есть ) Для демонстрации и курса я собрал небольшой стенд на одной виртуальной машинке. Хватает простой Убунты на 6 ядрах, чтобы запустить полноценную функциональную сборку и посмотреть, как работает этот класс решений.
На открытом воркшопе покажу компонентный состав, а по итогу - дам ссылку на ГитХаб, с помощью которого можно собрать стенд за пару скриптов.
Забирайте в комментарии файлик со встречей, и забукайте время - 3 февраля в 18:00 МСК!
1 814
Я видел 6 реплик на 10 млн пользователей.
И это был мега осознанный выбор потому что на 10 млн Россия кончалась и рост прекратился.
Было там же где люди с песьими головами
1 814
Repost from System Design & Highload (Alexey Rybak)
Что не так с постом от 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
1 814
Эти ребята пользуются популярностью у детей (6, 6 и 8).
ВК бы мультики про них снимать
1 814
+3
PgPro Day 2026
Много интересных технологий, ребята решили всерьез заняться аналитикой. Собрали аж несколько весьма представительных команд.
Уверен, мы будем слышать от них много интересных и прорывных в хорошем смысле идей в ближайшие годы.
1 814
Задачи разного уровня
Джун: Неси [куриные] яйца из холодильника к плите и постарайся не разбить, как в прошлый раз!
Миддл: Бери скоровороду, наливай масло, ставь на огонь, кидай туда яйца, жарь до готовности!
Сениор: Приготовь яичницу!
Тимлид: Приготовь вкусный и полезный ужин!
Архитектор: Спланируй кухню: где что лежит, сколько надо обрудования, какой персонал, какие требования по помещению, электричеству и т.д.
СТО: Организуй надежную массовую готовку и поставку еды.
СЕО: Открой сеть ресторанов и выведи их в прибыль.
1 814
Правильный ответ - задать встречный вопрос. Здесь ничего не сказано о режиме зеркалирования. Если grouped mirrors, ответ один. Если spread mirrors, то еще важно, сколько праймари сегментов на сегмент-сервер.
Дальше считаем по формуле Байеса, аккуратно складывая случаи выхода мастеров и сегментов.
Вопрос с подвохом - на понимание архитектуры ГП. Берите на собес на позиции, где она, архитектура, важна.
1 814
School ties
Красивая английская идиома, которая обозначает полезные связи, полученные в школьном возрасте. На выпускной в крутых британских школах дарят галстуки с символикой школы. А слово ties это одновременно и «галстуки» и «связи»
Мне мои дипломы позволили легко перескочить один из самых сложных этапов - первые джунские позиции.
Моей первой работой была очень маленькая и бедная компания, в которой лидами тянули девушки из МГУ. Думаю, не в последнюю очередь повлияло то, что в массе откликов я как раз «сигналил». Был понятен и одной крови.
На втором месте просто первый был вопрос: «Лицо у тебя знакомое, ты с физтеха чтоли?» А физтех, он маленький, все мы ходим по одним коридорам, поэтому даже если кого-то и не знаешь лично, то в лицо вы друг другу примелькаетесь. Потом я написал за 20 секунд запрос к ораклу с двумя джойнами и оконной функцией - ох как меня дрючили девушки из МГУ! - и понял по лицам что я впереди примерно 95% кандидатов. Все, дальше я работу искал и находил уже на лида и далее.
Такие вот school ties в действии.
Учитесь, ребята. Если можете себе позволить - учитесь. Размен потенциальных полезных связей и сигналов на сиюминутные и небольшие деньги - очень невыгодная сделка.
1 814
Сергей, спасибо за коммент!
Когда я в Вышке изучал трудовую экономику, узнал, что этот вопрос - одна из главных загадок мироздания. Как влияют уровни и годы обучения на доход, удовлетворенность жизнью, карьеру и так далее.
С одной стороны есть факт, что тот кто больше учится, зарабатывает больше. Даже несмотря на то, что у бросившего универ будет больше лет опыта, через лет 5 они сравниваются. То есть 5 лет учебы + 5 лет работы начинают обгонять 10 лет работы.
С другой стороны, невозможно проверить: этот эффект именно от обучения или работают другие факторы. Те, кто дольше учатся, происходят в целом из более обеспеченных семей. Или обладают большей склонностью к науке и способностями. Эти же факторы, очевидно, влияют и на карьеру. И поди пойми, человек сделал карьеру потому что стал умнее или потому что его папа, который может потянуть 5 лет обучения, может и в карьере подтолкнуть.
Есть еще такое хорошее объяснение как сигнальная теория. Если у человека на руках диплом хорошего ВУЗа, то это сигнал что он не тупой, и поэтому его стоит взять на работу. В стопке джунов без достижений у этого джуна достижение как раз-таки есть.
Сигнальная теория это когда сама академия говорит: эй, мы знаем, что все чему мы учим - для работы малополезная ерунда. Но зато, зарыв много лет и денег в формальное образование, ты будешь иметь на руках бумажку, что вот, ты в состоянии осиливать довольно сложные материи довольно быстро.
Подпись, печать, бланк с Госзнака.
1 814
Завтра буду на московской площадке Дата-Елки от ODS.
Обязательно пишите @alexbelozersky если хотите там пойматься и пообщаться!
1 814
Целеполагания вопрос
На третьем курсе физтеха после многих семестров матана я добрался до ТФКП и решал примерно такое.
Теперь же второклассница Маша с помощью GPT 5.2 вполне может решить вот такой примерчик
sin(z) = 5 (в военное время синус может достигать пяти!)
Если больше не нужно, как ее папе, тратить 12 лет на обучение сложным техническим премудростям, то чем тогда полезным заняться Маше?
1 814
Repost from N/a
🔥 Alibaba представила open-source интеграцию DuckDB — AP-движок для аналитических запросов прямо в MySQL
Крупнейший китайский облачный вендор Alibaba открыл исходный код глубокой интеграции аналитической СУБД DuckDB в AliSQL (форк MySQL). Это позволяет запускать аналитические запросы (OLAP) в тысячи раз быстрее, чем на InnoDB, с полным сохранением MySQL-синтаксиса.
Проект доступен полностью в open source — разработчики и компании могут использовать, модифицировать и внедрять эту технологию самостоятельно, без привязки к облачным сервисам.
🛠 Как это работает:
DuckDB встроен как плагинный storage-движок в архитектуру MySQL. Аналитические реплики синхронизируются через бинарный лог (binlog), что обеспечивает согласованность данных и отказоустойчивость. Под капотом реализованы оптимизации:
- Пакетное выполнение транзакций
- Поддержка DDL через
INPLACE / INSTANT или COPY - механизмы
- Многопоточная конвертация таблиц
📊 Производительность:
На тестах TPC-H SF100 DuckDB показал впечатляющие результаты — общее время выполнения 22 запросов:
• DuckDB: 15.31 сек (в 1648 раз быстрее!)
• InnoDB: 25 234.31 сек
🌐 Исходный код и документация:
Решение полностью открыто и доступно в репозитории AliSQL. Сообщество может изучать, использовать и развивать эту интеграцию.
👉 Репозиторий и подробная документация
#OpenSource #AliSQL #DuckDB #MySQL #OLAP #Database #Analytics #Alibaba #GitHub
Endi mavjud! Telegram Tadqiqoti 2025 — yilning asosiy insaytlari 
