Прочитала на Реддите, что приняли KIP-1150: Diskless Topics.
Жень, что это значит?
Сейчас разберемся.
Кафку сделали в LinkedIn и передали в Apache Foundation, где она стала опенсорс. Любой может поднять себе на сервере Кафку и пользоваться ей, покупать лицензию не нужно. Более того, можно не просто пользоваться Кафкой, но и дописать в нее фичу и продавать получившийся продукт.
Или можно продавать managed Kafka. Когда облачный провайдер поднимает Кафку у себя в облаке, сам ее поддерживает, а вы просто пользуетесь ей как сервисом (девопсы не дадут соврать, что не все идеально, но решение рабочее).
Например, managed Kafka есть у Confluent, AWS, Aiven, у Yandex Cloud и MWS Cloud.
KIP (Kafka Improvement Proposal) — это дизайн-документ, где описывается какая-то проблема и предлагаемое архитектурное решение. Сообщество обсуждает KIP, затем контрибьюторы его реализуют.
Diskless топики пока не появились в самой Кафке, а реализованы только в форке Inkless от компании Aiven, который и стал основой для KIP-1150. Разные компании уже делали свои похожие решения, но они были коммерческие. А теперь будут делать опенсорсное решение.
Что такое Diskless Topics? Какую проблему решаем?
Сейчас Кафка хранит сообщения на локальных дисках. Это дает низкую задержку (latency): Кафка работает быстро. Для надежности используется репликация, то есть данные хранятся несколько раз (на лидере, на репликах).
Однако когда мы храним на дисках много данных и еще их копии - это оказывается дорого. Особенно если в топике данные не о важных платежах, а какие-нибудь логи, которые конечно нужны, но и сэкономить на них хотелось бы.
При этом есть S3 Object Storage, хранение в котором намного дешевле.
Идея diskless topics: хранить сообщения не на дисках брокеров, а в S3 хранилище.
В обычном топике:
Продюсер -> Брокер -> Сохраняем на локальный диск -> Реплицируем в другие брокеры
В diskless topics:
Продюсер -> Брокер -> Сохраняем в S3
Сообщения все же будут временно записываться на локальный диск, пока не закончится активный сегмент, потому что сохранять в S3 по одному сообщению будет сильно медленнее. В S3 будет загружаться готовый сегмент.
Так что это скорее disk-for-a-moment topics, но это звучит не так круто, как diskless 😃
В чем минусы?
Latency: у diskless topics задержка может быть до ~ 2 секунд против миллисекунд у обычных топиков.
Меняется ли что-то в работе консьюмеров?
Практически ничего. Diskless topics специально проектируются так, чтобы Kafka API и модель потребления остались прежними. Наш консьюмер может даже не знать, что этот топик diskless.
Партиции, сегменты и оффсеты остаются. Меняется только внутренний путь чтения данных: брокер читает сегменты из S3 хранилища (с использованием кэша).
Что с надежностью?
Как писала выше, в Кафке надежность достигается за счет репликации партиций. В diskless топиках вопрос надежности делегируется S3 Object Storage. S3 сам хранит несколько копий данных, а Kafka хранит метаданные и управляет партициями.
Кафка гарантировала порядок сообщений внутри одной партиции, сохранится ли эта фича в diskless topics?
Да.
В классических топиках порядок обеспечивается благодаря тому, что сообщения пишутся в файлики как в append-only log. Для каждой партиции есть только один лидер, через которого и идут все записи.
В diskless топиках сохраняется идея, что у каждой партиции в конкретный момент времени есть только один writer. Если он упадет, то контроллер выберет для партиции нового writer-а.
Когда это пригодится?
Diskless топики медленные и дешевые, они подойдут для потоков большого объёма, где допустима более высокая задержка, например:
🟢 логи
🟢 данные для аналитических систем и дата-лейков
🟢 события аудита
Обычные топики быстрые и дорогие: актуальны для real-time сценариев (платежи, бизнес-события).
Интересно, что этот подход compute + object storage уже используется во многих Big Data системах: Spark, Flink и др.
В комментариях оставлю ссылки на статьи по теме.
А еще у меня есть серия постов про Кафка (от основ до share groups) и пост про S3.