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 это прям в нашу команду…»

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

📢 ищем дата-коллег к себе в Яндекс Финтех → дата инженеры 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 ⌘⌘⌘ § что ещё можно послушать-посмотреть условному бизнес-аналитику в условном финтехе? что вообще понимают в разных компаниях под «бизнес-аналитиком»? в моей голове есть системные аналитики, которые ближе к данным и процессам, а есть продакты, которые ближе к бизнесу. а «бизнес-аналитиком» получается, это что-то между этими двумя.