Моделювання даних з Kafka? Теми та розділи

Одне з перших, про що я думаю, коли користуюся новою службою (наприклад, сховищем даних, що не є RDBMS, або чергою повідомлень), є: "Як я повинен структурувати свої дані?".

Я читав і переглядав деякі вступні матеріали. Зокрема, візьмемо, наприклад, Kafka: розподілену систему обміну повідомленнями для обробки журналів , яка пише:

• "Тема - контейнер, з яким пов'язані повідомлення"
• "Найменша одиниця паралелізму - це розділ теми. Це означає, що всі повідомлення, які ... належать до певного розділу теми, споживаються споживачем у групі споживачів".

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

Наприклад, скажімо, що мої дані (Clojure) виглядають так:

{:user-id 101 :viewed "/page1.html" :at #inst "2013-04-12T23:20:50.22Z"}
{:user-id 102 :viewed "/page2.html" :at #inst "2013-04-12T23:20:55.50Z"}

Чи повинна базуватися тема user-id? viewed? at? Що з розділом?

Як прийняти рішення?

Структуруючи свої дані для Kafka, це дійсно залежить від того, яким чином вони будуть споживатись.

На мій погляд, тема - це групування повідомлень подібного типу, які споживатимуть однотипні споживачі, тому у наведеному вище прикладі я б просто мав одну тему, і якщо ви вирішите натиснути якийсь інший тип Дані через Kafka, ви можете додати нову тему для цього пізніше.

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

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

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

Як тільки ви дізнаєтесь, як розділити потік події, назва теми стане простою, тому давайте відповімо спочатку на це питання.

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

Наприклад:

1. Якщо ви дбаєте про середній час перебування користувачів на сайті, то вам слід розділити його :user-id. Таким чином, всі події, пов’язані з діяльністю сайту одного користувача, будуть доступні в одному розділі. Це означає, що двигун потокової обробки, такий як Apache Samza, може обчислити середній час перебування на сайті для певного користувача, просто переглянувши події в одному розділі. Це дозволяє уникнути необхідності виконувати будь-які затратні обробки розділів у глобальному масштабі
2. Якщо ви дбаєте про найпопулярніші сторінки вашого веб-сайту, вам слід розділити їх :viewed. Знову ж таки, Самза зможе зберегти кількість переглядів певної сторінки, просто переглянувши події в одному розділі

Як правило, ми намагаємось уникати глобального стану (наприклад, зберігання рахунків у віддаленій базі даних, наприклад, DynamoDB або Cassandra), і натомість зможемо працювати, використовуючи стан-розділ. Це тому, що місцева держава є основним примітивом у потоковій обробці .

Якщо вам потрібні обидва вищезазначені випадки використання, то загальною схемою з Kafka є спочатку розділ за допомогою сказати :user-id, а потім повторний розділ , :viewedготовий до наступної фази обробки.

Назви тем - очевидним тут було б eventsабо user-events. Щоб бути більш конкретним, ви можете піти з events-by-user-idта / або events-by-viewed.

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

Ключові слова про поїздку:

• Загалом, чим більше розділів у кластері Kafka, тим вище пропускна здатність можна досягти. Нехай максимум, що досягається на одній перегородці для виробництва, буде p, а витрата - c . Скажімо, ваша цільова пропускна здатність - t . Тоді вам потрібно мати принаймні max ( t / p , t / c ) розділи.

• Наразі в Kafka кожен брокер відкриває обробку файлів як індексу, так і файлу даних кожного сегмента журналу. Отже, чим більше розділів, тим вище потрібно налаштувати ліміт обробки файлів відкритого типу в базовій операційній системі. Наприклад, у нашій виробничій системі ми одного разу побачили помилку too many files are open, коли ми мали близько 3600 тематичних розділів.

• Коли брокер закривається нечисто (наприклад, вбити -9), спостережувана недоступність може бути пропорційною кількості розділів.

• Кінцева затримка в Кафці визначається часом від часу, коли виробник публікує повідомлення, до моменту, коли повідомлення читає споживач. Як правило, якщо ви дбаєте про затримку, напевно, хороша ідея обмежити кількість розділів для брокера до 100 x b x r , де b - кількість посередників у кластері Kafka, а r - коефіцієнт реплікації.

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

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

Kafka розроблена LinkedIn для агрегації та доставки журналів. ця сцена дуже хороша як приклад.

Події користувача у вашому веб-Інтернеті чи додатку можуть реєструватися веб-сервером, а потім надсилатись до брокера Kafka через виробника. У виробника ви можете вказати метод розділу, наприклад: тип події (різні події зберігаються в іншому розділі) або час події (розділ на день на різний період відповідно до логіки вашої програми) або тип користувача або просто немає логіки та збалансувати всі журнали на багато розділів.

Що стосується Вашого випадку, ви можете створити одну тему під назвою "перегляд сторінки-подія" та створити N розділів за допомогою хеш-клавіш для рівномірного розподілу журналів у всіх розділах. Або ви можете вибрати логіку розділів, щоб зробити розповсюдження журналу своїм духом.