Никита Рьянов — Строим смобалансирующийся мониторинг обработки топиков Kafka с помощью самой Kafka

• Приветствие участников конференции.  

• Представление темы доклада о Kafka.  

• Представление спикера Никиты Янова из компании Тинькофф.  

• Никита объясняет, что доклад будет о мониторинге Kafka и оптимизации джойнов.  

• Призыв к участникам поднять руки, если они используют Kafka Stream.  

• Никита Янов из команды платформенной разработки Тинькофф.  

• Описание сервиса потоковой обработки и его мониторинга.  

• План доклада: постановка задачи, ограничения, актуальность метрик, проблемы и их решения.  

• Задача: мониторить состояние обработки Kafka топиков.  

• Описание сложности задачи: множество топиков с разными профилями нагрузки.  

• Необходимость метрики для понимания состояния топиков и их актуальности.  

• Обсуждение метрики актуальности и её важности для бизнеса.  

• Сравнение метрик LAG и актуальности.  

• Проблемы с метрикой LAG и необходимость более точной метрики.  

• Описание структуры Kafka сообщений и их метаданных.  

• Важность тайм-стемпа для расчета дельты между сообщениями.  

• Различие между K-Time и LAG-Time и их влияние на точность метрики.  

• Процесс расчета метрики актуальности.  

• Использование последних обработанных и необработанных сообщений.  

• Проблемы с масштабированием и рестартом системы.  

• Хранение двух хэшмап для расчета дельты.  

• Потеря состояния при перезапуске сервиса.  

• Оптимизация: сохранение внешнего стейта в компакт-топик.  

• Добавление реплик для надежности.  

• Проблема дублирования метрик.  

• Неэффективность и сложность обработки большого количества топиков.  

• Добавление компакт-топика со списком активных топиков.  

• Использование Kafka Streams для выполнения нескольких JOIN.  

• Проблемы с составными ключами и необходимость ручного джойна.  

• Построение топологии и сбор мемри стейта.  

• Использование легковесных решений для хранения данных.  

• Автоматическое сохранение изменений в чен топик.  

• Использование стандартного оператора для заполнения стейта.  

• Применение хэшмапы для хранения данных.  

• Использование интерактивных кэров для доступа к данным.  

• Обработка исключений при миграции состояния.  

• Проблемы с корректным джойном партийций.  

• Необходимость использования партишн сайнеров для равномерного распределения нагрузки.  

• Раунд робин и рейнджа сайнеры.  

• Проблемы с использованием рейнджа сайнера в Kafka Streams.  

• Необходимость изучения алгоритмов распределения партийций.  

• Алгоритм состоит из пяти шагов, первый из которых валидирует топики на одинаковое количество партийций и ключи.  

• Для валидации нужно явно указать джойн, чтобы Kafka Streams запускал этот шаг.  

• Пример топологии показывает, что добавление джойна увеличивает объем данных в семь раз.  

• Исходные топики имеют одинаковое число партийций и разные ключи сообщений.  

• Нужно объяснить Kafka Streams, что топики уже позиционированы, чтобы избежать увеличения данных.  

• Рассматривается возможность реализации кастомного Task Saver для распределения партийций по клиентам.  

• Интерфейс Task Saver открыт, но есть нюансы с его внедрением в Kafka Streams.  

• Основная логика Task Saver включает группировку партийций по номерам и сбор информации о клиентах.  

• Распределение задач по клиентам выполняется вручную с использованием Round Robin.  

• Kafka Streams автоматически перемещает состояние между инстансами мониторинга при их падении.  

• Решение обеспечивает надежность и корректное распределение нагрузки.  

• Масштабирование возможно через увеличение количества партийций, но это может нарушить распределение ключей.  

• Для мониторинга множества топиков с разным профилем нагрузки рекомендуется использовать метрику актуальности.  

• Kafka Streams полезен для решения проблемы обогащения данных, что часто решается с помощью Apache Flume или Apache Spark.  

• Kafka Streams позволяет упростить топологию и достичь эффективного и легковесного решения.  

• Kafka Stream позволяет оставаться легковесным решением для микросервисов.  

• Напоминание о возможности задать вопросы через QR-код и оставить оценку докладу.  

• Мониторинг специальных топиков осуществляется стандартными средствами Kafka.  

• Важно гарантировать отсутствие отставания в чтении топиков.  

• Сообщения не перекладываются целиком, а конвертируются в метрики.  

• Сохраняются только важные данные, такие как таймстемп.  

• Решение для мониторинга доступно в репозитории на GitHub.  

• Решение простое и легко реализуемое.  

• Консьюмер группы не используются для обработки исходных топиков.  

• Мониторинг осуществляется по одному консьюмеру, так как единственным консьюмером является платформа.  

• Важно учитывать, что последнее сообщение не двигается.  

• Метрика показывает дельту актуальности данных, чтобы бизнес понимал, как долго данные не обрабатываются.