Аналитике редко учат напрямую: как выстраивать аналитическое мышление, находить реальные причины изменений в метриках и выбирать KPI, которые ведут к решениям, а не к «красивым отчётам». Эта статья — о навыках аналитика, которые формируются на практике и чаще всего через ошибки.
Эта статья будет полезна DS специалистам, и тем, кто хоть когда-нибудь сталкивался с такой проблемой, как выбросы в данных или OOD (out of distribution), и ищет пути решения проблем, возникающих из-за них.
Хочу рассказать о своей разработке и поделиться ей с сообществом habr в виде готового модуля для Python.
Этот модуль решает задачу обновления данных в базе данных. Он выполняет insert/update/delete в одном действии.
Модуль DBMerge проектировался для упрощения ETL процессов по загрузке данных из множества внешних источников в SQL базу.
Для взаимодействия с базой данных используется SQLAlchemy и ее универсальные механизмы, таким образом, разработка не имеет привязки к конкретной БД. (На момент написания статьи, детальные тесты проводились для PostgreSQL, MariaDB, SQLite, MS SQL)
Принцип действия
Принцип действия следующий: модуль создает временную таблицу в базе и записывает в нее весь входящий датасет через операцию массового insert. Далее он выполняет инструкции UPDATE, INSERT, DELETE для целевой таблицы.
История о том как я потратил 5 лет на изучении llm ботов и в итоге написал своего за пол года. Пути реализации и ошибки.
Привет, Хабр. Меня зовут Василий Мельник, я product owner решения для потоковой обработки данных Data Ocean SDI в компании Data Sapience. Наша команда приобрела большой практический опыт работы с Apache Iceberg в задачах на стыке традиционной пакетной обработки и near real-time и конкретно с использованием технологий на базе Flink, поэтому мы не могли пройти мимо нового открытого табличного формата (OTF) Paimon от разработчиков Apache Flink. В этой статье я опишу наш опыт и те практические выводы, которые мы сделали на промышленных средах, в виде репрезентативного тестирования, на котором проиллюстрирую ключевые практические сценарии.
Любая модель машинного обучения начинается с данных. Известное выражение «garbage in, garbage out» как нельзя лучше описывает главную уязвимость ML‑систем. В автоматизированном машинном обучении (AutoML) наиболее критичными точками являются процесс сборки данных и проблема мониторинга данных, в т.ч. в онлайне. Если процессы feature engineering и обучения наша библиотека формализует «из коробки» с помощью конфигурационных файлов и единых правил, то ответственность за загрузку и получение данных несет пользователь.
В сети 26 кофеен на 240k чеков в месяц всё выглядело достаточно хорошо (поток гостей, выручка растёт, но прибыль не соответствует ожиданиям). Рассказываю, как мы собрали ежедневную BI аналитику для управления сетью: от R-Keeper и ETL до витрин в ClickHouse и дашбордов в Yandex DataLens. По дороге упёрлись в типичную проблему: справочники, из-за которых отчёты неточны.
Показана численная близость 
-значений 
-теста, 
-теста и 
-критерия Манна-Уитни в А/Б-тестах вероятностям лучшей группы байесовских моделей. Соотношения выполняются несмотря на различия в определениях.
Статья о создании процессов управления данными, о том, какие фундаментальные вопросы следует прояснить на старте, какую методологию стоит утвердить от технических специалистов менеджменту направления data.
Всем привет! Меня зовут Яна Чеканова, я проджект-менеджер в red_mad_robot уже два года — и да, я не технарь, а филолог по образованию. Парадоксально, но именно это образование помогло мне в одном из самых технологичных проектов — создании AI-поиска для сервиса книги билайн.
Идея родилась у команды билайна: они провели исследование и поняли, что большинство читателей не ищут конкретного автора или название, а ориентируются на настроение и ощущение от книги — «что-то атмосферное», «что-то как любимый роман». Так появилась гипотеза: сделать поиск, который понимает смысл запроса, а не только ключевые слова.
Мы подключились, чтобы превратить эту идею в технологию: векторизовали метаданные полумиллиона книг, обучили LLM и собрали гибридную систему, которая подбирает литературу по смыслу и контексту — даже если запрос звучит просто как «что-нибудь про путешествия во времени».
Рассказываю, как это было.
Привет! Меня зовут Никита Кречетов, я работаю в команде Datawave в юните DBA в Авито. В этой статье рассказываю, как мы перевели полторы тысячи инстансов Redis на Valkey Cluster, как отказались от ручного решардирования и что это дало разработчикам и бизнесу. Материал будет полезен инженерам, которые ищут практичный опыт миграции на новые базы данных.
Главной проблемой при обучении нейросетей остаётся нехватка качественной информации. Всем моделям глубокого обучения может потребоваться большой объём данных для достижения удовлетворительных результатов. Для успешного обучения модели данные должны быть разнообразными и соответствовать поставленной задаче. В противном случае пользы от такой сети будет мало. Хорошо известно, что нехватка данных легко приводит к переобучению.
Но вот беда, трудно предусмотреть и собрать данные, которые покрывали бы все ситуации. Допустим, вы хотите научить систему находить на фото конкретную кошку. Вам потребуются снимки этого животного в самых разных позах — будь то сидя, стоя или обдирающей диван.
А если требуется распознавать кошек в принципе, то вариантов становится в разы больше. Видов кошек в природе тысячи, они все разных цветов и размеров. Почему это важно? Представьте, что наш набор данных может содержать изображения кошек и собак. Кошки в наборе смотрят исключительно влево с точки зрения наблюдателя. Неудивительно, что обученная модель может неправильно классифицировать кошек, смотрящих вправо.
Поэтому всегда нужно проверять свою выборку на разнообразие. Если данные не подходят под реальные условия, то и задачу решить не получится.
Что делать, если у нас дефицит данных?
Вас приветствует команда Data Sapience, и в сегодняшней публикации мы расскажем о реализации процедурного расширения для работы с MPP-движками Lakehouse-платформы данных Data Ocean Nova, которое стало доступным для пользователей. В материале пойдет речь о возможностях, применимости и сценариях использования процедурного языка в аналитической платформе данных и примеры реализации решения типовых задач.
В любой крупной компании есть повторяющийся сценарий. Аналитик сидит над экспериментом или моделью, строит А/В тесты и дашборды, и в этот момент приходит бизнес и просит быстро посмотреть «продажи жвачки за вчера». Аналитик переключается, пишет запрос, отдаёт результат, а через десять минут прилетает почти такой же вопрос. Потом ещё один и ещё. День заканчивается, а свои задачи стоят и покрываются ржавчиной.
Так выглядит ручной доступ к данным. Бизнес понимает, что нужные данные в хранилище есть, но не всегда может их быстро получить. А аналитик становится «бутылочным горлышком», через которое проходит большой поток запросов.
Мы хотели упростить работу с данными. Чтобы пользователь задавал вопрос, сервис превращал его в SQL, выполнял в хранилище и возвращал аналитический ответ. Чтобы рутина уходила в инструмент, а аналитик переставал быть «бутылочным горлышком».
Вроде ничего нового, но в реальной инфраструктуре вскрывается много интересного: специфическая лексика, свойственная каждому из направлений бизнеса, громоздкие витрины, опыт работы с легаси системами и поведение LLM, которую сначала надо надрессировать.
Всем привет! На связи практика Business Intelligence GlowByte. Открываем год полезной информацией.
В 2022 году мы опубликовали на Habr статью про выбор BI-платформы, публикация набрала более 24 000 просмотров. Тогда наш подход был простым: составили большую таблицу сравнения по множеству критериев, поставили баллы — и вуаля, выбирайте лидера.
Четыре года спустя понимаем: такой подход работал для своего времени, но сегодня устарел. В условиях большой неопределенности компании действительно искали универсальные решения "на все случаи жизни". Логика была понятной: выбираем один инструмент, который закроет максимум потребностей на годы вперед.
Но рынок BI созрел. Заказчики стали подходить к выбору осознаннее, исходя не из абстрактного функционала, а из конкретных бизнес-сценариев. И оказалось, что попытка найти "универсальную пилюлю" часто приводит к разочарованию.
Расскажу, как мы в GlowByte пересмотрели методику выбора BI и почему сценарный подход работает эффективнее.
CedrusData Engine — это lakehouse-движок, основанный на Trino. На реальных нагрузках наш продукт рутинно превосходит по производительности другие технологии (Trino, Doris, Dremio, StarRocks) в 1.5-3 раза, с еще более значительным отрывом от устаревших Greenplum и Impala. Эти результаты — следствие постоянных вложений в разработку новейших техник обработки больших данных. В этой статье я расскажу про проект Oxide — одну из наших ключевых инициатив прошлого года по переписыванию ядра Trino с Java на Rust.
В декабре 2025 года VK провёл RecSys Challenge LSVD — соревнование по машинному обучению с нестандартной постановкой задачи. Традиционные рекомендательные системы решают проблему "что показать пользователю", но здесь требовалось обратное: для каждого нового клипа определить, каким пользователям он может быть интересен. Такой подход помогает решать проблему холодного старта контента, когда новое видео только появляется в системе и не имеет истории взаимодействий.
Я принял участие в этом челлендже и хочу поделиться своим решением, архитектурой системы и практическими выводами.
Привет, Хабр! Мой путь в мире IT официально начался относительно недавно: в октябре 2025 года. До этого программирование вообще не выходило за рамки увлечений. Но однажды я решил испытать удачу и выйти на тропу приключений, после которой я уже не вернулся прежним...
Эта статья проведёт вас через классический проект по машинному обучению — анализ датасета Titanic. Мы разберём полный цикл работы: от первоначального знакомства с данными и их очистки до построения и валидации первых предсказательных моделей. Вы узнаете, как преобразовывать категориальные признаки, создавать новые переменные, бороться с пропущенными значениями и оценивать качество моделей через ключевые метрики. На примере Random Forest и логистической регрессии наглядно показываю, как разные алгоритмы решают одну задачу и почему выбор модели зависит от поставленной цели.
Clickhouse никогда не удаляет ваши данные, главное помнить об этом и знать где искать. Наш кейс миграции на Clickhouse Keeper, история потери и восстановления данных
