Если я хорошо понял, вы хотите, чтобы Kafka в качестве конечного бэкэнд должен был хранить данные, а не как внутренний канал, используемый агентом Flume для связи как источника, так и приемника. Я имею в виду, агент Flume в основном состоит из источника, получающего данные, и создает события Flume, которые помещаются в канал, чтобы приемник считывал эти события и что-то делал с ними (как правило, сохраняя эти данные в конечном бэкэнд). Таким образом, согласно вашему дизайну, если вы используете Kafka как внутренний канал, это будет тот, внутренний способ передачи HTTP-источника и HDFS-приемника; но он никогда не будет доступен извне агента.
Для того, чтобы удовлетворить ваши потребности, вам нужно будет и агент, такие как:
http_source -----> memory_channel -----> HDFS_sink ------> HDFS
|
|----> memory_channel -----> Kafka_sink -----> Kafka
{.................Flume agent.....................} {backend}
Соблюдайте каналы памяти на основе являются внутренними из них, они могут быть основаны на память, или файлах, даже в Кафка, но каналы Кафки будут отличаться от финального Кафки, и вы будете хранить данные и которые будут доступны вашему приложению.
Спасибо за разъяснение. Согласитесь с вашими комментариями об использовании двух приемников. Одна вещь, которую я не понимал, - «но она никогда не будет доступна извне агента». Поскольку мы предоставляем кластер Kafka, это будет доступно вне агента, не так ли? Просьба уточнить. –
Уммм, ты прав. Поскольку канал Кафки основан на вашем собственном кластере, он совершенно доступен. Тем не менее, это было бы редким использованием Flume, я имею в виду, что вы могли бы избежать второй раковины и получить прямой доступ к данным внутри этого внутреннего канала на основе Kafka (в то же время HDFS-приемник будет потреблять эти данные для обеспечения хранения). Но я предпочел бы иметь 2 внутренних канала на основе памяти и рассматривать Kafka как окончательный бэкэнд вместо внутреннего канала. Я исправлю свой ответ. – frb
На самом деле вы можете очень хорошо использовать Kafka в качестве канала и получать потребительские сообщения из темы канала. Kafka обрабатывает смещения отдельно (в зависимости от типа клиента) и удаляет данные только после достижения TTL сообщения. –