Кафка: Consumer API vs Streams API

Нещодавно я почав вивчати Кафку і закінчую цими питаннями.

1. У чому різниця між Consumer і Stream? Для мене якщо будь-який інструмент / програма споживає повідомлення від Kafka - споживач у світі Kafka.

2. Чим потік відрізняється, оскільки він також споживає або створює повідомлення Кафці? і навіщо це потрібно, оскільки ми можемо писати власну споживчу програму за допомогою API споживача та обробляти їх за потреби або надсилати до Spark із споживчої програми?

Я працював у Google, але не отримав жодної хорошої відповіді на це. Вибачте, якщо це питання занадто тривіальне.

Оновлення 09 квітня 2018 р . : Сьогодні ви також можете використовувати ksqlDB , базу даних потокової передачі подій для Kafka, для обробки ваших даних у Kafka. ksqlDB побудований поверх API потоків Kafka, і він також має першокласну підтримку "потоків" і "таблиць".

у чому різниця між API споживачів та API потоків?

API потоків Kafka ( https://kafka.apache.org/documentation/streams/ ) побудований на базі клієнтів виробників та споживачів Kafka. Це значно потужніше, а також виразніше, ніж клієнт Kafka. Ось деякі особливості API Kafka Streams:

• Підтримує семантику обробки точно один раз (версії Kafka 0.11+)
• Підтримує відмовостійку державну (як і бездержавну, звичайно) обробку, включаючи потокові об’єднання , агрегації та вікна . Іншими словами, він підтримує нестандартне управління станом обробки вашої програми.
• Підтримка обробка подій часу , а також обробка на основі обробки часу і проковтування час
• Має першокласну підтримку як потоків, так і таблиць , саме там обробка потоків відповідає базам даних; на практиці більшості додатків для обробки потоків потрібні як потоки, так і таблиці для реалізації відповідних випадків використання, тому, якщо в технології обробки потоків не вистачає жодної з двох абстракцій (скажімо, немає підтримки таблиць), ви або застрягли, або повинні самостійно реалізувати цю функцію (удачі в цьому ...)
• Підтримує інтерактивні запити (також звані "стан запиту"), щоб представити останні результати обробки в інших програмах та службах
• Є більш виразним: він поставляється з (1) функціональний стиль програмування DSL з операціями , такими як map, filter, reduceа також (2) імперативний стиль процесора API для , наприклад , робити складну обробку подій (CEP), і (3) можна навіть комбінувати DSL і процесор API.

Дивіться http://docs.confluent.io/current/streams/introduction.html для більш детального, але все ще високого рівня вступу до API Kafka Streams, який також повинен допомогти вам зрозуміти відмінності від нижчого рівня споживача Kafka клієнт. Існує також підручник на основі Docker для API Kafka Streams , про який я писав блоги на початку цього тижня.

То чим же відрізняється API потоків Kafka, оскільки він також споживає або створює повідомлення Kafka?

Так, API Kafka Streams може як читати дані, так і записувати дані в Kafka.

і навіщо це потрібно, оскільки ми можемо писати власну споживчу програму за допомогою API споживача та обробляти їх за потреби або надсилати до Spark із споживчої програми?

Так, ви можете написати свій власний споживчий додаток - як я вже згадував, API Kafka Streams використовує клієнт Kafka споживача (плюс клієнт виробника), але вам доведеться вручну реалізувати всі унікальні функції, які надає API Streams . Перегляньте список вище для всього, що ви отримуєте "безкоштовно". Таким чином, досить рідкісна обставина, що користувач вибирає споживчого клієнта низького рівня, а не більш потужний API Kafka Streams.

Компонент Kafka Stream, побудований для підтримки типу трансформації повідомлень ETL. Засоби введення потоку з теми, перетворення та виведення в інші теми. Він підтримує обробку в режимі реального часу і в той же час підтримує попередні аналітичні функції, такі як агрегація, вікно, приєднання тощо.

"Kafka Streams спрощує розробку додатків, спираючись на бібліотеки виробників та споживачів Kafka та використовуючи власні можливості Kafka, щоб запропонувати паралельність даних, розподілену координацію, стійкість до відмов та простоту роботи".

Нижче наведені ключові архітектурні особливості потоку Кафка. Будь ласка, зверніться сюди

1. Розділи та завдання потоку : Kafka Streams використовує концепції розділів та завдань як логічні одиниці своєї моделі паралелізму на основі розділів теми Kafka.
2. Модель потокових потоків : Kafka Streams дозволяє користувачеві налаштувати кількість потоків, які бібліотека може використовувати для паралелізації обробки в екземплярі програми.
3. Місцеві державні магазини : Kafka Streams пропонує так звані державні сховища, які можуть використовуватися додатками для обробки потоків для зберігання та запиту даних, що є важливою можливістю при реалізації операцій із збереженням стану.
4. Толерантність до несправностей: Потоки Kafka базуються на можливостях відмовостійкості, інтегрованих в Kafka. Розділи Kafka є високодоступними та тиражуються, тому, коли дані потоку зберігаються для Kafka, вони доступні, навіть якщо додаток виходить з ладу і потребує їх повторної обробки.

Виходячи з мого розуміння нижче, є ключові відмінності, я відкритий для оновлення, якщо якийсь момент відсутній або вводить в оману

Де використовувати споживача - виробника:

1. Якщо є одиничні споживачі, споживайте процес надсилання повідомлень, але не переходьте до інших тем.
2. Як пункт 1, якщо у нас є лише продюсер, що виробляє повідомлення, нам не потрібен потік Кафка.
3. Якщо споживче повідомлення від одного кластера Kafka, але публікується для різних тем кластера Kafka. У цьому випадку навіть ви можете використовувати Kafka Stream, але вам потрібно використовувати окремий продюсер, щоб публікувати повідомлення в різних кластерах. Або просто скористайтеся механізмом споживача - виробника Kafka.
4. Пакетна обробка - якщо є вимога зібрати повідомлення або різновид пакетної обробки, це добре, щоб використовувати звичайний традиційний спосіб.

Де використовувати потік Кафка:

1. Якщо ви споживаєте повідомлення з однієї теми, перетворіть та публікуйте їх на інші теми Kafka Stream найкраще підходить.
2. Обробка в реальному часі, аналітика в реальному часі та машинне навчання.
3. Трансформація з угрупованням, така як агрегація, вікно об’єднання тощо.
4. Планується використовувати місцеві державні магазини або змонтовані державні магазини, такі як Portworx тощо.
5. Досягти Рівно однієї обробки семантичної та автоматично визначеної відмовостійкості.