🥇Low-code gebruiken in analytische platforms

Beste lezers, goede dag!

De taak van het bouwen van IT-platforms voor het verzamelen en analyseren van gegevens komt vroeg of laat voor elk bedrijf wiens activiteiten gebaseerd zijn op een intellectueel geladen dienstverleningsmodel of de creatie van technisch complexe producten. Het bouwen van analytische platforms is een complexe en tijdrovende taak. Elke taak kan echter worden vereenvoudigd. In dit artikel wil ik mijn ervaring delen met het gebruik van low-code tools om analytische oplossingen te helpen creëren. Deze ervaring is opgedaan tijdens de implementatie van een aantal projecten in de richting Big Data Solutions van het bedrijf Neoflex. Sinds 2005 houdt de afdeling Big Data Solutions van Neoflex zich bezig met de problemen van het bouwen van datawarehouses en meren, het oplossen van problemen met het optimaliseren van de snelheid van informatieverwerking en het werken aan een methodologie voor datakwaliteitsbeheer.

Niemand zal de bewuste accumulatie van zwak en/of sterk gestructureerde data kunnen vermijden. Misschien zelfs als we het over kleine bedrijven hebben. Bij het opschalen van een bedrijf zal een veelbelovende ondernemer immers worden geconfronteerd met de problemen van het ontwikkelen van een loyaliteitsprogramma, zal hij de effectiviteit van verkooppunten willen analyseren, zal hij nadenken over gerichte reclame en zal hij verbaasd zijn over de vraag naar bijbehorende producten. . In eerste instantie kan het probleem “op de knie” worden opgelost. Maar naarmate het bedrijf groeit, is het nog steeds onvermijdelijk om tot een analytisch platform te komen.

Maar in welk geval kunnen data-analysetaken zich ontwikkelen tot ‘Rocket Science’-klasseproblemen? Misschien op het moment dat we het over echt big data hebben.
Om Rocket Science makkelijker te maken, kun je de olifant stukje voor stukje opeten.

Hoe discreter en autonomer uw applicaties/diensten/microservices zijn, hoe gemakkelijker het voor u, uw collega's en het hele bedrijf zal zijn om de olifant te verteren.

Bijna al onze klanten kwamen tot dit uitgangspunt, nadat ze het landschap opnieuw hadden opgebouwd op basis van de engineeringpraktijken van DevOps-teams.

Maar zelfs met een ‘apart, olifantachtig’ dieet hebben we een grote kans op ‘oververzadiging’ van het IT-landschap. Op dit moment is het de moeite waard om te stoppen, uit te ademen en opzij te kijken low-code engineeringplatform.

Veel ontwikkelaars zijn bang voor het vooruitzicht op een doodlopende weg in hun carrière wanneer ze overstappen van het rechtstreeks schrijven van code naar het 'slepen' van pijlen in de gebruikersinterfaces van low-code-systemen. Maar de komst van werktuigmachines leidde niet tot het verdwijnen van ingenieurs, maar bracht hun werk naar een nieuw niveau!

Laten we uitzoeken waarom.

Data-analyse op het gebied van logistiek, telecombranche, mediaonderzoek, financiële sector gaat altijd gepaard met de volgende vragen:

Snelheid van geautomatiseerde analyse;
Mogelijkheid om experimenten uit te voeren zonder de belangrijkste gegevensproductiestroom te beïnvloeden;
Betrouwbaarheid van de opgestelde gegevens;
Wijzigingen bijhouden en versiebeheer;
Gegevensherkomst, gegevensafstamming, CDC;
Snelle levering van nieuwe features aan de productieomgeving;
En het beruchte: de kosten van ontwikkeling en ondersteuning.

Dat wil zeggen dat ingenieurs een groot aantal taken op hoog niveau hebben, die alleen met voldoende efficiëntie kunnen worden voltooid door hun bewustzijn te zuiveren van ontwikkelingstaken op een laag niveau.

De voorwaarden voor ontwikkelaars om naar een nieuw niveau te gaan waren de evolutie en digitalisering van het bedrijfsleven. De waarde van de ontwikkelaar verandert ook: er is een aanzienlijk tekort aan ontwikkelaars die zich kunnen verdiepen in de concepten van het bedrijf dat wordt geautomatiseerd.

Laten we een analogie trekken met programmeertalen op laag en hoog niveau. De overgang van talen op laag niveau naar talen op hoog niveau is een overgang van het schrijven van “directe richtlijnen in de taal van hardware” naar “richtlijnen in de taal van mensen”. Dat wil zeggen, het toevoegen van een laag abstractie. In dit geval is de transitie naar low-code platforms vanuit programmeertalen op hoog niveau een transitie van “richtlijnen in de taal van mensen” naar “richtlijnen in de taal van het bedrijfsleven”. Als er ontwikkelaars zijn die bedroefd zijn door dit feit, dan zijn ze misschien bedroefd sinds het moment dat Java Script werd geboren, dat array-sorteerfuncties gebruikt. En deze functies hebben uiteraard software-implementatie onder de motorkap via andere middelen van dezelfde programmering op hoog niveau.

Daarom is low-code slechts de schijn van een ander abstractieniveau.

Toegepaste ervaring met low-code

Het onderwerp low-code is vrij breed, maar nu wil ik het hebben over de praktische toepassing van “low-code concepten” aan de hand van het voorbeeld van een van onze projecten.

De Big Data Solutions-divisie van Neoflex is meer gespecialiseerd in de financiële sector van het bedrijfsleven, het bouwen van datawarehouses en lakes en het automatiseren van diverse rapportages. In deze niche is het gebruik van low-code al lang een standaard geworden. Onder andere low-code tools kunnen we tools noemen voor het organiseren van ETL-processen: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Of Oracle Apex, dat fungeert als omgeving voor de snelle ontwikkeling van interfaces voor het ontsluiten en bewerken van data. Het gebruik van low-code-ontwikkeltools houdt echter niet altijd in dat zeer gerichte applicaties worden gebouwd op een commerciële technologiestapel met een duidelijke afhankelijkheid van de leverancier.

Met low-code platforms kun je ook de orkestratie van datastromen organiseren, data science platforms creëren of bijvoorbeeld modules voor het controleren van datakwaliteit.

Een van de toegepaste voorbeelden van ervaring met het gebruik van low-code ontwikkeltools is de samenwerking tussen Neoflex en Mediascope, een van de leiders op de Russische mediaonderzoeksmarkt. Een van de zakelijke doelstellingen van dit bedrijf is de productie van gegevens op basis waarvan adverteerders, internetplatforms, tv-kanalen, radiostations, reclamebureaus en merken beslissingen nemen over de aankoop van advertenties en hun marketingcommunicatie plannen.

Mediaonderzoek is een technologisch geladen vakgebied. Het herkennen van videosequenties, het verzamelen van gegevens van apparaten die het kijkgedrag analyseren, het meten van de activiteit op internetbronnen - dit alles impliceert dat het bedrijf over een groot IT-personeel beschikt en over een enorme ervaring in het bouwen van analytische oplossingen. Maar de exponentiële groei van de hoeveelheid informatie, het aantal en de verscheidenheid van de bronnen ervan dwingt de IT-data-industrie tot voortdurende vooruitgang. De eenvoudigste oplossing voor het opschalen van het reeds functionerende analytische platform van Mediascope zou het vergroten van het IT-personeel kunnen zijn. Maar een veel effectievere oplossing is het versnellen van het ontwikkelingsproces. Eén van de stappen die in deze richting kunnen leiden is het gebruik van low-code platforms.

Toen het project van start ging, beschikte het bedrijf al over een functionerende productoplossing. De implementatie van de oplossing in MSSQL kon echter niet volledig voldoen aan de verwachtingen voor het schalen van functionaliteit met behoud van aanvaardbare ontwikkelingskosten.

De taak die voor ons lag was werkelijk ambitieus: Neoflex en Mediascope moesten in minder dan een jaar een industriële oplossing creëren, onder voorbehoud van de release van de MVP binnen het eerste kwartaal na de startdatum.

De Hadoop-technologiestack werd gekozen als basis voor het bouwen van een nieuw dataplatform op basis van low-code computing. HDFS is de standaard geworden voor gegevensopslag met behulp van parketbestanden. Om toegang te krijgen tot de gegevens op het platform werd Hive gebruikt, waarin alle beschikbare storefronts worden gepresenteerd in de vorm van externe tabellen. Het laden van gegevens in de opslag gebeurde met behulp van Kafka en Apache NiFi.

De Lowe-code-tool in dit concept werd gebruikt om de meest arbeidsintensieve taak bij het bouwen van een analytisch platform te optimaliseren: de taak van het berekenen van gegevens.

Er werd gekozen voor de low-code Datagram-tool als het belangrijkste mechanisme voor datamapping. Neoflex-datagram is een hulpmiddel voor het ontwikkelen van transformaties en datastromen.
Met deze tool kunt u Scala-code niet handmatig schrijven. Scalacode wordt automatisch gegenereerd met behulp van de Model Driven Architecture-aanpak.

Een duidelijk voordeel van deze aanpak is het versnellen van het ontwikkelingsproces. Naast snelheid zijn er echter ook de volgende voordelen:

Het bekijken van de inhoud en structuur van bronnen/ontvangers;
Het traceren van de oorsprong van gegevensstroomobjecten naar individuele velden (afstamming);
Gedeeltelijke uitvoering van transformaties met weergave van tussenresultaten;
Het beoordelen van de broncode en aanpassen voordat deze wordt uitgevoerd;
Automatische validatie van transformaties;
Automatische gegevensdownload 1 op 1.

De drempel voor toegang tot low-code oplossingen voor het genereren van transformaties is vrij laag: de ontwikkelaar moet kennis hebben van SQL en ervaring hebben met het werken met ETL-tools. Het is vermeldenswaard dat codegestuurde transformatiegeneratoren geen ETL-tools zijn in de brede zin van het woord. Low-code-tools hebben mogelijk geen eigen code-uitvoeringsomgeving. Dat wil zeggen dat de gegenereerde code wordt uitgevoerd in de omgeving die al op het cluster bestond voordat de low-code-oplossing werd geïnstalleerd. En dit is misschien nog een pluspunt voor low-code karma. Omdat parallel met een low-code team een ‘klassiek’ team kan werken dat functionaliteit bijvoorbeeld in pure Scala-code implementeert. Het in productie brengen van verbeteringen van beide teams zal eenvoudig en naadloos zijn.

Het is wellicht vermeldenswaard dat er naast low-code ook no-code oplossingen bestaan. En in de kern zijn dit verschillende dingen. Met low-code kan de ontwikkelaar zich meer bemoeien met de gegenereerde code. In het geval van Datagram is het mogelijk om de gegenereerde Scala-code te bekijken en te bewerken; no-code biedt deze mogelijkheid mogelijk niet. Dit verschil is niet alleen erg groot in termen van de flexibiliteit van de oplossing, maar ook in termen van comfort en motivatie in het werk van data-ingenieurs.

Oplossingsarchitectuur

Laten we proberen erachter te komen hoe een low-code tool precies helpt bij het oplossen van het probleem van het optimaliseren van de snelheid van het ontwikkelen van functionaliteit voor gegevensberekening. Laten we eerst eens kijken naar de functionele architectuur van het systeem. Een voorbeeld hiervan is het dataproductiemodel voor mediaonderzoek.

Gegevensbronnen zijn in ons geval zeer heterogeen en divers:

Mensenmeters (tv-meters) zijn software- en hardwareapparaten die het gebruikersgedrag van respondenten op televisiepanels aflezen: wie, wanneer en welke tv-zender er werd bekeken in het huishouden dat aan het onderzoek deelneemt. De aangeleverde informatie is een stroom van uitgezonden kijkintervallen gekoppeld aan het mediapakket en mediaproduct. Gegevens die zich in het stadium van laden in het Data Lake bevinden, kunnen worden verrijkt met demografische kenmerken, geostratificatie, tijdzone en andere informatie die nodig is voor het analyseren van het televisiekijken naar een bepaald mediaproduct. De uitgevoerde metingen kunnen worden gebruikt om reclamecampagnes te analyseren of te plannen, de activiteit en voorkeuren van het publiek te beoordelen en het omroepnetwerk samen te stellen;
De gegevens kunnen afkomstig zijn van monitoringsystemen voor het streamen van televisie-uitzendingen en het meten van de weergave van videobronnen op internet;
Meetinstrumenten in de webomgeving, inclusief zowel locatiegerichte als gebruikersgerichte meters. De gegevensprovider voor het Data Lake kan een browser-add-on in de onderzoeksbalk zijn en een mobiele applicatie met een ingebouwde VPN.
Gegevens kunnen ook afkomstig zijn van sites die de resultaten van het invullen van onlinevragenlijsten en de resultaten van telefonische interviews in bedrijfsenquêtes consolideren;
Extra verrijking van het datameer kan plaatsvinden door informatie te downloaden uit logs van partnerbedrijven.

De implementatie van het laden vanuit bronsystemen in de primaire enscenering van ruwe data kan op verschillende manieren worden georganiseerd. Als hiervoor low-code wordt gebruikt, is het automatisch genereren van laadscripts op basis van metadata mogelijk. In dit geval is het niet nodig om terug te gaan naar het niveau van het ontwikkelen van bron-naar-doel-toewijzingen. Om automatisch laden te implementeren, moeten we een verbinding tot stand brengen met de bron en vervolgens in de laadinterface de lijst met te laden entiteiten definiëren. De directorystructuur in HDFS wordt automatisch aangemaakt en komt overeen met de gegevensopslagstructuur op het bronsysteem.

In de context van dit project hebben we echter besloten om deze functie van het low-code platform niet te gebruiken, omdat het bedrijf Mediascope al zelfstandig is begonnen met het produceren van een soortgelijke dienst met behulp van de combinatie Nifi + Kafka.

Het is de moeite waard om meteen aan te geven dat deze instrumenten niet uitwisselbaar zijn, maar eerder complementair. Nifi en Kafka kunnen zowel in directe (Nifi -> Kafka) als in omgekeerde (Kafka -> Nifi) verbinding werken. Voor het mediaonderzoeksplatform werd de eerste versie van de bundel gebruikt.

In ons geval moest NayFi verschillende soorten gegevens uit bronsystemen verwerken en naar de Kafka-makelaar sturen. In dit geval werden berichten naar een specifiek Kafka-onderwerp verzonden met behulp van PublishKafka Nifi-processors. De orkestratie en het onderhoud van deze pijpleidingen gebeurt in een visuele interface. De Nifi-tool en het gebruik van de Nifi + Kafka-combinatie kunnen ook een low-code-aanpak van ontwikkeling worden genoemd, die een lage drempel heeft voor toegang tot Big Data-technologieën en het applicatie-ontwikkelproces versnelt.

De volgende fase in de projectimplementatie was het overbrengen van gedetailleerde gegevens naar één semantisch laagformaat. Als een entiteit historische attributen heeft, wordt de berekening uitgevoerd in de context van de betreffende partitie. Als de entiteit niet historisch is, is het optioneel mogelijk om ofwel de volledige inhoud van het object opnieuw te berekenen, ofwel volledig te weigeren dit object opnieuw te berekenen (vanwege het ontbreken van wijzigingen). In dit stadium worden sleutels gegenereerd voor alle entiteiten. De sleutels worden opgeslagen in de Hbase-directory's die overeenkomen met de masterobjecten, die een overeenkomst bevatten tussen de sleutels in het analytische platform en de sleutels van de bronsystemen. Consolidatie van atomaire entiteiten gaat gepaard met verrijking met de resultaten van voorlopige berekeningen van analytische gegevens. Het raamwerk voor gegevensberekening was Spark. De beschreven functionaliteit om data naar één semantiek te brengen werd eveneens geïmplementeerd op basis van mappings uit de low-code Datagram tool.

De doelarchitectuur vereiste SQL-toegang tot gegevens voor zakelijke gebruikers. Voor deze optie werd Hive gebruikt. Objecten worden automatisch in Hive geregistreerd wanneer u de optie “Registr Hive Table” inschakelt in de low-code tool.

Berekening stroomcontrole

Datagram heeft een interface voor het maken van workflowstroomontwerpen. Mappings kunnen worden gestart met behulp van de Oozie-planner. In de streamontwikkelaarinterface is het mogelijk om schema's te maken voor parallelle, sequentiële of uitvoeringsafhankelijke datatransformaties. Er is ondersteuning voor shellscripts en Java-programma's. Het is ook mogelijk om de Apache Livy-server te gebruiken. Apache Livy wordt gebruikt om applicaties rechtstreeks vanuit de ontwikkelomgeving uit te voeren.

Als het bedrijf al over een eigen procesorkestrator beschikt, is het mogelijk om de REST API te gebruiken om mappings in een bestaande flow in te bedden. We hadden bijvoorbeeld behoorlijk succesvolle ervaring met het inbedden van mappings in Scala in orkestrators geschreven in PLSQL en Kotlin. De REST API van de low-code tool omvat bewerkingen zoals het genereren van een uitvoerbaar jaar op basis van het mappingontwerp, het aanroepen van een mapping, het aanroepen van een reeks mappings en uiteraard het doorgeven van parameters aan de URL om mappings uit te voeren.

Samen met Oozie is het mogelijk om met Airflow een rekenstroom te organiseren. Misschien zal ik niet lang stilstaan bij de vergelijking tussen Oozie en Airflow, maar wil ik eenvoudigweg zeggen dat in de context van het werk aan een mediaonderzoeksproject de keuze in het voordeel van Airflow viel. De belangrijkste argumenten waren deze keer een actievere gemeenschap die het product ontwikkelde en een meer ontwikkelde interface + API.

Airflow is ook goed omdat het de geliefde Python gebruikt om rekenprocessen te beschrijven. En over het algemeen zijn er niet zoveel open source workflowbeheerplatforms. Het lanceren en monitoren van de uitvoering van processen (inclusief een Gantt-diagram) voegt alleen maar punten toe aan het karma van Airflow.

Het configuratiebestandsformaat voor het starten van low-code oplossingstoewijzingen is spark-submit geworden. Dit gebeurde om twee redenen. Ten eerste kunt u met spark-submit rechtstreeks een jar-bestand vanaf de console uitvoeren. Ten tweede kan het alle benodigde informatie bevatten om de workflow te configureren (wat het gemakkelijker maakt om scripts te schrijven die Dag genereren).
Het meest voorkomende element van de Airflow-workflow in ons geval was de SparkSubmitOperator.

Met SparkSubmitOperator kunt u jars uitvoeren: verpakte datagramtoewijzingen met vooraf gegenereerde invoerparameters ervoor.

Het is de moeite waard te vermelden dat elke Airflow-taak in een aparte thread wordt uitgevoerd en niets weet over andere taken. Daarom wordt de interactie tussen taken uitgevoerd met behulp van besturingsoperatoren, zoals DummyOperator of BranchPythonOperator.

Alles bij elkaar heeft het gebruik van de Datagram low-code-oplossing in combinatie met de universalisering van configuratiebestanden (het vormen van Dag) geleid tot een aanzienlijke versnelling en vereenvoudiging van het proces van het ontwikkelen van gegevenslaadstromen.

Showberekeningen

Misschien wel de meest intellectueel geladen fase in de productie van analytische gegevens is de stap van het bouwen van showcases. In de context van een van de gegevensberekeningsstromen van het onderzoeksbureau worden de gegevens in dit stadium teruggebracht tot een referentie-uitzending, rekening houdend met correcties voor tijdzones en gekoppeld aan het uitzendnetwerk. Ook is het mogelijk om aan te passen voor het lokale omroepnetwerk (lokaal nieuws en reclame). Deze stap splitst onder andere de intervallen van het continu bekijken van mediaproducten op op basis van de analyse van kijkintervallen. De kijkwaarden worden direct ‘gewogen’ op basis van informatie over hun betekenis (berekening van een correctiefactor).

Een aparte stap bij het voorbereiden van showcases is datavalidatie. Het validatiealgoritme omvat het gebruik van een aantal wiskundige wetenschappelijke modellen. Door het gebruik van een low-code platform kun je echter een complex algoritme opsplitsen in een aantal afzonderlijke, visueel leesbare mappings. Elk van de mappings voert een beperkte taak uit. Hierdoor zijn tussentijdse debuggen, loggen en visualiseren van datavoorbereidingsfasen mogelijk.

Er werd besloten om het validatie-algoritme te discretiseren in de volgende subfasen:

Het opbouwen van regressies van de kijkafhankelijkheden van tv-netwerken in een regio, waarbij alle netwerken in de regio gedurende 60 dagen worden bekeken.
Berekening van gestudentiseerde residuen (afwijkingen van werkelijke waarden van de waarden voorspeld door het regressiemodel) voor alle regressiepunten en voor de berekende dag.
Een selectie van afwijkende regio-netwerkparen, waarbij het gestudentiseerde saldo van de afwikkelingsdag de norm overschrijdt (gespecificeerd door de bedieningsinstellingen).
Herberekening van het gecorrigeerde gestudentiseerde residu voor afwijkende regio-tv-netwerkparen voor elke respondent die naar het netwerk in de regio heeft gekeken, waarbij de bijdrage van deze respondent wordt bepaald (de hoeveelheid verandering in het gestudentiseerde residu) wanneer het kijken van deze respondent uit de steekproef wordt uitgesloten .
Zoek naar kandidaten wier uitsluiting het studentensaldo van de betaaldag weer normaal maakt.

Het bovenstaande voorbeeld bevestigt de hypothese dat een data engineer al te veel aan zijn hoofd heeft... En als dit echt een “ingenieur” is en geen “codeur”, dan is de angst voor professionele degradatie bij het gebruik van low-code tools die hij gebruikt moet zich eindelijk terugtrekken.

Wat kan low-code nog meer doen?

Het toepassingsgebied van een low-code tool voor batch- en streamdataverwerking zonder de noodzaak om handmatig code te schrijven in Scala houdt daar niet op.

Het gebruik van low-code bij de ontwikkeling van datalake is voor ons inmiddels een standaard geworden. We kunnen waarschijnlijk zeggen dat oplossingen op basis van de Hadoop-stack het ontwikkelingspad volgen van klassieke DWH's op basis van RDBMS. Low-code tools op de Hadoop-stack kunnen zowel gegevensverwerkingstaken als de taak van het bouwen van definitieve BI-interfaces oplossen. Bovendien moet worden opgemerkt dat BI niet alleen de representatie van gegevens kan betekenen, maar ook het bewerken ervan door zakelijke gebruikers. Deze functionaliteit gebruiken wij vaak bij het bouwen van analytische platforms voor de financiële sector.

Met behulp van low-code en in het bijzonder Datagram is het onder andere mogelijk om het probleem op te lossen van het volgen van de oorsprong van datastroomobjecten met atomiciteit tot aan individuele velden (lineage). Om dit te doen, implementeert de low-code tool een interface met Apache Atlas en Cloudera Navigator. In wezen moet de ontwikkelaar een reeks objecten in Atlas-woordenboeken registreren en naar de geregistreerde objecten verwijzen bij het maken van toewijzingen. Het mechanisme voor het traceren van de oorsprong van gegevens of het analyseren van objectafhankelijkheden bespaart veel tijd wanneer het nodig is om verbeteringen aan te brengen in de berekeningsalgoritmen. Bij het opstellen van financiële overzichten kunt u met deze functie bijvoorbeeld comfortabeler de periode van wetswijzigingen overleven. Hoe beter we de afhankelijkheid tussen vormen in de context van objecten van een gedetailleerde laag begrijpen, hoe minder we “plotselinge” defecten zullen tegenkomen en het aantal herbewerkingen zullen verminderen.

Datakwaliteit & Low-code

Een andere taak die door de low-code-tool in het Mediascope-project werd geïmplementeerd, was de klassetaak Data Quality. Een speciaal kenmerk van de implementatie van de dataverificatiepijplijn voor het onderzoeksbedrijfproject was het gebrek aan impact op de prestaties en snelheid van de belangrijkste gegevensberekeningsstroom. Om onafhankelijke dataverificatiestromen te kunnen orkestreren, werd de al bekende Apache Airflow gebruikt. Toen elke stap van de dataproductie gereed was, werd parallel een afzonderlijk deel van de DQ-pijplijn gelanceerd.

Het wordt als een goede praktijk beschouwd om de kwaliteit van gegevens te monitoren vanaf het moment dat deze in het analytische platform worden geplaatst. Met informatie over metadata kunnen we de naleving van de basisvoorwaarden controleren vanaf het moment dat de informatie de primaire laag binnenkomt - niet nul, beperkingen of externe sleutels. Deze functionaliteit wordt geïmplementeerd op basis van automatisch gegenereerde mappings van de datakwaliteitsfamilie in Datagram. Het genereren van code is in dit geval ook gebaseerd op modelmetagegevens. Bij het Mediascope-project werd de interface uitgevoerd met de metadata van het Enterprise Architect-product.

Door de low-code tool te koppelen aan Enterprise Architect werden automatisch de volgende controles gegenereerd:

Controleren op de aanwezigheid van ‘null’-waarden in velden met de ‘not null’-modifier;
Controleren op de aanwezigheid van duplicaten van de primaire sleutel;
Het controleren van de externe sleutel van een entiteit;
Het controleren van de uniciteit van een string op basis van een set velden.

Voor complexere controles van de beschikbaarheid en betrouwbaarheid van gegevens is een mapping gemaakt met Scala Expression, die als invoer een externe Spark SQL-controlecode gebruikt die is opgesteld door analisten bij Zeppelin.

Uiteraard moet het automatisch genereren van cheques geleidelijk worden gerealiseerd. In het kader van het beschreven project gingen hieraan de volgende stappen vooraf:

DQ geïmplementeerd in Zeppelin-notebooks;
DQ ingebouwd in mapping;
DQ in de vorm van afzonderlijke massieve mappings die een hele reeks controles voor een afzonderlijke entiteit bevatten;
Universele geparametriseerde DQ-toewijzingen die informatie over metadata en bedrijfscontroles als invoer accepteren.

Misschien wel het belangrijkste voordeel van het creëren van een geparametriseerde controleservice is de vermindering van de tijd die nodig is om functionaliteit aan de productieomgeving te leveren. Nieuwe kwaliteitscontroles kunnen het klassieke patroon van het indirect leveren van code via ontwikkel- en testomgevingen omzeilen:

Alle metadatacontroles worden automatisch gegenereerd wanneer het model in EA wordt gewijzigd;
Controles op de beschikbaarheid van gegevens (waarbij de aanwezigheid van gegevens op een bepaald tijdstip wordt bepaald) kunnen worden gegenereerd op basis van een map die de verwachte timing opslaat van het verschijnen van het volgende stukje gegevens in de context van objecten;
Validatiecontroles voor bedrijfsgegevens worden door analisten in Zeppelin-notebooks gemaakt. Van daaruit worden ze rechtstreeks naar de DQ-module-opzettabellen in de productieomgeving gestuurd.

Er zijn geen risico's als scripts rechtstreeks naar productie worden verzonden. Zelfs met een syntaxisfout is het maximale dat ons bedreigt het niet uitvoeren van één controle, omdat de gegevensberekeningsstroom en de startstroom voor de kwaliteitscontrole van elkaar gescheiden zijn.

In wezen draait de DQ-service permanent in de productieomgeving en is hij klaar om met zijn werk te beginnen zodra het volgende stukje gegevens verschijnt.

In plaats Output

Het voordeel van het gebruik van low-code ligt voor de hand. Ontwikkelaars hoeven de applicatie niet helemaal opnieuw te ontwikkelen. En een programmeur die vrij is van extra taken, produceert sneller resultaten. Snelheid maakt op zijn beurt extra tijd vrij voor het oplossen van optimalisatieproblemen. Daarom kunt u in dit geval rekenen op een betere en snellere oplossing.

Natuurlijk is low-code geen wondermiddel, en magie komt niet vanzelf tot stand:

De low-code-industrie maakt een fase van ‘sterker worden’ door en er zijn nog geen uniforme industriële standaarden;
Veel low-code-oplossingen zijn niet gratis, en de aanschaf ervan moet een bewuste stap zijn, die moet worden gezet met het volste vertrouwen in de financiële voordelen van het gebruik ervan;
Veel low-code oplossingen werken niet altijd goed met GIT/SVN. Of ze zijn lastig te gebruiken als de gegenereerde code verborgen is;
Bij het uitbreiden van de architectuur kan het nodig zijn om de low-code oplossing te verfijnen – wat op zijn beurt het effect van “hechting en afhankelijkheid” op de leverancier van de low-code oplossing uitlokt.
Een adequaat beveiligingsniveau is mogelijk, maar het is zeer arbeidsintensief en moeilijk te implementeren in low-code systeemengines. Low-code platforms moeten niet alleen worden gekozen op basis van het principe van het zoeken naar voordelen uit het gebruik ervan. Bij de keuze loont het de moeite om vragen te stellen over de beschikbaarheid van functionaliteit voor toegangscontrole en delegatie/escalatie van identificatiegegevens naar het niveau van het gehele IT-landschap van de organisatie.

Als u echter alle tekortkomingen van het gekozen systeem kent en de voordelen van het gebruik ervan niettemin in de overheersende meerderheid zijn, ga dan zonder angst over op kleine code. Bovendien is de overgang ernaartoe onvermijdelijk – net zoals elke evolutie onvermijdelijk is.

Als één ontwikkelaar op een low-code platform sneller zijn werk doet dan twee ontwikkelaars zonder low-code, dan geeft dit het bedrijf in alle opzichten een voorsprong. De drempel voor toegang tot low-code-oplossingen is lager dan die van ‘traditionele’ technologieën, en dit heeft een positief effect op de problematiek van personeelstekorten. Bij het gebruik van low-code tools is het mogelijk om de interactie tussen functionele teams te versnellen en sneller beslissingen te nemen over de juistheid van het gekozen pad van data science-onderzoek. Low-level platforms kunnen de digitale transformatie van een organisatie aandrijven, omdat de geproduceerde oplossingen kunnen worden begrepen door niet-technische specialisten (met name zakelijke gebruikers).

Als u krappe deadlines, beladen bedrijfslogica, een gebrek aan technologische expertise heeft en uw time-to-market moet versnellen, dan is low-code een manier om aan uw behoeften te voldoen.

Het belang van traditionele ontwikkeltools valt niet te ontkennen, maar in veel gevallen is het gebruik van low-code-oplossingen de beste manier om de efficiëntie van de op te lossen taken te vergroten.

Bron: www.habr.com

Toepassing van low-code in analytische platforms