Как определить размер кластера Kafka
Я планирую решить, сколько узлов должно присутствовать в кластере Kafka. Я не уверен насчет параметров, которые нужно учитывать. Я уверен, что это должно быть>=3 (с коэффициентом репликации 2 и отказоустойчивости 1 узла).
Может кто-нибудь сказать мне, какие параметры следует учитывать при определении размера кластера и как они влияют на размер.
Я знаю следующие факторы, но не знаю, как это количественно влияет на размер кластера. Я знаю, как это качественно повлияет на размер кластера. Есть ли другой параметр, который влияет на размер кластера?
1. Replication factor (cluster size >= replication factor)
2. Node failure tolerance. (cluster size >= node-failure + 1)
Каким должен быть размер кластера для следующего сценария с учетом всех параметров
1. There are 3 topics.
2. Each topic has messages of different size. Message size range is 10 to 500kb. Average message size being 50kb.
3. Each topic has different partitions. Partitions are 10, 100, 500
4. Retention period is 7 days
5. There are 100 million messages which gets posted every day for each topic.
Может кто-нибудь указать мне соответствующую документацию или любой другой блог, который может обсуждать это. Я искал в Google, но безрезультатно
2 ответа
Как я понимаю, получение хорошей пропускной способности от Kafka зависит не только от размера кластера; Есть и другие конфигурации, которые также необходимо учитывать. Я постараюсь поделиться как можно больше.
Пропускная способность Кафки должна быть линейно масштабируемой с количеством дисков, которые у вас есть. Новая функция нескольких каталогов данных, представленная в Kafka 0.8, позволяет разделам Kafka иметь разные разделы на разных машинах. По мере того, как число разделов значительно возрастает, возрастают и шансы на то, что процесс выборов лидера будет медленнее, что также повлияет на изменение баланса потребителей. Это то, что нужно учитывать, и может стать узким местом.
Другой ключевой вещью может быть скорость очистки диска. Поскольку Kafka всегда немедленно записывает все данные в файловую систему, чем чаще данные записываются на диск, тем более "привязанным" будет поиск Kafka и тем ниже пропускная способность. Опять же, очень низкая скорость сброса может привести к различным проблемам, так как в этом случае объем данных, подлежащих очистке, будет большим. Поэтому предоставление точной цифры не очень практично, и я думаю, что по этой причине вы не смогли найти такой прямой ответ в документации Kafka.
Будут и другие факторы. Например, потребитель fetch размер, сжатия, размер пакета для асинхронных производителей, размеры буфера сокета и т. д.
Аппаратное обеспечение и операционная система также будут играть ключевую роль в этом, поскольку рекомендуется использовать Kafka в среде на основе Linux из-за механизма pageCache для записи данных на диск. Подробнее об этом здесь
Возможно, вы также захотите взглянуть на то, как поведение сброса ОС играет ключевую роль, прежде чем вы действительно настроите его под свои нужды. Я считаю, что это ключ к пониманию философии проектирования, которая делает его настолько эффективным с точки зрения пропускной способности и отказоустойчивости.
Еще один ресурс, который я считаю полезным копать
https://engineering.linkedin.com/kafka/benchmarking-apache-kafka-2-million-writes-second-three-cheap-machines
http://blog.liveramp.com/2013/04/08/kafka-0-8-producer-performance-2/
https://grey-boundary.io/load-testing-apache-kafka-on-aws/
https://cwiki.apache.org/confluence/display/KAFKA/Performance+testing
Общий МБ / с на одного брокера составит:
Данные / день = (100×10^6 сообщений / день) × 0,5 МБ = 5 ТБ / день на тему
Это дает нам ~58 МБ / с на брокера. Предполагая, что сообщения равномерно распределены между разделами, для всего кластера мы получим: 58 МБ / скс 3 Темы = 178 МБ / с для всего кластера.
Теперь для репликации у вас есть: 1 дополнительная реплика на тему. Таким образом, получается 58 МБ / с / брокер, ВХОДЯЩИЙ в исходные данные + 58 МБ / сек / брокер. ВЫХОДНЫЕ данные репликации + 58 МБ / сек., ВХОДЯЩИЙ в данные репликации.
Это дает около 136 МБ / с на вход брокера и 58 МБ / с на выход брокера.
Загрузка системы будет очень высокой, и это без учета какой-либо обработки потока.
Системная нагрузка может быть решена путем увеличения числа брокеров и разделения ваших тем на более конкретные разделы. Если ваши данные очень важны, вам может потребоваться другой (высокий) коэффициент репликации. Отказоустойчивость также является важным фактором для принятия решения о репликации.
Например, если у вас были очень очень важные данные, за исключением N активных посредников (с репликами), которые управляют вашими разделами, вам может потребоваться добавить резервных подписчиков в других областях. Если вам требуется очень низкая задержка, вы можете увеличить разделы (добавив дополнительные ключи). Чем больше у вас ключей, тем меньше будет сообщений на каждом разделе. Для малой задержки вам может потребоваться новый кластер (с репликами), который управляет только этой специальной темой, и для других тем дополнительные вычисления не выполняются. Если тема не очень важна, возможно, вы захотите снизить коэффициент репликации этой конкретной темы и быть более гибкими в случае потери некоторых данных. При создании кластера Kafka машины, поддерживающие вашу инфраструктуру, должны быть в равной степени способны. То есть, поскольку разбиение выполняется в стиле циклического перебора, вы ожидаете, что каждый брокер способен обрабатывать одинаковую нагрузку, поэтому размер ваших сообщений не имеет значения.
Нагрузка от потоковой обработки также будет иметь прямое влияние. Хорошим программным обеспечением для управления вашим монитором kafka и управления вашими потоками является Lenses, который лично мне очень нравится, так как он отлично справляется с обработкой потоков в реальном времени.
Я недавно работал с Кафкой, и это мои наблюдения.
Каждая тема разделена на разделы, и все разделы темы распределены между брокерами Kafka; В первую очередь это помогает сохранять темы, размер которых больше, чем емкость отдельного брокера Kafka, а также увеличивает параллелизм потребителей.
Чтобы повысить надежность и отказоустойчивость, делаются репликации перегородок, и они не увеличивают параллелизм потребителей.Правило большого пальца заключается в том, что один брокер может размещать только одну реплику на раздел. Следовательно, количество брокеров должно быть>= Нет реплик
Все разделы распределены по всем доступным посредникам, количество разделов может быть независимо от количества посредников, но количество разделов должно быть равно количеству потоков потребителей в группе потребителей (чтобы получить лучшую пропускную способность)
Размер кластера должен определяться с учетом пропускной способности, которую вы хотите достичь у потребителя.