Architektur und Funktionen von Tarantool Data Grid

Im Jahr 2017 gewannen wir einen Wettbewerb zur Entwicklung des Transaktionskerns des Investmentgeschäfts der Alfa-Bank und begannen unsere Arbeit (auf der HighLoad++ 2018 mit einem Bericht über den Kern des Investmentgeschäfts). durchgeführt Vladimir Drynkin, Leiter des Transaktionskerns des Investmentgeschäfts der Alfa Bank). Dieses System sollte Transaktionsdaten aus verschiedenen Quellen in verschiedenen Formaten aggregieren, die Daten in eine einheitliche Form bringen, speichern und Zugriff darauf ermöglichen.

Während des Entwicklungsprozesses entwickelte sich das System weiter und erlangte Funktionalität, und irgendwann wurde uns klar, dass wir etwas viel mehr herauskristallisierten als nur Anwendungssoftware, die zur Lösung eines streng definierten Aufgabenbereichs erstellt wurde: Es ist uns gelungen System zum Erstellen verteilter Anwendungen mit persistenter Speicherung. Die gesammelten Erfahrungen bildeten die Grundlage für ein neues Produkt - Tarantool-Datenraster (TDG).

Ich möchte über die TDG-Architektur und die Lösungen sprechen, zu denen wir während des Entwicklungsprozesses gekommen sind, Ihnen die Hauptfunktionalität vorstellen und zeigen, wie unser Produkt zur Grundlage für den Aufbau kompletter Lösungen werden kann.

Architektonisch haben wir das System in separate Teile unterteilt Rollen, von denen jeder für die Lösung einer bestimmten Reihe von Problemen verantwortlich ist. Eine einzelne laufende Anwendungsinstanz implementiert einen oder mehrere Rollentypen. In einem Cluster können mehrere Rollen desselben Typs vorhanden sein:

Anschluss

Connector ist für die Kommunikation mit der Außenwelt zuständig; Seine Aufgabe besteht darin, die Anfrage anzunehmen, sie zu analysieren und bei Erfolg die Daten zur Verarbeitung an den Eingabeprozessor zu senden. Wir unterstützen die Formate HTTP, SOAP, Kafka und FIX. Die Architektur ermöglicht es Ihnen, einfach Unterstützung für neue Formate hinzuzufügen, wobei die Unterstützung für IBM MQ in Kürze verfügbar sein wird. Wenn das Parsen der Anfrage fehlschlägt, gibt der Connector einen Fehler zurück; andernfalls antwortet er, dass die Anfrage erfolgreich bearbeitet wurde, auch wenn bei der weiteren Bearbeitung ein Fehler aufgetreten ist. Dies geschah speziell, um mit Systemen zu arbeiten, die nicht in der Lage sind, Anfragen zu wiederholen – oder dies im Gegenteil zu beharrlich tun. Um keine Daten zu verlieren, wird eine Reparaturwarteschlange verwendet: Das Objekt gelangt zuerst in diese und wird erst nach erfolgreicher Verarbeitung daraus entfernt. Der Administrator kann Benachrichtigungen über in der Reparaturwarteschlange verbleibende Objekte erhalten und es nach Behebung eines Software- oder Hardwarefehlers erneut versuchen.

Eingabeprozessor

Der Eingabeprozessor klassifiziert die empfangenen Daten nach charakteristischen Merkmalen und ruft entsprechende Prozessoren auf. Handler sind Lua-Code, der in einer Sandbox ausgeführt wird, sodass sie die Funktion des Systems nicht beeinträchtigen können. In dieser Phase können die Daten auf die erforderliche Form reduziert und bei Bedarf eine beliebige Anzahl von Aufgaben gestartet werden, die die erforderliche Logik implementieren können. Beispielsweise starten wir im MDM-Produkt (Master Data Management), das auf Tarantool Data Grid basiert, beim Hinzufügen eines neuen Benutzers die Erstellung eines Golden Record als separate Aufgabe, um die Bearbeitung der Anfrage nicht zu verlangsamen. Die Sandbox unterstützt Anfragen zum Lesen, Ändern und Hinzufügen von Daten, ermöglicht die Ausführung einiger Funktionen für alle Rollen des Speichertyps und die Aggregation des Ergebnisses (Zuordnen/Reduzieren).

Handler können in Dateien beschrieben werden:

sum.lua

local x, y = unpack(...)
return x + y

Und dann, in der Konfiguration deklariert:

functions:
  sum: { __file: sum.lua }

Warum Lua? Lua ist eine sehr einfache Sprache. Unserer Erfahrung nach beginnen die Leute ein paar Stunden nach dem Kennenlernen damit, Code zu schreiben, der ihr Problem löst. Und das sind nicht nur professionelle Entwickler, sondern beispielsweise auch Analysten. Zudem läuft Lua dank des JIT-Compilers sehr schnell.

Lagerung

Der Speicher speichert persistente Daten. Vor dem Speichern werden die Daten anhand des Datenschemas validiert. Um die Schaltung zu beschreiben, verwenden wir ein erweitertes Format Apache Avro. Beispiel:

{
    "name": "User",
    "type": "record",
    "logicalType": "Aggregate",
    "fields": [ 
        { "name": "id", "type": "string"}, 
        {"name": "first_name", "type": "string"}, 
        {"name": "last_name", "type": "string"} 
    ], 
    "indexes": ["id"] 
}

Basierend auf dieser Beschreibung wird automatisch DDL (Data Definition Language) für das Tarantula DBMS generiert und GraphQL Schema für den Datenzugriff.

Asynchrone Datenreplikation wird unterstützt (es ist geplant, eine synchrone hinzuzufügen).

Ausgabeprozessor

Manchmal ist es notwendig, externe Verbraucher über das Eintreffen neuer Daten zu informieren. Zu diesem Zweck gibt es die Rolle des Ausgabeprozessors. Nach dem Speichern der Daten können diese an den entsprechenden Handler übergeben werden (z. B. um sie in die vom Verbraucher gewünschte Form zu bringen) – und dann zum Senden an den Connector übergeben. Auch hier kommt eine Reparaturwarteschlange zum Einsatz: Wenn niemand das Objekt akzeptiert, kann der Administrator es später noch einmal versuchen.

Skalierung

Die Rollen Connector, Eingabeprozessor und Ausgabeprozessor sind zustandslos, sodass wir das System horizontal skalieren können, indem wir einfach neue Anwendungsinstanzen hinzufügen, wobei der gewünschte Rollentyp aktiviert ist. Der Speicher wird für die horizontale Skalierung verwendet Ansatz zum Organisieren eines Clusters mithilfe virtueller Buckets. Nach dem Hinzufügen eines neuen Servers werden einige der Buckets von den alten Servern im Hintergrund auf den neuen Server verschoben; Dies geschieht für den Benutzer transparent und hat keinen Einfluss auf den Betrieb des gesamten Systems.

Dateneigenschaften

Objekte können sehr groß sein und andere Objekte enthalten. Wir stellen die Atomizität des Hinzufügens und Aktualisierens von Daten sicher, indem wir ein Objekt mit allen Abhängigkeiten in einem virtuellen Bucket speichern. Dadurch wird verhindert, dass das Objekt auf mehrere physische Server „verteilt“ wird.

Versionierung wird unterstützt: Bei jeder Aktualisierung eines Objekts wird eine neue Version erstellt, und wir können jederzeit einen Zeitabschnitt betrachten und sehen, wie die Welt damals aussah. Für Daten, die keinen langen Verlauf benötigen, können wir die Anzahl der Versionen begrenzen oder sogar nur eine – die neueste – speichern, d. h. die Versionierung für einen bestimmten Typ im Wesentlichen deaktivieren. Sie können den Verlauf auch zeitlich begrenzen: Löschen Sie beispielsweise alle Objekte eines bestimmten Typs, die älter als 1 Jahr sind. Auch die Archivierung wird unterstützt: Wir können Objekte entladen, die älter als die angegebene Zeit sind, und so Speicherplatz im Cluster freigeben.

Aufgaben

Zu den interessanten Funktionen gehört die Möglichkeit, Aufgaben nach einem Zeitplan, auf Wunsch des Benutzers oder programmgesteuert aus der Sandbox zu starten:

Hier sehen wir eine andere Rolle – den Läufer. Diese Rolle ist zustandslos und bei Bedarf können dem Cluster weitere Anwendungsinstanzen mit dieser Rolle hinzugefügt werden. Die Verantwortung des Läufers besteht darin, Aufgaben zu erledigen. Wie bereits erwähnt, ist es möglich, neue Aufgaben aus der Sandbox zu generieren; Sie werden in einer Warteschlange im Speicher gespeichert und dann auf dem Läufer ausgeführt. Diese Art von Aufgabe wird Job genannt. Wir haben auch einen Aufgabentyp namens „Task“ – dabei handelt es sich um benutzerdefinierte Aufgaben, die nach einem Zeitplan (unter Verwendung der Cron-Syntax) oder bei Bedarf ausgeführt werden. Um solche Aufgaben zu starten und zu verfolgen, verfügen wir über einen praktischen Task-Manager. Damit diese Funktionalität verfügbar ist, müssen Sie die Planerrolle aktivieren; Diese Rolle hat einen Zustand und ist daher nicht skalierbar, was jedoch nicht erforderlich ist. Gleichzeitig kann es, wie bei allen anderen Rollen auch, eine Nachbildung geben, die zu funktionieren beginnt, wenn der Master sich plötzlich weigert.

Logger

Eine weitere Rolle heißt Logger. Es sammelt Protokolle von allen Mitgliedern des Clusters und bietet eine Schnittstelle zum Hochladen und Anzeigen über die Weboberfläche.

Dienstleistungen

Erwähnenswert ist, dass das System die Erstellung von Diensten erleichtert. In der Konfigurationsdatei können Sie angeben, welche Anfragen an einen vom Benutzer geschriebenen Handler gesendet werden, der in der Sandbox ausgeführt wird. In diesem Handler können Sie beispielsweise eine analytische Abfrage ausführen und das Ergebnis zurückgeben.

Der Dienst ist in der Konfigurationsdatei beschrieben:

services:
   sum:
      doc: "adds two numbers"
      function: sum
      return_type: int
      args:
         x: int
         y: int

Die GraphQL-API wird automatisch generiert und der Dienst steht zum Aufrufen zur Verfügung:

query {
   sum(x: 1, y: 2) 
}

Dadurch wird der Handler aufgerufen sumwas das Ergebnis zurückgibt:

3

Abfrageprofilierung und Metriken

Um den Betrieb des Systems und Profilierungsanfragen zu verstehen, haben wir die Unterstützung für das OpenTracing-Protokoll implementiert. Das System kann bei Bedarf Informationen an Tools senden, die dieses Protokoll unterstützen, wie z. B. Zipkin, sodass Sie nachvollziehen können, wie die Anfrage ausgeführt wurde:

Selbstverständlich stellt das System interne Metriken bereit, die mit Prometheus erfasst und mit Grafana visualisiert werden können.

Einsetzen

Tarantool Data Grid kann aus RPM-Paketen oder einem Archiv mithilfe eines Dienstprogramms aus der Distribution oder Ansible bereitgestellt werden. Es gibt auch Unterstützung für Kubernetes (Tarantool Kubernetes-Operator).

Die Anwendung, die die Geschäftslogik (Konfiguration, Handler) implementiert, wird in Form eines Archivs über die Benutzeroberfläche oder mithilfe eines Skripts über die von uns bereitgestellte API in den bereitgestellten Tarantool Data Grid-Cluster geladen.

Beispielanwendungen

Welche Anwendungen können mit Tarantool Data Grid erstellt werden? Tatsächlich hängen die meisten Geschäftsaufgaben irgendwie mit der Verarbeitung, Speicherung und dem Zugriff auf den Datenfluss zusammen. Wenn Sie also über große Datenströme verfügen, die sicher gespeichert und abgerufen werden müssen, kann Ihnen unser Produkt viel Entwicklungszeit sparen und Sie können sich auf Ihre Geschäftslogik konzentrieren.

Wir möchten beispielsweise Informationen über den Immobilienmarkt sammeln, um in Zukunft beispielsweise Informationen über die besten Angebote zu haben. In diesem Fall werden wir die folgenden Aufgaben hervorheben:

1. Roboter, die Informationen aus offenen Quellen sammeln, werden unsere Datenquellen sein. Sie können dieses Problem lösen, indem Sie vorgefertigte Lösungen verwenden oder Code in einer beliebigen Sprache schreiben.
2. Als nächstes akzeptiert und speichert Tarantool Data Grid die Daten. Wenn das Datenformat aus verschiedenen Quellen unterschiedlich ist, können Sie in Lua Code schreiben, der die Konvertierung in ein einziges Format durchführt. In der Vorverarbeitungsphase haben Sie beispielsweise auch die Möglichkeit, doppelte Angebote zu filtern oder zusätzlich Informationen über im Markt tätige Agenten in der Datenbank zu aktualisieren.
3. Jetzt haben Sie bereits eine skalierbare Lösung in einem Cluster, der mit Daten gefüllt werden kann und Datenauswahlen treffen kann. Anschließend können Sie neue Funktionen implementieren, beispielsweise einen Dienst schreiben, der Daten anfordert und das günstigste Angebot pro Tag unterbreitet. Dazu sind einige Zeilen in der Konfigurationsdatei und ein wenig Lua-Code erforderlich.

Was kommt als nächstes?

Unsere Priorität ist es, die Benutzerfreundlichkeit bei der Entwicklung zu verbessern Tarantool-Datenraster. Dies ist beispielsweise eine IDE mit Unterstützung für Profilerstellungs- und Debugging-Handler, die in einer Sandbox ausgeführt werden.

Wir legen auch großen Wert auf Sicherheitsaspekte. Derzeit durchlaufen wir die Zertifizierung durch FSTEC Russlands, um das hohe Sicherheitsniveau zu bestätigen und die Anforderungen für die Zertifizierung von Softwareprodukten zu erfüllen, die in Informationssystemen für personenbezogene Daten und Regierungsinformationssystemen verwendet werden.

Source: habr.com