Проще писать в базу

Кассандра идеально подходит , благо есть коннектор

ничего на самом деле, но большая устойчивость будет точно; и проще логика

Ломается хз почему, у меня тупо не делались новые пулы

у меня ниразу не ломалось на самом деле

У нас Кафка очищает лог

А стратегия reset не работает потому что они ее переопределять в none

Ну не можем мы все данные хранить

Я знаю , но все равно хранить в Кассандре удобней , давно хочу фичу запилить с пересчетами, когда оффсеты отматываешь

Ещё момент есть - я руками версию клиента Кафки переопределял до 0.10.1.2

а зачем?

какойто баг / фича апи?

спасибо

на постгре делали

О моя любимая тема, поэтому немного ворвусь.

1) Поддерживает, ввиду обратной совместимости на уровне Kafka.
Также стоит отметить, что всех стимулируют переходить на Spark Structured Streaming и поддержка Spark Streaming будет все хуже. По аналогии с тем, как в том же Spark Streaming стимулировали всех писать на Scala/Java, поэтому python версия намного меньше умеет.

2) Нет. Чтобы обеспечить exactly once нужен атомарный комит отступов и данных, а это каждый костылит по своему.

3) Проблема не в тормознутости, а в невозможности обеспечить exactly once. При хранении отступов в Kafka максимально можно получить at least once. А при auto-commit вообще никакая семантика не будет соблюдаться.

1) Я не особо писал под structured streaming, поэтому не скажу. Просто знаю что больше развивать классический spark streaming особо не будут, соответственно update коннекторов тоже особо не стоит дожидаться.

3) Там два варианта:
a) auto-commit (никакой семантики) - kafka переодически посылает heartbeat к consumer'у и если он жив сохраняет уже прочитанные им данные. Собственно легко придумать проблемные ситуации:
раз) Kafka обновит отступ, а consumer не успеет обработать сообщение - получаем потери данных
два) Сonsumer сообщение сохранил и умер, поэтому Kafka новый отступ не сохранит - при следующем фетче заберем те же самые строки и будут дубли
б) manual commit (я не помню как точно он называется, но семантика at least once) - после успешной обработки батча данных consumer посылает в Kafka ack, что все хорошо (после этого Kafka сохранит отступ соответсвующий обработанному батчу). Ну и проблемная ситуация: consumer данные или часть данных сохранил и упал => при следующем фетче снова будем вычитывать те же данные, итого дубли.

Spark structured streaming, да довольно свежий и активно развивающийся проект, поэтому багов будет куча. Но он архитектурно намного более грамотно построен и его активно развивают.

Имхо, если писать что-то новое, то Spark Structured Streaming точно выигрывает.

Из минусов стоит отметить, что он не поддерживает exactly once для пособытийной обработки (но с микробатчевой всё в целом прилично).

Это да, но к справедливости стоит отметить, что не всегда идемпотентность можно обеспечить и иногда это пипец как дорого вычислительно (к примеру, целевая структура данных большая и сложная или дублей больно много).