Зачем хранить данные в Apache Kafka постоянно и как это сделать: варианты использования и пример архитектурного решения Infinite Storage от Confluent Cloud, который лег в основу Tiered Storage.
Infinite Storage от Confluent Cloud для бесконечного хранения данных в Apache Kafka
Изначально Apache Kafka, как и любой другой брокер сообщений, не предполагает долговременного хранения данных. Сохранение нужного объема данных в Kafka является сложным и дорогостоящим с операционной точки зрения. В первую очередь это связано с тем, что в Apache Kafka хранилище и вычисления связаны друг с другом. Существует практический предел объема данных, который можно хранить у одного брокера Apache Kafka. Как только этот лимит будет достигнут, придется расширить кластер, включив в него дополнительных брокеров. Например, есть топик с конфигурацией retention.time, установленной в 7 дней, куда публикуются данные с постоянной скоростью 150 МБ/с. К седьмому дню в этом топике будет около 90,7 ТБ данных или ~272 ТБ данных, если фактор репликации равен 3.
Чтобы избавить своих пользователей от необходимости думать об ограничениях хранилища, разработчики облачного коммерческого решения на основе Kafka – Confluent Cloud создали Infinite Storage. Этот механизм хранения предоставляет такую модель использования облака, которая позволяет пользователям хранить столько данных, сколько они хотят, и так долго, как им нужно, взимая плату только за используемое хранилище. Бесконечное хранилище начинается с разделения вычислительных ресурсов и ресурсов хранения. Благодаря этому можно хранить подмножество «горячих» данных локально на брокере, одновременно выгружая большую часть данных на уровень объектного хранилища соответствующего облачного провайдера. Объем хранилища увеличивается автоматически по мере необходимости без ограничений на время хранения.
Таким образом, неограниченное хранилище Confluent Cloud меняет архитектуру систем, построенных на основе Kafka как платформы потоковой передачи событий, позволяя получать доступ к событиям в реальном времени и историческим данным, с помощью меньшего числа элементов. Исключение дополнительных звеньев из архитектуры сложной системы повышает ее надежность и дает возможность реализовать самые разные паттерны проектирования и варианты использования:
- источник событий (Event Sourcing) — поиск событий становится операционно сложным, когда приходится постоянно контролировать хранилище и расширять емкость для постоянно растущего объема данных. С неограниченным хранилищем это становится намного проще. Например, чтобы пользователи интернет-магазина могли просматривать полную историю всех своих транзакций, надо сперва интегрировать все транзакционные события в Kafka, а затем передать их в поисковую систему типа Elasticsearch. По мере добавления новых транзакционных событий в Kafka они будут постепенно отражаться в индексе Elasticsearch в режиме реального времени. Если экземпляр Elasticsearch выйдет из строя, его придется менять. Также придется добавлять новый экземпляр, чтобы приспособиться к возросшему трафику. Бесконечное хранение данных в Kafka упрощает эту задачу. Экземпляр Elasticsearch может просто сбросить потребительское смещение в Kafka до нуля, чтобы учесть все исторические данные. Затем он плавно переключается в инкрементальный режим. Это намного проще, чем использовать Kafka для инкрементной части и другую систему для начальной загрузки.
- машинное обучение, персонализация и расширенная аналитика данных — возможность эффективного хранения данных в течение длительных периодов времени позволяет комбинировать данные в реальном времени с историческими событиями для различных целей. Например, ML-приложению такси необходимы данные о трафике в реальном времени и исторические оценки прибытия. Это можно реализовать с помощью библиотек потоковой обработки, например, ksqlDB – клиентской библиотеки, которая позволяет совершать вычисления над данными, хранящимися в топиках Kafka, с помощью SQL-запросов. Для повышения эффективности ksqlDB хранит свое состояние в локальном хранилище. Если экземпляр ksqlDB потерпел сбой, его состояние необходимо перестроить. Бесконечное хранение позволяет ksqlDB хранить полный журнал коммитов в Kafka и при необходимости воспроизводить его для восстановления его локального состояния.
- потоковая обработка исторических данных: Infinite Storage позволяет разработчикам тратить меньше времени и усилий на восстановление истории из различных систем. Обычно эта задача решается с помощью «обратного ETL», когда данные надо извлечь из различных последующих источников и соединить их вместе. Получать пакетные дампы данных из различных источников для воссоздания состояния обработки потока каждый раз, когда меняется логика вычислений, очень сложно и отнимает много времени. Имея полные наборы данных в потоковой форме, можно просто перемотать потребителей и выполнить повторную обработку. Хранение данных для соответствия требованиям соответствия Infinite Storage с Confluent Cloud также гарантирует соблюдение компаниями нормативных требований к хранению данных. Например, финансовые учреждения обязаны хранить данные в течение семи лет. Во время аудитов компании часто создают новое приложение только для того, чтобы получить данные за этот период времени. Гораздо проще прочитать эти данные из существующего лога Apache Kafka, чем перезагружать данные из различных источников данных.
Однако, просто сделать время хранения неограниченным недостаточно. В Apache Kafka смешивание потребителей, которые читают как данные в реальном времени (самые последние), так и исторические (самые ранние), может вызвать большую нагрузку на систему ввода-вывода, замедляя пропускную способность и увеличивая задержку. Поэтому в Infinite Storage введена изоляция ресурсов, которая происходит между этими операциями чтения. Потребители «в реальном времени» потребляют данные из локального хранилища, то есть продолжают использовать локальную систему ввода-вывода. Потребители, читающие исторические данные из объектного хранилища, используют сеть, которая потребляет отдельный пул ресурсов. Это означает, что операции чтения больших пакетов, которые обычно наблюдаются при исторических рабочих нагрузках, не конкурируют с потоковой природой рабочих нагрузок в реальном времени, предотвращая резкие скачки задержки и повышая пропускную способность.
Идеи и некоторые архитектурные решения Infinite Storage, реализованные в Confluent Cloud, легли в основу многоуровневого хранилища (Tiered Storage), которое впервые стало доступно как функция раннего доступа в Apache Kafka 3.6, о чем мы писали здесь.
Научитесь администрированию и эксплуатации Apache Kafka на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Apache Kafka для инженеров данных
- Администрирование кластера Kafka
- Администрирование Arenadata Streaming Kafka
Источники
