Поток данных Kafka Storm HDFS/S3

Что касается Камю, да, должен работать планировщик, который запускает задание. То, что они используют в LinkedIn, — это Азкабан, вы тоже можете взглянуть на это.

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

Что касается Камю с S3, в настоящее время я не думаю, что это на месте.

Что касается поддержки Kafka для хранения S3, есть несколько потребителей Kafka S3, которых вы можете легко подключить, чтобы сохранить свои данные в S3. kafka-s3-storage — один из них.

Есть много возможных способов накормить бурю переведенными данными. Главный вопрос, который мне не ясен, это то, какую зависимость вы хотите устранить и какие задачи вы хотите, чтобы storm не выполнял. Если считается нормальным, что storm получит xml или json, вы можете легко прочитать исходную очередь, используя двух потребителей. Поскольку каждый потребитель контролирует сообщения, которые он читает, оба могут читать одни и те же сообщения. Один потребитель может вставить данные в ваше хранилище, а другой будет переводить информацию и отправлять ее в storm. Настоящей сложности с осуществимостью этого нет, но я считаю, что это не идеальное решение по следующим причинам:

1. Ремонтопригодность - потребитель нуждается в присмотре. Поэтому вам нужно будет контролировать своих работающих потребителей. В зависимости от вашего развертывания и того, как вы обрабатываете типы данных, это может оказаться нетривиальной задачей. Особенно, когда у вас уже установлен storm и, следовательно, он контролируется.

2. Storm connectivy — нужно еще придумать, как подключить эти данные к storm. У Srorm есть носик kafka, который я использовал, и он работает очень хорошо. Но, используя предложенную архитектуру, это означает дополнительную тему кафки для размещения переведенных сообщений. Это не очень эффективно, так как носик также может считывать информацию непосредственно из оригинальной темы и переводить ее с помощью простого болта.

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

Kafka фактически сохраняет события в течение настраиваемого периода времени — события не удаляются сразу после их использования, как другие системы сообщений или очередей. Это позволяет вам иметь несколько потребителей, которые могут читать из Kafka либо в начале (в соответствии с настраиваемым временем хранения), либо со смещением.

Для описанного варианта использования вы должны использовать Camus для пакетной загрузки событий в hadoop, а Storm — для считывания событий из того же вывода Kafka. Просто убедитесь, что оба процесса читают новые события до истечения настраиваемого времени хранения.

Что касается Камю, ggupta1612 лучше всего ответил на этот вопрос.

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

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