Informationen zu Kafka als Ziel

Sie können mithilfe von CDC Replication Engine for Kafkaaus jeder unterstützten CDC Replication -Quelle in einen Kafka -Cluster replizieren. Mit dieser Engine werden Kakfa-Nachrichten mit replizierten Daten in Kafka-Abschnitte geschrieben.

Standardmäßig werden replizierte Daten in der Nachricht „ Kafka “ im Avro-Binärformat „ Confluent “ geschrieben. Die folgenden Schema-Registrys sind kompatibel:

Sie können Subskriptionen für die Ausführung ohne Verbindung zu einer Schemaregistry konfigurieren, indem Sie einen Kafka -Prozessor für angepasste Operationen (KCOP) für CDC Replication Engine for Kafkaverwenden.

Der Kafka -Cluster und die Schemaregistrierungsanwendung, die Sie mit CDC Replication verwenden, sind außerhalb der CDC Replication -Installation und müssen unabhängig voneinander eingerichtet werden. CDC Replication bündelt die Schemaregistry oder das Kafka -Clusterdateisystem nicht und ist stattdessen für die Arbeit mit einer vorhandenen Kafka -Installation konzipiert.

Unabhängig davon, welche Schemaregistry verwendet wird, können Sie Kafka aus einer beliebigen von Ihnen bevorzugten Distribution verwenden. Wählen Sie von den Optionen in Confluent bzw. Hortonworks nur den Schemaregistry-Service und die entsprechende Confluent-Avro-Deserialisierungsfunktion für Binärdaten aus. Sowohl der Confluent Open Source-Schemaregistry-Service als auch der Hortonworks-Schemaregistry-Service fungieren als Repository für Avro-Schemas.

Die Schemaregistry ist ein kompakter Service zur Ausführung der folgenden Tasks:

  • Ist für ankommende Nachrichten empfangsbereit, die ein Schema für einen Abschnitt beschreiben, der eine Nummer zurückgibt, mit der eine Referenz auf dieses Schema für diesen Abschnitt erstellt wird.
  • Gibt anhand der Nummer das entsprechende Schema zurück, wenn Consumer Abschnittsdaten von Kafka anfordern.

Dieser Prozess ermöglicht die automatische Verarbeitung von Schemaänderungen, da jedem Datensatz bestimmte Versionen der Schemadaten eines Abschnitts zugeordnet sind. Der erste Datensatz mit einem geänderten Schema, der festgestellt wird, bewirkt, dass die Registry eine neue Nummer generiert und dieses Schema dem Datensatz des Abschnitts und zukünftigen Datensätzen zuordnet. Auf vorhandene Datensätze hat dies keine Auswirkungen, da die vorherige Version des Schemas weiterhin mit einer eigenen Referenznummer vorhanden ist.

Die CDC-Replikations-Engine für Kafka wurde entwickelt, um die Open-Source-Schema-Registry-API zu unterstützen, die in der Plattform Confluent bereitgestellt wird. Ab HDF v3.1.0 bietet Hortonworks Confluent Kompatibilität mit seinem Schemaregistry-Service, d. h. Hortonworks Schema Registry kann Schemas für Themen registrieren, die mit dem Confluent Avro-Serializer erstellt werden.

Dieser Schemaregistry-Service muss mit der ausgeführten Kafka-Version kompatibel sein. So ist zum Beispiel dokumentiert, dass die Confluent-Schemaregistry, die in Version 3.0 der Confluent-Plattform enthalten ist, Kafka 0.10.x unterstützt. Weitere Informationen finden Sie auf den folgenden Seiten:

Kafka-Datenconsumerkomponenten, die mit dem Kafka-Cluster erstellt oder verwendet werden, müssen die Deserialisierungsfunktion für die Schemaregistry verwenden, die im jeweiligen Schemaregistry-Service enthalten ist. Der Hostname und die Portnummer der Schemaregistry werden über die Kafka-Consumer-Eigenschaften als Parameter an die Deserialisierungsfunktion übergeben. Der Zugriff der Deserialisierungsfunktion auf die Schemaregistry ist aufgrund ihrer Integration in die innere Struktur transparent. So verarbeitet die Deserialisierungsfunktion bei der Ausführung automatisch die Zuordnung der entsprechenden Version des Schemas eines Abschnitts zu bestimmten Datensätzen für diesen Abschnitt.

Die CDC-Nachricht besteht aus einer Datenkomponente und einer Schlüsselkomponente. Der Kafka-Schlüssel basiert auf Schlüsselspalten, die vom Benutzer ausgewählt und in der Datenzuordnung der Replikationsquelle definiert sind. Die Datenkomponente der Nachricht enthält den Wert aller Spalten der Datenquelle, die für die Replikation ausgewählt wurden. Beachten Sie, dass Schlüsselspaltenwerte in diesem Teil der Nachricht erneut enthalten sind. Abgeleitete Spalten in der Quelle sind ebenfalls für die Replikation gültige Spalten, falls sie in CDC Management Console ausgewählt wurden.

CDC Replication enthält zwei Methoden für Schreibvorgänge in Kafka: eine Java-API und ein REST-Serverprotokoll. Bei Verwendung der Java™ -API lesen Kafka -Konsumenten die Kafka -Topics, die von CDC Replication gefüllt werden, mithilfe eines Deserializers, der mit dem CDC-Avro-Binärformat kompatibel ist. Bekannte kompatible Deserialisierungsfunktionen sind mit den Hortonworks- und Confluent-Schemaregistrypaketen verfügbar. Sie können Subskriptionen so konfigurieren, dass sie integrierte KCOPs (Kafka Custom Operation Processors), wie z. B. 'KcopJsonFormatIntegrated' oder 'KcopLiveAuditSingleRowIntegrated', verwenden, die Datensätze schreiben, die mit anderen Deserialisierungsfunktionen verarbeitet werden können. Schließlich können Kafka-Datensätze verarbeitet werden, indem das HTTP-Protokoll zum Herstellen einer Verbindung zum Kafka-REST-Server verwendet wird. Zum gegenwärtigen Zeitpunkt wird der einzige bekannte Kafka-REST-Server von Confluent bereitgestellt.

Hinweis: Die Java-API-Option für die Replikation auf Kafka -Ziele bietet die höchste Leistung und den größten Wertebereich für einige Datentypen. Die REST-API-Option eignet sich für Situationen, in denen die Kommunikation zwischen der CDC Replication Engine für Kafka -Ziel und dem eigentlichen Kafka Server über HTTP geleitet werden muss.

CDC Replication Engine for Kafka verwaltet das Lesezeichen, sodass nur Datensätze, die explizit als von Kafka geschrieben bestätigt wurden, als festgeschrieben betrachtet werden. Die Engine überspringt daher keine Operationen. Dieses Verhalten wird auch über mehrere Replikationssitzungen hinweg beibehalten, wobei eine Replikationssitzung eine Subskription im Status 'Spiegeln/Aktiv' ist. Dieses Verhalten bedeutet, dass CDC Replication Engine for Kafkaselbst bei einer abnormalen Beendigung (möglicherweise ist der Kafka -Cluster ausgefallen) beim Starten einer Subskription als 'Spiegel/Aktiv' sicherstellt, dass alle nicht bestätigten replizierten Quellenoperationen erneut gesendet, geschrieben und von Kafka bestätigt werden, bevor die Engine ihr Lesezeichen fortsetzt, um den Punkt anzugeben, der repliziert wurde. Hierbei handelt es sich um die Datenbereitstellungsgarantie.

Alle Daten, die in eine bestimmte Abschnitt/Partition-Kombination geschrieben werden, werden in der entsprechenden Reihenfolge für eine Subskription im Status 'Spiegeln/Aktiv' geschrieben. Beispiel: Wenn mehrere Datensätze aus verschiedenen Quellentabellen in einer Subskription an dieselbe Abschnitt/Partition-Kombination gesendet werden, weisen sie in dieser Abschnitt/Partition-Kombination dieselbe Reihenfolge auf wie in der Quellendatenbank.

Die Reihenfolge, in der die Operationen innerhalb einer Transaktion für die Quelle erfolgen, kann nicht unbedingt wiederhergestellt werden, indem die Kafka-Themen einfach verbraucht werden. Wenn ein Producer Datensätze zu einem Thema oder zu mehreren Themen für mehrere Partitionen schreibt, garantiert Kafka die Reihenfolge innerhalb einer Partition, aber nicht die Reihenfolge über mehrere Partitionen/Themen hinweg. Wie im Szenario der abnormalen Beendigung beschrieben, kann CDC Replication Engine for Kafka Daten erneut senden, die bereits an ein Kafka -Topic gesendet wurden, was zu Duplikaten führt, weil sichergestellt wurde, dass Nachrichten ordnungsgemäß zugestellt wurden.

Um dieses Problem zu beheben, stellt die CDC Replication Engine for Kafka in InfoSphere® Data Replication Version 11.4.0.0-505x und höher eine Kafka transaktionskonsistente Konsumentenbibliothek bereit, die Kafka -Datensätze bereitstellt, die frei von Duplikaten sind, und es Ihren Anwendungen ermöglicht, die Reihenfolge der Operationen in einer Quellentransaktion in mehreren Kafka -Topics und -Partitionen erneut zu erstellen.