Notkun lágkóða í greiningarkerfum

Kæru lesendur, góðan daginn!

Það verkefni að byggja upp upplýsingatæknivettvang til að safna og greina gögn kemur fyrr eða síðar upp fyrir hvert fyrirtæki sem byggir á vitsmunalega hlaðnu þjónustuafhendingarlíkani eða sköpun tæknilega flókinna vara. Að byggja upp greiningarvettvang er flókið og tímafrekt verkefni. Hins vegar er hægt að einfalda hvaða verkefni sem er. Í þessari grein vil ég deila reynslu minni af því að nota lágkóða verkfæri til að hjálpa til við að búa til greiningarlausnir. Þessi reynsla fékkst við innleiðingu fjölda verkefna í stórgagnalausnastefnu Neoflex fyrirtækisins. Frá árinu 2005 hefur Neoflex stefna Big Data Solutions fengist við að byggja upp gagnageymslur og vötn, leysa vandamál við að hámarka hraða upplýsingavinnslu og vinna að aðferðafræði fyrir gagnagæðastjórnun.

Enginn mun geta komist hjá meðvitaðri uppsöfnun veikburða og/eða sterkbyggðra gagna. Kannski jafnvel þótt við séum að tala um lítil fyrirtæki. Þegar öllu er á botninn hvolft mun efnilegur frumkvöðull standa frammi fyrir vandamálum um að þróa vildarkerfi, vilja greina skilvirkni sölustaða, hugsa um markvissar auglýsingar og verða undrandi á eftirspurn eftir meðfylgjandi vörum. . Að fyrstu nálgun er hægt að leysa vandamálið „á hnénu“. En eftir því sem fyrirtækið stækkar er enn óhjákvæmilegt að komast á greiningarvettvang.

Hins vegar, í hvaða tilfelli geta gagnagreiningarverkefni þróast í „Rocket Science“ bekkjarvandamál? Kannski á því augnabliki þegar við erum að tala um mjög stór gögn.
Til að gera Rocket Science auðveldara geturðu borðað fílinn bit fyrir bit.

Því aðgreindari og sjálfstæðari sem forritin/þjónustan/örþjónustan þín eru, því auðveldara verður fyrir þig, samstarfsmenn þína og allt fyrirtækið að melta fílinn.

Næstum allir viðskiptavinir okkar komu að þessari stellingu, eftir að hafa endurbyggt landslagið byggt á verkfræðiaðferðum DevOps teymanna.

En jafnvel með „aðskildu, fíla“ mataræði eigum við góða möguleika á „ofmettun“ á upplýsingatæknilandslaginu. Á þessari stundu er þess virði að stoppa, anda frá sér og horfa til hliðar lágkóða verkfræðivettvangur.

Margir forritarar eru hræddir við möguleikann á blindgötu á ferlinum þegar þeir hverfa frá því að skrifa kóða beint í átt að „draga“ örvar í viðmóti viðmóta lágkóðakerfa. En tilkoma véla leiddi ekki til þess að verkfræðingar hurfu, heldur færði vinnu þeirra á nýtt stig!

Við skulum reikna út hvers vegna.

Gagnagreining á sviði flutninga, fjarskiptaiðnaðar, fjölmiðlarannsókna, fjármálageirans tengist alltaf eftirfarandi spurningum:

• Hraði sjálfvirkrar greiningar;
• Geta til að framkvæma tilraunir án þess að hafa áhrif á helstu gagnaframleiðsluflæði;
• Áreiðanleiki tilbúinna gagna;
• Breyta rakningu og útgáfu;
• Gagnauppruni, Gagnaætt, CDC;
• Fljótleg afhending nýrra eiginleika til framleiðsluumhverfisins;
• Og hið alræmda: kostnaður við þróun og stuðning.

Það er, verkfræðingar hafa gríðarlegan fjölda verkefna á háu stigi, sem hægt er að ljúka með nægilega skilvirkni með því að hreinsa meðvitund sína um þróunarverkefni á lágu stigi.

Forsendur þess að þróunaraðilar færu á nýtt stig voru þróun og stafræn væðing fyrirtækja. Verðmæti framkvæmdaraðila er einnig að breytast: það er verulegur skortur á þróunaraðilum sem geta sökkt sér niður í hugmyndafræði fyrirtækisins sem er sjálfvirk.

Við skulum draga líkingu við lágstigs og háþróað forritunarmál. Umskiptin frá lágstigi tungumálum yfir í háþróaða tungumál eru umskipti frá því að skrifa „beinar tilskipanir á tungumáli vélbúnaðar“ yfir í „tilskipanir á tungumáli fólks“. Það er, að bæta við einhverju lag af abstrakt. Í þessu tilviki er umskiptin yfir í lágkóðakerfi frá háþróuðum forritunarmálum umskipti frá „tilskipunum á tungumáli fólks“ í „tilskipanir á tungumáli viðskipta“. Ef það eru forritarar sem eru sorgmæddir yfir þessari staðreynd, þá hafa þeir verið sorgmæddir, ef til vill, frá því augnabliki sem Java Script fæddist, sem notar fylkisflokkunaraðgerðir. Og þessar aðgerðir eru auðvitað með hugbúnaðarútfærslu undir húddinu með öðrum hætti með sömu háu forritun.

Þess vegna er lágkóði bara útlitið á öðru abstraktstigi.

Beitt reynsla með því að nota lágkóða

Viðfangsefnið lágkóða er nokkuð breitt, en nú langar mig að tala um hagnýta beitingu „lágkóðahugtaka“ með því að nota dæmi um eitt af verkefnum okkar.

Big Data Solutions deild Neoflex sérhæfir sig meira í fjármálageiranum í viðskiptum, byggingu gagnageymslur og vötn og sjálfvirkur margvísleg skýrslugerð. Í þessum sess er notkun lágkóða löngu orðin staðall. Meðal annarra tækja með litlum kóða má nefna verkfæri til að skipuleggja ETL ferla: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Eða Oracle Apex, sem virkar sem umhverfi fyrir hraða þróun á viðmótum til að nálgast og breyta gögnum. Hins vegar, notkun lágkóða þróunarverkfæra felur ekki alltaf í sér að byggja mjög markviss forrit á viðskiptatæknistafla með skýrri háð seljanda.

Með því að nota lágkóðakerfi geturðu líka skipulagt skipulagningu gagnaflæðis, búið til gagnavísindavettvang eða til dæmis einingar til að athuga gæði gagna.

Eitt af beittum dæmum um reynslu af notkun lágkóðaþróunarverkfæra er samstarf Neoflex og Mediascope, eins af leiðtogum rússneska fjölmiðlarannsóknamarkaðarins. Eitt af viðskiptamarkmiðum þessa fyrirtækis er framleiðsla gagna á grundvelli þeirra sem auglýsendur, netkerfi, sjónvarpsrásir, útvarpsstöðvar, auglýsingastofur og vörumerki taka ákvarðanir um innkaup á auglýsingum og skipuleggja markaðssamskipti sín.

Fjölmiðlarannsóknir eru tæknilega hlaðið viðskiptasvið. Að þekkja myndbandsraðir, safna gögnum úr tækjum sem greina áhorf, mæla virkni á vefauðlindum - allt felur þetta í sér að fyrirtækið hefur stóran upplýsingatæknistarfsmann og gríðarlega reynslu í að byggja upp greiningarlausnir. En veldisvöxtur í magni upplýsinga, fjölda og fjölbreytni heimilda þeirra neyðir upplýsingatæknigagnaiðnaðinn til stöðugra framfara. Einfaldasta lausnin til að stækka Mediascope greiningarvettvang sem þegar virkar gæti verið að fjölga upplýsingatæknistarfsfólki. En mun áhrifaríkari lausn er að flýta fyrir þróunarferlinu. Eitt af skrefunum sem leiða í þessa átt getur verið notkun á lágkóðapöllum.

Þegar verkefnið hófst var fyrirtækið þegar með virka vörulausn. Hins vegar gat innleiðing lausnarinnar í MSSQL ekki að fullu staðið undir væntingum um stærðarvirkni á meðan viðhaldið var ásættanlegum þróunarkostnaði.

Verkefnið sem blasti við okkur var sannarlega metnaðarfullt - Neoflex og Mediascope þurftu að búa til iðnaðarlausn á innan við ári, með fyrirvara um útgáfu MVP innan fyrsta ársfjórðungs frá upphafsdegi.

Hadoop tæknistaflinn var valinn grunnur að því að byggja upp nýjan gagnavettvang sem byggir á lágkóðatölvu. HDFS er orðinn staðall fyrir gagnageymslu með parketskrám. Til að fá aðgang að gögnum sem staðsett eru á pallinum var Hive notað, þar sem allar tiltækar geymslur eru sýndar í formi ytri töflur. Hleðsla gagna í geymsluna var útfærð með Kafka og Apache NiFi.

Lowe-kóða tólið í þessu hugtaki var notað til að hámarka vinnufrekasta verkefnið við að byggja upp greiningarvettvang - verkefnið að reikna gögn.

Lágkóði Datagram tólið var valið sem aðalbúnaður fyrir kortlagningu gagna. Neoflex Datagram er tæki til að þróa umbreytingar og gagnaflæði.
Með því að nota þetta tól geturðu gert án þess að skrifa Scala kóða handvirkt. Scala kóða er myndaður sjálfkrafa með því að nota Model Driven Architecture nálgun.

Augljós kostur við þessa nálgun er að hraða þróunarferlinu. Hins vegar, auk hraðans, eru einnig eftirfarandi kostir:

• Skoða innihald og uppbyggingu heimilda/viðtakenda;
• Rekja uppruna gagnaflæðishluta til einstakra reita (ætterni);
• Framkvæmd umbreytinga að hluta með skoðun á milliniðurstöðum;
• Skoða frumkóðann og stilla hann fyrir framkvæmd;
• Sjálfvirk löggilding umbreytinga;
• Sjálfvirkt niðurhal gagna 1 í 1.

Hindrun fyrir aðgang að lágkóðalausnum til að búa til umbreytingar er frekar lítil: verktaki þarf að þekkja SQL og hafa reynslu af því að vinna með ETL verkfæri. Þess má geta að kóðadrifnir umbreytingarrafallar eru ekki ETL verkfæri í víðum skilningi þess orðs. Lágkóða verkfæri mega ekki hafa sitt eigið keyrsluumhverfi. Það er að myndakóðinn verður keyrður í umhverfinu sem var til í þyrpingunni jafnvel áður en lágkóðalausnin var sett upp. Og þetta er kannski annar plús fyrir lágkóða karma. Þar sem, samhliða lágkóðateymi, getur „klassískt“ teymi unnið sem útfærir virkni, til dæmis í hreinum Scala kóða. Það verður einfalt og óaðfinnanlegt að koma endurbótum frá báðum liðum í framleiðslu.

Það er kannski athyglisvert að til viðbótar við lágkóða eru líka lausnir án kóða. Og í grunninn eru þetta ólíkir hlutir. Lágkóði gerir verktaki kleift að trufla meira kóðann sem myndast. Þegar um er að ræða Datagram er hægt að skoða og breyta Scala kóðanum sem myndaður er; enginn kóða veitir kannski ekki slíkt tækifæri. Þessi munur er mjög mikilvægur, ekki aðeins hvað varðar sveigjanleika lausnarinnar, heldur einnig hvað varðar þægindi og hvatningu í starfi gagnaverkfræðinga.

Lausnararkitektúr

Við skulum reyna að reikna út nákvæmlega hvernig tól með litlum kóða hjálpar til við að leysa vandamálið við að hámarka hraða þróunar gagnaútreikningsvirkni. Í fyrsta lagi skulum við líta á hagnýtan arkitektúr kerfisins. Dæmi í þessu tilviki er gagnaframleiðslulíkanið fyrir fjölmiðlarannsóknir.

Gagnaheimildir í okkar tilviki eru mjög ólíkar og fjölbreyttar:

• Fólksmælar (sjónvarpsmælar) eru hugbúnaðar- og vélbúnaðartæki sem lesa hegðun notenda frá svarendum sjónvarpsborðs - hver, hvenær og hvaða sjónvarpsrás var horft á á heimilinu sem tekur þátt í rannsókninni. Meðfylgjandi upplýsingar eru straumur af útsendingaráhorfsbilum sem tengjast miðlunarpakkanum og fjölmiðlavöru. Hægt er að auðga gögn á stigi hleðslu í Data Lake með lýðfræðilegum eiginleikum, landskiptingu, tímabelti og öðrum upplýsingum sem nauðsynlegar eru til að greina sjónvarpsáhorf á tiltekna fjölmiðlavöru. Mælingarnar sem gerðar eru má nota til að greina eða skipuleggja auglýsingaherferðir, meta virkni og óskir áhorfenda og setja saman útvarpsnetið;
• Gögnin geta komið frá vöktunarkerfum til að streyma sjónvarpsútsendingum og mæla áhorf á myndbandsefni á netinu;
• Mælitæki í vefumhverfinu, þar á meðal bæði svæðismiðaðir og notendamiðaðir mælar. Gagnaveitan fyrir Data Lake getur verið viðbót við rannsóknarstikuvafra og farsímaforrit með innbyggðu VPN.
• Gögn geta einnig komið frá síðum sem sameina niðurstöður útfyllingar spurningalista á netinu og niðurstöður símaviðtala í fyrirtækjakönnunum;
• Viðbótaraukning á gagnavatninu getur átt sér stað með því að hlaða niður upplýsingum úr skrám samstarfsfyrirtækja.

Hægt er að skipuleggja innleiðingu as is hleðslu úr upprunakerfum inn í frumsviðssetningu hrágagna á ýmsan hátt. Ef lágkóði er notaður í þessum tilgangi er sjálfvirk gerð hleðsluforskrifta sem byggjast á lýsigögnum möguleg. Í þessu tilviki er engin þörf á að fara niður á stig þróunarheimildar til að miða á kortlagningu. Til að innleiða sjálfvirka hleðslu þurfum við að koma á tengingu við upprunann og skilgreina síðan í hleðsluviðmótinu lista yfir einingar sem á að hlaða. Möppuuppbyggingin í HDFS verður búin til sjálfkrafa og mun samsvara uppbyggingu gagnageymslunnar á upprunakerfinu.

Hins vegar, í tengslum við þetta verkefni, ákváðum við að nota ekki þennan eiginleika lágkóðavettvangsins vegna þess að Mediascope fyrirtækið hefur þegar sjálfstætt hafið vinnu við að framleiða svipaða þjónustu með Nifi + Kafka samsetningunni.

Það er þess virði að gefa strax til kynna að þessi verkfæri eru ekki skiptanleg, heldur viðbót. Nifi og Kafka geta unnið bæði í beinni (Nifi -> Kafka) og í öfugri (Kafka -> Nifi) tengingu. Fyrir fjölmiðlarannsóknarvettvanginn var fyrsta útgáfan af búntinum notuð.

Í okkar tilviki þurfti NayFi að vinna úr ýmsum gerðum gagna úr upprunakerfum og senda þau til Kafka miðlara. Í þessu tilviki voru skilaboð send til ákveðins Kafka efnis með því að nota PublishKafka Nifi örgjörva. Skipun og viðhald þessara leiðslna fer fram í sjónrænu viðmóti. Nifi tólið og notkun Nifi + Kafka samsetningarinnar má einnig kalla lágkóða nálgun við þróun, sem hefur litla aðgangshindrun í Big Data tækni og flýtir fyrir þróunarferli forrita.

Næsta stig í framkvæmd verkefnisins var að koma ítarlegum gögnum í eitt merkingarlagssnið. Ef eining hefur sögulega eiginleika er útreikningurinn framkvæmdur í samhengi við viðkomandi skiptingu. Ef einingin er ekki söguleg, þá er valfrjálst mögulegt að annað hvort endurreikna allt innihald hlutarins eða neita algjörlega að endurreikna þennan hlut (vegna skorts á breytingum). Á þessu stigi eru lyklar búnir til fyrir allar einingar. Lyklarnir eru geymdir í Hbase möppunum sem samsvara aðalhlutunum, sem innihalda samsvörun á milli lyklanna í greiningarvettvangnum og lyklanna úr frumkerfunum. Sameiningu atómeininga fylgir auðgun með niðurstöðum bráðabirgðaútreiknings á greiningargögnum. Ramminn fyrir gagnaútreikning var Spark. Lýst virkni til að koma gögnum í eina merkingarfræði var einnig útfærð á grundvelli kortlagningar frá lágkóða Datagram tólinu.

Markarkitektúrinn krafðist SQL aðgangs að gögnum fyrir viðskiptanotendur. Hive var notað fyrir þennan valkost. Hlutir eru skráðir sjálfkrafa í Hive þegar þú virkjar „Registreer Hive Table“ valmöguleikann í lágkóða tólinu.

Útreikningsflæðisstýring

Datagram hefur viðmót til að búa til flæðishönnun verkflæðis. Hægt er að ræsa kortlagningu með Oozie tímaáætlun. Í straumhönnuðarviðmótinu er hægt að búa til kerfi fyrir samhliða, raðbundnar eða framkvæmdaháðar gagnabreytingar. Það er stuðningur við skeljaforskriftir og Java forrit. Það er líka hægt að nota Apache Livy netþjóninn. Apache Livy er notað til að keyra forrit beint úr þróunarumhverfinu.

Ef fyrirtækið er nú þegar með sinn eigin ferlisveitarmann er hægt að nota REST API til að fella inn kortanir í núverandi flæði. Til dæmis höfðum við nokkuð farsæla reynslu af því að fella inn kortanir í Scala inn í hljómsveitarstjóra skrifaðar í PLSQL og Kotlin. REST API lágkóða tólsins felur í sér aðgerðir eins og að búa til keyranlegt ártal byggt á kortlagningarhönnuninni, kalla á kortlagningu, kalla á röð af kortlagningum og að sjálfsögðu senda færibreytur á vefslóðina til að keyra kortlagningar.

Ásamt Oozie er hægt að skipuleggja útreikningsflæði með Airflow. Kannski mun ég ekki dvelja lengi við samanburðinn á Oozie og Airflow, en mun einfaldlega segja að í tengslum við vinnu við fjölmiðlarannsóknarverkefni féll valið Airflow í vil. Helstu rökin að þessu sinni voru virkara samfélag við þróun vörunnar og þróaðra viðmót + API.

Loftflæði er líka gott vegna þess að það notar hinn ástsæla Python til að lýsa útreikningsferlum. Og almennt séð eru ekki svo margir opinn uppspretta verkflæðisstjórnunarvettvangar. Að ræsa og fylgjast með framkvæmd ferla (þar á meðal Gantt töflu) bætir aðeins stigum við karma Airflow.

Stillingarskráarsniðið til að hefja kortlagningu á lágkóðalausnum hefur orðið neistasending. Þetta gerðist af tveimur ástæðum. Í fyrsta lagi gerir spark-submit þér kleift að keyra jar skrá beint frá stjórnborðinu. Í öðru lagi getur það innihaldið allar nauðsynlegar upplýsingar til að stilla verkflæðið (sem gerir það auðveldara að skrifa forskriftir sem búa til Dag).
Algengasta þátturinn í loftflæðisvinnuflæðinu í okkar tilfelli var SparkSubmitOperator.

SparkSubmitOperator gerir þér kleift að keyra krukkur - pakkaðar Datagram kortlagningar með fyrirfram mynduðum inntaksbreytum fyrir þær.

Þess má geta að hvert Airflow verkefni keyrir í sérstökum þræði og veit ekkert um önnur verkefni. Þess vegna er samspil milli verkefna framkvæmt með því að nota stjórntæki, eins og DummyOperator eða BranchPythonOperator.

Samanlagt leiddi notkun á Datagram lágkóðalausninni í tengslum við algildingu stillingaskráa (sem myndar Dag) til umtalsverðrar hröðunar og einföldunar á ferlinu við að þróa gagnahleðsluflæði.

Sýndu útreikninga

Kannski er vitsmunalega hlaðna stigið í framleiðslu greiningargagna skrefið að byggja upp sýningarskápa. Í samhengi við eitt af gagnaútreikningsstreymum rannsóknarfyrirtækisins, á þessu stigi, eru gögnin færð niður í viðmiðunarútsendingu, að teknu tilliti til leiðréttinga fyrir tímabelti og tengd útsendingarnetinu. Einnig er hægt að aðlaga fyrir staðbundnu útvarpsnetinu (staðbundnar fréttir og auglýsingar). Í þessu skrefi er meðal annars sundurliðað millibil stöðugrar skoðunar á fjölmiðlavörum út frá greiningu á áhorfsbili. Strax eru áhorfsgildin „vegin“ út frá upplýsingum um mikilvægi þeirra (útreikningur á leiðréttingarstuðli).

Sérstakt skref í að undirbúa sýningarskápa er sannprófun gagna. Staðfestingaralgrímið felur í sér notkun fjölda stærðfræðilegra vísindalíkana. Hins vegar gerir notkun lágkóðavettvangs þér kleift að brjóta flókið reiknirit í fjölda aðskildra sjónrænt læsilegra korta. Hver kortlagning framkvæmir þröngt verkefni. Fyrir vikið er millileiðvilla, skráning og sjónun á gagnaundirbúningsstigum möguleg.

Ákveðið var að sérgreina löggildingaralgrímið í eftirfarandi undirþrep:

• Byggja upp afturköllun á áhorfsfíkn sjónvarpsneta á svæði með áhorfi á öll net á svæðinu í 60 daga.
• Útreikningur á námsgreindum leifum (frávik raungilda frá þeim sem spáð er fyrir með aðhvarfslíkaninu) fyrir alla aðhvarfspunkta og fyrir reiknaðan dag.
• Úrval af afbrigðilegum svæðis-netpörum, þar sem nemandi staða uppgjörsdagsins fer yfir viðmið (tilgreint af rekstrarstillingum).
• Endurútreikningur á leiðréttu námsverði fyrir óeðlileg svæðis-sjónvarpsnetpör fyrir hvern svaranda sem horfði á netið á svæðinu, ákvarðar framlag þessa svaranda (fjárhæð breytinga á námsefnisleifinni) þegar áhorf þessa svaranda er útilokað frá úrtakinu .
• Leitaðu að frambjóðendum þar sem útilokun færir námsmannastöðu launadags aftur í eðlilegt horf.

Dæmið hér að ofan staðfestir þá tilgátu að gagnaverkfræðingur hafi þegar of mikið á prjónunum... Og ef þetta er í raun og veru „verkfræðingur“ en ekki „kóðari“, þá er óttinn við faglega niðurníðslu þegar hann notar lágkóðaverkfæri. verður að lokum að hörfa.

Hvað annað getur lágkóði gert?

Notkunarsvið lágkóðatóls fyrir lotu- og straumgagnavinnslu án þess að þurfa að skrifa kóða handvirkt í Scala endar ekki þar.

Notkun lágkóða í þróun gagnaflutnings er þegar orðin staðall fyrir okkur. Við getum líklega sagt að lausnir byggðar á Hadoop staflanum fylgi þróunarleið klassískra DWHs byggðar á RDBMS. Lágkóða verkfæri á Hadoop stafla geta leyst bæði gagnavinnsluverkefni og það verkefni að byggja upp endanleg BI tengi. Ennfremur skal tekið fram að BI getur ekki aðeins þýtt framsetningu gagna heldur einnig klippingu þeirra af viðskiptanotendum. Við notum þessa virkni oft þegar við byggjum upp greiningarvettvang fyrir fjármálageirann.

Meðal annars með því að nota lágkóða og þá sérstaklega Datagram er hægt að leysa vandamálið við að rekja uppruna gagnastraumshluta með atómvirkni niður í einstök svið (ættkvísl). Til að gera þetta útfærir lágkóða tólið viðmót við Apache Atlas og Cloudera Navigator. Í meginatriðum þarf verktaki að skrá safn af hlutum í Atlas orðabókum og vísa til skráðra hluta við smíði korta. Aðgerðin til að rekja uppruna gagna eða greina ósjálfstæði hluta sparar mikinn tíma þegar nauðsynlegt er að gera endurbætur á reikniritum útreikninga. Til dæmis, þegar þú gerir ársreikninga, gerir þessi eiginleiki þér kleift að lifa af tímabil lagabreytinga á auðveldari hátt. Þegar öllu er á botninn hvolft, því betur sem við skiljum háð milli forms í samhengi við hluti í ítarlegu lagi, því minna munum við lenda í "skyndilegum" göllum og fækka endurgerðum.

Gagnagæði og lágkóði

Annað verkefni sem útfært var með lágkóða tólinu í Mediascope verkefninu var Gagnagæða flokksverkefnið. Sérstakur þáttur í innleiðingu gagnasannprófunarleiðslunnar fyrir rannsóknarfyrirtækisverkefnið var skortur á áhrifum á afköst og hraða aðalgagnaútreikningsflæðisins. Til að geta skipulagt óháð gagnasannprófunarflæði, var þegar kunnuglegt Apache Airflow notað. Þar sem hvert skref í gagnaframleiðslu var tilbúið var sérstakur hluti af DQ leiðslunni hleypt af stokkunum samhliða.

Það þykir góð venja að fylgjast með gæðum gagna frá upphafi þeirra í greiningarvettvangi. Með því að hafa upplýsingar um lýsigögn getum við athugað samræmi við grunnskilyrði frá því augnabliki sem upplýsingarnar fara inn í aðallagið - ekki núll, takmarkanir, erlendir lyklar. Þessi virkni er útfærð á grundvelli sjálfkrafa myndaðra korta af gagnagæðafjölskyldunni í Datagram. Kóðagerð í þessu tilfelli er einnig byggð á líkanlýsigögnum. Í Mediascope verkefninu var viðmótið unnið með lýsigögnum Enterprise Architect vörunnar.

Með því að para lágkóða tólið við Enterprise Architect voru eftirfarandi athuganir sjálfkrafa búnar til:

• Athugar hvort „null“ gildi séu til staðar í reitum með „ekki núll“ breytinum;
• Athugun á tilvist afrita af aðallyklinum;
• Athugun á erlendum lykil aðila;
• Athugun á sérstöðu strengs byggt á mengi reita.

Fyrir flóknari athuganir á aðgengi og áreiðanleika gagna var búið til kortlagning með Scala Expression, sem tekur utanaðkomandi Spark SQL athugunarkóða sem útbúinn af sérfræðingum hjá Zeppelin sem inntak.

Auðvitað verður að ná fram sjálfvirkri gerð ávísana smám saman. Innan ramma verkefnisins sem lýst var, voru eftirfarandi skref á undan þessu:

• DQ útfært í Zeppelin fartölvum;
• DQ innbyggt í kortlagningu;
• DQ í formi aðskildra gríðarlegra korta sem innihalda heilt sett af ávísunum fyrir sérstakan aðila;
• Alhliða færibreytur DQ kortlagningar sem taka við upplýsingum um lýsigögn og viðskiptaathuganir sem inntak.

Kannski er helsti kosturinn við að búa til færibreyta ávísunarþjónustu styttingu tímans sem það tekur að skila virkni til framleiðsluumhverfisins. Ný gæðaeftirlit getur farið framhjá hinu klassíska mynstur að afhenda kóða óbeint í gegnum þróunar- og prófunarumhverfi:

• Allar athuganir á lýsigögnum eru búnar til sjálfkrafa þegar líkaninu er breytt í EA;
• Athuganir á aðgengi að gögnum (ákvarða tilvist hvers kyns gagna á hverjum tíma) er hægt að búa til á grundvelli möppu sem geymir væntanlega tímasetningu á útliti næsta gagnahluta í samhengi við hluti;
• Athuganir á löggildingu viðskiptagagna eru búnar til af sérfræðingum í Zeppelin fartölvum. Þaðan eru þær sendar beint í DQ mát uppsetningartöflurnar í framleiðsluumhverfinu.

Það er engin hætta á því að senda handrit beint í framleiðslu. Jafnvel með setningafræðivillu er hámarkið sem ógnar okkur bilun í að framkvæma eina athugun, vegna þess að gagnaútreikningsflæði og gæðaeftirlitsræsingarflæði eru aðskilin frá hvort öðru.

Í meginatriðum er DQ þjónustan í gangi varanlega í framleiðsluumhverfinu og er tilbúin til að hefja störf um leið og næsta gögn birtist.

Í stað þess að niðurstöðu

Kosturinn við að nota lágkóða er augljós. Hönnuðir þurfa ekki að þróa forritið frá grunni. Og forritari sem er laus við fleiri verkefni skilar árangri hraðar. Hraði, aftur á móti, losar um viðbótartíma til að leysa hagræðingarvandamál. Þess vegna, í þessu tilfelli, getur þú treyst á betri og hraðari lausn.

Auðvitað er lágkóði engin töfralyf og galdrar munu ekki gerast af sjálfu sér:

• Lágkóðaiðnaðurinn er að fara í gegnum „að verða sterkari“ stig og það eru engir samræmdir iðnaðarstaðlar ennþá;
• Margar lágkóðalausnir eru ekki ókeypis og að kaupa þær ætti að vera meðvitað skref sem ætti að gera með fullri trú á fjárhagslegum ávinningi af notkun þeirra;
• Margar lágkóðalausnir virka ekki alltaf vel með GIT/SVN. Eða þeir eru óþægilegir í notkun ef myndakóðinn er falinn;
• Þegar arkitektúrinn er stækkaður getur verið nauðsynlegt að betrumbæta lágkóðalausnina - sem aftur vekur áhrif "viðhengis og háðs" á birgja lágkóðalausnarinnar.
• Nægilegt öryggisstig er mögulegt, en það er mjög vinnufrekt og erfitt að innleiða það í kerfisvélum með lágt kóða. Lágkóða pallur ætti að vera valinn ekki aðeins á þeirri meginreglu að leita ávinnings af notkun þeirra. Þegar valið er er vert að spyrja spurninga um framboð á virkni fyrir aðgangsstýringu og framsali/stigmögnun auðkenningargagna á vettvangi alls upplýsingatæknilandslags fyrirtækisins.

Hins vegar, ef allir gallar á valnu kerfi eru þekktir fyrir þig, og ávinningurinn af notkun þess, engu að síður, er í ríkjandi meirihluta, farðu þá áfram í lítinn kóða án ótta. Þar að auki er umskiptin til þess óumflýjanleg - rétt eins og öll þróun er óumflýjanleg.

Ef einn verktaki á lágkóðavettvangi vinnur starf sitt hraðar en tveir forritarar án lágkóða, þá gefur þetta fyrirtækinu forskot í alla staði. Þröskuldurinn fyrir inngöngu í lágkóðalausnir er lægri en í „hefðbundinni“ tækni og það hefur jákvæð áhrif á skort á starfsfólki. Þegar notuð eru lítil kóða verkfæri er hægt að flýta fyrir samskiptum milli starfhæfra teyma og taka hraðari ákvarðanir um réttmæti valinnar leiðar gagnavísindarannsókna. Lágmarksvettvangar geta knúið áfram stafræna umbreytingu fyrirtækis vegna þess að lausnirnar sem framleiddar eru geta skilið af sérfræðingum sem ekki eru tæknimenn (sérstaklega viðskiptanotendur).

Ef þú ert með stutta fresti, hlaðna viðskiptarökfræði, skortur á tæknilegri sérfræðiþekkingu og þú þarft að flýta þér fyrir markaðssetningu, þá er lágkóði ein leið til að mæta þörfum þínum.

Því er ekki að neita mikilvægi hefðbundinna þróunartækja en í mörgum tilfellum er notkun lágkóðalausna besta leiðin til að auka skilvirkni þeirra verkefna sem verið er að leysa.

Heimild: www.habr.com