Microservice-Architektur für ETL

Question

Ich erstelle eine kleine Monolith-ETL-Software neu, die in Python geschrieben wurde. Ich finde eine Microservice-Architektur geeignet, da sie uns die Flexibilität gibt, bei Bedarf verschiedene Technologien zu verwenden (Python ist meiner Meinung nach nicht die beste Sprache für Unternehmenssoftware). Wenn wir also drei Microservices hätten (nennen wir sie Extract, Transform, Load), könnten wir in Zukunft Java for Transform Microservice verwenden.

Das Problem ist, es ist hier nicht möglich, das Ergebnis eines Serviceaufrufs in einer API-Antwort (sagen wir HTTP) zu übergeben. Die Ausgabe von Extract wird Gigabytes an Daten sein.

Eine Idee besteht darin, Extract aufzurufen und die Ergebnisse in einer Datenbank speichern zu lassen (was wirklich das ist, was das Modul im Monolith macht, also einfach zu implementieren). In diesem Fall gibt der Dienst nur eine Ja/Nein-Antwort zurück (war der Prozess erfolgreich oder nicht).

Ich fragte mich, ob es eine bessere Möglichkeit gäbe, sich dem zu nähern. Was wäre eine bessere Architektur? Ist das, was ich vorschlage, vernünftig?

Answer 1

Dies ist ein interessantes Problem. Die beste Lösung hierfür könnte Reactive Spring Boot sein. Sie können den Extract-Dienst als Reactive Spring Boot-App verwenden und statt der Übertragung von GB Daten die Daten an den erforderlichen Dienst streamen.

Jetzt wundern Sie sich vielleicht, dass während des Streamings, könnte es auf dem Arbeitsfaden halten. Die Antwort ist nein. IT arbeitet auf Betriebssystemebene. Es hält keine Anfrage Thread zum Streamen der Ergebnisse. Das ist die Schönheit des Reactive Spring Boot.

gehen durch diese und
https://spring.io/blog/2016/07/28/reactive-programming-with-spring-5-0-m1

Answer 2

erkunden Wenn Ihr ETL-Prozess auf einzelne Datensätze (einige parallelize-fähige Einheiten Berechnung) funktioniert, dann gibt es eine Menge von Optionen, die Sie mit gehen könnte, sind hier ein paar :

Messaging System-basierte

Sie Ihre Verarbeitung um ein Messaging-System stützen könnten, wie Apache Kafka. Es erfordert eine sorgfältige Konfiguration und Konfiguration (abhängig von den Anforderungen an Haltbarkeit, Verfügbarkeit und Skalierbarkeit Ihrer spezifischen Anwendungsfälle), kann Ihnen jedoch eine bessere Anpassung als eine relationale Datenbank bieten.

In diesem Fall würden die ETL-Schritte völlig unabhängig arbeiten und nur einige Themen verbrauchen, in einigen anderen Themen produzieren. Diese anderen Themen werden dann von dem nächsten Schritt usw. aufgenommen. Es würde keine direkte Kommunikation (Anrufe) zwischen den E/T/L-Schritten geben.

Es ist eine saubere und leicht verständliche Lösung mit unabhängigen Komponenten.

Off-the-shelf-Verarbeitungslösungen

Es gibt ein paar OTS-Lösungen für die Datenverarbeitung/Berechnung und Transformation: Apache Flink, Apache Storm, Apache Spark.

Obwohl diese Lösungen Sie offensichtlich auf eine bestimmte Technologie beschränken würden, könnten sie besser sein, als ein ähnliches System von Grund auf neu aufzubauen.

Nicht persistente

Wenn die aktuellen Daten-Streaming/Rekord-basiert, und es ist nicht die Ergebnisse zwischen den Schritten bestehen bleibt erforderlich, konnten Sie nur mit Lang Abfrage der HTTP-Ausgabe des wegkommen vorheriger Schritt.

Sie sagen, dass es einfach zu viele Daten, aber dass Daten nicht in die Datenbank zu gehen (wenn es nicht erforderlich ist), und konnten nur statt, um zum nächsten Schritt gehen. Wenn die Daten kontinuierlich (nicht alles in einem Stapel) im selben lokalen Netzwerk produziert werden, halte ich das nicht für ein Problem.

Dies wäre technisch sehr einfach zu tun, sehr einfach zu validieren und zu überwachen.