Dragi čitaoci, dobar dan!
Zadatak izgradnje IT platformi za prikupljanje i analizu podataka prije ili kasnije se javlja za svaku kompaniju čije se poslovanje zasniva na intelektualno opterećenom modelu pružanja usluga ili kreiranju tehnički složenih proizvoda. Izgradnja analitičkih platformi je složen i dugotrajan zadatak. Međutim, svaki zadatak se može pojednostaviti. U ovom članku želim podijeliti svoje iskustvo u korištenju alata s niskim kodom za pomoć u kreiranju analitičkih rješenja. Ovo iskustvo stečeno je tokom realizacije niza projekata u pravcu Big Data Solutions kompanije Neoflex. Od 2005. godine smjer Big Data Solutions Neoflexa bavi se pitanjima izgradnje skladišta podataka i jezera, rješavanjem problema optimizacije brzine obrade informacija i radom na metodologiji upravljanja kvalitetom podataka.
Niko neće moći izbjeći svjesno gomilanje slabo i/ili jako strukturiranih podataka. Možda čak i ako govorimo o malim preduzećima. Uostalom, prilikom skaliranja poslovanja, perspektivni poduzetnik će se suočiti s pitanjima razvoja programa lojalnosti, htjet će analizirati učinkovitost prodajnih mjesta, razmišljat će o ciljanom oglašavanju i bit će zbunjen potražnjom za pratećim proizvodima. . U prvoj aproksimaciji, problem se može riješiti „na kolenu“. Ali kako posao raste, dolazak na analitičku platformu je i dalje neizbježan.
Međutim, u kom slučaju se zadaci analize podataka mogu razviti u probleme klase „Raketna nauka“? Možda u trenutku kada govorimo o zaista velikim podacima.
Da biste olakšali Rocket Science, možete jesti slona dio po dio.
Što su vaše aplikacije/usluge/mikroservise diskretnije i autonomnije, to će vama, vašim kolegama i cijelom poslovanju biti lakše da svarite slona.
Gotovo svi naši klijenti došli su do ovog postulata, nakon što su ponovo izgradili pejzaž na osnovu inženjerskih praksi DevOps timova.
Ali čak i sa “odvojenom, slonovskom” ishranom, imamo dobre šanse za “prezasićenost” IT pejzaža. U ovom trenutku vrijedi stati, izdahnuti i pogledati u stranu niskokodovana inženjerska platforma.
Mnogi programeri su uplašeni mogućnošću ćorsokaka u svojoj karijeri kada se odmaknu od direktnog pisanja koda ka „povlačenju“ strelica u UI interfejsima sistema sa niskim kodom. Ali pojava alatnih mašina nije dovela do nestanka inženjera, već je njihov rad dovela na novi nivo!
Hajde da shvatimo zašto.
Analiza podataka iz oblasti logistike, telekom industrije, medijskih istraživanja, finansijskog sektora je uvek povezana sa sledećim pitanjima:
- Brzina automatske analize;
- Sposobnost izvođenja eksperimenata bez utjecaja na glavni tok proizvodnje podataka;
- Pouzdanost pripremljenih podataka;
- Praćenje promjena i upravljanje verzijama;
- Porijeklo podataka, porijeklo podataka, CDC;
- Brza isporuka novih funkcija u proizvodno okruženje;
- I zloglasno: troškovi razvoja i podrške.
Odnosno, inženjeri imaju ogroman broj zadataka visokog nivoa, koji se mogu završiti sa dovoljnom efikasnošću samo čišćenjem njihove svijesti o razvojnim zadacima niskog nivoa.
Preduvjeti za prelazak programera na novi nivo bili su evolucija i digitalizacija poslovanja. Vrijednost programera se također mijenja: postoji značajan nedostatak programera koji mogu uroniti u koncepte poslovanja koje se automatizira.
Hajde da povučemo analogiju sa programskim jezicima niskog i visokog nivoa. Prelazak sa jezika nižeg nivoa na jezike visokog nivoa je prelazak sa pisanja „direktnih direktiva na jeziku hardvera” ka „direktivama na jeziku ljudi”. To jest, dodavanje nekog sloja apstrakcije. U ovom slučaju, prijelaz na platforme s niskim kodom sa programskih jezika visokog nivoa je prijelaz sa “smjernica na jeziku ljudi” ka “smjernicama na jeziku poslovanja”. Ako postoje programeri koji su tužni zbog ove činjenice, onda su bili tužni, možda, od trenutka kada je rođen Java Script, koji koristi funkcije sortiranja nizova. I ove funkcije, naravno, imaju softversku implementaciju ispod haube pomoću drugih sredstava istog programiranja visokog nivoa.
Stoga je niski kod samo pojava drugog nivoa apstrakcije.
Primijenjeno iskustvo korištenja niskog koda
Tema niskog koda je prilično široka, ali sada bih želio govoriti o praktičnoj primjeni “low-code koncepata” na primjeru jednog od naših projekata.
Odeljenje Big Data Solutions kompanije Neoflex više je specijalizovano za finansijski sektor poslovanja, izgradnju skladišta podataka i jezera i automatizaciju različitih izveštavanja. U ovoj niši, upotreba niskog koda je odavno postala standard. Od ostalih low-code alata možemo spomenuti alate za organizaciju ETL procesa: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Ili Oracle Apex, koji djeluje kao okruženje za brzi razvoj interfejsa za pristup i uređivanje podataka. Međutim, upotreba razvojnih alata s niskim kodom ne uključuje uvijek izgradnju visoko ciljanih aplikacija na komercijalnom tehnološkom stogu sa jasnom ovisnošću o dobavljaču.
Koristeći platforme s niskim kodom, također možete organizirati orkestraciju tokova podataka, kreirati platforme za nauku o podacima ili, na primjer, module za provjeru kvaliteta podataka.
Jedan od primijenjenih primjera iskustva u korištenju alata za razvoj niskog koda je suradnja između Neoflexa i Mediascopea, jednog od lidera na ruskom tržištu medijskih istraživanja. Jedan od poslovnih ciljeva ove kompanije je proizvodnja podataka na osnovu kojih oglašivači, internet platforme, TV kanali, radio stanice, reklamne agencije i brendovi donose odluke o kupovini oglašavanja i planiraju svoje marketinške komunikacije.
Istraživanje medija je tehnološki opterećeno područje poslovanja. Prepoznavanje video sekvenci, prikupljanje podataka sa uređaja koji analiziraju gledanost, mjerenje aktivnosti na web resursima - sve to implicira da kompanija ima veliki IT kadar i ogromno iskustvo u izgradnji analitičkih rješenja. Ali eksponencijalni rast količine informacija, broja i raznolikosti njihovih izvora tjera IT industriju podataka da konstantno napreduje. Najjednostavnije rješenje za skaliranje već funkcionalne analitičke platforme Mediascope moglo bi biti povećanje IT osoblja. Ali mnogo efikasnije rješenje je ubrzati proces razvoja. Jedan od koraka koji vode u ovom smjeru može biti korištenje platformi niskog koda.
U vrijeme kada je projekat započeo, kompanija je već imala funkcionalno rješenje proizvoda. Međutim, implementacija rješenja u MSSQL nije mogla u potpunosti ispuniti očekivanja za funkcionalnost skaliranja uz održavanje prihvatljivih troškova razvoja.
Zadatak koji je pred nama bio je zaista ambiciozan - Neoflex i Mediascope su morali da kreiraju industrijsko rešenje za manje od godinu dana, pod uslovom da se MVP objavi u prvom kvartalu od datuma početka.
Tehnološki stog Hadoop izabran je kao temelj za izgradnju nove platforme podataka zasnovane na računarstvu sa niskim kodom. HDFS je postao standard za pohranu podataka pomoću parket fajlova. Za pristup podacima koji se nalaze na platformi korišćen je Hive, u kojem su svi dostupni izlozi predstavljeni u obliku eksternih tabela. Učitavanje podataka u skladište je implementirano pomoću Kafke i Apache NiFi.
Alat Lowe-code u ovom konceptu korišten je za optimizaciju najintenzivnijeg zadatka u izgradnji analitičke platforme - zadatka izračunavanja podataka.
Alat za datagram niskog koda odabran je kao glavni mehanizam za mapiranje podataka. Neoflex Datagram je alat za razvoj transformacija i tokova podataka.
Koristeći ovaj alat, možete bez ručnog pisanja Scala koda. Scala kod se generira automatski korištenjem pristupa arhitekture vođene modelom.
Očigledna prednost ovog pristupa je ubrzanje procesa razvoja. Međutim, osim brzine, postoje i sljedeće prednosti:
- Pregled sadržaja i strukture izvora/prijemnika;
- Praćenje porijekla objekata protoka podataka do pojedinačnih polja (loza);
- Djelomično izvođenje transformacija sa pregledom međurezultata;
- Pregledavanje izvornog koda i prilagođavanje prije izvršenja;
- Automatska validacija transformacija;
- Automatsko preuzimanje podataka 1 u 1.
Barijera za ulazak u rješenja s niskim kodom za generiranje transformacija je prilično niska: programer mora poznavati SQL i imati iskustvo u radu s ETL alatima. Vrijedi napomenuti da generatori transformacije vođeni kodom nisu ETL alati u širem smislu riječi. Alati sa niskim kodom možda nemaju svoje okruženje za izvršavanje koda. To jest, generirani kod će se izvršiti u okruženju koje je postojalo na klasteru čak i prije instaliranja rješenja s niskim kodom. A ovo je možda još jedan plus za niskokodnu karmu. Budući da paralelno sa timom sa niskim kodom može raditi i “klasični” tim koji implementira funkcionalnost, na primjer, u čistom Scala kodu. Dovođenje poboljšanja oba tima u proizvodnju će biti jednostavno i neprimetno.
Možda je vrijedno napomenuti da pored low-code, postoje i rješenja bez koda. A u svojoj suštini, to su različite stvari. Low-code dozvoljava programeru da se više miješa u generirani kod. U slučaju Datagrama, moguće je pregledati i urediti generirani Scala kod; no-code možda neće pružiti takvu mogućnost. Ova razlika je vrlo značajna ne samo u pogledu fleksibilnosti rješenja, već iu smislu udobnosti i motivacije u radu data inženjera.
Arhitektura rješenja
Pokušajmo točno shvatiti kako alat s niskim kodom pomaže u rješavanju problema optimizacije brzine razvoja funkcionalnosti izračunavanja podataka. Prvo, pogledajmo funkcionalnu arhitekturu sistema. Primjer u ovom slučaju je model proizvodnje podataka za istraživanje medija.
Izvori podataka u našem slučaju su vrlo heterogeni i raznoliki:
- Brojila ljudi (TV mjerači) su softverski i hardverski uređaji koji očitavaju ponašanje korisnika od ispitanika na televizijskom panelu – ko je, kada i koji TV kanal gledao u domaćinstvu koje učestvuje u istraživanju. Isporučene informacije su tok intervala gledanja emitiranja povezanih s medijskim paketom i medijskim proizvodom. Podaci u fazi učitavanja u Data Lake mogu se obogatiti demografskim atributima, geostratifikacijom, vremenskom zonom i drugim informacijama potrebnim za analizu televizijskog gledanja određenog medijskog proizvoda. Poduzeta mjerenja mogu se koristiti za analizu ili planiranje reklamnih kampanja, procjenu aktivnosti i preferencija publike i sastavljanje mreže emitovanja;
- Podaci mogu doći iz sistema za praćenje za striming televizijskih emisija i mjerenja gledanosti sadržaja video resursa na Internetu;
- Alati za mjerenje u web okruženju, uključujući mjerače usmjerene na lokaciju i na korisnika. Dobavljač podataka za Data Lake može biti dodatak pretraživaču istraživačke trake i mobilna aplikacija sa ugrađenim VPN-om.
- Podaci mogu doći i sa sajtova koji objedinjuju rezultate popunjavanja onlajn upitnika i rezultate telefonskih intervjua u anketama kompanija;
- Dodatno obogaćivanje jezera podataka može se desiti preuzimanjem informacija iz dnevnika partnerskih kompanija.
Implementacija as je učitavanja iz izvornih sistema u primarno postavljanje sirovih podataka može se organizirati na različite načine. Ako se u ove svrhe koristi low-code, moguće je automatsko generiranje skripti za učitavanje na osnovu metapodataka. U ovom slučaju, nema potrebe da se spuštate na nivo razvoja izvora do ciljanih mapiranja. Da bismo implementirali automatsko učitavanje, moramo uspostaviti vezu sa izvorom, a zatim u interfejsu za učitavanje definirati listu entiteta koji će se učitati. Struktura direktorija u HDFS-u će biti kreirana automatski i odgovarat će strukturi pohrane podataka na izvornom sistemu.
Međutim, u kontekstu ovog projekta odlučili smo da ne koristimo ovu mogućnost platforme niskog koda zbog činjenice da je kompanija Mediascope već samostalno započela rad na proizvodnji slične usluge koristeći kombinaciju Nifi + Kafka.
Vrijedi odmah naznačiti da ovi alati nisu zamjenjivi, već komplementarni. Nifi i Kafka mogu raditi i u direktnoj (Nifi -> Kafka) iu obrnutoj (Kafka -> Nifi) vezi. Za platformu za istraživanje medija korištena je prva verzija paketa.
U našem slučaju, NayFi je trebao obraditi različite vrste podataka iz izvornih sistema i poslati ih Kafka brokeru. U ovom slučaju, poruke su poslane na određenu Kafka temu pomoću PublishKafka Nifi procesora. Orkestracija i održavanje ovih cjevovoda se odvija u vizualnom interfejsu. Nifi alat i upotreba kombinacije Nifi + Kafka mogu se nazvati i low-code pristupom razvoju, koji ima nisku barijeru za ulazak u Big Data tehnologije i ubrzava proces razvoja aplikacija.
Sljedeća faza u implementaciji projekta bila je dovođenje detaljnih podataka u jedan format semantičkog sloja. Ako entitet ima povijesne atribute, izračunavanje se izvodi u kontekstu dotične particije. Ako entitet nije historijski, onda je opciono moguće ili ponovno izračunati cijeli sadržaj objekta, ili potpuno odbiti ponovno izračunavanje ovog objekta (zbog nedostatka promjena). U ovoj fazi se generišu ključevi za sve entitete. Ključevi se pohranjuju u Hbase direktorije koji odgovaraju glavnim objektima, koji sadrže korespondenciju između ključeva u analitičkoj platformi i ključeva iz izvornih sistema. Konsolidaciju atomskih entiteta prati obogaćivanje rezultatima preliminarnog proračuna analitičkih podataka. Okvir za proračun podataka bio je Spark. Opisana funkcionalnost za dovođenje podataka u jednu semantiku također je implementirana na osnovu mapiranja iz alata Datagram niskog koda.
Ciljna arhitektura je zahtijevala SQL pristup podacima za poslovne korisnike. Za ovu opciju je korištena košnica. Objekti se automatski registruju u košnici kada omogućite opciju “Registriraj tablicu košnice” u alatu za niske kodove.
Kontrola protoka proračuna
Datagram ima interfejs za kreiranje dizajna toka posla. Mapiranja se mogu pokrenuti pomoću Oozie planera. U interfejsu programera toka moguće je kreirati šeme za paralelne, sekvencijalne ili transformacije podataka zavisne od izvršenja. Postoji podrška za shell skripte i java programe. Takođe je moguće koristiti Apache Livy server. Apache Livy se koristi za pokretanje aplikacija direktno iz razvojnog okruženja.
Ako kompanija već ima svoj vlastiti orkestrator procesa, moguće je koristiti REST API za ugrađivanje mapiranja u postojeći tok. Na primjer, imali smo prilično uspješno iskustvo ugrađivanja mapiranja u Scali u orkestratore napisane u PLSQL-u i Kotlinu. REST API alata sa niskim kodom uključuje operacije kao što su generiranje izvršne godine na osnovu dizajna mapiranja, pozivanje mapiranja, pozivanje niza mapiranja i, naravno, prosljeđivanje parametara URL-u za pokretanje mapiranja.
Uz Oozie, moguće je organizirati tok proračuna koristeći Airflow. Možda se neću dugo zadržavati na poređenju između Ooziea i Airflowa, već ću jednostavno reći da je u kontekstu rada na projektu istraživanja medija izbor pao u korist Airflowa. Glavni argumenti ovoga puta bili su aktivnija zajednica koja razvija proizvod i razvijeniji interfejs + API.
Protok zraka je također dobar jer koristi omiljeni Python za opisivanje procesa izračunavanja. I općenito, ne postoji toliko mnogo platformi za upravljanje tokovima rada otvorenog koda. Pokretanje i praćenje izvršavanja procesa (uključujući Ganttov grafikon) samo dodaje bodove karmi Airflow-a.
Format konfiguracijske datoteke za pokretanje mapiranja rješenja niskog koda postao je spark-submit. To se dogodilo iz dva razloga. Prvo, spark-submit vam omogućava da direktno pokrenete jar datoteku sa konzole. Drugo, može sadržavati sve potrebne informacije za konfiguriranje toka posla (što olakšava pisanje skripti koje generiraju Dag).
Najčešći element toka rada Airflow u našem slučaju bio je SparkSubmitOperator.
SparkSubmitOperator vam omogućava da pokrenete jar - upakovane Datagram mapiranja sa unapred generisanim ulaznim parametrima za njih.
Vrijedi napomenuti da svaki zadatak Airflow radi u zasebnoj niti i ne zna ništa o drugim zadacima. Stoga se interakcija između zadataka provodi pomoću kontrolnih operatora, kao što su DummyOperator ili BranchPythonOperator.
Uzeto zajedno, korištenje rješenja niskog koda Datagrama u sprezi sa univerzalizacijom konfiguracijskih datoteka (formirajući Dag) dovelo je do značajnog ubrzanja i pojednostavljenja procesa razvoja tokova učitavanja podataka.
Proračuni za izlog
Možda je intelektualno najopterećenija faza u proizvodnji analitičkih podataka korak izgradnje vitrina. U kontekstu jednog od tokova izračunavanja podataka istraživačke kompanije, u ovoj fazi, podaci se svode na referentno emitovanje, uzimajući u obzir korekcije za vremenske zone i povezuju se sa mrežom emitovanja. Također je moguće prilagoditi za lokalnu mrežu emitiranja (lokalne vijesti i oglašavanje). Između ostalog, ovaj korak razbija intervale kontinuiranog gledanja medijskih proizvoda na osnovu analize intervala gledanja. Vrijednosti gledanja se odmah „ponderišu“ na osnovu informacija o njihovoj važnosti (izračunavanje faktora korekcije).
Poseban korak u pripremi vitrina je validacija podataka. Algoritam validacije uključuje upotrebu brojnih matematičkih modela. Međutim, korištenje platforme s niskim kodom omogućava vam da razbijete složeni algoritam u više zasebnih vizualno čitljivih mapiranja. Svako od preslikavanja obavlja uski zadatak. Kao rezultat, moguće je posredno otklanjanje grešaka, evidentiranje i vizualizacija faza pripreme podataka.
Odlučeno je da se algoritam validacije diskretizira u sljedeće podfaze:
- Izgradnja regresije zavisnosti gledanja TV mreže u regionu sa gledanošću svih mreža u regionu za 60 dana.
- Izračunavanje studentiziranih reziduala (odstupanja stvarnih vrijednosti od onih predviđenih regresijskim modelom) za sve regresijske tačke i za izračunati dan.
- Odabir anomalnih parova regija-mreža, gdje studentski saldo dana obračuna premašuje normu (navedenu postavkama operacije).
- Preračunavanje korigovanog studentizovanog ostatka za anomalne parove region-TV mreža za svakog ispitanika koji je gledao mrežu u regionu, utvrđivanje doprinosa ovog ispitanika (iznos promene studentizovanog ostatka) kada se iz uzorka isključi gledanost ovog ispitanika .
- Tražite kandidate čije isključenje vraća studentski saldo dana isplate u normalu.
Gornji primjer potvrđuje hipotezu da inženjer podataka već ima previše na umu... I, ako je to zaista „inženjer“, a ne „koder“, onda strah od profesionalne degradacije kada koristi alate sa niskim kodom mora konačno da se povuče.
Šta još može učiniti niski kod?
Opseg primjene alata s niskim kodom za batch i stream obradu podataka bez potrebe za ručnim pisanjem koda u Scali se tu ne završava.
Upotreba niskog koda u razvoju datalake-a je već postala standard za nas. Vjerovatno možemo reći da rješenja bazirana na Hadoop steku slijede razvojni put klasičnih DWH-ova baziranih na RDBMS-u. Alati sa niskim kodom na Hadoop steku mogu riješiti i zadatke obrade podataka i zadatak izgradnje konačnih BI sučelja. Štaviše, treba napomenuti da BI može značiti ne samo predstavljanje podataka, već i njihovo uređivanje od strane poslovnih korisnika. Ovu funkcionalnost često koristimo kada gradimo analitičke platforme za finansijski sektor.
Između ostalog, korištenjem niskog koda, a posebno Datagrama, moguće je riješiti problem praćenja porijekla objekata toka podataka sa atomicnošću sve do pojedinačnih polja (lineage). Da bi to uradio, alat sa niskim kodom implementira interfejs sa Apache Atlasom i Cloudera Navigatorom. U suštini, programer treba da registruje skup objekata u Atlas rečnicima i referencira registrovane objekte kada gradi mapiranje. Mehanizam za praćenje porijekla podataka ili analizu ovisnosti objekata štedi mnogo vremena kada je potrebno poboljšati algoritme proračuna. Na primjer, kada sastavljate finansijske izvještaje, ova funkcija vam omogućava da udobnije preživite period zakonskih promjena. Uostalom, što bolje razumijemo ovisnost između oblika u kontekstu objekata detaljnog sloja, to ćemo manje nailaziti na „iznenadne“ nedostatke i smanjiti broj dorada.
Kvalitet podataka i niski kod
Drugi zadatak koji je implementirao alat za niski kod na projektu Mediascope bio je zadatak klase kvaliteta podataka. Posebnost implementacije cevovoda za verifikaciju podataka za projekat istraživačke kompanije bio je nedostatak uticaja na performanse i brzinu glavnog toka proračuna podataka. Da bi se mogli orkestrirati nezavisni tokovi verifikacije podataka, korišten je već poznati Apache Airflow. Kako je svaki korak proizvodnje podataka bio spreman, paralelno je pokrenut poseban dio DQ pipelinea.
Smatra se dobrom praksom praćenja kvaliteta podataka od trenutka njihovog nastanka u analitičkoj platformi. Imajući informacije o metapodacima, možemo provjeriti usklađenost sa osnovnim uslovima od trenutka kada informacija uđe u primarni sloj - ne null, ograničenja, strani ključevi. Ova funkcionalnost je implementirana na osnovu automatski generisanih mapiranja porodice kvaliteta podataka u Datagramu. Generisanje koda u ovom slučaju se takođe zasniva na metapodacima modela. Na projektu Mediascope, interfejs je izveden sa metapodacima proizvoda Enterprise Architect.
Uparivanje alata za niske kodove sa Enterprise Architect-om, automatski su generisane sljedeće provjere:
- Provjera prisutnosti "null" vrijednosti u poljima s modifikatorom "not null";
- Provjera prisustva duplikata primarnog ključa;
- Provjera stranog ključa entiteta;
- Provjera jedinstvenosti niza na osnovu skupa polja.
Za složenije provjere dostupnosti i pouzdanosti podataka, kreirano je mapiranje pomoću Scala Expressiona, koji kao ulaz uzima vanjski Spark SQL kontrolni kod koji su pripremili analitičari u Zeppelin-u.
Naravno, automatsko generiranje čekova mora se postići postepeno. U okviru opisanog projekta, tome su prethodili sljedeći koraci:
- DQ implementiran u Zeppelin notebook računare;
- DQ ugrađen u mapiranje;
- DQ u obliku odvojenih masivnih mapiranja koje sadrže cijeli skup provjera za poseban entitet;
- Univerzalna parametrizovana DQ mapiranja koja prihvataju informacije o metapodacima i poslovnim provjerama kao ulaz.
Možda je glavna prednost kreiranja parametrizirane usluge provjere smanjenje vremena potrebnog za isporuku funkcionalnosti proizvodnom okruženju. Nove provjere kvaliteta mogu zaobići klasični obrazac posrednog dostavljanja koda kroz razvojna i testna okruženja:
- Sve provjere metapodataka se generišu automatski kada se model modificira u EA;
- Provjere dostupnosti podataka (utvrđivanje prisutnosti bilo kojeg podatka u određenom trenutku) mogu se generirati na osnovu direktorija koji pohranjuje očekivano vrijeme pojavljivanja sljedećeg podatka u kontekstu objekata;
- Provjere valjanosti poslovnih podataka kreiraju analitičari u Zeppelin bilježnicama. Odatle se šalju direktno u tabele podešavanja DQ modula u proizvodnom okruženju.
Nema rizika direktnog slanja skripti u produkciju. Čak i sa sintaksičkom greškom, maksimum koji nam prijeti je neuspjeh da izvršimo jednu provjeru, jer su tok izračunavanja podataka i tok pokretanja provjere kvaliteta odvojeni jedan od drugog.
U suštini, DQ servis stalno radi u proizvodnom okruženju i spreman je da počne sa radom čim se pojavi sledeći podatak.
Umjesto zaključka
Prednost korištenja niskog koda je očigledna. Programeri ne moraju razvijati aplikaciju od nule. A programer oslobođen dodatnih zadataka daje rezultate brže. Brzina, zauzvrat, oslobađa dodatno vrijeme za rješavanje problema optimizacije. Stoga u ovom slučaju možete računati na bolje i brže rješenje.
Naravno, niski kod nije lijek, a magija se neće dogoditi sama od sebe:
- Industrija niskog koda prolazi kroz fazu “jačanja” i još ne postoje jedinstveni industrijski standardi;
- Mnoga rješenja s niskim kodom nisu besplatna, a njihova kupovina bi trebala biti svjestan korak, koji bi trebao biti učinjen s punim povjerenjem u finansijske koristi od njihovog korištenja;
- Mnoga rešenja niskog koda ne rade uvek dobro sa GIT/SVN. Ili su nezgodni za korištenje ako je generirani kod skriven;
- Prilikom proširenja arhitekture, možda će biti potrebno precizirati rješenje s niskim kodom - što, zauzvrat, izaziva efekat „vezanosti i zavisnosti“ od dobavljača rješenja niskog koda.
- Adekvatan nivo sigurnosti je moguć, ali je veoma radno intenzivan i teško ga je implementirati u sistemske mašine sa niskim kodom. Platforme niskog koda treba birati ne samo na principu traženja koristi od njihove upotrebe. Prilikom odabira vrijedi postaviti pitanja o dostupnosti funkcionalnosti za kontrolu pristupa i delegiranje/eskalaciju identifikacionih podataka na nivo cjelokupnog IT pejzaža organizacije.
Međutim, ako su vam svi nedostaci odabranog sistema poznati, a koristi od njegove upotrebe ipak su u dominantnoj većini, onda bez straha prijeđite na mali kod. Štaviše, prijelaz na njega je neizbježan – kao što je neizbježna i svaka evolucija.
Ako jedan programer na platformi niskog koda radi svoj posao brže od dva programera bez niskog koda, onda to kompaniji daje prednost u svim aspektima. Prag za ulazak u low-code rješenja je niži nego u “tradicionalne” tehnologije, a to ima pozitivan učinak na problem nedostatka osoblja. Korištenjem low-code alata moguće je ubrzati interakciju između funkcionalnih timova i donijeti brže odluke o ispravnosti odabranog puta istraživanja nauke o podacima. Platforme niskog nivoa mogu pokrenuti digitalnu transformaciju organizacije jer proizvedena rješenja mogu razumjeti netehnički stručnjaci (posebno poslovni korisnici).
Ako imate kratke rokove, opterećenu poslovnu logiku, nedostatak tehnološke ekspertize i trebate ubrzati svoje vrijeme za izlazak na tržište, onda je low-code jedan od načina da zadovoljite svoje potrebe.
Ne može se poreći važnost tradicionalnih razvojnih alata, ali u mnogim slučajevima, korištenje low-code rješenja je najbolji način da se poveća efikasnost zadataka koji se rješavaju.
izvor: www.habr.com