Aplikácia low-code v analytických platformách

Vážení čitatelia, dobrý deň!

Úloha vybudovať IT platformy na zber a analýzu dát skôr či neskôr vyvstane pre každú spoločnosť, ktorej podnikanie je založené na intelektuálne zaťaženom modeli poskytovania služieb alebo vytváraní technicky zložitých produktov. Budovanie analytických platforiem je zložitá a časovo náročná úloha. Každá úloha sa však dá zjednodušiť. V tomto článku sa chcem podeliť o svoje skúsenosti s používaním nástrojov s nízkym kódom na pomoc pri vytváraní analytických riešení. Tieto skúsenosti nadobudol pri realizácii množstva projektov v smere Big Data Solutions spoločnosti Neoflex. Smer Big Data Solutions spoločnosti Neoflex sa od roku 2005 zaoberá problematikou budovania dátových skladov a jazier, riešením problémov optimalizácie rýchlosti spracovania informácií a prácou na metodike riadenia kvality dát.

Nikto sa nebude môcť vyhnúť vedomému hromadeniu slabo a/alebo silne štruktúrovaných údajov. Možno aj keď hovoríme o malých podnikoch. Koniec koncov, pri rozširovaní podnikania bude nádejný podnikateľ čeliť otázkam vývoja vernostného programu, bude chcieť analyzovať efektivitu predajných miest, bude premýšľať o cielenej reklame a bude zmätený dopytom po sprievodných produktoch. . Pri prvom priblížení sa dá problém vyriešiť „na kolene“. Ale ako podnikanie rastie, príchod na analytickú platformu je stále nevyhnutný.

V akom prípade sa však úlohy analýzy údajov môžu rozvinúť do problémov triedy „Rocket Science“? Možno v momente, keď sa bavíme o skutočne veľkých dátach.
Aby ste si Rocket Science uľahčili, môžete slona zjesť kúsok po kúsku.

Čím sú vaše aplikácie/služby/mikroslužby diskrétnejšie a autonómnejšie, tým ľahšie slona strávite vy, vaši kolegovia a celý podnik.

Takmer všetci naši klienti prišli k tomuto postulátu, keď prestavali krajinu na základe inžinierskych postupov tímov DevOps.

Ale aj pri „oddelenej, slonej“ strave máme veľkú šancu na „presýtenie“ IT prostredia. V tejto chvíli stojí za to zastaviť sa, vydýchnuť a pozrieť sa na stranu nízkokódová inžinierska platforma.

Mnoho vývojárov sa bojí vyhliadky na slepú uličku vo svojej kariére, keď sa odklonia od priameho písania kódu smerom k „ťahaniu“ šípok v rozhraniach používateľského rozhrania systémov s nízkym kódom. Ale príchod obrábacích strojov neviedol k zmiznutiu inžinierov, ale priniesol ich prácu na novú úroveň!

Poďme zistiť prečo.

Analýza dát v oblasti logistiky, telekomunikačného priemyslu, mediálneho výskumu, finančného sektora je vždy spojená s nasledujúcimi otázkami:

• Rýchlosť automatizovanej analýzy;
• Schopnosť vykonávať experimenty bez ovplyvnenia hlavného toku produkcie údajov;
• Spoľahlivosť pripravených údajov;
• Sledovanie zmien a vytváranie verzií;
• Doklad údajov, línia údajov, CDC;
• Rýchle dodanie nových funkcií do produkčného prostredia;
• A notoricky známe: náklady na vývoj a podporu.

To znamená, že inžinieri majú obrovské množstvo úloh na vysokej úrovni, ktoré môžu byť s dostatočnou efektivitou dokončené iba očistením ich vedomia od vývojových úloh nízkej úrovne.

Predpokladom pre posun vývojárov na novú úroveň bola evolúcia a digitalizácia biznisu. Mení sa aj hodnota vývojára: je výrazný nedostatok vývojárov, ktorí by sa mohli ponoriť do konceptov automatizovaného biznisu.

Nakreslite analógiu s nízkoúrovňovými a vysokoúrovňovými programovacími jazykmi. Prechod od jazykov nízkej úrovne k jazykom vysokej úrovne je prechodom od písania „priamych smerníc v jazyku hardvéru“ k „smerniciam v jazyku ľudí“. To znamená pridanie určitej vrstvy abstrakcie. V tomto prípade je prechod na platformy s nízkym kódom z programovacích jazykov na vysokej úrovni prechodom od „smerníc v jazyku ľudí“ k „smerniciam v jazyku podnikania“. Ak existujú vývojári, ktorých táto skutočnosť mrzí, potom sú zarmútení možno od chvíle, keď sa zrodil Java Script, ktorý používa funkcie triedenia polí. A tieto funkcie majú samozrejme pod kapotou softvérovú implementáciu inými prostriedkami rovnakého programovania na vysokej úrovni.

Preto je low-code len zdanie inej úrovne abstrakcie.

Aplikované skúsenosti pomocou nízkeho kódu

Téma low-code je pomerne široká, ale teraz by som rád hovoril o praktickej aplikácii „low-code konceptov“ na príklade jedného z našich projektov.

Divízia Big Data Solutions spoločnosti Neoflex sa špecializuje skôr na finančný sektor podnikania, budovanie dátových skladov a jazier a automatizáciu rôznych reportingov. V tomto výklenku sa používanie nízkeho kódu už dlho stalo štandardom. Z ďalších low-code nástrojov môžeme spomenúť nástroje na organizáciu ETL procesov: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Alebo Oracle Apex, ktorý funguje ako prostredie pre rýchly vývoj rozhraní pre prístup a úpravu dát. Používanie nástrojov na vývoj s nízkym kódom však nie vždy zahŕňa vytváranie vysoko cielených aplikácií na komerčnom technologickom zásobníku s jasnou závislosťou od dodávateľa.

Pomocou platforiem s nízkym kódom môžete organizovať aj orchestráciu dátových tokov, vytvárať platformy dátovej vedy alebo napríklad moduly na kontrolu kvality dát.

Jedným z aplikovaných príkladov skúseností s používaním nízkokódových vývojových nástrojov je spolupráca medzi Neoflex a Mediascope, jedným z lídrov na ruskom trhu mediálneho výskumu. Jedným z obchodných cieľov tejto spoločnosti je produkcia dát, na základe ktorých sa inzerenti, internetové platformy, TV kanály, rádiá, reklamné agentúry a značky rozhodujú o nákupe reklamy a plánujú svoju marketingovú komunikáciu.

Mediálny výskum je technologicky zaťažená oblasť podnikania. Rozoznávanie videosekvencií, zbieranie údajov zo zariadení, ktoré analyzujú sledovanie, meranie aktivity na webových zdrojoch – to všetko naznačuje, že spoločnosť má veľký IT personál a obrovské skúsenosti s budovaním analytických riešení. Ale exponenciálny rast množstva informácií, počtu a rôznorodosti ich zdrojov núti IT dátový priemysel neustále napredovať. Najjednoduchším riešením škálovania už fungujúcej analytickej platformy Mediascope by mohlo byť zvýšenie počtu zamestnancov IT. Oveľa efektívnejším riešením je však urýchliť proces vývoja. Jedným z krokov vedúcich týmto smerom môže byť použitie platforiem s nízkym kódom.

V čase spustenia projektu mala spoločnosť už fungujúce produktové riešenie. Implementácia riešenia v MSSQL však nemohla plne naplniť očakávania týkajúce sa škálovacej funkcionality pri zachovaní prijateľných nákladov na vývoj.

Úloha, ktorá pred nami stála, bola skutočne ambiciózna – Neoflex a Mediascope museli vytvoriť priemyselné riešenie za menej ako rok, s výhradou vydania MVP v prvom štvrťroku od dátumu začiatku.

Technologický zásobník Hadoop bol vybraný ako základ pre vybudovanie novej dátovej platformy založenej na výpočte s nízkym kódom. HDFS sa stal štandardom pre ukladanie dát pomocou parketových súborov. Na prístup k údajom umiestneným v platforme bol použitý Hive, v ktorom sú všetky dostupné výklady prezentované vo forme externých tabuliek. Načítanie dát do úložiska bolo realizované pomocou Kafka a Apache NiFi.

Nástroj Lowe-code v tomto koncepte bol použitý na optimalizáciu najnáročnejšej úlohy pri budovaní analytickej platformy – úlohy výpočtu dát.

Ako hlavný mechanizmus na mapovanie údajov bol zvolený nízkokódový nástroj Datagram. Datagram Neoflex je nástroj na vývoj transformácií a dátových tokov.
Pomocou tohto nástroja sa zaobídete bez manuálneho písania kódu Scala. Scala kód sa generuje automaticky pomocou modelu Driven Architecture.

Zjavnou výhodou tohto prístupu je urýchlenie procesu vývoja. Okrem rýchlosti však existujú aj tieto výhody:

• Prezeranie obsahu a štruktúry zdrojov/prijímačov;
• Sledovanie pôvodu objektov toku údajov k jednotlivým poliam (lineár);
• Čiastočné vykonávanie transformácií s prezeraním medzivýsledkov;
• Kontrola zdrojového kódu a jeho úprava pred spustením;
• Automatická validácia transformácií;
• Automatické sťahovanie dát 1 v 1.

Prekážka vstupu do riešení s nízkym kódom na generovanie transformácií je pomerne nízka: vývojár potrebuje poznať SQL a mať skúsenosti s prácou s nástrojmi ETL. Stojí za zmienku, že kódom riadené transformačné generátory nie sú ETL nástrojmi v širšom zmysle slova. Nástroje s nízkym kódom nemusia mať svoje vlastné prostredie na vykonávanie kódu. To znamená, že vygenerovaný kód sa spustí v prostredí, ktoré existovalo v klastri ešte pred inštaláciou riešenia s nízkym kódom. A to je možno ďalšie plus pre karmu s nízkym kódom. Keďže paralelne s nízkokódovým tímom môže pracovať „klasický“ tím, ktorý implementuje funkcionalitu napríklad v čistom kóde Scala. Zavedenie vylepšení od oboch tímov do produkcie bude jednoduché a bezproblémové.

Možno stojí za zmienku, že okrem nízkeho kódu existujú aj riešenia bez kódu. A v ich jadre sú to rôzne veci. Nízky kód umožňuje vývojárovi viac zasahovať do generovaného kódu. V prípade Datagramu je možné prezerať a upravovať vygenerovaný Scala kód, no-code nemusí takúto možnosť poskytovať. Tento rozdiel je veľmi výrazný nielen z hľadiska flexibility riešenia, ale aj z hľadiska komfortu a motivácie pri práci dátových inžinierov.

Architektúra riešenia

Pokúsme sa presne zistiť, ako nástroj s nízkym kódom pomáha vyriešiť problém s optimalizáciou rýchlosti vývoja funkcií výpočtu údajov. Najprv sa pozrime na funkčnú architektúru systému. Príkladom je v tomto prípade model produkcie údajov pre mediálny výskum.

Zdroje údajov sú v našom prípade veľmi heterogénne a rôznorodé:

• Peoplemetre (TV metre) sú softvérové ​​a hardvérové ​​zariadenia, ktoré snímajú správanie používateľov od respondentov televíznych panelov – kto, kedy a aký televízny kanál sledoval v domácnosti, ktorá sa štúdie zúčastňuje. Poskytnuté informácie sú prúdom intervalov sledovania vysielania prepojených s mediálnym balíkom a mediálnym produktom. Dáta vo fáze načítania do Data Lake môžu byť obohatené o demografické atribúty, geostratifikáciu, časové pásmo a ďalšie informácie potrebné na analýzu televízneho sledovania konkrétneho mediálneho produktu. Vykonané merania možno použiť na analýzu alebo plánovanie reklamných kampaní, posúdenie aktivity a preferencií publika a zostavenie vysielacej siete;
• Údaje môžu pochádzať z monitorovacích systémov na streamovanie televízneho vysielania a meranie sledovania obsahu video zdrojov na internete;
• Nástroje na meranie vo webovom prostredí vrátane meračov zameraných na lokalitu aj používateľov. Poskytovateľom dát pre Data Lake môže byť doplnok prieskumného prehliadača a mobilná aplikácia so vstavanou VPN.
• Údaje môžu pochádzať aj zo stránok, ktoré konsolidujú výsledky vyplnenia online dotazníkov a výsledky telefonických rozhovorov v podnikových prieskumoch;
• K ďalšiemu obohateniu dátového jazera môže dôjsť stiahnutím informácií z denníkov partnerských spoločností.

Implementácia as is načítania zo zdrojových systémov do primárneho stagingu nespracovaných dát môže byť organizovaná rôznymi spôsobmi. Ak sa na tieto účely použije nízky kód, je možné automatické generovanie načítavacích skriptov na základe metadát. V tomto prípade nie je potrebné klesať na úroveň vývojového mapovania zdroja k cieľu. Na implementáciu automatického načítavania musíme vytvoriť spojenie so zdrojom a potom definovať v načítavacom rozhraní zoznam entít, ktoré sa majú načítať. Adresárová štruktúra v HDFS sa vytvorí automaticky a bude zodpovedať štruktúre dátového úložiska na zdrojovom systéme.

V rámci tohto projektu sme sa však rozhodli túto funkciu low-code platformy nevyužiť z dôvodu, že spoločnosť Mediascope už samostatne začala pracovať na výrobe podobnej služby pomocou kombinácie Nifi + Kafka.

Okamžite stojí za to uviesť, že tieto nástroje nie sú vzájomne zameniteľné, ale skôr sa dopĺňajú. Nifi a Kafka sú schopní pracovať v priamom (Nifi -> Kafka) aj v spätnom (Kafka -> Nifi) spojení. Pre platformu mediálneho výskumu bola použitá prvá verzia balíka.

V našom prípade NayFi potrebovalo spracovať rôzne typy dát zo zdrojových systémov a poslať ich brokerovi Kafka. V tomto prípade boli správy odoslané na konkrétnu tému Kafka pomocou procesorov PublishKafka Nifi. Organizácia a údržba týchto potrubí sa vykonáva vo vizuálnom rozhraní. Nástroj Nifi a využitie kombinácie Nifi + Kafka možno nazvať aj low-code prístupom k vývoju, ktorý má nízku bariéru vstupu do Big Data technológií a urýchľuje proces vývoja aplikácií.

Ďalšou etapou implementácie projektu bolo preniesť podrobné dáta do formátu jednej sémantickej vrstvy. Ak má entita historické atribúty, výpočet sa vykoná v kontexte príslušného oddielu. Ak entita nie je historická, potom je voliteľne možné buď prepočítať celý obsah objektu, alebo úplne odmietnuť prepočet tohto objektu (kvôli chýbajúcim zmenám). V tejto fáze sa vygenerujú kľúče pre všetky entity. Kľúče sú uložené v adresároch Hbase zodpovedajúcich hlavným objektom, ktoré obsahujú korešpondenciu medzi kľúčmi v analytickej platforme a kľúčmi zo zdrojových systémov. Konsolidáciu atómových entít sprevádza obohatenie o výsledky predbežného výpočtu analytických údajov. Rámec pre výpočet údajov bol Spark. Opísaná funkcionalita na privedenie údajov do jedinej sémantiky bola implementovaná aj na základe mapovaní z nízkokódového nástroja Datagram.

Cieľová architektúra vyžadovala prístup SQL k údajom pre podnikových používateľov. Pre túto možnosť bol použitý Hive. Objekty sa v Hive zaregistrujú automaticky, keď povolíte možnosť „Registrovať tabuľku podregistra“ v nástroji s nízkym kódom.

Riadenie toku výpočtu

Datagram má rozhranie na vytváranie návrhov toku pracovných postupov. Mapovania je možné spustiť pomocou plánovača Oozie. V rozhraní pre vývojárov streamov je možné vytvárať schémy pre paralelné, sekvenčné alebo na vykonaní závislé transformácie údajov. Existuje podpora pre shell skripty a programy Java. Je tiež možné použiť server Apache Livy. Apache Livy slúži na spúšťanie aplikácií priamo z vývojového prostredia.

Ak už spoločnosť má vlastný procesný orchestrátor, je možné použiť REST API na vloženie mapovaní do existujúceho toku. Napríklad sme mali celkom úspešnú skúsenosť s vložením mapovaní v Scale do orchestrátorov napísaných v PLSQL a Kotlin. REST API nástroja s nízkym kódom zahŕňa operácie, ako je generovanie spustiteľného roku na základe návrhu mapovania, volanie mapovania, volanie sekvencie mapovaní a samozrejme odovzdávanie parametrov URL na spustenie mapovaní.

Spolu s Oozie je možné organizovať výpočtový tok pomocou Airflow. Možno sa nebudem dlho zdržiavať porovnaním Oozieho a Airflow, ale jednoducho poviem, že v kontexte práce na projekte mediálneho výskumu padla voľba v prospech Airflow. Hlavnými argumentmi boli tentokrát aktívnejšia komunita vyvíjajúca produkt a rozvinutejšie rozhranie + API.

Prúdenie vzduchu je tiež dobré, pretože používa obľúbený Python na popis procesov výpočtu. A vo všeobecnosti nie je toľko open source platforiem na správu pracovného toku. Spustenie a monitorovanie vykonávania procesov (vrátane Ganttovho diagramu) len pridáva body do karmy Airflow.

Formát konfiguračného súboru na spustenie mapovania riešení s nízkym kódom sa stal spark-submit. Stalo sa tak z dvoch dôvodov. Po prvé, spark-submit vám umožňuje priamo spustiť súbor jar z konzoly. Po druhé, môže obsahovať všetky potrebné informácie na konfiguráciu pracovného toku (čo uľahčuje písanie skriptov, ktoré generujú Dag).
Najčastejším prvkom pracovného toku Airflow bol v našom prípade SparkSubmitOperator.

SparkSubmitOperator vám umožňuje spúšťať jar - zabalené mapovania Datagramu s vopred vygenerovanými vstupnými parametrami pre ne.

Za zmienku stojí, že každá úloha Airflow beží v samostatnom vlákne a nevie nič o iných úlohách. Preto sa interakcia medzi úlohami uskutočňuje pomocou riadiacich operátorov, ako je DummyOperator alebo BranchPythonOperator.

Celkovo vzaté, použitie riešenia Datagram low-code v spojení s univerzalizáciou konfiguračných súborov (tvoriacich Dag) viedlo k výraznému zrýchleniu a zjednodušeniu procesu vývoja tokov načítania dát.

Ukážka výpočtov

Snáď najviac intelektuálne zaťaženou fázou pri produkcii analytických údajov je krok budovania vitrín. V kontexte jedného z tokov výpočtu údajov výskumnej spoločnosti sa v tejto fáze údaje zredukujú na referenčné vysielanie, pričom sa berú do úvahy korekcie pre časové pásma a sú prepojené s vysielacou mriežkou. Je tiež možné prispôsobiť sa lokálnej vysielacej sieti (miestne správy a reklama). Tento krok okrem iného rozdeľuje intervaly nepretržitého sledovania mediálnych produktov na základe analýzy intervalov sledovania. Zobrazované hodnoty sú okamžite „vážené“ na základe informácie o ich význame (výpočet korekčného faktora).

Samostatným krokom pri príprave vitrín je validácia údajov. Validačný algoritmus zahŕňa použitie množstva matematických vedeckých modelov. Použitie platformy s nízkym kódom vám však umožňuje rozdeliť zložitý algoritmus na množstvo samostatných vizuálne čitateľných mapovaní. Každé z mapovaní plní úzku úlohu. V dôsledku toho je možné prechodné ladenie, zaznamenávanie a vizualizácia fáz prípravy údajov.

Bolo rozhodnuté diskretizovať validačný algoritmus do nasledujúcich čiastkových fáz:

• Budovanie regresií závislostí sledovania televíznych sietí v regióne so sledovaním všetkých sietí v regióne počas 60 dní.
• Výpočet študentizovaných rezíduí (odchýlky skutočných hodnôt od hodnôt predpovedaných regresným modelom) pre všetky regresné body a pre vypočítaný deň.
• Výber anomálnych párov región-sieť, kde študentizovaná bilancia dňa zúčtovania presahuje normu (špecifikovanú nastaveniami prevádzky).
• Prepočet korigovaného studentizovaného rezidua pre anomálne páry región-TV sieť pre každého respondenta, ktorý sledoval sieť v regióne, určenie príspevku tohto respondenta (veľkosť zmeny v študentskom rezíduu) pri vylúčení sledovanosti tohto respondenta zo vzorky .
• Vyhľadajte kandidátov, ktorých vylúčenie vráti študentský zostatok výplaty späť do normálu.

Vyššie uvedený príklad potvrdzuje hypotézu, že dátový inžinier už toho má na srdci priveľa... A ak je to naozaj „inžinier“ a nie „kóder“, potom strach z profesionálneho znehodnotenia pri používaní nástrojov s nízkym kódom musí konečne ustúpiť.

Čo ešte dokáže nízky kód?

Rozsah použitia nízkokódového nástroja na dávkové a streamové spracovanie dát bez nutnosti manuálneho zapisovania kódu v Scale nekončí.

Používanie low-code pri vývoji datalake sa u nás už stalo štandardom. Pravdepodobne môžeme povedať, že riešenia založené na zásobníku Hadoop idú cestou vývoja klasických DWH založených na RDBMS. Nástroje s nízkym kódom v zásobníku Hadoop dokážu vyriešiť úlohy spracovania údajov aj úlohu budovania finálnych rozhraní BI. Okrem toho je potrebné poznamenať, že BI môže znamenať nielen reprezentáciu údajov, ale aj ich úpravu podnikovými používateľmi. Túto funkcionalitu často využívame pri budovaní analytických platforiem pre finančný sektor.

Okrem iného pomocou low-code a najmä Datagramu je možné vyriešiť problém sledovania pôvodu objektov dátového toku s atomicitou až k jednotlivým poliam (lineage). Na tento účel nástroj s nízkym kódom implementuje rozhranie s Apache Atlas a Cloudera Navigator. Vývojár v podstate potrebuje zaregistrovať súbor objektov v slovníkoch Atlas a pri vytváraní máp odkazovať na registrované objekty. Mechanizmus sledovania pôvodu údajov alebo analýzy závislostí objektov šetrí veľa času, keď je potrebné vylepšiť algoritmy výpočtu. Napríklad pri zostavovaní účtovnej závierky vám táto funkcia umožňuje pohodlnejšie prežiť obdobie legislatívnych zmien. Veď čím lepšie pochopíme medziformovú závislosť v kontexte objektov detailnej vrstvy, tým menej sa budeme stretávať s „náhle“ defektmi a znížime počet prerábok.

Kvalita dát a nízky kód

Ďalšou úlohou implementovanou nízkokódovým nástrojom na projekte Mediascope bola úloha Data Quality class. Zvláštnosťou implementácie potrubia overovania údajov pre projekt výskumnej spoločnosti bol nedostatočný vplyv na výkonnosť a rýchlosť hlavného toku výpočtu údajov. Aby bolo možné organizovať nezávislé toky overovania údajov, použil sa už známy Apache Airflow. Keďže každý krok produkcie dát bol pripravený, paralelne sa spustila samostatná časť DQ pipeline.

Za dobrú prax sa považuje monitorovanie kvality údajov od okamihu ich vzniku v analytickej platforme. S informáciami o metadátach môžeme kontrolovať súlad so základnými podmienkami od momentu, keď informácia vstúpi do primárnej vrstvy – nie null, obmedzenia, cudzie kľúče. Táto funkcionalita je implementovaná na základe automaticky generovaných mapovaní rodiny dátovej kvality v Datagrame. Generovanie kódu je v tomto prípade tiež založené na metadátach modelu. Na projekte Mediascope bolo rozhranie realizované s metadátami produktu Enterprise Architect.

Spárovaním nástroja s nízkym kódom s Enterprise Architect sa automaticky vygenerovali nasledujúce kontroly:

• Kontrola prítomnosti hodnôt „null“ v poliach s modifikátorom „not null“;
• Kontrola prítomnosti duplikátov primárneho kľúča;
• Kontrola cudzieho kľúča entity;
• Kontrola jedinečnosti reťazca na základe množiny polí.

Pre komplexnejšie kontroly dostupnosti a spoľahlivosti údajov bolo vytvorené mapovanie pomocou Scala Expression, ktoré berie ako vstup externý kontrolný kód Spark SQL pripravený analytikmi spoločnosti Zeppelin.

Samozrejme, automatické generovanie kontrol musí byť dosiahnuté postupne. V rámci opísaného projektu tomu predchádzali tieto kroky:

• DQ implementované v notebookoch Zeppelin;
• DQ zabudované do mapovania;
• DQ vo forme samostatných masívnych mapovaní obsahujúcich celý súbor kontrol pre samostatný subjekt;
• Univerzálne parametrizované mapovania DQ, ktoré ako vstup akceptujú informácie o metaúdajoch a obchodných kontrolách.

Možno hlavnou výhodou vytvorenia parametrizovanej kontrolnej služby je skrátenie času potrebného na dodanie funkčnosti do produkčného prostredia. Nové kontroly kvality môžu obísť klasický vzor doručovania kódu nepriamo prostredníctvom vývojových a testovacích prostredí:

• Všetky kontroly metadát sa generujú automaticky pri úprave modelu v EA;
• Kontroly dostupnosti údajov (určujúce prítomnosť akýchkoľvek údajov v určitom časovom bode) možno generovať na základe adresára, v ktorom je uložené očakávané načasovanie objavenia sa ďalšej časti údajov v kontexte objektov;
• Kontroly overenia obchodných údajov vytvárajú analytici v notebookoch Zeppelin. Odtiaľ sa odosielajú priamo do tabuliek nastavenia modulu DQ v produkčnom prostredí.

Neexistujú žiadne riziká priameho odosielania skriptov do výroby. Aj pri chybe v syntaxi nám hrozí maximálne nevykonanie jednej kontroly, pretože tok výpočtu dát a tok spustenia kontroly kvality sú od seba oddelené.

V podstate je služba DQ permanentne spustená v produkčnom prostredí a je pripravená začať svoju prácu v momente, keď sa objaví ďalší údaj.

namiesto záveru

Výhoda použitia nízkeho kódu je zrejmá. Vývojári nemusia vyvíjať aplikáciu od začiatku. A programátor oslobodený od ďalších úloh prináša výsledky rýchlejšie. Rýchlosť zase uvoľňuje ďalší čas na riešenie problémov s optimalizáciou. Preto sa v tomto prípade môžete spoľahnúť na lepšie a rýchlejšie riešenie.

Samozrejme, nízky kód nie je všeliekom a mágia sa nestane sama od seba:

• Odvetvie s nízkym kódom prechádza fázou „posilňovania“ a zatiaľ neexistujú jednotné priemyselné štandardy;
• Mnohé riešenia s nízkym kódom nie sú zadarmo a ich nákup by mal byť vedomým krokom, ktorý by sa mal robiť s plnou dôverou vo finančné výhody ich používania;
• Mnoho riešení s nízkym kódom nie vždy funguje dobre s GIT/SVN. Alebo ich použitie je nepohodlné, ak je vygenerovaný kód skrytý;
• Pri rozširovaní architektúry môže byť potrebné vylepšiť riešenie s nízkym kódom - čo zase vyvoláva efekt „pripútanosti a závislosti“ na dodávateľovi riešenia s nízkym kódom.
• Primeraná úroveň zabezpečenia je možná, ale je veľmi náročná na prácu a ťažko sa implementuje v systémových motoroch s nízkym kódom. Platformy s nízkym kódom by sa mali vyberať nielen na princípe hľadania výhod z ich používania. Pri výbere sa oplatí položiť si otázky o dostupnosti funkcionality pre riadenie prístupu a delegovanie/eskaláciu identifikačných údajov na úroveň celého IT prostredia organizácie.

Ak však poznáte všetky nedostatky zvoleného systému a výhody z jeho používania sú napriek tomu v dominantnej väčšine, bez obáv prejdite na malý kód. Navyše prechod k nemu je nevyhnutný – rovnako ako je nevyhnutná akákoľvek evolúcia.

Ak jeden vývojár na platforme s nízkym kódom robí svoju prácu rýchlejšie ako dvaja vývojári bez nízkeho kódu, dáva to spoločnosti náskok vo všetkých ohľadoch. Hranica pre vstup do nízkokódových riešení je nižšia ako do „tradičných“ technológií, čo má pozitívny vplyv na problematiku nedostatku personálu. Pri použití low-code nástrojov je možné zrýchliť interakciu medzi funkčnými tímami a rýchlejšie rozhodovať o správnosti zvolenej cesty výskumu dátovej vedy. Nízkoúrovňové platformy môžu riadiť digitálnu transformáciu organizácie, pretože vytvorené riešenia môžu pochopiť aj netechnickí špecialisti (najmä obchodní používatelia).

Ak máte krátke termíny, zaťaženú obchodnú logiku, nedostatok technologických znalostí a potrebujete urýchliť uvedenie na trh, potom je nízky kód jedným zo spôsobov, ako splniť vaše potreby.

Nemožno poprieť dôležitosť tradičných vývojových nástrojov, ale v mnohých prípadoch je použitie nízkokódových riešení najlepším spôsobom, ako zvýšiť efektivitu riešených úloh.

Zdroj: hab.com