Как StarRocks защищает production от перегрузки. Query Queues

В прошлых постах я рассказывал про Multi-Warehouse и про Resource Groups. Сегодня третья часть, и она отвечает на вопрос, которым предыдущий пост закончился: что делает кластер, когда запросов прилетает больше, чем все группы вместе способны обработать?

Представим ситуацию: в кластер одновременно приходит 500 тяжёлых запросов. Resource Groups поделят между ними CPU и память, но сами запросы всё равно продолжат конкурировать друг с другом. В результате всё начинает замедляться: растёт latency, память забивается, появляется риск OOM и каскадной деградации.

В этом случае помогут Query Queues. Это механизм back-pressure: когда нагрузка превышает возможности кластера, лишние запросы встают в очередь со статусом PENDING. Как только ресурсы освобождаются, запрос запускается. Кластер обрабатывает поток порциями ровно настолько, насколько у него хватает ресурсов.

По сути:
1️⃣ Resource Groups отвечают на вопрос: кому сколько ресурсов
2️⃣ Query Queues: кого вообще пускать на выполнение

Запрос уходит в очередь, если превышен любой из порогов:
🔹 число выполняющихся запросов на BE
🔹 использование памяти на BE
🔹 загрузка CPU на BE

Работает это на двух уровнях:
🔹 глобальная очередь, на весь кластер
🔹 очередь внутри Resource Group, отдельно для каждого класса нагрузки

Например, можно ограничить ETL пятью одновременными запросами, а BI-дашборды 50 запросами. Запрос стартует только тогда, когда одновременно свободны и глобальный лимит, и лимит его группы.

При этом StarRocks смотрит на реальную загрузку кластера. Каждый BE регулярно отправляет FE статистику по памяти и числу выполняющихся запросов, а Leader FE собирает единую картину нагрузки по всему кластеру. Без этого разные FE могли бы независимо принять слишком много запросов одновременно.

Примечание. Выше описано поведение Query Queues v1 (с порогами на ресурсы BE). С версии StarRocks 3.3 есть v2 на логических слотах: каждый запрос занимает какое-то их число в зависимости от веса, и в очередь попадают те, для кого слотов сейчас нет. В StarRocks 4.1 v2 включён по умолчанию. Принцип back-pressure общий для обеих моделей.

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

Как включать и какие параметры настроить, см. документацию StarRocks (en, ru).

В следующем посте рассмотрим Pipeline DOP: как StarRocks подстраивает параллелизм запроса под текущую загрузку.

Ставьте 🔥, если материал был полезен.

#StarRocks #Selena #MPP #DataArchitecture #Lakehouse #DataEngineering #starrocks_tutorials

Дайджест статей

📰 RAG в энтерпрайзе: почему демо работает, а прод нет
🔗 https://habr.com/ru/articles/1038670/
📝 О чём: разбор причин, по которым RAG-прототип ломается в проде. Проблемы чанкинга длинных таблиц, эмбеддинги, не знающие корпоративный жаргон, ненадёжность top-k и cosine similarity, парсинг PDF и сканов, проброс ACL в метаданные, multi-hop запросы и сложность оценки качества без ground truth. В конце — набор приёмов: сужение домена, гибрид BM25 + векторный поиск через RRF, вынос структурированных данных в SQL.

📰 The Death of Traditional ETL: How AI Agents Are Rewriting Data Engineering (по метаданным)
🔗 https://medium.com/@arrufus/the-death-of-traditional-etl-...
📝 О чём: статья об использовании ИИ-агентов в data engineering. По доступному фрагменту — сценарий, где при изменении схемы выше по потоку ломается downstream-консьюмер, и агент берёт на себя трассировку lineage и починку джоба.

📰 Как мы построили сквозную аналитику в Power BI
🔗 https://habr.com/ru/articles/1038944/
📝 О чём: кейс интегратора VSL-BI для компании по продаже стройматериалов. Сбор данных из Яндекс.Директ, Google Ads, Яндекс Метрики и Битрикс24 в отдельную аналитическую БД на MySQL, загрузка через Python, объединение продаж и рекламных источников по UTM-меткам, построение модели данных и дашбордов в Power BI с метриками ДРР, CpC, CpL, CR.

📰 OCR для Data Lakehouse: от Apache Tika к Docling
🔗 https://habr.com/ru/companies/diasoft_company/articles/1039044/
📝 О чём: путь команды Диасофт от Apache Tika + Tesseract к собственному сервису парсинга документов на базе docling-serve. Описана гибридная архитектура: лёгкий анализ структуры (Layout, TableFormer, Figure Classifier) локально, тяжёлая VL-модель — за внешним шлюзом Digital Q.GPT по OpenAI-протоколу. Рекурсивная обработка вложений, OCR изображений внутри Office-документов, бенчмарки по скорости, CER и потреблению ресурсов в Kubernetes.

📰 Бизнес-аналитика для сети из 300 аптек
🔗 https://habr.com/ru/companies/w_code/articles/1039952/
📝 О чём: внедрение BI-системы интегратором «Белый код» для аптечной сети поверх «СмартАптеки». Пять витрин — оперативный мониторинг с почасовым обновлением, сводка по сети с KPI и LFL, продажи с цветовой индикацией, остатки с drill-down, финансы. Прогноз продаж на день и месяц с учётом времени последней продажи в каждой точке, отдельный мобильный дашборд.

📰 ИИ в работе с данными: почему без человека пока никак
🔗 https://habr.com/ru/companies/yandex_praktikum/articles/1039950/
📝 О чём: пересказ вебинара Яндекс Практикума о применении ИИ аналитиками и дата-сайентистами. Сценарии использования (борьба с «белым листом», ревью кода, саммари по данным, второе мнение), обзор инструментов (чат-боты, Perplexity, NotebookLM, ИИ-агенты) и ограничения: ИИ не учитывает корнер-кейсы, чувствителен к формулировке запроса и не понимает доменный контекст.

📰 Inside AI Meetup (Wildberries) — записи докладов
🔗 https://habr.com/ru/companies/wildberries/articles/1040624/
📝 О чём: анонс с видеозаписями и презентациями митапа Wildberries & Russ от 20 мая. Доклады по AIOps на платформе KeepHQ, автоматическим guardrails (МФТИ), Discovery-платформе VK, отекстовке видео, поиску вакансий на Avito, ИИ-платформе M2, векторной модерации с 200+ моделями и RAG-ассистенту MWS на QWEN3-8B, BGE-M3 и гибридном поиске Vector + BM25 через RRF.

Это случилось: Vitess для PostgreSQL. Чувак, который делал Vitess (шардинг из коробки, MySQL@YouTube) - Sugu Sougoumarane - теперь в Supabase, и они открывают вот такое:

https://supabase.com/blog/multigres-v0-1-alpha

Если кратко, это Vitess для PostgreSQL: шардинг из коробки, пул соедиений, HA.

Дайджест статей

📰 База знаний для распределённых производств: как синхронизировать филиалы
🔗 https://habr.com/ru/companies/teamly/articles/1043664/
💡 Вывод: Локальная вики на каждой площадке не лечит рассинхронизацию знаний, а множит её: версии расходятся, обновления не доходят, администрирование съедает ресурс. Работает не ещё один портал, а единая точка входа плюс управленческое правило «новые регламенты публикуются только здесь». И формализовать стоит не всё подряд, а сценарии с высокой частотой и высокой ценой ошибки, где экономический эффект прямой.

📰 Как Data Fabric и HTAP превращают сырые данные в бизнес-события для мгновенной аналитики
🔗 https://habr.com/ru/companies/vk/articles/1044946/
💡 Вывод: Ускорение ночного ETL до почасового разрыв не закрывает: растёт стоимость инфраструктуры, а сырые события всё равно нужно обогащать смыслом в момент возникновения. Если бизнесу нужен ответ в день запуска продукта, а не на следующее утро, проблема архитектурная. Связка не заменяет DWH, а делит роли: HTAP держит оперативные 7–30 дней, DWH остаётся для истории и ML, Data Fabric обогащает и доставляет.

📰 Tarantool DataBase и Kafka: событийная архитектура без лишних слоёв
🔗 https://habr.com/ru/companies/vktech/articles/1045344/
💡 Вывод: Самописный сервис синхронизации, это скрытый постоянный налог: мониторинг, redelivery, риск потери и дублей, переделка при каждом изменении схемы. Аргумент за готовый CDC сводится к стоимости владения и time-to-market. Но читать его стоит честно: это не «удаление слоя интеграции», а замена своего слоя на вендорский, и выгода реальна там, где нет специфичных требований к ландшафту.

📰 «К нам едет ревизор», или Как не построить космические замки на бюджете сарая при внедрении DWH
🔗 https://habr.com/ru/companies/glowbyte/articles/1046548/
💡 Вывод: Состав артефактов предпроектного обследования определяется его целью, а не «лучшими практиками»: для решения о запуске нужна аргументированная презентация на 25–30 слайдов, для тендера — требования, архитектура, сайзинг и TCO на 3–5 лет. Позиция заказчика «вы эксперты, вам виднее» чаще означает не доверие, а попытку снять с себя ответственность за решения. И отдельно сильное: Agile, прекрасный для проектов развития, на greenfield-запуске DWH растягивает срок втрое.

📰 Как я собрал эталонный Data Engineering проект: ClickHouse, Kafka, Spark, dbt, Airflow и Superset за одну команду
🔗 https://habr.com/ru/articles/1047304/
💡 Вывод: Ценность проекта не в списке инструментов, он у всех одинаковый, а в операционной дисциплине, которая делает «одну команду деплоя» работающей: идемпотентность на каждом шаге, graceful degradation для необязательных стадий, честный список version-конфликтов. Разделение ответственности тоже по делу: dbt для SQL-трансформаций, Spark для того, что горизонтально масштабируется. Бонус для CROSSx-контекста: данные крипто, паттерны детекции аномалий рабочие.

ИИшные будни и полный пятничный сумбур

Сегодня подводили итоги квартала и все команды дата офиса сейчас пишут контекст для своих помощников. И вот нонсенс - чем лучше ваша слоенная архитектура и чем больше у нее документации, тем сложнее ее запихать в RAG и тем хуже на ней работают модели. Спасибо умным людям (привет, Венера), которые начали подробно описывать метрики в компании в маркдауне в репке dbt еще в 22 году - это самый простой и потрясающий буст по контексту для простых потребителей. Но вернемся к тому, почему вроде работали,а получилась шляпа. Самый простой способ убедиться в этом без построениях всяких специальных рагов - поставить nao.

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

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

Решить этой штукой мне хотелось вечную боль команд данных - выгрузки. И все бы ничего, но в коробке такого функционала нет :) Отвечать на вопросы с цифрами может, графики рисовать умеет, но csv выплюнуть - не сделали. У нас в планах на следующий квартал реализовать и пушнуть в апстрим. Еще коллега впрягся и добавил туда поддержку StarRocks :)

А что по остальным командам? BI и их ужасные системы из большой тройки. Самая большая проблема там - найти интересующую тебя информацию. Даже если приложение имеет описание, надо его еще найти, посмотреть есть ли там нужные разрезы и метрики. Решение - RAG. Чуете чем пахнет? Дата говернансом, дада, тем самым. Когда-то внедряли каталоги данных за миллион денег, которые сами по себе не могут решить никаких проблем. Так вот описание нужно, а каталоги - нет. И сам по себе офис данных сейчас по сути становится держателем контекста информации всей компании, мне так кажется.

В 2018 году начал писать в Яндекс Дзен. Одному из первых подключили тогда монетизацию. Сначала писал редко, но потом разогнался и стал выдавать по одной статье в день. Это начало приносить не просто удовольствие от создания микро-комьюнити, но и какие-то деньги.

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

Алгоритмические ленты мощно соединяли релевантный контент с нужной публикой. В 2019 мой бложик про ритейл резко увеличился до 35 тысяч подписчиков. Выступал на встречах с авторами и участвовал в разных мероприятиях. В какой-то момент доход от всей этой истории помог купить однушку и сделать в ней ремонт. Естественно, с ипотекой.

Так получилось, что постепенно внимание переключилось на youtube и затянуло производство видео. Это сильно сложнее, чем просто напечатать текст, но и сам результат совсем другой. История с Дзеном закончилось в 2022, когда Мэил (он же ВК) приобрел платформу у Яндекса.

Ушла старая команда, авторов начали цензурить. Доходы у большинства упали раз в 15-20. Прошлых лидеров заместили военные каналы с существенными заработками (>млн в мес). В чатах смеялись, мол, ВК – это царь мидас наоборот. К чему прикасается – все превращается не в золото, а в дерьмо.

К счастью, за этим шапито уже наблюдал как-то со стороны. Еще что-то дублировал и иногда заливал туда, по старой памяти. До 2025 года. В итоге набрал 200к подписчиков и снес канал.

С того времени для меня ВК – это компания ***** и созданный ими мессенджер М – стремный продукт. Если кто-то тащит туда людей, то это, мягко говоря, нехороший человек, которому не только класть на аудиторию, но и глобально плевать на ру комьюнити (да, вот так пафосно). Участвовать в продвижение этого = одобрять ограничения других сервисов.

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

С другой стороны, есть те, кто молча игнорирует эту замечательную возможность или публично заявляет про свое негативное отношение. И вот это прямо круто (мем с Олегом). Я запомнил таких. +10 к уважению и лояльности.

Мэил блокнули вчера в apple store. Много было возмущения от простых пользователей? А такая же равнодушная реакция была бы при блокировки приложения ТГ? Навязанный продукт, которым вынуждают пользоваться от безысходности – это хреновое резюме.

Знаете, когда осенью все заблокируют (есть сомнения?), то у меня останется WeChat. Китайцы как раз не так давно разрешили регать аккаунт на ру телефон. Больше не нужно подтверждение личности от двух активных пользователей приложения, как было раньше. И WeChat наши чинуши не тронут 100%. Их оскопят если рискнут расстраивать товарища Си. Родственников и друзей уже сагитировал. Присоединяйтесь, отлично ловит на парковке.

Китай вводит AI со школьной скамьи. Это не про технологии — это про поколение

29 июня Китай анонсировал план: AI-образование на всех уровнях — от началки до старших классов. Не факультатив, не кружок робототехники. Системная перестройка.

Что будут учить:
— Пользоваться LLM для решения задач (ok, ожидаемо)
— Критически мыслить: «ставить под сомнение ответы AI, проверять из нескольких источников» (вот это интересно)
— Сохранять человеческое: способность задавать вопросы, творить, сотрудничать

Фон: Китайские университеты уже сократили 12 000 «устаревших» специальностей, заменяя AI-ориентированными.
Ввели «воплощённый интеллект» как отдельную специальность. Шесть из десяти топ-моделей мира — китайские (OpenRouter).

Что это значит на самом деле: Дети, которые пойдут в школу с AI-уроками, выйдут на рынок через 10-15 лет. Они не будут «изучать AI» — они будут мыслить с AI как с воздухом. Разрыв с системой образования, где AI всё ещё «цифровая грамотность» факультативно — станет не технологическим, а цивилизационным.

У нас в нефтегазе кадровый голод по AI — уже сейчас. А через 10 лет мы будем нанимать людей, которых учили работать как с человеком, против тех, кого учили работать с AI. Это не про рост — это про выживание компетенций. 🎓