Перенос рабочих нагрузок 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 для использования нового кластера.
Версии 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
, могут возвращаться к старым типам запросов или выдавать соответствующие ошибки, если функциональность недоступна.
Обратите внимание: это не означает, что клиент поддерживает более старые брокеры. Дополнительные сведения см. в разделе Таблица совместимости.
Общий процесс миграции
В следующих руководствах по миграции предполагается, что кластер Apache Kafka 1.0.0 или 1.1.0, развернутый в HDInsight 3.6, находится в отдельной виртуальной сети. У существующего брокера есть несколько разделов, и он активно используется производителями и объектами-получателями.
Чтобы завершить миграцию, выполните следующие действия.
Разверните новый кластер и клиенты HDInsight 4.0 для тестирования. Разверните новый кластер HDInsight 4.0 Kafka. Если можно выбрать несколько версий кластера Kafka, рекомендуется выбрать последнюю версию. После развертывания задайте необходимые параметры и создайте раздел с тем же именем, что и у существующей среды. Кроме того, при необходимости задайте TLS и шифрование с созданием собственных ключей (BYOK). Затем проверьте, правильно ли оно работает с новым кластером.
Переключите кластер для приложения производителя и подождите, пока все данные очереди не начнут использоваться текущими объектами-получателями. Когда новый кластер HDInsight 4.0 Kafka будет готов, переключите существующее назначение на новый кластер. Ничего не меняйте до тех пор, пока существующее приложение объекта-получателя не использует все данные из существующего кластера.
Переключите кластер на приложение объекта-получателя. Убедившись, что существующее приложение объекта-получателя завершило использование всех данных из существующего кластера, переключитесь на подключение к новому кластеру.
При необходимости удалите старый кластер и тестовые приложения. После завершения и правильной работы переключения при необходимости удалите старый кластер HDInsight 3.6 Kafka, а также создатели и объекты-получатели, которые использовались в тесте.