data будни

мне кажется последние два интервью отлично смотрятся вместе и дополняют друг друга >_>

и отдельно мысль, которая где-то проговаривалась в этих интервью: токены — новый вид бенефита для сотрудников.

большие компании готовы вливать миллионы в токены для своих разработчиков.

а сами поставщики фундаментальных моделей в принципе ограничены только внутренними мощностями для своих сотрудников.

в подкастах Кирилла Мокевнина @orgprog упоминали, что в долине у каждого второго безлимит на модели OpenAI / Anthropic по тем или иным каналам

🥷 DHH об agent-first подходе

DHH — известный ии-скептик и сторонник написания кода вручную; в своём сетапе он не использует IDE с их подсказками и навигацией по коду — всё набивает ручками (и радуется)

ещё DHH известен своими сильным мнением и радикальными взглядами — он говорит что думает, не взирая на мнения большинства или отдельных авторитетов

недавно зашёл к Pragmatic Engineer на интервью
https://youtu.be/JiWgKRgdgpI

и вот наступил действительно переломный момент:

⁃ июль 2025 — DHH не верит и не использует агентов

⁃ январь 2026 — DHH переходит на agent-first разработку

что поменялось? вышли модели, которые выдают достаточно хороший результат, которые при минимальных доработках можно шипать в прод.

если уже DHH «распробовал» агентский подход — значит, результаты работы становятся действительно достаточно хорошими

⌘⌘⌘

DHH делится историей, как агент помогает ему разбирать ишью в его проекте на Гитхабе: из 250 открытых пулл-реквестов агент за пару часов разобрал 100.

какие-то единицы можно было мержить «как есть» — они уже были достаточно хорошего качества; другую часть агент провалидировал как «правильно опознанный баг, но реализация не идеальная» — такие он адаптировал/переписал согласно принятому стилю репо; и ещё часть агент смог аргументированно зареджектить.

при этом сам DHH потратил бы на эту работу несколько дней (и не получил бы большого удовольствия от неё).

🦄 руководитель Claude Code об AI в разработке

послушал интервью Бориса Чёрного в подкасте Ленни. Борис написал первую версию Claude Code и теперь руководит этим направлением в Anthropic.

https://youtu.be/We7BZVKbCVw

по их данным сейчас уже 4% всех коммитов в Гитхаб создаются через Claude Code (ожидают 20% к концу года)

интересно, что первую версию Claude Code Борис сделал прошлой весной и это не был сиюминутный успех; популярность инструмента росла постепенно и взрывной рост случился после выхода модели осенью (Опус 4.5 кажется)

и с ноября 2025 Борис не написал ни строчки кода вручную — всё через Клода; так же приводит в пример «лучших программистов Spotify», мол, они тоже больше не пишут код руками.

Борис видит, что в будущем профессии будут теснее переплетены: не будет программистов или дизайнеров, все будут builder («создатель»?) — задавать ви́дение, раздавать задачи аи-агентам и принимать результат их работы.

этот сдвиг парадигмы ставят в один ряд с изобретением печатного станка и освобождением пицсцов от монотонной работы; и с переходом от программирования на перфокартах к следующему уровню.

📁 про культуру ведения тикетов

продолжаю рассказывать про внутрянку нашей команды, привлекая ваше внимание к активным вакансиям >_>

> важный дисклеймер: это не я, это всё наш техлид Кирилл (я тут только документирую и выношу)

думаю, все видели тикеты, прочитав которые, осталось непонятным что́ надо сделать; или задачи, где ты вроде сделал что было написано, но оказалось, что нужно было не то и не так ¯\_(ツ)_/¯

мы в команде стараемся придерживаться культуры ведения задач — попробую описать как я это вижу


⌘⌘⌘

начнём с того, что создать хороший тикет - это отдельная работа; чтобы понятно описать что надо сделать, надо как минимум представлять проблему и целевое решение

есть базовый паттерн, которого мы придерживаемся:
⁃ контекст
⁃ проблема
⁃ что сделать
⁃ допматериалы

небольшие тикеты могут пропускать 1-2 пункта; а большие эпики будут наоборот побольше


⌘⌘⌘

«хорошие» задачи формулируются через глаголы:
сделать …, добавить …, исправить …, пересчитать …

однозначно указан объект изменения: таблица, таск, модуль и пр.

есть перечень связанных действий: в конце …сделать миграцию, …пересчитать историю, и пр.


⌘⌘⌘

задачи на имплементацию проходят через общее техревью на входе, чтобы вместе посмотреть и проверить:
⁃ проверить, что мы в принципе хотим это делать
(тут бинарно; пока без приоритетов)
⁃ задача описана понятно
⁃ ожидаемый результат считывается однозначно
⁃ (опционально) докапывается технических деталей

цель такого пре-ревью проверить, что автор достаточно подумал про задачу и потенциальный исполнитель прочитает её ожидаемо

паттерны задач помогают консистентно формулировать задачи внутри команды, а так же уменьшают количество догадок и уточнений на этапе разработки


⌘⌘⌘

если задача занимает больше нескольких дней, то внутри ожидаются отбивки по текущему статусы; размер отбивок пропорционален масштабу задачи

причём не абстрактный статус «продолжаю работать», а короткий апдейт по фактам: сделано Х / осталось сделать У / открытые вопросы и блокеры …


⌘⌘⌘

в конце каждого тикет исполнитель оставляет резюме о проделанной работе

«сделал таск, пересчитал историю, вот ссылка на итоговый объект» — всё что нужно знать о задаче, осознанно принять результат (и при необходимости вспомнить через полгода что тут было вообще)

статусы и резюмешки повышают прозрачность работы для сторонних наблюдателей: заказчиков, тимлидов, а так же для себя из будущего

прозрачность ведения задач особенно важна при ведении инцидентов — для них помимо резюме дополнительно надо сразу заполнить пост-морфем
(инцидент-менеджемент у нас тоже есть — про него в другой раз)

⌘⌘⌘

лайк-шер-репост
👉 https://t.me/data_days/400

🦀 Clawdbot / Moltbot / OpenClaw

там похоже намечается очередной качественный скачок аи-строения: австрийский программист написал автономного (?) ии-агента… и понеслось

формат горячих новостей не мой любимый жанр, но это залетело в моё инфополе с трёх разных сторон:

+ Самат Галимов накидал ссылок для понимания контекста
https://t.me/ctodaily/1995

+ Pragmatic Engineer выпустил интервью с автором
https://youtu.be/8lF7HmQ_RgY

+ ребята из Шмит16 собрались вместе где-то на Бали и скупают все доступные мак-мини, чтобы устроить ферму из таких аи-агентов

сам автор бота не случайный мамкин вайбкодер — он начинал ещё с веб-приложений в начале 2000-х и потом перешёл на приложения айос для первого айфона.

потом запилил как побочный продукт PSPDFKit — низкоуровневый парсер и рендере пдф-ок; продукт быстро стал приносить денег больше, чем основная работа и он переключился на него фултайм. потихоньку стартап разросся до 70 человек.

продукт оказался достаточно востребованным, чтобы его покупали большие компании, и при этом достаточно сложным, чтобы они не могли его просто сделать внутри

отсюда у автора большой опыт в построении сложных технических продуктов с большим количеством разношёрстных пользователей — надо успевать развивать продукт, ничего не поломав.

⌘⌘⌘

потом он (традиционно) выгорел и ушёл с радаров на три года, ничего не делал, ничем не занимался; и всё, чтобы «вернуться в интернет» в 2025-м —прямо на рассвете ии-агентов

тут он офигел от новой технологии и по первым ощущениям от продукта он вспомнил все хорошие впечатления от программирования

в итоге к осени он врубился в технологию настолько, что она стала для него «запойной»: работает на десятью пет-проектами сразу и 10 разных агентах / терминалах

⌘⌘⌘

поинты автора про подход к агентам:

⌘ замкнуть цикл обратной связи: задача → план → исполнение → отладка → тестирование → сверка с исходной задачей — всё это агент делает сам в бесконечной итерации, пока результат не достигнут

⌘ «новое» программирование — это верхнеуровневый дизайн, а не написание кода

⌘ из аи-агенты можно собирать локальные мини-команды (и не отдельные тулзы)

⌘ а синьорные инженеры — это теперь аи-менеджеры таких локальных команд для разработки

⌘⌘⌘

сам Moltbot / OpenClaw выглядит как проект на стыке аи- и арт-перфоманса

автономный агент, которому явно дают доступ к локальной системе — это что-то за гранью привычного

причём не каждый догадывается или может позволить себе отдельный мак-мини для инстанса бота — и они грузят их прям на своей основной тачке

с другой стороны, эти эмерджентный и удивительные свойства агента проявляются как раз на богатой почве развитого локального окружения; на стерильной системе у него не будет истории переписки в мессенджер и почте, не на что смотреть)

⌘⌘⌘

агент имеет доступ к своим настройкам и исходному коду

может менять свою конфигурацию, дописывать новые модули

так, у бота не было модуля работы с голосовыми сообщениями, но, получив однажды голосяшку от автора, он через какое-то время дал релевантный ответ (оказалось, он прочитал хедер сообщения, нашёл нужный модуль, установил его и смог декдодировать пришедшее ранее сообщение)

🤯

data будни pinned «📢 ищем дата-коллег к себе в Яндекс Финтех → дата инженеры https://yandex.ru/jobs/vacancies/inzhener-dannih-v-finteh-36637 → дата-партнёры (они же системные аналитики двх) https://yandex.ru/jobs/vacancies/analitik-dwh-v-finteh-27815 это прям в нашу команду…»

📝 о код-ревью (часть 2)

вижу тема ↑ код-ревью хорошо зашла — продолжаю накидывать


⌘ разные авторы — разные вопросы на ревью

+ во время онбордина на первые ревью обычно приходит тьма комментариев; чтобы проверить, что автор достаточно погрузился в новый проект, приходится спрашивать с самых банальностей: «почему тут за Т-2», «почему тут снепшото, а не апсёрт?» и т.д.

+ со временем у авторов набирается «репутация» — вопросы переходят на следующий уровень абстракций (или вовсе пропадают с типовых решений)


⌘ размер имеет значение

− гигантский ПР на 500+ строк кода, затрагивающий множество модулей, имеет шанс погрязнуть в процессе ревью (не говоря уже про увеличенную вероятность пропустить багульку в прод)

+ а вот маленький атомарный ПР легко читать и требует адекватного количества когнитивной энергии ревьюера — а значит не вызывает сопротивления и обычно сходится предсказуемо быстро


⌘ не всегда есть «правильный» ответ

+ иногда вопрос — это предложение к дискуссии или просто любопытство почему выбран именно такой подход

+ хочется проверить, что автор продумал основные кейсы в предлагаемом решении


⌘ проблемы код-ревью

− неконсистентность от ревью к ревью: даже один ревьюер может спросить разное, не говоря уже о нескольких

− код-ревью не случается само — оно занимает время и тратит когнитивную энергию; это буквально конвейер и его надо явно планировать в своём календаре (получается всем в команде)

− ну и в целом — растёт тайм-ту-маркет, в задачу надо закладывать время на схождение код-ревью


⌘ ожидания от код-ревью

+ код-ревью не должно быть узким горлышком — положительные эффекты складываются, когда вся команда ревьюит друг-друга (не только один тимлид по ночам и выходным)

+ LGTM — это тоже ответственность; если код падает прям сразу после релиза — вопросики будут как к автору, так и к ревьюеру;

+ всем в команде (включая ревьюера) потом поддерживать этот код — в общих интересах поддерживать кодовую базу в хорошем виде


⌘ пускай потеет машина

+ проверять синтаксис и опечатки должны машины, а не белковые мешки; поэтому эффективнее настроить линтеры, тесты, вот это всё

+ если команда уже сформировала код-стайл и обсудила архитектурные подходы, то будет проще формализовать и базовые проверки

+ а дальше пускай уже и аи-шные агенты ревьюят код помимо базовых линтеров и тестов — эти уже не только формально, но и по смыслу смогут накидать на вентилятор


---

тем временем мы продолжаем искать дата-коллег — ваши репосты нам очень помогут

📢 ищем дата-коллег к себе в Яндекс Финтех

→ дата инженеры
https://yandex.ru/jobs/vacancies/inzhener-dannih-v-finteh-36637

→ дата-партнёры (они же системные аналитики двх)
https://yandex.ru/jobs/vacancies/analitik-dwh-v-finteh-27815

это прям в нашу команду, то есть будем работать вместе)

наша команда свежая — начали строить наш двх осенью 2024; поэтому не успели пока обрасти легаси и техдолгами, зато смогли заработать репутацию и кредит доверия за свой первый полный год работы.

хотим и дальше нести свет в массы, поэтому активно ищем новых коллег


что у нас есть интересного:
→ есть полная документация — наши объекты не идут в прод без описания каждого атрибута
→ на нанейминг полей и объектов — есть конвенция
→ на YQL — есть линтеры
→ на пулл-реквесты — тесты в си-сд (и 4 глаза ревьюеров)

из технологии — почти всё яндексовое:
+ YTsaurus как основная система хранения
+ смотрим в сторону ClickHouse рядом
+ придерживаемся подхода инфра-как-код через Terraform
+ логброкер как шина данных для стриминга и дата-трансфер как коннектор (если вам это о чём-то говорит)

любим процессы (но без карго культов)
→ есть дежурство и инцидент-менеджмент с пост-мортемами
→ есть удобный процесс мониторинга и алертов
→ подробный онбординг и прочие документы о процессах команды


чем предстоит заниматься:
§ перекладывать джейсоны ысоны слева направо — разобраться где найти, откуда они там появляются, почему в таком формате, и как лучше их разложить, чтобы дорогим пользователям было удобнее их селектить;

$ работать над доступностью сервиса и данных: как валидировать данные и мониторить корректность на потоке, чтобы не пробивать общие сла;

$ выяснять, спрашивать, изучать у источников почему данных не было, почему поздние долёты, почему внутри полная шляпа, и вообще где ещё три нужных поля;

$ спорить с дорогими коллегами как оптимальнее перелопатить теробайты в секунду, как лучше описать новый домен, какой кусок вынести в общую либу, голосовать какие фичи больше всего нужны в общей платформе

и делать это всё в максимально подготовленной и комфортной среде, внутри Яндекса развитая культура внутренних инструментов: доступы к основным аи-моделям, рабочие места с Курсором, внутренние вебинар и обучалки на любые темы


понимаю, что процесс найма долгий, поэтому планирую постепенно накидывать заметок о буднях команды; ссылки буду появляться ниже
→ о код ревью
→ ещё о код ревью
→ про культуру ведения тикетов
→ …

можно откликаться на вакансия выше или присылать CV с кратким интро мне в личку @SashaMikhailov

буду рад ответить на вопросы в комментах или так же в личке

✍️ о код-ревью

у нас в команде в прод только через пулл-реквесты и каждый пулл-реквест должно посмотреть двое коллег. моя личная статистика за 2025 год показывает 430 проведённых код-ревью. сложились какие-то мысли по этому поводу, ниже пытаюсь собрать их вместе.


⌘ зачем вообще нужно код-ревью

+ это вторая пара глаз с иным контекстом и уровнем погружения: автор и ревьюер смотрят на код в разных когнитивных режимах → ловятся разные ошибки

+ передача знаний в рамках команды: «применяем вот такие паттерны, а вот так не делаем» → в среднем качестве кода постепенно улучшается

+ барьер против энтропии и деградации кодовой базы: без должного присмотра любой проект постепенно превращается в трудно поддерживаемое болото


⌘ как бывает без код ревью

когда команда небольшая, да ещё и допустим без большого опыта, то большой соблазн поспешить с реализацией или смалодушничать при проектировании → в результате получается нагромождение модулей, которые через время проще сжечь, чем исправить


⌘ как задавать вопросы на код-ревью

+ открытые вопросы лучше чётких предложений — во-первых, ревьюер сам можем не осознать что здесь происходит, а, во-вторых,

+ любой код может быть написан множеством способов — прежде чем предложить что-то поправить, надо понять а точно ли оно будет объективно лучше? или просто «ревьюер привык писать по-другому»

+ спорные места должны быть выведены в общие архитектурные соглашения на команду (какие линтеры используем, как ставим отступы и пр.)


⌘ эффект от код ревью

− растёт время на разработку: уходит время на найти ревьюеров и иногда пройти несколько итераций над кодом

+ твои типичные вопросы на код-ревью возвращаются в твои пулл-реквесты — нарабатывается паттерны и начинаешь думать про типовые кейсы заранее

+ повышение качества среднего пулл-реквеста — на ревью не поступает откровенно плохих пулл-реквестов, где какой-то треш или забыли подумать

🤓 Martin Fowler в гостях Pragmatic Engineer

https://youtu.be/CQmI4XKTa0U

Мартину уже за 60 лет, из которых он 40 с лишним считает себя инженером; когда опыт исчисляется десятками, то накапливается тот уровень насмотренности, когда можно сравнивать эпохи и видеть глобальные тенденции

⌘⌘⌘

по своему масштабу Мартин сравнивает нынешний скачок с переходом программистов с ассемблера на языки более высокого уровня

сам Мартин не имеет ничего против вайбкодинга как такового (тут он понимает «вайбкодинга» именно как безоглядное принятие любого результата ллм-ки без глубокого осознания написанного), однако чётко ограничивает зону его возможностей: небольшие проекты, прототипы на выброс и т.д.

главный недостаток слепого вайбкодинга — отсутствие цикла обратной связи. не пропуская через себя этот код, нет процесса обучения. новые знания не налипают и не копятся

получается вайбкодер через год останется ровно с таким же уровнем и потом его сменит просто другой вайбкодер (помоложе); или просто следующее поколение агентов, которым не нужна будет «простилка» между клавиатурой и креслом

⌘⌘⌘

при этом в прототипировании аи-помощник показывает небывалые приросты в продуктивности. приводят пример инженера из Антропика, который за 2 дня собрал 20 прототипов, итеративно проверяя и валидируя их об команду.

здесь быстрый цикл обратной связи помог им сразу на практике осознать простанство потенциальных вариантов и найти подходящие векторы для развития, отбросив остальные

⌘⌘⌘

ещё одна проблема ллм-ок — полная неспособность решить задачу «переименования класса»; по своему дизайну она скорее перепишет половину кодовой базы, чем поправит в трёх местах нужное название

при этом современные иде уже давно научились это делать, правда со своей подкапотной магией (которой, видимо, и не хватает ллм-кам)

⌘⌘⌘

общий подход к результатам работы моделей — ничему не верить, всё проверять; вдумчиво читать, внимательно вникать, нещадно тестировать, чтобы добавить чуток детерменированности их безудержной креативности.

и тогда действительно можно получать какой-то профит от совместной работы

🎧 Data Platform T-Bank

послушал подкаст с СТО платформы данных Т-Банка
https://t.me/book_cube/3766

для понимания масштаба

→ 15К MAU пользователей платформы (при условных 18К всех сотрудниках инхаус — это довольно большое проникновение)

→ всю платформу поддерживает ~230 человек

→ сторадж — около 15–20 петабайт;

→ компьют — порядка 100К ядер

→ внутри ~20 тысяч объектов

основная аналитическая СУБД — Greenplum: около 10 кластеров от 30 до 72 нод в каждом


проблемы с текущей архитектурой

⌘ Greenplum имеет ограничение на количество параллельных запросов, которые он может обработать эффективно; считается, что это около ста запросов.

⌘ система требует постоянного мониторинга и ручного управления распределением нагрузки между кластерами. это включает решение «задачки рюкзака», когда необходимо определить, сколько нагрузки можно распределить на каждый кластер с учётом их мощности и возраста оборудования

⌘ архитектура с Greenplum оказалась сложной и нестабильной; даже небольшие сбои могут привести к необходимости переключения пользователей на резервные кластеры, что не всегда проходит гладко и может вызывать негативный опыт

⌘ несмотря на то, что данные распределяются по сегментам, возникают проблемы с их равномерным распределением и обработкой, особенно при больших объёмах и высокой нагрузке


планы дальше

со временем стало понятно, что текущая архитектура не выдерживает всё возрастающий масштаб платформы

теперь задача — рядом с уже летящим самолётом построить ещё один, новый; и как-то аккуратно пересадить «пассажиров» с одного борта на другой

в качестве новой целевой архитектуры выбрали стандартный набор:
iceberg + s3 + spark + trino

по отзывам пользователей где-то новая архитектура отрабатывает дольше, чем старая; но по наблюдениям, она в целом надёжнее и готова к дальнейшему масштабированию в принципе


@data_days

а освежить в голове
результаты опроса 2024 можно тут
https://newhr.org/data/research-analysts-2024

NewHR в очередной — уже шестой! — раз проводит опрос про работу аналитиков

я бы тоже прошёл, но я, к сожалению, я не аналитик

если тоже любите читать результаты таких исследований, можно инвестировать 20 минут в опрос

новый опрос за 2025 год тут

🐤 джуны, LLM и Shopify

в интернетах есть тезис, что с внедрением LLM джуны будут не нужны: мол, llm-агент сам как крайне усердный и очень производительный джун

→ и тогда со временем всю базовую джуновскую работу будут делать llm-агенты

⌘⌘⌘

противоположный тезис высказывает Farhan Thawar, Head of Engineering в Shopify (всё время читаю как Spotify, приходится себя одёргивать и перепроверять)

Shopify среди меня известен своим мега-крутым фаундером — Tobias Lütke; слушал его в Lenny's Podcast — создаёт впечатление очень здравого и продвинутого человека

кроме того, про него неоднократно упоминал Lex Fridman, что даёт ещё сколько-то очков этому джентельмену и культуре в его компании

⌘⌘⌘

ещё добавляет веса этой дискуссии фигура ведущего. Gergely Orosz — автор рассылки The Pragmatic Engineer (а теперь ещё и одноимённого подкаста)

Gergely каждый раз глубоко копает тему, проводит предварительный ресёрч и «наводит справки». многие вопросы он задаёт «а вот твои коллеги, говорят… ».

ну и в целом гигантский опыт Gergely в бигтехе позволяет ему фильтровать всякий булшит, если вдруг тот появится.

⌘⌘⌘

про адоптинг аи-тулзов

господин Farhan замечает, что Шопифай был первым пользователем Copilot за пределами GitHub — для этого просто надо было написать письмо напрямую СЕО и просто попросить.

сразу после того, как Томас Домк стал генеральным директором GitHub, он отправил ему электронное письмо с просьбой предоставить доступ к Copilot для инженеров Shopify.

хотя на тот момент инструмент не был доступен для коммерческого использования, Shopify всё равно получила к нему доступ. Компания пользовалась Copilot около двух лет без оплаты и в обмен предоставляла разработчикам GitHub обширные отзывы о работе инструмента.

⌘

при этом инженеры — не основная профессия, которая пользуется аи-тулзами: помимо них там продакты, аналитики, сейлзы и, конечно, саппорт.

почти для каждого инструмента внутри Шопифай есть MCP сервер и инструкция как его подключить к своему Курсору.

⌘

про найм стажёров

- в прошлый семестр (?) Шопифай нанял 25 стажёров

- Farhan уговорил своего СЕО в следующий семестр нанять ноль 1000 (!) стажёров

при этом на собесах разрешается использовать любые помогаторы. а скорее даже поощряется! подразумевается, что кандидат идёт в комплекте с ai-агентом и умеет пользоваться этими новыми технологиями — без них он просто отстанет от будущих коллег

логика для такого найма простая — Farhan видит, что новое поколение думает по-другому. они уже буквально ai-native, они учатся и заканчивают вузы, когда chatgpt уже стал нормой, поэтому могут предложить нестандартные решения для задач.

и само наличие таких людей в командах помогает «старичкам» узнавать новое и где-то по-другому смотреть на свой опыт.

в общем, Шопифай делает ставку на ai-стажёров

подкаст есть на ютубе
https://youtu.be/u-3IILWQPRM

@data_days

🤑 yet another zarplaty

классный пример коллаборации:

Саша Варламов собрал парсер и визуализацию
https://t.me/data_bar/60

а Никита это дело автоматизировал
https://t.me/joni_in_web/21

в результате получаем работающий проект и возможность посмотреть живую аналитику зарплат — на скрин вынес кусочек деша с фильтром по аналитике.

что мне нравится в подобных проектах:

1. проактивность — сам придумал, сам спроектировал, сам затащил, сам отчитался в блог

2. коллаборация — организоваться вдвоём гораздо сложнее, чем сделать одному, но эффект может быть круче

3. полезность, направленная наружу: когда решал свою задачу, а польза — всем

в общем, смотрите деш и ставьте лайки Саше с Никитой)

🦆 прилетят орлы и поднимут прод

когда в работе встречаю какую-то проблему, то первым делом хочется написать в командный чатик, типа «ребята, там на дисках место заканчивается»

со стороны это читается как «там на дисках место заканчивается … кто-нибудь сделайте что-нибудь!»

получается, что я привлекаю внимание всех коллег к проблеме и тогда один из коллег (кстати, кто?) должен оторваться от своего текущего контекста и пойти расследовать эту проблему, потратить своё время и внимание, и найти причину и потенциальное решение

но если я уже видел проблему, почему бы самому не посмотреть глубже, потратить какое-то время на расследование и прикинуть варианты решений. и в результате прийти в чатик уже не с проблемой, а с каким-то решением!

- понятно, что расследование может занять больше нескольких минут

- понятно, что решение может быть тоже не простое или даже несовсем правильное

в этих случая включаются уже устоявшиеся процессы в команде; но базовый принцип остаётся — не рассчитывать, что в последний момент прилетят орлы и решат все проблемы

иными словами, приходи с решением, а не проблемой!

2/2

в общем, много чего для нужд аналитики в удб уже есть, но чего там нет — надо додумывать самому)

из озвученного — нет поддержки триггеров и хранимых процедур. плюс конечно как у любого нового инструмента нет такого богатого набора аддонов и инструментов как у того же постгреса, то же относиться и к коммьюнити.

плюс в документации есть отдельная сноска чего пока нет в колоночных таблицах

> В настоящий момент реализована не вся функциональность колоночных таблиц
https://ясубд.рф/docs/ru/concepts/datamodel/table.html#column-oriented-tables

(надеюсь, документация просто чуток отстаёт от новых фич)

⌘⌘⌘

в теории звучит хорошо — один инструмент лучше, чем пять разных (при прочих равных)

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

либо по-быстрому настроить быстрые базовые витрины: наклепать каких-то простых трансформаций операционных данных в несколько колоночных таблиц и вывести на деши. но такое решение рискует быстро превратиться в какой-то теневой двх — надо иметь в уме следующий шаг и вовремя перевести на продовые рельсы с подобающими моделями.

⌘

с другой стороны — амбициозная задача максимально широко покрыть кейсы других узкоспециализированных баз данных заведомо имеет явный трейдоф. общий инструмент не будет так хорош для каких-то задач, как явно заточенный под конкретно эти задачи.

то есть зоопарк инструментов остаётся, но задачи и кейсы могут чуток перераспределиться — polyglot persistance пока не отменяем
https://martinfowler.com/bliki/PolyglotPersistence.html

либо можно принять явное архитектурное решение, чтобы перейти с условного гринплама на удб, чтобы снизить косты на поддержку, вместе с этим получая какие-то ограничения по функциональности.

в любом случае кажется, что ниша дата-лейка как будто бы в безопасности — хранить и обрабатывать петабайт в том же yt должно быть дешевле, чем в удб. в силу архитектуры и заявленных характеристик систем.

📦 YDB + OLAP = ?

ydb — это отлп-база данных от Яндекса. основная характеристика — нативная распределённость с поддержкой транзакции. из свойства распределённости следует высокая доступность и гибкая масштабируемость. помимо олтп-базы там есть ещё такая сущность как топики, с кафка-совместимым апи.

и вот недавно ребята объявили, что ещё они идут в сторону олап-нагрузки. собирая эдакую всё-в-одном базу: с одной стороны у вас сервисы, с другой аналитика, а между ними нативный сдс-процесс, прямо не выходя из контура бд.

https://yandex.cloud/ru/blog/posts/2024/12/ydb-dwh


⌘⌘⌘

интересно посмотреть со стороны аналитики и нашего двх-мира.

→ очереди настраиваются через SQL-команды (кажется, в кликхаусе можно так же настроить читателя для кафки). в целом удобно, но хз как будет поддерживать в масштабе сотен таких топиков-читателей.

→ изначально идут по пути раздельного хранения и обработки — соответственно, можно независимо масштабировать под текущую потребность.

→ добавили колоночное хранение c массивно-параллельными вычислениями через векторные движки

→ стоимостной оптимизатор (cost-based) для плана запроса с подбором оптимального порядка и алгоритма джойнов

→ поддержка скл-хинтов для ручных подсказок оптимизатору

→ спиллы на диск для больших вычислений

→ нативная поддержка охлаждения данных в s3 (автоматическое гибридное хранение для колоночных таблиц)

→ сбор статистики для таблиц

→ predicate pushdown для оптимизации чтения

→ федеративные sql-запросы из разных источников

→ пулы ресурсов — разделение под разные нагрузки

→ асинхронная репликация между удб-инстансами


по мотивам обзорного доклада про новости удб с конфы yandex scale
https://vkvideo.ru/video-200452713_456239488

и недавнего вебинара, посвященного релизу ydb dwh (ссылки не осталось есть ссылка, есть презентация)

1/2

🗿 подкасты про карьеру

специально для постоянной читательницы этого блога — Натальи — ни к чему не обязывающая подборка подкастов на тему карьеры, её смены и всякого такого >_>

подкасты хороши тем, что можно слушать на фоне, удобно чтобы ненапряжно набраться чужого опыта. пока остальные процессы ещё только готовятся или обдумываются

⌘⌘⌘

первым делом, конечно, стоит упомянуть про подкаст «собес» — в последнем сезоне они делают эпизоды в формате мок-собесов. это когда реальный рекрутер под реальную вакансию собесит кандидата прямо в эфире, а потом дают обратную связь и говорят что можно подкрутить.

на своём опыте ощутил, что полезно послушать со стороны как звучит все эти привычные фразы и что излишняя скромность на интервью только мешает и будет интерпретирована не пользу кандидата. это сложно принять в теоретическом вакууме, надо просто послушать N раз других людей.

→ https://libolibo.ru/sobes


⌘⌘⌘

я бы сказал, что подлодка — мастхев в подкаст-приёмнике айтишника. как шутят сами ведущие, когда законичились темы про айти, начались про всё остальное, поэтому в длинном списке эпизодов можно найти темы под любые запросы.

в недавнем выпуске собрался весь состав ведущих и обсудили смену работы, переход из кодеров в менеджеры и обратно (!), переходы внутренние и внешние. кажется на всех они собрали все возможные кейсы и всё подробно обсудили. м-м-мякотка!

→ https://t.me/podlodkanews/1440


⌘⌘⌘

и отдельно на тему аналитики два проекта от ребят из тбанка.

первый про аналитику — тоже можно повыбирать эпизоды с привлекательной темой. мне понравился выпуск про офлайн-ритейл с представителем Магнита. ребята в унисон разгоняли про темы как вообще анализировать штуки из реального мира, когда надо прямо ножками дойти, что-то поменять, а потом ещё как-то измерить результат. масштаб внушает трепет, а подходы — уважение.

→ https://t.me/eto_schitaetsya/477

и вот только что узнал про ещё один их подкаст, добавил себе в послушать. подводка звучит интересно. тематика, видимо, связана с продуктами их банка, но иногда зовут и людей извне.

→ https://t.me/karty_dengi_product/112


⌘⌘⌘

ещё один пример с другой стороны, когда продукт надо не только анализировать, но и управлять им. кто такие продакты, зачем они нужны, где их место в общей организации и как наладить диалог с разработкой.

→ https://music.yandex.ru/album/22481935/track/129159864


⌘⌘⌘

§ что ещё можно послушать-посмотреть условному бизнес-аналитику в условном финтехе?

что вообще понимают в разных компаниях под «бизнес-аналитиком»? в моей голове есть системные аналитики, которые ближе к данным и процессам, а есть продакты, которые ближе к бизнесу. а «бизнес-аналитиком» получается, это что-то между этими двумя.