Übersicht: Connectors

Dieses Dokument bietet einen Überblick über Kafka Connect-Connectors inGoogle Cloud. Hier erfahren Sie, wann Sie die einzelnen Connectortypen zum Verwalten und Einbinden Ihrer Datenstreams verwenden sollten.

Diese Connectors verwenden das Kafka Connect-Framework, um Apache Kafka in andere Anwendungen zu integrieren. Sie erfassen und replizieren Daten zwischen Ihren Kafka-Clustern und Anwendungen. Die verfügbaren Connector-Typen sind:

  • MirrorMaker 2.0-Connectors

    • Quellconnector

    • Checkpoint-Connector

    • Heartbeat-Connector

  • BigQuery-Senken-Connector

  • Cloud Storage-Senken-Connector

  • Pub/Sub-Quell-Connector

  • Pub/Sub-Senken-Connector

MirrorMaker 2.0-Connectors wurden speziell für die Datenreplikation und Notfallwiederherstellung zwischen Kafka-Clustern entwickelt. Sie ermöglichen das Spiegeln von Daten von einem Kafka-Cluster in einen anderen und sorgen so für Hochverfügbarkeit und Fehlertoleranz.

MirrorMaker 2.0-Connectors können Verbindungen zwischen Managed Service for Apache Kafka-Clustern und anderen Managed Service for Apache Kafka-Clustern oder selbstverwalteten Kafka-Clustern herstellen.

Die anderen Sink- und Source-Connectors dienen dazu, Kafka in verschiedeneGoogle Cloud -Dienste einzubinden. Mit diesen Connectors können Daten zwischen Managed Service for Apache Kafka-Clustern und Google Cloud -Diensten wie BigQuery, Cloud Storage oder Pub/Sub übertragen werden.

Hinweise

Bevor Sie Connectors untersuchen und erstellen, sollten Sie sich mit den folgenden Grundlagen und Voraussetzungen vertraut machen:

Wann sollte MirrorMaker 2.0 verwendet werden?

Verwenden Sie MirrorMaker 2.0-Connectors in den folgenden Szenarien:

  • Daten migrieren: Verschieben Sie Ihre Kafka-Arbeitslast in einen neuen Managed Service for Apache Kafka-Cluster.

  • Notfallwiederherstellung: Erstellen Sie einen Sicherungscluster, um im Falle von Ausfällen die Geschäftskontinuität zu gewährleisten.

  • Daten aggregieren: Konsolidieren Sie Daten aus mehreren Kafka-Clustern in einem zentralen Managed Service for Apache Kafka-Cluster für Analysezwecke.

Wichtige Funktionen von MirrorMaker 2.0

  • Es werden alle erforderlichen Komponenten repliziert, einschließlich Themen, Daten, Konfigurationen, Consumer-Gruppen mit Offsets und ACLs.
  • Behält dasselbe Partitionierungsschema im Zielcluster bei, was den Übergang für Anwendungen vereinfacht.
  • Neue Themen und Partitionen werden automatisch erkannt und repliziert, sodass die manuelle Konfiguration minimiert wird.
  • Bietet wichtige Messwerte wie die End-to-End-Replikationslatenz, mit denen Sie den Zustand und die Leistung des Replikationsprozesses im Blick behalten können.
  • Sorgt für einen zuverlässigen Betrieb, auch bei großen Datenmengen, und kann horizontal skaliert werden, um steigende Arbeitslasten zu bewältigen.
  • Verwendet interne Themen für die Offset-Synchronisierung, Checkpoints und Heartbeats. Für diese Themen sind konfigurierbare Replikationsfaktoren wie offset.syncs.topic.replication.factor verfügbar, um Hochverfügbarkeit und Fehlertoleranz zu gewährleisten.

MirrorMaker 2.0-Quellconnector verwenden

Der Quell-Connector von MirrorMaker 2.0 repliziert Themen und Daten von einem Kafka-Cluster (der Quelle) in einen anderen Kafka-Cluster (dem Ziel).

Quelle Ziel
Managed Service for Apache Kafka-Cluster Managed Service for Apache Kafka-Cluster
Managed Service for Apache Kafka-Cluster Externer oder selbstverwalteter Kafka-Cluster
Externer oder selbstverwalteter Kafka-Cluster Managed Service for Apache Kafka-Cluster

Der MirrorMaker 2.0-Quellconnector unterstützt die folgenden Migrationsszenarien:

  • Daten aus einem externen oder selbstverwalteten Kafka-Cluster in einen Managed Service for Apache Kafka-Cluster replizieren oder migrieren

  • Daten aus einem Managed Service for Apache Kafka-Cluster in einen externen oder selbstverwalteten Kafka-Cluster replizieren oder migrieren.

  • Kafka-Daten über Regionen hinweg replizieren, um die Anforderungen an Notfallwiederherstellung und Hochverfügbarkeit zu erfüllen.

MirrorMaker 2.0-Prüfpunkt-Connector verwenden

Die Verwendung des Prüfpunkt-Connectors von MirrorMaker 2.0 ist optional. Dabei werden die Consumer-Offsets kopiert, die die letzte erfolgreich verarbeitete Nachricht angeben. So können Consumer im Zielcluster die Verarbeitung an derselben Stelle fortsetzen wie im Quellcluster.

Dieser Connector ist nicht erforderlich, damit der MirrorMaker 2.0-Quellconnector funktioniert. Dieser Connector ist nur erforderlich, wenn Sie den ConsumerGroup-Status synchronisieren müssen, um die Ausfallzeit beim Wechsel vom Quell- zum Zielcluster zu minimieren. Wenn Sie nur eine Kopie Ihrer Quelldaten benötigen, ist dieser Connector nicht erforderlich.

Verwenden Sie den Prüfpunkt-Connector von MirrorMaker 2.0 für die folgenden Anwendungsfälle:

  • Notfallwiederherstellung, um einen konsistenten Verbraucherstatus über Cluster hinweg aufrechtzuerhalten und ein nahtloses Failover zu ermöglichen.

  • Den Fortschritt der Nutzer in wichtigen Szenarien beibehalten

MirrorMaker 2.0-Heartbeat-Connector verwenden

Der Heartbeat-Connector von MirrorMaker 2.0 ist eine optionale Komponente, die im Kafka-Quellcluster regelmäßig Heartbeat-Nachrichten generiert. Der Connector schreibt diese Nachrichten in ein dediziertes Thema, das in der Regel heartbeats heißt.

Sie können einen MirrorMaker 2.0-Quell-Connector so konfigurieren, dass das Thema heartbeats in den Zielcluster repliziert wird. Wenn Sie sich dieses replizierte Thema im Zielcluster ansehen, können Sie den Status und die Leistung Ihres Themenreplikationsvorgangs überwachen. So lässt sich die Verbindung und der Datenfluss zwischen Clustern überprüfen, auch wenn keine anderen Daten erzeugt oder repliziert werden.

Wenn Sie nur den Heartbeat-Connector bereitstellen, wird die Replikationsintegrität nicht automatisch überwacht. Wenn Sie es für das Monitoring verwenden möchten, müssen Sie das Thema heartbeats replizieren und dann seine Präsenz und Aktualität im Zielcluster beobachten oder Monitoring-Tools verwenden, die diese Heartbeats nutzen.

Der Heartbeat-Connector ist nicht erforderlich, damit der MirrorMaker 2.0-Quellconnector funktioniert. Verwenden Sie den MirrorMaker 2.0-Heartbeat-Connector für die folgenden Anwendungsfälle:

  • Zustand und Status der MirrorMaker 2-Replikation überwachen

  • Konfigurieren Sie Benachrichtigungen in Cloud Monitoring mit den generierten Heartbeats und verfügbaren Messwerten, um sich benachrichtigen zu lassen, wenn die Replikation oder der Heartbeat stoppt.

Sink-Connectors verwenden

Senken-Connectors exportieren Daten aus Kafka-Themen in andere Systeme.

BigQuery-Senken-Connector verwenden

Der Senken-Connector von BigQuery streamt Daten aus Kafka-Themen in BigQuery-Tabellen.

Verwenden Sie den BigQuery-Senken-Connector für die folgenden Anwendungsfälle:

  • Data Warehousing, um Streamingdaten zur Analyse und Berichterstellung in BigQuery zu laden.

  • BigQuery-Tabellen mit Daten füllen, die für Echtzeit-Dashboards verwendet werden.

Cloud Storage-Senken-Connector verwenden

Der Senken-Connector von Cloud Storage streamt Daten aus Kafka-Themen in Cloud Storage-Buckets.

Verwenden Sie den Cloud Storage-Sink-Connector für die folgenden Anwendungsfälle:

  • Data Lake-Aufnahme, um Kafka-Daten in einem Data Lake für die langfristige Archivierung und Batchverarbeitung zu speichern.

  • Daten archivieren, um gesetzliche Anforderungen zu erfüllen.

Pub/Sub-Senken-Connector verwenden

Der Senken-Connector von Pub/Sub streamt Nachrichten aus Kafka-Themen in ein Pub/Sub-Thema.

Verwenden Sie den Pub/Sub-Senken-Connector für die folgenden Anwendungsfälle:

  • Dienstintegration, um Daten von Kafka an andere Google CloudDienste oder Anwendungen zu senden, die Daten aus Pub/Sub aufnehmen.

  • Echtzeitbenachrichtigungen oder ‑aktionen basierend auf verarbeiteten Daten auslösen.

Quell-Connectors verwenden

Quell-Connectors importieren Daten aus anderen Systemen in Kafka-Themen.

Pub/Sub-Quell-Connector verwenden

Der Pub/Sub-Quell-Connector streamt Nachrichten aus einem Pub/Sub-Abo in ein Kafka-Thema.

Verwenden Sie den Pub/Sub-Quell-Connector für die folgenden Anwendungsfälle:

  • Echtzeit-Datenaufnahme, bei der Daten aus Cloud-Diensten oder anderen Anwendungen abgerufen und zur Streamverarbeitung in Pub/Sub in Kafka veröffentlicht werden.

  • Ereignisgesteuerte Architekturen, die die Kafka-basierte Verarbeitung basierend auf in Pub/Sub veröffentlichten Ereignissen auslösen.

Richtlinie für Task-Neustart

Sie können die Richtlinie für den Neustart von Aufgaben eines Connectors festlegen, um das Verhalten bei einem Fehler zu bestimmen. Connectors unterstützen die folgenden Richtlinien:

  • Nie neu starten. Der Connector startet fehlgeschlagene Tasks nicht neu. Diese Richtlinie ist das Standardverhalten. Dies ist nützlich für das Debugging oder in Situationen, in denen nach einem Fehler ein manueller Eingriff erforderlich ist.

  • Mit exponentiellem Backoff neu starten Der Connector startet eine fehlgeschlagene Aufgabe nach einer Verzögerung (Backoff-Zeitraum) neu. Die Verzögerung erhöht sich mit jedem nachfolgenden Fehler exponentiell. Diese Richtlinie wird für die meisten Produktionsarbeitslasten empfohlen.

    Wenn Sie die Richtlinie für exponentielles Backoff verwenden, legen Sie auch Werte für das minimale und maximale Backoff fest. Der minimale Backoff sollte größer als 60 Sekunden und der maximale Backoff kleiner als 7.200 Sekunden sein.

Transformationen und Vorhersagen

Kafka Connect unterstützt die standardmäßigen Kafka-Transformationen und ‑Prädikate.

Sie geben die Konfiguration im Rahmen der Connector-Konfiguration an. Wenn Sie beispielsweise einen Sink-Connector so konfigurieren möchten, dass Nachrichten mit dem Header-Schlüssel DoNotProcess ignoriert werden, fügen Sie Ihrem Connector die folgende Konfiguration hinzu:

transforms=dropMessage
transforms.dropMessage.type=org.apache.kafka.connect.transforms.Filter
transforms.dropMessage.predicate=hasKey
predicates=hasKey
predicates.hasKey.type=org.apache.kafka.connect.transforms.predicates.HasHeaderKey
predicates.hasKey.name=DoNotProcess

Diese Konfiguration hat folgende Auswirkungen:

  1. Konfiguriert ein Prädikat mit dem Namen hasKey vom Typ org.apache.kafka.connect.transforms.predicates.HasHeaderKey. Dieses Prädikat entspricht allen Nachrichten, die einen Header mit dem Schlüssel DoNotProcess enthalten.

  2. Konfiguriert eine Transformation mit dem Namen dropMessage vom Typ org.apache.kafka.connect.transforms.Filter. Bei dieser Transformation werden alle Nachrichten verworfen, die dem konfigurierten Prädikat entsprechen.

  3. Verknüpft die Transformation mit dem Prädikat hasKey. So wird sichergestellt, dass nur Nachrichten mit dem Header-Schlüssel DoNotProcess von der Transformation verworfen werden.

Weitere Informationen finden Sie in der Kafka-Dokumentation zu Transformationen und Prädikaten.

Nächste Schritte

Apache Kafka® ist eine eingetragene Marke der Apache Software Foundation oder deren Tochtergesellschaften in den USA und/oder anderen Ländern.