Apache Kafka как ядро event-streaming Big Data архитектуры: кейс The New York Times

Big Data, Большие данные, обработка данных, Kafka, архитектура, администрирование, Elasticsearch

Сегодня мы продолжим разговор о событийно-процессной архитектуре Big Data систем на примере использования Apache Kafka в The New York Times. Читайте далее, как одно из самых известных американских СМИ с более чем 160-летней историей хранит в Apache Kafka все свои статьи и с помощью API Kafka Streams публикует контент в режиме реального времени в различные приложения, делая его мгновенно доступным для читателей.

Постановка задачи: технический взгляд и позиция бизнеса

Основной причиной создания новой системы публикации контента в The New York Times стала необходимость оперативного предоставления множеству внутренних и внешних приложений доступа к опубликованному контенту. При этом стоило учесть разные требования каждого из компонентов этой многосвязной системы [1]:

  • сервису, который предоставляет содержимое для веб-сайта и собственных приложений необходимо делать ресурсы доступными сразу после их публикации, причем всегда нужна только последняя версия каждого ресурса.
  • Разные сервисы предоставляют списки контента, часть из которых составляются вручную, а некоторые — на основе запросов. Вторые нужно автоматически обновлять при публикации контента, который соответствует запросу. А если опубликовано обновление, из-за которого материал не отвечает этому требованию, его следует удалить из списка. Также требуется поддерживать изменения в самом запросе и создание новых списков, что предполагает доступ к ранее опубликованному контенту для повторного создания списков.
  • Для поиска по сайту используется кластер Elasticsearch, которому необходимо обеспечить легкий доступ к ранее опубликованному контенту, т.к. требуется переиндексировать все при изменении схемы или конвейера приема результатов поиска.
  • Поскольку каждому из читателей предлагается персонализированный контент, его необходимо обрабатывать повторно при изменении алгоритмов персонализации.

 

Почему Apache Kafka или проблемы API-based архитектуры

До перехода на Apache Kafka архитектура системы предоставления всем потребителям доступа к опубликованному контенту базировалась на API (API-based). Производители контента предоставляли API для доступа к нему, а также каналы, на которые можно подписаться для получения уведомлений о новых публикациях. Сервисы-потребители контента вызывали эти API, чтобы получить необходимые данные. Однако, эта типовая API-архитектура провоцировала целый ряд проблем:

  • поскольку разные API-интерфейсы разрабатывались в разное время разными командами, они работали совершенно по-разному – у них отличались фактически предоставляемые конечные точки, семантика и принимаемые параметры. Это усложняет работу с сервисами и требует усиленной координации между командами.
  • Каждая система имеет свою собственную, иногда неявно определенную схему. В частности, имена полей в одной CMS отличаются от таких же полей в другой CMS, а одно и то же имя поля могло означать абсолютно разные вещи в разных системах. Поэтому каждая система, которой нужен доступ к контенту, должна знать все эти различные API-интерфейсы и их особенности, и выполнять нормализацию между различными схемами данных.
  • Наконец, в рамках этой архитектуры не так-то просто получить доступ к ранее опубликованному контенту. Большинство систем не позволяли эффективно передавать архивы контента в потоковом режиме, а из СУБД не поддерживали его. Поэтому, даже при наличии списка всех публикаций, выполнение отдельного API-вызова для извлечения каждого отдельного материала занимает очень много времени и создает непредсказуемую нагрузку.

Для решения этих проблем Big Data специалисты в The New York Times приняли решение перейти от API-архитектуры к событийно-процессной или журнальной (log-based) на базе Apache Kafka, о которой мы расскажем далее.

 

Что такое log-based архитектура и чем она хороша

Идея журнальной архитектуры была впервые подробно описана исследователем кембриджского университета Мартином Клеппманном в статье «Turning the database inside-out with Apache Samza» (2015 год) [2] и позже раскрыта в его же книге «Designing Data-Intensive Applications» (2017 год) [3]. При этом журнал или лог выступает в качестве общей структуры данных. В случае Apache Kafka все опубликованное содержимое добавляется к топику в хронологическом порядке и сторонние сервисы получают к нему доступ, используя журнал. Таким образом, log-based архитектуры на основе журналов решают проблему единого источника истины, делая им журнал. Тогда как СУБД обычно хранит результат некоторого события, в журнале хранится оно само, поэтому лог становится упорядоченным представлением всех событий, произошедших в системе. Используя лог, можно создать любое количество пользовательских хранилищ данных, которые станут материализованными представлениями журнала, т.к. они содержат производное, а не исходное содержимое. Если нужно изменить схему в таком хранилище данных, можно просто создать новую и начать журнал заново.

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

Кроме того, log-based архитектура упрощает доступ к потокам контента. В традиционном хранилище данных доступ к полному дампу (моментальному снимку) и «живым» данным в виде канала реализуются по-разному. В журнальной или event-streaming архитектуре это различие пропадает: нужно всего лишь считывать лог с определенного смещения (начало, конец или любая промежуточная точка). Наконец, log-based архитектура также предоставляет множество преимуществ при развертывании систем с отслеживанием состояния, т.к. хранилище данных может быть воссоздано из журнала. Примечательно, что в отличие от Google Pub/Sub, AWS SNS/SQS и AWS Kinesis, Apache Kafka не только позволяет нескольким потребителям подписываться на сообщения, опубликованные разными несколькими производителями и отслеживать обработку без потери данных. Поскольку Kafka является журналом, то она хранит все события вечно, позволяя в любой момент восстановить историческую причинно-следственную связь системы [1].

 

Какие плюсы получил The New York Times от Apache Kafka

Возвращаясь к кейсу The New York Times, отметим, что, помимо log-based архитектуры, Apache Kafka также используется для создания целой системы data pipeline’ов. В частности, с помощью API Kafka Streams было разработано Java-приложение, которое поддерживает постоянно обновляемое локальное хранилище последней версии каждой публикации вместе со ссылками на нее. Когда новый материал публикуется, данное приложение собирает все зависимости из локального хранилища и записывает их в виде пакета в денормализованный журнал. Благодаря отсутствию нормализации, нет необходимости в полном упорядочивании, нужно только убедиться, что разные версии одного и того же материала поступают в корректном порядке. Таким образом, Kafka Streams позволяет использовать многораздельный журнал параллельно сразу для нескольких клиентов. Конвейер обработки данных при этом выглядит так [1]:

  • публикуется новый материал или обновляется CMS;
  • публикация записывается в шлюз как двоичный файл protobuf;
  • Шлюз проверяет актив и записывает его в локальное хранилище;
  • Приложение Kafka Streams потребляет публикацию актив из локального хранилища, собирая зависимости и записывая их вместе в денормализованный журнал.
  • Разделитель Kafka назначает ресурсы разделам на основе URI ресурса верхнего уровня.
  • Все узлы приема поиска запускают приложение, которое использует потоки Kafka для доступа к денормализованному журналу. Каждый узел считывает раздел, создает объекты JSON, которые будут проиндексированы в Elasticsearch, и записывает их в определенные узлы этой поисковой системы. Для ускорения индексации репликацию Elasticsearch можно отключить, включив ее потом снова до запуска нового индекса.
  • конвейер реализован на Google Cloud Platform, где запущены Apache Kafka и ZooKeeper. Все остальные процессы (шлюз, репликаторы Kafka, приложение Kafka Streams API и пр.) выполняются в контейнерах Kubernetes. Для обеспечения безопасности Kafka используется взаимная аутентификация, авторизация SSL и удаленный вызов процедур gRPC/Cloud Endpoint для API.
Big Data, Большие данные, обработка данных, Kafka, архитектура, администрирование, Elasticsearch
Конвейер публикаций в The New York Times

 

При том, что данная архитектура еще только вводится в production, сотрудники The New York Times отметили для себя целый ряд преимуществ [1]:

  • весь контент проходит через один и тот же конвейер, упрощая процессы разработки программного обеспечения как для интерфейсных приложений, так и для серверных систем;
  • развертывания стали проще, в частности, можно делать полные повторы в новые индексы Elasticsearch при внесении изменений в анализаторы или схему, вместо того, чтобы делать это на месте для текущего индекса.
  • Ведется непрерывный мониторинг того, как опубликованные ресурсы проходят через стек – каждой публикации, прошедшей через шлюз, назначается уникальный идентификатор, который возвращается издателю, а также передается Kafka и приложениям-потребителям. Это позволяет отслеживать и контролировать, где и когда каждое отдельное обновление обрабатывается, вплоть до приложений конечных пользователей.
Big Data, Большие данные, обработка данных, Kafka, архитектура, администрирование, Elasticsearch
Архитектура Big Data систем в The New York Times

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

 

Источники

  1. https://www.confluent.io/blog/publishing-apache-kafka-new-york-times/
  2. https://martin.kleppmann.com/2015/03/04/turning-the-database-inside-out.html
  3. https://habr.com/ru/company/piter/blog/309106/
Поиск по сайту