Оригинальная статья о технологии конских сот, пожалуйста, подпишитесь на общедоступный аккаунт, чтобы получать больше сухих товаров: mfwtech

Kafka — популярное промежуточное программное обеспечение очереди сообщений. Оно может обрабатывать массивные данные в режиме реального времени. Обладает характеристиками высокой пропускной способности, низкой задержки и надежного механизма асинхронной доставки сообщений. Оно вполне может решить проблему обмена и доставки данных между различными системами. .

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

Часть 1 Сценарий применения

С точки зрения сценариев применения Kafka на платформе больших данных она в основном делится на следующие три категории:

Первая категория — использование Kafka в качестве базы данных., которая предоставляет услуги хранения данных в реальном времени на платформе больших данных. По двум измерениям источника и назначения данные в реальном времени можно разделить на данные БД бизнес-стороны, журналы типа мониторинга, встроенные клиентские журналы на основе точек (H5, WEB, APP, апплет) и журналы на стороне сервера.

Вторая категория — предоставление источников данных для анализа данных., каждый журнал скрытых точек будет использоваться в качестве источника данных для поддержки и подключения автономных данных компании, хранилища данных в реальном времени и системы анализа, включая многомерные запросы, Druid OLAP в реальном времени, детали журнала и т. д.

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

Основное приложение показано на следующем рисунке:

Часть 2 Дорога эволюции

четыре этапа

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

Решение вышеуказанных проблем является для нас актуальным и сложным. В ответ на некоторые болевые точки в использовании Kafka для платформ больших данных мы выполнили ряд практик от использования кластера до расширения уровня приложения, В целом, он включает четыре этапа:

Первый этап: обновление версии. Сосредоточив внимание на некоторых узких местах и проблемах в производстве и использовании данных платформы, мы сделали технический выбор для текущей версии Kafka и, наконец, решили использовать версию 1.1.1.

Этап 2: Изоляция ресурсов. Чтобы поддержать быстрое развитие бизнеса, мы улучшили мультикластерное построение и изоляцию ресурсов между темами внутри кластера.

**Третья фаза:**Контроль разрешений и мониторинг сигналов тревоги.

Во-первых, с точки зрения безопасности, ранний кластер Kafka находился в запущенном состоянии. Поскольку несколько линеек продуктов используют Kafka, легко вызвать проблемы с безопасностью данных из-за неправильного прочтения тем других предприятий. Поэтому мы добавили функцию аутентификации на основе SASL/SCRAM + ACL.

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

Этап 4: Расширение приложения. В первые дни, когда Kafka была открыта для различных бизнес-направлений компании, из-за отсутствия единой спецификации использования некоторые деловые стороны использовали ее неправильно. Чтобы решить эту проблему, мы создали платформу подписки в реальном времени, которая позволяет бизнес-сторонам в форме сервисов приложений реализовать автоматизацию процессов во многих звеньях, таких как приложения для производства и потребления данных, авторизация пользователей платформы, мониторинг пользователей и сигнализация и т. д. Используйте общий замкнутый цикл всестороннего управления ресурсами и контроля.

Ниже приводится введение в несколько ключевых моментов.

основная практика

1. Обновление версии

Платформа больших данных использовала раннюю версию Kafka 0.8.3, и на данный момент последняя официальная версия Kafka достигла версии 2.3, поэтому при длительном использовании версии 0.8 постепенно возникало множество узких мест и проблем. мы Это может быть решено обновлением версии.

В качестве примера, вот некоторые распространенные проблемы со старыми версиями:

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

В то же время было проведено селекционное исследование по характеристикам некоторых целевых версий, таких как:

Версия 0.9, увеличенная квота и безопасность, из которых проверка подлинности и авторизация безопасности являются функциями, которые нас больше всего беспокоят.
Версия 0.10, более подробные метки времени.Вы можете выполнять быстрый поиск данных на основе смещений, чтобы найти нужные метки времени. Это чрезвычайно важно для воспроизведения данных на основе источника данных Kafka при обработке данных в реальном времени.
Версия 0.11, поддержка идемпотентности и транзакций, а также устранение потери/несогласованности данных в репликах.
Версия 1.1, улучшенная работа и обслуживание. Например, когда Controller Shut Down хочет выключить брокера, раньше для этого требовался долгий и сложный процесс, который был значительно улучшен в версии 1.0.

Окончательный выбор версии 1.1 обусловлен совместимостью версий Camus и Kafka и всесторонним рассмотрением поддержки важных новых функций в сценарии использования с версией 1.1. Здесь мы кратко поговорим о компоненте Camus, который также является открытым исходным кодом Linkedin и в основном используется как важный способ выгрузки данных Kafka в HDFS на нашей платформе больших данных.

2. Изоляция ресурсов

Ранее из-за сложности и небольшого масштаба бизнеса разделение кластеров Kafka платформой больших данных было относительно простым. Таким образом, через некоторое время бизнес-данные компании будут перемешаны, и необоснованное использование определенной бизнес-темы может привести к перегрузке некоторых брокеров, что повлияет на другие обычные бизнесы, и даже сбои некоторых брокеров повлияют на все. , что приводит к риску недоступности бизнеса в масштабах всей компании.

В ответ на вышеуказанные проблемы мы применили два метода трансформации кластера:

Разделить независимые кластеры по функциональному признаку
Изоляция ресурсов детализации тем внутри кластера

(1) Разделение кластера

Разделите несколько физических кластеров Kafka в соответствии с функциональными параметрами, чтобы изолировать сервисы и упростить эксплуатацию и техническое обслуживание.

Что касается наиболее важного использования данных скрытых точек, то в настоящее время они разделены на три типа кластеров. Функции каждого типа кластера определяются следующим образом:

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

Общая архитектура кластера делится следующим образом:

(2) Изоляция ресурсов

Размер тематического трафика является важной основой для изоляции ресурсов в кластере. Например, два источника данных с большим количеством встроенных журналов в нашем бизнесе — это внутренний встроенный источник данных сервер-событие и встроенный источник данных мобильных событий на конце.Мы должны избегать хранения тематического раздела двух Назначается узлам одного брокера в кластере. Физически изолируя разные темы, можно предотвратить искажение трафика на брокере.

3. Управление разрешениями и мониторинг сигналов тревоги

(1) Авторитетный контроль

В начале введения мы сказали, что ранний кластер Kafka не устанавливал проверку безопасности и находился в чистом рабочем состоянии, поэтому, пока вы знаете адрес подключения брокера, вы можете производить и потреблять, и есть серьезные проблемы с безопасностью данных.

Вообще говоря, большинство пользователей, которые используют SASL, выберут Kerberos, но с точки зрения сценария использования кластера платформы Kafka пользовательская система не сложна, и использование Kerberos несколько излишне, В то же время Kerberos относительно сложен, и есть риск вызвать другие проблемы. Кроме того, с точки зрения шифрования, поскольку все они работают в среде интрасети, шифрование SSL не используется.

Последний кластер платформы Kafka использует SASL в качестве метода аутентификации, основанного на облегченной комбинации SASL/SCRAM + ACL, для динамического создания пользователей и обеспечения безопасности данных.

(2) Мониторинг сигналов тревоги

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

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

Общая программа:

Общее решение в основном основано на компонентах с открытым исходным кодом Kafka JMX Metrics+OpenFalcon+Grafana:

Метрики Kafka JMX: внутренние метрики брокера Kafka выставляются наружу в виде метрик JMX. Версия 1.1.1 предоставляет множество индикаторов мониторинга для удовлетворения потребностей мониторинга.
OpenFalcon: высокодоступная и масштабируемая система мониторинга корпоративного уровня с открытым исходным кодом от Xiaomi.
Grafana: Знакомая всем система визуализации Metrics может быть подключена к множеству источников данных Metrics.

О мониторинге:

Falcon-agent: развертывается на каждом брокере, анализирует отчетные данные метрик Kafka JMX.
Grafana: используется для визуализации данных Falcon Kafka Metrics и создания панели мониторинга для четырех ролей кластера, брокера, темы и потребителя.
Eagle: получает активное состояние группы потребления и отставание группы потребления Lag, а также предоставляет API-интерфейсы для предоставления данных мониторинга для «радара» системы мониторинга и предупреждения.

Об оповещениях:

радиолокационная система: Самостоятельно разработанная система мониторинга, получает индикаторы Kafka через Falcon и Eagle и генерирует сигналы тревоги в сочетании с установленными пороговыми значениями. Если взять потребление в качестве примера, отставание является важным индикатором для измерения того, является ли потребление нормальным.Если отставание продолжает увеличиваться, с этим нужно бороться.

Когда возникает проблема, об этом должен знать не только администратор Потребителя, но и его пользователи, поэтому система сигнализации также должна уведомить пользователя. Конкретный метод заключается в автоматическом напоминании ответственному лицу или пользователю о соответствующей группе потребления и менеджере кластера Kafka через корпоративного робота сигнализации WeChat.

Пример мониторинга:

4. Расширения приложений

**(1) Платформа подписки на данные в режиме реального времени **

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

Основная идея состоит в том, чтобы управлять нижестоящими приложениями Kafka при одновременном повышении безопасности данных на основе проверки подлинности источника данных Kafka и контроля разрешений.

(2) Стандартизированный процесс подачи заявки

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

(3) Мониторинг сигналов тревоги

Для платформы разрешения привязаны к ресурсам, а ресурсы могут быть Topic для производства или GroupTopic для потребления. Как только разрешения будут назначены, использование этой части ресурса будет автоматически зарегистрировано в нашей системе радиолокационного мониторинга для наблюдения за всем жизненным циклом ресурса.

(4) Воспроизведение данных

Благодаря учету целостности и точности данных архитектура Lamda уже является распространенным методом архитектуры для больших данных. Но, с другой стороны, архитектура Lamda также имеет проблемы чрезмерного использования ресурсов и высокой сложности разработки.

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

(5) Управление темой

Зачем предоставлять управление темами? Чтобы привести несколько очень простых примеров, например, когда мы хотим, чтобы пользователь создал свою собственную тему Kafka в кластере, мы, очевидно, не хотим, чтобы он работал непосредственно на узле. Следовательно, для только что упомянутой службы, будь то для пользователей или администраторов, нам нужен интерфейс для ее работы, потому что невозможно всем подключиться к серверу через SSH.

Поэтому необходим сервис, предоставляющий функции управления, создание единой записи и внедрение сервиса для управления темами, включая создание тем, спецификацию изоляции ресурсов, управление метаданными тем и т. д.

(6) Выгрузка данных

В предыдущей архитектуре степень детализации потребления данных Kafka потребителем заключалась в том, что каждая тема Kafka сохраняет полные данные LogSource, но при использовании многим потребителям нужно потреблять только часть данных каждого LogSource, что может составлять несколько под определенным приложением.Данные о событии скрытой точки. Если нижестоящим приложениям необходимо написать свои собственные правила фильтрации, это должно привести к пустой трате ресурсов и простоте использования; кроме того, существуют некоторые сценарии, требующие объединения нескольких источников данных для совместного использования.

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

Часть 3 План дальнейших действий

Решить проблему дублирования данных. Чтобы решить проблему дублирования данных, вызванную такими факторами, как восстановление после сбоя в потоковой обработке текущей платформы в реальном времени, мы пытаемся использовать механизм транзакций Kafka в сочетании с двухэтапным протоколом фиксации Flink для достижения только сквозной обработки. -раз семантика. Он был протестирован в небольшом масштабе на платформе, и если он пройдет тест, он будет продвигаться в производственной среде.
Ограничение тока потребителя. В сценарии «многократная запись-чтение», если потребитель выполняет большое количество операций чтения с диска, это повлияет на задержку других операций потребителя на уровне «Производство». l Поэтому ограничение текущего потребления Consume и поддержка динамической настройки порога через механизм Kafka Quota также является нашим дальнейшим направлением.
расширение сцены. На основе Kafka различные методы подписки и создания сообщений, такие как SDK и HTTP, расширены для удовлетворения потребностей различных языковых сред и сценариев.

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

Автор этой статьи: Би Бо, инженер по исследованиям и разработкам платформы больших данных Mafengwo.