Шины данных
Современные компании работают с десятками разрозненных систем: ERP, CRM, BI, e-commerce, производственные MES, маркетинговые платформы, банковские шлюзы, приложения и API. Данные во всех этих системах постоянно изменяются — и именно их согласованность, скорость и качество напрямую определяют эффективность бизнеса.
Шина данных (Data Bus) — это архитектурный подход, позволяющий объединить все ключевые ИТ-системы компании через централизованный поток событий. В её основе лежит принцип event-driven архитектуры, обеспечивающей быструю, надежную и масштабируемую передачу данных между системами в режиме реального времени.
Мы реализуем такую архитектуру с помощью Apache Kafka — одного из самых зрелых и мощных инструментов построения потоковой интеграции и событийных систем.
Что даёт внедрение шины данных
- Единое ядро обмена данными: избавьтесь от «point-to-point» интеграций, которые сложно сопровождать и масштабировать.
- Онлайн-доступ к бизнес-событиям: любые изменения (новый заказ, оплата, отказ, отгрузка, регистрация пользователя) мгновенно становятся доступны всем нуждающимся системам.
- Масштабируемость и отказоустойчивость: Kafka отлично работает как в стартапах, так и в корпорациях с сотнями сервисов и миллиардами событий в день.
- Гибкость для цифровых команд: новые продукты, витрины и микросервисы можно подключать без вмешательства в существующие системы.
- Основу для real-time аналитики и рекомендательных систем: шина становится источником «живых» данных для DWH, BI, ML и AI-платформ.
Почему Apache Kafka
- Мы выбрали Apache Kafka как технологическую основу шины данных, потому что:
- Это индустриальный стандарт потоковой передачи данных.
- Kafka обеспечивает гарантированную доставку, контроль очередей и сохранение порядка событий.
- Поддерживает масштабирование «на лету» без остановки систем.
- Имеет развитую экосистему: Kafka Connect, ksqlDB, Schema Registry, Kafka Streams и др.
- Имеет активное сообщество и используется в Netflix, Uber, LinkedIn, Сбербанк, Tinkoff и других лидерах отраслей.
Что мы предлагаем
- Наша команда помогает компаниям выстроить архитектуру на базе Apache Kafka:
- Анализ текущего ландшафта и подготовка архитектуры событийного взаимодействия.
- Проектирование топологий Kafka и стратегий партиционирования, хранения, мониторинга.
- Настройка Kafka-кластера (on-premise или в облаке), безопасность, балансировка, high availability.
- Разработка коннекторов, трансформаций и stream-процессинга (Kafka Streams, Flink, Spark).
- Интеграция с внешними системами (1С, Oracle, PostgreSQL, ClickHouse, API и т. д.).
- Обучение команд и сопровождение эксплуатации.
Изначально созданная для обработки логов, Kafka теперь является основой для множества приложений. Её устойчивое хранилище сообщений и гибкий доступ к данным позволяют потребителям извлекать записи в удобное для них время.
Вот несколько популярных сценариев использования Kafka:
- Обработка и анализ логов: Эффективно справляется с огромными объёмами данных логов для их анализа и генерации инсайтов.
- Стриминг данных для рекомендаций: Обеспечивает потоковую обработку данных в реальном времени для предоставления персонализированных рекомендаций.
- Мониторинг и оповещения систем: Ускоряет мониторинг метрик и отправку уведомлений для своевременного реагирования на события в системе.
- Change Data Capture (CDC): Фиксирует и обрабатывает изменения в базах данных, чтобы поддерживать синхронизацию данных между системами.
- Миграция систем: Поддерживает бесшовную миграцию данных, обеспечивая их консистентность и доступность.
Учебные материалы Apache Kafka
- Apache Kafka: Введение
- Apache Kafka: основные операции
- Apache Kafka: архитектура кластера
- Apache Kafka: алгоритм установки
- Интеграция Apache Kafka и Spark
- Введение в Apache Kafka
- Что такое Apache Kafka
- Apache Kafka: что это и как работает
- Apache Kafka: обзор
- Kafka vs RabbitMQ: что нужно знать аналитику про брокеры сообщений
- Построение архитектур для обработки данных в режиме реального времени при помощи Apache Kafka, Flink и Druid
- Архитектура конвейера потоковых данных
- CDC репликация средствами Debezium и Kafka Connect
- Kafka Connect на примере Debezium PostgresConnector
- Руководство по установке Apache Kafka с помощью Docker
- Как с помощью Docker запустить Kafka?
- Начало работы с Apache Kafka в Docker: пошаговая инструкция
- kafka-python
- Python-клиент для Apache Kafka
- Выбор клиента Python Kafka: сравнительный анализ
- Apache Kafka на Python
- Потоковая обработка данных с помощью Python и Apache Kafka: руководство для новичков
- Коннекторы Kafka
- Kafka Connect: коннекторы, конфигурации, задачи, рабочие узлы
- Введение в Apache Kafka со Spring Boot
- Подробное руководство по интеграции Kafka в приложение Spring Boot
- Быстрая и легкая интеграция Kafka со Spring Boot
- Почему Kafka – это новое Data Lake?
- Наиболее распространенные ошибки при работе с Kafka и способы их устранения
- Настройка SSL и SASL аутентификации Kafka
- Повышаем безопасность кластера Apache Kafka с помощью SSL, SASL и ACL
- Безопасность Kafka: Аутентификация с помощью SASL_SCRAM
- Автоматизированная непрерывная репликация Greenplum в Apache Kafka
- Потоковая передача данных Postgres с помощью Apache Kafka и Debezium | ETL в режиме реального времени
- Планирование миллионов сообщений с помощью Kafka и Debezium
- Потоковая передача данных из PostgreSQL в Kafka с помощью Debezium
- Децентрализованная сеть данных с Apache Kafka в сфере финансовых услуг
- Мониторинг метрик Kafka с помощью Prometheus и Grafana
- Data Lake с помощью Debezium, Kafka Connect и Apache Iceberg sink
- Комплексная система обработки данных на основе реальных данных с использованием Kafka, Spark, Airflow, Postgres и Docker
Работа Кафки просто и наглядно
Шикарная визуализация работы Кафки: https://softwaremill.com/kafka-visualisation
И менее шикарная, но тоже пригодится: https://evoura.com/kafka-traffic-visualizer
Мастхев задание, если есть сомнения в работе партиций, ключей, консьюмер групп, репликации между брокерами.
Разбираемся с основами, начинаем здесь:
1. Установите: 1 брокер, 1 консьюмер группа, 1 консьюмер, 2 партиции. Посмотрите, как сообщения распределяются между партициями.
2. Добавьте второго консьюмера в существующую группу. Посмотрите, как распределяются между ними сообщения.
3. Добавьте третьего консьюмера в существующую группу. Посмотрите, как распределяются между ними сообщения.
4. Перенесите третьего консьюмера в отдельную консьюмер группу. Сравните потребление сообщений в двух консьюмер группах.
Теперь понаблюдаем за работой с ключами, переключитесь сюда:
5. Установите 2 партиции, key range = 4. Посмотрите как сообщения с одинаковым ключом распределяются между партициями
6. Установите 3 партиции, потом 4.
7. Установите 6 партиций. Что изменилось? Почему так происходит?
Возвращаемся в основной симулятор:
8. Установите: 2 брокера, фактор репликации - 2, 1 консьюмер группа, 1 консьюмер. Посмотрите, где и как реплицируются партиции и сообщения.
9. Установите: 3 брокера, фактор репликации = 2. Посмотрите, как теперь работает репликация.
10. Установите: фактор репликации = 1. Посмотрите, как теперь работает репликация.
11. Установите: фактор репликации = 3. Обратите внимание, как распределяются между брокерами мастер-партиции (яркие) и их реплики (блеклые)
12. Отключите один брокер, в котором есть хотя бы одна мастер-партиция, кликом по синей иконке. Это имитация недоступности одного из брокеров. Посмотрите, как перераспределились партиции.
На каждом шаге внимательно посмотрите, в какие брокеры и партиции записывается сообщение, и какие консьюмеры его получают. Объясните, почему так. Если объяснить не получается - нужно еще раз перечитать и осмыслить теорию. Ну и сами поиграйтесь с параметрами.