Apache Pulsar Technology Series – Umfangreiche DB-Datenerfassung und -sortierung basierend auf Pulsar

12,23 Yuan Chuanghui·Shanghai Station, sprechen wir über die LLM-Infrastruktur

Einführung

Apache Pulsar ist eine mandantenfähige, leistungsstarke dienstübergreifende Nachrichtenübertragungslösung, die Mandantenfähigkeit, geringe Latenz, Lese-/Schreibtrennung, überregionale Replikation, schnelle Erweiterung, flexible Fehlertoleranz und andere Funktionen unterstützt. Dieser Artikel ist ein Artikel in der Pulsar-Technologiereihe und stellt hauptsächlich die Anwendung von Pulsar im Szenario der massiven inkrementellen Datenerfassung und -sortierung von DB Binlog vor.

Vorwort

Als typischer Vertreter der nächsten Generation der Messaging-Middleware wird Pulsar häufig in Big-Data-Bereichen, Werbung, Abrechnung und anderen Szenarien eingesetzt. In diesem Artikel werden als Referenz hauptsächlich die Anwendungen von Pulsar im Bereich Big Data, die inkrementelle Datenerfassung und Sortierung von DB Binlog sowie die Verwendung und Optimierung des Pulsar Java SDK während der Verwendung beschrieben.

1. Hintergrundeinführung

Das in diesem Artikel beschriebene Szenario für die inkrementelle Datenerfassung und Sortierung von MySQL Binlog ist [Apache InLong] (https://inlong.apache.org/< a i=2>) Eine Unterfähigkeit des Systems. Sie müssen Komponenten wie DBAgent (Komponente zum Sammeln von Binlog), Sort (Komponente zum Sortieren und Lagern) und US (Planungssystem) in Apache InLong verwenden.

Abbildung 1 InLong DBAgent-Datenerfassungs- und -verarbeitungsprozess

Wie in Abbildung 1 dargestellt, ist die InLong DBAgent-Komponente (Sammeln von Binlog) in der Java-Sprache implementiert, um die Funktionen der Binlog-Synchronisierung, Binlog-Datenanalyse, Binlog-Datenfilterung, Binlog-Datenkonvertierung sowie das Senden von Daten und Indikatoren, die die Filterbedingungen erfüllen, zu vervollständigen der Pulsarhaufen.

InLong Sort (Sortierung und Lagerung) wird in der Java-Sprache implementiert, um das Abonnement von Daten aus dem Pulsar-Cluster, die Datenanalyse und -konvertierung sowie den abschließenden Data-Warehousing-Vorgang (Thive) abzuschließen.

US Runner (Planungsaufgabe) ist in der Java-Sprache implementiert. Es basiert auf der US-Planungsplattform und wird durch die Pulsar-Nachricht ausgelöst. Bevor der von der Geschäftspartei bereitgestellte Task Runner aufgerufen wird, schließt er die Überprüfung ab, um die Datenintegrität sicherzustellen , Vorabhängigkeit Überprüfen Sie den Datenerfassungsstatus, schließen Sie den Indikatordatenabgleich ab, schließen Sie den End-to-End-Abgleich ab und ergänzen Sie die End-to-End-Daten usw.

1.1. Funktionale Architektur

Abbildung 2 Übersicht über den DB-Datenerfassungs- und Sortierprozess

Wie in Abbildung 2 dargestellt, besteht im Apache InLong-System der inkrementelle Datenerfassungs- und Sortierprozess basierend auf MySQL Binlog hauptsächlich aus den folgenden Teilen:

InLong Manger: Verantwortlich für den Zugriff und die Bereitstellung der DB-Erfassungs- und Sortierkonfiguration.
InLong DBAgent: Der Knoten ist für die Ausführung bestimmter DB-Erfassungsaufgaben verantwortlich, zustandslos, hochverfügbar, unterstützt die Bereitstellung heterogener Modelle und unterstützt DB-Erfassungsaufgaben zwischen mehreren InLong DBAgents HA-Planung und Senden von Daten und Indikatoren an den entsprechenden Pulsar-Cluster.
Pulsar: ist in Daten-Cluster und Indikator-Cluster unterteilt, die bei Verwendung mit derselben Cluster-Adresse konfiguriert werden können.
InLong Sort: Verantwortlich für das Abonnieren von Sortierdaten, die Verarbeitung der Datenkonvertierung und die Lagerlogik. Unterstützt Exactly Once-Semantik und mehrere Warehousing-Senken wie Thive/Hive, Iceberg, Hbase, Clickhouse usw.
US Runner: US ist eine Planungsplattform. Der Runner bezieht sich hier auf die darauf ausgeführten Aufgaben. Derzeit unterstützt es den Indikatorabgleich und den End-to-End-Abgleich. Nur Abgleich Passes Erst dann werden die nachgelagerten Aufgaben ausgeführt, um sicherzustellen, dass die Daten unter bestimmten Qualitätssicherungsbedingungen von Benutzern verwendet werden können.

1.2. Sammelterminal basierend auf Pulsar

1.2.1 Sammlungsende-Architekturdesign

InLong DBAgent dient als Datenerfassungsende und sendet die gesammelten Daten an den Pulsar-Cluster.

InLong DBAgent ist ein zustandsloser Knoten mit Funktionen wie der Wiederaufnahme von Haltepunkten, der Erfassung mehrerer DB-Aufgaben auf einer Maschine, der HA-Planung von DB-Erfassungsaufgaben usw. Er unterstützt auch die Bereitstellung mehrerer Maschinen auf einer einzelnen Maschine und die Bereitstellung heterogener Maschinenmodelle.

Abbildung 3 DBAgent-Architekturdesign

Wie in Abbildung 3 dargestellt, werden die von InLong DBAgent synchronisierten Job-Metadateninformationen über InLong Manager verwaltet, und Benutzer konfigurieren Job-Metadaten über InLong Manager. Mehrere InLong DBAgent-Ausführungsknoten bilden einen InLong DBAgent-Cluster.

Jeder InLong DBAgent-Cluster wählt den Anführer über Zookeeper aus und generiert einen Knoten mit der Koordinatorrolle, der für die Verteilung der DB-Erfassungsjobs in diesem Cluster verantwortlich ist.

1.2.2 Produktionsdaten und Indikatoren

Abbildung 4 InLong DBAgent-Einzeljob-Daten-/Indikatorflussumkehrprozess und Zeitverbrauch jedes Teils

InLong DBAgent verarbeitet die Sammlung mehrerer Jobs gleichzeitig, wie in Abbildung 4 dargestellt. Dabei handelt es sich um den Verarbeitungsablauf eines einzelnen Jobs innerhalb von Inlong DBAgent. Verschiedene Jobs sind logisch isoliert (historische Versionen haben lange Zeit keine vollständige Isolation erreicht). (Später wird das Kapitel einige der hier genannten Probleme vorstellen), das heißt, verschiedene Jobs verwenden völlig unabhängige logische Ressourcen, wie z. B. DB-Verbindung, Daten-Pulsar-Client, Daten-Pulsar-Produzent, Indikator-Pulsar-Client, Indikator-Pulsar-Produzent und Cache, die für die Aggregation verwendet werden Während des Zwischendatentorsionsprozesses werden Threads und Warteschlangen usw. verteilt, um eine gegenseitige Beeinflussung zwischen Jobs zu vermeiden und auch die Job-HA-Planung zwischen verschiedenen InLong DBAgent-Knoten zu erleichtern.

Natürlich birgt diese Entwurfsmethode gewisse Risiken, die eine angemessene Planung während der Bereitstellung und des Betriebs erfordern. Detaillierte Erläuterungen finden Sie in den folgenden Kapiteln.

Um die Vollständigkeit der Daten sicherzustellen, unterstützt der gesamte Erfassungs- und Sortierprozess den Indikatorabgleichsprozess. Der Indikatorabgleich stellt hier sicher, dass innerhalb jeder Zeitpartition die Anzahl der Daten, die vom InLong DBAgent und dem InLong Sort-Speicher erfolgreich erfasst und an Pulsar gesendet wurden, angegeben wird write Vergleich der Gesamtdatenmenge nach Eingabe in Thive und Deduplizierung.

InLong DBAgent gewährleistet Datenintegrität und Indikatordatengenauigkeit durch Zwei-Punkt-Design.

Entwerfen Sie zunächst den Bestätigungsmechanismus der Binlog-Site. Dieser Mechanismus stellt die Kontinuität des Sammel- und Pull-Prozesses sicher und vermeidet Sammelsprungprobleme.

Jeder Job in InLong DBAgent ruft Daten ab, analysiert sie und verarbeitet die Rückwärtsverteilungslogik (einschließlich Szenarien, in denen es keine tatsächliche Rückwärtsverteilung von Daten gibt, z. B. Punkte, die übersprungen werden müssen, Bits, die durch die Heartbeat-Zeit generiert werden Logisch). Websites usw. müssen ebenfalls hinzugefügt und bestätigt werden. Wenn sie entfernt werden, werden die aktuellen Mindestpositionsinformationen aktualisiert. Danach werden die Positionsinformationen in einer Sammlung vom Typ ConcurrentSkipListSet gespeichert. Wenn die Daten werden an gesendet. Nachdem Pulsar erfolgreich war, durchläuft es den internen Website-Bestätigungsprozess. Beim Entfernen der Website aus ConcurrentSkipListSet wird die kleinste Position im aktuellen Satz durch den Sammlungs-Website-Cache aktualisiert Vergleichslogik. Diese zwischengespeicherten Informationen werden als Ort verwendet, an dem die aktuelle Sammlung abgeschlossen wird. Der Hintergrund verwendet periodische Threads, um die aktuell gesammelten Cache-Standortinformationen mit ZK zu synchronisieren und sie an InLong Manager zu melden.

Wenn der InLong DBAgent-Prozess neu gestartet wird oder die Ausführung des Jobs auf einem neuen InLong DBAgent-Knoten geplant ist, muss der Job zunächst mit den in ZK gespeicherten Standortinformationen initialisiert werden, um sicherzustellen, dass die Daten weiterhin von dem Standort abgerufen werden, an dem er zuletzt ausgeführt wurde Die Sammlung wurde abgeschlossen.

Zu beachten ist, dass Standorte asynchron aktualisiert und gespeichert werden. Daher kann es nach einem Neustart oder einer HA-Planung bei der Jobfortsetzung zu einer geringen Menge doppelter Daten kommen.

Zweitens: Entwerfen Sie einen Eins-zu-Eins-Garantiemechanismus zwischen Indikatoren und Daten. Indikatordaten werden in der Erfolgslogik der Rückrufverarbeitung generiert, nachdem die Nachrichtendaten asynchron an die Pulsar-Nachricht gesendet wurden. Sie werden regelmäßig durch Aggregationsberechnung an den Indikatorserver gesendet.

Die Prozessstopp- und Jobstoppprozesse von InLong DBAgent sind relativ geschlossen und komplex. Es muss sichergestellt werden, dass alle Abstimmungsindikatoren nach dem erfolgreichen Senden der an Pulsar gesendeten Nachricht und der neuesten Position an ZK aktualisiert werden, bevor die Anwendung oder der Job gestoppt wird. Bei anormalen Betriebsbedingungen wie Kill-9 werden doppelte Daten generiert und Indikatoren gehen verloren. In diesem Fall erfordert der Abstimmungsprozess der Partition einen manuellen Eingriff.

Die Umgebung des vorhandenen Netzwerks ist komplex, und auch die Geschäftsnutzungs- sowie Betriebs- und Wartungsszenarien sind unterschiedlich. Der Standortbestätigungsgarantiemechanismus kann Sprünge und Datenverluste nicht vollständig vermeiden. Beispielsweise löst die Sammlung während des Erfassungsprozesses aufgrund des Ausfalls der aktuell verbundenen Datenbank einen Verbindungswechsel aus und ruft Daten vom neuen DB-Knoten ab. Wenn die Binlog-Dateidaten auf diesem Knoten im Fehler gespeichert sind, d. h. Das Binlog auf dem neuen Knoten ist unvollständig oder die Sammlung Das Binlog, in dem sich der Standort befindet, wurde gelöscht. Beispielsweise kann sich der Erfassungsprozess aufgrund einer großen Datenmenge oder eines Ressourcenengpasses auf dem Erfassungscomputer verzögern, und der Erfassungsfortschritt kann nicht mit der Reinigungsgeschwindigkeit des serverseitigen Binlogs mithalten. Dies sind alles Szenarien, die während des Betriebsprozesses aufgetreten sind. Diese Situation erfordert eine rechtzeitige Entdeckung durch Überwachungsindikatoren und rechtzeitiges manuelles Eingreifen.

1.3 Sortierende basierend auf Pulsar

1.3.1 Sortieren und Architekturdesign

Am Ende der Datensortierung ist InLong Sort dafür verantwortlich, Daten aus dem Pulsar-Cluster zu abonnieren, zu deserialisieren, zu konvertieren und zu lagern.

InLong Sort wird basierend auf dem Flink-Framework implementiert. Der Implementierungsprozess umfasst viele Flink-bezogene Mechanismen und Konzepte. In diesem Artikel wird nicht zu viel beschrieben. Interessierte Studenten können die offizielle Website der Flink-Community besuchen, um relevante Erklärungen anzuzeigen.

Die Gesamtarchitektur von InLong Sort ist in Abbildung 5 dargestellt. Die gesammelten Daten werden derzeit hauptsächlich in Thive sortiert und gespeichert.

Abbildung 5 Gesamtarchitektur von InLong Sort

1.3.2 Verbrauchsdaten

InLong Sort abonniert den Datenverbrauch im Pulsar-Cluster und ist entsprechend dem Datenverarbeitungsprozess grob in vier Teile unterteilt, wie in Abbildung 6 dargestellt. Die mit Indikatoren verbundenen Operatoren werden hier nicht markiert. Natürlich gibt es einige Unterschiede zwischen den verschiedenen Speichertypen.

Abbildung 6 InLong Sort-Datenverarbeitungsablauf

InLong Sort ist eine Single-Task- (Oceanus-Task) und Multi-Dataflow-Sortieranwendung. Daher muss jeder Bediener mehrere Dataflow-Szenarien bearbeiten und die Datenflussverarbeitungsprozesse zwischen Dataflows sind logisch isoliert.

Der Quelloperator übernimmt das Parsen und Laden des Quellinformationsteils in Dataflow sowie das Abonnement und die Rückwärtsverteilung von Pulsar-Nachrichten.

Der Deserialisierungsoperator übernimmt das Parsen von MQ-Nachrichtendaten, teilt sie entsprechend der Konfiguration in verschiedene Feldinhalte auf, organisiert sie im Datensatz und verteilt sie rückwärts.

Der Sink-Operator verwaltet die Lagerlogik der Daten.

Der Commiter-Operator kümmert sich um die Übermittlungslogik eingehender Daten. Am Beispiel von Thive kümmert sich der Commiter-Teil um die Erstellung von Partitionen, die Produktion von US-Pulsar-Nachrichten usw. Der Committer-Operator ist nicht für alle Speichertypen erforderlich. Das Programm unterscheidet anhand des Bibliothekstyps, auf den zugegriffen wird.

Der gesamte Verarbeitungsablauf und das Design von InLong Sort sind relativ klar, aber die Implementierung ist relativ komplex, und auch die Implementierung von Zwischenoperatoren entwickelt sich ständig iterativ weiter. In diesem Artikel wird nicht zu viel beschrieben. Interessierte Studenten können auf verwandte Freigaben achten oder lernen Weitere Informationen finden Sie in nachfolgenden Artikeln zu verwandten Themen.

1.4. Abstimmung basierend auf der Planungsplattform

Runner ist ein Instanzkonzept, das im US-Planungssystem ausgeführt wird. Nachdem InLong Sort die Daten sortiert hat, wird die US-Plattform dazu veranlasst, den entsprechenden Runner über die Pulsar-Nachricht auszuführen. Es gibt hauptsächlich zwei verwandte Arten von Aufgaben: „Triggering“ und „Reconciliation“. Die „Trigger“-Aufgabe ist eine leere Aufgabe. Nach Erhalt der entsprechenden MQ-Nachricht startet der Verbraucher der US-Pulsar-Nachricht indirekt die „Abgleich“-Aufgabe über die „Trigger“-Aufgabe.

2. Pulsar-Anwendung

Während des gesamten Datenerfassungs- und Sortierprozesses dient Pulsar als Übertragungsstation für Daten und Indikatoren, empfängt von InLong DBAgent gemeldete Daten und erfolgreich gesendete Datenindikatoren, akzeptiert Abonnementdaten für InLong Sort-Aufgaben und empfängt Abonnementindikatordaten für DBAgent-Audit. Das Folgende ist in zwei Abschnitte unterteilt, um die Nutzungsszenarien, bestehende Probleme und Verarbeitungserfahrungen beim Sammeln und Erstellen von Pulsar-Nachrichten bzw. beim Sortieren und Verwenden von Pulsar-Daten vorzustellen.

2.1 Pulsarproduktion

2.1.1 Produktionsszenario

Aus der Einführung in das Architekturdesign von InLong DBAgent in Abschnitt 1 können wir ersehen, dass im Prozess jedes InLong DBAgent 1-N Erfassungsjobs ausgeführt werden müssen. Jeder Job ist für die Erfassung von Binlog-Daten auf einer DB-Instanz verantwortlich Jeder Job entspricht einem Pulsar. Die Clusterkonfiguration erzeugt die gesammelten Daten auf diesem Pulsar-Cluster. Jeder Job enthält mehrere Aufgaben und jede Aufgabe entspricht einem Pulsar-Thema. Dieses Thema sammelt einen Satz Bibliotheks- und Tabellendaten, die die Filterbedingungen erfüllen. Die entsprechende Beziehung bei der Umstellung auf Pulsar ist in Abbildung 7 unten dargestellt:

Abbildung 7 Pulsar SDK-Objekt, das dem Datenfluss innerhalb eines einzelnen Jobs entspricht

Es ist ersichtlich, dass das Szenario, in dem InLong DBAgent das Pulsar SDK verwendet, darin besteht, dass wir 1-M Pulsar Client-Objekte in einem einzigen Java-Prozess erstellen und verwalten müssen. Darüber hinaus muss jedes Pulsar-Client-Objekt zum Erstellen und Verwalten von 1-N Topic Producer-Objekten verwendet werden.

2.1.2 Probleme und Tuning

Für die im vorherigen Abschnitt beschriebenen Anwendungsszenarien müssen folgende Punkte berücksichtigt und bearbeitet werden:

Frage 1: Wird das Pulsar-Client-Objekt global verwaltet? Wenn mehrere Jobs dieselbe Konfiguration haben, teilen sie sich dann ein Pulsar-Client-Objekt?

In der alten Version haben wir es tatsächlich so implementiert. Dies reduziert nicht nur die Anzahl der Pulsar-Client-Objekte, sondern auch die Anzahl der Sammlungsknoten (jeder InLong DBAgent-Bereitstellungsknoten wird als Sammlungsknoten betrachtet). und der Pulsar-Cluster /span>. Anzahl der Verbindungen

Im tatsächlichen Betrieb sind jedoch die folgenden zwei Probleme aufgetreten.

Erstens ist die Datenmenge zwischen Jobs (zwischen Aufgaben innerhalb eines Jobs) unausgewogen. Einige Datenmengen können sehr groß sein, wie z. B. Flussdatentabellen, Indikatordatentabellen usw., während einige Datenmengen sehr klein sein können. Beispielsweise weisen einige Datenbanktabellen bei einigen Geschäftsaufträgen im Ausland zyklische Merkmale auf, z. B. die Stapelaktualisierung von Datentabellen jeden frühen Morgen. Wenn Sie einen Pulsar-Client gemeinsam nutzen und ein Producer-Objekt für die Produktion erstellen, weist der Datenerfassungsfortschritt zwischen Jobs unterschiedliche Größenordnungen auf, was zu einer gegenseitigen Beeinflussung führt, die schließlich zu einer großen Anzahl von Erfassungsverzögerungen führt.

Zweitens muss das System zur Gewährleistung einer hohen Verfügbarkeit der Datenerfassung in der Lage sein, Jobs zwischen mehreren InLong DBAgent-Knoten im Cluster entsprechend der Maschinenlast zu planen (d. h. Job 1 kann auf InLong DBAgent ausgeführt werden). 1 im letzten Moment und später. Es kann zu einem bestimmten Zeitpunkt geplant und auf InLong DBAgent-2 ausgeführt werden. Wenn sich mehrere Jobs den Pulsar-Client teilen, ist es notwendig, Pulsar-Client und -Produzent entsprechend den Änderungen in den gemeinsam genutzten Informationen dynamisch zu warten. Dies erhöht nicht nur die Schwierigkeit der Entwicklung und Wartung, sondern führt bei unsachgemäßer Implementierung auch zum Verlust von Client- und Produzentenobjekten. Das hinterlässt Probleme für das Programm. Verborgene Gefahr. Gleichzeitig kann das Schließen des Producer Clients auch Auswirkungen auf andere Jobs im Zwischenzustand haben oder sogar zu Datenverlust führen.

Nach einer Phase der Argumentation und Überlegung wurde während des Versionsiterationsprozesses eine Strategie der vollständigen Isolierung zwischen Jobs implementiert, d. h. jeder Job verwaltet sein eigenes Pulsar-Client-Objekt und erstellt auf der Grundlage dieses Objekts den 1-Produzenten von N Topics . Dadurch wird völlig logisch die Interaktion zwischen Jobs vermieden. Manche Leser fragen sich vielleicht: Gibt es keine Wechselwirkungen zwischen mehreren Aufgaben in einem Job? Nein, oder die Auswirkungen sind grundsätzlich vernachlässigbar. Dies liegt daran, dass jeder Job Binlog-Daten in derselben DB-Instanz sammelt und die Daten nur der Reihe nach abgerufen werden. Die Daten sind natürlich sequentiell und es treten grundsätzlich keine Probleme zwischen verschiedenen Themen auf. Darüber hinaus erleichtert die vollständige Isolation zwischen Jobs auch die Job-HA-Planung zwischen InLong DBAgent-Knoten, wodurch die Schwierigkeit der Codeentwicklung und -wartung verringert wird.

Hier gibt es noch ein weiteres Problem, das ich erwähnen muss – nämlichdie Anzahl der Verbindungen (die FD-Ressourcen belegen).

Auf jedem InLong DBAgent wird die maximale Anzahl von Jobs, die der aktuelle InLong DBAgent gleichzeitig ausführen kann, basierend auf der aktuellen Maschinenkonfiguration (dem sogenannten heterogenen Maschinenmodell) konfiguriert. Die maximale Anzahl von Verbindungen zwischen dem aktuellen Knoten und dem Pulsar-Cluster muss gemäß der folgenden Formel geschätzt werden (unter der Annahme, dass die 1-N Themenpartitionen in jedem Job alle Broker-Knoten abdecken und an diese verteilen können):

Maximale Anzahl von Verbindungen = (MaxJobsNum) * (Pre BrokerConnectNum) * (PulsarBrokerNum) * Min (MaxPartitionNum, PulsarBrokerNum)

Zum Beispiel: MaxJobsNum = 60, PreBrokerConnectNum = 2, PulsarBrokerNum = 90 Maximale Anzahl von Verbindungen = (MaxJobsNum) * (Pre BrokerConnectNum) * (PulsarBrokerNum) * Min (MaxPartitionNum, PulsarBrokerNum) = 97200

Dieser Wert ist im Verhältnis zu allgemeinen Live-Netzwerkmaschinen ein sehr großer Wert und erhöht sich mit der Zunahme der Anzahl der Broker-Knoten und der Zunahme der Anzahl der Jobs in einem einzelnen InLong DBAgent-Knoten. Bei der Live-Netzwerkbereitstellung: Während Während des Betriebs- und Wartungsprozesses müssen eine entsprechende Wertschätzung und Einsatzplanung durchgeführt werden, um groß angelegte Prozessabstürze während des Betriebsprozesses ohne Probleme in der Frühphase zu vermeiden.

Frage 2: Kann bei der Verwendung von Pulsar Producer zum Erstellen von Nachrichten zur Verbesserung der Effizienz eine Multithread-Produktion verwendet werden?

Die Antwort lautet: Ja, wir können Produktionsnachrichten über mehrere Threads verteilen. Die folgende Implementierungsmethode (Pseudocode) kann jedoch die Produktionseffizienz erheblich beeinträchtigen:

public Sender extends Thread {
    Producer prodcuer;
    Queue msgQueue;
    public Sender(Producer prodcuer,Queue msgQueue) {
	     this.prodcuer = prodcuer;
	     this.msgQueue = msgQueue;
	}
	public void run() {
	      while(true) {
		    Message msg = msgQueue.poll();
		    producer.asynSend(msg);
	      }
	}
}
.....
PulsarProducer prodcuer = new PulsarProducer();
Queue msgQueue = new Queue();
Sender sender1 = new Sender(prodcuer, msgQueue).start();
Sender sender2 = new Sender(prodcuer, msgQueue).start();

Wie im Pseudocode gezeigt, rufen mehrere Threads gleichzeitig Daten von msgQueue ab und erzeugen Pulsar-Nachrichten asynchron (oder synchron, der Effekt der Synchronisierung wird deutlicher) über denselben Produzenten. Während des Produktionsprozesses wird Pulsar SDK Das Rotationstraining zwischen mehreren Partitionen erfordert Parallelität und Sperrensteuerung (interessierte Studenten können sich die spezifische Implementierung des Producer-Teils im Pulsar SDK ansehen). Diese Art der gemeinsamen Nutzung des Producers spiegelt nicht die Vorteile des parallelen Sendens mit mehreren Threads wider Im Gegenteil, es wird die Produktionszeit verlängern und die Produktionseffizienz verringern.

Wenn für die gleichzeitige Produktion mehrere Threads erforderlich sind, muss jeder Thread sein eigenes Producer-Objekt für die Produktion verwenden. Die Verbesserungsmethode ist in der folgenden Abbildung dargestellt:

public Sender extends Thread {
    Queue msgQueue;
    public Sender(String topic ,Queue msgQueue) {
	     this.prodcuer = new Prodcuer(topic);
	     this.msgQueue = msgQueue;
	}
	public void run() {
	      while(true) {
		    Message msg = msgQueue.poll();
		    producer.asynSend(msg);
	      }
	}
}

Das Obige sind die Produktions-Pulsar-Nachrichten, die ich während der Entwicklungs-, Test- und Betriebs- und Wartungsprozesse auf der Sammlungsseite gefunden habe. Es handelt sich um zwei repräsentative Probleme. Sie können sie basierend auf Ihren eigenen Geschäftsmerkmalen heranziehen.

2.2 Pulsarverbrauch

2.2.1 Verbrauchsszenario

Wie aus der Hintergrundeinführung im ersten Abschnitt hervorgeht, wird InLong Sort basierend auf dem Flink-Framework implementiert und verwendet einen Multi-Datenfluss-Ansatz (Multi-Dataflow) für eine einzelne Aufgabe (hier bezieht sich auf die Oceanus-Aufgabe), d. h. unter Für jede Oceanus-Aufgabe werden 1-N Dataflow-Daten sortiert und in der Datenbank gespeichert. Jeder Datenfluss entspricht der Verbrauchskonfiguration eines Themas, und ein einzelner Datenfluss unterstützt das Abonnieren von Daten aus mehreren Pulsar-Clustern. Es ist ersichtlich, dass der InLong Sort-Abonnementverarbeitungsprozess dem Produktionsnachrichtenszenario von InLong DBAgent etwas ähnelt. Ein Prozess muss mehrere Pulsar-Clients basierend auf 1-N-Datenflusskonfigurationen verwalten und die entsprechenden 1-N-Themenabonnements verarbeiten.

2.2.2 Probleme und Tuning

Der Nachrichtenabonnement- und Verbrauchsteil von InLong Sort hat sich in zwei Versionen entwickelt. Im Folgenden werden die Verarbeitungsmethoden und bestehenden Probleme der ersten Version sowie die Verbesserungen der zweiten Version beschrieben.

Bevor Sie mit der Erläuterung des Nachrichtenabonnementteils beginnen, beschreiben Sie kurz einige Informationen zum Sortieren von DB-Daten durch InLong Sort. DB-Daten werden derzeit hauptsächlich in Thive gespeichert. Darunter werden Statusinformationen wie der Standort des MQ-Verbrauchsfortschritts, der Datenpartitionsstatus und die Sichtbarkeit eingehender Dateien über den Statusmechanismus von Flink verwaltet, der auf dem Checkpoint-Mechanismus von Flink basiert und regelmäßig im persistenten Speicher gespeichert wird. Gleichzeitig basiert es auf dem Checkpoint-Mechanismus, um die Sichtbarkeit von Dateibenutzern zu steuern.

Die Wartung von MQ-Verbrauchsstandorten und die Sichtbarkeitskontrolle von Dateien in Partitionen wirken sich direkt auf die Integrität der Daten aus. Wenn beispielsweise die Verbrauchsseite aktualisiert und gespeichert wurde, die vorherigen Nachrichten jedoch nicht garantiert in die Datenbank übernommen wurden, führt ein Neustart (erwarteter oder unerwarteter Neustart) zu Datenverlust. Dementsprechend werden die Daten wiederholt verbraucht und die Daten werden wiederholt in der Datenbank gespeichert, wenn bei jedem Neustart der Verbrauch vom verarbeiteten Nachrichtenspeicherort aus gestartet wird und die Datei bereits sichtbar ist, was zu Duplikaten führt. Deshalb haben diese beiden Punkte bei unserem Sortierprozess oberste Priorität.

Im Folgenden werden der Verbrauchsverarbeitungsprozess und die bestehenden Probleme der ersten Version ausführlich erläutert.

Die erste Version ähnelt der Verarbeitungsmethode von Pulsar Flink Connector und wird mit Pulsar Reader implementiert. Die ursprüngliche Absicht des Pulsar Reader-Designs besteht darin, dass jeder Leser eine Partition eines Themas abonniert, d. h. das Partitionsthema muss während der Initialisierung konfiguriert werden. Gleichzeitig wird während der Initialisierung eine zufällige, nicht persistente Verbrauchergruppe verwendet Verbrauchsprozess für Leserabonnements.

Zufällige Abonnementgruppen sind für die Überwachung während des Betriebs und der Wartung sehr unfreundlich. Bei jedem Neustart müssen Sie die überwachten Verbrauchergruppeninformationen erneut abrufen und konfigurieren. Um den Betrieb und die Wartung zu erleichtern, nutzte die erste Version eine Schwachstelle in der damaligen Pulsar Broker-Version aus (oder eine Funktion, die dem Design widersprach. Es ist schwierig zu garantieren, dass nachfolgende Versionen weiterhin vorhanden sind). Das heißt, jedem Leser wurde eine persistente Datenbank zugewiesen. Verwenden Sie die statistischen Daten des Brokers dieser persistenten Abonnementgruppe, um den Fortschritt zu überwachen.

Darüber hinaus werden während des Betriebs- und Wartungsprozesses der Sortierung häufig Speicher, Parallelität und andere Konfigurationen von Flink-Aufgaben entsprechend der Nachrichtenmenge angepasst. Einige Konfigurationsanpassungen wirken sich auf die Wiederherstellung des Status aus. Das heißt, nach einigen Konfigurationsänderungen Sie müssen sich dafür entscheiden, Checkpoint nicht zu verwenden. Die Statuswiederherstellung beginnt.

Darüber hinaus besteht während des Betriebsprozesses häufig die Notwendigkeit, aus erwarteten und unerwarteten Gründen eine Kopie der Daten wiederherzustellen. Das Ergänzen von Daten aus der Quelle erscheint etwas aufwändig und erfordert eine Konfiguration durch die Geschäftsseite. Der bequemere Weg besteht darin, die Daten der historischen Position von Pulsar erneut zu nutzen.

Fassen wir an dieser Stelle die Fähigkeiten zusammen, die wir im Sortierprozess benötigen:

Erleichtert Betrieb und Wartung zur Überwachung des Verbrauchsfortschritts;
Wenn keine Wiederherstellung von Checkpoint erfolgt, können Daten nicht verloren gehen;
Möglichkeit, Verbrauchsstandorte je nach Bedarf dynamisch zurückzusetzen

Aus der obigen Beschreibung können wir ersehen, dass die Implementierung der Reader-Methode etwas nutzlos ist. Da ist zunächst einmal das Problem der Consumer-Gruppennamen, das oben bereits ausführlich beschrieben wurde und dessen Hauptgrund darin besteht, dass die Verfügbarkeit nachfolgender Versionen nicht gewährleistet werden kann. Zweitens kann eine nicht durchgeführte Wiederherstellung von Checkpoint zum Verlust von Nachrichten führen. Wenn keine Wiederherstellung von Checkpoint erfolgt, können Sie nur wählen, ob Sie mit der Datenverarbeitung am Anfang oder an der letzten (neuen) Position beginnen möchten. Ersteres führt definitiv zu Datenduplizierung und Letzteres höchstwahrscheinlich zu Datenverlust. Drittens ist es nicht möglich, die Position nach dem Anhalten anzupassen, sondern nur während des Betriebs.

Um die potenziellen Risiken und Probleme der Reader-Methode zu lösen, wurde die zweite Version des InLong Sort-Verbrauchsteils auf die Puslar Consumer-Implementierung umgestellt.

Erstens unterstützt der Verbrauchermodus die Verwendung dauerhafter Abonnements für Verbrauchergruppen, was den Betrieb und die Wartung zur Überwachung des Verbrauchsfortschritts erleichtert. Dieser Mechanismus entspricht den Designerwartungen von Pulsar und bringt keine Kompatibilitätsprobleme mit sich. Zweitens unterstützt der Verbrauchermodus den Reset-Positionsvorgang während des Betriebs und nach dem Stoppen des Programms, und die Anwendungsszenarien sind umfangreicher. Drittens unterstützt die Consumer-Methode mehrere Abonnementmodi, nämlich Shared, Exclusive, Failover usw., und das Szenario zum Sortieren des Verbrauchs eignet sich sehr gut für die Verwendung der Exclusive-Methode.

Ähnlich wie bei der Reader-Methode müssen Sie beim Erstellen eines Consumers im Exklusivmodus in InLong Sort auch das Parititon-Thema angeben.

Warum verwendet InLong Sort insbesondere nicht den Shared-Modus, um Consumer zu erstellen? Das Wichtigste ist, die Integrität der Daten sicherzustellen.

Studierende, die mit dem Entwurfs- und Implementierungsmechanismus von Pulsar vertraut sind, wissen, dass sich das Verbrauchsmodell von Pulsar stark vom Design früherer MQs wie RockerMQ und Kafka unterscheidet. Interessierte Studierende können auf die relevanten Dokumente der Pulsar-Community verweisen. Welche Probleme treten auf, wenn Shared in InLong Sort verwendet wird?

InLong Sort ist eine Flink-Aufgabe mit den Konzepten Operatoren und Parallelität. Wenn die Quelle (der Operator des Verbrauchers, der die Pulsar-Topic-Nachricht abonniert) die Shared-Methode verwendet, um einen Verbraucher zu erstellen, werden alle für das Zielthema erstellten Verbraucher diesen konsumieren Thema. Neuigkeiten, wie kann man den Verbrauchsort speichern?

Wenn Sie den auf der Broker-Seite aufgezeichneten Speicherort verwenden, um beim Neustart mit dem Verbrauch zu beginnen, stellt dies offensichtlich ein Problem dar, da keine Garantie dafür besteht, dass die Nachricht vor diesem Speicherort während des Neustarts (normal oder unerwartet) erfolgreich in der Datenbank gespeichert wurde.

Wenn Sie beim Neustart vom Checkpoint wiederherstellen und dabei den in den entsprechenden Statusinformationen aufgezeichneten Standort verwenden, wie werden die Statusinformationen hier gespeichert? Da alle Verbraucher die Daten jedes Partitionsthemas verbrauchen, verfügt jeder Verbraucher innerhalb jedes Parallelitätsgrads über eine Ack-Verbrauchsstandortinformation. Wo fangen Sie also nach dem Neustart an? Um keine Daten zu verlieren, müssen wir alle Statusinformationen aggregieren und für jedes Partitionsthema die kleinste Position auswählen, um den Verbrauch zurückzusetzen. Dies führt unweigerlich zu Datenduplizierung. Dies erhöht nicht nur die Komplexität des Programms und die Größe des Prüfpunkts, sondern muss auch den Union State-Typ zum Speichern verwenden. Wenn die Klassendaten zu groß sind, ist dies beim Neustart sehr unfreundlich für die Aufgabe und möglicherweise sogar dazu führen, dass die Aufgabe nicht gestartet werden kann.

Das Obige ist ein Teil meiner Erfahrung in der Analyse und Verarbeitung bei der Verwendung von Pulsar im Prozess der Datensortierung. Sie können darauf zurückgreifen.

3. Zusammenfassung

In diesem Artikel wird ein Fall der inkrementellen DB-Datenerfassung von Apache InLong beschrieben. Zunächst werden die Gesamtarchitektur und einige Funktionen von InLong DBAgent, InLong Sort, US Reconciliation Runner und anderen Teilen vorgestellt. Danach konzentrierte ich mich darauf, einige Erfahrungen mit der Verwendung von Pulsar im Sammel- und Sortierprozess als Referenz für alle weiterzugeben. Die detaillierten Design- und Implementierungsdetails jeder Komponente von Apache InLong können in der Apache InLong-Community oder in Dokumenten und Kursen zu verwandten Themen geteilt werden.