Моделирование данных с помощью Kafka? Темы и разделы

Одна из первых вещей, о которых я думаю при использовании новой службы (например, хранилище данных, отличных от РСУБД или очереди сообщений), это: "Как мне структурировать данные?".

Я читал и смотрел некоторые вводные материалы. В частности, возьмите, например, Kafka: система распределенных сообщений для обработки журналов, которая пишет:

  • "a Тема - это контейнер, с которым связаны сообщения"
  • "наименьшая единица parallelism - это раздел темы. Это означает, что все сообщения, которые... относятся к определенному разделу темы, будут потребляться потребителем в группе потребителей."

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

В качестве примера предположим, что мои данные (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? Как насчет раздела?

Как мне решить?

ОТВЕТЫ

Ответ 1

При структурировании ваших данных для Kafka это действительно зависит от того, как это должно быть потреблено.

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

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

Разделы, с другой стороны, - это способ распараллеливать потребление сообщений, а общее количество разделов в кластере брокеров должно быть, по крайней мере, таким же, как количество потребителей в группе потребителей, чтобы иметь смысл разделить особенность. Потребители в группе потребителей будут разделять бремя обработки темы между собой в соответствии с разделением, так что один потребитель будет заниматься только сообщениями в самом разделе "назначено".

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

Ответ 2

Как только вы узнаете, как разделить поток событий, имя темы будет легко, поэтому сначала дайте ответ на этот вопрос.

@Ludd верен - структура разделов, которую вы выбираете, будет во многом зависеть от того, как вы хотите обработать поток событий. В идеале вам нужен ключ раздела, который означает, что обработка вашего события partition-local.

Например:

  • Если вы заботитесь о среднем времени пользователей на сайте, вам следует разделить на :user-id. Таким образом, все события, связанные с активностью одного пользователя, будут доступны в одном разделе. Это означает, что механизм обработки потока, такой как Apache Samza, может вычислять среднее время на месте для данного пользователя, просто просматривая события в одном разделе. Это позволяет избежать выполнения какой-либо дорогостоящей обработки раздела-глобальной
  • Если вам нравятся самые популярные страницы вашего сайта, вы должны разделить их на странице :viewed. Опять же, Samza сможет отслеживать количество отображаемых просмотров страниц, просто просматривая события в одном разделе

Как правило, мы стараемся не полагаться на глобальное состояние (например, вести подсчет в удаленной базе данных, например, DynamoDB или Cassandra), и вместо этого работать в режиме локального состояния. Это связано с тем, что локальное состояние является фундаментальным примитивом в обработке потоков.

Если вам нужны оба вышеупомянутых варианта использования, то общий шаблон с Kafka заключается в первом разделе, например, :user-id, а затем переразделить на :viewed, готовом для следующий этап обработки.

В именах тем - очевидным здесь будет events или user-events. Чтобы быть более конкретным, вы можете использовать events-by-user-id и/или events-by-viewed.

Ответ 3

Я думаю, что название темы - это вывод своего рода сообщений, и производитель публикует сообщение на тему и сообщение подписки потребителей через тему подписки.

В теме может быть много разделов. раздел хорош для parallelism. раздел также является единицей репликации, поэтому в Kafka лидер и последователь также говорят на уровне раздела. На самом деле раздел представляет собой упорядоченную очередь, которая является порядком поступления сообщения. И тема состоит из одной или нескольких очередей в простом слове. Это полезно для нашей модели нашей структуры.

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

Пользовательские события в вашем Интернете или приложении могут быть зарегистрированы в вашем веб-сервере, а затем отправлены брокером Kafka через производителя. В качестве производителя вы можете указать метод разделения, например: тип события (другое событие сохраняется в другом разделе) или время события (разделить день на другой период в соответствии с логикой приложения) или тип пользователя или просто нет логики и сбалансировать все журналы во многие разделы.

В вашем случае вы можете создать один раздел под названием "page-view-event" и создать N разделов с помощью хеш-ключей для равномерного распределения журналов во все разделы. Или вы можете выбрать логику раздела, чтобы сделать распространение журнала вашим духом.