Beste lesers, goeie dag!
Die taak om IT-platforms vir data-akkumulasie en -ontleding te bou, ontstaan vroeër of later vir enige maatskappy wie se besigheid gebaseer is op 'n intellektueel gelaaide model van diensverskaffing of die skepping van tegnies komplekse produkte. Die bou van analitiese platforms is 'n komplekse en arbeidsintensiewe taak. Enige taak kan egter vereenvoudig word. In hierdie artikel wil ek my ervaring van die gebruik van laekode-instrumente deel om analitiese oplossings te help skep. Hierdie ervaring is opgedoen tydens die implementering van 'n aantal projekte in die Big Data Solutions-rigting van Neoflex. Neoflex se Big Data Solutions is sedert 2005 besig met die bou van datapakhuise en mere, die oplossing van probleme om die spoed van inligtingverwerking te optimaliseer en werk aan 'n datakwaliteitbestuursmetodologie.
Niemand sal die bewuste ophoping van swak en/of sterk gestruktureerde data kan vermy nie. Miskien selfs al praat ons van klein besighede. Inderdaad, wanneer 'n besigheid skaal, sal 'n belowende entrepreneur die kwessies van die ontwikkeling van 'n lojaliteitsprogram in die gesig staar, die doeltreffendheid van verkoopspunte wil ontleed, aan geteikende advertensies dink en verbaas wees oor die vraag na gepaardgaande produkte. In die eerste benadering kan die probleem "op die knie" opgelos word. Maar met die groei van besigheid is die aankoms na die analitiese platform steeds onvermydelik.
In watter geval kan die take van data-analise egter ontwikkel tot take van die “Rocket Science”-klas? Miskien op die oomblik wanneer dit kom by werklik groot data.
Om Rocket Science makliker te maak, kan jy die olifant stukkie vir stukkie eet.
Hoe groter die diskreetheid en outonomie van jou toepassings / dienste / mikrodienste is, hoe makliker sal dit vir jou, jou kollegas en die hele besigheid wees om die olifant te verteer.
Byna al ons kliënte het tot hierdie postulaat gekom deur die landskap te herbou gebaseer op die ingenieurspraktyke van DevOps-spanne.
Maar selfs met 'n "aparte, olifantiese" dieet, het ons 'n goeie kans om die IT-landskap te "oorversadig". Op hierdie punt moet jy stop, uitasem en na die kant kyk. lae-kode ingenieursplatform.
Baie ontwikkelaars word geïntimideer deur die vooruitsig van 'n loopbaan doodloopstraat wanneer hulle wegbeweeg van die skryf van kode direk en na die sleep van pyle in lae-kode UI's. Maar die voorkoms van masjiengereedskap het nie gelei tot die verdwyning van ingenieurs nie, maar het hul werk na 'n nuwe vlak gebring!
Kom ons vind uit hoekom.
Data-analise in die veld van logistiek, die telekommunikasiebedryf, in die veld van medianavorsing, die finansiële sektor, word altyd met die volgende kwessies geassosieer:
- Die spoed van outomatiese analise;
- Vermoë om eksperimente uit te voer sonder om die hoofdataproduksiestroom te beïnvloed;
- Betroubaarheid van die voorbereide data;
- Verander dop en weergawe;
- Data bewys, Data afkoms, CDC;
- Vinnige aflewering van nuwe kenmerke aan die produksie-omgewing;
- En die berugte: die koste van ontwikkeling en ondersteuning.
Dit wil sê, ingenieurs het 'n groot aantal hoëvlaktake wat slegs met voldoende doeltreffendheid uitgevoer kan word deur hul gedagtes skoon te maak van laevlak-ontwikkelingstake.
Die voorvereistes vir ontwikkelaars om na 'n nuwe vlak te beweeg, is die evolusie en digitalisering van besigheid. Die waarde van die ontwikkelaar is ook aan die verander: daar is 'n aansienlike tekort aan ontwikkelaars wat hulself kan verdiep in die essensie van die konsepte van 'n outomatiese besigheid.
Kom ons teken 'n analogie met laevlak- en hoëvlakprogrammeringstale. Die oorgang van laevlaktale na hoëvlaktale is 'n oorgang van die skryf van "direkte voorskrifte in die taal van yster" na "direktiewe in die taal van mense." Dit wil sê om 'n laag abstraksie by te voeg. In hierdie geval is die oorgang na lae-kode-platforms van hoëvlak-programmeertale 'n oorgang van "direktiewe in die taal van mense" na "direktiewe in die taal van besigheid". As daar ontwikkelaars is wat hartseer is oor hierdie feit, dan is hulle hartseer, miskien sedert die geboorte van Java Script, wat skikkingssorteerfunksies gebruik. En hierdie funksies het natuurlik sagteware-implementering onder die enjinkap deur middel van dieselfde hoëvlak-programmering.
Daarom is lae-kode net die voorkoms van 'n ander vlak van abstraksie.
Toegepaste ervaring met lae-kode
Die onderwerp van lae-kode is redelik breed, maar nou wil ek praat oor die toepassing van "lae-kode konsepte" deur die voorbeeld van een van ons projekte te gebruik.
Die Big Data Solutions-afdeling van Neoflex spesialiseer tot 'n groter mate in die finansiële sektor van die onderneming, die bou van datapakhuise en mere en outomatisering van verskeie verslagdoening. In hierdie nis is die gebruik van lae-kode lank reeds die standaard. Ander lae-kode-instrumente sluit instrumente in om ETL-prosesse te organiseer: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Of Oracle Apex, wat die omgewing is vir vinnige ontwikkeling van koppelvlakke vir toegang tot en redigering van data. Die gebruik van lae-kode ontwikkelingsinstrumente word egter nie altyd geassosieer met die konstruksie van eng gefokusde toepassings op 'n kommersiële tegnologiestapel met 'n uitgesproke afhanklikheid van die verkoper nie.
Met die hulp van lae-kode platforms kan jy ook die orkestrasie van datavloei organiseer, datawetenskapplatforms skep of byvoorbeeld datakwaliteitkontrolemodules.
Een van die toegepaste voorbeelde van die ervaring van die gebruik van laekode-ontwikkelingsinstrumente is die Neoflex-samewerking met Mediascope, een van die leiers in die Russiese medianavorsingsmark. Een van die take van hierdie maatskappy se besigheid is die vervaardiging van data, op grond waarvan adverteerders, internetwebwerwe, TV-kanale, radiostasies, advertensie-agentskappe en handelsmerke besluite neem oor advertensie-aankope en hul bemarkingskommunikasie beplan.
Medianavorsing is 'n tegnologies gelaaide sakegebied. Herkenning van 'n video-volgorde, versameling van data vanaf toestelle wat kyk ontleed, meting van aktiwiteit op webbronne - dit alles impliseer dat die maatskappy 'n groot IT-personeel en geweldige ervaring het in die bou van analitiese oplossings. Maar die eksponensiële groei in die hoeveelheid inligting, die aantal en verskeidenheid van sy bronne laat die IT-databedryf voortdurend vorder. Die eenvoudigste oplossing om die reeds funksionerende analitiese platform Mediascope te skaal, kan 'n toename in IT-personeel wees. Maar 'n baie meer doeltreffende oplossing is om die ontwikkelingsproses te bespoedig. Een van die stappe wat in hierdie rigting lei, kan die gebruik van lae-kode platforms wees.
Ten tyde van die aanvang van die projek het die maatskappy reeds 'n funksionele produkoplossing gehad. Die implementering van die oplossing op MSSQL kon egter nie ten volle voldoen aan die verwagtinge vir die skaal van die funksionaliteit terwyl 'n aanvaarbare koste van verbetering gehandhaaf word nie.
Die taak voor ons was werklik ambisieus - Neoflex en Mediascope moes 'n industriële oplossing in minder as 'n jaar skep, mits die MVP reeds binne die eerste kwartaal vrygestel is vanaf die datum van aanvang van werk.
Die Hadoop-tegnologiestapel is gekies as die grondslag vir die bou van 'n nuwe dataplatform gebaseer op lae-kode-berekening. HDFS het die databergingstandaard geword deur parketlêers te gebruik. Om toegang tot die data in die platform te verkry, word Hive gebruik, waarin alle beskikbare winkelfronte in die vorm van eksterne tabelle aangebied word. Die laai van data in die berging is geïmplementeer met behulp van Kafka en Apache NiFi.
Die lae-kode-instrument in hierdie konsep is gebruik om die mees arbeidsintensiewe taak te optimaliseer in die bou van 'n analitiese platform - die taak om data te bereken.
Die Datagram-laekode-instrument is gekies as die hoofmeganisme vir datakartering. Neoflex Datagram is 'n hulpmiddel vir die ontwikkeling van transformasies en datavloei.
Deur hierdie instrument te gebruik, kan jy klaarkom sonder om Scala-kode "handmatig" te skryf. Scala-kode word outomaties gegenereer met behulp van die Model Driven Architecture-benadering.
Die ooglopende voordeel van hierdie benadering is die versnelling van die ontwikkelingsproses. Benewens spoed is daar egter ook die volgende voordele:
- Bekyk die inhoud en struktuur van bronne/bestemmings;
- Naspeuring van die oorsprong van datavloei-objekte na individuele velde (lyn);
- Gedeeltelike uitvoering van transformasies met besigtiging van tussenresultate;
- Bekyk die bronkode en pas dit aan voor uitvoering;
- Outomatiese validering van transformasies;
- Outomatiese data laai 1 in 1.
Die toegangsdrempel vir lae-kode-oplossings vir die generering van transformasies is redelik laag: 'n ontwikkelaar moet SQL ken en ondervinding hê met ETL-nutsgoed. Terselfdertyd is dit die moeite werd om te noem dat kodegedrewe transformasiegenerators nie ETL-instrumente in die breë sin van die woord is nie. Laekode-nutsgoed het dalk nie hul eie omgewing vir die uitvoering van kode nie. Dit wil sê, die gegenereerde kode sal uitgevoer word op die omgewing wat op die cluster was selfs voor die installering van die lae-kode oplossing. En dit is miskien nog 'n pluspunt vir lae-kode karma. Aangesien, parallel met die lae-kode-opdrag, 'n "klassieke" opdrag kan werk wat die funksionaliteit implementeer, byvoorbeeld op suiwer Scala-kode. Om die verbeterings van beide spanne in produksie te trek, sal eenvoudig en naatloos wees.
Miskien moet ook daarop gelet word dat daar benewens lae-kode ook geen-kode-oplossings is. En in wese is dit verskillende dinge. Lae kode laat die ontwikkelaar in 'n groter mate toe om met die gegenereerde kode in te meng. In die geval van Datagram is dit moontlik om die gegenereerde Scala-kode te sien en te wysig, geen-kode sal dalk nie so 'n geleentheid bied nie. Hierdie verskil is baie betekenisvol, nie net in terme van oplossingsbuigsaamheid nie, maar ook in terme van gemak en motivering in die werk van data-ingenieurs.
Oplossingsargitektuur
Kom ons probeer uitvind presies hoe die lae-kode-instrument help om die probleem op te los om die spoed van die ontwikkeling van die databerekeningsfunksionaliteit te optimaliseer. Kom ons ontleed eers die funksionele argitektuur van die stelsel. In hierdie geval is die dataproduksiemodel vir medianavorsing 'n voorbeeld.
Die databronne in ons geval is baie heterogeen en uiteenlopend:
- Mensemeters (TV-meters) is sagteware- en hardewaretoestelle wat die gebruikersgedrag van die respondente van die TV-paneel lees – wie, wanneer en watter TV-kanaal gekyk is in die huishouding wat aan die studie deelneem. Die inligting wat verskaf word, is 'n stroom uitsaai-kykintervalle wat aan 'n mediapakket en 'n mediaproduk gekoppel is. Data in die stadium van laai in Data Lake kan verryk word met demografiese eienskappe, geostraat, tydsone en ander inligting wat nodig is om die TV-kyk van 'n spesifieke mediaproduk te ontleed. Die metings wat gemaak word, kan gebruik word om advertensieveldtogte te ontleed of te beplan, die aktiwiteit en voorkeure van die gehoor te assesseer, 'n uitsaairooster op te stel;
- Data kan kom van moniteringstelsels vir die stroom van televisie en die meting van die kyk van video-inhoud op die internet;
- Meetinstrumente in 'n webomgewing, insluitend beide werfgesentreerde en gebruikergesentreerde tellers. Die dataverskaffer vir Data Lake kan 'n navorsingstaafblaaierbyvoeging en 'n mobiele toepassing met 'n ingeboude VPN wees.
- Data kan ook kom van webwerwe wat die resultate van die invul van aanlynvraelyste en die resultate van telefoniese onderhoude in maatskappyopnames konsolideer;
- Bykomende verryking van die datameer kan plaasvind deur inligting van die logs van vennootmaatskappye af te laai.
Die implementering van as is laai vanaf bronstelsels na primêre stadium van rou data kan op verskeie maniere georganiseer word. As lae-kode vir hierdie doeleindes gebruik word, is outomatiese generering van aflaai-skrifte gebaseer op metadata moontlik. In hierdie geval is dit nie nodig om af te gaan na die ontwikkelingsvlak van bron om kartering te teiken nie. Om outomatiese laai te implementeer, moet ons 'n verbinding met die bron vestig, en dan 'n lys van entiteite definieer wat in die laai-koppelvlak gelaai moet word. Die skepping van die gidsstruktuur in HDFS sal outomaties plaasvind en sal ooreenstem met die databergingstruktuur in die bronstelsel.
In die konteks van hierdie projek het ons egter besluit om nie hierdie kenmerk van die laekode-platform te gebruik nie, omdat Mediascope reeds onafhanklik begin werk het aan die vervaardiging van 'n soortgelyke diens gebaseer op die Nifi + Kafka-bundel.
Daar moet dadelik op gelet word dat hierdie gereedskap nie uitruilbaar is nie, maar eerder aanvullend. Nifi en Kafka kan beide in direkte (Nifi -> Kafka) en in omgekeerde (Kafka -> Nifi) bundel werk. Vir die medianavorsingsplatform is die eerste weergawe van die bundel gebruik.
In ons geval moes Naifai verskeie soorte data vanaf bronstelsels verwerk en na die Kafka-makelaar stuur. Terselfdertyd is boodskappe na 'n spesifieke Kafka-onderwerp gestuur deur PublishKafka Nifi-verwerkers te gebruik. Orkestrering en instandhouding van hierdie pyplyne word in 'n visuele koppelvlak gedoen. Die Nifi-instrument en die gebruik van die Nifi + Kafka-bundel kan ook 'n lae-kode-benadering tot ontwikkeling genoem word, wat 'n lae drempel het vir die invoer van Big Data-tegnologieë en die toepassingsontwikkelingsproses versnel.
Die volgende stap in die implementering van die projek was om die formaat van 'n enkele semantiese laag gedetailleerde data te bring. As 'n entiteit historiese eienskappe het, word die berekening in die konteks van die betrokke partisie uitgevoer. As die entiteit nie histories is nie, dan is dit opsioneel moontlik om óf die hele inhoud van die voorwerp te herbereken, óf heeltemal te weier om hierdie voorwerp te herbereken (weens die afwesigheid van veranderinge). Op hierdie stadium word sleutels vir alle entiteite gegenereer. Die sleutels word gestoor in die Hbase-gidse wat ooreenstem met die meestervoorwerpe, wat die ooreenstemming bevat tussen die sleutels in die analitiese platform en die sleutels van die bronstelsels. Konsolidasie van atoomentiteite gaan gepaard met verryking met die resultate van voorlopige berekening van analitiese data. Die raamwerk vir die berekening van die data was Spark. Die beskryfde funksionaliteit om data na 'n enkele semantiek te bring, is ook geïmplementeer op grond van kartering van die Datagram-laekode-instrument.
Die teikenargitektuur wat nodig is om SQL-toegang tot data vir besigheidsgebruikers te verskaf. Hive is vir hierdie opsie gebruik. Registrasie van voorwerpe in Hive word outomaties uitgevoer wanneer jy die "Registreer Korf Tabel" opsie in die lae-kode instrument aktiveer.
Betaalstaatbestuur
Datagram het 'n koppelvlak vir die bou van 'n werkvloeiontwerp. Kartering kan uitgevoer word met behulp van die Oozie skeduleerder. In die stroomontwikkelaarkoppelvlak is dit moontlik om skemas vir parallelle, opeenvolgende of toestandafhanklike datatransformasies te skep. Daar is ondersteuning vir dopskrifte en java-programme. Dit is ook moontlik om die Apache Livy-bediener te gebruik. Apache Livy word gebruik om toepassings direk vanaf die ontwikkelingsomgewing te laat loop.
As die maatskappy reeds sy eie prosesorkeseerder het, is dit moontlik om die REST API te gebruik om kartering in 'n bestaande vloei in te sluit. Ons het byvoorbeeld 'n redelik suksesvolle ervaring gehad om Scala-afbeeldings in te sluit in orkestreerders wat in PLSQL en Kotlin geskryf is. Die REST API van 'n lae-kode instrument impliseer die teenwoordigheid van sulke bewerkings soos die generering van 'n uitvoerbare jaar gebaseer op die kartering ontwerp, die oproep van die kartering, die oproep van die volgorde van kartering, en, natuurlik, deur te gee van parameters na die URL om die kartering te begin .
Saam met Oozie, is dit moontlik om die vloei van berekening te organiseer met behulp van Airflow. Miskien sal ek nie lank stilstaan by die vergelyking van Oozie en Airflow nie, maar ek sal bloot sê dat in die konteks van die werk aan die medianavorsingsprojek, die keuse in die rigting van Airflow geval het. Die hoofargumente hierdie keer was 'n meer aktiewe gemeenskap wat die produk ontwikkel, en 'n meer ontwikkelde koppelvlak + API.
Lugvloei is ook goed omdat dit die geliefde Python deur baie gebruik om die berekeningsprosesse te beskryf. En oor die algemeen is daar nie soveel oopbronwerkvloeibestuurplatforms nie. Die bekendstelling en monitering van die uitvoering van prosesse (insluitend dié met 'n Gantt-kaart) voeg net punte by Airflow se karma.
Die konfigurasielêerformaat vir die uitvoer van lae-kode oplossing kartering het vonk-indien geword. Dit het om twee redes gebeur. Eerstens laat spark-submit jou toe om 'n jar-lêer direk vanaf die konsole te laat loop. Tweedens kan dit al die nodige inligting bevat om die werkvloei te konfigureer (wat dit makliker maak om skrifte te skryf wat die Dag vorm).
Die mees algemene Airflow-werkvloeielement in ons geval was die SparkSubmitOperator.
SparkSubmitOperator laat jou toe om potte - verpakte Datagram-afbeeldings met voorafgevormde invoerparameters daarvoor te laat loop.
Dit moet genoem word dat elke Airflow-taak op 'n aparte draad loop en niks van ander take weet nie. In hierdie verband word interaksie tussen take uitgevoer met behulp van beheeroperateurs, soos DummyOperator of BranchPythonOperator.
Saam het die gebruik van die Datagram-laekode-oplossing in samewerking met die universalisering van konfigurasielêers (wat Dag gevorm het) gelei tot 'n aansienlike versnelling en vereenvoudiging van die proses om data-laaivloei te ontwikkel.
Uitstalberekening
Miskien is die mees intellektueel veeleisende stap in die produksie van analitiese data die stap om 'n winkelfront te bou. In die konteks van een van die navorsingsmaatskappy se databerekeningstrome vind die omskakeling na die verwysingsuitsending op hierdie stadium plaas, met inagneming van die regstelling vir tydsones met verwysing na die uitsaairooster. Dit is ook moontlik om vir die plaaslike uitsaairooster (plaaslike nuus en advertensies) reg te stel. Hierdie stap voer onder andere 'n uiteensetting uit van die intervalle van deurlopende kyk van mediaprodukte gebaseer op die ontleding van die kykintervalle. Daar is onmiddellik 'n "gewig" van die aansigwaardes gebaseer op inligting oor hul betekenis (berekening van 'n korreksiefaktor).
'n Afsonderlike stap in die voorbereiding van vertoonvensters is datavalidering. Die valideringsalgoritme word gekoppel aan die gebruik van 'n aantal wiskundige wetenskapmodelle. Die gebruik van 'n lae-kode platform laat jou egter toe om 'n komplekse algoritme in 'n aantal afsonderlike visueel leesbare kaarte op te breek. Elkeen van die kartering voer 'n noue taak uit. As gevolg hiervan is intermediêre ontfouting, aanteken en visualisering van datavoorbereidingstadia moontlik.
Daar is besluit om die valideringsalgoritme in die volgende substadia te diskretiseer:
- Konstruksie van regressie-afhanklikhede van televisienetwerkkyk in die streek met die besigtiging van alle netwerke in die streek vir 60 dae.
- Berekening van gestudentiseerde residue (afwykings van werklike waardes van dié wat deur die regressiemodel voorspel word) vir alle regressiepunte en vir die vereffeningsdag.
- 'n Seleksie van abnormale streek-TV-netwerkpare, waar die gestudentiseerde balans van die vereffeningsdag die norm oorskry (gespesifiseer deur die bedryfsinstellings).
- Herberekening van die gekorrigeerde gestudentiseerde saldo vir abnormale streek-TV-netwerkpare vir elke respondent wat na die netwerk in die streek gekyk het met die bepaling van die bydrae van hierdie respondent (die bedrag van verandering in die gestudentiseerde saldo) terwyl die kyk van hierdie respondent uitgesluit word vanaf die monster.
- Soek na kandidate wie se uitsluiting die gestudentiseerde balans van die skikkingsdag na normaal terugbring.
Bogenoemde voorbeeld is 'n bevestiging van die hipotese dat 'n data-ingenieur reeds te veel in sy kop behoort te hê ... En, as dit regtig 'n "ingenieur" is en nie 'n "kodeerder nie", dan is die vrees vir professionele agteruitgang by die gebruik van lae -kode gereedskap wat hy uiteindelik moet terugtrek.
Wat anders kan lae-kode doen?
Die omvang van 'n lae-kode-instrument vir bondel- en stroomdataverwerking sonder dat dit nodig is om kode handmatig in Scala te skryf, eindig nie daar nie.
Die gebruik van lae-kode in die ontwikkeling van data mere het reeds 'n standaard vir ons geword. Waarskynlik kan ons sê dat oplossings op die Hadoop-stapel die pad van ontwikkeling van klassieke DWH wat op RDBMS gebaseer is, herhaal. Lae-kode gereedskap op die Hadoop stapel kan beide data verwerking take en die take van die bou van finale BI koppelvlakke oplos. Verder moet daarop gelet word dat BI nie net die voorstelling van data kan beteken nie, maar ook hul redigering deur besigheidsgebruikers. Ons gebruik dikwels hierdie funksionaliteit wanneer ons analitiese platforms vir die finansiële sektor bou.
Onder andere, met behulp van lae-kode en veral Datagram, is dit moontlik om die probleem op te los om die oorsprong van datavloeivoorwerpe met atomisiteit na individuele velde (lynlyn) op te spoor. Om dit te doen, implementeer die laekode-instrument koppeling met Apache Atlas en Cloudera Navigator. In wese moet die ontwikkelaar 'n stel voorwerpe in Atlas-woordeboeke registreer en na die geregistreerde voorwerpe verwys wanneer kartering gebou word. Die meganisme om die oorsprong van data op te spoor of die afhanklikhede van voorwerpe te ontleed, spaar baie tyd as dit nodig is om verbeterings aan die berekeningsalgoritmes aan te bring. Byvoorbeeld, wanneer jy finansiële state bou, stel hierdie kenmerk jou in staat om die tydperk van wetsveranderinge gemakliker te oorleef. Hoe meer kwalitatief ons die interform-afhanklikheid in die konteks van die voorwerpe van die gedetailleerde laag besef, hoe minder sal ons "skielike" defekte teëkom en die aantal herwerke verminder.
Datakwaliteit en lae kode
Nog 'n taak wat deur die laekode-instrument op die Mediascope-projek geïmplementeer is, was die taak van die Datakwaliteit-klas. 'n Kenmerk van die implementering van die dataverifikasiepyplyn vir die projek van 'n navorsingsmaatskappy was die afwesigheid van 'n impak op die prestasie en spoed van die hoofvloei van databerekening. Vir die moontlikheid om onafhanklike datavalideringsvloei te orkestreer, is die reeds bekende Apache Airflow gebruik. Aangesien elke stap van dataproduksie gereed was, is 'n aparte deel van die DQ-pyplyn parallel geloods.
Dit is goeie praktyk om die kwaliteit van data te monitor vanaf die oomblik dat dit in 'n analitiese platform gebore word. Met inligting oor metadata, kan ons die nakoming van die basiese voorwaardes nagaan vanaf die oomblik dat die inligting die primêre laag binnegaan - nie nul, beperkings, vreemde sleutels nie. Hierdie funksionaliteit word geïmplementeer op grond van outomaties gegenereerde kartering van die datakwaliteitfamilie in Datagram. Kodegenerering in hierdie geval is ook gebaseer op modelmetadata. Op die Mediascope-projek was die koppelvlak met die metadata van die Enterprise Architect-produk.
Deur die laekode-instrument en Enterprise Architect te koppel, is die volgende tjeks outomaties gegenereer:
- Kontroleer vir die teenwoordigheid van "nul" waardes in velde met die "nie nul" wysiger;
- Kontroleer vir die teenwoordigheid van duplikate van die primêre sleutel;
- Kontroleer die vreemde sleutel van 'n entiteit;
- Kontroleer die uniekheid van 'n string deur 'n stel velde.
Vir meer komplekse kontroles van databeskikbaarheid en geldigheid, is 'n kartering geskep met Scala Expression, wat 'n eksterne Spark SQL-kontrolekode wat deur Zeppelin-ontleders voorberei is, as inset neem.
Natuurlik moet outo-generering van tjeks geleidelik benader word. Binne die raamwerk van die beskryfde projek is dit deur die volgende stappe voorafgegaan:
- DQ geïmplementeer in Zeppelin notaboeke;
- DQ ingebed in kartering;
- DQ in die vorm van afsonderlike massiewe kartering wat 'n hele stel tjeks vir 'n aparte entiteit bevat;
- Generiese geparameteriseerde DQ-kaarte wat inligting oor metadata en besigheidskontroles as insette aanvaar.
Miskien is die grootste voordeel van die skep van 'n geparameteriseerde tjekdiens die vermindering in die tyd wat dit neem om die funksionaliteit aan die produksie-omgewing te lewer. Nuwe kwaliteitskontroles kan die klassieke patroon van die lewering van kode indirek deur ontwikkeling- en toetsomgewings omseil:
- Alle metadata-tjeks word outomaties gegenereer wanneer die model in EA verander word;
- Databeskikbaarheidkontroles (wat die teenwoordigheid van enige data op 'n tydstip bepaal) kan gegenereer word op grond van 'n gids wat die verwagte tydsberekening van die verskyning van die volgende gedeelte data in die konteks van voorwerpe stoor;
- Besigheidsdata-validasies word deur ontleders in Zeppelin-notaboeke geskep. Van waar hulle reguit na die opsteltabelle van die DQ-module op die produksie-omgewing gestuur word.
Daar is geen risiko's van direkte versending van draaiboeke vir produksie as sodanig nie. Selfs met 'n sintaksfout, is die maksimum wat ons bedreig die versuim om een kontrole uit te voer, want die vloei van databerekening en die vloei van die bekendstelling van kwaliteitkontroles is van mekaar geskei.
Trouens, die DQ-diens loop permanent op die produksie-omgewing en is gereed om met sy werk te begin op die oomblik dat die volgende stukkie data verskyn.
In plaas daarvan om 'n gevolgtrekking
Die voordeel van die gebruik van lae-kode is voor die hand liggend. Ontwikkelaars hoef nie 'n toepassing van nuuts af te ontwikkel nie. En die programmeerder wat van bykomende take bevry is, gee die resultaat vinniger. Spoed maak op sy beurt 'n bykomende tydsbron vry om optimaliseringskwessies op te los. Daarom kan u in hierdie geval staatmaak op die beskikbaarheid van 'n beter en vinniger oplossing.
Lae-kode is natuurlik nie 'n wondermiddel nie, en magie sal nie vanself gebeur nie:
- Die laekode-industrie gaan deur 'n "versterkende" stadium, en tot dusver is daar geen eenvormige industriële standaarde daarin nie;
- Baie laekode-oplossings is nie gratis nie, en die verkryging daarvan moet 'n bewuste stap wees wat met volle vertroue geneem moet word in die finansiële voordele van die gebruik daarvan;
- Baie lae-kode oplossings speel nie altyd goed met GIT/SVN nie. Óf hulle is ongerieflik om te gebruik in die geval van die wegsteek van die gegenereerde kode;
- Wanneer die argitektuur uitgebrei word, kan dit nodig wees om die lae-kode-oplossing te verfyn - wat op sy beurt die effek van "aanhegting en afhanklikheid" op die verskaffer van die lae-kode-oplossing uitlok.
- ’n Behoorlike vlak van sekuriteit is moontlik, maar baie arbeidsintensief en moeilik om te implementeer in laekode-enjins. Lae-kode-platforms moet nie net gekies word op grond van die beginsel om voordele uit hul gebruik te vind nie. By die keuse is dit die moeite werd om vrae te vra oor die beskikbaarheid van toegangsbeheerfunksionaliteit en delegering / eskalasie van identifikasiedata na die vlak van die hele IT-landskap van die organisasie.
As al die nadele van die gekose stelsel egter aan u bekend is, en die voordele van die gebruik daarvan is nietemin in die oorheersende meerderheid, gaan dan sonder vrees voort na die klein kode. Boonop is die oorgang daarna onvermydelik – aangesien enige evolusie onvermydelik is.
As een ontwikkelaar op 'n lae-kode-platform hul werk vinniger kan doen as twee ontwikkelaars sonder lae-kode, dan gee dit die maatskappy in alle opsigte 'n voorsprong. Die toegangsdrempel vir laekode-oplossings is laer as vir "tradisionele" tegnologieë, en dit het 'n positiewe uitwerking op die kwessie van personeeltekort. Wanneer lae-kode nutsmiddels gebruik word, is dit moontlik om die interaksie tussen funksionele spanne te versnel en vinniger besluite te neem oor die korrektheid van die gekose pad van data-wetenskap-navorsing. Laevlakplatforms kan die rede wees vir die digitale transformasie van 'n organisasie, aangesien die oplossings wat geproduseer word deur nie-tegniese spesialiste (veral besigheidsgebruikers) verstaan kan word.
As jy streng spertye, gelaaide besigheidslogika, gebrek aan tegnologiese kundigheid het, en jy moet die tyd tot mark bespoedig, dan is lae-kode een van die maniere om aan jou behoeftes te voldoen.
Die belangrikheid van tradisionele ontwikkelingsinstrumente kan nie ontken word nie, maar in baie gevalle is die gebruik van lae-kode oplossings die beste manier om die doeltreffendheid van die take wat opgelos word, te verhoog.
Bron: will.com