Моя компания рассматривает возможность использования flume для обработки больших объемов журналов. Мы считаем, что обработка журналов должна быть распределена как по объему (масштабируемость), так и по причинам отказа (надежность), и Flume кажется очевидным выбором.
Однако мы думаем, что упустили что-то очевидное, потому что не видим, как Flume обеспечивает автоматическую масштабируемость и отработку отказа.
Я хочу определить поток, который говорит для каждой строки журнала, сделать что-то A, затем передать это и выполнить B, затем передать это и выполнить C, и так далее, что, похоже, хорошо соответствует Flume. Тем не менее, я хочу иметь возможность определить этот поток в чисто логических терминах, а затем в основном сказать: «Привет, Flume, вот серверы, вот определение потока, иди на работу!». Серверы умрут (и ops перезапустит их), мы добавим серверы в кластер и удалим другие, а flume просто направит работу на любые узлы, имеющие доступную емкость.
Это описание того, как Hadoop map-lower реализует масштабируемость и отработку отказа, и я предположил, что Flume будет таким же. Однако документация предполагает, что мне нужно вручную настраивать, на каких физических серверах работает каждый логический узел, и настраивать конкретные сценарии отработки отказа для каждого узла.
Я прав, и Flume не служит нашей цели, или я что-то упустил?
Спасибо за вашу помощь.