Анализируй и проектируй
В статье разбираем, как устроен Apache Airflow 3, для каких задач он используется, какую роль играет в архитектуре DWH и BI, и когда его стоит выбирать для оркестрации процессов обработки данных. Сравниваем с Prefect и Dagster.
Привет! Меня зовут Сергей Прокопкин, я развиваю мотивационную программу и отвечаю за realtime-систему трекинга заданий в Авито.
В мотивационной программе у каждого пользователя может быть свой набор заданий: купить товар, добавить что-то в избранное, забронировать услугу или выполнить последовательность действий. За выполнение пользователь получает награду — бонусы, промокоды, внутреннюю валюту, участие в розыгрышах и так далее.
На первый взгляд техническая задача выглядит довольно просто: получаем действия пользователя, проверяем их на соответствие активным заданиям и обновляем прогресс. Но когда поток событий становится большим, а число заданий и аудитория растут, простая схема начинает дорого обходиться. В нашем случае выяснилось, что более 99% обрабатываемых событий вообще не влияли на прогресс пользователей.
Расскажу, как мы вынесли фильтрацию из основной системы, почему выбрали FlinkSQL, как решали проблему актуального состояния пользователя и обогащения событий — и как в итоге в 600 раз сократили поток событий, доходящий до основной системы.
Над системами аналитики мы обычно работаем командой: менеджер, фронтенд и бэкенд. Но в этот раз фронты были загружены, и проект для своих HR реализовывали вдвоем с бэкенд-разработчиком Morizo: она решала, как строить, и писала код вместе с агентом. Оказалось, что архитектором может быть и не специалист по фронтенду, если он в теме. Мы дорабатывали HR-аналитику в корпоративном портале на Laravel Nova, который давным-давно построили до нас, и мы пришли в готовую систему. Для нас это был первый опыт работы с агентом в таком формате, и там было много всего...
Привет, Хабр! На связи команда разработки кредитных продуктов для физлиц Т-Банка. Продолжаем серию статей о нашем опыте работы с Zeebe — workflow-движком, лежащим в основе Camunda 8. В прошлой части затронули архитектуру, отказоустойчивость, масштабируемость и асинхронную обработку.
За высокой производительностью в начале эксплуатации может скрываться постепенное замедление. Долгосрочная эксплуатация Zeebe выявляет критическую зависимость от инфраструктуры хранения истории. Накопление данных о процессах нагружает не только сам движок, увеличивая потребление памяти и время создания снапшотов, но и Elasticsearch, который при недостатке ресурсов быстро становится узким местом. Хотя архитектура Zeebe позволяет гибко управлять экспортом событий через кастомные экспортеры и выбирать альтернативные инструменты мониторинга, именно стабильность работы с историей определяет общую эффективность системы.
В статье разберем, как рост объема данных трансформируется в падение throughput, и почему оптимизация хранилища зачастую важнее тонкой настройки самого движка.
Публичный лидерборд — это рейтинг моделей на одной дистанции: все решают одни и те же задачи, и видно, у кого процент продуктивно-эффективности выше. Звучит как ответ за пять минут и принятие решения о том, что устанавливать к себе на мощности, а что пропустить.
На деле дистанция у всех своя: чужие версии моделей, чужие настройки, чужие режимы инференса. Мы проверили на себе: полгода и полсотни часов машинного времени ушли на то, чтобы понять, почему чужие цифры показывают не ту картину.
Внутри — четыре причины, почему цифры врут, и три истории, в которые трудно поверить: модель на 27 млрд параметров догнала модель на 284 млрд; «кодинговая» модель провалила кодинг; есть задачи, которые не берёт ни одна модель, ни на одном из шести языков. И таблица, после которой вы навсегда начнёте фиксировать настройки.
Привет, Хабр! Меня зовут Иван Тарасов, я TUL Architecture Governance в техплатформе Авито. Одна из моих команд — SLA — создаёт условия для повышения технической надёжности, а также развивает инструменты NFR и сценарии стабильности.
В этой статье я расскажу, как в Авито устроена система измерения надёжности: от SLI/SLO/SLA и разницы между Stability Rate и Uptime, до устройства NFR для REST/RPC-сервисов, шин данных и кастомных операций.
Также поясню, чем концепция бюджета ошибок в Авито отличается от канонического описания в книге Google SRE, и почему это не случайное отклонение, а намеренное решение.
Предметное поле банковского приложения для сотрудников: как его визуализировать — как лес, дерево или граф? Я Валерий Разномазов, тимлид команды системных аналитиков проекта «Цифровой офис сотрудника», в рамках которого мы создаем приложение для сотрудников Россельхозбанка. В этой статье я рассказываю, как мы строили модель данных для приложения «Цифровой офис сотрудника» в РСХБ и почему отказались от классического «дерева» в пользу ориентированного ациклического графа (Directed Acyclic Graph, DAG).
Более двух с половиной миллионов квадратных метров в год — под тотальным цифровым контролем. Не выборочные замеры и не акты «на глазок», а лазерное сканирование с миллиметровой точностью. Setl Group прошла этот путь за шесть лет: от первого в России наземного сканера Leica до собственной системы строительного контроля, которая сегодня встроена в каждый этап стройки. О том, как технология превратилась из эксперимента в конкурентное преимущество, — из первых рук.
Риски, которые «съедают» бюджет застройщика
Каждый строительный проект на старте имеет проектные даты, которые показывают инвестору, что всё идёт по плану. Событий (вех) в проекте тысячи, и с каждым событием связаны люди и организации, которые они представляют. Если один из этих этапов будет выполнен не в срок, это отразится на последующих. Поэтому застройщику в 2026 году важно смотреть в глубину своих процессов и стремиться повышать их качество.
Риски, которые несёт застройщик:
Задержки сроков и вопросы к качеству...
Про Iceberg сейчас много чего понаписано. Либо обзор «формат будущего, открытость, лейкхаус», после которого непонятно, где нажать, либо разбор одного механизма — снимки отдельно, каталог отдельно, права отдельно. Iceberg плохо объясняется словами, поэтому я собрал стенд, где все части уже соединены и поднимаются одной командой. Trino, каталог Lakekeeper, права в OpenFGA через OPA, вход через Keycloak, S3 на RustFS, а из инструментов нужен только DBeaver. В статье — путь одного запроса через все компоненты, снимки и откат таблицы, права мышкой и обслуживание таблиц с рекомендациями для рабочей системы.
Практический взгляд на то, как можно строить надёжную обработку ошибок и оповещения в интеграционных решениях. Классификация ошибок, повторные попытки, очереди, защита от дублей, агрегация алертов и метрики для мониторинга — с примерами и рекомендациями для реальных проектов.
Привет! Кажется, что не так давно мы впервые рассказывали о нашей работе с платформой BPMSoft в департаменте корпоративных систем ЛАНИТ, где я выполняю задачи аналитика. Но год прошел, календарь перевернут и пришло время добавить новые главы к описанию нашего взаимодействия с этой low-code системой.
В этой статье мне хотелось бы поделиться не только внутренним опытом по настройке и внедрению решения на платформе, но и обратной связью от тех, кто использует систему каждый день.
В репозитории проекта лежит 146 YAML-файлов с контентом: персонажи, сюжеты, настройки моделей. На каждом деплое они импортируются в базу — прямо там же, где выполняются миграции схемы.
Механизм работает второй год и меня полностью устраивал. Потом я сел писать о нём статью, полез перечитывать собственный код импортёра и нашёл сценарий, при котором опечатка в одном файле удаляет сущность из базы. Не архивирует — удаляет, и деплой при этом остаётся зелёным.
Внутри: две ступени сравнения через хэш файла, версии контента, медиа вне репозитория, разбор самой ошибки по трём безобидным кускам кода и ещё пара находок — счётчики, которые всегда равны нулю, и экспортёры, прописанные в конфиге, но не существующие в коде.
Остановил Python сервис с моделью машинного обучения, .NET API продолжил работать и вернул HTTP 503. После восстановления Python запрос снова завершился с HTTP 200, без перезапуска основного приложения.
Зачем разделять .NET и Python, как организовать взаимодействие между ними и что нужно предусмотреть, чтобы отказ ИИ оставался проблемой отдельной функции, а не всей платформы.
Просто стало интересно — что такое описательный анализ. Математический анализ, функциональный анализ знаю. А описательный?
Наверно такое определение подойдет: Описательный анализ — это последовательность шагов, которая превращает сырые данные в понимание процесса. Маркетологи наверно будут говорить, что это не анализ, а аналитика, ну это их проблемы.
Как теоретическую основу я использовал идеи из следующих источников:
Process Mining — Ван дер Аалст, «Process Mining: Data Science in Action (2016). Методология извлечения знаний о процессе из логов событий.»
EDA (Exploratory Data Analysis) — Тьюки, 1977. Принцип: сначала смотреть на данные, потом строить модели.
Lean Six Sigma — DMAIC (Define, Measure, Analyze, Improve, Control). Стандартная методология улучшения процессов.
Я не применяю всех методов, описываемых в Process Mining: Data Science in Action. Для данного анализа достаточно понимать, что наука о данных — это, в частности, превращение данных в реальную ценность.
В этой статье ценность — понимание процесса. Мы не строим прогнозы, не используем машинное обучение. Мы делаем описательный анализ: превращаем сырые логи в картину того, как процесс работает на самом деле.
В статье неявно используется дискретная математика, теория графов, а математическая статистика не потребовалась. Еще: для меня реальные значения более информативны, чем картинки, но для любителей несколько диаграмм я все ж добавил. В тексте много цифр, я старался показать весь процесс, но для понимания результатов можно смотреть только выводы в конце каждого шага
В продукте, который называется «ИИ-сметчик», нейросеть пока не посчитала ни рубля.
Компания по ремонту и отделке квартир в Москве дала мне пять рабочих смет. По ним система выдала 310 замечаний (прогоны 16–21.08.2026). Самая дорогая находка — общий итог одной сметы занижен на 515 786 ₽. Это занижение нашлось ещё при обследовании смет перед ТЗ, а правило под него я написал потом, так что здесь заслуга внимательного чтения, а не кода. Код интереснее другим: 51 подтверждённое замечание он выдал сверх эталонного списка ошибок, составленного при том обследовании. В списке их не было.
Все 310 замечаний выдаёт код с правилами. ИИ-слой написан и покрыт тестами на заглушке, но на живой модели ещё не запускался: ключа доступа нет, платформу выбирает заказчик. Рабочую версию я ему передал, и она обходится без интернета.
Во второй системе, конфигураторе замеров для сервиса, который готовит чертежи стеклянных душевых кабин под заказ, нейросети нет совсем. Модель в обоих проектах работала у меня в разработке: писала код, разбирала Excel заказчика, сверяла замечания со строками смет. В сам продукт я пускаю её только туда, где без неё нельзя.
В собственном маркетплейсе я однажды обнаружил ошибку в обработчике платежей. Логика выглядела правильной: проверить статус PENDING, перевести операцию в SUCCESS и начислить баланс. Но при одновременной обработке двух webhook’ов оба запроса могли пройти проверку и начислить деньги дважды. Этот код я написал сам, без AI.
Сегодня AI-агент может реализовать такой обработчик за минуты. Но функционального описания недостаточно, чтобы гарантировать корректность при конкурентных запросах. Кто должен определить эти ограничения и сформулировать требования до начала разработки?
На пяти ситуациях из собственного маркетплейса и мультибрендовой платформы разбираю, какие решения приходится принимать заранее: идемпотентность платежей, миграции данных, доставка сообщений между экземплярами сервиса, интеграции провайдеров и архитектура брендов. В конце — чек-лист из 12 вопросов перед генерацией кода.
Приветствуем, Хабр.
Врываемся в новую неделю с обширным интервью от Сергея Кушниренко @dalerank автора одной из лучших наших книг 2025–2026 года: «Game++. Устройство и оптимизация игрового движка». Сергей ведёт на Хабре отличный блог, а также создал сайт https://dalerank.github.io/, на котором выкладывается более глубокий и обширный контент, чем обычные лонгриды в формате Хабра. Под катом Сергей ответил на наши вопросы, рассказал о своём подходе к профессии и искусству программирования, языке C++, своей прекрасной дебютной книге, а также о новой книге «Прагматичный C++», которую только что сдал в редактуру.
Для наших читателей — промокод «GAME++» на эту книгу.
Добро пожаловать под кат
Разбор того, как построить систему оценки эффективности, которая контролирует себя сама, и почему заимствованную теорию необходимо переосмыслять относительно обстоятельств своего бизнеса, рынка и культуры.
Российские компании охотно берут готовые управленческие методологии, будь то KPI, OKR, ЦКП и статистики, Lean или Agile. Чаще всего их внедряют как свод правил, который достаточно аккуратно повторить, и гораздо реже как теорию, которую сначала нужно понять, проверить на своих условиях и доработать. Разница между этими подходами решает, получит ли компания работающий инструмент или дорогую имитацию.
В статье я разбираю обезличенный случай внедрения системы «ценного конечного продукта и статистик» в крупной организации. На нём хорошо видно, как методика, перенесённая без адаптации, превращает систему, которая должна была дать прозрачность, в ещё один источник цифр, которым никто не верит. Я рассказываю, как было устроено исследование, какой замкнутый круг порчи данных оно обнаружило и какую модель системы я предложил в ответ. Модель состоит из основы и шести уровней контроля, а кроме неё в статье есть принципы защиты от подгонки показателей под премию, порядок внедрения и пошаговый способ адаптировать любую методологию под свою компанию.
Конечно же, не забыл сопровождать текст вставками цитат разных авторитетных (возможно, для кого-то) западных специалистов, на случай, если моих доводов будет недостаточно.
Я к вам пишу — чего же боле?
Агент все может написать.
Но за ошибки поневоле
Придется вам же отвечать.
(Письмо инженера Татьяны к вайбкодеру Евгению)
Как писать код с агентами, говорят много, часто предлагают конкретные подходы. На мой взгляд, полезнее подняться на уровень абстракции выше — разобраться в проблематике, ценностях и смыслах, и только после переходить к деталям.
У одного из сотрудников TRI было около шести Excel-таблиц. Он выгружал данные из 1С, переносил их в свои файлы и занимался тем, чем приходится заниматься после переноса данных: сводил, пересчитывал, проверял. Когда в компании решили выяснить, сколько времени на это уходит, продуктовый директор Магомед Ахматов предложил завести ещё одну таблицу. В ней предполагалось учитывать время, потраченное на предыдущие.
Магомед рассказал нам об этом, когда мы обсуждали результаты внедрения аналитики. Компания производит клеи, герметики, компаунды и гидроизоляционные покрытия. Наша команда делала для неё несколько отчётов, а здесь я остановлюсь на одном: расчёте потребности в сырье. В этом проекте мы сначала собирались использовать рецептуры, затем нашли другой источник данных и довольно долго сверяли результат с человеком, который раньше считал всё вручную.