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

Современные проблемы требуют современных решений

Так выглядит снапшот Айсберга. И какой это кладезь метаданных! Тут есть • когда изменились данные • что именно произошло в этом изменении: аппенд 9 дата-паркетов. • Какое состояние таблицы: записей, число дата-файлов всех видов • через какой движок: Трино версия 468, библиотека Айсберг 1.7 • какой юзер это сделал • какой айди запроса в точности Через 2 дня это будет зачищено, но до того доступно для любых DG / Sec Audit тулов!

Давно хотел запостить. Это взгляд крупного бизнеса на 2026-й. Режем, откладываем, ужимаемся. Прожить год, потом инвестиции. В России выживают пессимисты. Если вы торгуете любым инвестиционным товаром - поздравляю, у вас трудности. Привет платформам данных и ИИ. Учитесь операционализировать свои предложения, говорить про пользу здесь и прямо сейчас, а не когда-то через год. Ну и начинайте с малого, растите доверие у заказчика, пока все сидят на заборе со своими огромными капексными коробками и ждут хороших лет.

Предприниматель в 2026-ом Логично в последний рабочий день 25-го подумать о том, как мы будем жить в грядущем 26-ом. Жить будем сложно, но весело. Гарантировано. Степень неопределенности зашкаливает. Что будет с СВО? Что с санкциями? Как малый бизнес переживет новые налоги (и переживет ли)? Какая будет инфляция? Какая будет ставка? Что будет с авторынком при такой ставке и утиле? Добьют ли карго? А курс? Какой будет курс? А тут еще и WhatsApp забанили, и непонятно, где будет трафик и в какой канал инвестировать? А тут еще ИИ и ИИ-пузырь. Всё это превращает бизнес в 26-ом немного в лотерею. И что делать? Кто-то начнет рассказывать байки про некую «антихрупкость», а я скажу проще: маржа! У кого будет маржа, тот и выживет. В 26-ом нужно быть максимально маржинальными. Режьте косты «не дожидаясь перитонита». Все эти прожекты, т.н. инвестиции и прочие фантазии - всё надо резать - сокращать расходы, ради сокращения расходов. Да, это порождает порочную спираль, ведь ваши расходы - это чьи-то доходы, а значит, если все начнут резать расходы, то у всех упадут и доходы. Но в бизнесе иногда не проблема «умереть», главное - «умереть последним». Но как же будущее? А что потом? А вдруг мы пропустим рост? Братцы, в России выживают пессимисты. Так что готовимся к худшему, надеемся на лучшее.

Peace Что ж, рад что мы во всем разобрались. Явную клевету убрали (хотя интернет помнит все), с Димой (@rockyourdata) мы объяснились. Что ж, кто не устранял последствия разгульных вечеринок, тот не жил и не дышал 🫢 Спасибо всем, кто оказал поддержку! Очень приятно знать, что вокруг люди, готовые помочь и словом и делом. Неимоверно вас ценю. Теперь peace и архитектура

О далеких доброжелателях На днях подписчик прислал ссылку на пост в жанре площадной филиппики в мой адрес. В целом мне приятно, что малознакомые люди, собравшись в кружок вечером в субботу, обсуждают меня. Пусть даже предметом являются мой кошелек, мои бонусы и сильно искаженная версия трудовой биографии. Видимо, так и приходит «известность». На пару тезисов, тем не менее, отвечу. Первое. Я не являюсь энтерпрайз архитектором в жанре «рисую стрелочки, дорого». Я не имею отношения к архитектуре ВК, где соцсети, почта, реклама. Я работаю с заказчиками ВК Облака, типичный мой заказчик - медиум и крупный российский бизнес. Те, кто размещают инфрастуктуру данных в облаке на IaaS, SaaS, PaaS или думают об этом. В реалиях рынка мне открыто сильно больше, чем типовому дата инженеру просто потому что перед глазами не 1 проект в котором я устроен, а 15-20 проектов заказчиков облака, с которыми я взаимодействую. Второе. Бонусы у меня и правда есть, они и правда неплохие. Но привязаны они к перформансу моего продукта на рынке. Я кровно завишу от того, насколько интересно людям то что я говорю и насколько работают технологии, которые я предлагаю. Работают и приносят пользу - см. п.1 - в рядовом российском энтерпрайзе. Третье - про обвинение в «воровстве» чье-го кода. Накатик в том, что я сделал демонстрационный репозиторий не с нуля, а на основе другого открытого. И если бы я скопипастил код без указания на авторский, это было бы воровство. Если бы я взял без спроса платный лицензируемый продукт, это было бы воровство. А когда ты берешь открытое произведение, указываешь автора, дополняешь своими соображениями и также выкладываешь в общий доступ - это нормальные опен-сорсные практики. Если поверх любого моего репо кто-то сделает что-то себе полезное, я только порадуюсь, и уверен, что автор оригинала тоже. Расшифрую: если видишь кроме надписи forked рядышком также надпись This branch is N commit ahead of, это означает, что предлагаемое содержит дополнения по сравнению с. К примеру, в оригинале сборка не устанавливается на чистую систему и требует пререквизитов, в моей сборке - ставится. Есть расхардкоженные пароли, унесенные в зону вне репо и тд. Это все не инженерный мастерпис, но это экономит время и понижает порог входа в сборку. Если мы с командой сэкономили 30 минут каждому, кто попытается использовать сборку по назначению, считаю, что дополнения сделаны и выложены не зря. По факту уже сейчас воспользовались 50+ человек, те, о которых знаю. Авторам пасквилей рекомендую обсудить что-то более духовное, чем чужой кошелек, когда в следующий раз они «соберутся на яхте». И заняться чем-то более полезным, чем распространение клеветы в адрес малознакомых людей. Ссылка на филиппику - в первом коменте. Молодые ребята дают жару на яхте - смотреть без регистрации и смс. Хотя веселые кружочки из канала уже удалили. P.S. Картинку в посте я тоже у Ильи Репина украл.

Команда Кликхауса опенсорснула Кубернетис оператор https://clickhouse.com/blog/clickhouse-kubernetes-operator

На нас надвигается великий и ужасный 117-й приказ ФСТЭК. Нашел хорошее почти трехчасовое (!) видео с объяснением и обсуждением его деталей. В видео прекрасные тайм-коды, можно быстро почерпнуть нужные именно вам темы.

Снаряд два раза в одну воронку не падает Интересно, что у архитектора данных вышел цикл постов о том, почему стоит ехать в облако. А тем временем в нашей вселенной идет все ускоряющийся цикл ухода от облачной инфраструктуры во внутреннюю платформу данных чисто на реализовавшихся рисках (деньги смысла считать даже нет, стоимость рисков с лихвой покрывает всё). Про что речь? В своем докладе что на смартдате, что в остальных местах я рассказывал про блокировку аккаунта в Google BigQuery в прошлом году на время уточнения данных, и заняло это 3 недели. Что случилось 2 недели назад? Да, аккаунт опять заблокировали, опять уточнение, ну а работа - потерпите, чай не сахарные. И следом уже вчера заблокировали целый пул ip адресов европейских цодов из стран вокруг РФ - запрет на использование api своих сервисов (BQ, GCP). То есть ты находишься не в РФ, платишь не с РФ, но никого не волнует. Итого последние 3 недели мы перевозим проекты в StarRocks днем и ночью. Но почему-то получилось, что вместо расчета их там все заехало в Spark. Причина достаточно простая - наши эксперименты с бигквери проходили на проектах малого размера, почти все модели в dbt считались на table материализации. Spark такие штуки раскладывает примерно за 10-15 секунд на витринку, нагружать же mpp бд такого рода нагрузкой кажется напрасной затеей. Ведь в чем всегда была притензия к данным в хадупе - медленное чтение, а вот витринки собираются порой быстрее вертики (да что там, кликхауз у меня тоже получалось когда-то в телекоме обогнать). В итоге пользователи, биай и сервисы читают и делают эдхоки через StarRocks, а счет идет в кластере хадупа - все по заветам современных историй лейкхаузов, правда без перекладывания данных в слой доступа. Ну а какие выводы можно сделать за эти 2 недели? А вот такие: * перевозить витрины можно очень быстро * сверять результаты между системами - чудовищная по трудоемкости операция * витрины начинают разбегаться между системами буквально на следующей недели после переноса - надо или следить, или очень быстро ехать Даже если функции выглядят в двух системах похоже (именуются одинаково), то совсем не факт что их аргументы или возвращаемые результаты будут идентичными. И поверх накладывается проблема вскрывания ошибок во время написания витрин в исходной системе, когда мы вынуждены или переносить расчет данных и найденную ошибку, либо мы теряем возможность построчной сверки :( Вообщем печаль, беда и разорение. Если кто знает уже готовый тулсет для сверки таблиц построчно-поколоночно на спарке - напишите в комментарии, пожалуйста. Написать свой вроде несложно, но вдруг древние уже учли все проблемы. Почему spark? Потому что можно в нем внутри сравнивать разные системы без материализации и копирования данных, а еще легко сделать select sha1(*) from...

Два хороших примера использования нейронки

Из комментов, тест Seedance 2.0 подписчика, промт (!): A spectacular fight between a Tajik and an Uzbek over pilaf. They use pilaf to fight each other in spectacular hand-to-hand combat. ЭТО ЧТО ТАКОЕ ВООБЩЕ?! 😮

Домашний ИИ-бот, который заказывает продукты из ВкусВилл С нового года хотел попробовать MCP-сервер ВкусВилл и OpenClaw — open-source фреймворк (181k+ звёзд на GitHub), который превращает LLM в Telegram-бота с навыками. Вчера Даша сказала: нужен бот в чат с диетологом. Давай уже сделаем? Быстро смотреть продукты, КБЖУ, собирать корзину. Основной поставщик у нашей семьи — ВкусВилл. Засел на вечер. 🧠 Opus — дорого даже для домашнего бота Начал с Claude Opus 4.6. За 2 часа настройки и тестов с диетологом — $30. Для бота, который ищет творог — перебор. Подключать подписку Max — боюсь, может нарушать ToS. Переехал на Kimi K2.5 от Moonshot AI. Спасибо за наводку @nobilix Триллион параметров, MoE-архитектура. На бенчмарках рядом с Opus, подписка за 20 долларов и я не боюсь за ToS.

💡 OpenClaw имеет встроенную поддержку Kimi Coding — не нужно возиться с эндпоинтами. Указал модель, прописал ключ — работает.

🛒 MCP ВкусВилл: ищет, но не проверяет наличие MCP-сервер умеет искать товары, показывать КБЖУ и собирать корзину. Но не проверяет наличие по адресу доставки. Без этого бот собирает корзину из товаров, от которых нет пользы. Сайт отдаёт блок наличия только настоящему браузеру — curl не проходит, сервер проверяет TLS-fingerprint. 🔧 Решение: Puppeteer рядом с Docker Развернул headless Chrome через Puppeteer. Один раз авторизовался через chrome://inspect, прописал адрес доставки — куки сохранились. Keepalive раз в сутки, чтобы сессия не протухала. Теперь бот перед сборкой корзины проверяет каждый товар: есть — добавляет, нет — предлагает замену. Единственная ручная работа — авторизация через DevTools. 💰 Стоимость: ~$33 в месяц 🔸 Kimi K2.5 API — $20 🔸 VPS (1 ядро, 2 ГБ) — $12 🔸 Perplexity API (веб-поиск) — ~$1 🔸 OpenAI API (голосовые) — копейки Семейный ассистент с голосовыми, веб-поиском и интеграцией с продуктовым магазином. Настройку делал через Claude Code — следил за лимитами, хватило бы стандартной подписки. 🔒 Безопасность Docker, allowlist по Telegram ID, изоляция сессий между пользователями. В интернет — только через проверенные эндпоинты. 📦 Гайд со всеми граблями Конфигурация провайдера, heartbeat, Puppeteer, безопасность, cron-задачи: 🔗 GitHub: openclaw-homebot-guide Если пост увидят во ВкусВилл — ребята, MCP крутой, но сделайте авторизацию для ИИ-агентов. Одна таблица в базе, связь с учёткой, SMS — и можно отдать ключ агенту без костылей с безголовым Chrome. ---- Поляков считает — AI, код и кейсы

О вайбкодинге Сегодня впервые показывали навайбкоженное демо бизнес-заказчику. Как было раньше: технически продуктовая часть работает, задача решается. Но показать это сложно, нужно залезать в «черные экраны» или в лучшем случае, Джупитер-ноутбуки. Бизнес-заказчик не понимает этих инструментов, ему нужен перевод с технического на бизнес-язык. Сейчас: функциональная часть быстро оборачивается в интерфейс и заказчик видит билзко к тому, что будет в конечном продукте. Он видит свой 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