Архитектор Данных

О вайбкодинге Сегодня впервые показывали навайбкоженное демо бизнес-заказчику. Как было раньше: технически продуктовая часть работает, задача решается. Но показать это сложно, нужно залезать в «черные экраны» или в лучшем случае, Джупитер-ноутбуки. Бизнес-заказчик не понимает этих инструментов, ему нужен перевод с технического на бизнес-язык. Сейчас: функциональная часть быстро оборачивается в интерфейс и заказчик видит билзко к тому, что будет в конечном продукте. Он видит свой UX, понимает его, доверие к показанному растет, а доверие это важно. В финале заказчик может попробовать демо сам, со своей мыши, для этого не нужно знать консольные команды или питон. Стал лучше понимать, почему мой хороший знакомый Влад Каменский ушел с позиции фаундера и CEO компании в области данных и стал 100% вайб-кодером. Внимательно слежу за его экспериментом. Как говорится, и я был скептик.

LakeFS приобрела DVC Идет дальнейшая консолидация продуктов. В конце прошлого года 2 решения Git-over-S3 объединились На моей практике многие ДС-команды "хотели" внедрять такие решения в свои пайплайны. Управлять версиями датасетов так же легко и теми же способами, как это делается для кода самих моделей. Валидировать вчерашнюю модель + сегодняшние данные против сегодняшняя модель + вчерашние данные. Быстро понимать, предикты испортились потому что в модели напортачили или потому что дрейф в данных пошел. Но в проде такой логики я ни у кого не видел и не слышал. Киньте ссылку, если видели статью или доклад про применение гитования данных в проде!

Философское - облако и разделение труда (5) В начало цикла. Части 1-3. В плане разделения ИТ-труда и кооперации многие российские компании находятся на стадии натурального хозяйства. Все сделаем и разработаем сами, сами закупим железо, сами настроим, сами будем эксплуатировать, сами напишем код. Отдельно грустно когда в большой компании или холдинге отдельные отделы и бизнесы ведут себя так же обособленно. Это уже не феодализм, а феодальная раздробленность, эпоха воюющих княжеств. Как в таком состоянии можно с кем-то всерьез конкурировать? С тем, кто просто на другом этапе развития? Рыцари и бояре с копьями не имеют шансов против пулемета, какими бы лично сильными, храбрыми, выносливыми они ни были. Внутри у себя поощряйте разделение труда. Чтобы хотя бы отделы сумели договориться админить базы сообща. Или почтовый сервер купили. Или хранилище данных с отчетами вместе одно на всех поддерживали. Выстраивание общих процессов ценно само по себе, растит экспертизу и экономит ресурсы. Бейте по голове менеджеров, которым проще самим все сделать, чем с кем-то пойти договориться. Выжигайте огнем культуру феодализма хоть бы и вместе с феодалами. Ваши менеджеры должны искать способы купить машину, а не изобрести мопед. Найти тех кому можно доверять хотя бы в малом, чтобы хотя бы в этом малом сэкономить внутренние ресурсы. Отдельно хотелось бы пожелать любимым регуляторам. Не растите риски на ровном месте. Самый большой риск - это риск возрастания рисков. Причем возрастания часто внезапного и нелогичного. Позитивный тренд от регуляторов - принуждение к кооперации. Яркий пример - проект ГосОблака от Минцифры, который как-то движется. Вдумайтесь, вместо того чтобы каждый сайт региональной прокуратуры, муниципалитета и детского сада решал проблему размещения своей инфраструктуры и сервисов самостоятельно, делаем общее для всех пространство. И это в то время когда большие и "цифровые" в сознании людей компании следуют подходу - мы будем делать все сами, пусть бедно и плохо, но зато ни от кого не завися. А в запущенных ситуациях - примерно то же но уже на уровне отдельных отделов и команд.

Философское - облако и разделение труда (4) В начало цикла - Части 1-3 Как добиться роста кооперации. Рост выгоден всем. Компаниям, государству, специалистам. Если вы владелец или топ-менеджер платформы или сервиса, подумайте, как сделать, чтобы ваши клиенты захотели с вами кооперироваться. Подумайте, как для них нарастить выгоду от сотрудничества с вами и как снизить риски. Как снизить риски в продукте 1️⃣ Начинайте с малого. Все клиенты из моего пула в облаке стартовали с небольших проектов и второстепенных сервисов. Тогда ваши клиенты точно будут знать, что именно вам можно доверить, а что нет. А ваши факапы не станут смертельными для сотрудничества. Почти всегда вы пушите продажи и внедрение забрать сразу вообще все. Самые крупные проекты, самые сжатые сроки. В ответ получаете запредельную для вас планку по техническим требованиям и по доверию к вам. Факапитесь, и на этом вашим отношениям с клиентом конец. Продукт или ваше предложение должен позволить начать с малого. Будьте готовы работать на небольших оборотах, имейте запас прочности, чтобы не оказаться в ситуации, когда нужно много денег вот прямо сейчас. 2️⃣ Продукт должен убирать собственные риски. Такие «второстепенные» функции ИТ-продукта как мониторинги, обсервабилити, безопасность - часто делается по остаточному принципу после «важных» фичей продукта. Это бич типичного российского ИТ-изделия. Так вы получаете прекрасный и функциональный (но это не точно) продукт, которым невозможно пользоваться на практике. А ну как сломается, и что с этим делать? Как вот этому у которого нет базового дашборда мониторинга (зеленый - хорошо, красный - плохо), поручить критичные бизнес-процессы? Давайте небольшой чеклист про риски. *️⃣Вы продумали, что делать, когда в вашем изделии все пойдет не так. У вас можно заметить проблемы на ранних подступах. *️⃣У вас есть документация, как это чинить, вы проводите обучение ответственных сотрудников заказчика, объясняете как пользоваться вашим изделием правильно и по назначению. *️⃣У вас есть база знаний типовых поломок и плохих ситуаций, что к ним может привести и как с ними бороться. *️⃣У вас есть качественная и быстрая поддержка. Вы готовы бросить все и сорваться чинить критическую проблему заказчика. Второй бич почти всех российских вендоров - поддержка вида «ну напишите нам в телегу или на почту, там разберемся» Чеклист можно продолжить. Когда вы приходите к заказчику, главный вопрос, который он решает - можно ли вот этим поручить серьезное дело? Правильно ли я поступаю, ставя себя в зависимость вот от них? Думайте об этом, носите мысль в сердце своем.

Ловлю двумя руками челюсть где-то у земли. Хорошо живут современные школьники (в правильных местах).

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

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

 <...>

Обновление плейлиста 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. ———————————————————————- Приглашаю ознакомиться с плейлистом по Лейкхаус на ВК, и подписаться на него. Туда я добавляю свои стримы и интересные доклады ведущих экспертов. А также на канал Архитектор Данных на ВК Видео. ———————————————————————-

Last Call на курс по Lakehouse + Iceberg + Modern Data Stack Изучим как делать современный дата стек в облаке и он-преме. Глубоко погрузимся в современные форматы данных Iceberg, Paimon. Практика на Python, Trino, Airflow, DBT, Spark. Подготовленные шаблоны для развертывания собственных инсталляций на ваших машинах. Записывайтесь скорее на 2-й поток - на этой неделе еще можно! https://devhands.ru/lakehouse

Репо со вчерашнего вебинара можно посмотреть тут! Автоматизация через содержимое папки scripts. https://github.com/alex-belozersky/local_lakehouse Не забудьте поставить GitHub звездочку!

Last Call - присоединяемся по ссылке

Тут накопилось несколько событий. 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 Никого не забыл упомянуть?!🟢

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

Во вторник 3-го февраля выбираем снаряжение для покорения айсбергов! С первого взгляда кажется, что Лейкхаус - это чудовищный зоопарк решений, компонентов и сервисов. И так оно и есть ) Для демонстрации и курса я собрал небольшой стенд на одной виртуальной машинке. Хватает простой Убунты на 6 ядрах, чтобы запустить полноценную функциональную сборку и посмотреть, как работает этот класс решений. На открытом воркшопе покажу компонентный состав, а по итогу - дам ссылку на ГитХаб, с помощью которого можно собрать стенд за пару скриптов. Забирайте в комментарии файлик со встречей, и забукайте время - 3 февраля в 18:00 МСК!

Я видел 6 реплик на 10 млн пользователей. И это был мега осознанный выбор потому что на 10 млн Россия кончалась и рост прекратился. Было там же где люди с песьими головами

Что не так с постом от 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

Эти ребята пользуются популярностью у детей (6, 6 и 8). ВК бы мультики про них снимать

PgPro Day 2026 Много интересных технологий, ребята решили всерьез заняться аналитикой. Собрали аж несколько весьма представительных команд. Уверен, мы будем слышать от них много интересных и прорывных в хорошем смысле идей в ближайшие годы.

CDO: Выступи с докладом, что все наши [куриные] яйца проверены ИИ.

Задачи разного уровня Джун: Неси [куриные] яйца из холодильника к плите и постарайся не разбить, как в прошлый раз! Миддл: Бери скоровороду, наливай масло, ставь на огонь, кидай туда яйца, жарь до готовности! Сениор: Приготовь яичницу! Тимлид: Приготовь вкусный и полезный ужин! Архитектор: Спланируй кухню: где что лежит, сколько надо обрудования, какой персонал, какие требования по помещению, электричеству и т.д. СТО: Организуй надежную массовую готовку и поставку еды. СЕО: Открой сеть ресторанов и выведи их в прибыль.

Правильный ответ - задать встречный вопрос. Здесь ничего не сказано о режиме зеркалирования. Если grouped mirrors, ответ один. Если spread mirrors, то еще важно, сколько праймари сегментов на сегмент-сервер. Дальше считаем по формуле Байеса, аккуратно складывая случаи выхода мастеров и сегментов. Вопрос с подвохом - на понимание архитектуры ГП. Берите на собес на позиции, где она, архитектура, важна.