DT
Тогда никаких
а как с отказоустойчивостью, exactly-once процессингом и контролем последовательного процессинга и записи?
Size: a a a
2018 July 08
DT
не будет ли приколов в виде deadlock’ов при распределенном процессинге в spark, все ноды которого сливают в одну mysql табличку?
AS
а как с отказоустойчивостью, exactly-once процессингом и контролем последовательного процессинга и записи?
Exactly-once процессинг ИМХО это миф
AS
не будет ли приколов в виде deadlock’ов при распределенном процессинге в spark, все ноды которого сливают в одну mysql табличку?
Вообще по опыту лучше так не делать
DT
Вообще по опыту лучше так не делать
а как лучше делать?
AS
Хотя на такой низкой частоте проблем быть особо не должно
AS
а как лучше делать?
Писать в in-memory хранилище типо Redis
DT
Писать в in-memory хранилище типо Redis
а его с mysql синхронизировать?
AS
Да, в нужную под запросы структуру
DT
Да, в нужную под запросы структуру
а чем из redis в mysql лить?
AS
Это такая speed ветка lambda архитектуры получается
DT
хочется снизить время появления данных в mysql. Интуиция подсказывает, что kafka -> spark -> redis -> ? -> Mysql будет медленнее kafka -> spark -> mysql
DT
(и больше зоопарк => точек отказа)
AS
Можно лить сразу, но вроде помнится ловили неконсистентность
DT
Можно лить сразу, но вроде помнится ловили неконсистентность
из-за параллельного писания спарком?
AS
Да, надо внимательно за партиционированием в ссмом spark следить
AS
Вообще, in general подход вполне рабочий
AS
Вместо spark streaming под эту задачу посмотрите еще flink
DT
ну, в моем случае неконсистентость на короткий промежуток времени - не беда. Данные доедут - станет все хорошо
AS
ну, в моем случае неконсистентость на короткий промежуток времени - не беда. Данные доедут - станет все хорошо
Ок, посмотрите еще в сторону Flink