🥇Verwendung von Low-Code in Analyseplattformen

Liebe Leserinnen und Leser, guten Tag!

Die Aufgabe, IT-Plattformen zum Sammeln und Analysieren von Daten aufzubauen, stellt sich früher oder später für jedes Unternehmen, dessen Geschäft auf einem intellektuell aufgeladenen Servicebereitstellungsmodell oder der Erstellung technisch komplexer Produkte basiert. Der Aufbau analytischer Plattformen ist eine komplexe und zeitaufwändige Aufgabe. Allerdings kann jede Aufgabe vereinfacht werden. In diesem Artikel möchte ich meine Erfahrungen mit der Verwendung von Low-Code-Tools zur Erstellung analytischer Lösungen teilen. Diese Erfahrung wurde bei der Umsetzung einer Reihe von Projekten im Bereich Big Data Solutions der Firma Neoflex gesammelt. Seit 2005 beschäftigt sich die Abteilung Big Data Solutions von Neoflex mit dem Aufbau von Data Warehouses und Lakes, der Lösung von Problemen der Optimierung der Geschwindigkeit der Informationsverarbeitung und der Arbeit an einer Methodik für das Datenqualitätsmanagement.

Niemand wird an der bewussten Anhäufung von schwach und/oder stark strukturierten Daten vorbeikommen. Vielleicht sogar, wenn wir über kleine Unternehmen sprechen. Denn bei der Skalierung eines Unternehmens steht ein vielversprechender Unternehmer vor der Frage der Entwicklung eines Treueprogramms, möchte die Wirksamkeit von Verkaufsstellen analysieren, denkt über gezielte Werbung nach und ist verwirrt über die Nachfrage nach begleitenden Produkten . In erster Näherung lässt sich das Problem „auf dem Knie“ lösen. Aber auch wenn das Unternehmen wächst, ist der Umstieg auf eine Analyseplattform immer noch unvermeidlich.

Doch in welchem Fall können sich Datenanalyseaufgaben zu „Rocket Science“-Unterrichtsaufgaben entwickeln? Vielleicht in dem Moment, in dem wir über wirklich große Datenmengen sprechen.
Um Rocket Science einfacher zu machen, können Sie den Elefanten Stück für Stück essen.

Je diskreter und autonomer Ihre Anwendungen/Dienste/Microservices sind, desto leichter wird es für Sie, Ihre Kollegen und das gesamte Unternehmen sein, den Elefanten zu verdauen.

Fast alle unserer Kunden kamen zu diesem Postulat, nachdem sie die Landschaft auf der Grundlage der technischen Praktiken der DevOps-Teams neu aufgebaut hatten.

Aber selbst bei einer „separaten, elefantenhaften“ Ernährung besteht eine gute Chance einer „Übersättigung“ der IT-Landschaft. In diesem Moment lohnt es sich, innezuhalten, auszuatmen und zur Seite zu schauen Low-Code-Engineering-Plattform.

Viele Entwickler haben Angst vor der Aussicht auf eine Sackgasse in ihrer Karriere, wenn sie vom direkten Schreiben von Code zum „Ziehen“ von Pfeilen in den UI-Oberflächen von Low-Code-Systemen übergehen. Doch das Aufkommen der Werkzeugmaschinen führte nicht zum Verschwinden der Ingenieure, sondern brachte ihre Arbeit auf ein neues Niveau!

Lassen Sie uns herausfinden, warum.

Datenanalysen im Bereich Logistik, Telekommunikationsindustrie, Medienforschung, Finanzsektor sind immer mit folgenden Fragestellungen verbunden:

Geschwindigkeit der automatisierten Analyse;
Fähigkeit, Experimente durchzuführen, ohne den Hauptdatenproduktionsfluss zu beeinträchtigen;
Zuverlässigkeit der aufbereiteten Daten;
Änderungsverfolgung und Versionierung;
Datenherkunft, Datenherkunft, CDC;
Schnelle Bereitstellung neuer Funktionen in der Produktionsumgebung;
Und das Berüchtigte: die Kosten für Entwicklung und Support.

Das heißt, Ingenieure haben eine große Anzahl von Aufgaben auf hoher Ebene, die nur dann mit ausreichender Effizienz erledigt werden können, wenn sie sich von Entwicklungsaufgaben auf niedriger Ebene befreien.

Die Voraussetzungen dafür, dass Entwickler auf eine neue Ebene gelangen konnten, waren die Weiterentwicklung und Digitalisierung des Geschäfts. Auch der Stellenwert des Entwicklers verändert sich: Es besteht ein erheblicher Mangel an Entwicklern, die sich in die Konzepte der Geschäftsautomatisierung vertiefen können.

Lassen Sie uns eine Analogie zu Low-Level- und High-Level-Programmiersprachen ziehen. Der Übergang von Low-Level-Sprachen zu High-Level-Sprachen ist ein Übergang vom Schreiben „direkter Anweisungen in der Sprache der Hardware“ hin zu „Anweisungen in der Sprache der Menschen“. Das heißt, es wird eine gewisse Abstraktionsebene hinzugefügt. In diesem Fall ist der Übergang von höheren Programmiersprachen zu Low-Code-Plattformen ein Übergang von „Anweisungen in der Sprache der Menschen“ hin zu „Anweisungen in der Sprache der Wirtschaft“. Wenn es Entwickler gibt, die über diese Tatsache traurig sind, dann sind sie vielleicht seit der Geburt von Java Script, das Array-Sortierfunktionen verwendet, traurig. Und diese Funktionen verfügen natürlich über eine Software-Implementierung unter der Haube mit anderen Mitteln derselben High-Level-Programmierung.

Daher ist Low-Code nur der Anschein einer weiteren Abstraktionsebene.

Angewandte Erfahrung mit Low-Code

Das Thema Low-Code ist recht breit gefächert, aber jetzt möchte ich am Beispiel eines unserer Projekte über die praktische Anwendung von „Low-Code-Konzepten“ sprechen.

Der Geschäftsbereich Big Data Solutions von Neoflex ist stärker auf den Finanzsektor spezialisiert, indem er Data Warehouses und Lakes baut und verschiedene Berichte automatisiert. In dieser Nische ist der Einsatz von Low-Code längst zum Standard geworden. Unter anderen Low-Code-Tools können wir Tools zur Organisation von ETL-Prozessen erwähnen: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Oder Oracle Apex, das als Umgebung für die schnelle Entwicklung von Schnittstellen für den Zugriff und die Bearbeitung von Daten fungiert. Der Einsatz von Low-Code-Entwicklungstools bedeutet jedoch nicht immer, dass zielgerichtete Anwendungen auf einem kommerziellen Technologie-Stack mit einer klaren Abhängigkeit vom Anbieter erstellt werden.

Mithilfe von Low-Code-Plattformen können Sie außerdem die Orchestrierung von Datenflüssen organisieren, Data-Science-Plattformen oder beispielsweise Module zur Überprüfung der Datenqualität erstellen.

Eines der angewandten Beispiele für Erfahrungen im Einsatz von Low-Code-Entwicklungstools ist die Zusammenarbeit zwischen Neoflex und Mediascope, einem der Marktführer im russischen Medienforschungsmarkt. Eines der Geschäftsziele dieses Unternehmens ist die Produktion von Daten, auf deren Grundlage Werbetreibende, Internetplattformen, TV-Sender, Radiosender, Werbeagenturen und Marken Entscheidungen über den Einkauf von Werbung treffen und ihre Marketingkommunikation planen.

Medienforschung ist ein technologisch stark belastetes Geschäftsfeld. Das Erkennen von Videosequenzen, das Sammeln von Daten von Geräten, die die Anzeige analysieren, das Messen der Aktivität auf Webressourcen – all dies setzt voraus, dass das Unternehmen über ein großes IT-Personal und enorme Erfahrung im Aufbau analytischer Lösungen verfügt. Doch das exponentielle Wachstum der Informationsmenge sowie der Anzahl und Vielfalt ihrer Quellen zwingt die IT-Datenbranche zu ständigem Fortschritt. Die einfachste Lösung zur Skalierung der bereits funktionierenden Mediascope-Analyseplattform könnte eine Aufstockung des IT-Personals sein. Eine viel effektivere Lösung besteht jedoch darin, den Entwicklungsprozess zu beschleunigen. Ein Schritt in diese Richtung könnte der Einsatz von Low-Code-Plattformen sein.

Zum Zeitpunkt des Projektstarts verfügte das Unternehmen bereits über eine funktionierende Produktlösung. Allerdings konnte die Implementierung der Lösung in MSSQL die Erwartungen an die Skalierung der Funktionalität bei akzeptablen Entwicklungskosten nicht vollständig erfüllen.

Die vor uns liegende Aufgabe war wirklich ehrgeizig: Neoflex und Mediascope mussten in weniger als einem Jahr eine industrielle Lösung entwickeln, vorausgesetzt, dass das MVP innerhalb des ersten Quartals des Startdatums veröffentlicht wird.

Als Grundlage für den Aufbau einer neuen Datenplattform auf Basis von Low-Code-Computing wurde der Hadoop-Technologie-Stack gewählt. HDFS hat sich zum Standard für die Datenspeicherung mithilfe von Parquet-Dateien entwickelt. Für den Zugriff auf die in der Plattform befindlichen Daten wurde Hive verwendet, in dem alle verfügbaren Storefronts in Form externer Tabellen dargestellt werden. Das Laden der Daten in den Speicher wurde mit Kafka und Apache NiFi implementiert.

Das Lowe-Code-Tool in diesem Konzept wurde verwendet, um die arbeitsintensivste Aufgabe beim Aufbau einer Analyseplattform zu optimieren – die Aufgabe der Datenberechnung.

Als Hauptmechanismus für die Datenzuordnung wurde das Low-Code-Datagram-Tool ausgewählt. Neoflex-Datagramm ist ein Werkzeug zur Entwicklung von Transformationen und Datenflüssen.
Mit diesem Tool können Sie auf das manuelle Schreiben von Scala-Code verzichten. Scala-Code wird mithilfe des Model Driven Architecture-Ansatzes automatisch generiert.

Ein offensichtlicher Vorteil dieses Ansatzes ist die Beschleunigung des Entwicklungsprozesses. Neben der Geschwindigkeit ergeben sich jedoch auch folgende Vorteile:

Inhalt und Struktur von Quellen/Empfängern einsehen;
Rückverfolgung der Herkunft von Datenflussobjekten auf einzelne Felder (Herkunft);
Teilweise Durchführung von Transformationen mit Sichtung von Zwischenergebnissen;
Überprüfung des Quellcodes und Anpassung vor der Ausführung;
Automatische Validierung von Transformationen;
Automatischer Daten-Download 1 in 1.

Die Hürde für den Einstieg in Low-Code-Lösungen zur Generierung von Transformationen ist recht niedrig: Der Entwickler muss SQL beherrschen und Erfahrung im Umgang mit ETL-Tools haben. Es ist erwähnenswert, dass codegesteuerte Transformationsgeneratoren keine ETL-Tools im weiteren Sinne des Wortes sind. Low-Code-Tools verfügen möglicherweise nicht über eine eigene Codeausführungsumgebung. Das heißt, der generierte Code wird in der Umgebung ausgeführt, die bereits vor der Installation der Low-Code-Lösung auf dem Cluster vorhanden war. Und das ist vielleicht ein weiterer Pluspunkt für Low-Code-Karma. Denn parallel zu einem Low-Code-Team kann ein „klassisches“ Team arbeiten, das Funktionalität beispielsweise in reinem Scala-Code umsetzt. Die Verbesserungen beider Teams in die Produktion zu übertragen, wird einfach und nahtlos sein.

Es ist vielleicht erwähnenswert, dass es neben Low-Code auch No-Code-Lösungen gibt. Und im Kern sind das verschiedene Dinge. Low-Code ermöglicht es dem Entwickler, stärker in den generierten Code einzugreifen. Im Fall von Datagram ist es möglich, den generierten Scala-Code anzuzeigen und zu bearbeiten; No-Code bietet eine solche Möglichkeit möglicherweise nicht. Dieser Unterschied ist nicht nur im Hinblick auf die Flexibilität der Lösung, sondern auch im Hinblick auf den Komfort und die Motivation bei der Arbeit von Dateningenieuren von großer Bedeutung.

Lösungsarchitektur

Versuchen wir herauszufinden, wie genau ein Low-Code-Tool dabei hilft, das Problem der Optimierung der Geschwindigkeit bei der Entwicklung von Datenberechnungsfunktionen zu lösen. Schauen wir uns zunächst die funktionale Architektur des Systems an. Ein Beispiel hierfür ist das Datenproduktionsmodell für die Medienforschung.

Die Datenquellen sind in unserem Fall sehr heterogen und vielfältig:

Personenzähler (TV-Messgeräte) sind Software- und Hardwaregeräte, die das Benutzerverhalten der Befragten im Fernsehpanel auslesen – wer, wann und welchen Fernsehsender in dem an der Studie teilnehmenden Haushalt geschaut hat. Bei den bereitgestellten Informationen handelt es sich um einen Stream von Sendeintervallen, der mit dem Medienpaket und dem Medienprodukt verknüpft ist. Daten können beim Laden in den Data Lake mit demografischen Attributen, Geostratifizierung, Zeitzone und anderen Informationen angereichert werden, die für die Analyse der Fernsehwiedergabe eines bestimmten Medienprodukts erforderlich sind. Die erfassten Messungen können zur Analyse oder Planung von Werbekampagnen, zur Beurteilung der Aktivität und Vorlieben des Publikums sowie zur Zusammenstellung des Sendenetzes genutzt werden;
Die Daten können von Überwachungssystemen zum Streamen von Fernsehsendungen und zum Messen der Anzeige von Videoressourceninhalten im Internet stammen;
Messwerkzeuge in der Webumgebung, einschließlich standortzentrierter und benutzerzentrierter Messgeräte. Der Datenanbieter für den Data Lake kann ein Browser-Add-on für die Suchleiste und eine mobile Anwendung mit integriertem VPN sein.
Daten können auch von Websites stammen, die die Ergebnisse des Ausfüllens von Online-Fragebögen und die Ergebnisse von Telefoninterviews in Unternehmensbefragungen zusammenführen;
Eine zusätzliche Anreicherung des Data Lake kann durch das Herunterladen von Informationen aus Protokollen von Partnerunternehmen erfolgen.

Die Implementierung des Ist-Ladens aus Quellsystemen in die primäre Bereitstellung von Rohdaten kann auf verschiedene Arten organisiert werden. Wird für diese Zwecke Low-Code eingesetzt, ist eine automatische Generierung von Ladeskripten auf Basis von Metadaten möglich. In diesem Fall besteht keine Notwendigkeit, auf die Ebene der Entwicklung von Quell-Ziel-Zuordnungen vorzudringen. Um das automatische Laden zu implementieren, müssen wir eine Verbindung zur Quelle herstellen und dann in der Ladeschnittstelle die Liste der zu ladenden Entitäten definieren. Die Verzeichnisstruktur in HDFS wird automatisch erstellt und entspricht der Datenspeicherstruktur auf dem Quellsystem.

Im Rahmen dieses Projekts haben wir uns jedoch entschieden, diese Funktion der Low-Code-Plattform nicht zu nutzen, da das Unternehmen Mediascope bereits unabhängig mit der Entwicklung eines ähnlichen Dienstes unter Verwendung der Kombination Nifi + Kafka begonnen hat.

Es sollte sofort darauf hingewiesen werden, dass diese Tools nicht austauschbar, sondern einander ergänzend sind. Nifi und Kafka können sowohl in direkter (Nifi -> Kafka) als auch in umgekehrter (Kafka -> Nifi) Verbindung arbeiten. Für die Medienrechercheplattform wurde die erste Version des Bundles verwendet.

In unserem Fall musste NayFi verschiedene Arten von Daten aus Quellsystemen verarbeiten und an den Kafka-Broker senden. In diesem Fall wurden Nachrichten mithilfe von PublishKafka Nifi-Prozessoren an ein bestimmtes Kafka-Thema gesendet. Die Orchestrierung und Wartung dieser Pipelines erfolgt in einer visuellen Oberfläche. Das Nifi-Tool und die Verwendung der Nifi + Kafka-Kombination können auch als Low-Code-Entwicklungsansatz bezeichnet werden, der eine niedrige Eintrittsbarriere in Big-Data-Technologien aufweist und den Anwendungsentwicklungsprozess beschleunigt.

Der nächste Schritt in der Projektumsetzung bestand darin, detaillierte Daten in ein einziges semantisches Schichtformat zu bringen. Wenn eine Entität über historische Attribute verfügt, wird die Berechnung im Kontext der betreffenden Partition durchgeführt. Wenn die Entität nicht historisch ist, besteht optional die Möglichkeit, entweder den gesamten Inhalt des Objekts neu zu berechnen oder die Neuberechnung dieses Objekts vollständig zu verweigern (aufgrund fehlender Änderungen). In dieser Phase werden Schlüssel für alle Entitäten generiert. Die Schlüssel werden in den Hbase-Verzeichnissen gespeichert, die den Masterobjekten entsprechen, die eine Entsprechung zwischen den Schlüsseln in der Analyseplattform und den Schlüsseln aus den Quellsystemen enthalten. Die Konsolidierung atomarer Einheiten geht mit der Anreicherung der Ergebnisse der vorläufigen Berechnung analytischer Daten einher. Das Framework zur Datenberechnung war Spark. Die beschriebene Funktionalität zur Zusammenführung von Daten in eine einzige Semantik wurde auch auf Basis von Mappings aus dem Low-Code-Datagram-Tool implementiert.

Die Zielarchitektur erforderte SQL-Zugriff auf Daten für Geschäftsanwender. Für diese Option wurde Hive verwendet. Objekte werden automatisch in Hive registriert, wenn Sie die Option „Hive-Tabelle registrieren“ im Low-Code-Tool aktivieren.

Berechnungsflusskontrolle

Datagram verfügt über eine Schnittstelle zum Erstellen von Workflow-Flow-Designs. Zuordnungen können mit dem Oozie-Planer gestartet werden. In der Stream-Entwickleroberfläche ist es möglich, Schemata für parallele, sequentielle oder ausführungsabhängige Datentransformationen zu erstellen. Es gibt Unterstützung für Shell-Skripte und Java-Programme. Es ist auch möglich, den Apache Livy-Server zu verwenden. Apache Livy wird verwendet, um Anwendungen direkt aus der Entwicklungsumgebung auszuführen.

Wenn das Unternehmen bereits über einen eigenen Prozess-Orchestrator verfügt, besteht die Möglichkeit, Mappings über die REST-API in einen bestehenden Ablauf einzubetten. Beispielsweise haben wir recht gute Erfahrungen mit der Einbettung von Zuordnungen in Scala in Orchestratoren gemacht, die in PLSQL und Kotlin geschrieben wurden. Die REST-API des Low-Code-Tools umfasst Vorgänge wie das Generieren eines ausführbaren Jahres basierend auf dem Mapping-Design, das Aufrufen eines Mappings, das Aufrufen einer Folge von Mappings und natürlich das Übergeben von Parametern an die URL zum Ausführen von Mappings.

Zusammen mit Oozie ist es möglich, mithilfe von Airflow einen Berechnungsablauf zu organisieren. Vielleicht werde ich nicht lange auf den Vergleich zwischen Oozie und Airflow eingehen, sondern einfach sagen, dass die Wahl im Rahmen der Arbeit an einem Medienforschungsprojekt auf Airflow gefallen ist. Die Hauptargumente waren diesmal eine aktivere Community, die das Produkt entwickelt, und eine weiter entwickelte Schnittstelle + API.

Airflow ist auch deshalb gut, weil es das beliebte Python verwendet, um Berechnungsprozesse zu beschreiben. Und im Allgemeinen gibt es nicht so viele Open-Source-Workflow-Management-Plattformen. Das Starten und Überwachen der Ausführung von Prozessen (einschließlich eines Gantt-Diagramms) erhöht das Karma von Airflow nur um Punkte.

Das Konfigurationsdateiformat zum Starten von Low-Code-Lösungszuordnungen ist Spark-Submit. Dies geschah aus zwei Gründen. Erstens können Sie mit spark-submit eine JAR-Datei direkt über die Konsole ausführen. Zweitens kann es alle notwendigen Informationen zum Konfigurieren des Workflows enthalten (was das Schreiben von Skripten erleichtert, die Dag generieren).
Das häufigste Element des Airflow-Workflows war in unserem Fall der SparkSubmitOperator.

Mit SparkSubmitOperator können Sie JARs ausführen – gepackte Datagram-Zuordnungen mit vorgenerierten Eingabeparametern dafür.

Erwähnenswert ist, dass jede Airflow-Aufgabe in einem separaten Thread ausgeführt wird und nichts über andere Aufgaben weiß. Daher erfolgt die Interaktion zwischen Aufgaben mithilfe von Steueroperatoren wie DummyOperator oder BranchPythonOperator.

Insgesamt führte der Einsatz der Datagram-Low-Code-Lösung in Verbindung mit der Universalisierung von Konfigurationsdateien (die Dag bilden) zu einer erheblichen Beschleunigung und Vereinfachung des Prozesses der Entwicklung von Datenladeflüssen.

Vorzeigeberechnungen

Der vielleicht intellektuell am stärksten beanspruchte Schritt bei der Produktion analytischer Daten ist der Schritt der Erstellung von Schaufenstern. Im Rahmen eines Datenberechnungsablaufs des Forschungsunternehmens werden in dieser Phase die Daten unter Berücksichtigung von Korrekturen für Zeitzonen auf eine Referenzsendung reduziert und mit dem Senderaster verknüpft. Eine Anpassung an das lokale Rundfunknetz (lokale Nachrichten und Werbung) ist ebenfalls möglich. In diesem Schritt werden unter anderem die Intervalle der kontinuierlichen Betrachtung von Medienprodukten anhand der Betrachtungsintervallanalyse aufgeschlüsselt. Die Betrachtungswerte werden umgehend anhand von Informationen über ihre Signifikanz „gewichtet“ (Berechnung eines Korrekturfaktors).

Ein separater Schritt bei der Vorbereitung von Showcases ist die Datenvalidierung. Der Validierungsalgorithmus umfasst die Verwendung einer Reihe mathematisch-wissenschaftlicher Modelle. Durch die Verwendung einer Low-Code-Plattform können Sie jedoch einen komplexen Algorithmus in eine Reihe separater, visuell lesbarer Zuordnungen aufteilen. Jede der Zuordnungen führt eine enge Aufgabe aus. Dadurch sind zwischenzeitliches Debuggen, Protokollieren und Visualisieren von Datenvorbereitungsphasen möglich.

Es wurde beschlossen, den Validierungsalgorithmus in die folgenden Unterstufen zu diskretisieren:

Erstellen von Regressionen der TV-Netzwerk-Anzeigeabhängigkeiten in einer Region mit der Anzeige aller Netzwerke in der Region für 60 Tage.
Berechnung studentisierter Residuen (Abweichungen der tatsächlichen Werte von den vom Regressionsmodell vorhergesagten) für alle Regressionspunkte und für den berechneten Tag.
Eine Auswahl anomaler Region-Netzwerk-Paare, bei denen der studentisierte Saldo des Abrechnungstages die Norm (durch die Betriebseinstellungen festgelegt) überschreitet.
Neuberechnung des korrigierten studentisierten Residuums für anomale Region-TV-Netzwerkpaare für jeden Befragten, der das Netzwerk in der Region gesehen hat, wobei der Beitrag dieses Befragten (der Betrag der Änderung des studentisierten Residuums) ermittelt wird, wenn das Anschauen dieses Befragten aus der Stichprobe ausgeschlossen wird .
Suchen Sie nach Kandidaten, deren Ausschluss den studentisierten Saldo des Gehalts wieder normalisiert.

Das obige Beispiel bestätigt die Hypothese, dass ein Dateningenieur bereits zu viel im Kopf hat ... Und wenn es sich wirklich um einen „Ingenieur“ und nicht um einen „Programmierer“ handelt, dann besteht die Angst vor beruflicher Verschlechterung bei der Verwendung von Low-Code-Tools muss sich endlich zurückziehen.

Was kann Low-Code noch tun?

Der Anwendungsbereich eines Low-Code-Tools für die Batch- und Stream-Datenverarbeitung, ohne dass manuell Code in Scala geschrieben werden muss, endet hier nicht.

Der Einsatz von Low-Code bei der Entwicklung von Datalake ist für uns bereits zum Standard geworden. Wir können wahrscheinlich sagen, dass auf dem Hadoop-Stack basierende Lösungen dem Entwicklungspfad klassischer DWHs auf RDBMS-Basis folgen. Low-Code-Tools auf dem Hadoop-Stack können sowohl Datenverarbeitungsaufgaben als auch die Aufgabe des Aufbaus endgültiger BI-Schnittstellen lösen. Darüber hinaus ist zu beachten, dass BI nicht nur die Darstellung von Daten, sondern auch deren Bearbeitung durch Fachanwender bedeuten kann. Wir nutzen diese Funktionalität häufig beim Aufbau von Analyseplattformen für den Finanzsektor.

Mit Low-Code und insbesondere Datagram lässt sich unter anderem das Problem lösen, die Herkunft von Datenstromobjekten mit Atomizität bis hin zu einzelnen Feldern (Lineage) zu verfolgen. Dazu implementiert das Low-Code-Tool eine Schnittstelle zu Apache Atlas und Cloudera Navigator. Im Wesentlichen muss der Entwickler eine Reihe von Objekten in Atlas-Wörterbüchern registrieren und beim Erstellen von Zuordnungen auf die registrierten Objekte verweisen. Der Mechanismus zur Verfolgung der Datenherkunft oder zur Analyse von Objektabhängigkeiten spart viel Zeit, wenn Verbesserungen an den Berechnungsalgorithmen erforderlich sind. Mit dieser Funktion können Sie beispielsweise bei der Erstellung von Jahresabschlüssen die Zeit der Gesetzesänderungen bequemer überstehen. Denn je besser wir die Inter-Form-Abhängigkeit im Kontext von Objekten einer detaillierten Ebene verstehen, desto weniger werden wir auf „plötzliche“ Fehler stoßen und die Anzahl der Nacharbeiten verringern.

Datenqualität und Low-Code

Eine weitere Aufgabe, die vom Low-Code-Tool im Mediascope-Projekt implementiert wurde, war die Klassenaufgabe „Datenqualität“. Ein besonderes Merkmal der Implementierung der Datenverifizierungspipeline für das Forschungsunternehmensprojekt war die fehlende Auswirkung auf die Leistung und Geschwindigkeit des Hauptdatenberechnungsflusses. Um unabhängige Datenverifizierungsflüsse orchestrieren zu können, wurde der bereits bekannte Apache Airflow verwendet. Als jeder Schritt der Datenproduktion fertig war, wurde parallel ein separater Teil der DQ-Pipeline gestartet.

Es gilt als bewährte Praxis, die Qualität der Daten ab dem Zeitpunkt ihrer Aufnahme in die Analyseplattform zu überwachen. Mit Informationen über Metadaten können wir die Einhaltung grundlegender Bedingungen ab dem Zeitpunkt überprüfen, an dem die Informationen in die primäre Ebene gelangen – nicht Null, Einschränkungen oder Fremdschlüssel. Diese Funktionalität wird basierend auf automatisch generierten Zuordnungen der Datenqualitätsfamilie in Datagram implementiert. Die Codegenerierung basiert auch in diesem Fall auf Modellmetadaten. Beim Mediascope-Projekt erfolgte die Schnittstelle mit den Metadaten des Produkts Enterprise Architect.

Durch die Kombination des Low-Code-Tools mit Enterprise Architect wurden automatisch folgende Prüfungen generiert:

Überprüfung auf das Vorhandensein von „Null“-Werten in Feldern mit dem Modifikator „nicht null“;
Überprüfen des Vorhandenseins von Duplikaten des Primärschlüssels;
Überprüfen des Fremdschlüssels einer Entität;
Überprüfen der Eindeutigkeit einer Zeichenfolge anhand einer Reihe von Feldern.

Für komplexere Prüfungen der Datenverfügbarkeit und -zuverlässigkeit wurde ein Mapping mit Scala Expression erstellt, das als Eingabe einen externen Spark SQL-Prüfcode verwendet, der von Analysten bei Zeppelin erstellt wurde.

Natürlich muss die automatische Generierung von Schecks schrittweise erreicht werden. Im Rahmen des beschriebenen Projektes gingen dem folgende Schritte voraus:

DQ in Zeppelin-Notebooks implementiert;
DQ in Mapping integriert;
DQ in Form separater massiver Zuordnungen, die eine ganze Reihe von Prüfungen für eine separate Entität enthalten;
Universelle parametrisierte DQ-Zuordnungen, die Informationen über Metadaten und Geschäftsprüfungen als Eingabe akzeptieren.

Der Hauptvorteil der Erstellung eines parametrisierten Prüfdienstes besteht möglicherweise in der Verkürzung der Zeit, die für die Bereitstellung der Funktionalität in der Produktionsumgebung benötigt wird. Neue Qualitätsprüfungen können das klassische Muster der indirekten Bereitstellung von Code über Entwicklungs- und Testumgebungen umgehen:

Alle Metadatenprüfungen werden automatisch generiert, wenn das Modell in EA geändert wird;
Datenverfügbarkeitsprüfungen (Bestimmung des Vorhandenseins von Daten zu einem bestimmten Zeitpunkt) können auf der Grundlage eines Verzeichnisses erstellt werden, das den erwarteten Zeitpunkt des Erscheinens des nächsten Datenelements im Kontext von Objekten speichert.
Validierungsprüfungen für Geschäftsdaten werden von Analysten in Zeppelin-Notebooks erstellt. Von dort werden sie direkt an die DQ-Modul-Setup-Tabellen in der Produktionsumgebung gesendet.

Es besteht kein Risiko, Skripte direkt an die Produktion zu senden. Selbst bei einem Syntaxfehler droht uns maximal die Nichtdurchführung einer Prüfung, da der Datenberechnungsablauf und der Startablauf der Qualitätsprüfung voneinander getrennt sind.

Im Wesentlichen läuft der DQ-Dienst permanent in der Produktionsumgebung und ist bereit, seine Arbeit zu beginnen, sobald das nächste Datenelement erscheint.

Statt einer Schlussfolgerung

Der Vorteil der Verwendung von Low-Code liegt auf der Hand. Entwickler müssen die Anwendung nicht von Grund auf neu entwickeln. Und ein von zusätzlichen Aufgaben befreiter Programmierer liefert schneller Ergebnisse. Durch die Geschwindigkeit wiederum wird zusätzliche Zeit für die Lösung von Optimierungsproblemen frei. Daher können Sie in diesem Fall mit einer besseren und schnelleren Lösung rechnen.

Natürlich ist Low-Code kein Allheilmittel und Magie wird nicht von alleine geschehen:

Die Low-Code-Branche befindet sich in einer „Stärkungsphase“ und es gibt noch keine einheitlichen Industriestandards;
Viele Low-Code-Lösungen sind nicht kostenlos und der Kauf sollte ein bewusster Schritt sein, der im vollen Vertrauen in die finanziellen Vorteile ihrer Nutzung erfolgen sollte;
Viele Low-Code-Lösungen funktionieren nicht immer gut mit GIT/SVN. Oder ihre Verwendung ist unpraktisch, wenn der generierte Code verborgen ist.
Bei der Erweiterung der Architektur kann es erforderlich sein, die Low-Code-Lösung zu verfeinern – was wiederum den Effekt einer „Anhaftung und Abhängigkeit“ beim Anbieter der Low-Code-Lösung hervorruft.
Ein ausreichendes Maß an Sicherheit ist möglich, aber sehr arbeitsintensiv und schwierig in Low-Code-System-Engines zu implementieren. Low-Code-Plattformen sollten nicht nur nach dem Grundsatz ausgewählt werden, Vorteile aus ihrer Nutzung zu ziehen. Bei der Auswahl lohnt es sich, Fragen zur Verfügbarkeit von Funktionalitäten zur Zugangskontrolle und Delegation/Eskalation von Identifikationsdaten auf die Ebene der gesamten IT-Landschaft der Organisation zu stellen.

Wenn Ihnen jedoch alle Mängel des gewählten Systems bekannt sind und die Vorteile seiner Verwendung dennoch in der überwiegenden Mehrheit liegen, dann gehen Sie ohne Angst zu kleinem Code über. Darüber hinaus ist der Übergang dorthin unvermeidlich – so wie jede Entwicklung unvermeidlich ist.

Wenn ein Entwickler auf einer Low-Code-Plattform seine Arbeit schneller erledigt als zwei Entwickler ohne Low-Code, dann verschafft das dem Unternehmen einen Vorsprung in allen Belangen. Die Einstiegshürde in Low-Code-Lösungen ist niedriger als in „klassische“ Technologien, was sich positiv auf die Personalengpässe auswirkt. Durch den Einsatz von Low-Code-Tools ist es möglich, die Interaktion zwischen Funktionsteams zu beschleunigen und schneller Entscheidungen über die Richtigkeit des gewählten Weges der datenwissenschaftlichen Forschung zu treffen. Low-Level-Plattformen können die digitale Transformation eines Unternehmens vorantreiben, da die erstellten Lösungen auch von nicht-technischen Spezialisten (insbesondere Geschäftsanwendern) verstanden werden können.

Wenn Sie knappe Fristen, eine überlastete Geschäftslogik und einen Mangel an technologischem Fachwissen haben und Ihre Markteinführungszeit verkürzen müssen, dann ist Low-Code eine Möglichkeit, Ihre Anforderungen zu erfüllen.

Die Bedeutung traditioneller Entwicklungstools lässt sich nicht leugnen, doch in vielen Fällen ist der Einsatz von Low-Code-Lösungen der beste Weg, die Effizienz der zu lösenden Aufgaben zu steigern.

Source: habr.com

Anwendung von Low-Code in Analyseplattformen