Наша специализация выгодно отличаются от других тем, что домашние задания принимаются на настоящем кластере. Это, конечно, приносит определенную боль, но очень полезный навык.

Хм, supervisor или rc.d или что-то на мотив, чем не подходит?

ну вот вы ноду уронили, а ярн задача работает

Коллеги, кто-то из вас использовал MinHashLSH на спарк 2.3.2?

угу

как-нибудь решили по-другому?)

Я нет, а в чем вопрос, интересно?

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

Если seed один и тот же, то забавно. Вообще в реализации minhash довольно просто накосячить

Ладно, буду копать дальше

А вы на пайспарке?

Вдруг там pythonhashseed где-то внутри используется)

Не, скала

Мы сделали такую стратегию.

У нас есть watcher, который следит за streaming query (смотрит его стейт периодически). Внутри все это оформлено в такую стейт машину:
-> INITIAL
INITIAL -> (RUNNING|FATAL_ERROR)
RUNNING -> (RUNNING|RECOVERABLE_ERROR|FATAL_ERROR)
RECOVERABLE_ERROR -> (RUNNING|RECOVERABLE_ERROR|FATAL_ERROR)
FATAL_ERROR -> EXIT

Если случилась RECOVERABLE_ERROR то попытаемся поднять streaming query.
Если FATAL_ERROR, то завершаем все queries в текущем апе и выходим.

RECOVERABLE_ERROR - это практически любая ошибка, которая вызвала штатную остановку streaming query извне (самим спарком).
FATAL_ERROR - это либо n раз провалились при попытке подняться из RECOVERABLE_ERROR, либо был какой-то unhandled exception.

Почему так?
1. Стейт у streaming query мало информативен на самом деле. Если джоба упала по случайности (партиция кафки например поменяла лидера), то эта одна история, а если в пайплайне ошибка или беда с wal, то совсем другая. Разбираться человеку легко, автоматически - сложно.

2. У нас как правило в каждом апе минимум 3 queries, потому что 3 разных кластера кафки (в разных dc). Поэтому ситуация когда какой-то query припал, возможно (например учения в dc).

3. Таймаут между рестартами полезен, за это время можно что-нибудт починить :-)

4. Чтобы не мучаться с перезапуском всего, проще в случае FATAL_ERROR аккуратно выйти, а потом cron/ваш любый планировщик увидит что джобы нет и запустит ее.

p.s. Watcher и стейт машина естественно находятся внутри апа.

пасибо

Ребят, есть вопрос.
Python, Spark, Postgres.

Скачал драйвер, закинул в конфиг. Поднял  туннель, подключился к бд, пытаюсь переложить Spark DF в Postgres используя драйвер.

Всё отрабатывает, не падает, код после df.write.jdbc  отрабатывает, что в df действительно есть данные убедился. Однако в бд - пусто.

Куда смотреть? Как то можно в консоль вывести что происходит под капотом у write?

Я прям точно не помню, но это кажется связано, с тем, что не коммитится транзакция

Скинь кусок кода, где пишешь данные

.save() должен быть?