Big Data *

Привет, Хабр!

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

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

Таких кейсов в публичном поле почти нет, но кража клиентов уже ведётся. Если вам не хочется погружаться в художественную предысторию моего повествования, сразу переходите к главе 3 «Научная». Там — суть проблемы, без прикрас и обёрток.

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

В этом проекте мы разработали полноценный программный комплекс для автоматизированного сбора, хранения и анализа данных Steam. Построили двухуровневую архитектуру хранилища, реализовали оркестрацию чанков, разработали пайплайны работы с API и конфигурацию параллельного масштабирования. На основе собранных данных сформирован датасет объёмом десятки тысяч игр и сотни тысяч пользователей — и проведён базовый аналитический обзор рынка.

В данной работе представлен комплексный анализ звёздного населения Млечного Пути на основе данных миссии Gaia DR3. Рассматриваются методы массовой выгрузки и обработки десятков миллионов астрономических объектов с использованием распределённой архитектуры Map/Reduce. Построены ключевые распределения: расстояния, фотометрические величины (G, BP, RP), собственные движения, HR‑диаграмма, а также карта небесной сферы. Проведен анализ погрешностей измерений и выявлены наблюдательные и селекционные эффекты.

Всем привет, меня зовут Максим Шаланкин, Machine Learning Team Lead в команде финтеха Big Data MWS. Внутренняя аналитика в финтехе живет в режиме постоянной гонки: новые клиенты приходят, ведут себя по‑разному, а бизнесу нужно быстро понимать, чем группы с разными сценариями отличаются друг от друга. При этом значительная часть работы аналитика — это однотипное сравнение когорт и поиски закономерностей в табличках и графиках. Фоновый LLM‑агент, который умеет сам поднимать данные, запускать статистические проверки и возвращать готовые инсайты, заметно сокращает путь от данных до решения.

Под катом — разбор, как устроен такой background‑агент для анализа активности новых клиентов, на чем он основан, как мы минимизируем галлюцинации и почему выбрали архитектуру, похожую на Claude Skills, а не идем в сторону MCP‑подхода.

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

Как Озон заподозрил мошенника, если он учел все и не сделал никаких ошибок.
Что происходит под капотом и что стало с третим аккаунтом?

В этой статье мы разберем как работает эта система, откуда она берет данные и почему Китайский сценарий развития интернета уже наступил

Декабрь… месяц, когда ощущаешь волшебство везде — в первом снеге, в зимнем какао, в запахе хвои, в разноцветных огоньках гирлянд, в шорохе упаковочной бумаги, в улыбках прохожих. Это пора, когда даже самые серьезные взрослые лиды и синьоры, будто на мгновение превращаются в детей, верящих в чудеса стабильной работы новогодних релизов обновления ИТ‑ландшафта. ИТ‑мир становится волшебнее, а волшебный мир — технологичнее. Мы верим в Деда Мороза и его верных помощников, которые создают новогоднюю сказку, а что если и до волшебного мира добрались инновации? А может Дед Мороз — это самый продвинутый айтишник?

Для организации волшебной сказки для детей и взрослых команда Деда Мороза готовится целый год. Круглый год главный волшебник получает письма с заветными желаниями, к декабрю можно насчитать уже миллиарды запросов на подарки. Наш Дед Мороз «идет в ногу» с современными технологиями, поэтому у него есть секретные ИТ‑системы для автоматизации волшебных процессов, построенных на магическом open source‑коктейле, включающем заморского оленя Рудольфа — Apache NiFi, с отечественными patch‑подковами и упряжкой компонентов ручной работы талантливых мастеров.

Центр управления новогодним волшебством «хо‑хо»

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

Какие навыки реально нужны в IT? Разбор рынка по данным hh.ru. Мы обработали 393 000 вакансий за 2025 год и делимся результатами: универсальный стек технологий, медианные зарплаты по специальностям и доля удаленки. А еще — техническая реализация нашего open-source проекта для сбора данных.

В сегодняшней публикации мы попробуем разобраться в производительности популярных MPP-движков в специализированной задаче ХД – предоставлении доступа к денормализованной витрине данных. Также ответим на вопрос: нужен ли ClickHouse в аналитическом ландшафте, спроектированном по принципу Lakehouse-платформ? Для этого будем использовать бенчмарк ClickBench.

ClickBench появился не так давно, в 2022 году. Методика создана и поддерживается командой ClickHouse. Авторы позиционируют его следующим образом -  «Этот бенчмарк представляет типичную рабочую нагрузку в следующих областях: анализ потоков кликов и трафика, веб-аналитика, машинно-генерируемые данные, структурированные журналы и данные о событиях. Он охватывает типичные запросы в ad-hoc аналитике и дашбордах реального времени». Последний сценарий вызывает у нас особый интерес, ведь редко встретишь архитектурный дизайн аналитического ландшафта, где не было бы решения на базе ClickHouse именно для этой цели, на вершине пирамиды тракта данных от источника до потребителя.

Всем известно, что злые корпорации собирают о нас данные, но как именно они это делают?

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

А также как сайты легко вычисляют ВПН-щиков.

В этой статье мы разберемся во всем этом и составим портрет человека на основе собранных данных.

Начиная с первых курсов университета, первой ассоциацией у студентов ИТ специальностей со словом «ключ» в базах данных является идентификатор. В принципе это верно, однако следует это понятие расширить – связать его с целостностью данных и производительностью. Рассмотрим эволюцию подходов к работе с ключами на примере роста выдуманной компании NeoCat.

В предыдущей статье мы говорили о текстовом поиске, а в сегодняшней я расскажу о векторном (семантическом) поиске.

Итак, если мы используем OpenSearch, в Yandex Cloud представляется логичным использовать модели вложений этого же облака.

Этот код можно запустить как Python Cloud Function. Написан он исходя из того, что в каталоге сервисного аккаунта, под которым запускается функция, доступна модель вложений (embedding). Детали подключения к кластеру описаны в документации.

Рассмотрим один крайний случай: если мы подключаемся, указывая FQDN DATA-узлов, у которых не включен публичный доступ, то функция должна запускаться в сети кластера OpenSearch, иначе они будут недоступны. Альтернативные варианты: подключаться через «Особый FQDN» или узел DASHBOARD с публичным доступом.   

Код создаёт тестовый индекс с текстовым и векторным полем, явно вызывает embedding model через REST API, создавая векторы вложений для документов и запроса, и выполняет векторный поиск, демонстрируя способ интеграции. Обратите внимание на способ выбора разных моделей для документов и запросов.  

Воронки конверсий - популярный инструмент, который сейчас используется почти в любом коммерческом продукте.

Считается, что эта штука быстро и гибко отвечает на большое количество практических продуктовых вопросов.

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

В статье разберем малоизвестные, но очень полезные функции ClickHouse с точки зрения аналитика. Покажу на примерах, как считать сценарии поведения действия через sequenceMatch и sequenceCount, строить воронки с таймаутами с помощью windowFunnel, делать когортный retention функцией retention() и не путаться в GROUP BY. Заодно разбираем комбинаторы If, Distinct, State / Merge, ForEach - как они помогают не плодить подзапросы и вынести тяжёлую логику в витрины.

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

Однако внутренняя эффективность компаний при работе с данными (трансакционные издержки) остается все еще «темной материей». Time-2-market для релиза цифровых решений по-прежнему велико, документация устаревает быстрее среднего срока работы специалиста по данным в компании, а приоритезация бэклога, выбор способа расчета метрик и т. д. принимаются на основе экспертизы, эскизов в Miro и тысяч внутренних Excel-таблиц, которые переделываются при каждой смене лидеров направлений. Все это — скрытые внутренние издержки, которые негативно сказываются на марже компании в долгосрочном периоде.

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

Здесь же я хочу рассказать не о том, как заполнять каталог или какой выбрать. А о том, что нужно сделать, прежде чем переходить к покупке/запуску этого каталога. Для тех, кто уже имеет такого зверя в своем зоопарке, но с ним что-то не так, думаю, тоже будет полезно.

Если вы один из счастливчиков, у кого каталог действительно взлетел, можете дальше не читать. Однако что-то мне подсказывает, что таких будет не много.

Осторожно, статья-детектор.

На Хабре тысячи статей про OCR, IDP, ML и искусственный интеллект. Все они сходятся в одном: «качественная разметка данных — ключ к точности модели». Но что это значит на практике?

Меня зовут Снежана Игнатенко, я руковожу отделом разметки данных в SL Soft AI. Каждый день моя команда работает с самыми разными документами: печатными, рукописными, строгими формами, свободными текстами, сканами и фотографиями, в которых встречаются печати, подписи, штампы, затертые области, перекосы и артефакты. Наша задача — создавать качественный, точный и контекстно корректный набор размеченных данных, который служит фундаментом для всех интеллектуальных систем класса IDP.

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

Привет, Хабр! На связи — технические лидеры направления разработки Apache Spark в составе платформы Data Ocean Андрей Первушин и Дмитрий Паршин из Data Sapience. Мы занимаемся решением нетривиальных задач в области Spark-вычислений, некоторые из которых становятся частью конечного продукта.

Сегодня мы расскажем, с какими проблемами можно столкнуться при реализации Upsert Streaming в Iceberg, что такое equality delete, почему они создают нагрузку при чтении таблиц в Apache Iceberg и как мы оптимизировали Apache Spark, чтобы снизить потребление памяти и ускорить чтение данных.

Геопространственные данные быстро перестают быть «слоем на карте», когда их нужно свести с другими источниками, регулярно обновлять, масштабировать запросы вроде «точка в полигоне» и отдавать результат в BI или GIS без ручной сборки артефактов. В статье разбирается практичный способ собрать геопространственный lakehouse на Databricks и открытых инструментах поверх Spark: как приземлять разные форматы в Delta, где чинить системы координат и некорректные геометрии, чем ускорять тяжёлые геоджойны и как организовать слой представления под разные потребители — от Power BI до облачных ГИС.

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

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

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

Давай поговорим о North Star Metric (NSM). Меня, если честно, иногда бесит, когда её преподносят как какую-то магию, которая сама по себе выведет бизнес в лидеры. Это не так.

За свою карьеру я видел разное: компании, которые отлично росли и без формально прописанной NSM, просто потому что у всех в голове и так была общая цель. И видел провалы, когда команды слепо поклонялись одной цифре, вырванной из контекста, и в итоге «оптимизировали» бизнес прямиком в тупик.

Вся суть не в том, чтобы найти «идеальную метрику». Суть в том, чтобы заставить все отделы говорить на одном языке. И здесь как раз помогает метрика Полярной Звезды.