Big Data *

Всем привет! На связи команда BI-практики GlowByte.

У нас прошел внутренний хакатон AI Seasons. Он вдохнул жизнь в корпоративное обучение и дал участникам ощутимую бизнес-ценность. Хочу поделиться этим опытом и подкинуть вам идею для масштабирования истории у себя. Ниже расскажу подробно, а пока вкратце опишу основную идею, как это реализовали у нас в GlowByte.

Итак, мы взяли вымышленную розничную сеть «МегаБайт» с сотнями магазинов и миллионами заказов. Поставили перед командами задачу реализовать DWH/BI-кейс, решать задачки нужно было с помощью ИИ. На старте участвовали 28 команд, до финиша добрались три: было по-спортивному напряжённо, горячо и энергично, так что не все смогли потянуть битву в таком темпе.

Под катом я расскажу:

● как устроен наш хакатон;

● как оценивались задания;

● какие ошибки мы допустили;

● что было ценного и что мы уже забираем в текущие рабочие процессы.

Будет здорово, если вам зайдет тема и организуете подобный «боевик» для специалистов у себя. Потом обязательно поделитесь в комментариях! 

Всем привет! Меня зовут Муса. Наша команда занимается витринами данных по товарному учёту.

Каждый день мы доставляем около 10 млрд записей в разных форматах. На этих данных строится различная аналитика, связанная с товарными запасами и движениями экземпляров. Перед нами встала задача: пять раз в день обогащать выгрузку из миллиардов экземплярных остатков дополнительными атрибутами для построения различного рода аналитики. История этих атрибутов уже измерялась десятками миллиардов записей.

Первое решение выглядело просто: положить данные в ClickHouse и сделать JOIN. Но одна выгрузка считалась около 12 часов, а нам нужно было укладываться в десятки минут.

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

Вы открываете Binance / Bybit / OKX и т.п., смотрите на график, нажимаете Buy и думаете, что только что купили актив на рынке

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

И самое неприятное - вы почти всегда играете против участников, которые технически и информационно находятся на другом уровне

Спойлер: у вас нет шансов. Сейчас покажу почему на реальных примерах.

Если не хотите читать лонгрид — смело мотайте в конец статьи. Там коротко собрал главный вывод и что с этим делать, как получить преимущество над большинством трейдеров

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

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

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

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

Привет, это команда BI GlowByte.

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

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

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

В работе с FASTA и FASTQ таких мест неприлично много. Почти все они когда‑то были задуманы как удобство.

Вот три, с которыми я сталкивался чаще всего.

Первое. Инструмент пишет FASTQ, а качества у записи нет. Вместо ошибки он подставляет строку из I. Файл получается валидный, парсер доволен, а фильтр по качеству дальше по пайплайну видит идеальные риды и пропускает всё подряд.

Второе. R1 и R2 разъехались: один файл отфильтровали, второй забыли. На выходе абсолютно корректный FASTQ, просто риды спарены не с теми. Формат не нарушен ни в одном байте. Ни один валидатор не возразит.

Третье. Определение Phred‑кодировки по образцу, который одинаково хорошо подходит и под Phred+33, и под Phred+64. Инструмент молча выбирает вариант. Иногда правильный.

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

Полгода назад я начал писать fastx, библиотеку и CLI для FASTA/FASTQ на Rust. Основное решение в ней сформулировано так: там, где можно либо угадать, либо признать неоднозначность, признавать неоднозначность.

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

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

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

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

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

В этой статье мы разбираем реальный кейс анализа массива из сотен тысяч заказов за 10 лет работы крупного автодилера. Разберем обработку данных в Python (Pandas/Seaborn), столкнемся с Парадоксом Симпсона в действии и рассчитаем честный LTV клиентов. Вы узнаете, как сезонная переобувка работает в роли «троянского коня» и почему клиенты с шиномонтажом за свой жизненный цикл приносят компании в 3.1 раза больше денег.

Как выбрать аналитическую СУБД, если одна быстрее, другая проще в эксплуатации, а третья лучше поддерживает нужный SQL? Рассказываю о нашем исследовании: TPC-DS и SSB, экспертные критерии и метод комплексной оценки с расчётом, который можно повторить на своих данных.

Привет, Хабр! Я Павел Молчанов, Data Engineer из группы обработки гео- и медиаданных Big Data компании МТС Web Services. Наш продукт «ГеоЭффект» занимается расчетами различных геостатистик на основе телеком-данных (например, по туризму).

У нас есть ежедневно обновляемая инфраструктурной командой витрина-источник с событиями (точками нахождения абонентов) на основе мобильной сети по всем регионам присутствия МТС. За сутки на каждого абонента приходится в среднем порядка 200 геособытий, общий объем данных в витрине — около 11 млрд записей в сутки. Однако в витрине-источнике не было привязки геособытий к административно-территориальной информации «Регион РФ / район», что критически важно нам как продуктовой команде, решающей бизнес-кейсы в интересах заказчиков. 

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

Пара слов по технологическому стеку: сейчас мы активно проводим подготовительные работы по переходу на Data LakeHouse, но пока что основная рабочая лошадка — Spark на старом добром Hadoop-кластере с HDFS и Hive Metastore. Так что повествование будет идти в контексте технологий Spark on YARN + Sedona + HDFS + Hive.

Как выбрать биржу для алгоритмической торговли: latency, matching engine и реальная ликвидность

Я несколько лет занимаюсь алгоритмической торговлей и за это время прогнал через свои алгоритмы десятки криптобирж.

Я подключал биржи к своим ботам, торговал через API и проверял то, что действительно важно алгоритмическому трейдеру: стаканы, latency, WebSocket, исполнение ордеров, ликвидность, ошибки и поведение рынка в момент реальной сделки.

В результате я протестировал около 40 бирж.

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

Иногда всё наоборот.

Как я встроил AI‑агента прямо в интерфейс Apache Superset и не сломал ему CSP

Есть Apache Superset. Есть аналитик, который открывает SQL Lab и десять минут вспоминает, как называется таблица с заказами — orders, olist_orders или fact_orders_v2. Есть языковые модели, которые отлично пишут SQL, но понятия не имеют, что лежит в вашем хранилище.

Задача звучала просто: добавить в интерфейс Superset кнопку, по которой открывается чат с моделью. Причём агент должен работать по принципу MCP — не фантазировать имена колонок, а сходить и посмотреть их в метаданных. Подключаться к любому OpenAI‑совместимому API: локальная Ollama, llm7, OpenAI — что угодно.

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

Перед техническим разбором можно посмотреть короткую демонстрацию того, как AI‑ассистент работает непосредственно в интерфейсе Apache Superset: видео на YouTube.

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

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

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

Привет, это практика BI GlowByte. В прошлой статье мы говорили про новый продукт FanRuan Dora – дата-агентов поверх BI. Мы разобрали, как устроены агенты, какие роли они выполняют и с чего лучше начинать внедрение. В продолжение темы поговорим о требованиях к данным. Тема вполне актуальная и родилась не на пустом месте. Последние полгода заказчики нам стабильно задают один и тот же вопрос: «У нас есть BI, можно ли поставить сверху ИИ-агента, чтобы он сам отвечал на вопросы руководства?»

Да, это выполнимая задача, но для старта необходимо понимать, что из себя представляют ваши данные в BI.

Наш партнёр FanRuan привел хорошие примеры в статье Fast Answers Are Not Enough: Why Data Agents Need AI-Ready Data. Автор публикации Сабер Чен, AI Product Architect & CPO FanRuan, не так давно выступал на конференции GlowByte и рассказывал о развитии продуктов компании в эпоху искусственного интеллекта. В статье он сформулировал пять требований к данным, которые должны быть выполнены до того, как вы подключаете ИИ. Мы взяли эти тезисы и развернули их в практический чек-лист. Он отлично демонстрирует и подход GlowByte к проверке метрик.

parquet - данные лежат в открытом формате - казалось бы, бери кто хочешь. Но есть неприметный артефакт, от которого зависит, увидите вы таблицы или мусор из файлов и кого вообще к ним подпустят. Это каталог. Разбираю просто, что такое Apache Iceberg, зачем ему каталог - и почему новость про Polaris важнее, чем кажется. В продолжение анонса новостей…

Привет! Меня зовут Вадим Вахрушев, я старший DS-инженер в Авито, занимаюсь задачами поиска. В статье расскажу, как устроено ранжирование в Авито Работе: какие ML-модели помогают создавать выдачу вакансий, и какие инсайты мы вынесли из нескольких показательных АБ-тестов.

Думаю, статья будет в первую очередь интересна ML-инженерам, которым важно разобраться, как поисковое ранжирование адаптируется под конкретную бизнес-вертикаль. Если хочется узнать про поиск в Авито в целом, загляните в обзорную статью — «Как работает поисковое ранжирование для миллионов объявлений Авито». В этом материале я сфокусируюсь именно на специфике вакансий.

Когда вышел DuckDB 1.0, я написал статью Всё что нужно знать про DuckDB. Теперь вышел DuckLake v1.0 — LakeHouse-формат из той же экосистемы. Это отличный повод разобраться, как он устроен и как его можно использовать в production-сценариях.

В этой статье разберём, какую проблему решает DuckLake, чем его архитектура отличается от Apache Iceberg и как поднять DuckLake локально или в окружении, приближённом к production: PostgreSQL для каталога метаданных и S3/MinIO для файлов данных.

🏆 Ищем Грааль на рынке криптовалют

Искал Грааль в крипте через TradingView Ideas: прошлые результаты авторов не предсказывают будущее, зато работает простой признак — лидеры мнений пишут, когда по монете ещё тихо

Статья представляет собой практическое руководство для ИИ агента как воспроизвести технологию

Всем привет! На связи Александр Ларин, руководитель центра поддержки и обучения в GlowByte.

Компания GlowByte – официальный партнер FanRuan по внедрению FineBI в России. Мы внимательно изучаем новые продукты вендора и не могли пройти мимо свежего релиза – набора дата-агентов Dora, работающих поверх BI-среды: моделей данных, метрик и дашбордов.

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

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

Всем привет! Меня зовут Аня Шатшнайдер, я старший BI-разработчик в команде антифрода Авито. Мы пользуемся сотнями ИИ-моделей, чтобы бороться с действиями недобросовестных пользователей. Но иногда модели работают не так эффективно, как следует. Поэтому моя команда решила найти аутсайдеров и передать их на доработку DS-инженерам. Расскажу, как мы пересматривали подход к оценке моделей.

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