В 1915 году Владимир Иванович Вернадский запустил проект, который сегодня назвали бы национальной базой данных ресурсов. Без компьютеров и цифровых технологий комиссия КЕПС собрала сведения о недрах, лесах, водах и энергии страны, заложив основы подхода «сначала данные, потом решения».
Всем привет. На связи Дмитрий Немчин из Т-Банка. Снова буду говорить про Greenplum, но в необычном контексте.
С 2015 года занимаюсь Greenplum: развитием, эксплуатацией, автоматизацией и всем, что обычно появляется вокруг большой аналитической платформы. Когда я пришел, у нас было два production-кластера Greenplum и десятки терабайтов данных. Сейчас production-кластеров около 20 и объемы данных измеряются петабайтами. За это время Greenplum прошел путь от небольшого DWH до центра крупной Дата Платформы. И сейчас это система, которая все еще держит большую часть нагрузки, но постепенно перестает быть точкой будущих инвестиций.
Переход к такому состоянию системы часто воспринимается болезненно. Особенно если технология долго была центральной для команды и бизнеса. Но сам факт перехода в legacy не означает, что система была плохой или что работа команды обесценилась. Чаще наоборот: legacy становятся решения, которые долго работали, выдержали рост и успели стать частью критичной инфраструктуры.
В статье хочу разобрать переход на примере Greenplum: что я называю legacy, почему технология начала ограничивать следующий этап роста, какие варианты были у команды и что происходит с людьми, когда привычная система постепенно уходит из фокуса развития.
Всем привет! Меня зовут Вардан Манучарян, я аналитик в команде Монетизации Авито, и мы отвечаем за механику алгоритмов продвижения, то есть управляем порядком, в котором пользователи видят объявления. Для этого нам нужно отслеживать, как изменения в ранжировании влияют на бизнес и покупателей. В этой статье расскажу про интерливинг, — метод, который помогает корректно проводить A/B-тесты с изменением ранжирования. Статья будет интересна аналитикам, которые проводят много A/B-тестов.
Любой аналитик знает, что самым надёжным способом проверки гипотез являются рандомизированные контролируемые эксперименты (RCT), или, как их называют в народе — A/B-тесты. На практике часто возникают ситуации, когда провести A/B-тест невозможно — в основном это происходит по этическим или техническим причинам. Однако бывают кейсы, когда рандомизация невозможна потому, что treatment-ом является определённое действие пользователя. Например, treatment-ом может быть оформление платной подписки или отмена бронирования на сервисе. Давайте назовём такой вид воздействия добровольным.
В русскоязычном пространстве, и в частности на Хабре, достаточно много статей, посвящённых таким методам Causal Inference, как DiD, PSM и Causal Impact. Тем не менее, к моему удивлению, практически нет статей, посвящённых методам на основе ортогонализации и regression adjustment, хотя, на мой взгляд, именно эти методы являются самыми удобными для оценки эффекта от добровольного treatment-а. Пришло время исправить это недоразумение и разобрать метод Double/Debiased Machine Learning (DML) и Partial Linear Regression для задач Causal Inference!
Привет, Хабр! На связи Анастасия Шулакова и Георгий Геймбух, аналитики поддержки Авито. Мы помогаем командам развивать внутренние инструменты для специалистов так, чтобы пользователи получали ответы быстрее, а поддержка оставалась управляемой по качеству и стоимости.
Недавно мы переработали один из самых нагруженных блоков админки — страницы пользователя и объявления, с которыми ежедневно работают поддержка, модерация и другие линии. Это был не косметический редизайн, а замена ключевого операционного контура. И главный вопрос, на который нужно было ответить перед решением о масштабировании: не ухудшает ли новый интерфейс AHT (среднее время обработки обращения) — нашу ключевую метрику эффективности?
По задумке это выглядит как классическая задача для A/B-теста. Но в реальности дизайн сложнее: единица воздействия здесь — специалист, а не обращение, выборка маленькая, дисперсия большая, и обычный рандомный сплит даёт слишком высокий MDE.
В этой статье расскажем, как мы собирали группы генетическим алгоритмом, балансировали ковариаты, проверяли баланс после старта и считали итоговый эффект через CUPED — этот метод доступен из коробки в нашей внутренней A/B-платформе Trisigma, поэтому нам не пришлось писать расчёт с нуля, и мы сосредоточились на дизайне теста и выборе ковариат.
Привет, Хабр! Пишет команда Business Intelligence GlowByte. Каждый год мы проводим Fine Day Online – конференцию про бизнес-аналитику, где практики из разных компаний делятся честным опытом. 22 апреля собрались спикеры из сети “Галамарт”, банков Уралсиб и ОТП, а также FanRuan, и все пять докладов оказались про одно и то же: данные есть, деньги в инструменты вложены, а бизнес по-прежнему принимает решения на ощущениях.
В этом материале хотим поделиться: что обсуждали спикеры, какие цифры называли, что пошло не так и чем закончилось.
Звонил мне на днях один знакомый CIO. Питерский, ритейл, средний бизнес, ничего особенного. Слушай, говорит, надо нам с ИИ что-то делать: все вокруг внедряют, конкуренты вон что-то запустили, на отраслевом Data Summit уши прожужжали, а у меня даже плана нет. И денег, кстати, особо на это не выделили, но не суть.
Это был, кажется, пятый такой звонок за месяц.
И знаете, что меня в них всех поражает? Спрашивают они одно и то же, и спрашивают неправильно. Не «нужен ли нам ИИ», а «куда бежать, чтобы не опоздать», - разница на самом деле огромная, потому что первый вопрос предполагает разбор задачи, а второй уже подразумевает, что бежать в любом случае надо, осталось только направление выбрать.
Так вот, если коротко - не надо бежать.
Сам я не специалист по нейросетям. Много лет вожусь с базами данных в банках, в ритейле, в системной интеграции, и работа моя: смотреть, как данные живут в настоящих, не презентационных компаниях, и решать, что из задуманного взлетит, а что разобьётся об реальность. Через этот фильтр я и предлагаю взглянуть на нынешний шум вокруг локальных LLM, RAG и «корпоративных помощников».
Каждый раз, когда вы делаете EDA, вы стоите перед выбором: нарисовать быстрый df.plot() - или потратить 10-20 минут на оформление, которое скажет что-то важное про ваши данные. В нашем курсе в МТС Школа Аналитиков Данных мы проверили этот выбор экспериментально: 44 студента сделали 220 EDA-графиков, мы получили 6000 попарных сравнений и проанализировали через CrowdBT. (кстати, уже второй раз!) Результат: победители используют не больше данных, а больше контекста. Фоновые зоны, медианы, адаптивная перекраска, inset-axes - именно эти приёмы отличают скучный график от графика, который меняет решения.
В статье - cookbook из 15 рецептов с кодом "до" и "после" на python. Данные - встроенный seaborn.load_dataset("diamonds"), копируйте, запускайте, вдохновляйтесь.
Недавно прогремела громкая новость: Google DeepMind будет тестировать ИИ-модели в EVE Online — одной из самых сложных MMO с живой экономикой, корпорациями игроков, дипломатией, войнами и рынками. Лаборатория заключила исследовательское партнерство с Fenris Creations, студией-разработчиком EVE Online, ранее известной как CCP Games. Google также получила миноритарную долю в компании.
Сделка прошла в момент крупной перестройки студии. Fenris Creations вышла из-под контроля Pearl Abyss и стала независимой после соглашения на 120 млн долл. Компания сохранила руководство, команды и текущие проекты, включая EVE Online, EVE Vanguard и EVE Frontier.
DeepMind не будет запускать эксперименты в основном мире EVE Online. Для исследований будет использоваться офлайн-версия игры на локальном сервере. Это позволит тестировать и оценивать модели в изолированной среде.
Зачем ИИ-проектам такие песочницы, чему они будут там обучаться и каким может стать ИИ благодаря такому обучению.
Привет, Хабр! На связи Илья Амосов из команды поддержки Lakehouse-платформы данных Data Ocean Nova вендора Data Sapience. В сегодняшней публикации я раскрою тему влияния динамического сокрытия чувствительных данных на производительность SQL-запросов. Мы сравним различные методики маскирования, узнаем, как работает оптимизатор и движок со скрытыми полями, происходит ли деградация пропускной способности платформы, как влияет на производительность выбранный метод сокрытия чувствительных данных в случаях, если вы используете компонент на базе Apache Ranger.
Всем привет! С вами Артемий Лямин (@lyaminartemiy) и Иван Тренёв (@123-39). Мы работаем специалистами по разработке нейронных сетей в команде автоматизации машинного обучения Альфа-Банка. В данной статье рассказываем, как провели масштабную модернизацию нашей внутренней AutoDL-библиотеки, пересмотрев её с самых основ.
Мы покажем, какие ограничения были у предыдущей версии и почему точечные улучшения перестали работать. Далее разберём архитектурные решения, которые легли в основу новой системы: переход к модульной мультимодальной трансформерной архитектуре, автоматический поиск архитектур, оптимизацию гиперпараметров, а также переосмысление пайплайна работы с данными. Отдельно остановимся на инфраструктурной части — удалённых запусках и оркестрации экспериментов.
В результате мы покажем как превратили набор разрозненных моделей в единую воспроизводимую и расширяемую AutoDL-платформу. Предлагаем пройти этот путь вместе с нами.
Год назад на рандом-кофе мы с коллегой обсуждали так называемую (мной) цифровую экологию и проблемы работы с большими данными, и он мне посоветовал доклад "The Unbelievable Insecurity of the Big Data Stack" с конференции Black Hat USA 2021 - в целом название полностью описывает содержание доклада. И вот только сейчас, спустя год, у меня дошли руки его разобрать и поделиться с вами своими мыслями на этот счёт. За пять лет доклад совершенно не утратил актуальности и, кажется, стал только более насущным.
Доклад делала Sheila A. Berta - специалист по offensive security из Аргентины, которая много лет занимается поиском уязвимостей и исследованием инфраструктур. В последние годы она сфокусировалась на безопасности Big Data и cloud-native систем. Это не теоретическая работа, а результат практического ресёрча.
Привет, Хабр!
Меня зовут Денис Пашков, я – ведущий архитектор данных в группе компаний GlowByte. В этой публикации я бы хотел поделиться опытом работы с MPP-решением StarRocks, набирающим популярность на российском рынке. Все, кто интересуется данной темой, уже, наверное, не сомневаются, что StarRocks очень хорошо себя показывает в аналитической нагрузке. Мои коллеги из Data Sapience регулярно делятся результатами нагрузочных испытаний платформы данных Data Ocean Nova (ознакомиться можно: 1, 2 и 3). Сегодня же речь пойдет о неочевидном сценарии использования – OLTP-нагрузке.
Привет, Хабр! Меня зовут Максим Шакуров, я ML-инженер в VK.
Сегодня индустрия активно внедряет LLM для оптимизации рабочих процессов. Наша команда решила идти не от самой технологии, а от реальных потребностей. Чтобы найти процессы с наибольшим потенциалом для автоматизации, мы начали с аудита текущей рутины: проанализировали, с какими запросами аналитики и менеджеры приходят в чаты поддержки к инженерам Data Office (специалистам, отвечающим за сбор, хранение и миграцию корпоративных данных) и к разработчикам нашей платформы данных (команде, которая поддерживает и дорабатывает DWH).
Затем сформировали образ нашей будущей системы: она помогает ориентироваться в каталоге витрин, может рассказать, что и где хранится, помогает заполнить заявку на доступы, отвечает на вопросы по специфической документации и пишет скрипты, которые люди могут сразу забрать к себе в ETL-процессы. Под катом рассказали о том, что из этого вышло.
Каждый, кто начинал визуализировать данные на Python, сталкивался с этим: берешь кусок кода со StackOverflow, пытаешься подвинуть легенду или добавить вторую ось, и внезапно весь график ломается. А главное — почему одни пишут plt.plot(), а другие ax.plot()? Какой синтаксис правильный?
В этом туториале мы не просто нарисуем пару линий. Мы заглянем под капот Matplotlib и разберем «анатомию» графиков на простых примерах. Вы поймете разницу между процедурным и объектно-ориентированным подходом, научитесь кастомизировать основные типы визуализаций и навсегда избавитесь от ошибки «белого квадрата» при сохранении файлов.
Привет, Хабр! Меня зовут Ян Пиле, руковожу в MAGNIT TECH направлением развития алгоритмов доступности товаров. Задача моей команды: сделать так, чтобы в магазине, куда вы зашли за своим любимым майонезом, он с большей вероятностью оказался на полке. А если не оказался — чтобы сотруднику магазина как можно быстрее прилетело задание: «проверь, почему именно этой позиции сейчас нет, и, если возможно, верни её обратно».
Мы уже дважды писали про OSA (On-Shelf Availability — уровень доступности товара на полке). В статье «Как OSA превращает пустые полки в полные корзины?» рассказывали про продуктовый контекст: зачем эта история нужна бизнесу и почему «товар числится в системе» и «товар реально лежит на полке» — это два совершенно разных утверждения. А в статье «Когда 0 в продажах — аномалия? CUSUM для поиска проблем в ритейле» мы подробно разбирали один из рабочих алгоритмов команды. В этот раз я хочу пройтись по всему стеку детекции целиком — от самых простых правил до А/Б-тестов, в которых приходится бороться с зависимыми наблюдениями.
Мы уже рассказывали, что такое OpenSearch как сервис в Selectel и как легко и быстро начать им пользоваться. Если коротко — это managed-решение, где кластер развертывается за несколько минут, а все заботы берет на себя провайдер: обслуживает кластеры, настраивает СУБД, обеспечивает отказоустойчивость, беспокоится о бэкапах и масштабировании, предоставляет поддержку.
Но дальше возникает вопрос — как с этим кластером работать? Как настроить мониторинг, визуализировать данные и метрики, работать с бэкапами, управлять пользователями и доступами? Можно, конечно, отправлять curl-запросы к API. Можно подключать сторонние инструменты, вроде Grafana. Но есть способ проще и удобнее — OpenSearch Dashboards.
Привет, Хабр! Меня зовут Сергей Кардапольцев, я технический писатель в Selectel. В этой статье расскажу, как можно упростить работу с кластером OpenSearch с помощью OpenSearch Dashboards.
Привет! Меня зовут Марк Каширский, я работаю DS-инженером в команде LLM Авито. Создаю инструменты для разработчиков, чтобы им было легче и удобнее работать. В статье рассказываю, как мы автоматизировали процесс Code review при помощи больших языковых моделей.
Взял 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. Внутри - графики, таблица «что выбрать под ваш сценарий» и репозиторий, чтобы повторить у себя.
Внедрение современных инструментов Data Governance (управления данными) часто воспринимается как финальная точка в построении культуры работы с данными. Компании инвестируют в Data Quality-проверки (качества данных), создают каталоги данных и выстраивают красивые дашборды, которые сигнализируют о полном порядке. Однако на практике бизнес часто обнаруживает, что за фасадом «зеленых галочек» скрывается хаос: отчеты не сходятся, ключевые метрики вызывают вопросы, а доверие к аналитике падает. Этот разрыв между формальным качеством данных и их реальной ценностью для бизнеса приводит к финансовым потерям и неверным управленческим решениям.
Меня зовут Сергей Петриченко. Я продуктовый менеджер VK Data Platform. В этой статье я покажу типовой путь компании и расскажу, как сделать работу с данными не самоцелью для ИТ, а инструментом, который полезен для бизнеса.
