2016-01-11 2 views
2

У нас есть система (например, система A), которая получает данные временных рядов по HTTP, и эти данные сохраняются в OpenTSDB через интерфейс REST OpenTSDB. Теперь я хотел бы представить Apache Kafka в систему. Идея для меня заключалась бы в том, чтобы запустить сервер Kafka, где System A, как только получает сообщения о временных рядах, публикует это сообщение на сервере Apache Kafka.Apache Kafka для сохранения данных временных рядов

У меня может быть потребитель, который читает из темы и записывает эти данные в OpenTSDB. У меня есть несколько вопросов, с этим подходом:

В отношении к разработке архитектуры производителя и потребителя:

  1. Могу ли я иметь отдельный клиент, где я буду писать потребителей, которые только потребляющие от темы Кафки и написать сообщения в OpenTSDB

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

Что касается Кафки тем, данные временных рядов некоторых показателей, которые имеют ключ и значение и пример которого, как показано ниже:

"metric.metricType.tagName" 

у меня будет сотня или даже, возможно, тысячи этих различных тэгов. Как я структурирую эту информацию и представляю ее как тему в Apache Kafka. Я не уверен, есть ли ограничение на количество тем, которые я мог бы создать.

Должен ли я иметь одну тему для имени тега? Какова сделка с разделением темы?

Что касается Apache Кафки секционирования, у меня есть следующие вопросы:

  1. Если у меня есть тема «Тема A» и установите разделы 4 по этой теме, и если мой продюсер пишет это раздел, в котором раздел этой темы будет доступен для этого сообщения? Одно и то же сообщение доступно для каждого раздела в одной и той же теме?

  2. Если я пишу потребителю эту секционированную тему, как это будет вести себя, я имею в виду, получит ли этот потребитель сообщение из раздела?

  3. Если у меня есть несколько потребителей для этой секционированной темы, будут ли все эти потребители получать одни и те же сообщения? Я имею в виду, если в теме есть 4 раздела (TP1, TP2, TP3, TP4), и у меня есть 4 группы потребителей (CG1, CG2, CG3, CG4), где в каждой группе потребителей у меня есть один потребитель, который читает сообщения из соответствующий раздел раздела (C1 читается из TP1, C2 читается с TP2 и т. д.). Будут ли у меня появляться повторяющиеся сообщения, если все мои группы потребителей записывают сообщения, которые он получает в одну и ту же базу данных?

ответ

2

Могу ли я иметь отдельный клиент, где я буду писать, что потребители просто потребляющие от темы Кафки и писать сообщения в OpenTSDB?

Да, вот как я это сделал. Отдельное приложение java (вы можете назвать его «java-серверным приложением»).

Должен ли я иметь одну тему для имени тега?

Если вы хотите обрабатывать сообщения одним тегом по-разному, то другие теги, например. удержание, размер сообщения (и other topic-level settings), тогда имеет смысл иметь отдельную тему, но если у вас будут тысячи тегов, я бы этого не сделал. Это может быть просто поле внутри сообщения. У вас может быть одна тема, которая будет использоваться для ваших показателей, а затем, когда вы захотите добавить другие типы сообщений (и вы обязательно захотите сделать это, как только увидите преимущество :), вы можете создать другую тему для что. Вы можете грубо смотреть на темы как сущности в базе данных, но это довольно слабое сравнение, поскольку оно зависит от многих факторов, таких как размер, скорость входящего и т. Д. Нет рецепта на один размер, поэтому вам придется задать отдельный конкретный вопрос со всеми параметрами, которые у вас есть.

В чем заключена секция раздела?

Перегородки являются механизмом параллелизма потребления Kafka (они также облегчают избыточность, поскольку каждый раздел реплицируется через брокеров, в зависимости от выбранного вами коэффициента репликации). Поскольку раздел не может потребляться более чем одним потоком потребителя, вы хотите сначала создать больше разделов (и начать потреблять с меньшим количеством потоков), чтобы впоследствии можно увеличить количество потоков до количества разделов. (Это ограничение, возможно, было отменено в последней версии Kafka 0.9. Это правило применяется к потребителю низкого уровня v0.8).

Если у меня есть тема «Тема A» и поставил перегородки 4 для этой темы, и если мой продюсер записывает в этот раздел, в котором раздел этой темы будет это сообщение будет доступно?

Если вы публикуете сообщения, описанные вами, вы не будете знать, в каком разделе сообщение закончится. Это определяется путем хэширования на стороне производителя, а механизм хэширования по умолчанию - случайный (что-то вроде «round robin»). Вы можете управлять секционированием, определяя атрибуты (атрибуты), которые будут использоваться для хеширования. Например. если вы включите в хэш tag, все сообщения с одним и тем же тегом будут всегда переходить к одному разделу. Это важно, когда вы хотите убедиться, что сообщения с одним и тем же тегом будут потребляться в том же порядке, который они были помещены в Kafka, то есть.

Доступно ли одно и то же сообщение для каждого раздела в той же теме?

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

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

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

Если у меня есть несколько потребителей для этой секционированной темы, будут ли все пользователи те же сообщения?

Это зависит от группы потребителей. Все потребительские потоки, которые находятся в одной группе, получают в общей сложности 100% сообщений (например, каждый из 4 потребительских потоков получит 25% сообщений из этой темы). Если, с другой стороны, у вас есть 2 потребителя с разными группами, каждый из них будет потреблять 100% сообщений из этой темы. Я думаю, вы можете вывести ответы на свои последние два вопроса из этого, не так ли?

+0

1. Наверное, вы имели в виду автономное клиентское приложение? – sparkr

+0

Клиент в потребительском клиенте «Kafka», но в целом он выглядит как маленький сервер, поскольку это долго работающая задача, которая что-то делает. Mine также имеет интерфейс REST, который можно использовать для получения некоторых показателей потребления, вытащить одно сообщение при определенном смещении и управлять некоторыми параметрами конфигурации (которые могут быть динамически изменены). –

+0

Я не совсем понял ваше утверждение «Нет, разделы всегда содержат примерно равное подмножество их темы ...». Не могли бы вы рассказать об этом, пожалуйста? – sparkr