🥇Madala koodi rakendamine analüüsiplatvormidel

Lugupidajad, tere päevast!

IT-platformide loomise ülesanne andmete kogumiseks ja analüüsimiseks tekib varem või hiljem igas ettevõttes, mille ärimudel toetub intellektuaalselt keeruliste teenuste osutamisele või tehniliselt keerukate toodete loomisele. Analüütiliste platvormide rajamine on keeruline ja aeganõudev ülesanne. Siiski on igat ülesannet võimalik lihtsustada. Käesolevas artiklis soovin jagada kogemusi low-code-tööriistade rakendamisel analüütiliste lahenduste loomisel. See kogemus on saadud mitmete Big Data Solutions projekti elluviimisel ettevõttes "Neoflex". Ettevõtte "Neoflex" Big Data Solutions suunitluses tegeletakse alates 2005. aastast andmete hoidlate ja järvede loomise küsimustega, lahendatakse teabe töötlemise kiirusenõudmisi ja töötatakse välja andmekvaliteedi juhtimise metoodikat.

Teadlikult madala ja/või kõrge struktuuriandmete kogumisel ei pääse keegi. Tõenäoliselt isegi mitte väikeettevõte. Kui ettevõte kasvab, satub tulevikus optimistlik ettevõtja silmitsi lojaalsusprogrammi arendamise, müügikohtade efektiivsuse analüüsiga, käivitab sihitud reklaami ja mõtleb lisatoodete nõudlusele. Esialgselt saab probleemi lahendada "hõlpsalt". Kuid ettevõtte kasvu korral on analüütilisele platvormile üleminek vältimatu.

Kuid millal võivad andmeanalüüsi ülesanded muutuda "Rocket Science"-i kategooriaks? Tõenäoliselt siis, kui on tõeliselt suurtest andmetest jutt.
Et ülesannet "Rocket Science" lihtsustada, võib hea idee olla "sööda elevanti tükkideks".

Mida suurem on teie rakenduste/teenuste/mikroteenuste diskreetne ja autonoomne kontseptsioon, seda lihtsam on teil, teie kolleegidel ja kogu ettevõttel elevanti Seedida.

Selle postulaadi on mõistnud praktiliselt kõik meie kliendid, kes on ümber kujundanud maastiku, tuginedes DevOps meeskondade inseneritavadele.

Kuid isegi "eraldi, elevanti-küllastunud" dieediga on meil head võimalused IT-maastiku "üleküllastamiseks". Sel hetkel tasub peatuda, sügada ja vaadata poole low-code engineering platform.

Paljude arendajate jaoks on hirm, et karjäär võib takerduda, kui liikuda koodikirjutamisest low-code süsteemide „ui-interfaces“ lohistamise suunas. Kuid masinate tulek ei tähendanud inseneride kadumist, vaid tõstis nende töö uuele tasemele!

Vaatame, miks.

Andmete analüüs logistikasektoris, telekommunikatsioonitööstuses, meediauuringute valdkonnas ja rahanduses on alati seotud järgmiste küsimustega:

Automatiseeritud analüüsi teostamise kiirus;
Eksperimentide läbiviimise võimalus ilma peamise andmete tootmisvoo mõjutamisega;
Töödeldud andmete usaldusväärsus;
Muutuste jälgimine ja versioonimine;
Andmete päritolu, andmete seosed, CDC;
Uute funktsioonide kiire tarnimine tootmisümbrusse;
Ja kuulus küsimus: arenduse ja hoolduse maksumus.

See tähendab, et inseneridel on tohutul hulgal kõrgtaseme ülesandeid, mille tõhus täitmine on võimalik vaid siis, kui vabaneda madalama taseme arenduse ülesannetest.

Arendajate uuele tasemele liikumise eelduseks sai äri areng ja digitaliseerimine. Arendaja väärtus muutub samuti: puudus on arendajatest, kes suudavad süveneda automatiseeritava äri kontseptsioonidesse.

Teeme analoogia madala- ja kõrgematasemeliste programmeerimiskeelte vahel. Liikumine madala taseme keeltest kõrgema taseme keelte suunas on üleminek „otse masinakeele käskude kirjutamisest“ „käsudeni inimkeeles“. Tõsi, see tähendab teatud abstraktsioonikihi lisamist. Sel juhul on üleminek madala-koodiga platvormidele kõrgema taseme programmidelt samm „inimkeeles käskude andmisest“ äri keelde käskude andmise suunas. Kui on arendajaid, keda see fakt kurvastab, siis võib-olla on nad kurvastanud sellest hetkest, kui sündis Java Script, kus kasutatakse massiivi sorteerimise funktsioone. Ja need funktsioonid sisaldavad loomulikult sama kõrgtaseme programmeerimise rakendusi.

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

Praktiline kogemus low-code'i kasutamisest

Low-code teema on üsna lai, kuid nüüd sooviksin rääkida "madalkoodide kontseptsioonide" rakendusliku kasutamise kohta ühe meie projekti näitel.

Ettevõtte "Neoflex" Big Data Solutions divisjon keskendub peamiselt finantssektorile, luues andmehoidlaid ja andmejärvi ning automatiseerides erinevaid aruandeid. Selles niššis on low-code kasutamine juba ammu standardiks saanud. Muude madalkoodide tööriistade seas võib mainida ETL-protsesside korraldamise vahendeid: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Või Oracle Apex, mis on kiire arendamise keskkond andmete juurdepääsu ja redigeerimise liideste loomiseks. Siiski ei ole madalkoodide arendustööde kasutamine alati seotud kitsaste rakenduste loomisega kommertstehnoloogiate virnas, mis on selgelt sõltuvuses müüjast.

Low-code platvormide abil on samuti võimalik korraldada andmevoogude orkestreerimist, luua andeteaduse platvorme või näiteks andmekvaliteedi kontrollimooduleid.

Üks rakenduslik näide madalkoodide arendustööde kasutamisest on koostöö "Neoflex" ja ettevõtte Mediascope vahel, mis on üks Venemaa meediauuringute turu juhtidest. Selle ettevõtte äriülesanne on luua andmeid, mille alusel reklaamisponsorid, veebiplatvormid, telekanalid, raadiod, reklaamiagentuurid ja kaubamärgid teevad reklaamiostuotsused ja planeerivad oma turunduskommunikatsioone.

Meediauuringud on tehnoloogiliselt nõudlik äri valdkond. Videoklippide tuvastamine, andmete kogumine seadmetelt, mis analüüsivad vaatamist, veebiresursside aktiivsuse mõõtmine – kõik see eeldab ettevõttelt suurt IT-töötajate arvu ja tohutut kogemust analüütiliste lahenduste väljatöötamises. Kuid teabe suurenev maht, selle allikate arv ja mitmekesisus sunnib andmete IT-tööstust pidevalt arenema. Kõige lihtsam lahendus Mediascope'i juba toimiva analüütika platvormi mõõtmedamise suurendamiseks oleks olnud suurendada IT-töötajate arvu. Kuid palju tõhusam lahendus on arendusprotsessi kiirendamine. Üks samm, mis viib selleni, võib olla madalkoodide platvormide kasutamine.

Projekti käivitamise hetkeks omas ettevõte juba toimivat tootelahendust. Kuid MSSQL-i kasutamine ei suutnud täielikult rahuldada funktsionaalsuse skaleerimise ootusi, säilitades samas aktsepteeritava lisandmooduli hinna.

Meie ees seisev ülesanne oli tõeliselt ambitsioonikas – Neoflex ja Mediascope pidid looma tööstuslahenduse vähem kui aastaga, kusjuures MVP (minimaalne toimiv toode) pidi valmima juba esimese kvartali jooksul pärast tööde alustamist.

Uue andmeplatvormi aluseks, mis põhineb madala koodiga arvutustel, valiti Hadoopi tehnoloogiate virn. Andmete salvestamise standardiks sai HDFS, kasutades parquet formaadi faile. Andmetele, mis asuvad platvormil, pääseb ligi Hive'i kaudu, kus kõik saadavad vitriinid on esitatud väliste tabelitena. Andmete laadimine ladustamisse teostati Kafka ja Apache NiFi abil.

Madala koodiga tööriista rakendati selles kontseptsioonis, et optimeerida kõige töömahukamat ülesannet analüüsiplatvormi ehitamisel – andmete arvutamise ülesannet.

Peamiseks andmete mappimise mehhanismiks valiti madala koodiga tööriist Datagram. Neoflex Datagram on vahend andmete transformatsioonide ja voogude arendamiseks.
Selle tööriista kasutamisel saab hakkama ilma Scala kodeerimiseta "käsi". Scala kood genereeritakse automaatselt, kasutades Model Driven Architecture lähenemist.

Ilmselge pluss selle lähenemise juures on arendusprotsessi kiirus. Kuid lisaks kiirusel on veel mitmeid eeliseid:

Allikate / sihtkohtade sisu ja struktuuri vaatamine;
Andmevoogude objektide päritolu jälgimine kuni üksikute väljade tasemeni (lineage);
Osaline transformatsioonide teostamine vahepealsete tulemuste vaatamisega;
Algkoodi vaatamine ja selle kohandamine enne käivitamist;
Automaatne transformatsioonide valideerimine;
Andmete automaatne laadimine 1:1.

Low-code lahenduste sisenemisbarjäär transformatsioonide genereerimiseks on piisavalt madal: arendajal on vaja tunda SQL-i ja omada kogemusi ETL-tööriistadega. Siiski tasub mainida, et code-driven transformatsioonide generaatorid ei ole ETL-tööriistad laiemas mõttes. Low-code tööriistad ei pruugi omada oma keskkonda koodi täitmiseks. See tähendab, et genereeritud kood täidetakse keskkonnas, mis oli klastris olemas juba enne low-code lahenduse installimist. Ja see on ehk veel üks pluss low-code'i kasuks. Sest kõrvale low-code meeskonnale võib töötada "klassikaline" meeskond, mis teostab funktsionaalsust näiteks puhtal Scala koodil. Mõlema meeskonna muudatuste viimine tootmisse on lihtne ja "sujuv".

Tuleb veel märkida, et lisaks low-code lahendustele on olemas ka no-code lahendused. Ja oma olemuselt on need erinevad asjad. Low-code võimaldab arendajal rohkem sekkuda genereeritud koodi. Datagrami puhul on võimalik vaadata ja redigeerida genereeritud Scala koodi, no-code ei pruugi sellist võimalust pakkuda. See erinevus on üsna oluline mitte ainult lahenduse paindlikkuse osas, vaid ka andmeinseneride töö mugavuse ja motivatsiooni osas.

Lahenduse arhitektuur

Proovime mõista, kuidas low-code tööriist aitab lahendada andmete arvutamise funktsionaalsuse arendamise kiirusprobleemi. Alustame süsteemi funktsionaalsest arhitektuurist. Sel juhul on näiteks andmete tootmismudel meedia-uuringute jaoks.

Ainealased andmeallikad on meie juhul väga mitmekesised ja mitmekesised:

Peoplemeters (TV meters) are software and hardware devices that capture user behavior among respondents of a television panel—who, when, and which TV channel was viewed in the household participating in the study. The supplied information is a stream of viewing intervals linked to the media package and media product. Data during the upload phase to the Data Lake can be enriched with demographic attributes, geographic ties, time zones, and other information necessary for analyzing the viewership of a particular media product. The measurements obtained can be used for the analysis or planning of advertising campaigns, evaluating audience activity and preferences, and creating broadcasting schedules.
Data can be sourced from streaming television monitoring systems and from measuring content viewership on video resources on the internet;
Measuring tools in the web environment include both site-centric and user-centric counters. A research bar browser extension and a mobile application with embedded features can serve as data suppliers for the Data Lake. VPN.
Data can also be obtained from platforms that consolidate results from online surveys and the outcomes of telephone interviews in the company's survey research;
Additional enrichment of the data lake can occur through loading information from the logs of partner companies.

The implementation of as-is loading from source systems into the initial staging of raw data can be organized in various ways. If low-code is used for these purposes, automatic script generation for loading can be based on metadata. In this case, there is no need to delve into the development of source to target mappings. To facilitate automatic loading, we need to establish a connection with the source and then define in the loading interface the list of entities to be loaded. The creation of the directory structure in HDFS will happen automatically and will correspond to the data storage structure in the source system.

However, in the context of this project, we decided not to utilize this low-code platform capability due to the fact that Mediascope has already begun working independently on creating a similar service using the Nifi + Kafka combination.

On kohe selgelt märkida, et need tööriistad ei ole üksteist asendavad, vaid pigem täiendavad teineteist. Nifi ja Kafka suudavad töötada nii otse (Nifi -> Kafka) kui ka vastupidiselt (Kafka -> Nifi). Meediauurimise platvormil kasutati esimest varianti.

Meie puhul pidi Nifi töötlema erinevat tüüpi andmeid allikate süsteemidest ja edastama need Kafka vahendajale. Samal ajal suunati sõnumid kindlasse Kafka teema, kasutades Nifi publishKafka protsessoreid. Nende pipeline'ide orkestreerimine ja hooldus toimub visuaalses liideses. Nifi tööriista ja Nifi + Kafka ühenduse kasutamist võib samuti nimetada low-code lähenemiseks arendusele, mis omab madalat sisenemispiiri Big Data tehnoloogiatesse ja kiirendab rakenduste arendamise protsessi.

Projekti elluviimise järgmine etapp oli detailsete andmete ühise semantilise kihina vormindamine. Kui entiteedil on ajaloolisi atribuute, toimingut teostatakse arvesse võetud partitsiooni kontekstis. Kui entiteet ei ole ajalooline, on võimalus kas arvutada ümber kogu objekti sisu või loobuda objekti ümberarvutamisest (tänu muudatuste puudumisele). Sellel etapil genereeritakse võtmed kõigi entiteetide jaoks. Võtmed salvestatakse vastavatesse Hbase põhielementide registritesse, mis sisaldavad seoseid analüütilise platvormi võtmete ja allikate süsteemide võtmete vahel. Aatomiliste entiteetide konsolideerimist saadab analüüsitud andmete tulemuste rikastamine. Andmete arvutamise raamistikuks oli Spark. Kirjeldatud andmete viimine ühte semantika juurde realiseeriti ka low-code tööriista Datagram mappimise alusel.

Eesmärgi arhitektuuris oli vajalik tagada SQL-juurdepääs andmetele äritöötajate jaoks. Selle valiku jaoks kasutati Hive'i. Objektide registreerimine Hive'is toimub automaatselt, kui low-code tööriistas lülitatakse sisse valik „Registr Hive Table”.

Arvutamise voogude haldamine

Datagramil on töövoogude kujundamiseks liides. Kaardistamise käivitamine võib toimuda Oozie ajastaja abil. Arendaja liideses on võimalik luua paralleelse, järjekindla või tingimustel põhineva andmete muundamise skeeme. Toetatakse shell-skripte ja Java programme. Samuti on võimalik kasutada serverilt Apache Livy. Apache Livy't kasutatakse rakenduste käivitamiseks otse arenduskeskkonnast.

Kui ettevõttel on juba oma protsesside orkestreerija, on võimalik REST API abil olemasolevatesse töövoogudesse kaardistamisi sisestada. Näiteks oleme omanud üsna edukat kogemust Scala kaardistamiste integreerimises PLSQL ja Kotlinis kirjutatud orkestreerijatesse. Madala koodiga tööriista REST API sisaldab selliseid toiminguid nagu kaardistamise disainist lähtuva käivitatava aasta genereerimine, kaardistamise kutsumine, kaardistamiste järjestuse väljakutsumine ja loomulikult ka parameetrite edastamine URL-is kaardistamiste käivitamiseks.

Koos Ooziega on võimalik arvutusprotsessi korraldada ka Airflow abil. Võib-olla ei viibi ma pikalt Oozie ja Airflow võrdlemisel, vaid ütlen lihtsalt, et meedia-uuringute projekti kontekstis langes valik Airflow kasuks. Peamised argumendid olid seekord aktiivsem kogukond, kes arendab toodet, ja arenenum liides + API.

Airflow on suurepärane ka seetõttu, et selle arvutusprotsesside kirjeldamiseks kasutatakse paljude seas populaarset Pythonit. Üldiselt ei ole avatud lähtekoodiga töövoogude juhtimise platvorme väga palju. Protsesside käivitamine ja jälgimine (sealhulgas Gantt-diagrammiga) lisab Airflow'le veel punkte.

Kaardistamiste käivitamise konfiguratsioonifaili formaadiks madala koodiga lahenduse jaoks sai spark-submit. See juhtus kahel põhjusel. Esiteks võimaldab spark-submit otse käivitada jar-faili konsoolist. Teiseks võib see sisaldada kogu vajaliku teabe töövoo konfigureerimiseks (mis hõlbustab Dag-i genereerivate skriptide kirjutamist).
Airflow tööprotsesside kõige sagedamini esinev element on meie puhul olnud SparkSubmitOperator.

SparkSubmitOperator võimaldab käivitada jar-file, mis on pakendatud Datagrami kaardistamised koos eelnevalt vormistatud sisendparameetritega.

Tuleb mainida, et iga Airflow'i ülesanne täidetakse eraldi lõimes ja ei tea midagi teistest ülesannetest. Seetõttu toimub ülesannete vaheline suhtlemine juhtivate operaatorite, nagu DummyOperator või BranchPythonOperator, kaudu.

Low-code lahenduse Datagram kasutamine koos konfiguratsioonifailide (Dage moodustavate) universaliseerimisega on oluliselt kiirendanud andmete laadimisprotsesside arendamist ja lihtsustanud neid.

Vitrinade arvestus

Tõenäoliselt on kõige vaimsemalt koormatud etapp analüütiliste andmete tootmises vitrinade ehitamine. Ühe andmevoo kontekstis toimub sellel etapil viidatud standardiseerimise käigus andmete üleviimine ajavööndite korrigeerimisega, mis on seotud edastamisvõrguga. Samuti on võimalik kohandamine kohaliku eetrivõrgu (kohalikud uudised ja reklaam) jaoks. Selles etapis toimub muu hulgas pideva vaatamise ajavahemike jagamine meediatoodete analüüsi põhjal. Samuti toimub siin vaatamise väärtuste „kaalumine“ nende olulisuse andmete põhjal (korrigeerimisteguri arvutamine).

Vitrinate ettevalmistamise eraldi samm on andmete valideerimine. Valideerimise algoritm on seotud mitmete matemaatiliste teadusmudelite rakendamisega. Siiski võimaldab low-code platvormi kasutamine keerulise algoritmi jagada visuaalselt loetavateks kaardistusteks. Iga kaardistus täidab kitsast ülesannet. Selle tulemusena on võimalik vahepealne tõrkeotsing, logimine ja andmete ettevalmistamise etappide visualiseerimine.

Valideerimise algoritmi otsustati diskretiseerida järgmiste alaetappideks:

Ahnmise regressioonide koostamine televõrgu vaatamise ja kõigi võrgu vaatamise vahel piirkonnas viimase 60 päeva jooksul.
Tudengiseeritud jääkide arvutamine (erinevused tegelike väärtuste ja regressioonimudelite ennustatud väärtuste vahel) kõigi regressioonipunktide ja arvutusliku päeva jaoks.
Ebanormaalsete paari valimine piirkond-televõrk, kus arvutatud päeva tudengiseeritud jääk ületab normi (mille seadistas operatsioon).
Korrektseeritud üliõpilaste saldot arvestavate anomaalsete piirkondade televõrkude järgi iga küsitletava jaoks, kes vaatas piirkonnas võrku, tuvastades selle küsitletava panuse (ületatud üliõpilaste saldo muutus), välja arvatud selle küsitletava vaatamine valimist.
Kandidaatide otsimine, kelle välistamine toob normi tagasi korrigeeritud saldo kalkulatsiooni päeval.

Ülaltoodud näide kinnitab hüpoteesi, et andmeinseneril on peas juba liiga palju asju... Ja kui ta tõeliselt on «insener», mitte «kooder», siis madala koodiga tööriistade kasutamise hirm professionaalse degradeerumise ees peaks tõeliselt kaduma.

Mis veel madala koodi puhul võimalik on?

Madala koodi tööriista rakendus infovoogude ja partiiandmete töötlemiseks ilma Scala käsitsi koodi kirjutamata ei piirdu.

Madala koodi rakendamine datalake'ide arendamisel on meist juba saanud teatud standard. Tõenäoliselt võib öelda, et Hadoopi tehnoloogia lahendused jälgivad klassikaliste RDBMS põhiste DWH arenguteed. Madala koodiga tööriistad Hadoopi tehnoloogial võivad lahendada nii andmete töötlemise ülesandeid kui ka lõpuks BI-liideste loomise ülesandeid. Oluline on märkida, et BI all võib mõista mitte ainult andmete esitlust, vaid ka nende redigeerimist äritegevuse kasutajate poolt. Seda funktsionaalsust rakendame me sageli analüütiliste platvormide loomisel finantssektoris.

Loodud on madala koodi abiga ja eelkõige Datagram'i kaudu võimalik lahendada andmevoogude objektide päritolu jälgimise ülesanne, sealhulgas üksikute väljade (lineage) tasandil. Selleks on madala koodi tööriistas rakendatud integreerimine Apache Atlase ja Cloudera Navigatoriga. Sisuliselt peab arendaja registreerima objektide kogumi Atlase sõnastikes ja viitama registreeritud objektidele kaardistamise koostamise käigus. Andmete päritolu jälgimise mehhanism või objektide sõltuvuste analüüs säästab palju aega, kui on vajalik algoritmide täiendamine. Näiteks finantsaruande koostamisel võimaldab see funktsioon mugavamalt üle elada seadusandlikke muudatusi. Mida paremini mõistame objektide detailitaseme vahelisi sõltuvusi, seda vähem kohtame „üllatavaid“ defekte ja vähendame ümbertegemiste arvu.

Andmete kvaliteet ja madal kood

Teiseks ülesandeks, mille madala koodi tööriist rakendas Mediascope'i projektis, oli andmete kvaliteedi ülesanne. Andmete kontrollimise konveieril puudus mõju andmete arvutamise peamise voolu toimimisele ja kiirus. Andmete kontrollimiseks eraldiseisvate voogude orkestreerimiseks kasutati tuttavat Apache Airflow'i. Iga andmete tootmise etapi valmides käivitati samal ajal eraldi DQ-konveieri osa.

Heaks praktikaks peetakse andmete kvaliteedi jälgimist nende tekkimisest alates analüüsiplatvormil. Omades teavet metaandmete kohta, saame juba alates informatsiooni jõudmisest esmaste andmete kihina kontrollida põhiliste tingimuste järgimist — mitte-null, piirangud, välisvõtmed. See funktsioon on rakendatud automaatselt genereeritud kaardistuste alusel, mis kuuluvad andmete kvaliteedi peresse Datagram'is. Koodigeneratsioon põhineb sel juhul samuti mudeli metaandmetel. Mediascope'i projektis toimus integreerimine Enterprise Architecti toote metaandmetega.

Madala koodi tööriista ja Enterprise Architecti integreerimise tulemusena on automaatselt genereeritud järgmised kontrollid:

Kontroll „null” väärtuste olemasolu üle mitte-null modifikaatoriga väljadest;
Kontroll algsete võtmete dubleerimise üle;
Välise võtme kontrollimine entiteedis;
Rea unikaalsuse kontroll vastavalt väljade kogumile.

Kasutajate vajadustega kohandatud keerukamate kontrollide jaoks andmete kättesaadavuse ja usaldusväärsuse tagamiseks loodi Scala väljendite kaardistus, mis võtab sisendiks välise Spark SQL kontrollkoodi, mille on ette valmistanud analüütikud Zeppelin'is.

Loomulikult tuleb automaatsete kontrollide genereerimisele läheneda järk-järgult. Käesoleva projekti eelõhtul olid järgmised sammud:

DQ, mis on realiseeritud Zeppelin'i märkmikes;
DQ, mis on integreeritud kaardistusse;
DQ eraldi mahukate kaardistustena, mis sisaldavad mitmeid kontrollpunkte konkreetse entiteedi jaoks;
Üksikasjalikud parameetriseeritud DQ kaardistused, mis võtavad sisendiks metainformatsiooni ja ärikontrollide kohta.

Tõenäoliselt on parameetritesse kohandatud kontrollide teenuse loomise peamine eelis funktsionaalsuse toimetamise aega tootmisringkonda lühendada. Uued kvaliteedikontrollid võivad mööda minna klassikalisest koodide toimetamise mustrist arendus- ja testimistest;

Kõik metaandmete kontrollid genereeritakse automaatselt mudeli muutmisel EA-s;
Andmete kättesaadavuse kontrollid (andmete olemasolu kindlaksmääramine teatud ajahetkel) saab genereerida jaotise alusel, mis säilitab oodatava ajakava järgmise andmehulgaga objektide osas;
Ärikontrollide andmete usaldusväärsus luuakse analüütikute poolt Zeppelin'i märkmikes. Sealt suunatakse nad otse DQ mooduli seadistustabelitesse tootmisringis.

Otsese skriptide saatmise riske tootmisringkonnas ei ole. Isegi süntaktilise vea korral on maksimum, mis meid ähvardab, - ühe kontrolli mitte täitmine, kuna andmete arvutussüsteem ja kvaliteedikontrollide käivitusprotsess on omavahel eraldatud.

Sisuliselt on DQ teenus pidevalt aktiivne tootmisringkonnas ja valmis alustama oma tööd, kui järgmine andmehulk ilmub.

Lõpetuseks

Madaloodud kodeerimise eelised on ilmsed. Arendajatel ei ole vaja rakendust "nullist" välja töötada. Ja vabanenud programmeerija annab tulemusi kiiremini. Kiirus omakorda vabastab täiendava ajavaru, et tegeleda optimeerimise küsimustega. Seega võib sellisel juhul loota paremate ja kiiremate lahenduste olemasolule.

Muidugi ei ole madaloodud kood imerohi ja maagia ei juhtu iseenesest:

Madaloodud kooditööstus läbib "tugevdamise" etappi, kus seni puuduvad ühtsed tööstusstandardid;
Paljud madaloodud lahendused ei ole tasuta ja nende soetamine peab olema teadlik samm, mille peaks tegema täieliku veendumusega finantshüvede osas nende kasutamisest;
Paljud madaloodud lahendused ei sobi alati hästi GITi / SVNi. Kasutamine võib olla ebamugav, kui genereeritud kood on varjatud;
Aruandluse laienemisel võib olla vajalik madaloodud lahenduse kohandamine - see omakorda kutsub esile "seotuse ja sõltuvuse" efekti madaloodud lahenduse pakkujast.
Kohane turvalisuse tagamise tase on võimalik, kuid võib olla väga töömahukas ja keeruline madaloodud süsteemide mootorite rakendamiseks. Madaloodud platvormid ei tohiks olla valitud ainult nende kasutamise kasu otsimise põhjal. Valimisel on mõistlik küsida, kas funktsionaalsus juurdepääsu haldamiseks ja identifitseerimisandmete delegeerimise/escalation tasemele kogu organisatsiooni IT-maastik hõlmab.

Kuid kui kõik valitud süsteemi puudused on teile teada ja selle kasutamise kasulikkus on siiski domineeriv, siis minge madaloodud koodi juurde kartmata. Veelgi enam, liikumine selle poole on vältimatu - nagu on vältimatu iga evolutsioon.

Kui üks arendaja madala koodiga platvormil suudab oma tööd teha kiiremini kui kaks arendajat ilma madala koodita, annab see ettevõttele igaühes eelise. Madala koodi lahenduste kasutuselevõtu takistus on väiksem kui "traditsiooniliste" tehnoloogiate puhul, mis positiivselt mõjutab tööjõu puuduse küsimust. Madala koodi tööriistade abil on võimalik kiirendada koostööd funktsionaalsete meeskondade vahel ja kiiresti langetada otsuseid andmete teadusuuringute valitud suuna õigsuse osas. Madala taseme platvormid võivad olla organisatsiooni digitaalsete transformatsioonide põhjustajad, kuna loodud lahendused on mõistetavad mitte-tehnilistele spetsialistidele (eriti äritöötajatele).

Kui teil on tähtaegade surve, keeruline äriloogika, tehnoloogiaekspertiisi puudus ja teil on vaja turule jõudmist kiirendada, on madala koodiga lahendus üks viise teie vajaduste rahuldamiseks.

Ei saa eitada traditsiooniliste arendustööriistade tähtsust, kuid paljude juhtumite korral on madala koodi lahenduste kasutamine parim viis suurendada lahenduste tõhusust.

Allikas: habr.com