🥇Low-code rakendamine analüütilistes platvormides

Lugupidamine, head päeva!

IT-platvormide loomise ülesanne andmete kogumiseks ja analüüsimiseks tekib varem või hiljem igas ettevõttes, mille äri põhineb keerulisel teenuse osutamise mudelil või tehnoloogiliselt keerukate toodete loomisel. Analüütiliste platvormide väljatöötamine on keeruline ja töömahukas ülesanne. Siiski võib iga ülesande lihtsustamiseks leida võimalusi. Selles artiklis tahan jagada oma kogemusi low-code-tööriistade rakendamisest, mis aitavad luua analüütilisi lahendusi. See kogemus on saadud ettevõtte „Neoflex” Big Data Solutions suunalise projektide elluviimisel. Big Data Solutions suund ettevõttes „Neoflex” on alates 2005. aastast tegelenud andmete ladude ja järvede ülesehitamise küsimustega, lahendab teabe töötlemise kiirusprobleeme ning töötab välja andmekvaliteedi haldamise metoodikat.

Keegi ei pääse tõeliselt teadlikult vältimast nõrgalt ja/või tugevalt struktureeritud andmete kogumist. Isegi väikeettevõtte puhul. Kui ettevõte kasvab, seisab ambitsioonikas ettevõtja silmitsi küsimustega, nagu lojaalsusprogrammi arendamine, müügipunktide tõhususe analüüs, sihitud reklaam ja vajadus lisatoodete järele. Esialgu võib probleem isegi lahendada „kümne sõrme” meetodil. Kuid ettevõtte laienemisega muutub analüütikaplatvormi kasutamine paratamatuks.

Kuid millal võivad andmeanalüütika ülesanded muutuda tõeliselt keerukateks? Samal hetkel, kui on juttu tõeliselt suurtest andmetest.
Tõeliselt keerulise ülesande lihtsustamiseks võib porkna süüa osade kaupa.

Mida suurem on teie rakenduste/teenuste/mikroteenuste diskreetne ja iseseisev struktuur, seda lihtsam on teil, teie kollegidel ja kogu ettevõttel 'sööda' suur porkna.

Sellele postulaadile on jõudnud praktiliselt kõik meie kliendid, muutes oma maastikku, põhinedes DevOps-meeskondade inseneritavadel.

Kuid isegi „eraldiseisva, elevandi“ dieedi korral on meil head võimalused IT-maastiku „ülekülluse“ saamiseks. Sel hetkel tasub peatuda, hingata välja ja vaadata poole. low-code inseneritehnoloogia platvorm.

Paljusid arendajaid hirmutab perspektiiv karjäärilõksust, liikudes otsekohe kodeerimisest „lohistamise“ suunas low-code süsteemide UI-liidestes. Kuid masinate tulek ei viinud insenere kadumiseni, vaid tõstis nende töö uuele tasemele!

Vaatame, miks.

Andmeanalüüs logistikas, telekommunikatsiooni sektoris, meediauuringutes, rahanduse valdkonnas on alati seotud järgmiste küsimustega:

Automatiseeritud analüüsi läbiviimise kiirus;
Eksperimentide läbiviimise võimalus ilma andmevoogude põhivoolu mõjutamata;
Valmistatud andmete usaldusväärsus;
Muudatuste jälgimine ja versioonihaldus;
Andmete päritolu, andmete radade jälgimine, CDC;
Uute funktsioonide kiire kohaletoimetamine tootmiskeskkonda;
Ja kurikuulus: arendamise ja hooldamise kulu.

See, inseneritel on tohutult palju kõrgetasemelisi ülesandeid, mille täitmine efektiivselt on võimalik vaid madalate arendustegevuste mõtetest vabanemisega.

Arendajate uuele tasemele ülemineku eeltingimuseks on olnud äri areng ja digitaliseerimine. Arendaja väärtus on samuti muutunud: puudus on arendajatest, kes suudavad süveneda automatiseeritava äri kontseptsioonide olemusse.

Vaatame, kuidas madalama ja kõrgema taseme programmeerimiskeeled omavahel seonduvad. Üleminek madalama taseme keeltest kõrgema taseme keelte suunas tähendab, et liigume „otsekäskudelt rauale” „inimkeeles käskudeni”. See tähendab, et lisandub teatud abstraktsioonikiht. Seega, üleminek low-code platvormidele kõrgema taseme programmeerimiskeeltelt on nagu üleminek „inimkeeles käskudelt” „äri keeles käskudele”. Kui leidub arendajaid, kellele see fakt muret teeb, siis võivad nad olla mures juba alates hetkest, mil JavaScript ilmavalgust nägi, kus kasutatakse massiivi sorteerimise funktsioone. Need funktsioonid, loomulikult, sisaldavad teisi programmeerimisvahendeid sama kõrgema taseme programmeerimise all.

Seega on low-code lihtsalt veel ühe abstraktsioonikihi ilmumine.

Praktiline kogemus low-code'i kasutamisest

Low-code teema on piisavalt lai, kuid täna sooviksin rääkida „vähe kodeerimise kontseptsioonide” praktilisest rakendamisest ühe meie projekti näitel.

ProHoster-i Big Data Solutions divisjon keskendub peamiselt finantssektorile, luues andmesalvestusi ja andmejärvede ning automatiseerides erinevat aruandlust. Selles valdkonnas on madala koodiga lahenduste kasutamine juba pikka aega standardiks kujunenud. Muuhulgas võib nimetada ETL-protsesside korraldamiseks mõeldud madala koodi tööriistu: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Või Oracle Apex, mis toimib kiire arenduse keskkonnana andmete juurdepääsu ja redigeerimise jaoks. Siiski ei ole madala koodi arendustööriistade kasutamine alati seotud kitsaste rakenduste loomisega kommerts-tehnoloogiakuhjal, millel on selgelt väljendatud tarnija sõltuvus.

Madala koodiga platvormide abil on võimalik korraldada ka andmevoogude orkestreerimist, luua andmete teaduse platvorme või näiteks andmekvaliteedi kontrollimise mooduleid.

Üheks näidisprojekti kogemuse näidiseks madalkoodide arendustööriistade kasutamiseks on koostöö "Neoflex" ja Mediascope'i vahel, mis on üks Venemaa meediauuringute turuliidreid. Selle ettevõtte äriüheks ülesandeks on andmete tootmine, mille põhjal reklaamijad, Interneti-platvormid, televisioonikanalid, raadiojaamad, reklaamiagentuurid ja brändid teevad reklaamiostuotsuseid ja planeerivad oma turunduskommunikatsiooni.

Meediauuringud on tehnoloogiliselt keeruline äritase. Videojärje tundmine, andmete kogumine seadmetest, mis analüüsivad vaatamist, tegevuse mõõtmine veebiresurssidel – see kõik eeldab ettevõttelt suurt IT-meeskonda ja tohutut kogemust analüüsilahenduste loomisel. Kuid info koguse ja allikate arvu eksponentsiaalne kasv sunnib IT-andmete tööstust pidevalt arenema. Mediascope'i juba toimiva analüüsiplatvormi laiendamise kõige lihtsam lahendus oleks võinud olla IT-meeskonna suurendamine. Kuid palju tõhusam lahendus on arenduse protsessi kiirendamine. Üheks sammuks selle suunas võiks olla madala koodisisestusega platvormide kasutamine.

Projekt algas juba töövalmis produkti lahendusega. Siiski, MSSQL-lahenduse rakendamine ei suutnud täielikult vastata ootustele funktsionaalsuse suurendamise osas, säilitades samas rahuldava täiendustasu.

Meie ees seisnud ülesanne oli tõeliselt ambitsioonikas – «Neoflex» ja Mediascope pidid välja töötama tööstusliku lahenduse vähem kui aasta jooksul, kusjuures MVP pidanuks valmima juba esimese kvartali jooksul alates tööde algusest.

Uue andmeplatvormi põhjana, mis põhineb low-code-arvutustel, valiti tehnoloogiate virn Hadoop. Andmete salvestamise standardiks sai HDFS, kasutades parquet formaadis faile. Andmetele, mis asuvad platvormil, päästakse juurde Hive'i kaudu, kus kõik saadaval olevad vitriinid on esitatud väliste tabelitena. Andmete laadimine salvestusse toimus Kafka ja Apache NiFi abiga.

Low-code-tööriista kasutati selles kontseptsioonis töövoogude optimeerimiseks, et vähendada kõige töömahukamat ülesannet analüütilise platvormi koostamisel – andmete arvutamise ülesannet.

Andmete mappimiseks valiti põhimehhanismiks low-code-tööriist Datagram. Neoflex Datagram on vahend transformatsioonide ja andmevoogude arendamiseks.
Käesoleva tööriista kasutamine võimaldab vältida Scala koodi käsitsi kirjutamist. Scala kood genereeritakse automaatselt Model Driven Architecture lähenemist kasutades.

Selge pluss selle lähenemise juures on arendusprotsessi kiirendamine. Kuid kiirusest lisaks on ka teised eelised:

Allikate/sihtkohtade sisu ja struktuuri vaatamine;
Andmevoogude objektide päritolu jälgimine kuni üksikute väljadeni (lineage);
Muundamiste osaline täitmine, vaadates vahepealseid tulemusi;
Allika koodi vaatamine ja selle parandamine enne täitmist;
Automaatne muundamiste valideerimine;
Automaatne andmete laadimine 1:1.

Low-code lahenduste lävendi saavutamine transformatsioonide genereerimiseks on piisavalt madal: arendajal on vajalik teada SQL-i ja omada kogemusi ETL-tööriistadega. Samas tuleb märkida, et code-driven genereerijad ei ole ETL-tööriistad laiemas mõttes. Low-code tööriistadel võib puududa oma keskkond koodi täitmiseks. See tähendab, et genereeritud kood töötatakse välja keskkonnas, mis oli klastris enne low-code lahenduse installimist. Ja see on ilmselt veel üks pluss low-code’i kasuks. Kuna parallel on low-code meeskonna kõrval aktiivne ka "klassikaline" meeskond, kes rakendab funktsionaalsust näiteks puhtal Scala-koodil. Mõlema meeskonna muudatuste toomine tootmisse saab olema lihtne ja "juhtmeta".

Võib-olla tasub mainida, et lisaks low-code lahendustele on olemas ka no-code lahendused. Need on põhimõtteliselt erinevad asjad. Low-code võimaldab arendajal rohkem sekkuda genereeritud koodi. Datagrami puhul on võimalik vaadata ja redigeerida genereeritud Scala koodi, kuid no-code ei pruugi sellist võimalust pakkuda. See erinevus on märkimisväärne mitte ainult lahenduse paindlikkuse, vaid ka andmeinseneride töö mugavuse ja motivatsiooni osas.

Lahenduse arhitektuur

Proovime aru saada, kuidas low-code tööriist aitab lahendada andmete arvutamise funktsionaalsuse arendamise kiirusprobleemi. Esiteks analüüsime süsteemi funktsionaalset arhitektuuri. Antud juhul on näitena toodud andmete tootmise mudel meediauuringute jaoks.

Meie puhul on andmeallikad väga mitmekesised ja erinevad:

Peoplemeters (TV meters) — software-hardware devices that read user behavior from respondents of the television panel — who, when, and which TV channel was watched in the household participating in the study. The provided information consists of a stream of viewing intervals linked to the media package and media product. Data at the loading stage into the Data Lake can be enriched with demographic attributes, geographic references, time zones, and other information needed for analyzing viewing habits of specific media products. The measurements taken can be used for analysis or planning advertising campaigns, assessing audience activity and preferences, and scheduling broadcasts.
Data may come from monitoring systems of streaming television and measuring content viewing on internet video resources.
Measurement tools in the web environment, including both site-centric and user-centric counters. A browser extension research bar and a mobile application with built-in functionality can serve as data providers for the Data Lake. VPN.
Andmed võivad samuti pärineda saitidelt, mis konsolideerivad online-küsimustike täitmise tulemusi ja telefonintervjuude tulemusi ettevõtte uuringutes;
Andmejärve täiendav rikastamine võib toimuda partnerettevõtete logide andmete laadimise kaudu.

Allikate süsteemidest toore andmete esmase staging'u laadimise rakendamine as is võib olla organiseeritud erinevalt. Kui kasutada low-code lahenduseid, on võimalik automaatne lähetuslaadimisstsenaariumide genereerimine metandmete põhjal. Sellisel juhul ei ole vajalik laskuda source to target mappide tasemele. Automaatse laadimise teostamiseks on vajalik luua ühendus allikaga, pärast mida tuleb laadimisliideses määrata laadimise alla kuuluvate üksuste loend. Kataloogistruktuuri loomine HDFS-is toimub automaatselt ja vastab allikasse salvestamise struktuurile.

Kuid selle projekti kontekstis otsustasime seda low-code platvormi võimalust mitte kasutada, kuna Mediascope on juba iseseisvalt käivitanud samalaadse teenuse loomise Nifi + Kafka kombinatsioonil.

Oluline on kohe öelda, et need tööriistad ei ole omavahel vahetatavad, vaid pigem täiendavad teineteist. Nifi ja Kafka suudavad töötada nii otseses (Nifi -> Kafka) kui ka tagurpidi (Kafka -> Nifi) seoses. Meediauuringute platvormil kasutati esimest seose varianti.

Meie juhtumi puhul pidi Nifi töötlema erinevat tüüpi andmeid allikatest ning edastama need Kafka vahendajale. Samuti suunati sõnumite saatmine kindlasse Kafka teema Nifi PublishKafka protsessorite abil. Nende pipeline'ide koordineerimine ja haldamine toimub visuaalses liideses. Tööriista Nifi ja Nifi + Kafka kombinatsiooni võib samuti nimetada low-code lähenemiseks arendusele, millel on madal sisenemise piir tehnoloogiatesse Big Data ning mis kiirendab rakenduste arendamise protsessi.

Järgmine etapp projekti elluviimisel hõlmas detailsete andmete ühtse semantilise kihi vormingusse toomist. Ajalooliste atribuutidega entiteedi korral toimub arvutus arvestatava partitsiooni kontekstis. Kui entiteet ei ole ajalooline, on võimalik kas kogu objekti sisu ümberarvutamine või selle objekti ümberarvutamisest loobumine (muutuste puudumise tõttu). Selles etapis genereeritakse võtmed kõigi entiteetide jaoks. Võtmed salvestatakse vastavatesse Hbase'i põhielementide registritesse, mis sisaldavad seoseid analüütilise platvormi võtmete ja allika süsteemide võtmete vahel. Aatomaarsete entiteetide konsolideerimine käib eelnevalt arvutatud analüütiliste andmete rikastamisega. Andmete arvutamise raamistikuks oli Spark. Kirjeldatud funktsionaalsus andmete ühtse semantika saavutamiseks viidi ellu samuti low-code-tööriista Datagram kaardistuste baasil.

Sihtarhitektuuris oli vajalik, et SQL-juurdepääs andmetele oleks ärikasutajatele tagatud. Selle võimaluse jaoks kasutati Hive'i. Hive'i objektide registreerimine toimub automaatselt, kui madalkooditööriista „Registr Hive Table“ funktsioon on aktiivne.

Arvutuse voo haldamine

Datagramil on liides töövoogude disaini loomiseks. Kaardistuste käivitamine võib toimuda Oozie ajastaja abil. Töövoogude arendaja liideses on võimalik luua andmete töötlemise muundamiste paralleelseid, järjestikulisi või tingimuslike skeeme. Toetatakse shell skripte ja java programme. Samuti on võimalik kasutada serverile Apache Livy'd. Apache Livy't kasutatakse rakenduste käivitamiseks otse arenduskeskkonnast.

Kui ettevõttel on juba olemas oma protsesside orkestratsioon, on võimalik kasutada REST API-d, et integreerida mappimisi juba olemasolevasse voogu. Näiteks oleme saanud piisavalt edukat kogemust mappimiste integreerimisel Scalasse, mis on kirjutatud PLSQL ja Kotlinis. Madala koodiga tööriista REST API hõlmab selliseid operatsioone nagu käivitatava aasta genereerimine mappimise kujunduse põhjal, mappimise väljakutse, mappimise järjestuse väljakutse ja loomulikult parameetrite edastamine URL-is mappimiste käivitamiseks.

Oozie kõrval on võimalik korraldada arvutusvoog Airflow abil. Ma ei hakka pikalt peatuma Oozie ja Airflow võrdlemisel, vaid ütlen lihtsalt, et meediauurimiste projekti kontekstis langes valik Airflow kasuks. Peamisteks argumentideks olid seekord aktiivsem kogukond, mis arendab toodet, ja arenenum liides + API.

Airflow on samuti hea, sest protsesside arvutamiseks kasutatakse paljude lemmikprogrammi Pythonit. Üldiselt ei ole avatud lähtekoodiga töövoogude haldamise platvorme nii palju. Protsesside käivitamine ja jälgimine (sealhulgas Gantti diagramm) annab Airflow'le lisapunkte.

Konfiguratsioonifaili vorminguks low-code lahenduse käivitamiseks sai spark-submit. See juhtus kahe põhjuse tõttu. Esiteks võimaldab spark-submit otse käivitada jar-faili konsoolist. Teiseks võib see sisaldada kogu vajalikku teavet töövoo konfigureerimiseks (mis lihtsustab skriptide kirjutamist, mis genereerivad Dag'i).
Meie juhul on kõige sagedamini esinev Airflow töövoo element SparkSubmitOperator.

SparkSubmitOperator võimaldab käivitada jar'e - pakitud Datagrami kaarte, mille jaoks on eelnevalt valmistatud sisendparameetrid.

Oluline on mainida, et iga Airflow ülesanne täidetakse eraldi lõimes ja ei tea teistest ülesannetest midagi. Seetõttu toimub ülesannetevaheline suhtlemine haldamisoperatsioonide, näiteks DummyOperator või BranchPythonOperator, kaudu.

Low-code lahenduse Datagram kasutamine koos konfiguratsioonifailide universaliseerimisega (mis moodustavad Dag) on toonud kaasa märkimisväärse kiirusetõusu ja arendusprotsessi lihtsustamise andmevoogude loomisel.

Vitrinite arvutamine

Tõenäoliselt on kõige kõrgemal tasemel vaimselt laetud etapp analüüsandmete tootmisel just vitrinide loomine. Ühe andmevoo analüüsimisel toimub sel etapil viidatud standardse tõlke kohandamine, arvestades ajavööndite korrektiive seostudes edastamisvõrguga. Samuti on võimalik kohandada kohaliku edastamise võrku (kohalikud uudised ja reklaam). Selles etapis jagatakse pideva vaatamise ajaklussed meedia toodete vaatamise ajavahemike analüüsi alusel. Siin toimub ka vaatamise väärtuste „kaalumine” nende olulisuse info alusel (korrektuuriteguri arvutamine).

Üks samm vitriinide ettevalmistamisel on andmete valideerimine. Valideerimise algoritm on seotud mitmete matemaatiliste teadusmudelite rakendamisega. Ent madala koodiga platvormi kasutamine võimaldab keerulise algoritmi jagada mitmeks eraldi visuaalselt loetavaks kaartimiseks. Iga kaartimine täidab konkreetset ülesannet. Selle tulemusena on võimalik vahepealne silumine, logimine ja andmete ettevalmistamise etappide visualiseerimine.

Valideerimise algoritmi otsustati diskreetida järgmisteks alamsammudeks:

Regressioonide koostamine, mis seob telekanali vaatamised piirkonnas kõikide võrkude vaatamistega piirkonnas 60 päeva jooksul.
Stjuuditeeritud jääkide arvutamine (reaalsete väärtuste kõrvalekalle regressioonimudeli ennustatud väärtustest) kõigi regressioonipunktide ja arvestuspäeva jaoks.
Anomaalsete piirkond-telekanali paaride valimine, kus arvestuspäeva stjuuditeeritud jääk ületab normi (mis on määratud operatsiooni seadistustega).
Korrigeeritud studentiseeritud jäägi ümberarvutamine anomaalsete piirkondade-televõrkude paaride jaoks iga vastaniku puhul, kes vaatas võrgustikku piirkonnas, määrates selle vastaniku panuse (studentiseeritud jäägi muutuse suurus), jättes välja selle vastaniku vaatamise valimist.
Kandidaatide otsimine, kelle välistamine toob arvutuspäeva studentiseeritud jäägi normaali.

Ülaltoodud näide kinnitab hüpoteesi, et andmealusel inseneril on juba liiga palju mõtteid peas… Ja kui see tõesti on 'insener', mitte 'kooder', siis madala koodiga tööriistade kasutamise professionaalse languse hirm peaks tema jaoks lõpuks kaduma.

Mida veel madala koodiga teha saab?

Madalakoodiliste tööriistade kasutusala pakett- ja vooluandmete töötlemisel ilma Scala käsitsi kodeerimise vajaduseta ei lõppe.

Low-code kasutamine datalake'ide arenduses on meie jaoks juba muutunud teatud standardiks. Võib öelda, et Hadoopi stekil põhinevad lahendused järgivad klassikaliste RDBMS-ide põhiste DWH-de arenguteed. Hadoopi stekil põhinevad madalkoodilised tööriistad suudavad lahendada nii andmete töötlemise ülesandeid kui ka lõpp-BI-liideste loomise ülesandeid. Samas tuleb märkida, et BI mõiste ei tähenda ainult andmete esitlust, vaid ka nende redigeerimist ärikasutajate poolt. Seda funktsionaalsust kasutame sageli analüütiliste platvormide loomisel finantssektori jaoks.

Muuhulgas lahendab low-code, eriti Datagram, andmevoogude objektide päritolu jälgimise ülesande, saavutades atomaarse taseme eraldi väljade osas (lineage). Selleks on low-code tööriistas rakendatud ühendus Apache Atlase ja Cloudera Navigatoriga. Sisuliselt peab arendaja registreerima objektide kogumi Atlase sõnastikes ja viitama registreeritud objektidele mappide loomisel. Andmete päritolu jälgimise mehhanism või objektide sõltuvuste analüüs säästab suures koguses aega, kui on vaja teha muudatusi arvutuste algoritmides. Näiteks finantsaruannete koostamisel aitab see funktsioon mugavamalt üle elada seadusandlikke muudatusi. Mida paremini me mõistame vormidevahelist sõltuvust detailse kihi objektide lõikes, seda vähem kohtame 'üllatavaid' defekte ja vähendame ümbertegemiste arvu.

Andmete kvaliteet & low-code

Veel ülesandeid, mille on rakendanud low-code tööriist ettevõttes Mediascope, on andmekvaliteedi klassi ülesanne. Andmekontrolli konveieri rakendamise eripära uurimisettevõtte projektis oli see, et see ei mõjutanud andmete peamise arvutustöötluse toimimist ja kiirus. Andmete kontrollimisprotsesside iseseisvaks orkestreerimiseks kasutati juba tuttavat Apache Airflow'd. Iga andmebaasi tootmisetapi valmisolekul käivitati paralleelselt eraldiseisev DQ konveier.

Hea praktikana peetakse andmete kvaliteedi jälgimist juba andmete tekkimise hetkest analüütilises platvormis. Omades teavet metaandmete kohta, saame kontrollida põhitingimuste täitmist — not null, constraints, foreign keys — juba siis, kui teave jõuab esmasesse kihti. See funktsionaalsus on rakendatud automaatselt genereeritavate mappide baasil data quality peres Datagram'is. Koodigeneratsioon põhineb samuti mudeli metaandmetel. Ettevõttes Mediascope toimus sidumine Enterprise Architect'i toote metaandmetega.

Aitäh madala koodiga tööriista ja Enterprise Architecti ühendamise eest on automaatselt genereeritud järgmised kontrollid:

Kontroll väärtuste «null» olemasolu väljade puhul, mille modifikaator on «not null»;
Kontroll primaarvõtme dubleeritud olemasolu;
Kontroll once-entity välisvõtme olemasolu;
Kontroll unikaalsuse olemasolu rida kombinatsiooni alusel;

Töötlemiseks, et saada rohkem keerulisi kontrolli kättesaadavuse ja usaldusväärsuse andmeid, loodi mapp Scala väljendiga, mis võtab sisendina välise Spark SQL-koodi, mille analüütikud ette valmistasid Zeppelinis.

Loomulikult peab automaatsete kontrollide genereerimine toimuma järk-järgult. Kirjeldatud projekti raames eelnesid järgmised sammud:

DQ, mis on loodud Zeppelinis olevates märkmikes;
DQ, mis on integreeritud mappimisse;
DQ eraldi massiivsete kaardistuste kujul, mis sisaldavad kogu kontrollide kogumit üksiku üksuse jaoks;
Üksikute parameetriseeritud DQ-mappimised, mis võtavad sisendina teavet metaandmete ja äri kontrollide kohta.

Tõenäoliselt on peamine eelis parameetritest sõltuvate kontrollide teenuse loomisel funktsionaalsuse tootmisüksusesse toimetamise aja lühendamine. Uued kvaliteedikontrollid võivad mööda minna klassikalisest koodi edastamise mustrist, mis toimub arendus- ja testikeskkondade kaudu.

Kõik metaandmete kontrollid genereeritakse automaatselt, kui mudel EA-s muutub;
Andmete kättesaadavuse kontrollid (mis määravad, kas mingid andmed on antud ajahetkel olemas) võivad põhineda registril, mis salvestab järgmise andmepartii ootamatut ajakava objektide lõikes;
Ärikontrollide andmete tõepärasuse kohta loovad analüütikud Zeppelin'i notebook'ides. Need suunatakse otse DQ moduuli seadistuslauadesse tootmiskeskkonnas.

Otsese skriptide tootmisse laadimise riskid puuduvad. Isegi süntaktilise vea korral on see, mis meid ähvardab, maksimaalselt ühe kontrolli ebaõnnestumine, kuna andmete arvutamise voog ja kvaliteedikontrollide käivitamise voog on üksteisest lahus.

DQ teenus töötab pidevalt tootmisvõttes ja on valmis alustama oma tööd kohe, kui järgmine andmepartii saadakse.

Kokkuvõtte asemel

Low-code'i kasutamine toob selged eelised. Arendajad ei pea rakendust "nullist" arendama. Ja vähem tööd tegelev arendaja toob tulemuse kiiremini. Kiirus vabastab omakorda lisaaja ressurssi optimeerimise küsimuste lahendamiseks. Seega võib antud juhul oodata kvaliteetsemat ja kiiremat lahendust.

Muidugi, low-code ei ole imerelv ja ime ei juhtu iseenesest:

Low-code tööstus läbib "tugevnemise" etappi ning hetkel puuduvad sellised homogeensed tööstusstandardid;
Paljud low-code lahendused ei ole tasuta ning nende soetamine peab olema teadlik otsus, mille tegemiseks peab olema täielik kindlus nende kasutamise rahalist kasu toomisest;
Paljud madala koodiga lahendused ei pruugi alati hästi toimida GIT / SVN-iga. Või on ebamugavad kasutada, kui genereeritud kood on varjatud.
Arhitektuuri laiendamisel võib olla vajalik madalkoodide lahenduse täiendamine, mis omakorda tekitab „sidumise ja sõltuvuse“ efekti madalkoodide lahenduse pakkujast.
Nõutud turvalisustase on võimalik, kuid madalkoodide süsteemide mootorite rakendamine on äärmiselt töömahukas ja keeruline. Madalkoodide platvormid ei tohiks valituks osutuda ainult kasuotsimise põhimõtte järgi. Valiku tegemisel tuleks mõelda juurdepääsu haldamise ja identiteediandmete volitamise/escalatsiooni funktsionaalsuse olemasolule kogu organisatsiooni IT-maastikul.

Kuid kui kõik valitud süsteemi puudused on teile teada ning selle kasutamisest saadav kasu on sellegipoolest domineeriv, siis liikuge madalkoodi suunas kartmata. Eriti, kuna selle suunas liikumine on vältimatu – nagu igasugune evolutsioon.

Kui üks arendaja madala koodi platvormil teeb oma tööd kiiremini kui kaks arendajat ilma madala koodita, annab see ettevõttele eelise igas mõttes. Madala koodi lahenduste sissepääsukünnis on madalam kui traditsiooniliste tehnoloogiate puhul, mis positiivselt mõjutab personalipuuduse küsimust. Madala koodi tööriistade kasutamine võib kiirendada koostööd funktsionaalsete meeskondade vahel ja võimaldada kiiremaid otsuseid andmete teaduslike uurimiste õigustatuse kohta. Madala koodi platvormid võivad olla organisatsiooni digitaalsete transformatsioonide ajendiks, kuna loodud lahendused võivad olla arusaadavad mitte-tehnilistele spetsialistidele (eriti ärikasutajatele).

Kui teil on ajakava pingeline, äärmiselt keeruline äriloogika, tehnoloogilisest ekspertiisist puudus ning vajate time to marketi kiirusest suurendamist, siis madala koodi lahendus on üks viis teie vajaduste rahuldamiseks.

Ei saa eitada traditsiooniliste arendustööriistade tähtsust, kuid paljudel juhtudel on madala koodisisaldusega lahenduste kasutamine parim viis tõhususe suurendamiseks.

Allikas: habr.com