Kafka как шина данных: что это значит для компании
Apache Kafka перестаёт быть только инструментом больших технологических компаний. Вот как объяснить её роль без технического жаргона.
Apache Kafka появилась в LinkedIn для решения конкретной задачи - передавать огромные объёмы событий между внутренними системами в реальном времени. Потом LinkedIn открыл код, и последние несколько лет Kafka используют крупные технологические компании для похожих задач.
Сейчас я начинаю видеть её в проектах, где заказчик - не технологическая компания, а производственная, логистическая или финансовая. Это хороший момент, чтобы объяснить, что Kafka делает и для каких задач она имеет смысл - без предположения, что читатель знает, что такое "брокер сообщений".
Что такое шина данных в принципе
Представьте, что у компании есть десяток систем: ERP, CRM, производственная MES, склад, доставка, аналитическое хранилище. Каждая из них производит события - заказ создан, партия отгружена, оборудование дало сигнал, клиент оставил заявку.
Без централизованной шины каждая система говорит с каждой напрямую. Это так называемая "звезда" или, в худшем случае, "спагетти" - N систем порождают N×(N-1) интеграционных связей. Каждая связь хрупка, каждое изменение в одной системе ломает другие.
Шина данных - это посредник. Системы не разговаривают друг с другом напрямую. Они отправляют события в шину, и подписчики получают то, что им нужно. Это значительно упрощает архитектуру и снижает хрупкость интеграций.
Чем Kafka отличается от классических интеграционных шин
Классические ESB (enterprise service bus) тоже были шинами. Kafka отличается несколькими свойствами, которые важны на практике.
Первое - Kafka сохраняет историю событий. Обычная очередь сообщений: сообщение получено - удалено. Kafka хранит поток событий за настраиваемый период. Это значит, что новая система, подключённая месяц спустя, может "прочитать прошлое" и догнать всё, что произошло.
Второе - Kafka масштабируется горизонтально. При росте объёма данных можно добавить серверы, а не менять архитектуру.
Третье - потребители независимы. Аналитическая система, система мониторинга и операционная система могут читать один и тот же поток событий независимо, в своём темпе.
Где это имеет смысл
Kafka оправдана там, где есть несколько систем с высокой частотой событий, и где важна согласованность данных между ними.
Производство: события с оборудования, сигналы MES, данные качества - всё это потоки, которые должны быть доступны нескольким потребителям: операционному контролю, аналитике, предиктивному обслуживанию.
Логистика: события отгрузки, подтверждения доставки, GPS-метки - поток событий, который нужен нескольким системам одновременно.
Финансы: транзакции, которые должны попасть в аналитику, систему fraud detection и операционный учёт без промежуточных копирований и потерь.
Что важно понять до принятия решения
Kafka - инструмент с операционными требованиями. Кластер Kafka нужно поддерживать, мониторить, резервировать. Для небольшой компании с простыми интеграциями - это избыточная нагрузка.
Несколько вопросов, которые помогут оценить нужно ли это:
- Сколько систем в компании сейчас интегрированы между собой и насколько сложны эти интеграции?
- Есть ли задачи, требующие обработки событий в реальном или близком к реальному времени?
- Есть ли несколько систем, которым нужны одни и те же данные - и сейчас это решается копированием или синхронизацией?
- Есть ли у нас инженерные ресурсы для поддержки инфраструктурного компонента такого уровня?
Если ответы положительные - Kafka может упростить архитектуру. Если нет - более простые решения справятся лучше.