Спасибо за интересный доклад. - Почему выбрали именно Samza для стриминга? Насколько сложно было масштабировать его под такой продакшн? - Какая семантика поддерживается для доставки ивентов в слой кеширования (topic -> fetcher -> cache)? Не сталкивались ли с проблемами нарушения, например, целостности флагов кэше (в вашем примере - dirty) при обработке потоков из топиков (например, если нет гарантированного exactly once)? Как в целом обеспечивается целостность write-through кэша в сценариях: событие прочтено, офсет записали в Cassandra, в этот момент кэш упал. Событие прочтено, офсет зафиксирован, записали в кэш, но в этот момент Cassandra упала. И т. д. Нет ли потерянных или дуплицированных ивентов? - В вашем подходе кэш - какую реализацию использует? Redis? В чем именно польза такого кэша и почему не писать стримы топиков сразу в Cassandra - это попытка избежать частого чтения/записи и губительных tombstone в C*, работая с быстрым кэшем? Cassandra гарантировано не обеспечивала нужных latency при работе без кэширующего слоя? - Как в таком подходе работает сквозная schema evolution: от событий стриминга/батч до фичей? Как вы сохраняете прямую/обратную совместимость при эволюции схем событий? Не пробовали ли вы другие форматы сериализации, например Avro? - Вы говорите о highload в "горячем feature store" и высоких требованиях к его отказоустойчивости, при этом используя однонодную конфигурацию Cassandra без кластера и multi-DC, этот момент не совсем понятен. Правильно ли я понимаю, что однонодная Cassandra - это только часть одного экземпляра feature store, который по факту и является атомарной единицей отказоустойчивости и масштабирования? То есть одна партиция топика = один узел feature store = один шард чтения для клиентов? - Как вы инвалидируете кэш при наступлении TTL в Cassandra?
Привет! 1) Выбрали Самзу давно, так как это быстрый и хорошо зарекомендовавший себя фреймворк от линкедин 2) Целостность поддерживаем на всех уровнях. Мы еще коммитим оффсеты в кассандру, что уберечься от незафлашенных из кэша записей. Если падает и корраптится Кассандра (очень редкое явление), то восстанавливаем с живой реплики. 3) Кэш свой. Написан для демпфирования нагрузки на Кассандру 4) Обычно разные версии разводим по разным топикам. Авро не заводили, так как это лишний оверхед. 5) Однонодная кассандра в нескольких репликах. На одну ноду заводятся несколько партиций топика. Правила распределения партиций по ключу распостраняются и на клиентов. 6) В кэше реализованы несколько стратегий чистки, но они не синхронизированы с Кассандрой. Ситуация когда в Кассандре данные почистились по TTL, а в кэше остались супер редкая + при чтении из Кассандры мы проверяем что данные не протухли.
Спасибо за интересный доклад.
- Почему выбрали именно Samza для стриминга? Насколько сложно было масштабировать его под такой продакшн?
- Какая семантика поддерживается для доставки ивентов в слой кеширования (topic -> fetcher -> cache)? Не сталкивались ли с проблемами нарушения, например, целостности флагов кэше (в вашем примере - dirty) при обработке потоков из топиков (например, если нет гарантированного exactly once)? Как в целом обеспечивается целостность write-through кэша в сценариях: событие прочтено, офсет записали в Cassandra, в этот момент кэш упал. Событие прочтено, офсет зафиксирован, записали в кэш, но в этот момент Cassandra упала. И т. д. Нет ли потерянных или дуплицированных ивентов?
- В вашем подходе кэш - какую реализацию использует? Redis? В чем именно польза такого кэша и почему не писать стримы топиков сразу в Cassandra - это попытка избежать частого чтения/записи и губительных tombstone в C*, работая с быстрым кэшем? Cassandra гарантировано не обеспечивала нужных latency при работе без кэширующего слоя?
- Как в таком подходе работает сквозная schema evolution: от событий стриминга/батч до фичей? Как вы сохраняете прямую/обратную совместимость при эволюции схем событий? Не пробовали ли вы другие форматы сериализации, например Avro?
- Вы говорите о highload в "горячем feature store" и высоких требованиях к его отказоустойчивости, при этом используя однонодную конфигурацию Cassandra без кластера и multi-DC, этот момент не совсем понятен. Правильно ли я понимаю, что однонодная Cassandra - это только часть одного экземпляра feature store, который по факту и является атомарной единицей отказоустойчивости и масштабирования? То есть одна партиция топика = один узел feature store = один шард чтения для клиентов?
- Как вы инвалидируете кэш при наступлении TTL в Cassandra?
Привет!
1) Выбрали Самзу давно, так как это быстрый и хорошо зарекомендовавший себя фреймворк от линкедин
2) Целостность поддерживаем на всех уровнях. Мы еще коммитим оффсеты в кассандру, что уберечься от незафлашенных из кэша записей. Если падает и корраптится Кассандра (очень редкое явление), то восстанавливаем с живой реплики.
3) Кэш свой. Написан для демпфирования нагрузки на Кассандру
4) Обычно разные версии разводим по разным топикам. Авро не заводили, так как это лишний оверхед.
5) Однонодная кассандра в нескольких репликах. На одну ноду заводятся несколько партиций топика. Правила распределения партиций по ключу распостраняются и на клиентов.
6) В кэше реализованы несколько стратегий чистки, но они не синхронизированы с Кассандрой. Ситуация когда в Кассандре данные почистились по TTL, а в кэше остались супер редкая + при чтении из Кассандры мы проверяем что данные не протухли.