В технологическом блоге Uber опубликована статья «Введение в многоуровневое хранилище Kafka в Uber», целью которой является максимальное сохранение данных при меньшем количестве брокеров Kafka и меньшем объеме памяти. Это позволяет увеличить время хранения сообщений в различных бизнес-приложениях.

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

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

Сценарий

Важно понимать, что Kafka — это компонент очереди сообщений (MQ), предназначенный только для добавления, с очень высокой пропускной способностью. Kafka хранит журналы в локальном хранилище брокера, и пользователи могут настроить время хранения или размер журнала. В моей предыдущей компании (Lenovo) мы использовали Flink для непрерывного потребления данных. Большой объем данных может привести к превышению лимита дискового пространства Kafka, что приведет к сбоям записи данных и бизнес-ошибкам. Чтобы сократить расходы, вместо развертывания большего количества компьютеров мы могли лишь корректировать время хранения.

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

Решение

Суть в том, чтобы трансформировать Брокера, добавив в него удаленное управление логами и хранилищем.

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

RemoteStorageManager: управляет действиями для удаленных сегментов журнала, включая копирование, выборку и удаление. Метаданные, связанные с удаленными сегментами журнала, включают информацию о смещениях начала и конца сегмента, метках времени, моментальных снимках состояния производителя и контрольных точках ведущей эпохи.
] RemoteLogMetadataManager отслеживает эти метаданные, чтобы гарантировать, что система знает, где начинается и заканчивается каждый сегмент, а также другую важную информацию, необходимую для поиска данных и управления ими.

RemoteLogMetadataManager: управляет жизненным циклом метаданных для удаленных сегментов журнала с высокой согласованностью.

Среди них RemoteLogManager действует как компонент управления, напрямую подключаясь к диску в брокере для получения считанных данных. Он также отвечает за обратный вызов удаленных данных. RemoteStorageManager — это объект, который работает с данными, а RemoteLogMetadataManager отвечает за управление метаданными.

Краткое описание трех действий в многоуровневом хранилище Kafka

1. Копирование сегментов в удаленное хранилище
   Сегмент журнала считается пригодным для копирования в удаленное хранилище, если его конечное смещение (смещение последнего сообщения в сегменте) меньше, чем последнее стабильное смещение раздела. (Last-Stable-Offset (LSO): наибольшее смещение для которого все предыдущие сообщения полностью подтверждаются всеми синхронизированными репликами, что гарантирует отсутствие потери данных.）RemoteStorageManager обрабатывает копирование сегментов журнала вместе со связанными с ними индексами, временными метками, снимками производителей и кешем ведущей эпохи.

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

3. Извлечение сегментов из удаленного хранилища
   RemoteLogManager определяет целевой удаленный сегмент на основе желаемого смещения и ведущей эпохи, просматривая хранилище метаданных с помощью RemoteLogMetadataManager. Он использует RemoteStorageManager, чтобы найти позицию в сегменте и начать получение нужных данных.