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

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

— строить Iceberg-таблицы SCD-2 с помощью Trino, SQL и Python;

— попутно освоим прекрасные функции merge, MD5 и другие полезные инструменты;

— напишем свой собственный оператор для Airflow для автоматизации ETL-процесса.

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

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

Весь код писали на Python, использовали FastAPI и другие популярные на тот момент фреймворки и технологии.

Всем привет! Меня зовут Катерина Черных. Я ведущий бизнес-аналитик в X5, но в этой статье не будет про IT. Так получилось, что за август я взошла сразу на три вершины: пик Юхина (5130 м), Арарат (5137 м) и Эльбрус (5642 м). И только после третьей горы нашла для себя ответ на вопрос «зачем я хожу в горы?». Если вы тоже выбираете свою первую серьёзную гору, мой опыт может оказаться полезным.

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

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

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

К утру инфраструктура так и не полыхнула синим пламенем, зато система оповещений просто разрывалась. Так я впервые узнал об «усталости от алертов» и начал искать способ справиться с этой проблемой.

ИИ уже вошёл в нашу будничную рутину. Кто-то использует его как быстрый справочник, кто-то как помощника в IDE, а кто-то уже собирает вокруг него весь рабочий процесс. Рынок меняется слишком быстро, чтобы игнорировать это на собеседованиях. Какой смысл проверять кандидата в искусственных условиях, если в реальной работе он всё равно использует ИИ каждый день? Логичнее сразу посмотреть, как он работает на самом деле. Мы не стали с этим бороться, а встроили в процесс.

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

Реорганизация разработки часто начинается с мысли: «Сейчас пересоберём команды и поедем быстрее». Но стоит копнуть глубже и несколько раз задать вопрос «зачем?», как выясняется, что нужна вовсе не реорганизация, а быстрый результат — довести что‑то до продакшена, снять ограничения, вернуть управляемость.

В инженерных оргсистемах редко бывает одна универсальная проблема и почти всегда своя комбинация сложностей. Как в «задаче трёх тел» Лю Цысиня: как только в гравитационном взаимодействии появляется третий объект, точного аналитического решения больше не существует. Пересборка команд — такая же задача многих тел, в которой задействованы сами команды, новые роли, стейкхолдеры, ожидания бизнеса, накопленные конфликты. У всех свои интересы и влияние на систему.

Мы в Лаборатории прикладной промптологии и производственной тревожности НИИ ИИ второй год следим за тем, как разработчики синхронизируются с генеративными моделями. Уже сформировался новый тип производственного взаимодействия. Это бесконечная серия коротких переговоров, в ходе которых одна сторона просит поправить одну строку, а вторая через 14 секунд возвращается с полностью переписанным кодом. Как будто во всех проектах появился ещё один разработчик, который постоянно косячит, выдаёт старый код за новый, до последнего спорит даже с техлидами, не признаёт очевидных ошибок, нуждается в постоянном ревью и при этом не может быть уволен. Потому что за ним, как нам регулярно объясняют, будущее отрасли, а значит, со временем он «вырастет» и повысит качество кода и точность ответов. Поэтому нам не остаётся ничего другого, кроме как настраивать эту синхронизацию.

Школьные олимпиады по информатике до сих пор воспринимаются как отдельный мир, где дети решают абстрактные задачи, далёкие от реальной работы. Но сильный олимпиадник сегодня уже не просто быстро пишет код. По уровню алгоритмического мышления он близок к junior, а иногда и к middle-разработчику, только без боевого опыта. Он умеет жить в таймлимитах, думать об асимптотике, быстро проектировать решение, дебажить под давлением и работать не только с чистой алгоритмикой, но и с задачами по ИИ, безопасности и робототехнике. Поэтому заключительный этап Всероссийской олимпиады школьников по информатике, который в этом году проходит с 22 по 28 марта, показывает, какой инженер будет нужен индустрии через несколько лет. Чтобы понять, из каких скилов собирается портрет будущего инженера, мы посмотрели, как сегодня устроен финал олимпиады, какие задачи там дают и чему он на самом деле учит.

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

Поддержка двух нативных приложений в таких условиях может быть дорогой в финансовом плане и сложной в скорости вывода новых функциональностей. Один из способов модернизировать продукт и снизить расходы – постепенно перейти на Kotlin Multiplatform.

В этой статье технический директор Александр Кияйкин и iOS-разработчик Мария Нестерова из CleverPumpkin вместе с экспертами X5 Tech, AvitoTech и MAGNIT OMNI разбирают, как компании со зрелыми цифровыми продуктами использует KMP, какие риски учитывают и какой видят от этого эффект.

Linux пропитан магией. Тип файла определяется не по расширению, а библиотекой magic, которая смотрит на сигнатуру первых байтов. В системе живут демоны, процессы могут работать в режиме daemon, а исполняемые файлы хранятся в формате ELF и разбираются утилитой readelf. Это похоже на шутки старых разработчиков, но они появились не случайно.

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

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

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

Привет, Хабр! Меня зовут Дмитрий Орлов. На AI Talent Camp я выступал в роли хастлера (AI-Product) команды ExamLab Bot и ожидал классический хакатон: собрать команду, получить дедлайны, сделать демо и разъехаться. На деле это оказался интенсив с быстрыми итерациями и постоянным общением с менторами. Нам всё время напоминали, что MVP — это не демка «на сцену», что мы отвечаем за полноценный AI-продукт, который будет нужно развивать. Поэтому мы с Дарьей Дмитриевой, которая выступала в роли хакера (LLM Engineer), и смогли сделать то, на что в продуктовой разработке уходят недели.

Сегодня расскажу о модели, которую мы построили для оценки реального эффекта промокодов. Главные вопросы: кому, какой, и зачем мы выдаем промокод. Спойлер: ответ нас удивил. И именно этот ответ стал главной причиной, по которой эту модель вообще стоило строить.

Представьте стандартный отчёт по промокампании: «Пользователи, применившие промокод, потратили на 800 рублей больше среднего». Бизнес доволен, маркетинг рапортует об успехе. Но подождите, а сколько из них потратили бы эти деньги и без промокода?

Это не риторический вопрос. Это принципиальная проблема, которая называется selection bias — систематическая ошибка отбора.

Недавно вечером после работы я зашёл в «Перекрёсток». Усталый, шёл между рядами, взял апельсины и машинально положил на электронные весы. Они сами распознали фрукт, показали картинку и напечатали ценник. Потом я отправил в корзину салфетки, выпечку и пакет молока. На кассе самообслуживания терминал проверил скидки, предложил списать баллы и подтвердить оплату. В этот момент где-то в системе обновились остатки, пересчитались метрики по категориям, а алгоритм учёл мою покупку в общем спросе.

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

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

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

Эта статья не про роботов как технологию и не про автоматизацию как цель. Она про роль, которая появляется, когда автоматизация становится массовой. Про человека, который стоит между WMS, роботами и реальным складом. И про то, почему без этой роли, даже если формально всё работает, автоматизация со временем деградирует.

Мы все видим, как ассистенты и агенты меняют правила игры. То, что недавно называли «умной IDE» с подсказками, рефакторингом и статическим анализом, сегодня лишь разминка перед сбором функциональности. Ассистенты и агенты могут пройтись по десяткам файлов, обновить тесты и даже оформить базовую документацию. Но вместе с бешеной скоростью генерации пришёл и хаос. 

Поговорим о том, как не дать «вайб-кодингу» развалить ваш продакшен и почему Spec-Driven Development (SDD) — это наш новый «компилятор», которому нужно доверять.

Стейкхолдеры — это те самые люди, которые приходят с задачей «Надо ещё вчера», а формулируют её на уровне «Копаем от забора до заката!» и при этом вполне способны одним решением заморозить проект. В итоге команда либо бросается делать «как поняла» и приплывает не туда, либо зависает в ожидании мифического ТЗ, либо выгорает в героическом овертайме, а результат всё равно остаётся под вопросом. Знакомо?

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

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

Хабр, привет! Недавно завершилось ML-соревнование E-CUP 2025. Наша команда из X5 Tech заняла первое место в треке «Логистика: автопланирование курьеров», где было нужно оптимизировать время, затрачиваемое курьерами на доставку 20 000 заказов. В статье расскажем про подходы, которые использовали для решения этой задачи. Посмотрим, во сколько раз можно сжать JSON с матрицей расстояний. Какой код мы использовали для быстрого решения задачи TSP с помощью LKH-3. Обсудим, на что обращать внимание при кластеризации заказов.

Постановка задачи

Требовалось распределить порядка 20 000 заказов между 280 курьерами и построить для каждого из них маршрут так, чтобы минимизировать их суммарное время работы. Оно складывалось из времени перемещения курьеров между заказами и времени выполнения самих заказов (service time). За каждый невыполненный заказ добавлялся штраф 3000 секунд...

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

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

Мы хотели упростить работу с данными. Чтобы пользователь задавал вопрос, сервис превращал его в SQL, выполнял в хранилище и возвращал аналитический ответ. Чтобы рутина уходила в инструмент, а аналитик переставал быть «бутылочным горлышком».

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

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

Мы в X5 Tech решили превратить генеративный ИИ из источника хаотичных вариаций в стабильный конвейер брендового визуала. Зафиксировали стиль, задали структуру, выстроили управление вариациями, и в итоге собрали рабочий пайплайн. Когда он заработал, скорость выросла почти вдвое, некоторые команды полностью отказались от фотостоков или значительно сократили их использование, а 40–45% визуального контента «Пятерочки» и «Чижика» теперь создается с участием ИИ.

В этой статье — разбор принципов, на которых держатся пайплайны управления генерациями: как модели помогают контролировать структуру и стиль, какую роль в этом играет дизайнер и за счет чего связка ControlNet, LoRA, Style Reference и мультимодальных ИИ превращает генерации в предсказуемую систему.

У статьи в ленте Хабра есть несколько строк, чтобы пройти читательский фильтр «открыть или пролистать». Для кого-то всё решают цифры и вау-эффект, для кого-то – реальный кейс, для кого-то – автор или хаб. И мы, команда редакции блога X5 Tech, очень хотим узнать, что вам ближе, чтобы анонсы в нашем блоге показывали важное и не тратили ваше внимание на лишнее.