Big Data *

Полгода назад я начал писать на Хабр дважды в неделю. Результаты разошлись в восемьдесят раз: от 120 тысяч охвата и 647 закладок до полутора тысяч охвата и нуля закладок при одинаковом подходе к работе.

Чтобы разобраться, я сделал очевидное — собрал 200 статей с высоким рейтингом и посчитал в них всё, что считается. Вышла красивая формула, совпадающая с тем, что обычно советуют авторам: пиши коротко, без картинок, с личного аккаунта, про горячую тему.

Потом я добавил контрольную группу — все 1033 статьи, вышедшие на площадке за месяц, без всякого отбора. И формула развалилась.

Картинки: по хитам корреляция с охватом −0.21, по всей популяции с рейтингом +0.26. Статьи вообще без иллюстраций имеют медианный рейтинг 4, с двадцатью и более — 15.

Длина: по хитам короткое побеждает, по всей популяции статьи на 4000–6000 слов имеют втрое больший шанс взять рейтинг выше 50, чем короткие.

Модель на всех измеримых признаках сразу — длина, картинки, гифки, видео, код, таблицы, ссылки, заголовок, час, день недели, тема, тип блога — даёт R² = 0.06. Вся форма объясняет шесть процентов разброса рейтинга.

Внутри: реальные базовые ставки площадки (медианная статья собирает 8869 охвата, 7 плюсов и 3 комментария), шестикратный разброс по хабам, разбор того, за что дают плюсы и за что закладки, история про тему, выгоревшую за пять месяцев с 697 тысяч охвата до 66 тысяч, и отдельный сюжет о том, как я чуть не повторил ту же ошибку второй раз — уже специально про неё зная.

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

Работая единственным QA в команде, в обязанности которого активно входит мониторинг, я столкнулась с проблемами тайм-менеджмента: очень много времени уходит на анализ упавших пайплайнов, заведение однотипных задач, поднятие тревоги, отмена тревоги, потому что проблема уже исправляется и прочие прелести тестерской работы. В один прекрасный осенний денек, сидя на окне и думая о нем (мониторинге), я решила - хватит это терпеть. Посидела, погуглила, вспомнила родительские слова “Хочешь сделать что-то хорошо - сделай это сама”. Что ж таков путь.

Привет, Хабр! На связи Александр Сабко, Виктория Белявская и Сергей Павлухин, из мастерской по прикладному ИИ Инженерно-математической школы НИУ ВШЭ и VK.

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

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

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

В статье мы расскажем, как мы выстраивали схему разметки на интервью с практикующими психологами, какие источники текстов взяли, что внутри инструмента, и что получилось с дообучением Qwen-3.

Всем привет! С вами на связи Евгений Певцов, эксперт по качеству данных группы развития методологии из МТС. Около года назад мои коллеги уже рассказывали, зачем нам потребовались формализованные соглашения об обмене данными и какую проблему они должны были решить.

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

Сейчас дата-контракты — это полноценный сервис, встроенный в существующие ETL-процессы на всем жизненной пути данных. Им ежедневно пользуются продуктовые команды, архитекторы, аналитики и Владельцы данных. 

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

Привет! Меня зовут Гриша Крюков, я аналитик в команде доверия и безопасности Авито. Я провёл чемпионат среди четырёх популярных моделей для оценки индивидуальных эффектов: S-learner, T-learner, X-learner и Causal Forest. В статье расскажу, как проходили испытания и какая из моделей забрала золото после всех испытаний. 

Материал будет полезен тем, кто интересуется uplift-моделированием: новичкам, чтобы узнать об этом методе, профессионалам — посмотреть на сравнение моделей в формате турнира. Не каждый же день такое устраивают!

В аналитике больших данных системы массивных параллельных вычислений часто находятся под постоянной нагрузкой в режиме 24/7. Из десятков и сотен тысяч запросов в день многие исполняются одновременно и конкурируют за ограниченные ресурсы вычислительного кластера. Чем рациональнее каждый отдельный запрос их использует, тем больше запросов система сможет обслуживать параллельно. Соответственно, выше пропускная способность за конкретный отрезок времени. Как правило, проблема нехватки ресурсов остро ощущается в пиковые часы нагрузки. Можно бесконечно до совершенства настраивать и править параметры сессии на каждый запрос индивидуально вручную, но нам — команде разработки платформы данных Data Ocean Nova — всегда хочется иметь более системный подход.

В сегодняшней публикации мы расскажем о том, как реализовали идею автоматической системы предсказания потребления ресурсов SQL-запросами для Impala и StarRocks, основанную на ML-принципах, и сделали её частью платформы данных.

Что если задать BI-системе вопрос, который выходит за рамки рутинной аналитики? Будет ли она также эффективна? Эта идея родилась из корпоративного шуточного спора: шутили над качествами сотрудника «Рака», а в статистику попали также и другие «носители» знака зодиака. 

Мы в Modus решили проверить закономерности на данных, так как это наш профессиональный рабочий инструмент и сфера интереса. Взяли статистику всех игроков Российской Премьер-Лиги, добавили знаки зодиака — и посмотрели, что получится. 

Спойлер: вышел настоящий дашборд и серьезный вывод о том, на что способен гибкий BI.

ClickHouse — один из самых востребованных инструментов для хранения и анализа больших объемов данных, обеспечивающий высокую производительность и наблюдаемость сервисов и приложений. Благодаря этим параметрам многие компании внедряют его в свои ИТ-инфраструктуры для решения задач аналитики, логирования и мониторинга. Однако, несмотря на широкое распространение, практика показывает, что далеко не все команды до конца осознают все особенности и нюансы работы с этой системой, что может приводить к неэффективному использованию ресурсов, ошибкам в проектировании и снижению общей производительности. 

Привет, Хабр. Меня зовут Александр Кривяков. Я пресейл-архитектор VK Data Platform, VK Tech. В этой статье я расскажу об основных принципах работы ClickHouse, а также покажу возможные архитектурные решения и типичные сценарии применения системы.

После атак на логистические центры Wildberries мониторинг цен YoloPrice зафиксировал аномальную волну снижения цен. Разбираемся, был ли это реальный «обвал», реакция селлеров на сбои или просто совпавшая по времени массовая переоценка.

Привет, я Лев Нечаев. Когда-то я работал на заполярной атомной станции, а теперь руковожу командой «Автоматическая модерация методами ИИ» в RWB. В этой статье расскажу, как мы (успешно) применяем детекторы на основе векторного поиска в модерации контента на маркетплейсе. Начнём с предпосылок, первых моделей и сбора данных. Вместе пройдём путь от обучения до оценки качества детекторов в работе на реальных потоках данных.

Все мы хоть раз искали что-то на маркетплейсах. И получали в выдаче совсем не то, что искали. YoloPrice разметил миллионы позиций поисковой выдач e-com площадок и посчитал, какая часть выдачи действительно отвечает на запрос пользователя. Отсюда родился рейтинг площадок по точности поисковой выдачи. Спойлер: у самых больших игроков мимо летит больше половины, а неожиданный лидер — вообще не маркетплейс. Полный рейтинг и методология — в статье.

Всем привет. Меня зовут Василий Гуров, я занимаюсь задачами оптимизации в ML Research Lab MAGNIT TECH. В этом материале разберу два промышленных кейса из крупного ритейла – планирование смен сотрудников магазинов и сглаживание нагрузки на распределительные центры.

На поверхности это разные задачи. В первой нужно построить график работы сотрудников по ролям и временным интервалам. Во втором кейсе стоит задача перераспределения логистических потоков так, чтобы снизить пики нагрузки на распределительные центры (РЦ). Но инженерная проблема у них оказалась общей. Прямая time-indexed постановка быстро раздувала модель до сотен тысяч и миллионов бинарных переменных, давала нестабильные рекомендации и плохо укладывалась в SLA.

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

Отзыв на качество образования в Центральном Университете от лица студента первого набора бакалавриата, переходящего на 3 курс. Есть как приятное, так и не очень, считаю поступающим и интересующимся будет полезно)

Когда речь заходит про Lakehouse и федеративный доступ, многие вспоминают про Trino и… часто на этом все. Но федеративные запросы поддерживаются в том или ином виде довольно большим количеством СУБД, SQL-движков и систем для виртуализации данных.

В этой статье постараемся немного расширить кругозор читателей, которым интересна данная тема: рассмотрим федеративные запросы на примере набирающего популярность и активно развивающегося StarRocks. Из статьи вы узнаете: что такое федеративные запросы, как обстоят дела с реализацией гетерогенного федеративного доступа в этой СУБД и какие изменения команда решения Data Ocean Nova реализовала для оптимизации в StarRocks и Impala с целью улучшения функционала доступа к внешним данным.

Недавно мы выкатили новость (кейс) о совместном проекте с компаниями «Полиэкс» и PIX BI о построении аналитической платформы (почитать можно тут). Все чинно-благородно (новостной язык суров): сроки, интеграции, архитектура. Но у нас с коллегами родилась идея – сделать перевод с делового языка на человеческий. И мы записали интервью с участниками проекта. Команда PIX BI задавала вопросы, а GlowByte и «Полиэкс» говорили как есть: от GlowByte – руководитель проектов Роман Прохоров, со стороны АО «Полиэкс» – ведущий аналитик службы стратегического развития Арина Бортникова.

Современный поиск по видеоконтенту — это высоконагруженная система, требующая молниеносной реакции и безупречной релевантности. Сервис VK Видео оперирует колоссальной базой в 500 миллионов видеороликов и ежедневно обрабатывает около 10 миллионов запросов пользователей. При времени ответа в 0,5 секунды и нагрузке в 1800 RPS алгоритмам необходимо моментально находить именно тот контент, который ожидает увидеть зритель. Однако развитие алгоритмов ранжирования невозможно без качественных данных, на которых они обучаются. 

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

Меня зовут Владислав Чернышев, я руководитель группы качества поиска по видео в AI VK. В этой статье подробно расскажу про путь перехода от классической ручной разметки к гибридной VLM-системе, разберу ошибки и инфраструктурные барьеры, которые пришлось преодолеть для кратного ускорения процессов подготовки обучающих датасетов и офлайн-оценки качества поиска.

Как мы провели проект через четыре «эпохи» — от ручных запусков на Windows‑планировщике до Spark + k8s на масштабе сети

Привет, Хабр! Меня зовут Имиль Валиуллин, я тимлид команды разработки платформы OSA. В предыдущих статьях цикла On Shelf Availability (OSA) уже разбирали с разных сторон: что такое OSA как продукт, как устроен алгоритм детекции аномалий и весь конвейер генерации сигналов — эвристики, ML‑модели, фильтры, обратная связь, A/B и оценка эффекта (ссылки на предыдущие статьи: 1, 2, 3). В этой статье мы раскрываем следующий слой — инженерный. Потому что всё перечисленное было бы невозможно без большой работы под капотом: данных, транспорта, оркестрации, SLA, мониторинга, качества данных, обратной связи, API и доставки сигналов в торговые точки. Многие забывают, что даже самая крутая ML‑модель — это только верхушка айсберга. Результат появляется только тогда, когда под ней есть надёжный фундамент: чистые данные, стабильный транспорт и бесперебойная доставка. Как говорится, garbage in — garbage out, и наоборот: качественный фундамент позволяет получить качественный результат.

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

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

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

Проблема начинается, когда данных становится так много, что прежняя архитектура перестает выдерживать изменения: появляются новые источники, ускоряются бизнес-процессы, растет стоимость хранения и обработки, а каждое изменение в модели данных требует пересмотра уже принятых решений. Как быть, когда архитектурные подходы организации данных, такие как DWH, Data Fabric, Data Lake, Снежинка, Data Vault, Anchor Modeling и другие, перестают отвечать требованиям и почему под давлением динамично меняющихся обстоятельств стройные концепции постоянно нарушаются?

Сегодня мы разберем, почему выбор стратегии работы с большими данными стал архитектурной задачей, как менялись подходы к построению платформ данных, что такое гравитация данных и какие требования стоит предъявлять к современным решениям.

Привет, Хабр! Я, Ольга Попова, ИИ-Евангелист Лаборатории искусственного интеллекта Департамента больших данных Россельхозбанка, подготовила дайджест новостей про ИИ. Поехали!

«Отдельные базы больше не нужны», «конец пайплайнов» - каждую неделю кто-то крупный со сцены хоронит то, что ты вчера поставил в прод. ClickHouse поступил ровно наоборот, и поэтому его анонсы стоит прочитать внимательно. Что реально показали на Open House 2026 и что из этого доедет до прода - разбор практика без вендорского глянца.