Поделиться через

Перенос рабочих нагрузок Apache Kafka в Azure HDInsight 4.0

  • Статья

Azure HDInsight 4.0 предлагает последние компоненты с открытым кодом с значительными улучшениями производительности, подключения и безопасности. В этом документе объясняется, как перенести рабочие нагрузки Apache Kafka в HDInsight 3.6 в HDInsight 4.0. После переноса рабочих нагрузок в HDInsight 4.0 можно использовать множество новых функций, которые недоступны в HDInsight 3.6.

Пути миграции для HDInsight 3.6 Kafka

HDInsight 3.6 поддерживает две версии Kafka: 1.0.0 и 1.1.0. HDInsight 4.0 поддерживает версии 1.1.0 и 2.1.0. В зависимости от версии Kafka и какой версии HDInsight вы хотите запустить, существует несколько поддерживаемых путей миграции. Эти пути описаны ниже и показаны на следующей схеме.

  • Запустите и Kafka, и HDInsight на последних версиях (это рекомендуется): перенесите приложение HDInsight 3.6 и Kafka 1.0.0 или 1.1.0 на HDInsight 4.0 с Kafka 2.1.0 (пути D и E ниже).
  • Запустите HDInsight в самой последней версии, но Kafka только на более новой версии: модернизируйте приложение HDInsight 3.6 и Kafka 1.0.0 до HDInsight 4.0 с Kafka 1.1.0 (путь B ниже).
  • Запустите HDInsight на последней версии, сохраняя версию Kafka: перенесите приложение HDInsight 3.6 и Kafka 1.1.0 в HDInsight 4.0 с Kafka 1.1.0 (см. путь C ниже).
  • Запустите Kafka на более новой версии, сохраните версию HDInsight: обновите приложение Kafka с 1.0.0 до 1.1.0 и оставайтесь на HDInsight 3.6 (путь A см. ниже). Обратите внимание, что этот параметр по-прежнему потребует развертывания нового кластера. Обновление версии Kafka в существующем кластере не поддерживается. После создания кластера с нужной версией перенесите клиенты Kafka на использование нового кластера.

Пути обновления для Apache Kafka 3.6.

Версии Apache Kafka

Kafka 1.1.0

При переходе с Kafka 1.0.0 на 1.1.0 можно воспользоваться следующими новыми функциями:

  • Усовершенствования контроллера Kafka ускоряют контролируемое завершение работы, поэтому вы можете перезапустить брокеры и быстрее восстановиться после проблем.
  • Улучшения логики FetchRequests , которые позволяют иметь больше секций (и, следовательно, больше тем) в кластере.
  • Kafka Connect поддерживает заголовки записей и регулярные выражения для тем.

Полный список обновлений см. в заметках о выпуске Apache Kafka 1.1.

Apache Kafka 2.1.0

При переходе на Kafka 2.1 вы можете воспользоваться следующими функциями:

  • Повышение устойчивости брокера из-за улучшенного протокола репликации.
  • Новые функции в API KafkaAdminClient.
  • Настраиваемое управление квотами.
  • Поддержка сжатия Zstandard.

Полный список обновлений см. в заметках о выпуске Apache Kafka 2.0 и заметках о выпуске Apache Kafka 2.1.

Совместимость клиента Kafka

Новые брокеры Kafka поддерживают старых клиентов. KIP-35 — Получение версии протокола ввела механизм динамического определения функциональности брокера Kafka, а KIP-97: Улучшенная политика совместимости RPC клиента Kafka представила новую политику совместимости и гарантии для клиента Java. Ранее клиент Kafka должен был взаимодействовать с брокером той же версии или более новой. Теперь более новые версии клиентов Java и других клиентов, поддерживающих KIP-35, например librdkafka , могут вернуться к старым типам запросов или вызвать соответствующие ошибки, если функциональные возможности недоступны.

Обновление совместимости клиента Kafka.

Обратите внимание, что это не означает, что клиент поддерживает старых брокеров. Дополнительные сведения см. в таблице совместимости.

Общий процесс миграции

Предполагается, что в следующем руководстве по миграции кластер Apache Kafka 1.0.0 или 1.1.0 развернут на HDInsight 3.6 в одной виртуальной сети. Существующий брокер имеет некоторые темы и активно используется производителями и потребителями.

Текущая предполагаемая среда Kafka.

Чтобы завершить миграцию, выполните следующие действия.

  1. Разверните новый кластер HDInsight 4.0 и клиенты для тестирования. Разверните новый кластер HDInsight 4.0 Kafka. Если можно выбрать несколько версий кластера Kafka, рекомендуется выбрать последнюю версию. После развертывания задайте некоторые параметры по мере необходимости и создайте раздел с тем же именем, что и существующая среда. Кроме того, при необходимости задайте шифрование TLS и при необходимости присвойте шифрованию собственный ключ (BYOK). Затем проверьте, работает ли он правильно с новым кластером.

    Развертывание новых кластеров HDInsight 4.0.

  2. Смените кластер для приложения-производителя и дождитесь, пока все данные очереди не будут потреблены текущими потребителями. Когда будет готов новый кластер HDInsight 4.0 Kafka, переключите адрес назначения производящего узла на новый кластер. Оставьте его как есть, пока существующее потребительское приложение не потребит все данные из существующего кластера.

    Смена кластера для приложения производителя.

  3. Переключите кластер в потребительском приложении. Убедившись, что существующее приложение-получатель завершило использование всех данных из существующего кластера, переключите подключение к новому кластеру.

    Переключение кластера в потребительском приложении.

  4. Удалите старый кластер и тестируйте приложения по мере необходимости. После завершения переключения и его правильной работы удалите старый кластер HDInsight 3.6 Kafka, а также производителей и потребителей, используемых в тесте, по мере необходимости.

Дальнейшие действия