Comments 20
Вообще, проблема мне кажется в двух основных свойствах Кафка. Первое, это бесплатный продукт. Поэтому его commit это вещь совершенно эфемерная. То есть даже если в коде стоит «noop», то с точки зрения Кафка, это приемлемо. Ведь не секрет, что Американская фирма по производству батареек на заре своего существования укладывала в корпус батареек грунт со двора предприятия, и пользуясь колоссальной дешевизной исходного сырья продавала свои изделия за половину стоимости конкурентов.
По сей причине повторяющийся припев писателя, что мол «но ведь это не применимо, там, где речь идет о деньгах вкладчиков» слушается с юмором. Это конечно очень хорошо, что автор это понимает. Но как — то вот это самое понимание с действиями вместе не очень консистентно.
Вторая, если мое очень поверхностное знакомство с Кафкой я запомнил верно, у Кафка есть возможность воспользоваться разными носителями для хранения записей. По умолчанию она воспользуется файловой системой. И тут commit очень сильно зависит от файловой системы, и даже сборки машины, которая её обеспечивает. Но есть возможность и воспользоваться СУБД. Тем самым открывая доступ к хорошо проверенному механизму обеспечения операции commit. Но тогда КАФКА становится ни чем иным, как ширмой для СУБД.
Что касается скорости обработки пакетов, то простейшая extended procedure на с для Microsoft SQL Server с одним CPU Pentium 2.0 и 1 GB памяти поддерживал производительность 60,000 пакетов в секунду.
То есть в принципе статья конечно полезная, автору огромное спасибо. Но умудриться так долго говорить о дубликатах и производительности, не приведя ни одного эксперимента ( а для сравнения их нужно как минимум два ) получается двойственное ощущение богатого материала и отсутствия сути.
Наиболее близкая по архитектуре, описанной в статье, система сейчас обрабатывает около 3000 сообщений в секунду. Размер сообщений единицы килобайт.
Планируем запускать потоки, которые увеличат нагрузку в 10 раз. Под эту нагрузку развернули кластер из 6 брокеров Kafka.
0) В мире open source есть зилиард различных messaging solutions и messaging midlleware (zeromq, activemq, rabbitmq) Хотя бы два слова, почему взгляд пал на Kafka?
1) Так из-за чего возникают дубликаты? Можете расписать по шагам в каком сценарии kafka пересылает сообщение consumer'у повторно? Честно говоря, не понял концепции партиций, групп и топиков и как они соотносятся друг с другом и consumer'ам. Что такое ребалансировка? Наверняка есть какая-то наглядная картинка в Kafka user guide. Был бы признателен за ссылку
3) Было бы интересно посмотреть на более подробное описание экспериментов на стенде с указанием использованного железа, сути экспериментов и полученных результатов (цифра 60000 событий/сек без деталей не говорит ни о чем)
4) Стримы и архитектура базирующаяся на событиях, достаточно старая тема. У Fawler'а она датируется 2005годом: https://martinfowler.com/eaaDev/EventSourcing.html
В мире open source есть зилиард различных messaging solutions и messaging midlleware (zeromq, activemq, rabbitmq) Хотя бы два слова, почему взгляд пал на Kafka?
Классический messaging не обеспечивает возможности replay потока сообщений.
Одно время мы смотрели на RabbitMQ и AMQP аналоги, но в результате Кафка победила за счет персистентности с хорошими показателями производительности и масштабируемости. Спектр open source потоковых решений по передаче информации сводится к Apache Kafka, nats.io, Apache Pulsar. Их, увы, не так много как messaging solutions. Причем последние два решения появились недавно.
Так из-за чего возникают дубликаты?
Концепции топика, партиции и пр. подробно описаны в штатной документации Apache Kafka https://kafka.apache.org/documentation/
Дубли сообщений возникают после ребаланса consumer group при наличии сообщений, для которых не был выполнен commit.
Рекомендую почитать тут https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/
Было бы интересно посмотреть на более подробное описание экспериментов на стенде
Согласны, что нюансов много. Публиковать детальные результаты с анализом и рекомендациями по оптимизации производительности пока не можем :) В составе Apache Kafka есть штатные скрипты проверки производительности. Запустите на своем оборудовании и посмотрите результаты.
4) Стримы и архитектура базирующаяся на событиях, достаточно старая тема. У Fawler'а она датируется 2005годом: https://martinfowler.com/eaaDev/EventSourcing.html
На уровне идей тема дискутируется довольно давно. Event Sourcing начинал использовать в 2008. Думаю, что явно не первым (и даже не вторым) в мире и России.
Но вот готовые движки с реализацией stateful stream processing появились не так давно.
Как вы решили проблему event sourcing. Как я понял держать данные навсегда не получается, то есть retention time как то ограничено. Все данные нужно перенести в hadoop или nosql а если
replay то опять назад? Возможно не актуальная тема, но всё же, если данные оставить в кафке, то как достичь GDPR / right to forget. CRUD не возможен.
Какие отзывы от Ops? Кафка довольно сложнa в управлении.
Какой у вас опыт по resharding? То есть если уже пару терабайтов, то просто не получается.
Как выглядит audit и encryption?
Возможно NoSQL СУБД с change data capture был бы проще и архитектура выгледела не такой комплексной?
Как я понял держать данные навсегда не получается, то есть retention time как то ограничено.
Держать данные, необходимые для работы потока (справочники и накопленную информацию), нужно. Удалять устаревшие данные можно аналогично обычным непотоковым решениям. Для оконных алгоритмов агрегации после закрытия окна (и поступления поздних событий) результат фиксирован и не поменяется. Его можно сбросить в выходной поток за пределы движка потоковой обработки. Далее хранить и чистить опять же как и в обычных решениях.
Возможно не актуальная тема, но всё же, если данные оставить в кафке, то как достичь GDPR / right to forget.
С помощью topic retention
Какие отзывы от Ops? Кафка довольно сложнa в управлении.
Эксплуатируем, особых сложностей не заметили. Можете уточнить вопрос?
Какой у вас опыт по resharding?
Избегаем всеми силами. Операция дорогая по вычислительным ресурсам.
Как выглядит audit и encryption?
В кафке из коробки этого нет. Делали простые решения с помощью interceptors Кафки. Но если нет контроля за машинами где развернуты producers и consumers, толку от этого мало, так как interceptors могут быть отключены или подменены. Хорошо бы иметь interceptors на стороне брокера, но пока в ближайших планах у Confluent таких доработок не видел.
Возможно NoSQL СУБД с change data capture был бы проще и архитектура выгледела не такой комплексной?
Вомможно. Но придется решать задачи запуска map-reduce агрегаций для аналитических задач. Не уверен, что архитектура получится проще.
С помощью topic retentionИмеете ввиду compaction? Было такое размышление, но compaction даёт возможность иметь только distinct values by unique key. Тоесть клиент id 4711 дважды не может быть в topic. Поэтому отказались от compaction. Хотя закинув key 4711: value null, тогда GDPR-right to forget сработал бы.
Какие отзывы от Ops? Кафка довольно сложнa в управлении.
Эксплуатируем, особых сложностей не заметили. Можете уточнить вопрос?
Кафка это не только брокер, а также Zookeeper и следующие компоненты, REST proxy, schema etc. Продукт не даёт ощущения, что был сконструирован для enterprise и из за своей комплексности не прост в Ops. Нужно имеет очень хорошую и опытную команду Ops. На рынке open source есть примеры, как продукты могут быть просты в обращение в production.
Вомможно. Но придется решать задачи запуска map-reduce агрегаций для аналитических задач. Не уверен, что архитектура получится проще.
не в целях рекламы — MongoDB; aggregation framework + change streams, всё в одном?
В целом, спасибо за статью и ответы!
в Kafka все унифицировано, и разницы между Point-to-point и Publish-subscribe нет, в том числе и в API для программиста
Вот именно, поэтому режима ptp там нет в принципе (и более того, его очень сложно реализовать если вам нужны именно классические очереди с гарантированной доставкой и прочими ништяками, смотреть тут softwaremill.com/using-kafka-as-a-message-queue), а управление тем, кто и как получает сообщение, как раз и осуществляется посредством API программиста, а конкретно — через consumer groups, как вы ВНЕЗАПНО и узнаете ниже в статье :).
Так в топике можно сделать много партиций и посадить много читателей.
Число партишенов при этом должно быть не меньше числа консюмеров, иначе у вас будет consumer starvation.
В этот момент мы поняли: Kafka — это не совсем очередь.
А точнее, совсем не очередь ;).
Происходит ребаланс, и в течение некоторого времени брокер не отдает читателям никаких сообщений, пока ребаланс не произойдет.
Дело даже не в дублировании. Ребаланс — очень дорогая операция и примерно половина всех оптимизаций консюминга заключается в том чтобы его избежать, что выливается в шаманство с членством в группах и конфигурацией топиков. Самый простой способ, который вам надо было изначально применять — программное уравнивание. Создаете топик с N партишенов и при инициации консюминга создаете группу с N консюмерами. При этом, самый фан начинается когда вы топики и консюмеров в рантайме создаете, динамически. В сложных топологиях такого рода (напр. для построения микросервисных мешей) ребаланс в любом месте моментально убьет всю систему и окажется что группы из более чем 1 консюмера вообще надо применять очень аккуратно и в очень специфичных случаях.
События распределяются по ним в соответствии с ключами, которые мы событиям присваиваем… События внутри одной партиции упорядочены по времени… Второй подход — партиционирование потока при чтении.
Это ж называется CBR, или я чего-то не понял? Коллективный разум считает CBR антипаттерном Кафки и намекает, что если вам потребовалось его реализовать, то вы что-то не так делаете, т.к. кафка себя всегда позиционировала как быстрый транспорт, без этих ваших JMSов. Ну и да, термин «корреляция» в статье замечен не был, хотя обязан был быть.
Но есть такой класс задач — алгоритмы аналитики — где результатом обработки потока являются агрегаты событий… Как это реализовать?
Подключением к топику дополнительной группы консюмеров, выполняющих аналитику (имеется ввиду же онлайн-аналитика?). Потоковые вычисления, в т.ч. и аккумуляционные, испокон веков применялись в DSP и если честно я совсем не понял, зачем вам потребовалась наркомания с плавающими окнами на едином потоке.
Подумаем, как организовать доступ к данным потоковой архитектуры — данным в базах данных обработчиков событий.
Для RDBMS — на самом деле никак, пока не появятся реактивные драйвера для БД (Напр., ADBA для Oracle). JDBC является синхронным и блокирует все что нужно блокировать, поэтому в реактивных архитектурах их и не используют, либо реализуют волшебный CQRS и неблокирующие костыли.
***
От себя добавлю что термин «потоковая архитектура» правильно называется сейчас в источниках «reactive architecture» и строится на основе спецификации reactive streams.
В целом, есть у меня подозрение что если вы проведете бенчмарки одной и той же сложной бизнес-задачи на том решении что вы реализовали на базе Кафки и например на ActiveMQ (который еще с 2007 года поддерживает pub/sub, корреляцию и CBR чуть более чем полностью из коробки, в отличие от сатанинского MQ и чуть более кошерного Rabbit), то результаты у вас получатся примерно схожие, без учета кластеризации конечно, Кафка здесь вне конкуренции.
Почему? Потому что вы в статье использовали Кафку как аналог JMS-провайдера, накрутив поверх кучу поделок, компенсирующих напрочь отсутствующие в Кафке фичи спецификации. Кафку нельзя использовать как замену JMS, весь ее великий смысл — максимально быстро и эффективно передать много-много данных от продюсера к консюмеру. Что это за данные, какая у них семантика и тем более корреляция, как их лучше или хуже консюмить — это все вопросы приклада.
Кроме того, при безграничном масштабировании ВНЕЗАПНО окажется что больше 1-2к топиков на кластер Кафки делать совсем-совсем не рекомендуется и надо будет переосмысливать топологию (см. мои комментарии выше). Это выльется в фееричную боль, потому что переделывать надо будет вообще все.
очень хочется ответ @Sberbankувидеть
Дао интеграции Сбербанка: от локальных сетей к Kafka и потоковой разработке