Einsatz von Low-Code in Analyseplattformen

Sehr geehrte Leser, guten Tag!

Die Aufgabe zum Aufbau von IT-Plattformen zur Speicherung und Analyse von Daten stellt sich früher oder später für jedes Unternehmen, dessen Geschäft auf einem intellektuell belasteten Modell der Dienstleistungserbringung oder der Schaffung technisch anspruchsvoller Produkte basiert. Der Aufbau von Analyseplattformen ist eine komplexe und arbeitsintensive Aufgabe. Allerdings kann jede Aufgabe vereinfacht werden. In diesem Artikel möchte ich meine Erfahrungen mit Low-Code-Tools teilen, die bei der Erstellung von analytischen Lösungen helfen. Diese Erfahrungen wurden bei der Umsetzung mehrerer Projekte im Bereich Big Data Solutions der Firma "Neoflex" gesammelt. Das Big Data Solutions-Team der Firma "Neoflex" beschäftigt sich seit 2005 mit Fragen des Aufbaus von Data Warehouses und Data Lakes, löst Aufgaben zur Optimierung der Geschwindigkeit der Datenverarbeitung und arbeitet an Methoden zur Verwaltung der Datenqualität.

Es wird niemandem gelingen, das bewusste Ansammeln von schwach und/oder stark strukturierten Daten zu vermeiden. Vielleicht sogar nicht einmal im kleinen Unternehmensbereich. Denn beim Wachstum eines Unternehmens wird ein vielversprechender Unternehmer mit Fragen zur Entwicklung von Treueprogrammen konfrontiert, möchte die Effektivität von Verkaufsstellen analysieren, denkt über gezielte Werbung nach und fragt sich nach der Nachfrage nach Begleitprodukten. In der ersten Annäherung kann die Aufgabe "händisch" gelöst werden. Doch mit dem Wachstum des Unternehmens ist der Übergang zu einer Analyseplattform unvermeidlich.

Aber wann können die Aufgaben der Datenanalyse in Aufgaben der Klasse "Rocket Science" übergehen? Vielleicht genau dann, wenn es um wirklich große Datenmengen geht.
Um die Aufgabe "Rocket Science" zu vereinfachen, kann man den Elefanten stückweise essen.

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

Zu dieser Erkenntnis sind fast alle unsere Kunden gelangt, die die Landschaft auf der Grundlage der Ingenieurpraktiken von DevOps-Teams neu gestaltet haben.

Aber selbst bei einer "getrennten, elefantenhaften" Diät haben wir gute Chancen auf eine "Überversorgung" der IT-Landschaft. In diesem Moment sollte man innehalten, durchatmen und in Richtung schauen Low-Code-Engineering-Plattform.

Viele Entwickler haben Angst vor der Aussicht auf eine Sackgasse in ihrer Karriere, wenn sie vom direkten Programmieren zum „Ziehen“ von Pfeilen in den UI-Schnittstellen von Low-Code-Systemen wechseln. Aber die Einführung von Maschinen hat nicht zum Verschwinden von Ingenieuren geführt, sondern deren Arbeit auf ein neues Niveau gehoben!

Lassen Sie uns herausfinden, warum.

Die Datenanalyse im Bereich Logistik, Telekommunikationsindustrie, in der Medienforschung und im Finanzsektor ist immer mit den folgenden Fragen verbunden:

• Geschwindigkeit der automatisierten Analyse;
• Die Möglichkeit, Experimente durchzuführen, ohne den Hauptdatenstrom zu beeinflussen;
• Zuverlässigkeit der vorbereiteten Daten;
• Nachverfolgung von Änderungen und Versionierung;
• Data Provenance, Data Lineage, CDC;
• Schnelligkeit der Bereitstellung neuer Funktionen in der Produktionsumgebung;
• Und das allseits bekannte: die Kosten für Entwicklung und Wartung.

Das heißt, Ingenieure haben eine Vielzahl von hochrangigen Aufgaben, die mit ausreichender Effizienz nur bewältigt werden können, wenn sie ihren Geist von niedrigstufigen Entwicklungsaufgaben befreien.

Die Voraussetzungen für den Wechsel der Entwickler auf eine neue Ebene waren die Evolution und Digitalisierung von Unternehmen. Auch der Wert des Entwicklers verändert sich: Es gibt einen erheblichen Mangel an Entwicklern, die in der Lage sind, in die Essenz der zu automatisierenden Geschäftsmodelle einzutauchen.

Lassen Sie uns eine Analogie zu niedrigstufigen und hochgestuften Programmiersprachen ziehen. Der Übergang von niedrigstufigen zu hochstufigen Sprachen ist der Wechsel von der Erstellung „direkter Anweisungen in Maschinensprache“ hin zu „Anweisungen in menschenverständlicher Sprache“. Das heißt, es wird eine gewisse Ebene der Abstraktion hinzugefügt. In diesem Fall ist der Übergang zu Low-Code-Plattformen von hochstufigen Programmiersprachen der Übergang von „Anweisungen in menschenverständlicher Sprache“ hin zu „Anweisungen in Geschäftssprache“. Sollten es Entwickler geben, die sich darüber traurig fühlen, dann sind sie vielleicht schon seit der Einführung von JavaScript traurig, in dem Sortierfunktionen für Arrays verwendet werden. Und diese Funktionen verfügen natürlich über eine programmatische Implementierung durch andere Mittel der selben hochstufigen Programmierung.

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

Praktische Erfahrungen mit der Verwendung von Low-Code

Das Thema Low-Code ist ziemlich umfangreich, aber jetzt möchte ich über die praktische Anwendung von "Low-Code-Konzepten" anhand eines unserer Projekte berichten.

Die Abteilung Big Data Solutions des Unternehmens "Neoflex" spezialisiert sich hauptsächlich auf den Finanzsektor und baut Datenlager und Data Lakes, während sie verschiedene Berichterstattung automatisiert. In diesem Bereich ist die Anwendung von Low-Code seit langem zum Standard geworden. Unter anderen Low-Code-Tools können Lösungen zur Organisation von ETL-Prozessen erwähnt werden: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Oder Oracle Apex, das als Umgebung für die schnelle Entwicklung von Zugangs- und Bearbeitungsschnittstellen dient. Die Anwendung von Low-Code-Entwicklungsmitteln ist jedoch nicht immer mit dem Bau von spezialisierten Anwendungen auf kommerziellen Technologiestacks verbunden, die eine klare Abhängigkeit vom Anbieter aufweisen.

Mit Low-Code-Plattformen können auch Datenfluss-Orchestrierung, Data-Science-Plattformen oder beispielsweise Module zur Qualitätssicherung von Daten erstellt werden.

Ein praktisches Beispiel für die Erfahrung mit der Nutzung von Low-Code-Entwicklungsmitteln ist die Zusammenarbeit von "Neoflex" mit dem Unternehmen Mediascope, einem der Marktführer in der russischen Medienforschung. Eine der Herausforderungen für das Geschäft 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 Marketingkommunikation planen.

Medienforschung ist ein technologieintensiver Bereich der Wirtschaft. Die Erkennung von Videoinhalten, die Datensammlung von Geräten, die das Sehen analysieren, die Messung der Aktivität auf Webressourcen – all dies erfordert von einem Unternehmen eine große IT-Abteilung und enormous Erfahrung im Aufbau analytischer Lösungen. Doch das exponentielle Wachstum der Menge an Informationen, der Anzahl und Vielfalt ihrer Quellen zwingt die IT-Datenindustrie, ständig Fortschritte zu machen. Die einfachste Lösung zur Skalierung der bereits funktionierenden Analyseplattform Mediascope könnte die Aufstockung des IT-Personals sein. Doch eine weitaus effektivere Lösung ist die Beschleunigung des Entwicklungsprozesses. Ein Schritt in diese Richtung könnte die Verwendung von Low-Code-Plattformen sein.

Zum Zeitpunkt des Projektstarts verfügte das Unternehmen bereits über eine funktionierende Produktlösung. Die Implementierung der Lösung auf MSSQL konnte jedoch nicht vollständig den Erwartungen an die Skalierung der Funktionalitäten bei gleichzeitiger Beibehaltung akzeptabler Kosten für Anpassungen entsprechen.

Die vor uns stehende Aufgabe war wahrhaftig ambitioniert – Neoflex und Mediascope sollten innerhalb von weniger als einem Jahr eine industrietaugliche Lösung erstellen, wobei die Veröffentlichung eines MVP bereits im ersten Quartal nach Beginn der Arbeiten erfolgen sollte.

Als Grundlage für den Aufbau der neuen Datenplattform, die auf Low-Code-Berechnungen basiert, wurde der Technologie-Stack Hadoop ausgewählt. Der Standard für die Datenspeicherung wurde HDFS unter Verwendung von Parquet-Dateiformaten. Für den Zugriff auf die in der Plattform befindlichen Daten wurde Hive verwendet, in dem alle verfügbaren Datenlager als externe Tabellen dargestellt sind. Der Datenimport in das Speicher wurde mit Hilfe von Kafka und Apache NiFi realisiert.

Das Low-Code-Tool in diesem Konzept wurde eingesetzt, um die arbeitsaufwendigsten Aufgaben beim Aufbau der Analyseplattform – die Berechnung von Daten – zu optimieren.

Als Hauptmechanismus für das Mapping von Daten wurde das Low-Code-Tool Datagram ausgewählt. Neoflex Datagram ist ein Werkzeug zur Entwicklung von Transformationen und Datenströmen.
Mit diesem Werkzeug 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. Aber neben der Geschwindigkeit gibt es noch weitere Vorteile:

• Anzeige des Inhalts und der Struktur von Quellen/Zielsystemen;
• Verfolgung des Ursprungs von Objekten im Datenstrom bis hin zu einzelnen Feldern (Lineage);
• Teilergebnisse von Transformationen mit Zwischenresultaten anzeigen;
• Quellcode einsehen und vor der Ausführung anpassen;
• Automatische Validierung der Transformationen;
• Automatische Datenübertragung 1 zu 1.

Die Einstiegshürde in Low-Code-Lösungen zur Generierung von Transformationen ist relativ niedrig: Ein Entwickler muss SQL kennen und Erfahrung mit ETL-Tools haben. Dabei ist zu erwähnen, dass code-driven Transformationserzeuger keine ETL-Tools im weitesten Sinne des Wortes sind. Low-Code-Tools können möglicherweise keine eigene Umgebung zur Ausführung des Codes haben. Das bedeutet, dass der generierte Code in der Umgebung ausgeführt wird, die im Cluster vor der Installation der Low-Code-Lösung vorhanden war. Das ist, denk ich, ein weiterer Pluspunkt für Low-Code. Denn parallel zur Low-Code-Team kann ein „klassisches“ Team arbeiten, das die Funktionalität beispielsweise in reinem Scala-Code umsetzt. Die Integration von Ergänzungen beider Teams in die Produktion wird einfach und „nahtlos“ sein.

Es ist auch wichtig zu erwähnen, dass es neben Low-Code auch No-Code-Lösungen gibt. Im Kern sind das unterschiedliche Dinge. Low-Code ermöglicht es dem Entwickler in größerem Maße, in den generierten Code einzugreifen. Im Falle von Datagram ist eine Einsichtnahme und Bearbeitung des generierten Scala-Codes möglich, während No-Code diese Möglichkeit möglicherweise nicht bietet. Dieser Unterschied ist nicht nur hinsichtlich der Flexibilität der Lösung, sondern auch im Hinblick auf den Komfort und die Motivation der Dateningenieure erheblich.

Architektur der Lösung

Lass uns versuchen zu verstehen, wie genau ein Low-Code-Werkzeug dabei hilft, die Aufgabe der Optimierung der Geschwindigkeit bei der Entwicklung von Datenberechnungsfunktionen zu lösen. Zunächst betrachten wir die funktionale Architektur des Systems. In diesem Fall ist ein Beispiel das Modell der Datenproduktion für Medienforschungen.

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

• Peoplemeter (TV-Meter) sind programmiertechnische Geräte, die das Benutzerverhalten von Befragten in einem Fernsehpaneel aufzeichnen – wer, wann und welchen Fernsehsender im Haushalt gesehen hat, der an der Untersuchung teilnimmt. Die bereitgestellten Informationen sind ein Stream von Sehintervallen im Äther, verknüpft mit dem Medienpaket und dem Medienprodukt. Die Daten können in der Phase der Übertragung in den Data Lake mit demografischen Attributen, Verbindungen zu Geo-Standorten, Zeitzonen und anderen Informationen angereichert werden, die für die Analyse des Fernsehkonsums eines bestimmten Medienprodukts erforderlich sind. Die durchgeführten Messungen können zur Analyse oder Planung von Werbekampagnen, zur Bewertung der Aktivität und Vorlieben der Zielgruppe sowie zur Erstellung des Sendplans verwendet werden;
• Die Daten können aus Systemen zur Überwachung von Streaming-TV-Übertragungen und zur Messung des Konsums von Inhalten auf Videoressourcen im Internet stammen;
• Messinstrumente im Web, darunter sowohl site-zentrierte als auch nutzerzentrierte Zähler. Der Datenlieferant für den Data Lake kann eine Browsererweiterung namens research bar sowie eine mobile Anwendung mit integriertem 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 Meinungsforschungsstudien des Unternehmens konsolidieren;
• Zusätzliche Anreicherung des Datenpools kann durch den Upload von Informationen aus den Logs von Partnerunternehmen erfolgen.

Die Implementierung des as is-Uploads aus den Quellsystemen in das primäre Staging der Rohdaten kann auf verschiedene Weise organisiert werden. Bei Verwendung von Low-Code zu diesem Zweck ist die automatische Generierung von Upload-Szenarien auf der Grundlage von Metadaten möglich. Dabei ist es nicht erforderlich, auf die Ebene der Entwicklung von Source-to-Target-Mappings zu gehen. Um den automatischen Upload zu realisieren, müssen wir eine Verbindung zur Quelle herstellen und anschließend im Upload-Interface eine Liste der zu ladenden Entitäten definieren. Die Erstellung der Verzeichnisstruktur im HDFS erfolgt automatisch und entspricht der Datenstruktur im Quellsystem.

Im Kontext dieses Projekts haben wir uns jedoch entschieden, diese Möglichkeit der Low-Code-Plattform nicht zu nutzen, da das Unternehmen Mediascope bereits eigenständig an der Entwicklung eines ähnlichen Dienstes mit Nifi + Kafka arbeitet.

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) Verbindung arbeiten. Für die Plattform der Medienforschung wurde die erste Variante verwendet.

In unserem Fall musste Nifi verschiedene Datentypen aus den Quellsystemen verarbeiten und an den Kafka-Broker weiterleiten. Dabei wurde die Nachrichtenrichtung in ein bestimmtes Kafka-Topic durch den Einsatz von Nifi-Prozessoren PublishKafka realisiert. Die Orchestrierung und Verwaltung 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 zur Entwicklung bezeichnet werden, der einen niedrigen Einstieg in die Big Data-Technologien ermöglicht und den Entwicklungsprozess von Anwendungen beschleunigt.

Der nächste Schritt bei der Umsetzung des Projekts bestand darin, ein einheitliches semantisches Format für die detaillierten Daten zu schaffen. Bei Vorhandensein historischer Attribute der Entität wird die Berechnung im Kontext der betrachteten Partition durchgeführt. Ist die Entität jedoch nicht historisch, so ist optional entweder eine Neuberechnung des gesamten Objekts möglich oder es kann auf eine Neuberechnung dieses Objekts verzichtet werden (aufgrund fehlender Änderungen). In diesem Schritt findet die Generierung von Schlüsseln für alle Entitäten statt. Die Schlüsseldaten werden in die entsprechenden Master-Objekte von Hbase gespeichert, die die Zuordnung zwischen Schlüsseln in der Analyseplattform und Schlüsseln aus den Quellsystemen enthalten. Die Konsolidierung atomarer Entitäten wird von der Bereicherung mit Ergebnissen der vorläufigen Berechnung analytischer Daten begleitet. Das Framework für die Datenberechnung war Spark. Die beschriebene Funktionalität zur Angleichung der Daten an eine einheitliche Semantik wurde ebenfalls auf Basis von Low-Code-Mappings des Tools Datagram realisiert.

In der Zielarchitektur war es erforderlich, SQL-Zugriff auf die Daten für die Business-Nutzer bereitzustellen. Für diese Option wurde Hive verwendet. Die Registrierung von Objekten in Hive erfolgt automatisch, wenn die Option „Hive-Tabelle registrieren“ im Low-Code-Tool aktiviert wird.

Steuerung des Berechnungsflusses

Das Datagram hat eine Schnittstelle zur Gestaltung von Workflow-Designs. Das Starten von Mappings kann mit dem Oozie-Planer erfolgen. In der Entwickleroberfläche für Workflows ist es möglich, Schemata für parallele, serielle oder bedingte Ausführungen von Datenveränderungen zu erstellen. Es gibt Unterstützung für Shell-Skripte und Java-Programme. Auch die Nutzung von Server Apache Livy. Apache Livy wird verwendet, um Anwendungen direkt aus der Entwicklungsumgebung zu starten.

Wenn das Unternehmen bereits einen eigenen Prozessorchestrator hat, kann die REST-API verwendet werden, um Mappings in den bereits vorhandenen Workflow einzubetten. Zum Beispiel hatten wir bereits recht erfolgreiche Erfahrungen mit der Integration von Mappings in Scala in Orchestratoren, die in PLSQL und Kotlin geschrieben wurden. Die REST-API des Low-Code-Tools ermöglicht Operationen wie die Generierung von ausführbarem Jahr basierend auf dem Mapping-Design, den Aufruf von Mappings, den Aufruf von Mapping-Sequenzen und selbstverständlich die Übertragung von URL-Parametern zur Ausführung von Mappings.

Neben Oozie kann auch der Airflow-Workflow zur Berechnung organisiert werden. Ich möchte nicht lange auf den Vergleich zwischen Oozie und Airflow eingehen, sondern sagen, dass wir in diesem Kontext für das Projekt zur Medienforschung die Wahl auf Airflow gefallen ist. Die Hauptargumente in diesem Fall waren die aktivere Community, die das Produkt weiterentwickelt, und die fortschrittlichere Benutzeroberfläche + API.

Airflow ist auch deshalb gut, weil es zur Beschreibung von Berechnungsprozessen das von vielen geschätzte Python verwendet. Außerdem gibt es nicht viele Open-Source-Workflow-Management-Plattformen. Das Starten und Überwachen von Prozessen (einschließlich mit Gantt-Diagramm) bringt nur weitere Pluspunkte für Airflow.

Das Format der Konfigurationsdatei zum Starten der Low-Code-Lösungen wurde von spark-submit übernommen. 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 Workflows enthalten (was das Schreiben von Skripten zur Erstellung des DAG erleichtert).
Das am häufigsten vorkommende Element im Airflow-Workflow in unserem Fall war der SparkSubmitOperator.

Der SparkSubmitOperator ermöglicht das Starten von Jar-Dateien – gepackten Mappings von Datagram mit vorher festgelegten Eingabeparametern.

Es sollte erwähnt werden, dass jede Aufgabe von Airflow in einem separaten Thread ausgeführt wird und nichts über andere Aufgaben weiß. Daher erfolgt die Interaktion zwischen den Aufgaben mithilfe von Steuerungselementen wie DummyOperator oder BranchPythonOperator.

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

Berechnung von Data Warehouses

Der wohl am stärksten intellektuell belastete Schritt in der Erstellung analytischer Daten ist der Schritt der Konstruktion von Data Warehouses. Im Kontext eines der Datenberechnungsflüsse eines Forschungsunternehmens erfolgt an diesem Punkt die Anpassung an die Referenzübersetzung unter Berücksichtigung der Verschiebung in den Zeitzonen und in Verbindung mit dem Sendeschema. Auch eine Anpassung an das lokale Sendeschema (lokale Nachrichten und Werbung) ist möglich. Unter anderem erfolgt an diesem Schritt die Unterteilung der kontinuierlichen Sehintervalle von Medienprodukten basierend auf der Analyse der Sehintervalle. Hierbei erfolgt auch das „Wägen“ der Zuschauerzahlen auf der Grundlage von Informationen über deren Bedeutung (Berechnung eines Anpassungsfaktors).

Ein separater Schritt der Vorbereitung von Data Warehouses ist die Validierung der Daten. Der Validierungsalgorithmus ist mit der Anwendung einer Reihe von mathematischen Wissenschaftsmodellen verbunden. Die Verwendung einer Low-Code-Plattform ermöglicht es jedoch, den komplexen Algorithmus in eine Reihe von einzelnen visuell lesbaren Zuordnungen zu zerlegen. Jede dieser Zuordnungen führt eine spezifische Aufgabe aus. Infolgedessen ist eine Zwischen-Debugging, Protokollierung und Visualisierung der Schritte zur Datenvorbereitung möglich.

Der Validierungsalgorithmus wurde entschieden, auzufächern auf folgende Unterstufen:

• Konstruktion von Regressionsabhängigkeiten des Zuschauerverhaltens der Fernsehsender in der Region im Vergleich zum Zuschauerverhalten aller Sender in der Region über 60 Tage.
• Berechnung der studentisierten Residuen (Abweichungen der tatsächlichen Werte von den durch das Regressionsmodell vorhergesagten) für alle Punktregressionen und für den Berechnungstag.
• Auswahl von anomalen Paaren Region-Fernsehnetz, bei denen das studentisierte Residuum des Berechnungstags die Norm (festgelegt durch die Einstellungsoperation) überschreitet.
• Die Nachberechnung des angepassten standardisierten Restbetrags für anomale Regionen-Netzwerke für jeden Befragten, der das Netzwerk in der Region angesehen hat, unter Berücksichtigung des Beitrags dieses Befragten (Änderungsgröße des standardisierten Restbetrags) bei Ausschluss des Betrachtens dieses Befragten aus der Stichprobe.
• Die Suche nach Kandidaten, deren Ausschluss den standardisierten Restbetrag des Berechnungstags in die Norm führt.

Das oben angeführte Beispiel bestätigt die Hypothese, dass ein Dateningenieur bereits zu viele Informationen im Kopf haben muss… Wenn es sich wirklich um einen "Ingenieur" und nicht um einen "Coder" handelt, sollte die Angst vor beruflichem Verfall durch die Nutzung von Low-Code-Tools endgültig schwinden.

Was kann Low-Code noch?

Der Anwendungsbereich von Low-Code-Tools für die Batch- und Stream-Datenverarbeitung endet nicht mit der Notwendigkeit, Code in Scala manuell zu schreiben.

Die Anwendung von Low-Code in der Entwicklung von Datalakes ist für uns bereits zu einem Standard geworden. Man kann wahrscheinlich sagen, dass Lösungen auf dem Hadoop-Stack den Entwicklungsweg klassischer DWH, die auf RDBMS basieren, wiederholen. Low-Code-Tools auf dem Hadoop-Stack können sowohl Aufgaben der Datenverarbeitung als auch Aufgaben des Aufbaus von End-BI-Schnittstellen lösen. Dabei sollte bemerkt werden, dass unter BI nicht nur die Darstellung von Daten, sondern auch deren Bearbeitung durch Business-Nutzer verstanden werden kann. Diese Funktionalität wird von uns häufig beim Aufbau analytischer Plattformen für den Finanzsektor genutzt.

Unter anderem ermöglicht es low-code, und insbesondere Datagram, die Aufgabe der Nachverfolgung des Herkunfts von Objekten im Datenfluss mit einer Granularität bis hin zu einzelnen Feldern (Lineage) zu lösen. Dazu wurde in dem low-code-Tool eine Anbindung an Apache Atlas und Cloudera Navigator implementiert. Im Grunde muss der Entwickler eine Reihe von Objekten in den Atlas-Dictionaries registrieren und auf die registrierten Objekte beim Erstellen von Mappings verweisen. Der Mechanismus zur Nachverfolgung von Datenherkünften oder zur Analyse von Objektabhängigkeiten spart viel Zeit, wenn Modifikationen in den Berechnungsalgorithmen vorgenommen werden müssen. Zum Beispiel ermöglicht diese Funktion beim Erstellen von Finanzberichten, den Zeitraum von Gesetzesänderungen komfortabler zu bewältigen. Denn je besser wir die interformale Abhängigkeit im Bereich der Objekte der Detailebene erkennen, desto weniger „plötzliche“ Fehler werden wir begegnen und desto mehr werden wir die Anzahl der Reworks reduzieren.

Datenqualität & Low-Code

Eine weitere Aufgabe, die mit dem low-code-Tool im Projekt des Unternehmens Mediascope realisiert wurde, ist die Aufgabenklasse Datenqualität. Eine Besonderheit der Implementierung der Datenprüfungs-Pipeline für das Projekt des Forschungsunternehmens war, dass sie keinen Einfluss auf die Funktionalität und Geschwindigkeit des Hauptdatenberechnungsflusses hatte. Für das Orchestrieren von autonomen Datenprüfungsströmen wurde bereits bekanntes Apache Airflow verwendet. Mit der Fertigstellung jedes Schrittes der Datenproduktion wurde parallel ein separater Teil der DQ-Pipeline gestartet.

Es gilt als gute Praxis, die Datenqualität vom Moment ihrer Entstehung in der Analyseplattform zu überwachen. Mit Informationen über Metadaten können wir bereits ab dem Zeitpunkt, an dem die Informationen in die erste Schicht gelangen, die Einhaltung grundlegender Bedingungen überprüfen — not null, constraints, foreign keys. Diese Funktionalität wurde auf Basis automatisch generierter Mappings der Familie Datenqualität in Datagram implementiert. Im Projekt des Unternehmens Mediascope fand die Anbindung an die Metadaten des Produkts Enterprise Architect statt.

Dank der Anbindung des low-code-Tools an Enterprise Architect wurden automatisch die folgenden Prüfungen generiert:

• Prüfung des Vorhandenseins von null-Werten in Feldern mit dem Modifikator „not null“;
• Prüfung des Vorhandenseins von Duplikaten des Primärschlüssels;
• Überprüfung des Fremdschlüssels der Entität;
• Überprüfung der Eindeutigkeit einer Zeile anhand eines Satzes von Feldern.

Für komplexere Prüfungen der Verfügbarkeit und Korrektheit von Daten wurde ein Mapping mit Scala Expression erstellt, das einen externen Spark SQL-Prüfcode entgegennimmt, der von Analysten in Zeppelin vorbereitet wurde.

Selbstverständlich muss die automatische Generierung von Prüfungen schrittweise erfolgen. Im Rahmen des beschriebenen Projekts gingen folgende Schritte voraus:

• DQ, die in Zeppelin-Notizbüchern implementiert sind;
• DQ, die in das Mapping integriert sind;
• DQ in Form separater massiver Mappings, die eine gesamte Reihe von Prüfungen für eine einzelne Entität enthalten;
• Universelle parametrisierte DQ-Mappings, die Informationen über Metadaten und Geschäftsprüfungen entgegennehmen.

Das Hauptvorteil der Erstellung eines Dienstes für parametrische Prüfungen besteht darin, die Zeit bis zur Bereitstellung der Funktionalität in der Produktionsumgebung zu verkürzen. Neue Qualitätsprüfungen können das klassische Muster der Codebereitstellung über Entwicklungs- und Testumgebungen umgehen:

• Alle Metadatenprüfungen werden automatisch bei Änderungen des Modells in EA generiert;
• Prüfungen der Datenverfügbarkeit (Bestimmung des Vorhandenseins von Daten zu einem bestimmten Zeitpunkt) können auf der Grundlage eines Verzeichnisses generiert werden, das den erwarteten Zeitrahmen für das Erscheinen einer neuen Datencharge in Bezug auf Objekte speichert;
• Geschäftliche Prüfungen der Datenkorrektheit werden von den Analysten in Zeppelin-Notizbüchern erstellt. Von dort gehen sie direkt in die Konfigurationstabellen des DQ-Moduls in der Produktionsumgebung.

Die Risiken der direkten Übergabe von Skripten in die Produktion existieren nicht wirklich. Selbst bei syntaktischen Fehlern besteht maximal die Gefahr, dass eine Prüfung nicht ausgeführt wird, da der Datenberechnungsstrom und der Qualitätsprüfungsstrom voneinander getrennt sind.

Im Grunde genommen ist der DQ-Dienst permanent in der Produktionsumgebung aktiviert und bereit, seine Arbeit zu beginnen, sobald die nächste Datencharge verfügbar ist.

Zum Abschluss

Die Vorteile der Anwendung von Low-Code sind offensichtlich. Entwickler müssen die Anwendung nicht "von Grund auf neu" entwickeln. Ein von zusätzlichen Aufgaben befreiter Programmierer liefert schneller Ergebnisse. Geschwindigkeit wiederum schafft zusätzliche zeitliche Ressourcen für die Lösung von Optimierungsfragen. Folglich kann man in diesem Fall mit qualitativ hochwertigeren und schnelleren Lösungen rechnen.

Natürlich ist Low-Code kein Allheilmittel, und das Wunder wird sich nicht von selbst einstellen:

• Die Low-Code-Industrie durchläuft eine Phase der "Stärkung", und es gibt bisher keine einheitlichen industriellen Standards;
• Viele Low-Code-Lösungen sind nicht kostenlos, und ihr Erwerb sollte ein bewusster Schritt sein, den man nur bei voller Überzeugung von den finanziellen Vorteilen ihrer Nutzung gehen sollte;
• Viele Low-Code-Lösungen funktionieren nicht immer gut mit GIT / SVN. Oder sie sind unpraktisch zu verwenden, wenn der generierte Code verborgen ist;
• Bei der Erweiterung der Architektur kann eine Anpassung der Low-Code-Lösung erforderlich sein – was wiederum den Effekt der "Bindung und Abhängigkeit" vom Anbieter der Low-Code-Lösung provoziert.
• Ein angemessenes Sicherheitsniveau ist möglich, aber ziemlich aufwendig und komplex in der Umsetzung von Low-Code-Systemen. Low-Code-Plattformen sollten nicht nur nach dem Prinzip der Suche nach Nutzen aus ihrer Nutzung ausgewählt werden. Bei der Auswahl sollten Fragen zur Verfügbarkeit von Funktionen zur Verwaltung des Zugriffs und zur Delegation/Eskalation von Identifikationsdaten auf die Ebene der gesamten IT-Landschaft der Organisation gestellt werden.

Wenn Ihnen jedoch alle Nachteile des gewählten Systems bekannt sind und die Vorteile seiner Nutzung dennoch in der Mehrzahl überwiegen, können Sie ohne Angst zu Low-Code wechseln. Umso mehr, als der Wechsel unvermeidlich ist – wie jede Evolution unvermeidlich ist.

Wenn ein Entwickler auf einer Low-Code-Plattform seine Arbeit schneller erledigt als zwei Entwickler ohne Low-Code, verschafft das dem Unternehmen in vielerlei Hinsicht einen Vorteil. Die Einstiegshürde für Low-Code-Lösungen ist niedriger als bei „traditionellen“ Technologien, was sich positiv auf das Thema Fachkräftemangel auswirkt. Mit Low-Code-Tools kann die Interaktion zwischen funktionalen Teams beschleunigt und die Entscheidungsfindung zur Richtigkeit des gewählten data-science-Forschungsansatzes schneller getroffen werden. Low-Code-Plattformen können Auslöser für die digitale Transformation einer Organisation sein, da die entwickelten Lösungen auch für nicht-technische Fachleute (insbesondere für Geschäftsanwender) verständlich sein können.

Wenn Sie enge Fristen, komplexe Geschäftslogik und einen Mangel an technologischer Expertise haben und Ihre Markteinführungszeit verkürzen müssen, dann ist Low-Code eine Möglichkeit, Ihren Bedarf zu decken.

Es ist nicht zu leugnen, dass traditionelle Entwicklungstools wichtig sind, aber in vielen Fällen ist der Einsatz von Low-Code-Lösungen der beste Weg, die Effizienz bei der Bearbeitung von Aufgaben zu steigern.

Quelle: habr.com