Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Azure HDInsight 4.0 offers the latest open-source components with significant enhancements in performance, connectivity, and security. This document explains how to migrate Apache Kafka workloads on HDInsight 3.6 to HDInsight 4.0. After migrating your workloads to HDInsight 4.0, you can use many of the new features that aren't available on HDInsight 3.6.
HDInsight 3.6 Kafka migration paths
HDInsight 3.6 supports two versions of Kafka: 1.0.0 and 1.1.0. HDInsight 4.0 supports versions 1.1.0 and 2.1.0. Depending on which version of Kafka and which version of HDInsight you would like to run, there are multiple supported migration paths. These paths are explained below and illustrated in the following diagram.
- Run both Kafka and HDInsight on latest versions (recommended): Migrate an HDInsight 3.6 and Kafka 1.0.0 or 1.1.0 application to HDInsight 4.0 with Kafka 2.1.0 (paths D and E below).
- Run HDInsight on the latest version, but Kafka only on a more recent version: Migrate an HDInsight 3.6 and Kafka 1.0.0 application to HDInsight 4.0 with Kafka 1.1.0 (path B below).
- Run HDInsight on the latest version, retain Kafka version: Migrate an HDInsight 3.6 and Kafka 1.1.0 application to HDInsight 4.0 with Kafka 1.1.0 (path C below).
- Run Kafka on a more recent version, retain HDInsight version: Migrate a Kafka 1.0.0 application to 1.1.0 and stay on HDInsight 3.6 (path A below). Note that this option will still require deploying a new cluster. Upgrading the Kafka version on an existing cluster is not supported. After you create a cluster with the version you want, migrate your Kafka clients to use the new cluster.
Apache Kafka versions
Kafka 1.1.0
If you migrate from Kafka 1.0.0 to 1.1.0 you can take advantage of the following new features:
- Improvements to the Kafka controller speed up controlled shutdown, so you can restart brokers and recover from issues faster.
- Improvements in the FetchRequests logic which enable you to have more partitions (and hence more topics) on the cluster.
- Kafka Connect supports record headers and regular expressions for topics.
For a complete list of updates, see Apache Kafka 1.1 release notes.
Apache Kafka 2.1.0
If you migrate to Kafka 2.1, you can take advantage of the following features:
- Better broker resiliency due to an improved replication protocol.
- New functionality in the KafkaAdminClient API.
- Configurable quota management.
- Support for Zstandard compression.
For a complete list of updates, see Apache Kafka 2.0 release notes and Apache Kafka 2.1 release notes.
Zgodność klienta platformy Kafka
Nowi brokerzy platformy Kafka obsługują starszych klientów.
KIP-35 — Wersja protokołu pobierania wprowadziła mechanizm dynamicznego określania funkcjonalności brokera platformy Kafka i KIP-97: Ulepszone zasady zgodności RPC klienta platformy Kafka wprowadziły nowe zasady zgodności i gwarancje dla klienta Java. Wcześniej klient platformy Kafka musiał wchodzić w interakcję z brokerem tej samej wersji lub nowszej wersji. Now, newer versions of the Java clients and other clients that support KIP-35 such as librdkafka can fall back to older request types or throw appropriate errors if functionality isn't available.
Note that it does not mean that the client supports older brokers. Aby uzyskać więcej informacji, zobacz Macierz zgodności.
Ogólny proces migracji
The following migration guidance assumes an Apache Kafka 1.0.0 or 1.1.0 cluster deployed on HDInsight 3.6 in a single virtual network. Istniejący broker ma kilka tematów i jest aktywnie używany przez producentów i konsumentów.
Aby ukończyć migrację, wykonaj następujące czynności:
Deploy a new HDInsight 4.0 cluster and clients for test. Deploy a new HDInsight 4.0 Kafka cluster. Jeśli można wybrać wiele wersji klastra Platformy Kafka, zaleca się wybranie najnowszej wersji. Po wdrożeniu ustaw parametry zgodnie z potrzebami i utwórz temat o tej samej nazwie co istniejące środowisko. Ponadto ustaw szyfrowanie TLS i szyfrowanie z użyciem własnego klucza (BYOK) zgodnie z potrzebami. Następnie sprawdź, czy działa poprawnie z nowym klastrem.
Switch the cluster for the producer application, and wait until all the queue data is consumed by the current consumers. When the new HDInsight 4.0 Kafka cluster is ready, switch the existing producer destination to the new cluster. Pozostaw ją tak, jak jest, dopóki istniejąca aplikacja konsumenta nie zużyje wszystkich danych z istniejącego klastra.
Switch the cluster on the consumer application. Po potwierdzeniu, że istniejąca aplikacja konsumenta zakończyła korzystanie ze wszystkich danych z istniejącego klastra, przełącz połączenie z nowym klastrem.
Usuń stary klaster i aplikacje testowe zgodnie z potrzebami. Once the switch is complete and working properly, remove the old HDInsight 3.6 Kafka cluster and the producers and consumers used in the test as needed.