Spark будет работать с группами потребителей, как и любой другой потребитель Kafka, но партиями.Поэтому требуется как можно больше данных (на основе различных пользовательских настроек Kafka) из последних использованных смещений.Теоретически, если у вас такое же количество разделов с тем же интервалом фиксации, что и 10 ГБ, то на 100 ГБ потребуется только 10 раз больше.Вы не указали, сколько времени это занимает в данный момент, но для некоторых людей 1 минута против 10 минут может показаться «навсегда» , конечно.
Я бы порекомендовал вам построить график потребительского лага по времени, используя инструмент командной строки kafka-consumer-groups в сочетании с чем-то вроде Burrow или Remora ... Если вы заметили тенденцию к увеличению лага,тогда Spark не потребляет записи достаточно быстро.Чтобы преодолеть это, первым вариантом было бы убедиться, что число исполнителей Spark равномерно использует все разделы Kafka.
Вы также должны быть уверены, что не выполняете преобразования основных данных, кроме простых фильтров и сопоставлений между потреблением и записью записей, поскольку это также приводит к задержке.
Для подходов, не относящихся к Spark, я хотел бы отметить, что разъем Confluent S3 также является периодическим, поскольку он только периодически сбрасывается на S3, но сам расход все еще ближе кв режиме реального времени, чем Spark.Однако я могу убедиться, что он может записывать очень большие файлы S3 (размером в несколько ГБ), если куча достаточно велика и конфигурации сброса имеют большие значения.
Secor by Pinterest - еще один вариант, не требующий ручного кодирования