Einsatz von Low-Code in Analyseplattformen

Sehr geehrte Leser, guten Tag!

Die Aufgabe, IT-Plattformen zum Speichern und Analysieren von Daten aufzubauen, stellt sich früher oder später für jedes Unternehmen, dessen Geschäftsmodell auf intellektuell anspruchsvollen Dienstleistungen oder der Entwicklung technisch komplexer Produkte basiert. Der Aufbau analytischer Plattformen ist eine anspruchsvolle und zeitintensive Aufgabe. Doch jede Herausforderung lässt sich vereinfachen. In diesem Artikel möchte ich meine Erfahrungen mit Low-Code-Tools teilen, die bei der Erstellung analytischer Lösungen hilfreich sind. Diese Erfahrungen wurden während der Umsetzung mehrerer Projekte im Bereich Big Data Solutions der Firma „Neoflex“ gesammelt. Der Bereich Big Data Solutions der Firma „Neoflex“ beschäftigt sich seit 2005 mit dem Aufbau von Datenbanken und Datenflüssen, optimiert die Geschwindigkeit der Datenverarbeitung und entwickelt Methoden zur Qualitätssicherung von Daten.

Es ist unmöglich, die bewusste Ansammlung schwach und/oder stark strukturierter Daten zu vermeiden – nicht einmal kleine Unternehmen bleiben davon verschont. Wenn ein Unternehmer sein Geschäft ausbaut, sieht er sich schnell mit Fragen zur Entwicklung von Treueprogrammen konfrontiert, möchte die Effizienz von Verkaufsstellen analysieren, denkt über gezielte Werbung nach und fragt sich nach der Nachfrage nach Begleitprodukten. Zunächst lässt sich das Problem vielleicht „im Handumdrehen“ lösen. Mit dem Wachstum des Unternehmens wird jedoch der Übergang zu einer Analyseplattform unausweichlich sein.

Wann verwandeln sich Datenanalysen in Aufgaben, die mehr wie „Raketenwissenschaft“ wirken? Wahrscheinlich dann, wenn es um wirklich große Datenmengen geht.
Um die „Raketenwissenschaft“ zu vereinfachen, kann man das Elephant-Stück für Stück essen.

Je größer die Diskretion und Autonomie Ihrer Anwendungen/Dienste/Mikrodienste ist, desto einfacher wird es für Sie, Ihre Kollegen und das gesamte Unternehmen, den Elefanten zu verdauen.

Diese Erkenntnis haben praktisch alle unsere Kunden gewonnen, die die Landschaft basierend auf den engineering Praktiken der DevOps-Teams umgestaltet haben.

Aber selbst bei einer 'getrennten, elephantengerechten' Diät haben wir ganz gute Chancen auf eine 'Überflutung' der IT-Landschaft. An diesem Punkt sollte man innehalten, tief durchatmen und einen Blick darauf werfen. Low-Code-Entwicklungsplattform.

Viele Entwickler fürchten die Aussicht auf eine Karrierefalle, wenn sie vom direkten Programmieren zum 'Drag-and-Drop' in Low-Code-Systemen übergehen. Doch die Einführung von Maschinen hat nicht zum Verschwinden von Ingenieuren geführt, sondern ihre Arbeit auf ein neues Niveau gehoben!

Lass uns herausfinden, warum.

Die Datenanalyse in den Bereichen Logistik, Telekommunikation, Medienforschung und Finanzsektor ist immer mit folgenden Fragen verbunden:

• Geschwindigkeit der automatisierten Analyse;
• Möglichkeit zur Durchführung von Experimenten, ohne den Hauptdatenproduktionsfluss zu beeinflussen;
• Zuverlässigkeit der vorbereiteten Daten;
• Aufzeichnung von Änderungen und Versionierung;
• Data Provenance, Data Lineage, CDC;
• Schnelligkeit der Bereitstellung neuer Features in der Produktionsumgebung;
• Und das berüchtigte: Kosten für Entwicklung und Unterstützung.

Das bedeutet, dass Ingenieure eine Vielzahl von hochrangigen Aufgaben haben, die nur mit ausreichend Effizienz bewältigt werden können, wenn sie ihren Geist von der niedrigstufigen Entwicklung befreien.

Die Voraussetzungen für den Übergang der Entwickler auf eine neue Ebene sind die Evolution und Digitalisierung des Geschäfts. Der Wert von Entwicklern verändert sich ebenfalls: Es gibt einen erheblichen Mangel an Entwicklern, die in der Lage sind, in die Konzepte des automatisierbaren Geschäfts einzutauchen.

Lassen Sie uns eine Analogie zwischen Low-Level- und High-Level-Programmiersprachen ziehen. Der Übergang von Low-Level- zu High-Level-Sprachen bedeutet, von 'direkten Anweisungen in Maschinensprache' hin zu 'Anweisungen in menschlicher Sprache' überzugehen. Dies führt zu einer zusätzlichen Abstraktionsebene. In diesem Sinne ist der Wechsel zu Low-Code-Plattformen von High-Level-Programmiersprachen ein Schritt von 'Anweisungen in menschlicher Sprache' hin zu 'Anweisungen in Geschäftssprache'. Wenn es Entwickler gibt, die diesen Fakt traurig macht, dann sind sie vielleicht schon seit der Einführung von JavaScript traurig, wo Array-Sortierfunktionen verwendet werden. Und diese Funktionen haben selbstverständlich unter der Haube eine Programm-Implementierung mit denselben Hochsprachen-Mitteln.

Daher ist Low-Code lediglich das Auftauchen einer weiteren Abstraktionsebene.

Praktische Erfahrungen mit Low-Code

Das Thema Low-Code ist ausreichend breit gefächert, aber jetzt möchte ich über die praktische Anwendung der 'Low-Code-Konzepte' am Beispiel eines unserer Projekte sprechen.

Die Big Data Solutions-Abteilung von „Neoflex“ hat sich hauptsächlich auf den Finanzsektor spezialisiert, indem sie Datenlager und Data Lakes erstellt und verschiedene Reporting-Prozesse automatisiert. In diesem Bereich ist die Nutzung von Low-Code längst zum Standard geworden. Unter anderen Low-Code-Tools können wir ETL-Prozesslösungen wie Informatica Power Center, IBM Datastage oder Pentaho Data Integration erwähnen. Auch Oracle Apex, das als schnelle Entwicklungsumgebung für Schnittstellen zur Datenzugriffs- und Bearbeitung dient, spielt eine wichtige Rolle. Die Verwendung von Low-Code-Entwicklungstools bedeutet jedoch nicht immer die Entwicklung von spezialisierten Anwendungen auf einem kommerziellen Technologiestack mit deutlichen Abhängigkeiten von Anbietern.

Mit Low-Code-Plattformen lassen sich auch Datenstrom-Orchestrierungen einrichten, Data-Science-Plattformen schaffen oder beispielsweise Module zur Qualitätsprüfung von Daten entwickeln.

Ein praktisches Beispiel für die Nutzung von Low-Code-Entwicklungstools ist die Zusammenarbeit zwischen «Neoflex» und der Firma Mediascope, einem der führenden Unternehmen auf dem russischen Markt für Medienforschung. Eine der Hauptaufgaben dieses Unternehmens besteht darin, Daten zu produzieren, auf deren Basis Werbetreibende, Internetplattformen, Fernsehsender, Radiostationen, Werbeagenturen und Marken Entscheidungen über den Kauf von Werbung treffen und ihre Marketingkommunikationen planen.

Media-Research ist ein technologisch anspruchsvolles Geschäftsgebiet. Die Erkennung von Videoinhalten, die Datensammlung von Analysegeräten und die Messen von Aktivitäten auf Webressourcen erfordert eine umfangreiche IT-Abteilung und beträchtliche Erfahrung in der Entwicklung analytischer Lösungen. Doch das exponentielle Wachstum von Informationen sowie die Vielfalt ihrer Quellen zwingt die IT-Datenbranche zur ständigen Weiterentwicklung. Eine einfache Möglichkeit zur Skalierung der bereits bestehenden Mediascope-Analysetools wäre eine Erhöhung des IT-Personals. Eine weit effizientere Lösung ist jedoch die Beschleunigung des Entwicklungsprozesses. Ein Schritt in diese Richtung könnte der Einsatz von Low-Code-Plattformen sein.

Zum Projektstart verfügte das Unternehmen bereits über eine funktionierende Produktlösung. Allerdings konnte die Implementierung der Lösung auf MSSQL nicht vollständig den Erwartungen in Bezug auf die Skalierbarkeit der Funktionalität bei akzeptablen Kosten für Anpassungen entsprechen.

Die vor uns liegende Aufgabe war in der Tat ehrgeizig – „Neoflex“ und Mediascope sollten innerhalb weniger als eines Jahres eine industrielle Lösung entwickeln, wobei ein MVP bereits im ersten Quartal nach Projektbeginn verfügbar sein sollte.

Als Grundlage für die Entwicklung der neuen Datenplattform, die auf Low-Code-Computing basiert, wurde der Technologie-Stack Hadoop gewählt. Der Standard für die Datenspeicherung ist HDFS in Verbindung mit Parquet-Dateiformaten. Für den Zugriff auf die in der Plattform gespeicherten Daten wurde Hive verwendet, in dem alle verfügbaren Datenansichten als externe Tabellen dargestellt werden. Der Datenimport in das Speicher wurde mithilfe von Kafka und Apache NiFi realisiert.

In diesem Konzept wurde das Low-Code-Tool zur Optimierung der aufwendigen Aufgabe beim Aufbau der Analyseplattform eingesetzt – der Datenberechnung.

Das Hauptwerkzeug für das Mapping der Daten war das Low-Code-Tool Datagram. Neoflex Datagram ist ein Tool zur Entwicklung von Transformationen und Datenströmen.
Durch die Verwendung dieses Tools kann auf das manuelle Schreiben von Scala-Code verzichtet werden. Der Scala-Code wird automatisch unter Verwendung des Model-Driven-Architecture-Ansatzes generiert.

Ein offensichtlicher Vorteil dieses Ansatzes ist die Beschleunigung des Entwicklungsprozesses. Neben der Geschwindigkeit gibt es jedoch auch weitere Vorteile:

• Einblick in den Inhalt und die Struktur von Quellen/Empfängern;
• Verfolgung der Herkunft von Datenstromobjekten bis zu einzelnen Feldern (Lineage);
• Teilweise Ausführung von Transformationen mit Einsicht in Zwischenresultate;
• Einblick in den Quellcode und dessen Anpassung vor der Ausführung;
• Automatische Validierung von Transformationen;
• Automatischer 1:1-Datenimport.

Die Einstiegshürde für Low-Code-Lösungen zur Generierung von Transformationen ist recht niedrig: Ein Entwickler muss SQL kennen und Erfahrung mit ETL-Tools haben. Dabei ist zu beachten, dass code-driven Transformationserzeuger keine ETL-Tools im weitesten Sinne des Begriffs sind. Low-Code-Tools verfügen möglicherweise nicht über eine eigene Umgebung zur Ausführung von Code. Das bedeutet, dass der generierte Code in der Umgebung ausgeführt wird, die im Cluster bereits vor der Installation der Low-Code-Lösung vorhanden war. Und das ist vielleicht ein weiterer Pluspunkt für Low-Code. Denn parallel kann ein "klassisches" Team arbeiten, das Funktionen beispielsweise in reinem Scala-Code implementiert. Die Integration von Anpassungen beider Teams in die Produktion wird einfach und "nahtlos" sein.

Es sollte auch erwähnt werden, dass es neben Low-Code auch No-Code-Lösungen gibt. Diese sind im Grunde genommen verschiedene Ansätze. Low-Code ermöglicht es Entwicklern in hohem Maße, in den generierten Code einzugreifen. Im Fall von Datagram ist es möglich, den Scala-Quellcode zu betrachten und zu bearbeiten, während No-Code möglicherweise diese Möglichkeit nicht bietet. Dieser Unterschied ist sowohl in Bezug auf die Flexibilität der Lösung als auch auf den Komfort und die Motivation der Dateningenieure von großer Bedeutung.

Architektur der Lösung

Lassen Sie uns untersuchen, wie ein Low-Code-Tool bei der Optimierung der Entwicklungsgeschwindigkeit für Datenberechnungsfunktionen helfen kann. Zuerst betrachten wir die funktionale Architektur des Systems. In diesem Fall dient das Modell der Datenproduktion für Medienforschung als Beispiel.

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

• Peoplemeter (TV-Meter) sind hardware- und softwarebasierte Geräte, die das Nutzerverhalten von Befragten in einem Fernsehpannel erfassen – wer, wann und welcher Fernsehsender im Haushalt, das an der Studie teilnimmt, geschaut wurde. Die gelieferten Informationen bestehen aus einem Strom von Betrachtungsintervallen, die an das Medienpaket und das Medienprodukt gebunden sind. Die Daten können beim Laden in den Data Lake mit demografischen Attributen, regionalen Bezügen, Zeitzonen und anderen Informationen angereichert werden, die für die Analyse des Fernsehkonsums eines bestimmten Medienprodukts erforderlich sind. Die getätigten Messungen können zur Analyse oder Planung von Werbekampagnen, zur Bewertung der Aktivität und Präferenzen der Zuschauer sowie zur Erstellung des Programmplans verwendet werden.
• Die Daten können aus Systemen zur Überwachung des Streaming-Fernsehens und zur Messung des Inhaltskonsums von Videoressourcen im Internet stammen.
• Messinstrumente in der Web-Umgebung, darunter sowohl site-zentrierte als auch nutzerzentrierte Zähler. Ein Browser-Addon, das als Research-Bar fungiert, sowie eine mobile App mit integriertem Zugang können als Datenquelle für den Data Lake dienen. VPN.
• Die Daten können auch von Plattformen stammen, die die Ergebnisse der Ausfüllung von Online-Umfragen und die Ergebnisse von Telefoninterviews in den Umfragen des Unternehmens konsolidieren;
• Eine zusätzliche Anreicherung des Data Lakes kann durch das Hochladen von Informationen aus den Logfiles der Partnerunternehmen erfolgen.

Die Implementierung des as-is-Hochladens aus Quellsystemen in das primäre Staging roher Daten kann auf verschiedene Weise organisiert werden. Bei der Verwendung von Low-Code-Lösungen ist eine automatische Generierung von Hochlade-Skripten basierend auf Metadaten möglich. Dabei ist es nicht notwendig, auf die Entwicklung von Source-to-Target-Mappings herunterzugehen. Für die Implementierung des automatischen Hochladens müssen wir eine Verbindung zur Quelle herstellen und dann im Upload-Interface die Liste der zu ladenden Entitäten festlegen. Die Erstellung der Verzeichnisstruktur in HDFS erfolgt automatisch und entspricht der Speicherstruktur im Quellsystem.

Im Rahmen dieses Projekts haben wir uns entschieden, die Low-Code-Plattform nicht zu verwenden, da das Unternehmen Mediascope bereits selbst mit der Entwicklung eines ähnlichen Dienstes auf der Basis von Nifi und Kafka begonnen hat.

Es ist wichtig zu betonen, dass diese Tools sich nicht gegenseitig ersetzen, sondern sich vielmehr ergänzen. Nifi und Kafka können sowohl in direkter (Nifi -> Kafka) als auch in umgekehrter (Kafka -> Nifi) Beziehung arbeiten. Für die Medienforschungsplattform wurde die erste Verknüpfung verwendet.

In unserem Fall musste Nifi verschiedene Datentypen aus Quellsystemen verarbeiten und an den Kafka-Broker übermitteln. Dabei wurde die Richtung der Nachrichten zu einem bestimmten Kafka-Topic mittels Nifi-Prozessoren PublishKafka gesteuert. Die Orchestrierung und Wartung dieser Pipelines erfolgt über eine visuelle Benutzeroberfläche. Das Tool Nifi und die Verwendung der Kombination Nifi + Kafka können ebenfalls als Low-Code-Ansatz in der Entwicklung bezeichnet werden, der einen niedrigen Einstieg in Big Data-Technologien ermöglicht und den Entwicklungsprozess von Anwendungen beschleunigt.

Der nächste Schritt bei der Umsetzung des Projekts bestand darin, die detaillierten Daten in ein einheitliches semantisches Format zu bringen. Wenn eine Entität historische Attribute aufweist, erfolgt die Berechnung im Kontext der betreffenden Partition. Ist die Entität jedoch nicht historisch, kann optional entweder der gesamte Inhalt des Objekts neu berechnet oder ganz auf eine Neuberechnung dieses Objekts verzichtet werden (aufgrund fehlender Änderungen). In diesem Schritt werden Schlüssel für alle Entitäten generiert. Diese Schlüssel werden in die entsprechenden Master-Objektverzeichnisse in Hbase gespeichert, die die Zuordnung zwischen den Schlüsseln in der Analyseplattform und den Schlüsseln aus den Quellsystemen enthalten. Die Konsolidierung der atomaren Entitäten erfolgt zusammen mit der Anreicherung durch die Ergebnisse der vorläufigen Berechnung der Analysedaten. Das Framework, das für die Datenberechnung verwendet wurde, war Spark. Die beschriebene Funktionalität zur Angleichung der Daten an eine einheitliche Semantik wurde ebenfalls auf der Grundlage von Low-Code-Tool-Mappings von Datagram realisiert.

In der Zielarchitektur war es notwendig, SQL-Zugang zu Daten für Geschäftsanwender zu gewährleisten. Für diese Option wurde Hive verwendet. Die Registrierung von Objekten in Hive erfolgt automatisch, wenn die Option „Registr Hive Table“ im Low-Code-Tool aktiviert wird.

Steuerung des Berechnungsflusses

Datagram verfügt über ein Interface zur Gestaltung von Workflow-Streams. Die Ausführung von Mappings kann mit dem Oozie-Planer erfolgen. Im Entwicklerinterface für Streams können Schemata für parallele, sequenzielle oder bedingte Transformationen von Daten erstellt werden. Shell-Skripte und Java-Programme werden unterstützt. Auch die Nutzung von Server Apache Livy ist möglich. Apache Livy wird verwendet, um Anwendungen direkt aus der Entwicklungsumgebung auszuführen.

Falls das Unternehmen bereits einen eigenen Prozessorchestrator hat, kann das REST API verwendet werden, um Mappings in den bestehenden Workflow zu integrieren. Zum Beispiel haben wir bereits erfolgreiche Erfahrungen mit der Integration von Mappings in Scala in Orchestratoren, die mit PLSQL und Kotlin entwickelt wurden. Das REST API des Low-Code-Tools ermöglicht Funktionen wie die Generierung eines ausführbaren Jahres basierend auf dem Design des Mappings, den Aufruf von Mappings, den Aufruf von Mappingserien und natürlich die Übergabe von URL-Parametern zur Auslösung der Mappings.

Zusätzlich zu Oozie kann der Berechnungsprozess auch mit Airflow organisiert werden. Ich werde nicht lange über den Vergleich zwischen Oozie und Airflow sprechen, sondern einfach nur sagen, dass wir im Rahmen des Medienforschungsprojekts die Entscheidung zugunsten von Airflow getroffen haben. Die Hauptargumente dafür waren die aktivere Community, die das Produkt entwickelt, sowie die ausgefeiltere Benutzeroberfläche und API.

Airflow ist besonders beliebt, da es für die Beschreibung der Berechnungsprozesse die weithin geschätzte Programmiersprache Python verwendet. Zudem gibt es nicht viele Open-Source-Plattformen für das Management von Arbeitsabläufen. Das Starten und Überwachen der Prozesse (inklusive Gantt-Diagramm) bringt Airflow noch weitere Vorteile.

Das Format der Konfigurationsdatei für die Ausführung von Low-Code-Mapping-Lösungen basiert auf spark-submit. Dies geschah aus zwei Gründen. Erstens ermöglicht spark-submit das direkte Starten einer JAR-Datei aus der Konsole. Zweitens kann es alle notwendigen Informationen zur Konfiguration des Arbeitsablaufs enthalten, was das Schreiben von Skripten zur Erstellung von DAG erleichtert.
Das am häufigsten genutzte Element des Airflow-Arbeitsablaufs in unserem Fall ist der SparkSubmitOperator.

Der SparkSubmitOperator ermöglicht das Ausführen von JAR-Dateien – verpackten Mappings von Datagrammen mit vorher definierten Eingabeparametern.

Es ist wichtig zu erwähnen, dass jede Aufgabe im Airflow in einem separaten Thread ausgeführt wird und keine Kenntnisse über andere Aufgaben hat. Daher erfolgt die Interaktion zwischen den Aufgaben über Kontrolloperatoren wie den DummyOperator oder den BranchPythonOperator.

Die Kombination der Nutzung der Low-Code-Lösung Datagram zusammen mit der Vereinheitlichung der Konfigurationsdateien (die Dag bilden) hat zu einer erheblichen Beschleunigung und Vereinfachung des Entwicklungsprozesses von Datenladeflüssen geführt.

Berechnung der Datenmärkte

Der möglicherweise intellektuell anspruchsvollste Schritt in der Erstellung von Analysedaten ist der Aufbau der Datenmärkte. Im Kontext eines der Datenberechnungsflüsse eines Forschungsunternehmens erfolgt in diesem Schritt die Anpassung an die Standardübertragung unter Berücksichtigung der Zeitzonenanpassung in Verbindung mit dem Sendeschema. Ebenso ist eine Anpassung an das lokale Sendeschema (lokale Nachrichten und Werbung) möglich. Unter anderem erfolgt in diesem Schritt die Aufteilung der kontinuierlichen Sichtungsintervalle von Medienprodukten basierend auf der Analyse dieser Sichtungsintervalle. Gleichzeitig findet eine "Abwägung" der Sichtungswerte auf Grundlage der Informationen über ihre Bedeutung statt (Berechnung des Anpassungsfaktors).

Ein entscheidender Schritt bei der Vorbereitung von Dashboards ist die Validierung der Daten. Der Validierungsalgorithmus hängt mit der Anwendung mehrerer mathematischer Modelle zusammen. Die Nutzung einer Low-Code-Plattform ermöglicht es jedoch, den komplexen Algorithmus in eine Reihe von einzelnen, visuell verständlichen Mappings zu zerlegen. Jedes Mapping erfüllt eine spezifische Aufgabe. Dadurch sind Zwischen-Debugging, Protokollierung und die Visualisierung der Datenvorbereitungsphasen möglich.

Es wurde beschlossen, den Validierungsalgorithmus in die folgenden Unterphasen zu unterteilen:

• Erstellung von Regressionsanalysen zur Abhängigkeit des Zuschauerverhaltens einer bestimmten Mediathek in der Region im Vergleich zu allen Mediatheken in der Region über einen Zeitraum von 60 Tagen.
• Berechnung der studentisierten Residuen (Abweichungen der tatsächlichen Werte von den durch das Regressionsmodell vorhergesagten Werten) für alle Regressionspunkte und für den Berechnungstag.
• Auswahl anormaler Paare von Region und Mediathek, bei denen das studentisierte Residuum des Berechnungstags die Norm (die durch die Operationseinstellungen festgelegt ist) überschreitet.
• Die Neuberechnung des adjustierten Studentenresiduals bei anomalen Paaren von Region-Netzwerk für jeden Befragten, der das Netzwerk in einer Region betrachtet hat, erfolgt unter Berücksichtigung des Beitrags dieses Befragten (die Größenordnung der Änderung des studentischen Residuals), wenn dieser Befragte aus der Stichprobe ausgeschlossen wird.
• Suche nach Kandidaten, deren Ausschluss das studentische Residual des Berechnungstags in den Normalbereich zurückführt.

Das obige Beispiel bestätigt die Hypothese, dass ein Data Engineer ohnehin zu viele Dinge im Kopf haben muss... Und wenn er wirklich ein "Engineer" und kein "Coder" ist, sollte die Angst vor beruflicher Degradierung durch die Nutzung von Low-Code-Tools endgültig verschwinden.

Was kann Low-Code noch?

Der Anwendungsbereich des Low-Code-Tools für die Batch- und Streamverarbeitung von Daten endet nicht mit der Notwendigkeit, Scala manuell zu codieren.

Der Einsatz von Low-Code bei der Entwicklung von Datalakes hat sich für uns bereits als gewisser Standard etabliert. Man könnte sagen, dass Lösungen auf Basis von Hadoop den Entwicklungsweg klassischer DWH, die auf relationalen Datenbanken basieren, nachzeichnen. Low-Code-Tools im Hadoop-Stack können sowohl zur Datenverarbeitung als auch zur Erstellung finaler BI-Schnittstellen eingesetzt werden. Dabei ist zu beachten, dass unter BI nicht nur die Datenpräsentation, sondern auch deren Bearbeitung durch Business-Nutzer verstanden werden kann. Diese Funktionalität nutzen wir häufig beim Aufbau von Analyseplattformen für den Finanzsektor.

Unter anderem ermöglicht es low-code, und insbesondere Datagram, die Herausforderung der Herkunftsverfolgung von Datenstromobjekten bis auf die Ebene einzelner Felder (lineage) zu lösen. Dazu wurde im low-code-Tool eine Integration mit Apache Atlas und Cloudera Navigator implementiert. Im Wesentlichen muss der Entwickler eine Reihe von Objekten in den Atlas-Wörterbüchern registrieren und auf die registrierten Objekte beim Erstellen von Mappings verweisen. Der Mechanismus zur Herkunftsverfolgung von Daten oder zur Analyse der Abhängigkeiten von Objekten spart eine Menge Zeit, wenn Anpassungen an Berechnungsalgorithmen erforderlich sind. Zum Beispiel ermöglicht dieses Feature beim Erstellen von Finanzberichten ein reibungsloseres Handling von Änderungen in der Gesetzgebung. Denn je besser wir die interformativen Abhängigkeiten im Hinblick auf Objekte der Detailebene verstehen, desto weniger werden wir mit „plötzlichen“ Fehlern konfrontiert und reduzieren die Anzahl der Nacharbeiten.

Datenqualität & Low-code

Eine weitere Aufgabe, die mit dem Low-Code-Tool im Projekt des Unternehmens Mediascope umgesetzt wurde, war die Aufgabe der Datenqualität. Ein herausragendes Merkmal der Implementierung der Datenprüfkette für das Projekt des Forschungsunternehmens war das Fehlen von Einfluss auf die Funktionalität und Arbeitsgeschwindigkeit des Hauptdatenverarbeitungsablaufs. Zum Orchestrieren unabhängig prüfender Datenströme wurde das bereits bekannte Apache Airflow verwendet. Während jeder Schritt der Datenverarbeitung abgeschlossen wurde, wurde parallel ein separater Teil der DQ-Pipeline gestartet.

Es gilt als gute Praxis, die Datenqualität von der Entstehung in der Analyseplattform zu überwachen. Mit Informationen über Metadaten können wir bereits beim Eingang der Informationen in die erste Schicht grundlegende Bedingungen überprüfen – nicht null, Einschränkungen, Fremdschlüssel. Diese Funktionalität basiert auf automatisch generierten Mappings der Datenqualitätsfamilie in Datagram. Die Codegenerierung stützt sich in diesem Fall ebenfalls auf die Metadaten des Modells. Im Projekt des Unternehmens Mediascope fand die Verknüpfung mit den Metadaten des Produkts Enterprise Architect statt.

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

• Überprüfung auf vorhandene "null"-Werte in Feldern mit dem Modifikator "not null";
• Überprüfung auf doppelte Primärschlüssel;
• Überprüfung des Fremdschlüssels einer Entität;
• Überprüfung der Eindeutigkeit einer Zeile anhand einer Gruppe von Feldern.

Für komplexere Prüfungen der Verfügbarkeit und Genauigkeit der Daten wurde ein Mapping mit Scala Expressions erstellt, das externen Spark SQL-Prüfcode als Eingabe akzeptiert, welcher von Analysten in Zeppelin vorbereitet wurde.

Natürlich muss die Auto-Generierung von Prüfungen schrittweise eingeführt werden. Diesem Projekt gingen die folgenden Schritte voraus:

• DQ, die in Zeppelin-Notebooks implementiert sind;
• DQ, die in das Mapping integriert sind;
• DQ in Form separater massiver Mappings, die eine vollständige Reihe von Prüfungen für eine bestimmte Entität enthalten;
• Universelle, parametrisierte DQ-Mappings, die Informationen über Metadaten und Geschäftsprüfungen als Eingabe akzeptieren.

Einer der Hauptvorteile der Erstellung eines Dienstes für parametrisierte Prüfungen ist die Verkürzung der Zeit zur Bereitstellung von Funktionen in der Produktionsumgebung. Neue Qualitätsprüfungen können das klassische Muster der Bereitstellung von Code durch Entwicklungs- und Testumgebungen umgehen.

• Alle Metadatenprüfungen werden automatisch generiert, wenn sich das Modell in EA ändert.
• Prüfungen zur Verfügbarkeit von Daten (Feststellung des Vorhandenseins von Daten zu einem bestimmten Zeitpunkt) können auf der Grundlage eines Verzeichnisses generiert werden, das den erwarteten Zeitrahmen für das Auftreten der nächsten Datenmenge in Bezug auf Objekte speichert.
• Geschäftsprüfungen zur Datenverifizierung werden von Analysten in Zeppelin-Notebooks erstellt. Diese werden direkt in die Konfigurationstabellen des DQ-Moduls in der Produktionsumgebung überführt.

Risiken durch die direkte Auslieferung von Skripten in die Produktion sind nicht vorhanden. Selbst bei einem Syntaxfehler besteht höchstens die Gefahr, dass eine Prüfung nicht ausgeführt wird, da der Datenberechnungsfluss und der Prüfungsfluss voneinander getrennt sind.

Im Grunde genommen ist der DQ-Service permanent in der Produktionsumgebung aktiv und bereit, seinen Betrieb mit der nächsten Datenlieferung aufzunehmen.

Abschließend

Die Vorteile von Low-Code sind offensichtlich. Entwickler müssen die Anwendung nicht "von Grund auf neu" erstellen. Und der entlastete Programmierer liefert schneller Ergebnisse. Diese Geschwindigkeit wiederum schafft zusätzliche Zeitressourcen zur Optimierung. Folglich kann man in diesem Fall auf qualitativ bessere und schnellere Lösungen hoffen.

Natürlich ist Low-Code keine Lösung für alles, und das Wunder wird nicht einfach geschehen:

• Die Low-Code-Branche befindet sich in einer Phase der "Stärkung", und es gibt noch keine einheitlichen industriellen Standards;
• Viele Low-Code-Lösungen sind nicht kostenlos, und ihre Anschaffung sollte ein wohlüberlegter Schritt sein, der nur bei vollständiger Gewissheit über die finanziellen Vorteile ihrer Nutzung erfolgen sollte;
• Viele Low-Code-Lösungen sind nicht immer gut mit GIT / SVN kompatibel oder unbequem zu nutzen, wenn der generierte Code verborgen ist;
• Beim Ausbau der Architektur kann es notwendig sein, das Low-Code-Tool anzupassen – was wiederum zu einer «Bindung und Abhängigkeit» vom Anbieter des Low-Code-Systems führt.
• Ein angemessenes Sicherheitsniveau ist möglich, erfordert jedoch einen hohen Aufwand und ist komplex zu implementieren bei Low-Code-Systemen. Low-Code-Plattformen sollten nicht nur nach den erwarteten Vorteilen ihrer Nutzung ausgewählt werden. Bei der Auswahl sind Fragen nach der Verfügbarkeit von Funktionen für Zugriffsverwaltung und Delegation/Eskalation von Identifikationsdaten auf die gesamte IT-Landschaft der Organisation zu berücksichtigen.

Wenn Ihnen jedoch alle Nachteile des gewählten Systems bekannt sind und die Vorteile der Nutzung dennoch überwiegen, können Sie ohne Bedenken zu Low-Code wechseln. Zumal der Übergang unvermeidlich ist – wie jede Evolution.

Wenn ein Entwickler auf einer Low-Code-Plattform seine Arbeit schneller erledigt als zwei Entwickler ohne Low-Code, verschafft dies dem Unternehmen in vielerlei Hinsicht Vorteile. Die Einstiegshürden zu Low-Code-Lösungen sind niedriger als bei 'traditionellen' Technologien, was sich positiv auf den Fachkräftemangel auswirkt. Durch den Einsatz von Low-Code-Tools kann die Zusammenarbeit zwischen funktionalen Teams beschleunigt und die Entscheidungsfindung über die Richtigkeit des gewählten Data-Science-Forschungsansatzes schneller getroffen werden. Low-Code-Plattformen können der Motor für die digitale Transformation einer Organisation sein, da die entwickelten Lösungen auch für Nicht-Techniker (insbesondere für Business-Nutzer) verständlich sind.

Wenn Sie enge Fristen, komplexe Geschäftslogik und einen Mangel an technischer Expertise haben und Ihre Markteinführungszeit beschleunigen möchten, ist Low-Code eine der Möglichkeiten, um Ihren Anforderungen gerecht zu werden.

Es ist unbestreitbar, wie wichtig traditionelle Entwicklerwerkzeuge sind, doch in vielen Fällen stellen geringcode-basierte Lösungen den effektivsten Weg dar, um die Effizienz der bewältigten Aufgaben zu steigern.

Quelle: habr.com