Всем привет! Это Андрей Серебрянский, я создал канал, чтобы делиться интересностями о мире асинхронной обработки данных. Буду здесь рассказывать про:
- особенности работы Kafka и других брокеров сообщений;
- кейсы компаний, использующих стриминг;
- Apache Flink, Kafka Streams, Apache Beam и другие фреймворки для стрим-процессинга;
- детали event-based архитектур: event sourcing, CEP, CDC, CQRS и пр.

Постить буду нерегулярно, по мере появления интересного контента.

Как говорится, ставьте реакции, пишите комментарии, подписывайтесь на канал.

Вышла долгожданная Apache Kafka 4.0! В ней:
- параллельное чтение из партиции (наконец-то можно организовать нормальную очередь задач над топиком Kafka!). KIP с подробностями. Правда это чудо пока только в early access
- полный отказ от zookeeper. Теперь в кластер поместится больше партиций, а админам кафки теперь не нужно менеджить отдельное приложение для консенсуса.
- Полный фикс транзакций и exeactly-once в Кафке, который начался еще в 3.7. Проблемы, которые могли возникнуть описаны тут

Смотри полные Release Notes тут.

P.S. Про фикс Кафкой транзакций буду рассказывать через 2 недели на JPoint: если будешь там, заходи послушать

Просто делюсь прикольной штукой, которую увидел: https://www.confluent.io/events/kafka-summit-london-2024/asyncapi-v3-whats-new/

Это доклад про Async API - аналог Open API - способ описывать стриминговые архитектуры и взаимодействия между компонентами. Бонусом в конце доклада рссказывают про всякие тулзы, которые можно с этим использовать: генераторы кода, UI, генераторы фейковых сообщений

Если коротко: есть open source инициатива - давайте описывать наши ивенты так же, как мы уже стали классно описывать наши REST ручки. Описываем все (брокеры, топики, схемы сообщений, связи между топиками) в ямликах. Если все эти ямлики собрать в одном месте, то получается стриминговая архитектура организации. Эту архитектуру можно использовать, чтобы:
- визуализировать опен сорсными тулами, чтобы не рисовать архитектурные схемы руками
- по описанию приложения в формате Async API (типа приложение app-123 читает топик some-topic в таком-то кластере с такими то параметрами безопасности и пишет в some-other-topic сообщение типа SendSomeInfo с авросхемой my-avro-schema) сгенерить Java/Python/TS приложеньку, которая сразу будет уметь читать этот топик и писать в целевой топик в заданном формате. То есть весь бойлерплейт подключения к кластеру, сериализации и десериализации, запуска, мониторинга написан за вас. Вам осталось только бизнес логику допилить.
- по описанию сообщения в формате Async API начать генерить в указанный топик сообщения с рандомными значениями по заданной схеме. Для этого есть свое опенсорсное приложение

Ну и наверное есть еще какие-то применения, но я пока не успел погрузиться дальше) Для меня главная фича - это признанный стандарт для описания того хаоса ассинхронных взаимодействий, который обычно есть в организациях)

Тут опубликовали доклады с JPoint (и в том числе мой доклад про то, что может сломаться с exactly once в Kafka)

И раз уж пишу, заодно поделюсь записями с главной конференции про стриминг: все записи с Current (бывший Kafka Summit) в Бангалоре - ссылка, в Лондоне - ссылка

Ну и заодно honorable mention классных митапов этого года, которые посмотрел:
⁃ Авито переехал с Kafka на Redpanda: ссылка
⁃ OZON провел митап в стихах: ссылка
⁃ Тинькофф рассказал как уронил всю поставку в дата-платформу на Кафке на целую неделю: ссылка

P.S. Сори, что меня давно не было. Теперь поставил себе напоминалку, чтобы писать чаще

Про exactly once обработку в Kafka.

Зимой я добавлял транзакции в Kafka API в YDB, весной сделал про это доклад, а сейчас по его следам вышла статья про то, что может пойти не так в транзакциях Kafka, да и в целом, на какие грабли с exactly once можно наступить с брокером сообщений.

Если очень коротко и тезисно:
- Транзакции в Kafka чаще всего работают, но есть несколько редких edge case-ов или ошибок конфигурации, которые могут привести к дублям. Лучше всего обновиться на kafka 4.0+, чтобы минимизировать проблемы;
- На идемпотентный продьюссер kafka лучше не полагаться для exactly once загрузки в kafka, а вот kafka connect очень хорош;
- Для выгрузки из kafka во внешние системы exactly once лучше всего положиться снова на kafka connect и идемпотентную запись.

А детали лучше смотреть в статье / докладе, ну и буду рад ответить на вопросы в комментариях)

Про федерацию брокеров сообщений
Пост по следам моего доклада на ноябрьском хайлоаде (запись в ютубе, в VK).

Федерация брокеров сообщений - это несколько кластеров брокеров сообщений с общими метаданными. Такие федерации есть как минимум в Uber, Avito и Яндексе. Используют их для разных целей и по разному:

В Uber
Федерация тут для повышения отказоустойчивости - чтобы пережить отказ целого региона в амазоне. Uber реплицирует все данные из одного кластера в другой с помощью UberReplicator и умеет быстро клиентов (как писателей, так и читателей) между ними переключать. Подробности в их докладах: старый, но больше деталей (2019) и новый, но по верхам (2024).

В Avito
Тут тоже федерация для отказоустойчивости и удобства эксплуатации, но работает чуть по-другому: есть несколько кластеров Redpanda, в которые идет запись и из всех них данных реплицируются в кластер, из которого уже идет чтение. Детали в статье на хабре.

В Яндексе
Тут федерация нужна для экономии. Яндекс использует в качестве брокера YDB Topics, который умеет в erasure coding (если коротко, то мы отказоустойчиво храним данные, занимая всего х1,5 места, а не х3 как в Kafka). Детали в докладе (с таймкодом).

Нужна ли федерация всем?
Не уверен) Самостоятельно федерацию построить трудно: много edge case-ов в моменте отказа одного из кластеров. Да и выгода от федерации есть только, если вы теряете очень много денег при отказе брокера (как в Uber и Avito), или если у вас очень много данных (как в Яндексе - 150 gb/s). Говорят, каждая следующая девятка стоит в 10 раз дороже предыдущей. Тут примерно похожая математика - для федерации вам нужно больше инфраструктуры и команда для поддержки бизнес-логики репликации и переключения клиентов в сценарии катастрофы. А это дорого.

P.S. Всех с наступившим! В новом году да не раскопает эскалатор кабели у ваших дата-центров, да не снизятся ваши девятки и пусть latency будут низкими, а throughput - высоким!

Разобрался тут для будущего доклада, зачем добавляют очереди/топики в базу данных.

Оказалось, что причин 2:

1. Экономим на инфраструктуре: вместо брокера и базы данных у нас теперь только база данных. Так, например, предлагает делать PG Pro (который продает Postgres) и Oracle (который продает Oracle). Очереди в pg pro (дока) и oracle (дока) довольно ограничены по функциональности, поэтому мне сложно представить, как они могут заменить ту же Kafka со всей ее экосистемой. Поэтому переходим к пункту 2.

2. Приоритетная очередь. Вот это как раз удобно. В Kafka сейчас нет приоритетной очереди, а с помощью расширения для привычной базы такую очередь можно легко получить. Так, например, делает Яндекс 360. Бонусом к приоритетной очереди вы получаете единый транзакционный контур - вы пишете в свою таблицу и в свою очередь в одной транзакции с ACID гарантиями. Очень удобно, не надо изобретать transactional outbox.

Если знаете еще причины, чтобы использовать БД как очередь, напишите плз в комменты

P.S. Доклад наверное не случится, потому что контента мало, но зато хватило на пост)

P.P.S. В Яндексе мы кстати тоже сделали топики и таблицы в одной базе (в YDB) и тут причина скорее в том, что было очень удобно все эти огромные объемы данных надежно хранить на одной технологии, которую мы сами же и можем дорабатывать. Потом мы расширили наши топики Kafka протоколом, добавили SQS-протокол (для работы как с очередью) и разработали много других крутых фишек.