Big Data *

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

Но, как мы знаем, «IT» и «изменения» — синонимы, поэтому в идеальном мире, как гром среди ясного неба, появляются новые требования: разработать инструмент для регулярного добавления в витрину данных новых атрибутов, на текущий момент в неизвестном количестве.

Сразу отмечу, что решения и оценки, о которых пойдёт речь, подбирались для работы с большими данными на стеке технологий Apache Hadoop, где для обработки данных использовали фреймворк Apache Spark, СУБД — Apache Hive для анализа данных, оркестратор — Airflow, данные хранятся в колоночном формате Parquet.

Привет, Хабр! Меня зовут Лев Маковеев. Я младший инженер по обработке данных в компании «Криптонит». В этой статье хочу поделиться с вами результатами небольшого исследования, в ходе которого мы протестировали ускоритель запросов Apache DataFusion Comet и пришли к довольно впечатляющим результатам. Забегая вперёд, отмечу, что в отдельных тестах ускорение было более чем десятикратным!

Привет, Хабр! На связи команда матчинга и группировки из ecom.tech. Наша команда решает задачи поиска, группировки и сортировки товаров, с помощью алгоритмов машинного обучения. Например, такие алгоритмы объединяют товары от разных продавцов в одной карточке, что дает покупателям возможность сэкономить время и деньги. 

Сегодня мы расскажем, как исследовали алгоритмы community detection для группировки товаров, с какими проблемами столкнулись и при чём тут матчинг. Статья будет полезна всем, кто работает с большими объемами данных и ищет способы оптимизировать операции с этими данными. Поехали!

Аналитика по скидке: когда клиенты готовы платить только впечатлениями

Если данные новая нефть, то почему за нее не готовы платить?

Как измерить ценность внедрения аналитики?

Хабр, привет! И добро пожаловать на прямую текстовую трансляцию конференции ArenaDAY 2025! Да, сегодня на официальном сайте идёт прямая видеотрансляция мероприятия, но мы решили провести ещё и текстовую — специально для тех, кто не может смотреть онлайн. Следите за обновлениями: мы оперативно публикуем самые интересные моменты, главные тезисы выступлений и цитаты спикеров!

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

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

Если первая часть была про чистоту эксперимента, то вторая — про силу аргументов.

Привет! Меня зовут Елена Малая, я занимаюсь оффлайн A/B-тестами в Бургер Кинг Россия.

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

Эта статья — о том, как я выстраивала методологию A/B-тестирования в условиях оффлайн-ритейла. Она для тех, кто работает с данными не в идеальном вакууме, а на земле — в ресторанах, ритейле, логистике.

Здесь не будет учебных формул — только рабочие подходы, предостережения и лайфхаки, собранные через тесты, ошибки и (маленькие) победы. Если вы, как и я, когда-то поняли, что "по книжке" оно не взлетает — welcome.

Часто недооцененным аспектом разработки AI-агентов остаётся этап оценки. Хотя создать proof of concept относительно просто, поиск оптимальной конфигурации для балансировки стоимости, скорости, релевантности и других параметров требует значительных временных затрат. Инструменты и фреймворки для оценки являются ключевыми элементами этой стадии оптимизации.

Современные сервисы знакомств оптимизированы не для создания пар, а для монетизации одиночества через манипуляцию дофаминовыми циклами. Конфликт интересов между пользователями и платформами усугубляется архаичными социальными стереотипами и отсутствием платформ использующих современных технологии для поиска (хотя вроде и есть ML, скоринг, кластеризация..) И в таргетинге работают уже в весь рост. Там это выгодно. А выгодно ли сервисам?

Публикуем материалы с митапа по Data Science, который прошел 15 апреля.

В офисе Lamoda Tech мы делились свежими кейсами о том, как использовать большие данные и сделать шопинг ещё более приятным и улучшить UX. Рассказали, как поднимаем метрики поиска по самым нестандартным запросам, персонализируем рекомендации на примере главной страницы, а также создаём облако тегов и разметку отзывов для более точного выбора товаров.

Для обработки Common Crawl на терабайтных объёмах широко используются архитектуры обработки данных, построенные на фреймворках вроде Apache Spark. Благодаря распределённой обработке данных и структурированному стримингу Spark позволяет разработчикам создавать масштабируемые пайплайны, применять логику фильтрации и формировать итоговые очищенные корпусы для обучения. Эта статья перевод моей статьи на medium.com, я хотел рассматреть, как на практике формируются обучающие наборы из Common Crawl (например, в проектах C4, CCNet, OSCAR, GPT-3, BLOOM, Falcon и др.), а затем показать пример Spark Streaming-приложения, который я написал и опубликовал в GitHub. Мы также приводим пример подхода, реализованного в DeepSeek, для фильтрации математического контента — узкоспециализированная задача, которая способна дать существенный прирост в качестве моделей.

«Спасение утопающих — дело рук самих утопающих». Иногда это звучит не так уж и плохо.

Привет, Хабр! Меня зовут Юлий Гольдберг, работаю в GlowByte (занимаюсь платформами данных, BI, аналитическими решениями больше 20 лет). Сегодня хочу поделиться некоторыми наблюдениями о том, про что нужно не забывать, чтобы Self‑Service BI стал реальным драйвером развития корпоративной культуры работы с данными, а не остался благим пожеланием.

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

Сравниваем Ansible с другими инструментами для автоматизации управления инфраструктурой: Puppet, Chef, SaltStack.

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

Всем привет! Меня зовут Максим Шаланкин, и я веду несколько образовательных блоков в нашей школе аналитиков данных в МТС. Сегодня я хочу рассказать, как мы организовали необычное занятие по анализу данных: в нем студенты соревновались за звание лучшего в игре, напоминающей Tinder, но для графиков предварительного анализа (EDA). Эта активность не только помогла освоить ключевые навыки визуализации, но и сделала процесс обучения увлекательным и запоминающимся, демонстрируя практическую значимость качественного анализа данных.

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

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

20 марта мы провели митап для пользователей YTsaurus — главной платформы для хранения и обработки больших данных в Яндексе от разработчиков из Yandex Infrastructure, которая уже успела зарекомендовать себя за пределами компании.

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

Привет Хабр! Меня зовут Кучеров Андрей и я Lead Data Engineer с более чем 7-летним опытом в области распределенной обработки данных. Я работал над оптимизацией высоконагруженных Spark-приложений в X5 Retail Group и билайн, где мы обрабатывали петабайтные объемы данных. Регулярно сталкиваясь с производительностью запросов, я убедился, что понимание работы Catalyst — необходимый навык для каждого Data Engineer, работающего со Spark.

Если вы уже пробовали обучать модели, то знаете: выбрал не тот гиперпараметр — получил плохой результат. А перебирать их вручную или даже с помощью GridSearchCV из scikit-learn — долго, муторно и не всегда эффективно. Поэтому сегодня поговорим о том, как заставить компьютер делать эту скучную работу за нас. 

В этом поможет Optuna — библиотека для автоматической оптимизации гиперпараметров. Она умнее простого перебора и часто находит отличные комбинации параметров гораздо быстрее.

Привет, Хабр! Меня зовут Александр Цай, я ведущий аналитик в МТС Web Services, но на деле занимаюсь всеми вопросами, касающимися DA/DE/BI: выявлением потребностей и сбором требований, проектированием дашбордов и витрин для них, построением и развитием внутреннего хранилища, поиском источников данных, созданием сложных ETL-пайплайнов по их доставке, DQ, проведением аналитики и много чем еще.

В этом материале я расскажу про разворачивание пайплайна по стримингу данных из MongoDB в PostgreSQL с помощью Apache Flink (стримить из Kafka банально, а так заодно пощупаем документоориентированную БД). Делать это мы будем в minikube (kubernetes), а языком программирования для заданий выступит Python. Все описанное в посте выполняется на MacBook с процессором i7.

В интернете, тем более русскоязычном, нет информации о стриминге из MongoDB в Postgres с помощью Flink. Почти все материалы по Flink, которые мне попадались, сводятся к пережевыванию примера WordCount из flink-kubernetes-operator, где на запущенном поде из папки с примерами читается файл и в консоль выводится количество слов в нем. Если спускаться до использования PyFlink, то мы натыкаемся на кастомные образы с Harness SDK и Apache Beam и другие страшные слова. Знакомо?

Так вот, это не наш путь! Данное руководство будет полезно тем, кто такой же извращенец хочет пощупать Flink на родном Python и кто не планирует брать примеры, оторванные от реальности.