ch
Feedback

不要被骗子欺骗!Telemetrio 会找到并标记这些频道 👉 如果想查看标记,请订阅

data будни

data будни

前往频道在 Telegram

работаю инженером данных и пишу в основном про это. Профильные ссылки с коротким резюме (статьи, доклады, подкасты), иногда «софтовое» — например, про поиск работы.

显示更多
1 464
订阅者
无数据24 小时
-27 天
-530 天

正在加载数据

标签云
无数据
有任何问题?请刷新页面或联系我们的客服。
进出提及
---
---
---
---
---
---
吸引订阅者
10月 '26
十月 '26
+39
在0个频道中
九月 '260
在0个频道中
Get PRO
八月 '260
在0个频道中
Get PRO
七月 '260
在0个频道中
Get PRO
六月 '260
在0个频道中
Get PRO
五月 '260
在0个频道中
Get PRO
四月 '260
在0个频道中
Get PRO
三月 '260
在0个频道中
Get PRO
二月 '260
在0个频道中
Get PRO
一月 '260
在0个频道中
Get PRO
十二月 '250
在0个频道中
Get PRO
十一月 '250
在0个频道中
Get PRO
十月 '250
在0个频道中
Get PRO
九月 '250
在0个频道中
Get PRO
八月 '250
在0个频道中
Get PRO
七月 '250
在0个频道中
Get PRO
六月 '250
在0个频道中
Get PRO
五月 '250
在0个频道中
Get PRO
四月 '250
在0个频道中
Get PRO
三月 '250
在0个频道中
Get PRO
二月 '250
在0个频道中
Get PRO
一月 '250
在0个频道中
Get PRO
十二月 '24
+49
在1个频道中
Get PRO
十一月 '240
在2个频道中
Get PRO
十月 '240
在0个频道中
Get PRO
九月 '24
+29
在0个频道中
Get PRO
八月 '24
+164
在1个频道中
Get PRO
七月 '240
在1个频道中
Get PRO
六月 '240
在1个频道中
Get PRO
五月 '24
+10
在1个频道中
Get PRO
四月 '24
+33
在1个频道中
Get PRO
三月 '24
+17
在0个频道中
Get PRO
二月 '24
+49
在1个频道中
Get PRO
一月 '24
+77
在1个频道中
Get PRO
十二月 '23
+78
在1个频道中
Get PRO
十一月 '230
在0个频道中
Get PRO
十月 '230
在0个频道中
Get PRO
九月 '23
+11
在0个频道中
Get PRO
八月 '23
+20
在0个频道中
Get PRO
七月 '23
+20
在0个频道中
Get PRO
六月 '23
+15
在0个频道中
Get PRO
五月 '23
+21
在0个频道中
Get PRO
四月 '23
+19
在0个频道中
Get PRO
三月 '23
+17
在0个频道中
Get PRO
二月 '23
+16
在0个频道中
Get PRO
一月 '23
+26
在0个频道中
Get PRO
十二月 '22
+15
在0个频道中
Get PRO
十一月 '22
+33
在0个频道中
Get PRO
十月 '22
+27
在0个频道中
Get PRO
九月 '22
+16
在0个频道中
Get PRO
八月 '22
+20
在0个频道中
Get PRO
七月 '22
+17
在0个频道中
Get PRO
六月 '22
+26
在0个频道中
Get PRO
五月 '22
+24
在0个频道中
Get PRO
四月 '22
+28
在0个频道中
Get PRO
三月 '22
+37
在0个频道中
Get PRO
二月 '22
+12
在0个频道中
Get PRO
一月 '22
+133
在0个频道中
Get PRO
十二月 '21
+117
在0个频道中
Get PRO
十一月 '21
+89
在0个频道中
Get PRO
十月 '21
+42
在0个频道中
Get PRO
九月 '21
+17
在0个频道中
Get PRO
八月 '21
+53
在0个频道中
Get PRO
七月 '21
+107
在0个频道中
Get PRO
六月 '21
+10
在0个频道中
Get PRO
五月 '21
+270
在0个频道中
日期
订阅者增长
提及
频道
26 十月0
25 十月0
24 十月0
23 十月0
22 十月0
21 十月0
20 十月0
19 十月0
18 十月0
17 十月0
16 十月0
15 十月0
14 十月0
13 十月0
12 十月0
11 十月0
10 十月0
09 十月0
频道帖子
🤩 delirious dhh итак, прослушал ~5ч одного небезызвестного программиста с сильными взглядами; ушло у меня на это всего где-то неделя: пара походов в спортзал и комьютов. чем примечательно это интервью? во-первых, dhh известен своими взглядами за чистоту кода; это тот ещё художник и скульптор, который «вручную вытачивал» каждый кусочек своих программ. за свою карьеру с 90х он успел понабраться и опыта, и мнений во-вторых, не далее чем год назад, тот же самый dhh приходил в тот же подскаст и уверял, что этим вашим агентам ещё довольно далеко до настоящего года: так — автокомплит, не более! получается такой идеальный маркер для 2025-26 годов - даже самые сильные программисты стали признавать возросшие возможности и качество кода от агентов.
There are decades where nothing happens and weeks where decades happen
и вот с ноября 2025 dhh ведёт отсчёт, когда он впервые поймал себя на том, что выхлоп агента _достаточно_ похож на то, что он бы сам написал отметил тезис, что по мнению dhh большинство белковых программистов тоже пишут довольно посредственный код; не говоря уже о том, что им зачастую лень уделять много времени архитектуре или тестам. поэтому нет особого смысла гнать на «нейрослоп» — агенты хотя бы не будут отпираться и готовы пройти стопицот итераций, чтобы его исправить. а ещё написать сколько угодно тестов и обложить всё понятной и актуальной документацией. ⌘ в проектах dhh есть места, где он даже не смотрит на итоговой код — типа если оно работает по заданным спекам, то детали не важны. при этом в ядро проектов он внимательно ревьюит каждую строку (хоть и не пишет сам теперь) и чтобы понимать масштаб его текущих амбиций — он теперь пишет не очередной веб-фреймворк, а прям собственную ос, пускай и осованную на линуксе. это агентно-центричная система: её пишут агенты (под надзором dhh) для удобства использования другими агентами ⌘ спросите вашего агента про детали интервью — dhh у лекса фридмана от августа 2026

2
мне кажется последние два интервью отлично смотрятся вместе и дополняют друг друга >_> и отдельно мысль, которая где-то проговаривалась в этих интервью: токены — новый вид бенефита для сотрудников. большие компании готовы вливать миллионы в токены для своих разработчиков. а сами поставщики фундаментальных моделей в принципе ограничены только внутренними мощностями для своих сотрудников. в подкастах Кирилла Мокевнина @orgprog упоминали, что в долине у каждого второго безлимит на модели OpenAI / Anthropic по тем или иным каналам
950
3
🥷 DHH об agent-first подходе DHH — известный ии-скептик и сторонник написания кода вручную; в своём сетапе он не использует IDE с их подсказками и навигацией по коду — всё набивает ручками (и радуется) ещё DHH известен своими сильным мнением и радикальными взглядами — он говорит что думает, не взирая на мнения большинства или отдельных авторитетов недавно зашёл к Pragmatic Engineer на интервью https://youtu.be/JiWgKRgdgpI и вот наступил действительно переломный момент: ⁃ июль 2025 — DHH не верит и не использует агентов ⁃ январь 2026 — DHH переходит на agent-first разработку что поменялось? вышли модели, которые выдают достаточно хороший результат, которые при минимальных доработках можно шипать в прод. если уже DHH «распробовал» агентский подход — значит, результаты работы становятся действительно достаточно хорошими ⌘⌘⌘ DHH делится историей, как агент помогает ему разбирать ишью в его проекте на Гитхабе: из 250 открытых пулл-реквестов агент за пару часов разобрал 100. какие-то единицы можно было мержить «как есть» — они уже были достаточно хорошего качества; другую часть агент провалидировал как «правильно опознанный баг, но реализация не идеальная» — такие он адаптировал/переписал согласно принятому стилю репо; и ещё часть агент смог аргументированно зареджектить. при этом сам DHH потратил бы на эту работу несколько дней (и не получил бы большого удовольствия от неё).
861
4
🦄 руководитель Claude Code об AI в разработке послушал интервью Бориса Чёрного в подкасте Ленни. Борис написал первую версию Claude Code и теперь руководит этим направлением в Anthropic. https://youtu.be/We7BZVKbCVw по их данным сейчас уже 4% всех коммитов в Гитхаб создаются через Claude Code (ожидают 20% к концу года) интересно, что первую версию Claude Code Борис сделал прошлой весной и это не был сиюминутный успех; популярность инструмента росла постепенно и взрывной рост случился после выхода модели осенью (Опус 4.5 кажется) и с ноября 2025 Борис не написал ни строчки кода вручную — всё через Клода; так же приводит в пример «лучших программистов Spotify», мол, они тоже больше не пишут код руками. Борис видит, что в будущем профессии будут теснее переплетены: не будет программистов или дизайнеров, все будут builder («создатель»?) — задавать ви́дение, раздавать задачи аи-агентам и принимать результат их работы. этот сдвиг парадигмы ставят в один ряд с изобретением печатного станка и освобождением пицсцов от монотонной работы; и с переходом от программирования на перфокартах к следующему уровню.
878
5
📁 про культуру ведения тикетов продолжаю рассказывать про внутрянку нашей команды, привлекая ваше внимание к активным вакансиям >_> > важный дисклеймер: это не я, это всё наш техлид Кирилл (я тут только документирую и выношу) думаю, все видели тикеты, прочитав которые, осталось непонятным что́ надо сделать; или задачи, где ты вроде сделал что было написано, но оказалось, что нужно было не то и не так ¯\_(ツ)_/¯ мы в команде стараемся придерживаться культуры ведения задач — попробую описать как я это вижу ⌘⌘⌘ начнём с того, что создать хороший тикет - это отдельная работа; чтобы понятно описать что надо сделать, надо как минимум представлять проблему и целевое решение есть базовый паттерн, которого мы придерживаемся: ⁃ контекст ⁃ проблема ⁃ что сделать ⁃ допматериалы небольшие тикеты могут пропускать 1-2 пункта; а большие эпики будут наоборот побольше ⌘⌘⌘ «хорошие» задачи формулируются через глаголы: сделать …, добавить …, исправить …, пересчитать … однозначно указан объект изменения: таблица, таск, модуль и пр. есть перечень связанных действий: в конце …сделать миграцию, …пересчитать историю, и пр. ⌘⌘⌘ задачи на имплементацию проходят через общее техревью на входе, чтобы вместе посмотреть и проверить: ⁃ проверить, что мы в принципе хотим это делать (тут бинарно; пока без приоритетов) ⁃ задача описана понятно ⁃ ожидаемый результат считывается однозначно ⁃ (опционально) докапывается технических деталей цель такого пре-ревью проверить, что автор достаточно подумал про задачу и потенциальный исполнитель прочитает её ожидаемо паттерны задач помогают консистентно формулировать задачи внутри команды, а так же уменьшают количество догадок и уточнений на этапе разработки ⌘⌘⌘ если задача занимает больше нескольких дней, то внутри ожидаются отбивки по текущему статусы; размер отбивок пропорционален масштабу задачи причём не абстрактный статус «продолжаю работать», а короткий апдейт по фактам: сделано Х / осталось сделать У / открытые вопросы и блокеры … ⌘⌘⌘ в конце каждого тикет исполнитель оставляет резюме о проделанной работе «сделал таск, пересчитал историю, вот ссылка на итоговый объект» — всё что нужно знать о задаче, осознанно принять результат (и при необходимости вспомнить через полгода что тут было вообще) статусы и резюмешки повышают прозрачность работы для сторонних наблюдателей: заказчиков, тимлидов, а так же для себя из будущего прозрачность ведения задач особенно важна при ведении инцидентов — для них помимо резюме дополнительно надо сразу заполнить пост-морфем (инцидент-менеджемент у нас тоже есть — про него в другой раз) ⌘⌘⌘ лайк-шер-репост 👉 https://t.me/data_days/400
1 109
6
🦀 Clawdbot / Moltbot / OpenClaw там похоже намечается очередной качественный скачок аи-строения: австрийский программист написал автономного (?) ии-агента… и понеслось формат горячих новостей не мой любимый жанр, но это залетело в моё инфополе с трёх разных сторон: + Самат Галимов накидал ссылок для понимания контекста https://t.me/ctodaily/1995 + Pragmatic Engineer выпустил интервью с автором https://youtu.be/8lF7HmQ_RgY + ребята из Шмит16 собрались вместе где-то на Бали и скупают все доступные мак-мини, чтобы устроить ферму из таких аи-агентов сам автор бота не случайный мамкин вайбкодер — он начинал ещё с веб-приложений в начале 2000-х и потом перешёл на приложения айос для первого айфона. потом запилил как побочный продукт PSPDFKit — низкоуровневый парсер и рендере пдф-ок; продукт быстро стал приносить денег больше, чем основная работа и он переключился на него фултайм. потихоньку стартап разросся до 70 человек. продукт оказался достаточно востребованным, чтобы его покупали большие компании, и при этом достаточно сложным, чтобы они не могли его просто сделать внутри отсюда у автора большой опыт в построении сложных технических продуктов с большим количеством разношёрстных пользователей — надо успевать развивать продукт, ничего не поломав. ⌘⌘⌘ потом он (традиционно) выгорел и ушёл с радаров на три года, ничего не делал, ничем не занимался; и всё, чтобы «вернуться в интернет» в 2025-м —прямо на рассвете ии-агентов тут он офигел от новой технологии и по первым ощущениям от продукта он вспомнил все хорошие впечатления от программирования в итоге к осени он врубился в технологию настолько, что она стала для него «запойной»: работает на десятью пет-проектами сразу и 10 разных агентах / терминалах ⌘⌘⌘ поинты автора про подход к агентам: ⌘ замкнуть цикл обратной связи: задача → план → исполнение → отладка → тестирование → сверка с исходной задачей — всё это агент делает сам в бесконечной итерации, пока результат не достигнут ⌘ «новое» программирование — это верхнеуровневый дизайн, а не написание кода ⌘ из аи-агенты можно собирать локальные мини-команды (и не отдельные тулзы) ⌘ а синьорные инженеры — это теперь аи-менеджеры таких локальных команд для разработки ⌘⌘⌘ сам Moltbot / OpenClaw выглядит как проект на стыке аи- и арт-перфоманса автономный агент, которому явно дают доступ к локальной системе — это что-то за гранью привычного причём не каждый догадывается или может позволить себе отдельный мак-мини для инстанса бота — и они грузят их прям на своей основной тачке с другой стороны, эти эмерджентный и удивительные свойства агента проявляются как раз на богатой почве развитого локального окружения; на стерильной системе у него не будет истории переписки в мессенджер и почте, не на что смотреть) ⌘⌘⌘ агент имеет доступ к своим настройкам и исходному коду может менять свою конфигурацию, дописывать новые модули так, у бота не было модуля работы с голосовыми сообщениями, но, получив однажды голосяшку от автора, он через какое-то время дал релевантный ответ (оказалось, он прочитал хедер сообщения, нашёл нужный модуль, установил его и смог декдодировать пришедшее ранее сообщение) 🤯
905
7
📝 о код-ревью (часть 2) вижу тема ↑ код-ревью хорошо зашла — продолжаю накидывать ⌘ разные авторы — разные вопросы на ревью + во время онбордина на первые ревью обычно приходит тьма комментариев; чтобы проверить, что автор достаточно погрузился в новый проект, приходится спрашивать с самых банальностей: «почему тут за Т-2», «почему тут снепшото, а не апсёрт?» и т.д. + со временем у авторов набирается «репутация» — вопросы переходят на следующий уровень абстракций (или вовсе пропадают с типовых решений) ⌘ размер имеет значение − гигантский ПР на 500+ строк кода, затрагивающий множество модулей, имеет шанс погрязнуть в процессе ревью (не говоря уже про увеличенную вероятность пропустить багульку в прод) + а вот маленький атомарный ПР легко читать и требует адекватного количества когнитивной энергии ревьюера — а значит не вызывает сопротивления и обычно сходится предсказуемо быстро ⌘ не всегда есть «правильный» ответ + иногда вопрос — это предложение к дискуссии или просто любопытство почему выбран именно такой подход + хочется проверить, что автор продумал основные кейсы в предлагаемом решении ⌘ проблемы код-ревью − неконсистентность от ревью к ревью: даже один ревьюер может спросить разное, не говоря уже о нескольких − код-ревью не случается само — оно занимает время и тратит когнитивную энергию; это буквально конвейер и его надо явно планировать в своём календаре (получается всем в команде) − ну и в целом — растёт тайм-ту-маркет, в задачу надо закладывать время на схождение код-ревью ⌘ ожидания от код-ревью + код-ревью не должно быть узким горлышком — положительные эффекты складываются, когда вся команда ревьюит друг-друга (не только один тимлид по ночам и выходным) + LGTM — это тоже ответственность; если код падает прям сразу после релиза — вопросики будут как к автору, так и к ревьюеру; + всем в команде (включая ревьюера) потом поддерживать этот код — в общих интересах поддерживать кодовую базу в хорошем виде ⌘ пускай потеет машина + проверять синтаксис и опечатки должны машины, а не белковые мешки; поэтому эффективнее настроить линтеры, тесты, вот это всё + если команда уже сформировала код-стайл и обсудила архитектурные подходы, то будет проще формализовать и базовые проверки + а дальше пускай уже и аи-шные агенты ревьюят код помимо базовых линтеров и тестов — эти уже не только формально, но и по смыслу смогут накидать на вентилятор --- тем временем мы продолжаем искать дата-коллег — ваши репосты нам очень помогут
813
8
📢 ищем дата-коллег к себе в Яндекс Финтех → дата инженеры 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 буду рад ответить на вопросы в комментах или так же в личке
1 370
9
✍️ о код-ревью у нас в команде в прод только через пулл-реквесты и каждый пулл-реквест должно посмотреть двое коллег. моя личная статистика за 2025 год показывает 430 проведённых код-ревью. сложились какие-то мысли по этому поводу, ниже пытаюсь собрать их вместе. ⌘ зачем вообще нужно код-ревью + это вторая пара глаз с иным контекстом и уровнем погружения: автор и ревьюер смотрят на код в разных когнитивных режимах → ловятся разные ошибки + передача знаний в рамках команды: «применяем вот такие паттерны, а вот так не делаем» → в среднем качестве кода постепенно улучшается + барьер против энтропии и деградации кодовой базы: без должного присмотра любой проект постепенно превращается в трудно поддерживаемое болото ⌘ как бывает без код ревью когда команда небольшая, да ещё и допустим без большого опыта, то большой соблазн поспешить с реализацией или смалодушничать при проектировании → в результате получается нагромождение модулей, которые через время проще сжечь, чем исправить ⌘ как задавать вопросы на код-ревью + открытые вопросы лучше чётких предложений — во-первых, ревьюер сам можем не осознать что здесь происходит, а, во-вторых, + любой код может быть написан множеством способов — прежде чем предложить что-то поправить, надо понять а точно ли оно будет объективно лучше? или просто «ревьюер привык писать по-другому» + спорные места должны быть выведены в общие архитектурные соглашения на команду (какие линтеры используем, как ставим отступы и пр.) ⌘ эффект от код ревью − растёт время на разработку: уходит время на найти ревьюеров и иногда пройти несколько итераций над кодом + твои типичные вопросы на код-ревью возвращаются в твои пулл-реквесты — нарабатывается паттерны и начинаешь думать про типовые кейсы заранее + повышение качества среднего пулл-реквеста — на ревью не поступает откровенно плохих пулл-реквестов, где какой-то треш или забыли подумать
1 024
10
🤓 Martin Fowler в гостях Pragmatic Engineer https://youtu.be/CQmI4XKTa0U Мартину уже за 60 лет, из которых он 40 с лишним считает себя инженером; когда опыт исчисляется десятками, то накапливается тот уровень насмотренности, когда можно сравнивать эпохи и видеть глобальные тенденции ⌘⌘⌘ по своему масштабу Мартин сравнивает нынешний скачок с переходом программистов с ассемблера на языки более высокого уровня сам Мартин не имеет ничего против вайбкодинга как такового (тут он понимает «вайбкодинга» именно как безоглядное принятие любого результата ллм-ки без глубокого осознания написанного), однако чётко ограничивает зону его возможностей: небольшие проекты, прототипы на выброс и т.д. главный недостаток слепого вайбкодинга — отсутствие цикла обратной связи. не пропуская через себя этот код, нет процесса обучения. новые знания не налипают и не копятся получается вайбкодер через год останется ровно с таким же уровнем и потом его сменит просто другой вайбкодер (помоложе); или просто следующее поколение агентов, которым не нужна будет «простилка» между клавиатурой и креслом ⌘⌘⌘ при этом в прототипировании аи-помощник показывает небывалые приросты в продуктивности. приводят пример инженера из Антропика, который за 2 дня собрал 20 прототипов, итеративно проверяя и валидируя их об команду. здесь быстрый цикл обратной связи помог им сразу на практике осознать простанство потенциальных вариантов и найти подходящие векторы для развития, отбросив остальные ⌘⌘⌘ ещё одна проблема ллм-ок — полная неспособность решить задачу «переименования класса»; по своему дизайну она скорее перепишет половину кодовой базы, чем поправит в трёх местах нужное название при этом современные иде уже давно научились это делать, правда со своей подкапотной магией (которой, видимо, и не хватает ллм-кам) ⌘⌘⌘ общий подход к результатам работы моделей — ничему не верить, всё проверять; вдумчиво читать, внимательно вникать, нещадно тестировать, чтобы добавить чуток детерменированности их безудержной креативности. и тогда действительно можно получать какой-то профит от совместной работы
1 239
11
🎧 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
1 860
12
🥸 про коучинг наша встречу по наведению порядка в проекте через вопросы (два поста выше ↑) напомнила мне профессиональные коучинговые сессии — недавно я попробывал новый для себя инструмент для пары личных проектов. роль коуча как раз в безоценочной помощи в наведении порядка в хотелках и стремлениях (= проектах). Получается это такой инструмент для диагностики — прикладываешь его к нужному месту, отвечаешь на его вопросы → профит. ключевой фактор здесь именно в отсутствии оценки, т.е. коуч убирает себя как личность из процесса; он не оперирует терминами «хорошо» и «плохо» — только задаёт вопросы и пытается вместе с тобой найти твои конечные цели и приложить их к какому-то плану (а потом и к сделанным делам по этому плану) по себе знаю, насколько это сложно не пытаться давать совет после каждой реплики собеседника (ведь я же ЗНАЮ КАК ЛУЧШЕ!!1) я занимался с Димой Черненьковым и могу его смело рекомендовать. Дима — мой добрый приятель и по совместительству сертифицированный коуч (а ещё фанат кулинарии, спикер, участник подкастов и жонглёр примерно восьмью способами) Тем, у кого нет возможности на работе побить об кого-то свои проекты или есть личные проекты где могла бы пригодиться помощь извне — тем может быть полезно познакомиться с Димой. Начать можно с его канала, где встречаются советы о прокрастинации, заметки из книг и конспекты лекций (отдельный лайк за тематические мемы между) 🖤
347
13
О приоритетизации задач Дорогой читатель Алексей Махоткин @squadette в коментах к прошлому посту прислал релевантную заметку (спасибо большое! люблю такое, шлите ещё). Мой ограниченный опыт подтверждается богатым (подозреваю) опытом автора из ЖЖ — ошибка довольно распространённая. https://gaperton.livejournal.com/36144.html ⁃ неопределённость в проектах есть всегда; ей можно управлять (хотя бы наблюдать и иметь в виду). ⁃ неопределённость к концу проекта должна снижаться ⁃ мутные задачи делать сложно и неохотно, поэтому есть склонность откладывать их на конец проекта. ⁃ вместе с тем, в сложных задачах скрыто куча потенциальной неопределённости — и лучше бы узнать о них пораньше ⁃ иначе неопределённость проявится на 90% готовности проекта (тот случай когда внезапно появляются «вторые 90% проекта»). 👆
379
14
Польза вопросов Последние пару месяцев активно копаю в сторону стриминга. Последний проект — перевод одной отдельновзятой поставки данных на Flink. В какой-то момент настолько увлёкся и закопался, что потерял общий ориентир; ви́дение стало слишком узким и застал себя за тем, что «искал ключи где светло, а не там где их мог потерять» Благо дело было перед регулярной встрече 1-1 и на помощь пришёл наш бравый лид (привет, Саша!). Через ряд последовательных вопросов у него получилось упорядочить хаос в моей голове: вспомнить о цели проекта, предстоящих этапах и когда это должно быть сделано. прошли от обратного: дедлайн условно 1 сентября — значит, 31 августа должен быть релиз? нет, релиз нужен минимум за неделю до этого, чтобы посмотреть как работает на продовых данных и отловить возможные косяки окей, значит релиз нужен за неделю до этого. Что должно быть в релизе? парсинг входящих джейсонов по схеме и пара джойнов со стейтом (плюс сопутствующий обвес из Графины, настроенных доступов, алертов и пр.) я был сосредоточен на парсинге, потому что это самое простое 🤡 в то время как часть с джойнами была сложной (и я её оставил на потом). Мы проговорили, что логичнее начинать как раз с реализации джойнов, чтобы раньше узнать о всех сложностях и начать их решать. в результате беседы был готов расписанный план со всеми промежуточными этапами от сейчас и до дедлайна интересно, что Саша мог вообще быть не в курсе проекта — все технические и проектные вводные были от меня как участника процесса; он просто задавал нужные вопросы в правильном порядке
573
15
Нет правильных решений в школе было просто: тебе дают пример, ты что-то там решаешь на листочке и выдаёшь ответ — «42!». И сссразу получаешь обратную связь «правильно / неправильно». дальше всё получается сложнее. возьмём кластер Кликхауса, которому плоховато от нагрузки. Что с этим можно сделать? можно добавить ещё хостов, можно апнуть текущие хосты, можно добавить шардирование. с другой стороны можно проверить нагрузку; что больше грузит систему — запись или чтение? может мы пишем что-то лишнее, т.е. оптимизировать запись. Или у нас Даталенс с Графаной спамят по стопицот одинаковых запросов в секунду? здесь нет «правильного» ответа. По-хорошему надо бы зарыться в логи и разобраться что происходит, составить план и его придерживаться. Скорее всего придём не к одному решению, а к комбинации из нескольких. в любом случае, технический расклад по текущей нагрузке пригодится потом, когда придётся защищать запрос на дополнительное железо. А если даже нет, то всегда полезно самому понимать как оно устроено под капотом. и даже после того, как сделан анализ текущей нагрузки, проработы альтернативные варианты, сделала приоритезация и первые изменения пошли в прод, не придёт никакая технофея и не скажет «молодец! всё правильно сделал» — ничего подобного! просто продолжаешь наблюдать растущую нагрузку и как предыдущие решения на неё влияют. Оп! — один хост ушёл в maintenance, как система держится? CPU на живых машинах ушло в полочку на 100%, но лаг по данным не растёт. Уже неплохо! Если бы не предыдущие оптимизациия, было бы точно хуже. нет «правильных» решений — есть только более оптимальные в текущем контексте.
333
16
#послушано 🎧 Rework: AI! GPT! What a time to be alive! речи фаундеров 37 Signals просто как бальзам на мою fomo-душу! Для тех, кто переживает, что «поезд AI ушёл» и его уже не догнать, ребята предлагают взглянуть с другой стороны: в этой отрасли настолько быстро всё меняется, что период полураспада навыков — 48 часов! Если вы были мастером по MidJourney версии 3, то в пятой версии уже всё поменялось и буквально надо вкатываться заново. Поэтому можно смело начинать вкатываться с версии 5 (или 10!) — и все будут примерно на том же уровне. Главный совет от ребят — Have fun! Apple Podcasts 🎧 Moscow Python: Пайтон в мире анализа данных Мой бывший СТО из агентства Epoch8 — Андрей Татаринов — заглянул в подкаст Moscow Python рассказать про использование Python для анализа данных и ML. Андрей рассказал что там под капотом у Pandas и чем он отличается от Polars, который активно пиариться за счёт своей скорости. Интересно было про ускорение работы Python за счёт переноса куска вычислений на Rust. Получилось быстро и удивительно мало итераций до работающего прототипа. Общий совет — в начале писать наивную реализацию на Пайтон как быстрый прототип. И потом когда какие-то места упираются в производительность (problems nice to have) — точечно оптимизировать. А не наоборот =) Всегда приятно послушать хорошо структурированные рассуждения Андрея и анекдоты из его опыта. Apple Podcasts YouTube (c таймингами!) 🎧 Проветримся: Системное мышление (из 2020) к следующая книга в нашем книжном клубе будет «Системное мышление» Левенчука; в качестве подготовки переслушал эпизод подкаста с автором из 2020. Делюсь заметками: - Удачный полёт на Марс с первой попытки как результат науки «системная инженерии». - pretrain + finetune: чтобы поставить обучение танцам, можно прокачать «танцевальное мышление», понять куда смотреть — и тогда новый танец можно будет выучить за 2 часа, а не за дни-недели. - «машинка с типами» — уметь мыслить абстракциями и моделями. Проверка через простой вопрос «Лидер — это роль. Какие роли у лидера?» - утверждение, что «у стада коров есть хвост» валидно с точки зрения математики (через вхождение в подмножество), но невалидно с точки зрения систем, потому что оперирует разными уровнями систем. - эмерджентные свойства — в группе объектов появляются новые свойства, которых не было у отдельных элементов. - программирование как подобласть системной инженерии (утверждено NASA в 1968) - «наши требования это их потребности» — наш конченый продукт куда-то вставляется (в следующую систему) и, чтобы оно там работало, надо понимать как его будут применять. Нет смысла делать шестерёнки для часов полностью под размер, но из пластмассы. ссылки на платформы и сам файл с записью в канале подкаста https://t.me/progulka/128
355
17
ClickHouse: стриминг для бедных достался в поддержку проект по реалтайм обработке данных на основе КХ — чем больше в него погружаюсь, тем больше он нравится! смысл простой: из брокера сообщений инсёртим данные в КХ и там через материализованные представления раскладываем их в одну широкую денормализованную витрину. на выходе получаем основные данные для аналитики бизнеса с задержкой в единицы секунд для основных атрибутов и доезд остальных по мере поступления. вообще Кликхаус мне представляется как кладезь интересных технических решений. По мере погружения проект отметил два пункта, почему такой проект в принципе работает: 1. колоночное хранение 2. движки таблиц семейства MergeTree 3. матвьюхи, работающие по принципу стриминга 1/ колоночное хранение данные в таблицах базы — это файлы на диске (довольно очевидно, но до меня это дошло только когда читал Кабанчика) Когда в одном файле лежат полные строки, то в них могут быть нуллы, т.е. лишняя информация. Если хранение повернуть на 90° и хранить в файлах колонки, то там ничего лишнего не будет; а дополнительно получаешь плюшки в виде более эффективного сжатия и аналитических запросов. И тогда мы можем инсёртить в нашу широкую витрину на 100+ атрибутов из разных загрузчиков — каждый загрузчик наполняет только своё подмножество атрибутов. При такой вставке в остальных атрибутах не прорастают лишние нуллы. Чем-то похоже на принцип загрузки в анкор-датаволт: у нас есть «хаб» с первичным ключом и набор отдельных атрибутов-сателлитов; только не на уровне таблиц в базе, а на уровне файлов на диске. 2/ таблицы MergeTree ещё в Кабанчике читал про разницу между разными методами хранения данных в базе данных: B-Tree и LSM Tree. B-Tree хранит данные в дереве — это очень удобно для чтения, потому что можно до любой ячейки дойти за пару шагов по этому дереву. Но записывать такое дерево сложно — перед записью надо найти конкретное место, куда положить твои байтики. А если лист дерева переполнен, нужно создать новый. Log-Structered Merge (LSM) Tree же наоборот оптимизирует запись. Все входящий байтики пишутся тупо в конец последнего файла. Это очень быстро для записи. Но читать такое сложно — при доступе по ключу записи надо проверить все файлы от последнего к первому (самые плохие кейсы, когда такого ключа нет). В ClickHouse есть целое семейство из движков таблиц — MergeTree, поэтому туда можно быстро и много инсёртить. А под капотом уже происходит merge — наваленные в порядке записи файлики раскладываются в сортированном порядке, удаляя лишние данные. Что позволяет читать ваши терабайты за секунды. 3/ «стриминг» матвью интересная особенность матвьюх в КХ — они «присоединяются» к таблице-источник и их логика трансформации применяется к каждому входящему в эту таблицу куску данных. благодаря этой особенности можно налету «парсить» прилетающие из брокера сообщений инсёрты и раскладывать в нужные колонки нашей широкой витрины. напоминает триггеры из других баз — типа на каждый инсерт в таблицу Т1 делаем набор действий с таблицами Т2..Т99. И тут история делает полный круг — на первом своём проекте по дох-строению я сделал условный ЕТЛ на триггерах внутри Постгрес (про Эйрфлоу я тогда ещё не знал =). Как прототип это работало, но развивать и поддерживать это было сложно. В самом КХ это поддерживать тоже трудновато, надо запросы и DDL выносить куда-то во вне. Но по крайней мере оно всё работает на продавшен объёмах и не загибается; подозреваю, что благодаря пунктам 1. и 2. (и техническому гению Алексея Миловидова и команды КХ)
372
18
🤓️️Практикум: английский для разработчика Спустя 6 месяцев закончил курс, куда записался на панике сразу после мобилизации. На самом деле записался сразу на два английских от Практикума: общий и для разработчиков. Общий порадовал короткими кусочками — в любое свободное время за 15 минут проходишь теорию и после неё записываешься на практику на через-5-минут. Можно не держать в голове расписание, а заниматься по свободности. Но в итоге продолжил только с курсом английский для разработчиков. Там подкупила релевантность тем — всё связаны с ежедневной работой: стендапы и ретро, парное программирование и код-ревью, вопросы в интернете и публичная презентация; и конечно поиск работы и тренировка технических и бихейв интервью. ⌘ Процесс В самом начале был небольшой скрининг, проверяли мой английский (видимо, что я смогу общаться с преподом без русского) А дальше занятия 1-1 по зуму. Преподаватель шарит экран с уроками из Ноушена и мы вместе проходим. Там на понимание, на чтение и много на пересказ и прочие болталки. После занятия идут домашки (препод ещё спрашивал в начале нужны ли они, буду ли я их делать)). Домашки на той же платформе, где и занятия по обычному английскому. Каждое 8-е занятие идёт с носителем. За время обучения у меня были разные ребята из Милана, Австралии, Турции, США и Сингапура. У них был разный уровень английского — двое точно не нейтивы. Но в целом норм, они типа те самые айтишники, об которых можно потренироваться: отработать поведенческие и технические интервью. Ещё мне очень повезло с преподом. Хоть её и зовут Елена, но английский у неё на уровне нейтива — кажется это из-за того, что она долго жила где-то заграницей. Прям приятно её слушать и подмечать разные интересные фразы. Если вдруг у вас будет возможность выбора, рекомендую спросить можно ли заниматься с Elena Shoshkina полгода назад было два курса: для разработчиков и аналитиков. Сейчас вижу добавили третий (и расширили старые): 1. для разработчиков и QA 2. для продактов и прожектов 3. для аналитиков и DS https://practicum.yandex.ru/english/english_for_career-1/
400
19
там завтра наши хэды из платформы данных будут рассказывать как ворочать петабайтами в YTsaurus (он же Ыть, он же а-ля Хадуп) https://t.me/ytsaurus_ru/2869
364
20
👆 Минутка кибербезопасности Регулярно появляются новости, что взломали очередную компанию, поэтому тема актуальная. Кажется, что проблема где-то на другом уровне, но часто взломы начинаются с отдельного человека, который решил, что qwerty — сильный и надёжный пароль. В подкаст «Запуск завтра» пришёл хакер-предприниматель, компания которого проводит аудит безопасности: за деньги пытаются сломать компании с последующим отчётом и предложениями по улучшению. кулстори: для одной компании делали аудит, сделали скан и нашли забытый всеми почтовый сервис, торчащий наружу. Спарсили с Линкедина сотрудников, сгенерерили почтовые адреса и по всем прошлись проверкой на базовые пароли — нашёлся один с условным qwerty. Зашли внутрь и пошли гулять там по внутренней сети по соседним сервисам, наткнулись на незашифрованный бекап хранилища паролей. Редкий случай, но довольно показательный. векторов атаки много: можно скупать логи ботнетов и ищут там целенаправленно что-то про конкретную компанию, чтобы целенаправленно пытаться её сломать; либо искать по логам кто (ещё) использует технологию нужной версии, где недавно нашли критичный баг. фанфакт: если сделать облачную виртуальную машину, открытую наружу и с простым паролем, через несколько минут там будет работать чей-то майнинг крипты. Сканирование бубличного интернета и взломы такого уровня уже автоматизированы. вторая половина подкаста была про то как это всё работает в мире блокчейна и крипты — там полный дикий запад, поэтому особенно интересно послушать. https://t.me/ctodaily/1684
466