🏦 новый_план(2)_final

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

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

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

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

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

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

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

в общем, по всем пунктам можно поставить галочки:

⌘ посмотрел в сторону валютных удаленок (но не пошёл дальше)

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

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

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

и как итог «вернулся назад» в Яндекс, на этот раз в Яндекс Банк, он же Финтех (надеюсь, уже все открыли счёт, научились сплитить, и подключили авто-пополнение))

и спасибо всем, кто писал и шерил вакансии! в такие моменты поддержка особенно важна и к тому же крайне приятна <3

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

что же там оптимизировать, спросите вы? сейчас расскажу:

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

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

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

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

сравним две последовательности разгрузки:

ложка → вилка → нож → нож → вилка → ложка

ложка → ложка → вилка → вилка → нож → нож

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

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

можно пойти дальше и провести аналогии в выборе момента для упорядочивания элементов с двумя известными известными подходами: запись inplace в B-Tree или append-only LSM; то есть либо мы заранее оптимально раскладываем элементы (тратя какой-то ресурс на это), либо мы сваливаем как есть, а разбор элементов оставляем на потом (ровно как и траты ресурсов).

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

⌘ ⌘ ⌘

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

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

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

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

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

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

⌘⌘⌘

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

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

→ https://libolibo.ru/sobes


⌘⌘⌘

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

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

→ https://t.iss.one/podlodkanews/1440


⌘⌘⌘

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

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

→ https://t.iss.one/eto_schitaetsya/477

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

→ https://t.iss.one/karty_dengi_product/112


⌘⌘⌘

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

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


⌘⌘⌘

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

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

📦 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

2/2

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

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

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

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

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

⌘⌘⌘

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

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

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

⌘

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

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

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

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

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

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

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

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

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

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

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

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

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

🤑 yet another zarplaty

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

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

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

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

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

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

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

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

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

🐤 джуны, 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

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

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

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

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

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

🎧 Data Platform T-Bank

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

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

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

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

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

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

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

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


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

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

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

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

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


планы дальше

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

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

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

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


@data_days

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

https://youtu.be/CQmI4XKTa0U

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

⌘⌘⌘

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

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

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

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

⌘⌘⌘

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

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

⌘⌘⌘

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

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

⌘⌘⌘

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

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