Бөлісу құралы:

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

  • Мақала

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

Пути миграции Kafka в HDInsight 3.6

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 для использования нового кластера.

Upgrade paths for Apache Kafka on 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, могут возвращаться к старым типам запросов или выдавать соответствующие ошибки, если функциональность недоступна.

Upgrade Kafka client compatibility.

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

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

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

Current Kafka presumed environment.

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

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

    Deploy new HDInsight 4.0 clusters.

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

    Switch cluster for producer app.

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

    Switch cluster on consumer app.

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

Следующие шаги