Anvendelse av lavkode i analytiske plattformer

Kjære lesere, god dag!

Oppgaven med å bygge IT-plattformer for innsamling og analyse av data oppstår før eller siden for ethvert selskap hvis virksomhet er basert på en intellektuelt lastet tjenesteleveransemodell eller skapelse av teknisk komplekse produkter. Å bygge analytiske plattformer er en kompleks og tidkrevende oppgave. Men enhver oppgave kan forenkles. I denne artikkelen vil jeg dele min erfaring med å bruke lavkodeverktøy for å lage analytiske løsninger. Denne erfaringen ble tilegnet under gjennomføringen av en rekke prosjekter i Big Data Solutions-retningen til Neoflex-selskapet. Siden 2005 har Big Data Solutions-retningen til Neoflex håndtert problemene med å bygge datavarehus og innsjøer, løst problemer med å optimalisere hastigheten på informasjonsbehandling og arbeidet med en metodikk for datakvalitetsstyring.

Ingen vil kunne unngå bevisst akkumulering av svakt og/eller sterkt strukturert data. Kanskje selv om vi snakker om små bedrifter. Når alt kommer til alt, når du skalerer en virksomhet, vil en lovende gründer stå overfor problemene med å utvikle et lojalitetsprogram, vil analysere effektiviteten til salgssteder, tenke på målrettet annonsering og bli forundret over etterspørselen etter medfølgende produkter . Til en første tilnærming kan problemet løses "på kneet". Men etter hvert som virksomheten vokser, er det fortsatt uunngåelig å komme til en analytisk plattform.

Men i hvilket tilfelle kan dataanalyseoppgaver utvikle seg til "Rocket Science" klasseproblemer? Kanskje i det øyeblikket vi snakker om virkelig store data.
For å gjøre Rocket Science enklere kan du spise elefanten stykke for stykke.

Jo mer diskrete og autonome applikasjonene/tjenestene/mikrotjenestene dine er, desto lettere vil det være for deg, kollegene dine og hele virksomheten å fordøye elefanten.

Nesten alle våre kunder kom til dette postulatet, etter å ha gjenoppbygd landskapet basert på ingeniørpraksisen til DevOps-teamene.

Men selv med en "separat, elefantinsk" diett, har vi en god sjanse for "overmetning" av IT-landskapet. I dette øyeblikket er det verdt å stoppe, puste ut og se til siden lavkode ingeniørplattform.

Mange utviklere er skremt av utsiktene til en blindvei i karrieren når de beveger seg bort fra å skrive kode direkte mot å "dra" piler i grensesnittet til lavkodesystemer. Men bruken av maskinverktøy førte ikke til at ingeniører forsvant, men brakte arbeidet deres til et nytt nivå!

La oss finne ut hvorfor.

Dataanalyse innen logistikk, telekomindustri, medieforskning, finanssektor er alltid forbundet med følgende spørsmål:

• Hastighet for automatisert analyse;
• Evne til å utføre eksperimenter uten å påvirke hoveddataproduksjonsflyten;
• Pålitelighet av de forberedte dataene;
• Endre sporing og versjonering;
• Dataopprinnelse, Dataavstamning, CDC;
• Rask levering av nye funksjoner til produksjonsmiljøet;
• Og det beryktede: kostnadene ved utvikling og støtte.

Det vil si at ingeniører har et stort antall oppgaver på høyt nivå, som bare kan fullføres med tilstrekkelig effektivitet ved å fjerne bevisstheten om utviklingsoppgaver på lavt nivå.

Forutsetningene for at utviklere skulle flytte til et nytt nivå var utvikling og digitalisering av virksomheten. Verdien av utvikleren endrer seg også: det er en betydelig mangel på utviklere som kan fordype seg i konseptene for virksomheten som automatiseres.

La oss tegne en analogi med programmeringsspråk på lavt og høyt nivå. Overgangen fra språk på lavt nivå til språk på høyt nivå er en overgang fra å skrive «direkte direktiver på maskinvarens språk» til «direktiver på folks språk». Det vil si å legge til et lag med abstraksjon. I dette tilfellet er overgangen til lavkodeplattformer fra programmeringsspråk på høyt nivå en overgang fra "direktiver på folks språk" til "direktiver på forretningsspråket". Hvis det er utviklere som er triste over dette faktum, så har de kanskje vært triste siden det øyeblikket Java Script ble født, som bruker array-sorteringsfunksjoner. Og disse funksjonene har selvfølgelig programvareimplementering under panseret på andre måter med samme høynivåprogrammering.

Derfor er lavkode bare utseendet til et annet abstraksjonsnivå.

Anvendt erfaring med lav kode

Temaet lavkode er ganske bredt, men nå vil jeg gjerne snakke om den praktiske anvendelsen av "lavkodekonsepter" ved å bruke eksemplet fra et av prosjektene våre.

Big Data Solutions-divisjonen til Neoflex spesialiserer seg mer på finanssektoren, bygging av datavarehus og innsjøer og automatisering av ulike rapporteringer. I denne nisjen har bruken av lavkode lenge blitt en standard. Blant andre lavkodeverktøy kan vi nevne verktøy for organisering av ETL-prosesser: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Eller Oracle Apex, som fungerer som et miljø for rask utvikling av grensesnitt for tilgang til og redigering av data. Bruken av utviklingsverktøy med lav kode innebærer imidlertid ikke alltid å bygge svært målrettede applikasjoner på en kommersiell teknologistabel med en klar avhengighet av leverandøren.

Ved å bruke lavkodeplattformer kan du også organisere orkestreringen av datastrømmer, lage datavitenskapelige plattformer eller for eksempel moduler for å sjekke datakvaliteten.

Et av de anvendte eksemplene på erfaring med bruk av lavkodeutviklingsverktøy er samarbeidet mellom Neoflex og Mediascope, en av lederne i det russiske medieforskningsmarkedet. Et av forretningsmålene til dette selskapet er produksjon av data på grunnlag av hvilke annonsører, Internett-plattformer, TV-kanaler, radiostasjoner, reklamebyråer og merkevarer tar beslutninger om kjøp av reklame og planlegger sin markedskommunikasjon.

Medieforskning er et teknologisk belastet forretningsområde. Å gjenkjenne videosekvenser, samle inn data fra enheter som analyserer visning, måling av aktivitet på nettressurser – alt dette innebærer at selskapet har en stor IT-stab og enorm erfaring med å bygge analytiske løsninger. Men den eksponentielle veksten i informasjonsmengden, antallet og variasjonen av kildene tvinger IT-dataindustrien til stadig fremgang. Den enkleste løsningen for å skalere den allerede fungerende analytiske Mediascope-plattformen kan være å øke IT-staben. Men en mye mer effektiv løsning er å få fart på utviklingsprosessen. Et av trinnene som fører i denne retningen kan være bruk av lavkodeplattformer.

På det tidspunktet prosjektet startet hadde selskapet allerede en fungerende produktløsning. Implementeringen av løsningen i MSSQL kunne imidlertid ikke fullt ut oppfylle forventningene til skaleringsfunksjonalitet samtidig som en akseptabel utviklingskostnad ble opprettholdt.

Oppgaven foran oss var virkelig ambisiøs - Neoflex og Mediascope måtte lage en industriell løsning på mindre enn ett år, med forbehold om utgivelsen av MVP innen første kvartal av startdatoen.

Hadoop-teknologistabelen ble valgt som grunnlaget for å bygge en ny dataplattform basert på databehandling med lav kode. HDFS har blitt standarden for datalagring ved bruk av parkettfiler. For å få tilgang til dataene som ligger i plattformen, ble Hive brukt, der alle tilgjengelige butikkfronter presenteres i form av eksterne tabeller. Lasting av data til lagringen ble implementert ved hjelp av Kafka og Apache NiFi.

Lowe-code-verktøyet i dette konseptet ble brukt for å optimalisere den mest arbeidskrevende oppgaven i å bygge en analytisk plattform - oppgaven med databeregning.

Datagramverktøyet med lav kode ble valgt som hovedmekanisme for datakartlegging. Neoflex datagram er et verktøy for å utvikle transformasjoner og dataflyter.
Ved å bruke dette verktøyet kan du gjøre uten å skrive Scala-kode manuelt. Scala-kode genereres automatisk ved hjelp av Model Driven Architecture-tilnærmingen.

En åpenbar fordel med denne tilnærmingen er å fremskynde utviklingsprosessen. Men i tillegg til hastighet er det også følgende fordeler:

• Se innholdet og strukturen til kilder/mottakere;
• Spore opprinnelsen til dataflytobjekter til individuelle felt (avstamning);
• Delvis utførelse av transformasjoner med visning av mellomresultater;
• Gjennomgå kildekoden og justere den før kjøring;
• Automatisk validering av transformasjoner;
• Automatisk datanedlasting 1 i 1.

Barrieren for å komme inn i lavkodeløsninger for å generere transformasjoner er ganske lav: utvikleren trenger å kunne SQL og ha erfaring med å jobbe med ETL-verktøy. Det er verdt å nevne at kodedrevne transformasjonsgeneratorer ikke er ETL-verktøy i vid forstand av ordet. Verktøy med lav kode har kanskje ikke sitt eget kodeutførelsesmiljø. Det vil si at den genererte koden vil bli utført i miljøet som eksisterte på klyngen selv før installering av lavkodeløsningen. Og dette er kanskje enda et pluss for lavkodekarma. Siden det parallelt med et lavkodeteam kan jobbe et «klassisk» team som implementerer funksjonalitet, for eksempel i ren Scala-kode. Å bringe forbedringer fra begge team i produksjon vil være enkelt og sømløst.

Det er kanskje verdt å merke seg at i tillegg til lavkode, finnes det også kodefrie løsninger. Og i kjernen er dette forskjellige ting. Lav kode lar utvikleren forstyrre den genererte koden mer. Når det gjelder Datagram, er det mulig å se og redigere den genererte Scala-koden; no-code gir kanskje ikke en slik mulighet. Denne forskjellen er svært betydelig ikke bare når det gjelder fleksibiliteten til løsningen, men også når det gjelder komfort og motivasjon i arbeidet til dataingeniører.

Løsningsarkitektur

La oss prøve å finne ut nøyaktig hvordan et lavkodeverktøy hjelper til med å løse problemet med å optimalisere hastigheten på utvikling av databeregningsfunksjonalitet. La oss først se på den funksjonelle arkitekturen til systemet. Et eksempel i dette tilfellet er dataproduksjonsmodellen for medieforskning.

Datakilder i vårt tilfelle er svært heterogene og mangfoldige:

• Personmålere (TV-målere) er programvare- og maskinvareenheter som leser brukeratferd fra TV-panelrespondenter – hvem, når og hvilken TV-kanal som ble sett i husstanden som deltar i studien. Den medfølgende informasjonen er en strøm av visningsintervaller knyttet til mediepakken og medieproduktet. Data på stadiet for innlasting i Data Lake kan berikes med demografiske attributter, geostratifisering, tidssone og annen informasjon som er nødvendig for å analysere TV-visning av et bestemt medieprodukt. Målingene som tas kan brukes til å analysere eller planlegge reklamekampanjer, vurdere publikums aktivitet og preferanser og kompilere kringkastingsnettverket;
• Dataene kan komme fra overvåkingssystemer for strømming av TV-sendinger og måling av visning av videoressursinnhold på Internett;
• Måleverktøy i nettmiljøet, inkludert både stedsentriske og brukersentriske målere. Dataleverandøren for Data Lake kan være et nettlesertillegg for forskningsbar og en mobilapplikasjon med innebygd VPN.
• Data kan også komme fra nettsteder som konsoliderer resultatene av å fylle ut online spørreskjemaer og resultatene av telefonintervjuer i bedriftsundersøkelser;
• Ytterligere berikelse av datainnsjøen kan skje ved å laste ned informasjon fra logger til partnerselskaper.

Implementeringen av as is lasting fra kildesystemer til den primære stagingen av rådata kan organiseres på ulike måter. Hvis lav-kode brukes til disse formålene, er automatisk generering av innlastingsskript basert på metadata mulig. I dette tilfellet er det ikke nødvendig å gå ned til nivået for å utvikle kilden for å målrette kartlegginger. For å implementere automatisk lasting, må vi etablere en forbindelse til kilden, og deretter definere listen over enheter som skal lastes i lastegrensesnittet. Katalogstrukturen i HDFS vil bli opprettet automatisk og vil tilsvare datalagringsstrukturen på kildesystemet.

I forbindelse med dette prosjektet bestemte vi oss imidlertid for å ikke bruke denne funksjonen til lavkodeplattformen på grunn av det faktum at Mediascope-selskapet allerede uavhengig har begynt arbeidet med å produsere en lignende tjeneste ved å bruke Nifi + Kafka-kombinasjonen.

Det er verdt å umiddelbart indikere at disse verktøyene ikke er utskiftbare, men snarere komplementære. Nifi og Kafka kan fungere både i direkte (Nifi -> Kafka) og i omvendt (Kafka -> Nifi) forbindelse. For medieforskningsplattformen ble den første versjonen av pakken brukt.

I vårt tilfelle trengte NayFi å behandle ulike typer data fra kildesystemer og sende dem til Kafka-megleren. I dette tilfellet ble meldinger sendt til et spesifikt Kafka-emne ved å bruke PublishKafka Nifi-prosessorer. Orkestrering og vedlikehold av disse rørledningene utføres i et visuelt grensesnitt. Nifi-verktøyet og bruken av Nifi + Kafka-kombinasjonen kan også kalles en lavkodetilnærming til utvikling, som har en lav barriere for innpass i Big Data-teknologier og fremskynder applikasjonsutviklingsprosessen.

Neste trinn i prosjektimplementeringen var å bringe detaljerte data til et enkelt semantisk lagformat. Hvis en enhet har historiske attributter, utføres beregningen i sammenheng med den aktuelle partisjonen. Hvis enheten ikke er historisk, er det valgfritt mulig å enten beregne hele innholdet i objektet på nytt, eller helt nekte å beregne dette objektet på nytt (på grunn av mangelen på endringer). På dette stadiet genereres nøkler for alle enheter. Nøklene lagres i Hbase-katalogene som tilsvarer masterobjektene, som inneholder en korrespondanse mellom nøklene i den analytiske plattformen og nøklene fra kildesystemene. Konsolidering av atomære enheter er ledsaget av berikelse med resultatene av foreløpig beregning av analytiske data. Rammeverket for databeregning var Spark. Den beskrevne funksjonaliteten for å bringe data til en enkelt semantikk ble også implementert basert på kartlegginger fra datagramverktøyet med lav kode.

Målarkitekturen krevde SQL-tilgang til data for forretningsbrukere. Hive ble brukt for dette alternativet. Objekter registreres automatisk i Hive når du aktiverer alternativet "Registrer Hive Table" i lavkodeverktøyet.

Beregningsflytkontroll

Datagram har et grensesnitt for å lage arbeidsflyt-design. Kartlegginger kan startes ved hjelp av Oozie-planleggeren. I strømutviklergrensesnittet er det mulig å lage skjemaer for parallelle, sekvensielle eller utførelsesavhengige datatransformasjoner. Det er støtte for shell-skript og java-programmer. Det er også mulig å bruke Apache Livy-serveren. Apache Livy brukes til å kjøre applikasjoner direkte fra utviklingsmiljøet.

Hvis bedriften allerede har sin egen prosessorkestrator, er det mulig å bruke REST API for å bygge inn kartlegginger i en eksisterende flyt. For eksempel hadde vi ganske vellykket erfaring med å bygge inn kartlegginger i Scala i orkestratorer skrevet i PLSQL og Kotlin. REST API-en til lavkodeverktøyet inkluderer operasjoner som å generere et kjørbart år basert på kartleggingsdesignet, kalle en mapping, kalle en sekvens av tilordninger og, selvfølgelig, sende parametere til URL-en for å kjøre tilordninger.

Sammen med Oozie er det mulig å organisere en kalkulasjonsstrøm ved hjelp av Airflow. Jeg vil kanskje ikke dvele lenge ved sammenligningen mellom Oozie og Airflow, men vil ganske enkelt si at i sammenheng med arbeidet med et medieforskningsprosjekt, falt valget til fordel for Airflow. Hovedargumentene denne gangen var et mer aktivt fellesskap som utviklet produktet og et mer utviklet grensesnitt + API.

Luftstrømmen er også bra fordi den bruker den elskede Python til å beskrive beregningsprosesser. Og generelt er det ikke så mange plattformer for administrasjon av arbeidsflyt med åpen kildekode. Å starte og overvåke utførelsen av prosesser (inkludert et Gantt-diagram) legger bare til poeng til Airflows karma.

Konfigurasjonsfilformatet for lansering av lavkodeløsningskartlegginger har blitt spark-submit. Dette skjedde av to grunner. Først lar spark-submit deg kjøre en jar-fil direkte fra konsollen. For det andre kan den inneholde all nødvendig informasjon for å konfigurere arbeidsflyten (noe som gjør det lettere å skrive skript som genererer Dag).
Det vanligste elementet i Airflow-arbeidsflyten i vårt tilfelle var SparkSubmitOperator.

SparkSubmitOperator lar deg kjøre jars - pakkede Datagram-tilordninger med forhåndsgenererte inngangsparametere for dem.

Det er verdt å nevne at hver Airflow-oppgave kjører i en egen tråd og ikke vet noe om andre oppgaver. Derfor utføres interaksjon mellom oppgaver ved hjelp av kontrolloperatører, som DummyOperator eller BranchPythonOperator.

Samlet førte bruken av Datagram-lavkodeløsningen i forbindelse med universalisering av konfigurasjonsfiler (dannet Dag) til en betydelig akselerasjon og forenkling av prosessen med å utvikle datainnlastingsflyter.

Vis frem beregninger

Det kanskje mest intellektuelt belastede stadiet i produksjonen av analytiske data er trinnet med å bygge utstillingsvinduer. I sammenheng med en av analyseselskapets databeregningsstrømmer, blir dataene på dette stadiet redusert til en referansesending, tatt i betraktning korreksjoner for tidssoner og knyttet til kringkastingsnettet. Det er også mulig å justere for det lokale kringkastingsnettet (lokale nyheter og reklame). Dette trinnet bryter blant annet ned intervallene for kontinuerlig visning av medieprodukter basert på analyse av visningsintervaller. Umiddelbart blir visningsverdiene "vektet" basert på informasjon om deres betydning (beregning av en korreksjonsfaktor).

Et eget trinn i å forberede utstillingsvinduer er datavalidering. Valideringsalgoritmen innebærer bruk av en rekke matematisk vitenskapelige modeller. Bruken av en lavkodeplattform lar deg imidlertid bryte en kompleks algoritme i en rekke separate visuelt lesbare kartlegginger. Hver av kartleggingene utfører en smal oppgave. Som et resultat er mellomliggende feilsøking, logging og visualisering av dataforberedelsesstadier mulig.

Det ble besluttet å diskretisere valideringsalgoritmen i følgende understadier:

• Bygge regresjoner av seeravhengigheter for TV-nettverk i en region med visning av alle nettverk i regionen i 60 dager.
• Beregning av studentiserte residualer (avvik av faktiske verdier fra de som er forutsagt av regresjonsmodellen) for alle regresjonspoeng og for den beregnede dagen.
• Et utvalg av unormale region-nettverkspar, der den studentiserte saldoen for oppgjørsdagen overstiger normen (spesifisert av driftsinnstillingene).
• Omberegning av den korrigerte studentiserte restverdien for unormale region-TV-nettverkspar for hver respondent som så på nettverket i regionen, bestemmer bidraget til denne respondenten (mengden av endring i den studentiserte restverdien) når visningen til denne respondenten ekskluderes fra utvalget .
• Søk etter kandidater hvis ekskludering bringer den studentiserte saldoen på lønningsdagen tilbake til det normale.

Eksemplet ovenfor bekrefter hypotesen om at en dataingeniør allerede har for mye på hjertet... Og hvis dette virkelig er en «ingeniør» og ikke en «koder», så er frykten for faglig forringelse når han bruker lavkodeverktøy. må endelig trekke seg tilbake.

Hva annet kan lav kode gjøre?

Anvendelsesområdet for et lavkodeverktøy for batch- og strømdatabehandling uten behov for manuelt å skrive kode i Scala slutter ikke der.

Bruken av lavkode i utviklingen av datalake har allerede blitt en standard for oss. Vi kan nok si at løsninger basert på Hadoop-stakken følger utviklingsveien til klassiske DWH-er basert på RDBMS. Lavkodeverktøy på Hadoop-stakken kan løse både databehandlingsoppgaver og oppgaven med å bygge endelige BI-grensesnitt. Dessuten bør det bemerkes at BI ikke bare kan bety representasjon av data, men også redigering av det av forretningsbrukere. Vi bruker ofte denne funksjonaliteten når vi bygger analytiske plattformer for finanssektoren.

Blant annet ved hjelp av lavkode og spesielt Datagram er det mulig å løse problemet med å spore opprinnelsen til datastrømobjekter med atomitet ned til individuelle felt (linje). For å gjøre dette implementerer lavkodeverktøyet grensesnitt med Apache Atlas og Cloudera Navigator. I hovedsak må utvikleren registrere et sett med objekter i Atlas-ordbøker og referere til de registrerte objektene når de bygger kartlegginger. Mekanismen for å spore opprinnelsen til data eller analysere objektavhengigheter sparer mye tid når det er nødvendig å gjøre forbedringer i beregningsalgoritmene. For eksempel, når du utarbeider regnskap, lar denne funksjonen deg mer komfortabelt overleve perioden med lovendringer. Tross alt, jo bedre vi forstår avhengigheten mellom formene i sammenheng med objekter i et detaljert lag, desto mindre vil vi møte "plutselige" defekter og redusere antall omarbeidelser.

Datakvalitet og lav kode

En annen oppgave implementert av lavkodeverktøyet på Mediascope-prosjektet var klassen Datakvalitet. Et spesielt trekk ved implementeringen av dataverifiseringsrørledningen for forskningsselskapsprosjektet var mangelen på innvirkning på ytelsen og hastigheten til hoveddataberegningsstrømmen. For å kunne orkestrere uavhengige dataverifiseringsstrømmer ble den allerede kjente Apache Airflow brukt. Ettersom hvert trinn i dataproduksjonen var klart, ble en egen del av DQ-rørledningen lansert parallelt.

Det anses som god praksis å overvåke kvaliteten på data fra det øyeblikket de ble startet i den analytiske plattformen. Ved å ha informasjon om metadata, kan vi kontrollere samsvar med grunnleggende betingelser fra det øyeblikket informasjonen kommer inn i primærlaget - ikke null, begrensninger, fremmednøkler. Denne funksjonaliteten implementeres basert på automatisk genererte tilordninger av datakvalitetsfamilien i Datagram. Kodegenerering i dette tilfellet er også basert på modellmetadata. På Mediascope-prosjektet ble grensesnittet utført med metadataene til Enterprise Architect-produktet.

Ved å pare lavkodeverktøyet med Enterprise Architect ble følgende sjekker automatisk generert:

• Sjekke for tilstedeværelsen av "null"-verdier i felt med "ikke null"-modifikator;
• Kontrollere tilstedeværelsen av duplikater av primærnøkkelen;
• Sjekke fremmednøkkelen til en enhet;
• Sjekke det unike til en streng basert på et sett med felt.

For mer komplekse kontroller av datatilgjengelighet og pålitelighet ble det opprettet en kartlegging med Scala Expression, som tar som input en ekstern Spark SQL-sjekkkode utarbeidet av analytikere hos Zeppelin.

Selvfølgelig må automatisk generering av sjekker oppnås gradvis. Innenfor rammen av det beskrevne prosjektet ble dette innledet med følgende trinn:

• DQ implementert i Zeppelin-notatbøker;
• DQ innebygd i kartlegging;
• DQ i form av separate massive tilordninger som inneholder et helt sett med sjekker for en separat enhet;
• Universelle parameteriserte DQ-tilordninger som godtar informasjon om metadata og forretningssjekker som input.

Den viktigste fordelen med å lage en parameterisert sjekktjeneste er kanskje reduksjonen i tiden det tar å levere funksjonalitet til produksjonsmiljøet. Nye kvalitetskontroller kan omgå det klassiske mønsteret med å levere kode indirekte gjennom utviklings- og testmiljøer:

• Alle metadatasjekker genereres automatisk når modellen endres i EA;
• Datatilgjengelighetskontroller (bestemmer tilstedeværelsen av data på et tidspunkt) kan genereres basert på en katalog som lagrer den forventede timingen for utseendet til neste datastykke i sammenheng med objekter;
• Kontroller for validering av forretningsdata lages av analytikere i Zeppelin-notatbøker. Derfra sendes de direkte til DQ-moduloppsetttabellene i produksjonsmiljøet.

Det er ingen risiko ved å sende skript direkte til produksjon. Selv med en syntaksfeil er det maksimale som truer oss unnlatelse av å utføre én sjekk, fordi databeregningsflyten og kvalitetssjekkens lanseringsflyt er atskilt fra hverandre.

I hovedsak kjører DQ-tjenesten permanent i produksjonsmiljøet og er klar til å begynne arbeidet i det øyeblikket neste data vises.

I stedet for en konklusjon

Fordelen med å bruke lavkode er åpenbar. Utviklere trenger ikke å utvikle applikasjonen fra bunnen av. Og en programmerer som er frigjort fra flere oppgaver, gir resultater raskere. Hastighet frigjør på sin side ekstra tid for å løse optimaliseringsproblemer. Derfor kan du i dette tilfellet regne med en bedre og raskere løsning.

Selvfølgelig er lavkode ikke et universalmiddel, og magi vil ikke skje av seg selv:

• Lavkodeindustrien går gjennom en "bli sterkere" fase, og det er ingen enhetlige industrielle standarder ennå;
• Mange lavkodeløsninger er ikke gratis, og å kjøpe dem bør være et bevisst skritt, som bør gjøres med full tillit til de økonomiske fordelene ved å bruke dem;
• Mange lavkodeløsninger fungerer ikke alltid bra med GIT/SVN. Eller de er upraktiske å bruke hvis den genererte koden er skjult;
• Ved utvidelse av arkitekturen kan det være nødvendig å foredle lavkodeløsningen - noe som igjen provoserer effekten av "tilknytning og avhengighet" hos leverandøren av lavkodeløsningen.
• Et tilstrekkelig sikkerhetsnivå er mulig, men det er svært arbeidskrevende og vanskelig å implementere i systemmotorer med lav kode. Lavkodeplattformer bør velges ikke bare ut fra prinsippet om å søke fordeler ved bruken av dem. Ved valg er det verdt å stille spørsmål om tilgjengeligheten av funksjonalitet for tilgangskontroll og delegering/eskalering av identifikasjonsdata til nivået i hele IT-landskapet i organisasjonen.

Imidlertid, hvis alle manglene ved det valgte systemet er kjent for deg, og fordelene ved bruken av det likevel er i det dominerende flertallet, så gå videre til liten kode uten frykt. Dessuten er overgangen til det uunngåelig – akkurat som enhver evolusjon er uunngåelig.

Hvis én utvikler på en lavkodeplattform gjør jobben sin raskere enn to utviklere uten lavkode, så gir dette selskapet et forsprang på alle måter. Terskelen for å komme inn i lavkodeløsninger er lavere enn i «tradisjonelle» teknologier, og dette har en positiv effekt på spørsmålet om personalmangel. Når du bruker lavkodeverktøy, er det mulig å fremskynde interaksjonen mellom funksjonelle team og ta raskere beslutninger om riktigheten av den valgte banen til datavitenskapelig forskning. Lavnivåplattformer kan drive den digitale transformasjonen av en organisasjon fordi løsningene som produseres kan forstås av ikke-tekniske spesialister (spesielt forretningsbrukere).

Hvis du har stramme tidsfrister, lastet forretningslogikk, mangel på teknologisk ekspertise, og du trenger å fremskynde tiden til markedet, så er lav kode én måte å møte dine behov.

Det er ikke å nekte for viktigheten av tradisjonelle utviklingsverktøy, men i mange tilfeller er bruk av lavkodeløsninger den beste måten å øke effektiviteten på oppgavene som løses.

Kilde: www.habr.com