Pinot научился настраивать партиционирование под Kafka

StarTree добавил в Apache Pinot framework Custom Hash Function, который позволяет описывать сложные правила партиционирования прямо в конфигурации таблицы. Это решает проблему, когда Kafka и Pinot расходятся в способе расчёта номера партиции, из-за чего broker не может выполнять partition pruning и разбрасывает запросы по всей кластеру. Для observability-пайплайнов с жёсткими требованиями по latency такое расхождение превращает sub-second запросы в десятки секунд.

Почему расхождение в хеше ломает pruning

В типичной схеме OpenTelemetry → Kafka → Pinot именно Kafka решает, в какую партицию попадёт событие. Pinot хранит метаданные сегментов и использует ту же логику, чтобы при фильтре по ключу типа correlationId отправлять запрос только на нужные серверы. Если формула отличается хотя бы на один шаг, метаданные оказываются бесполезными и broker вынужден опрашивать все узлы. Partition pruning здесь означает механизм, при котором система отсекает заведомо нерелевантные узлы кластера ещё на этапе планирования запроса, сокращая объём данных, которые нужно сканировать. Без него запросы превращаются в полное сканирование, что особенно критично при больших объёмах телеметрии.

В описанном случае upstream применял fnv1(md5(correlationId)), а Pinot изначально умел только fnv1(correlationId). Даже после добавления FNV-1a pruning не заработал, потому что промежуточный MD5 остался скрытым. В результате p99 latency выросла до 10 секунд, хотя требования были sub-second. Broker в такой ситуации не может использовать метаданные сегментов для точечного обращения к серверам, и каждый запрос начинает обходить весь кластер. Это приводит к росту потребления ресурсов и нестабильности при пиковых нагрузках, когда observability-данные поступают непрерывно из распределённых источников.

Как устроен новый фреймворк

Вместо добавления отдельных функций под каждый частный случай разработчики сделали общий механизм Custom Hash Function. Логика теперь задаётся в разделе tableIndexConfig.segmentPartitionConfig, где можно описать произвольную цепочку преобразований ключа. Pinot получает возможность точно повторить upstream-поведение без изменения продюсера или переписывания данных. Такой подход позволяет интегрировать Pinot в уже существующие контуры, где upstream-логика задана сторонними системами и не подлежит изменению.

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

Что это даёт на практике

После того как Pinot начал вычислять партиции точно так же, как upstream, pruning заработал. Запросы стали попадать только на серверы, которые реально могли содержать данные, и p99 latency упала со ~10 с до сотен миллисекунд. При высокой concurrency и больших объёмах observability-данных экономия на fan-out заметно снижает и latency, и нагрузку на кластер. Fan-out здесь — это ситуация, когда запрос параллельно отправляется на все узлы вместо ограниченного набора, что увеличивает общую задержку и потребление CPU.

Для команд в РФ, где часто встречаются гетерогенные пайплайны с Kafka от разных поставщиков и legacy-продюсерами, возможность явно задать формулу хеша в конфиге Pinot позволяет избежать дорогостоящих переделок upstream. Не нужно требовать от смежных команд изменения кода, достаточно описать существующую логику в таблице Pinot. Это особенно ценно в средах с жёсткими SLA по времени отклика, где даже небольшое сокращение fan-out даёт ощутимый эффект на общую пропускную способность системы.

Ограничения и когда стоит внедрять

Фреймворк требует точного знания upstream-логики, включая все промежуточные хеши и преобразования. Если эта информация отсутствует или часто меняется, эффект от pruning будет нестабильным. Кроме того, custom-функция добавляет вычислительную нагрузку при ingestion и при планировании запросов, поэтому на очень простых ключах выигрыш может оказаться невелик. При оценке стоит учитывать, что дополнительная нагрузка проявляется как на этапе записи данных, так и при каждом планировании запроса, что может повлиять на общую утилизацию ресурсов кластера.

Внедрять стоит тогда, когда partition pruning уже является ключевым механизмом снижения latency и когда расхождение в партиционировании подтверждено метаданными сегментов. В остальных случаях проще использовать стандартные функции или выровнять продюсера под возможности Pinot. Перед внедрением рекомендуется провести аудит текущих метрик latency и убедиться, что именно расхождение в хеше является основной причиной деградации, а не другие факторы вроде размера сегментов или конфигурации брокеров.

Источник

Это краткий разбор материала StarTree. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Pinot научился настраивать партиционирование под Kafka.

Курс по теме — Каталог курсов Школы Больших Данных