Речь шла о фильтрации внутри сервера (брокера), поэтому, когда у вас есть потоки со многими ГБ и низкой избирательностью, большая часть потока не достигает потребителей (приложений). Но KSQL и KStreams являются клиентскими библиотеками == полный поток достигает всех клиентов, и они выполняют фильтрацию.

трю в потоки Кафки. Я хочу отфильтровать свой поток, используя фильтр с очень низкой селективностью (один на несколько тысяч). Я смотрел на этот метод:https://kafka.apache.org/0100/javadoc/org/apache/kafka/streams/kstream/KStream.html#filter(org.apache.kafka.streams.kstream.Predicate)

Но я не могу найти никаких доказательств того, будет ли фильтр оценен потребителем (я действительно не хочу передавать много ГБ потребителю, просто чтобы выбросить их), или внутри брокера (ура!).

Если его оценить на стороне потребителя, есть ли способ, как это сделать в брокере?

Спасибо!

Ответы на вопрос(2)

Решение Вопроса

те Streams API, фильтрация будет выполняться в вашем приложении (предикат не будет оцениватьсяKafkaConsumer но внутри "процессорного узла" вашей топологии - т. е. в коде среды выполнения Streams API).

Это может помочь:https://docs.confluent.io/current/streams/architecture.html

Причина, по которой не поддерживается фильтрация на стороне брокера, заключается в том, что брокеры используют только (1) байтовые массивы в качестве типов данных ключа и значения и используют (2) механизм нулевого копирования для достижения высокой пропускной способности. Для десериализации данных на стороне брокера потребуется фильтрация на стороне брокера, что станет основным ударом по производительности (стоимость десериализации и отсутствие оптимизации с нулевым копированием).

 malejpavouk20 янв. 2018 г., 16:14
Это все еще решение на стороне клиента ... моя проблема в том, что я хочу передать эти сообщения из брокера ...
 malejpavouk06 окт. 2017 г., 21:31
хорошо ... я был бы вполне хорошо даже с фильтрацией только ключа. Для меня это было бы гораздо меньшим ударом, если бы kafka только что позволил использовать фильтрацию массива "prefix" (мои ключи - строки, и я могу выбрать префикс для сопоставления), чем передавать много ГБ данных ...
 Hans Jespersen08 окт. 2017 г., 06:19
Можете ли вы легко выразить свои правила фильтрации в виде оператора Kafka Connect SMT (Single Message Transform) или оператора KSQL? Это самый простой способ добавить встроенную фильтрацию в конвейер Kafka.
 Matthias J. Sax06 окт. 2017 г., 22:16
Вы всегда можете создать запрос функции Jira:issues.apache.org/jira/projects/KAFKA
 malejpavouk06 окт. 2017 г., 22:44
хорошая точка зрения. Я создал запрос на улучшение:issues.apache.org/jira/browse/KAFKA-6020посмотрим, понравится ли им идея :-)

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

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

 malejpavouk11 окт. 2018 г., 09:08
И KSQL, и потоки на стороне клиента
 malejpavouk12 окт. 2018 г., 09:12
Речь шла о фильтрации внутри сервера (брокера), поэтому, когда у вас есть потоки со многими ГБ и низкой избирательностью, большая часть потока не достигает потребителей (приложений). Но KSQL и KStreams являются клиентскими библиотеками == полный поток достигает всех клиентов, и они выполняют фильтрацию.
 de.la.ru11 окт. 2018 г., 16:08
Что вы подразумеваете под KSQL на стороне клиента? Как работает эта настройка?

Ваш ответ на вопрос