А разве не весь Спарк так работает :troll-peek:

Я не шарю в спарках, поясните мемес, я хочу быть как все.

Ну, кстати, 90% работы, если не больше, идёт сразу в мусорку, всякие тмп, врк, рнд

На прод уже только алмазы попадают)

Спарк коры занимает (и «занимает»), а толку мало

аааа ))) кек

Ага

Настолько хорошо работает что главный создатель сказал: «фу, все перепишу»

Эм, меня в прод не сразу пустили 😏

Привет! Надеюсь, тут есть знатоки кафки, есть вопросы на понимание


1. Правильно ли я понимаю, что при включенном enable.idempotence=true надо генерить уникальный client.id и не прибивать его руками (т.е. нельзя шарить client.id между перезапусками одного и того же продьюсера), потому что  The broker will reject a producer request if its sequence number is not exactly one greater than the last committed message from that PID(producer id)/TopicPartition pair

2. Рассмотрим продьюсера с transactional.id. Он открыл транзакцию, шлет сообщения. В какой момент сообщения попадает в топик + пачкой или по-одному? Откуда вопрос. Я вычитал, что консьюмер, елси не проставить isolation level = read commited прочитает даже сфейленные (aborted) транзакции. Из этого следует, что брокер складывает сообщения  сразу в топик => при одновременной записи нескольких транзакций оффсеты сообщений идут непоследовательно => имеем проблемы с тем, чтобы эту транзакцию обработать в консьюмере. Где я ошибся?

3. Правильно ли я понимаю, что exacly once продьюсер -- фикция в том смысле, что возможен *только* если сам продьюсер будет персистить свой стейт куда-то еще при успешной транзакции, чтобы при перезапуске суметь понять, что "мы уже это записали".

4. Возможен ли exacly once без транзакций? Это будет блокирующий send с персистом каждого успешного send-а в какой-то свой  безопасный стор?

О, спасибо

gcyhsse fdwzf has been banned! Reason: CAS ban.

почему?

бонджорно!
тут есть успешные господа, которые используют Databricks "SQL Endpoint"?

Потому что для этого как минимум нужно привязать датафрейм к переменной. Если после присваивания выполнять какие-то операции над датафреймом, они в эту переменную не попадут, и в итоге вот такие ошибки, как выше скидывали
Зачем вносить в код что-то изначально лишнее?

col("column"), исполняясь внутри методов датафрейма, сам определит, к какому датафрейму он относится, этот код можно вынести в общую функцию, например, и использовать с разными датафреймами

Зачем не использовать спарк SQL .........

В идеале, простыни спарковского кода не должны содержать ни единого присвоения, как sql-запрос, только кодом