Традиційні посередники повідомлень та потокові дані

За даними сайту Kafka :

" Kakfa використовується для побудови конвеєрів даних у режимі реального часу та потокових програм. "

Шукаючи в Інтернеті далеко і широко, я знайшов таке загальновизнане визначення, що таке " потокові дані ":

• Дані потоку - це дані, що безперервно надходять від джерела до місця призначення через мережу; і
• Дані потоку не мають атомної природи, тобто будь-яка частина потоку потоку даних є осмисленою та оброблюваною, на відміну від файлу, байти якого нічого не означають, якщо у вас їх немає; і
• Дані потоку можна запускати / зупиняти в будь-який час; і
• Споживачі можуть за бажанням приєднувати та відлучати від потоку даних та обробляти лише ті частини, які вони хочуть

Тепер, якщо щось, про що я говорив вище, є невірним, неповним або абсолютно неправильним, почніть, виправляючи мене! Якщо припустити, що я більш-менш на шляху, то ...

Тепер, коли я розумію, що таке "потокова передача даних", то я розумію, що означають Кафка та Кінесіс, коли вони рахують себе як обробка / посередництво проміжного програмного забезпечення для програм із потоковими даними. Але це викликало мої інтереси: чи можна / слід "передавати проміжне програмне забезпечення" на зразок Kafka або Kinesis для неперетікання даних, як традиційні брокери повідомлень? І навпаки: чи можна / повинні традиційні MQ, такі як RabbitMQ, ActiveMQ, Apollo тощо, використовуватися для потокової передачі даних?

Візьмемо приклад, коли додаток надсилатиме постійний запуск резервного повідомлення JSON-повідомлень, які потрібно обробити, а обробка є досить складною (перевірка, перетворення даних, фільтрація, агрегація тощо):

• Справа №1: повідомлення - це кожен кадр фільму; це одна помилка JSON на відеокадр, що містить дані кадру та деякі підтримуючі метадані
• Випадок №2: Повідомлення - це дані часових рядів, можливо, чиєсь серцебиття як функція часу. Отже, повідомлення №1 надсилається, що відображає моє серцебиття при t = 1, повідомлення №2 містить моє серцебиття при t = 2 і т.д.
• Випадок №3: Дані є абсолютно розрізненими та не пов'язаними з часом або як частина будь-якого "потоку даних". Можливо, події аудиту / безпеки, які звільняються, коли сотні користувачів орієнтуються на додаток, натискаючи кнопки та вживаючи заходів

Виходячи з того, як проводиться облік рахунків Kafka / Kinesis та на моєму розумінні, що таке "потокова передача даних", вони здаються очевидними кандидатами у випадках №1 (суміжні відеодані) та №2 (суміжні дані часових рядів). Однак я не бачу жодної причини, чому традиційний брокер повідомлень, як RabbitMQ, не міг ефективно обробляти обидва ці входи.

А у випадку №3 нам надається лише подія, яка сталася, і нам потрібно обробити реакцію на цю подію. Тож для мене це говорить про необхідність використання традиційного брокера, такого як RabbitMQ. Але також немає жодних причин, через які ви не змогли б також Кафка або Кінесіс обробляти обробку даних про події.

Отже, я прагну створити рубрику, яка говорить: У мене є дані X з характеристиками Y. Я повинен використовувати потоковий процесор, як Kafka / Kinesis, щоб обробити його. Або, навпаки, той, який допомагає мені визначити: у мене є дані W із Z-характеристиками. Я повинен використовувати традиційного брокера повідомлень, щоб обробити його.

Тому я запитую: Які фактори щодо даних (або іншим чином) допомагають керувати рішенням між процесором потоку або брокером повідомлень, оскільки обидва можуть обробляти потокові дані, і обидва можуть обробляти (не потокові) дані повідомлень?

Кафка займається упорядкованими журналами атомних повідомлень. Ви можете переглядати його на зразок pub/subрежиму посередників повідомлень, але з чітким упорядкуванням і можливістю відтворення або пошуку навколо потоку повідомлень у будь-який момент минулого, який все ще зберігається на диску (що може бути назавжди).

Аромат Kafka в потоковому режимі стоїть на противагу віддаленим процедурним викликам, як Thrift або HTTP, і пакетній обробці, як в екосистемі Hadoop. На відміну від RPC, компоненти спілкуються асинхронно: можуть проходити години або дні між тим, коли повідомлення надсилається, і коли одержувач прокидається і діє на нього. У різні моменти часу одержувачів може бути багато, а може, ніхто і ніколи не потрудиться спожити повідомлення. Кілька виробників можуть виробляти одну і ту ж тему без відома споживачів. Кафка не знає, підписалися ви, чи повідомлення було використано. Повідомлення просто передається в журнал, де будь-яка зацікавлена ​​сторона може його прочитати.

На відміну від пакетної обробки, вас цікавлять окремі повідомлення, а не просто гігантські колекції повідомлень. (Хоча це не рідкість, щоб архівувати повідомлення Kafka у паркетні файли на HDFS та запитувати їх як таблиці вуликів).

Випадок 1 : Кафка не зберігає особливих часових відносин між виробником і споживачем. Це погана придатність для потокового відео, тому що Kafka дозволено сповільнювати, прискорювати, рухатися приступами та ін. Для потокового носія ми хочемо торгувати загальною пропускною здатністю в обмін на низьку і, що ще важливіше, стабільну затримку (інакше відомий як низький тремтіння). Кафка також бере великі болі, щоб ніколи не втрачати повідомлення. За допомогою потокового відео ми зазвичай використовуємо UDP і вміщуємося скидати кадр тут і там, щоб тримати відео. Загальноосвітня література у процесі, що підтримується Кафкою, зазвичай - від секунди до здорової, від годин до днів, коли вона здорова. SLA на потоковому носії становить десятки мілісекунд.

Netflix може використовувати Kafka для переміщення кадрів у внутрішній системі, яка перекодує терабайти відео на годину і зберігає їх на диску, але не пересилає їх на ваш екран.

Випадок 2 : Абсолютно. Ми використовуємо Кафку таким чином у мого роботодавця.

Випадок 3 : Ви можете використовувати Кафку для подібних речей, і ми, але ви платите непотрібні накладні витрати, щоб зберегти замовлення. Оскільки вам не байдуже замовлення, ви, можливо, могли би вичавити ще одну продуктивність із іншої системи. Якщо ваша компанія вже підтримує кластер Kafka, хоча, ймовірно, найкраще повторно використовувати його, а не взяти на себе тягар підтримки іншої системи обміну повідомленнями.

Kafka / Kinesis моделюється як потік. Потік має інші властивості, ніж повідомлення.

• Потоки мають для них контекст. Вони мають порядок. Ви можете застосувати функції вікон до потоків. Хоча кожен елемент у потоці є значущим, він може мати більше значення з контекстом навколо нього
• Оскільки потоки мають порядок, ви можете використовувати це для того, щоб робити певні твердження про семантику обробки. Наприклад, тризуб Apache нібито має рівно семантику при споживанні з потоку Kafka.
• Ви можете застосувати функції до потоків. Ви можете трансформувати потік, фактично не споживаючи його. Можна ліниво споживати потік. Ви можете пропустити частини потоку.
• Ви можете відтворювати потоки в Kafka, але ви не можете (без додаткового програмного забезпечення) відтворювати черги повідомлень. Це корисно, коли ви навіть не знаєте, що ще хочете зробити з даними. Це також корисно для тренування ШІ.

Як правило, використовуйте Kafka для обробки потоку в режимі офлайн, використовуйте черги повідомлень для повідомлень клієнта-сервера в реальному часі.

Приклад використання випадків з основного :

Kafka: Відстеження активності веб-сайтів, метрики, агрегація журналів, обробка потоків, пошук подій та журнали фіксації

RabbitMQ: обмін повідомленнями загального призначення ..., часто використовується для того, щоб веб-сервери могли швидко відповідати на запити, а не змушувати їх виконувати важкі для ресурсів процедури, поки користувач чекає результату. Використовуйте, коли вам потрібно використовувати існуючі протоколи, такі як AMQP 0-9-1, STOMP, MQTT, AMQP 1.0

Іноді може бути корисним використання обох! Наприклад, у Use Case # 2, якби це був потік даних з пейдмейкера, скажімо, я мав би виробник темпу передавати дані про серцебиття до черги повідомлень RabbitMQ (використовуючи класний протокол, як MQTT), де він негайно обробляється подивіться, чи все ще б’ється серце джерела. Це може призвести до роботи приладової панелі та системи надзвичайних ситуацій. Черга повідомлень також передасть дані часового ряду в Kafka, щоб ми могли аналізувати дані серцебиття з часом. Наприклад, ми можемо реалізувати алгоритм виявлення серцевих захворювань, помітивши тенденції в потоці серцебиття.