Не просто бургеры: архитектура данных в McDonald’s с Apache Kafka

архитектура данных Kafka пример, потоковая обработка событий с Apache Kafka Примеры курсы обучение, Apache Kafka Для дата-архитекторов и инженеров данных курсы обучение, реестр схем Apache Kafka, Kafka курсы примеры обучение, обучение большим данным, Школа Больших Данных Учебный Центр Коммерсант

Сегодня заглянем под капот ИТ-инфраструктуры самой знаменитой франшизы быстрого питания. Как устроена унифицированная платформа потоковой обработки событий в McDonald’s на базе облачного полностью управляемого сервиса Apache Kafka в AWS и что гарантирует высокую доступность и надежность решения.

Архитектурный дизайн

Архитектуры, основанные на событиях, обеспечивают гибкость интеграции, масштабируемость и некоторые возможности работы в реальном времени. Однако для успешной реализации такой архитектуры требуется надежная платформа. Будучи огромной корпорацией, McDonald’s использует события по всему технологическому стеку для асинхронной, транзакционной и аналитической обработки, включая отслеживание выполнения мобильных заказов и отправку маркетинговых сообщений (предложений и рекламных акций) своим клиентам.

Унифицированная платформа нужна для масштабируемой, безопасной и надежной обработки потока данных в режиме реального времени между службами и приложениями в разных доменах. Это обеспечивает согласованность и снижает сложность реализации и эксплуатации, связанную с поддержкой и внедрением архитектур обработки событий. Однако, несмотря на популярность решений подобного уровня, каждая большая компания реализует его под себя, т.к. отсутствуют универсальные лучшие практики и стандартные продукты. Поэтому на старте проекта архитекторы McDonald’s определили следующие высокоуровневые цели к будущей потоковой обработки событий:

  • автоматическое масштабирование для размещения растущего числа событий без потери качества обслуживания;
  • высокая доступность, чтобы выдерживать сбои в своих компонентах;
  • высокая производительность, события должны доставляться в режиме реального времени с возможностью обработки высококонкурентных рабочих нагрузок;
  • соответствие корпоративным рекомендациям по безопасности данных в части шифрования и контроля доступа;
  • управляемая надежность, чтобы избежать потери каких-либо событий;
  • согласованность реализации шаблонов, связанных с обработкой ошибок, отказоустойчивостью, развитием схемы данных, мониторингом и аварийным восстановлением;
  • простота реализации и эксплуатации.

События, создаваемые приложениями-продюсерами, будут отправляться в платформу потоковой обработки в виде сообщений, откуда их будут считывать потребители, т.е. другие приложения для последующих вычислений. Этот архитектурный дизайн реализуется следующими компонентами:

  • брокер сообщений, например, собственный кластер Apache Kafka или полностью управляемый облачный сервис типа AWS Managed Streaming for Kafka Service (MSK) для размещения топиков с событиями и предоставления семантики их создания и использования. В McDonald’s выбран AWS MSK, поскольку он интегрируется с другими сервисами AWS, которые используются в компании. При выборе также учитывался баланс между снижением эксплуатационных расходов и гибкостью настройки для сценариев использования.
  • реестр схем типа Confluent Schema Registry в Apache Kafka, нужный для проверки схемы данных и совместимости между версиями событий. События должны следовать четко определенному контракту, обеспечивая качество данных в нижестоящих приложениях-потребителях. Но потоковые данные имеют динамический характер, а потому эволюционируют. Реестр схем обеспечивает возможность работы приложений при изменении схемы событий.
  • Резервное хранилище событий. Чтобы избежать потери сообщений в случае недоступности MSK, платформа подключена к резервному хранилищу данных, где она записывает события в базу данных. Архитектура предоставляет инструменты и утилиты для чтения сообщений и публикации их обратно в MSK, как только этот облачный брокер сообщений вновь станет доступен.
  • SDK-инструменты разработки ПО, т.е. библиотеки для конкретных языков программирования, которые предоставляют продюсерам и потребителям API для записи и чтения событий со встроенной логикой проверки схемы, обработки ошибок и реализации шаблонов повторных попыток. SDK помогают разработчикам, повышая их производительность и обеспечивая последовательный подход к внедрению лучших практик.
  • вспомогательные утилиты и инструменты для разработчиков и SRE-инженеров, которые обеспечивают исправление событий в топиках недоставленных сообщений, видимость состояния кластера и администрирование кластера.
  • шлюз событий, который обеспечивает гибкость и абстракцию, не раскрывая внутреннее управление топиками Kafka, поскольку платформа потоковой обработки событий работает как с внутренними приложениями, так и с внешними системами.
Kafka архитектура данных AWS пример
Архитектурный дизайн платформы потоковой обработки событий в McDonald’s

Как работает эта архитектура данных, управляемая событиями, мы рассмотрим далее.

Принципы работы и технологии реализации

События создаются и потребляются вышеописанной платформой потоковой обработки McDonald’s следующим образом:

  • сперва схема события определяется и регистрируется в реестре схем;
  • приложения-продюсеры используют соответствующий SDK для публикации событий;
  • при запуске схема приложения-продюсера события кэшируется в нем для повышения производительности;
  • SDK выполняет проверку схемы, чтобы убедиться, что событие соответствует ей;
  • если проверка схемы прошла успешно, SDK публикует событие в основном топике Kafka. Иначе событие направляется в топик недоставленных сообщений для этого продюсера.
  • если SDK обнаруживает ошибку, связанную с недоступностью MSK, он записывает событие в базу данных DynamoDB;
  • приложения-потребители используют для чтения сообщений с событиями соответствующий SDK, который сперва выполняет проверку схемы, чтобы убедиться в корректности событий;
  • успешное потребление событий приводит к фиксации смещения обратно в MSK и переводит к потреблению следующего события из топика;
  • события в топике недоставленных сообщений позже исправляются с помощью утилиты администратора и публикуются обратно в основной топик Kafka;
  • внешние события от сторонних систем публикуются через шлюз событий.

Ключевой проблемой в потребляющих системах обычно является целостность данных. В случае McDonald’s гарантии консистентности обеспечивает MSK и реестр схем, позволяя обеспечивать соблюдение контрактов данных между системами. Схема определяется как описание ожидаемых полей и типов данных, а также необязательных и обязательных полей. В режиме реального времени каждое сообщение проверяется с помощью библиотек сериализации по этой схеме на достоверность. При обнаружении несоответствий сообщение направляется в топик недоставленных сообщений для исправления.

Apache Kafka примеры курсы обучение для архитекторов
Реализация архитектуры

При запуске приложения-продюсеры кэшируют в памяти список известных схем данных. Схема может быть обновлена ​​по разным причинам, включая увеличение количества полей или изменение типов данных. Когда продюсер публикует сообщение, информация о версии сохраняется в теме с использованием специального байта в начале каждого сообщения. Позже, когда сообщения потребляются, этот байт определяет, с какой схемой предполагается использовать сообщение. Такой подход сокращает количество последовательных обновлений и смешанных версий сообщений в топиках Kafka. Если нужно выполнить откат назад или сделать обновление схемы, потребители могут анализировать каждое сообщение отдельно. Использование реестра схем проверяет контракты данных в разрозненных системах и помогает обеспечить целостность данных в нижестоящих аналитических приложениях.

Хотя AWS MSK обеспечивает автоматическое масштабирование хранилища, подключенного к брокеру, инженерам McDonald’s пришлось создать собственное решение для расширения кластера. Эта функция автомасштабирования срабатывает, когда загрузка ЦП брокера превышает настраиваемый порог, добавляя брокера в кластер MSK, а затем запуская другую лямбда-функцию для перемещения разделов между брокерами. Для эффективного масштабирования и минимизации сбоев события разделены по нескольким кластерам MSK на основе домена. Домен событий определяет, в каком кластере будет находиться топик Kafka, а приложения-потребители имеют возможность использовать события из любого топика разных домена. Платформа настроена для поддержки глобальных развертываний в разных регионах с конфигурацией высокой доступности каждого.

автомасштабирование кластера Apache Kafka
Автомасштабирование и доменное разделение

В будущем дата-инженеры McDonald’s планируют развивать реализованную платформу потоковой обработки событий, добавив поддержку формальной спецификации событий, и перейти к бессерверному подходу для MSK, а также автомасштабированию разделов топиков Kafka.

Узнайте, как внедрить современные архитектурные модели на базе Apache Kafka в свои ИТ-проекты аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  1. https://medium.com/mcdonalds-technical-blog/behind-the-scenes-mcdonalds-event-driven-architecture-51a6542c0d86
  2. https://medium.com/mcdonalds-technical-blog/mcdonalds-event-driven-architecture-the-data-journey-and-how-it-works-4591d108821f

 

Поиск по сайту