Как не потеряться в сотнях графиков и найти реальные рычаги влияния на бизнес? В статье представлен подробный разбор Дерева метрик на примере FoodTech-сервиса (доставки еды). Мы уходим от простого мониторинга цифр к системной декомпозиции North Star Metric.
Как часто бизнес задает вопрос о результатах A/B-теста уже на второй день после запуска? В классической статистике основной ответ: необходимо ждать набора фиксированной выборки, иначе риск ложноположительного результата становится неконтролируемым. Однако современные подходы позволяют не только проводить мониторинг данных без риска математической ошибки, но и останавливать эксперименты значительно раньше срока. В основе такой гибкости лежит методология mSPRT, которая превращает эксперимент из закрытого процесса в прозрачный поток данных.
Вместо пассивного ожидания можно использовать концепцию доверительных последовательностей и всегда валидных p-значений. Эти инструменты сохраняют свою математическую силу независимо от того, как часто проверяются промежуточные итоги. Ключевую роль в настройке системы играет параметр смешивания тау, который помогает найти тонкий баланс между чувствительностью к минимальным изменениям и скоростью получения итогового результата.
Работа с реальным трафиком требует адаптации теории к специфике бизнеса. В статье разбирается, как метод линеаризации помогает применять последовательный анализ к сложным показателям вроде конверсии или среднего дохода на пользователя. Также рассматриваются ситуации, когда стандартная математика может давать сбои из-за экстремальных выбросов с тяжелыми хвостами распределения или изменения характеристик трафика во времени. Чтобы исключить ложные срабатывания, вводится система защитных механизмов, которая делает выводы устойчивыми к случайному шуму.
Такой метод позволяет сократить время проведения тестов на 30-50%, не жертвуя при этом достоверностью. Это способ сделать процесс проверки гипотез более гибким и быстрым, сохраняя безупречную математическую строгость в каждой точке принятия решения.
Третья статья цикла о построении CDC-пайплайна с нуля. Сегодня — самое интересное: захватываем изменения из PostgreSQL и отправляем в Kafka. И разбираемся, почему WAL может съесть весь диск, даже если данные не меняются.
Выделили из production-проекта и открыли в open-source PWA-приложение для персонального фитнес-тренера с AI.
Дисклеймер: это open source, в нем могут быть недостатки, заходите, предлагайте идеи, исправления. Публикую тут в ознакомительных и образовательных целях. Выпилил этот кусок в open source из части личного проекта, о котором писал тут. Весь код писал полностью Claude Code на Opus 4.5 с thinking режимом.
Привет Хабр! Возможно вас, как и меня, первое знакомство с функциональными зависимостями в базах данных повергло в легкий ступор. Длинные определения, которые не давались даже после третьего прочтения, излишняя абстрактность, когда на простые и понятные примеры поскупились, и прочее прелести «научного» подхода к объяснению сложных тем.
Пора раз и навсегда разобраться во всем этом. Тем не менее, я постараюсь не упускать детали и, где это уместно, углубиться в тему с головой. Без претензии на академичность, но с претензией на ясность. Начнем.
«Страница заказов грузится вечность», — такой тикет прилетел в понедельник утром. На проде 800 тысяч записей, а типичный запрос с фильтрацией и сортировкой заставлял менеджеров ждать по 12 секунд. В этой статье разберем, почему стандартный индекс по одному полю не сработал, как EXPLAIN ANALYZE помог найти «бутылочное горлышко» и почему порядок полей в составном индексе имеет решающее значение
Ты изучал SQL в университете, получал пятёрки на экзаменах… а на собеседовании по Data Science сталкиваешься с вопросом про OVER() и думаешь: "Что?! Впервые такое слышу..."
В этой статье я рассказываю, как превратить университетский SQL в инструмент, который реально помогает на собеседованиях.
Привет, Хабр!
В предыдущей статье мы рассказали, как установить Digital Q.DataBase на Astra Linux 1.8 и начать работу с этой российской СУБД, которая поддерживает нативную работу с диалектами MS SQL, PostgreSQL и Oracle. Сегодня мы поговорим о том, как перенести уже существующие данные в Digital Q.DataBase из других систем управления базами данных.
Для решения поставленной задачи мы разработали инструмент – Мастер переноса БД. Он позволяет выгрузить структуру, данные и хранимую логику из уже развернутой БД на одной из трех СУБД (Oraсle, MS SQL и PostgreSQL) и загрузить их в Digital Q.DataBase без переписывания кода приложений в отличие от любых миграторов-конверторов.
Стек: Python, Airflow, ClickHouse, Slack
В iGaming падение активности игровых провайдеров почти никогда не выглядит как "обрыв". Чаще это медленное затухание: ставок становится меньше, затем еще меньше, игроки уходят постепенно. Формально провайдер продолжает работать, стандартный мониторинг молчит, а бизнес уже теряет деньги.
Моя задача была не фиксировать факт полного падения активности, а поймать момент, когда траектория уже направлена вниз, но ситуацию ещё можно развернуть.
Вся логика работает внутри DAG в Airflow. Он запускается каждые 6 минут и анализирует активность игровых провайдеров в реальном времени. При обнаружении начала падения или восстановления система отправляет уведомления в Slack.
Привет, Хабр! Сегодня на связи Илья Ищенко, руководитель группы администраторов хостинга Рег.ру и Роман Рогов, старший системный инженер.
В прошлом году мы закончили масштабную задачу — добавили MySQL 8 на все серверы шаред-хостинга с ispmanager. Получилась полноценная инфраструктурная перестройка: с двумя версиями MySQL на одном сервере, прозрачным переключением клиентов и возможностью безопасной миграции.
В статье расскажем, какие варианты мы рассматривали, почему отказались от очевидных решений, как в итоге реализовали проксирование на уровне сокета и зачем нам понадобился собственный плагин миграции для ispmanager.
В статье рассматриваются текущие возможности горизонтального масштабирования СУБД для 1С, а также какое решение предлагает Tantor Postgres.
У тех, кто не кодит, бытует мнение, что у разработчиков на любую задачу есть какое-то одно решение — бест-практика. Достаточно почитать SO или, вот теперь, пообщаться с нейронкой и — вуаля — задача сделана. На практике, даже у такой задачи, как вставить данные в БД, есть варианты решения, каждый со своими плюсами и минусами. Делюсь небольшим примером.
Вторая статья цикла «CDC Pipeline в домашней лаборатории». В первой мы сделали Telegram-бота для парсинга банковских скриншотов. Теперь подготовим PostgreSQL к тому, чтобы Debezium мог захватывать изменения в реальном времени.
Хочу рассказать о своей разработке и поделиться ей с сообществом habr в виде готового модуля для Python.
Этот модуль решает задачу обновления данных в базе данных. Он выполняет insert/update/delete в одном действии.
Модуль DBMerge проектировался для упрощения ETL процессов по загрузке данных из множества внешних источников в SQL базу.
Для взаимодействия с базой данных используется SQLAlchemy и ее универсальные механизмы, таким образом, разработка не имеет привязки к конкретной БД. (На момент написания статьи, детальные тесты проводились для PostgreSQL, MariaDB, SQLite, MS SQL)
Принцип действия
Принцип действия следующий: модуль создает временную таблицу в базе и записывает в нее весь входящий датасет через операцию массового insert. Далее он выполняет инструкции UPDATE, INSERT, DELETE для целевой таблицы.
Я решил собрать для себя приложение, которое объединит несколько AI-модулей в одном месте: фитнес-трекер с AI-тренером, новостной дайджест по AI/ML, дашборды для других проектов. Не SaaS для всех, а инструмент для себя. PWA, чтобы работало как нативное приложение на телефоне.
В итоге: 4 дня по 4 часа, 8600 строк кода, работающий продукт в production. Расскажу как это получилось.
Путь разработчика от «Prisma — это магия» через «почему это так медленно?» к решению, которое сохраняет и DX, и производительность.
В статье разбирается техническая реализация SQLize Embed — легковесного JS-компонента для создания интерактивных песочниц прямо в тексте технических статей. Автор подробно описывает архитектуру решения: от использования MutationObserver для инициализации редакторов на фронтенде до обеспечения безопасности и изоляции запросов в Docker-контейнерах на бэкенде.
Вы узнаете, как реализована поддержка более 20 СУБД (включая PostgreSQL 18, MS SQL 2025 и Oracle 23ai) и как встроить «живые» примеры кода в свой проект всего парой строк HTML.
В любой крупной компании есть повторяющийся сценарий. Аналитик сидит над экспериментом или моделью, строит А/В тесты и дашборды, и в этот момент приходит бизнес и просит быстро посмотреть «продажи жвачки за вчера». Аналитик переключается, пишет запрос, отдаёт результат, а через десять минут прилетает почти такой же вопрос. Потом ещё один и ещё. День заканчивается, а свои задачи стоят и покрываются ржавчиной.
Так выглядит ручной доступ к данным. Бизнес понимает, что нужные данные в хранилище есть, но не всегда может их быстро получить. А аналитик становится «бутылочным горлышком», через которое проходит большой поток запросов.
Мы хотели упростить работу с данными. Чтобы пользователь задавал вопрос, сервис превращал его в SQL, выполнял в хранилище и возвращал аналитический ответ. Чтобы рутина уходила в инструмент, а аналитик переставал быть «бутылочным горлышком».
Вроде ничего нового, но в реальной инфраструктуре вскрывается много интересного: специфическая лексика, свойственная каждому из направлений бизнеса, громоздкие витрины, опыт работы с легаси системами и поведение LLM, которую сначала надо надрессировать.
В 1974 году, когда SQL только вышел из исследовательских лабораторий IBM, работа с базами данных выглядела просто: разработчик писал запрос и получал результат. Без слоёв, абстракций и фреймворков — только строки, описывающие нужные данные.
Эта прямота дорого обходилась. Переименование колонки превращалось в поиск по тысячам строк кода в надежде отловить все упоминания. Неаккуратная работа с пользовательским вводом приводила к SQL-инъекциям. Миграция с Oracle на PostgreSQL часто означала переписывание значительной части запросов из-за различий диалектов.
К середине 1990-х проблема стала настолько заметной, что начали появляться Object-Relational Mapper’ы (ORM). Идея выглядела привлекательно: работать с таблицами как с объектами, писать код на «родном» языке программирования вместо SQL-строк, а перевод на SQL оставлять фреймворку.
Продолжаем цикл статей с обзором изменений 19-й версии. На этот раз рассмотрим что появилось в рамках сентябрьского коммитфеста 2025 года.
Самое интересное из первого июльского коммитфеста можно прочитать здесь: 2025-07.
