Как я понял держать данные навсегда не получается, то есть retention time как то ограничено.
Держать данные, необходимые для работы потока (справочники и накопленную информацию), нужно. Удалять устаревшие данные можно аналогично обычным непотоковым решениям. Для оконных алгоритмов агрегации после закрытия окна (и поступления поздних событий) результат фиксирован и не поменяется. Его можно сбросить в выходной поток за пределы движка потоковой обработки. Далее хранить и чистить опять же как и в обычных решениях.
Возможно не актуальная тема, но всё же, если данные оставить в кафке, то как достичь GDPR / right to forget.
С помощью topic retention
Какие отзывы от Ops? Кафка довольно сложнa в управлении.
Эксплуатируем, особых сложностей не заметили. Можете уточнить вопрос?
Какой у вас опыт по resharding?
Избегаем всеми силами. Операция дорогая по вычислительным ресурсам.
Как выглядит audit и encryption?
В кафке из коробки этого нет. Делали простые решения с помощью interceptors Кафки. Но если нет контроля за машинами где развернуты producers и consumers, толку от этого мало, так как interceptors могут быть отключены или подменены. Хорошо бы иметь interceptors на стороне брокера, но пока в ближайших планах у Confluent таких доработок не видел.
Возможно NoSQL СУБД с change data capture был бы проще и архитектура выгледела не такой комплексной?
Вомможно. Но придется решать задачи запуска map-reduce агрегаций для аналитических задач. Не уверен, что архитектура получится проще.
В мире open source есть зилиард различных messaging solutions и messaging midlleware (zeromq, activemq, rabbitmq) Хотя бы два слова, почему взгляд пал на Kafka?
Классический messaging не обеспечивает возможности replay потока сообщений.
Одно время мы смотрели на RabbitMQ и AMQP аналоги, но в результате Кафка победила за счет персистентности с хорошими показателями производительности и масштабируемости. Спектр open source потоковых решений по передаче информации сводится к Apache Kafka, nats.io, Apache Pulsar. Их, увы, не так много как messaging solutions. Причем последние два решения появились недавно.
Было бы интересно посмотреть на более подробное описание экспериментов на стенде
Согласны, что нюансов много. Публиковать детальные результаты с анализом и рекомендациями по оптимизации производительности пока не можем :) В составе Apache Kafka есть штатные скрипты проверки производительности. Запустите на своем оборудовании и посмотрите результаты.
На уровне идей тема дискутируется довольно давно. Event Sourcing начинал использовать в 2008. Думаю, что явно не первым (и даже не вторым) в мире и России.
Но вот готовые движки с реализацией stateful stream processing появились не так давно.
Три системы в стадии опытной эксплуатации.
Наиболее близкая по архитектуре, описанной в статье, система сейчас обрабатывает около 3000 сообщений в секунду. Размер сообщений единицы килобайт.
Планируем запускать потоки, которые увеличат нагрузку в 10 раз. Под эту нагрузку развернули кластер из 6 брокеров Kafka.
Про ваш первый вопрос. Для быстрого пополнения счета можно на Главной странице приложения нажать кнопку «Пополнить», тогда номер счета автоматически подставится в перевод между своими счетами. При этом другой счет/карта будет предвыбран в поле «Счет списания». Для операции перевода между своими счетами у вас должно быть минимум два счета/карты. Если вы регулярно осуществляете одну и ту же операцию, можно также оформить шаблон на перевод. В таком случае все поля будут предзаполнены, вам останется только проверить/изменить сумму и подтвердить операцию.
Про остальные пункты. Большое спасибо за обратную связь, она очень ценна. Мы передали фидбек команде разработки, и они постараются исправить в ближайшие релизы. Если уточните в личку детали (на каких экранах, девайсах и версиях ОС), будет совсем замечательно!
Меня зовут Алексей Чеканов. Два месяца назад я пришел в «Сбербанк», чтобы создать группу эргономики и дизайна и сделать самый удобный банк нашей страны. Моя ответственность ― интерфейсы всех автоматизированных систем и информационных ресурсов банка. Очень большое хозяйство, очень ответственное наследство. Мне кажется, что судьба вела меня по всему профессиональному пути именно для решения этой задачи ― в течение 12 лет я руководил ведущими дизайн-студиями, а 5 лет до этого руководил учебным центром и был постановщиком задач в комании, разрабатывающей банковское программное обеспечение. Удивительный микс, позволяющий мне надеяться, что я вас не разочарую.
Ровно сегодня утром, 3 июня, на конкурсной комисси банка было принято решение об открытии конкурса по выбору генерального подрядчика, задачей которого будет проектирование пользовательского взаимодействия и разработка интерфейсов. В понедельник мы анонсируем этот конкурс, и в самое ближайшее время, насколько позволит наш технологический процесс, вы увидите качественные изменения всего, с чем вам приходится ежедневно сталкиваться. Но это не значит, что от этого радостного момента нас отделяют еще месяцы. Ежедневно мы пересматриваем работу наших существующих систем и стараемся как можно быстрее внедрять изменения.
Я был бы вам крайне признателен, если бы вы помогли мне расставить приоритеты и подсказали, за что стоит хвататься в первую очередь. Всё-таки наше собственное представление об этом может несколько отличаться от вашего. Я открыл специальную группу в facebook, где мы с вами могли бы начать обсуждения наиболее острых вопросов интерфейса и удобства наших систем. Милости прошу.
booya, вы можете подать это предложение в «Биржу идей», если оно будет поддержано другими клиентами банка и окажется востребованным, то банк рассмотрит его и внесет изменения.
Держать данные, необходимые для работы потока (справочники и накопленную информацию), нужно. Удалять устаревшие данные можно аналогично обычным непотоковым решениям. Для оконных алгоритмов агрегации после закрытия окна (и поступления поздних событий) результат фиксирован и не поменяется. Его можно сбросить в выходной поток за пределы движка потоковой обработки. Далее хранить и чистить опять же как и в обычных решениях.
С помощью topic retention
Эксплуатируем, особых сложностей не заметили. Можете уточнить вопрос?
Избегаем всеми силами. Операция дорогая по вычислительным ресурсам.
В кафке из коробки этого нет. Делали простые решения с помощью interceptors Кафки. Но если нет контроля за машинами где развернуты producers и consumers, толку от этого мало, так как interceptors могут быть отключены или подменены. Хорошо бы иметь interceptors на стороне брокера, но пока в ближайших планах у Confluent таких доработок не видел.
Вомможно. Но придется решать задачи запуска map-reduce агрегаций для аналитических задач. Не уверен, что архитектура получится проще.
Классический messaging не обеспечивает возможности replay потока сообщений.
Одно время мы смотрели на RabbitMQ и AMQP аналоги, но в результате Кафка победила за счет персистентности с хорошими показателями производительности и масштабируемости. Спектр open source потоковых решений по передаче информации сводится к Apache Kafka, nats.io, Apache Pulsar. Их, увы, не так много как messaging solutions. Причем последние два решения появились недавно.
Концепции топика, партиции и пр. подробно описаны в штатной документации Apache Kafka https://kafka.apache.org/documentation/
Дубли сообщений возникают после ребаланса consumer group при наличии сообщений, для которых не был выполнен commit.
Рекомендую почитать тут https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/
Согласны, что нюансов много. Публиковать детальные результаты с анализом и рекомендациями по оптимизации производительности пока не можем :) В составе Apache Kafka есть штатные скрипты проверки производительности. Запустите на своем оборудовании и посмотрите результаты.
На уровне идей тема дискутируется довольно давно. Event Sourcing начинал использовать в 2008. Думаю, что явно не первым (и даже не вторым) в мире и России.
Но вот готовые движки с реализацией stateful stream processing появились не так давно.
Наиболее близкая по архитектуре, описанной в статье, система сейчас обрабатывает около 3000 сообщений в секунду. Размер сообщений единицы килобайт.
Планируем запускать потоки, которые увеличат нагрузку в 10 раз. Под эту нагрузку развернули кластер из 6 брокеров Kafka.
Про остальные пункты. Большое спасибо за обратную связь, она очень ценна. Мы передали фидбек команде разработки, и они постараются исправить в ближайшие релизы. Если уточните в личку детали (на каких экранах, девайсах и версиях ОС), будет совсем замечательно!
ИТ-разработчиков
Меня зовут Алексей Чеканов. Два месяца назад я пришел в «Сбербанк», чтобы создать группу эргономики и дизайна и сделать самый удобный банк нашей страны. Моя ответственность ― интерфейсы всех автоматизированных систем и информационных ресурсов банка. Очень большое хозяйство, очень ответственное наследство. Мне кажется, что судьба вела меня по всему профессиональному пути именно для решения этой задачи ― в течение 12 лет я руководил ведущими дизайн-студиями, а 5 лет до этого руководил учебным центром и был постановщиком задач в комании, разрабатывающей банковское программное обеспечение. Удивительный микс, позволяющий мне надеяться, что я вас не разочарую.
Ровно сегодня утром, 3 июня, на конкурсной комисси банка было принято решение об открытии конкурса по выбору генерального подрядчика, задачей которого будет проектирование пользовательского взаимодействия и разработка интерфейсов. В понедельник мы анонсируем этот конкурс, и в самое ближайшее время, насколько позволит наш технологический процесс, вы увидите качественные изменения всего, с чем вам приходится ежедневно сталкиваться. Но это не значит, что от этого радостного момента нас отделяют еще месяцы. Ежедневно мы пересматриваем работу наших существующих систем и стараемся как можно быстрее внедрять изменения.
Я был бы вам крайне признателен, если бы вы помогли мне расставить приоритеты и подсказали, за что стоит хвататься в первую очередь. Всё-таки наше собственное представление об этом может несколько отличаться от вашего. Я открыл специальную группу в facebook, где мы с вами могли бы начать обсуждения наиболее острых вопросов интерфейса и удобства наших систем. Милости прошу.