Big Data *

P.S. Как вам этот тест для глаз?

Каждый год компании по всему миру тратят миллиарды долларов на внедрение BI-систем (Tableau, Power BI, Qlik, Looker). Аналитики Gartner и Forrester упорно твердят, что рынок растёт. Но есть цифра, о которой говорят немногие: до 70% проектов по внедрению бизнес-аналитики так и не выходят в окупаемость.

Почему? Ведь BI звучит как панацея: «Данные — это новая нефть», «Управление на основе KPI», «Дашборды первого лица». Проблема в том, что бизнес путает нефть с бензином, а бензин заливает не в тот бак. Разберем 5 фатальных ошибок, которые превращают BI в дорогую игрушку.

$56 млрд за 48 часов

15–17 апреля биржа Grinex — предполагаемый преемник Garantex — была взломана.

В это же время через связанный санкционный кластер на Tron прошло 56 млрд USDT крупными переводами ($100K).

Хак не остановил инфраструктуру. Трафик в отдельные часы — ускорился.

Либо выводили ликвидность. Либо хеджировались. Либо кластер просто продолжал работать параллельно — как работал всегда.

Привет! Меня зовут Женя Андриевская. Я — NLP-инженер в лаборатории R&D red_mad_robot. Сегодня расскажу, как мы призвали на помощь эволюцию, чтобы улучшить качество данных в задачах классификации текстов. Да-да, ту самую эволюцию, с мутациями и скрещиваниями — только в мире данных, промптов и LLM.

Ваши данные врут. Не потому, что кто-то хотел вас обмануть, а потому, что вы им это позволили.

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

Даже аккуратный дашборд может скрывать проблемы в данных, если этап подготовки был сделан формально.

Привет, Хабр! Меня зовут Ян Пиле, руковожу в MAGNIT TECH направлением развития алгоритмов доступности товаров. Задача моей команды: сделать так, чтобы в магазине, куда вы зашли за своим любимым майонезом, он с большей вероятностью оказался на полке. А если не оказался — чтобы сотруднику магазина как можно быстрее прилетело задание: «проверь, почему именно этой позиции сейчас нет, и, если возможно, верни её обратно».

Мы уже дважды писали про OSA (On-Shelf Availability — уровень доступности товара на полке). В статье «Как OSA превращает пустые полки в полные корзины?» рассказывали про продуктовый контекст: зачем эта история нужна бизнесу и почему «товар числится в системе» и «товар реально лежит на полке» — это два совершенно разных утверждения. А в статье «Когда 0 в продажах — аномалия? CUSUM для поиска проблем в ритейле» мы подробно разбирали один из рабочих алгоритмов команды. В этот раз я хочу пройтись по всему стеку детекции целиком — от самых простых правил до А/Б-тестов, в которых приходится бороться с зависимыми наблюдениями.

Привет, меня зовут Юля, я дата-инженер в департаменте аналитических решений ЮMoney. Мы разрабатываем и поддерживаем ETL(ELT)-процессы загрузки данных для BI-продуктов компании: отчётов, дашбордов, витрин, API и других.

В этой статье поделюсь, как мы разрабатывали MVP для построения data lineage системы и к каким выводам пришли, — так вы сможете адаптировать подход под свои процессы.

Проблема, которая привела нас к разработке MVP, заключается в том, что в начале работы над большинством задач требуется подготовительная аналитика: восстановить путь происхождения данных, чтобы понимать, какие ETL(ELT)-процессы будут затронуты и на что повлияют изменения. Это увеличивает время выполнения задачи. Но, что ещё существеннее, процесс достаточно рутинный: каждый раз необходимо проводить статический анализ кода и изучать документацию (при её наличии). Мы решили автоматизировать эту работу, чтобы иметь под рукой инструмент для построения пути данных по точкам их обработки и применения, — то есть создать data lineage систему.

Мы уже рассказывали, что такое OpenSearch как сервис в Selectel и как легко и быстро начать им пользоваться. Если коротко — это managed-решение, где кластер развертывается за несколько минут, а все заботы берет на себя провайдер: обслуживает кластеры, настраивает СУБД, обеспечивает отказоустойчивость, беспокоится о бэкапах и масштабировании, предоставляет  поддержку.

Но дальше возникает вопрос — как с этим кластером работать? Как настроить мониторинг, визуализировать данные и метрики, работать с бэкапами, управлять пользователями и доступами? Можно, конечно, отправлять curl-запросы к API. Можно подключать сторонние инструменты, вроде Grafana. Но есть способ проще и удобнее — OpenSearch Dashboards.

Привет, Хабр! Меня зовут Сергей Кардапольцев, я технический писатель в Selectel. В этой статье расскажу, как можно упростить работу с кластером OpenSearch с помощью OpenSearch Dashboards.

Привет, Хабр! В своей первой статье про анализ вакансий C#/.Net разработчиков на рынке я выделила очень интересное замечание, которое определило тему сегодняшней статьи – «не количество навыков делает из мидла синьора, а образ его мышления». Построить граф связности компетенций для синьора это конечно хорошо, но к сожалению, на практике применить его достаточно сложно.

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

Помните, как вы в очередной раз гуглили, как повернуть подписи осей в Matplotlib на 45 градусов? Или как на созвоне вас просили объяснить «вон ту аномальную точку» на красивом графике Seaborn, и вам приходилось судорожно лезть в Jupyter писать новые фильтры, потому что график — это просто статичная картинка? Знакомая боль.

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

Вы слышали о Kafka, MQTT, S3, Iceberg, Trino, PostgreSQL, Redis и Flink? А насколько хорошо вы знаете эти технологии? По каждой из них написаны огромные книги («Kafka: The Definitive Guide», около 800 страниц), и каждый день выходят новые публикации про тонкости.

Эта статья про другое.

Вместо внутренностей движков и законов распределённых систем посмотрим на эти технологии как на кубики LEGO: какую роль каждая из них играет в архитектуре и как они стыкуются друг с другом. Это будет практический туториал: начнём с минимальной конфигурации и постепенно соберём сложную систему. Статью можно просто читать как обзор архитектуры, а можно запускать каждую конфигурацию и изучать её в деталях. Для этого достаточно Git, Git LFS и Docker Compose. Всё запускается в контейнерах. Даже примеры на Java собираются через Docker multi-stage build.

Привет! Меня зовут Марк Каширский, я работаю DS-инженером в команде LLM Авито. Создаю инструменты для разработчиков, чтобы им было легче и удобнее работать. В статье рассказываю, как мы автоматизировали процесс Code review при помощи больших языковых моделей.

Вы пришли из мира PostgreSQL, Oracle или MSSQL. Вы знаете: материализованное представление — это «замороженный» результат запроса. Удобно. Предсказуемо.

Вы открываете документацию ClickHouse. Видите знакомые слова. Радуетесь. Пишете свой первый MATERIALIZED VIEW. Запускаете. И... получаете не то, что ожидали.

Потому что в ClickHouse материализованные представления работают СОВСЕМ не так, как везде.

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

Давайте разберем механику этой проблемы на фундаментальном уровне. Почему системы, в которые инвестированы миллионы, показывают фейк?

Взял MacBook Pro M2 Max, 64GB, и задал простой вопрос: какой MLX-сервер реально готов держать Qwen 3.5 35B как локальный API для команды? Оказалось - серверов восемь, каждый в README обещает «blazing fast», а по факту между ними пропасть.

Написал харнесс на Python, прогнал пять итераций на восьми промтах - от AIME до 52k токенов. Single-user тройка идёт ноздря в ноздрю. Но стоит пустить два запроса параллельно - и четыре фреймворка из шести откатываются в очередь, один деградирует до 0.85×, и только один выдаёт честные 2.17×.

По дороге всплыли квадратичный attention в 2026 году, фантомные 14 000 tokens/sec из-за одной строчки в SSE-парсере и зомби-процесс на 20GB RAM, про который молчат все README. Внутри - графики, таблица «что выбрать под ваш сценарий» и репозиторий, чтобы повторить у себя.

Архитектурный принцип Lakehouse предполагает, что вы оперируете всеми данными, загруженными в систему. Но иногда нужно выполнить ad hoc анализ за ее периметром, потому что необходимых данных по каким-либо причинам нет в Lakehouse-платформе. В этом случае на помощь приходит федеративный доступ. Стандартом для такой задачи является движок Trino. Он умеет извлекать данные из внешних СУБД и даже в некоторых случаях может делать push-down определенных вычислений на сторону системы-источника. Главное, чтобы под рукой был подходящий connector для нужной СУБД, который умеет эффективно с ней работать.

Недавно в состав Data Ocean Nova был добавлен новый Trino Teradata Connector. Он позволяет пользователям «подтягивать» необходимые срезы данных из Teradata в рамках ad hoc запросов и решает задачу эффективной передачи данных: можно передавать терабайты в несколько потоков без существенного увеличения нагрузки на источник.

В данной статье разберем:
• Как организовать эффективную многопоточную работу с Teradata: где часто допускают ошибки, как должно выглядеть правильное решение;
• Какие возможности дает Nova Trino Teradata Connector: многопоточная передача, push-down оптимизации.

Метрики могут «упасть» даже если вы ничего не меняли в модели.
Разбираемся, как распознать distribution shift и что с ним делать в продакшене.

Внедрение современных инструментов Data Governance (управления данными) часто воспринимается как финальная точка в построении культуры работы с данными. Компании инвестируют в Data Quality-проверки (качества данных), создают каталоги данных и выстраивают красивые дашборды, которые сигнализируют о полном порядке. Однако на практике бизнес часто обнаруживает, что за фасадом «зеленых галочек» скрывается хаос: отчеты не сходятся, ключевые метрики вызывают вопросы, а доверие к аналитике падает. Этот разрыв между формальным качеством данных и их реальной ценностью для бизнеса приводит к финансовым потерям и неверным управленческим решениям. 

Меня зовут Сергей Петриченко. Я продуктовый менеджер VK Data Platform. В этой статье я покажу типовой путь компании и расскажу, как сделать работу с данными не самоцелью для ИТ, а инструментом, который полезен для бизнеса.

 33 000 магазинов, 46 РЦ сети «Магнит», 17 млрд прогнозов на 90 дней, 8 ПБ данных и ни одного готового решения, которое можно было бы просто взять с рынка. В 2024 году мы начали с нуля собирать собственную F&R-платформу (Forecast and Replenishment) для «Магнита» — систему прогнозирования спроса и пополнения.

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

Часто полезные данные для обучения ИИ — побочный продукт от действий пользователя в игре, навигаторе или фитнес-приложении. Пользователь делает то, ради чего пришел: ловит виртуальных шушпанчиков, катается на велосипеде, объезжает пробки, вводит капчу — а где-то фоново формируется датасет. Это уже много обсуждали в комментариях к истории использования данных Pokémon Go для обучения пространственного ИИ (spatial AI). 

В этом материале я расскажу о кейсе Pokémon Go и о том, как работает использование данных из приложений.

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

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