Сравнительный обзор механизмов polling в Kafka и Pub/Sub в RabbitMQ: особенности и области применения

Друзья, привет! Меня зовут Андрей Комягин, я CTO компании STM Labs. Мы занимаемся разработкой очень больших распределённых высоконагруженных систем для различных отраслей, включая налоговое администрирование, телеком, track & trace и многие другие. В своих проектах и архитектурах мы широко применяем open-source-решения, включая брокеры сообщений, такие как Kafka и RabbitMQ.

Совсем недавно я выступил на конференции HighLoad++ Genesis 2025: рассказал про анатомию каждого из этих брокеров, сравнил их по набору критериев и оценил результаты их нагрузочного тестирования. А теперь решил выпустить этот материал в виде статьи в блоге, чтобы читатели Хабра тоже смогли изучить нюансы и понять, на какие задачи заточен каждый из брокеров. Итак, поехали!

О брокере Apache Kafka я очень подробно рассказал в своей предыдущей статье. Повторяться и снова разбирать его сегодня я не буду — вы можете перейти по ссылке выше и ознакомиться с материалом, а затем вернуться сюда.


Читать: https://habr.com/ru/articles/989590/

#ru

@big_data_analysis | Другие наши каналы

Как структура данных диктует стиль кода в SQL и pandas

В аналитике часто кажется, что выбор между оконной функцией и GROUP BY — дело случая. Но исследование решений реальных задач показывает чёткую закономерность: тип данных предопределяет преобладающие конструкции.

Временные ряды и задачи типа «самый высокий результат за день» почти всегда приводят к оконным функциям (RANK, LAG). Когда метрика собирается из нескольких таблиц (факты и измерения) — доминируют JOIN + GROUP BY. Задачи на исключения («кто никогда не совершал действие») — это анти-джойны (NOT EXISTS или ~isin). В pandas аналогично: .merge() появляется там, где нужно скомбинировать данные, а .groupby() — на следующем шаге.

Понимание этих паттернов позволяет не гадать, а сразу выбирать нужный инструмент, ускоряя написание и отладку кода. Подробности в статье: https://www.kdnuggets.com/visualizing-patterns-in-solutions-how-data-structure-affects-coding-style

Таблицы для аналитиков в 2026-м: Яндекс 360, Р7 и Google Sheets

Вопрос инструмента для совместной работы с данными стал сложнее: рынок офисных редакторов за последние год-два заметно перестроился. Появились новые ИИ-возможности прямо в интерфейсе таблиц, изменились условия по on-prem развёртыванию, а доступность облачных сервисов для российских команд остаётся нестабильной.

В полном разборе сравниваются три актуальных варианта по форматам, совместной работе, ИИ-ассистентам и интеграциям с аналитическим стеком (BigQuery, gspread, API). Удобно, что авторы свели всё в одну таблицу сравнения.

Читать полный разбор.

Обновление PostgreSQL остановит ваш CDC-пайплайн на wal2json, если не поправить конфиг

13 августа вышли PostgreSQL 18.6, 17.11, 16.15, 15.19 и 14.24: они закрывают CVE-2026-6471 (7,2 балла из 10 по шкале опасности). Аккаунт с атрибутом REPLICATION мог передать в CREATE_REPLICATION_SLOT любой путь к библиотеке, а сервер загружал её и выполнял код от имени пользователя ОС. Ошибке 12 лет: она с самого появления логического декодирования в 9.4.

Закрыли белым списком: параметр output_plugin_libraries, по умолчанию pgoutput и test_decoding. Любой другой плагин вывода, включая wal2json и decoderbufs, после обновления получает отказ, и декодирование не стартует, пока библиотеку не впишут в список и не перечитают конфиг.

Атрибут REPLICATION висит на бэкапах, standby, мониторинге и CDC. Проверьте plugin в pg_replication_slots до апдейта и допишите его в параметр тем же окном обслуживания.

Офсетный лаг не скажет, насколько старые данные лежат в вашем озере

Он показывает, на сколько сообщений консьюмер отстал от топика, а не возраст данных. При неровном потоке один и тот же лаг означает то минуты, то часы, а SLA на свежесть написан во времени.

В Twilio для пайплайнов на Apache Hudi Delta Streamer лаг считают во времени, не трогая продюсеров и консьюмеров: берут последний коммит Hudi в S3, достают из него чекпоинт Kafka, перематывают топик на этот офсет и вычитают время сообщения из текущего.

Грабли: в последнем коммите чекпоинта может не быть, если его сделал параллельный легаси-пайплайн. Тогда алгоритм идёт по истории коммитов назад, до ближайшего с метаданными.

Офсетный мониторинг это не отменяет: он ловит зависшего консьюмера, а time in queue даёт возраст данных и порог свежести с алертами на каждый пайплайн. Разбор на 5 трлн записей в месяц у InfoQ.

Трассировки OpenTelemetry можно свернуть в метрику, которая показывает, какой SQL чинить первым

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

Разбор на блоге CNCF предлагает не копить телеметрию, а сворачивать спаны БД в метрики: у спана есть длительность и текст запроса, по нормализованному тексту считается агрегат, и вместо потока событий выходит ряд для дашборда и алерта.

Метрика закрывает два вопроса. Оптимизация: ускорение какого запроса даст больше всего, если взвесить длительность на частоту вызовов. Инцидент: какой запрос отклонился от собственной нормы прямо сейчас.

SELECT по orders без индекса на customer_id отдаёт 20 мс на 10 тыс. строк и минуты на 10 млн: запрос не менялся, вырос объём. В статье это собрано в лабораторию, повторяемую на своём стеке.