Të nderuar lexues, përshëndetje!
Detyra e ndërtimit të platformave IT për akumullimin dhe analizën e të dhënave paraqitet në çdo kompani që ka një model shërbimi ose krijimi produktesh teknikisht të ndërlikuara. Ndërtimi i platformave analitike është një detyrë komplekse dhe e ndërlikuar. Megjithatë, çdo detyrë mund të thjeshtohet. Në këtë artikull, dua të ndaj përvojën e përdorimit të mjeteve low-code që ndihmojnë në krijimin e zgjidhjeve analitike. Kjo përvojë është fituar gjatë realizimit të një sërë projektesh në fushën e Big Data Solutions nga kompania "Neoflex". Fusha e Big Data Solutions në kompaninë "Neoflex" merret me ndërtimin e depozitave dhe liqeneve të të dhënave që nga viti 2005, zgjidhjen e problemeve të optimizimit të shpejtësisë së përpunimit të informacionit dhe punon mbi metodologjinë e menaxhimit të cilësisë së të dhënave.
Askush nuk mund të shmangë akumullimin e qëllimshëm të të dhënave pak dhe/ose shumë të strukturuara. Të paktën, jo edhe nga bizneset e vogla. Sepse gjatë zgjerimit të biznesit, një sipërmarrës i perspektivës do të përballet me çështjen e zhvillimit të një programi besnikërie, do të dëshironë të analizojë efektivitetin e pikave të shitjes, do të mendojë për reklamat e targetuara dhe do të shqetësohet për kërkesën për produkte shoqëruese. Në një fazë të parë, detyra mund të zgjidhet "në këmbë". Por me rritjen e biznesit, kalimi në një platformë analitike është i pashmangshëm.
Por kur mund të kalojnë detyrat e analizës së të dhënave në detyra të klasës "Rocket Science"? Ndoshta në momentin kur flasim për të dhëna vërtet të mëdha.
Për të thjeshtuar detyrën e "Rocket Science", mund të hani elefantin në pjesë.
Sa më shumë disketë dhe autonomi të kenë aplikacionet/shërbimet/mikroshërbimet tuaja, aq më lehtë do t'ju jetë juve, kolegëve tuaj dhe gjithë biznesit të përpunoni elefantin.
Ky postul ka ardhur në përfundim nga pothuajse të gjithë klientët tanë, të cilët kanë ristrukturuar peizazhin mbi bazën e praktikave inxhinierike të grupeve DevOps.
Por madje edhe me një dietë "të ndarë, elefantësh" kemi shanse të mira për "mbingopjen" e peizazhit IT. Në këtë moment, është e nevojshme të ndaloni, të merrni frymë dhe të shikoni drejt low-code engineering platform.
Shumë programues janë të frikësuar nga perspektiva e një ndalese në karrierë duke u larguar nga shkruajtja direkte e kodit në drejtim të "tërheqjes" së shigjetave në ndërfaqe të UI të sistemeve low-code. Por shfaqja e makinave nuk çoi në zhdukje të inxhinierëve, por e nxori punën e tyre në një nivel të ri!
Le të kuptojmë pse.
Analiza e të dhënave në fushën e logjistikës, industrisë së telekomunikacionit, në fushën e kërkimeve mediatike, sektorin financiar, gjithmonë lidhet me çështjet e mëposhtme:
- Shpejtësia e zhvillimit të analizave automatike;
- Mundësia për të kryer eksperimente pa ndikuar në fluksin kryesor të prodhimit të të dhënave;
- Saktësia e të dhënave të përgatitura;
- Ndjekja e ndryshimeve dhe versionimi;
- Data proves, Data lineage, CDC;
- Shpejtësia e dërgimit të karakteristikave të reja në mjedisin prodhues;
- Dhe e njohura: kostoja e zhvillimit dhe mbështetjes.
Kështu, inxhinierët kanë një numër të madh detyrash të nivelit të lartë, të cilat mund të përmbushen me efikasitet të mjaftueshëm vetëm pas pastrimit të mendjes nga detyrat e zhvillimit të nivelit të ulët.
Parakushtet për kalimin e programuesve në një nivel të ri ishin evolucioni dhe digjitalizimi i biznesit. Vlera e një programuesi gjithashtu ndryshon: ekziston një mungesë të konsiderueshme të programuesve që janë në gjendje të zhytin në thelbin e koncepteve të automatizuar të biznesit.
Le të bëjmë një analogji midis gjuhëve të programimit të nivelit të ulët dhe atyre të nivelit të lartë. Kalimi nga gjuhët e nivelit të ulët drejt atyre të nivelit të lartë është kalimi nga shkruajtja e "direktivave të drejtpërdrejta në gjuhën e harduerit" drejt "direktivave në gjuhën e njerëzve". Pra, shtimi i një katësi të caktuar të abstraksionit. Kështu, kalimi në platformat low-code nga gjuhët e programimit të nivelit të lartë është kalimi nga "direktivave në gjuhën e njerëzve" drejt "direktivave në gjuhën e biznesit". Nëse gjenden programues që e mërzitin ky fakt, atëherë ata mund të kenë qenë të mërzitur qysh në momentin që doli Java Script, ku përdoren funksione për sortimin e array-ve. Dhe këto funksione, padyshim, kanë një implementim programor në mënyra të tjera të programimit të nivelit të lartë.
Pra, low-code është thjesht shfaqja e një niveli tjetër të abstraksionit.
Përvoja praktike e përdorimit të low-code
Tema e low-code është mjaft e gjerë, por tani do të doja të flas për aplikimin praktik të "konceptet me pak kod" duke marrë shembuj nga një nga projektet tona.
Divizioni Big Data Solutions i kompanisĂ« «Neoflex» Ă«shtĂ« mĂ« shumĂ« i fokusuar nĂ« sektorin financiar tĂ« biznesit, duke ndĂ«rtuar depo dhe liqene tĂ« dhĂ«nash dhe duke automatizuar raportimin e ndryshĂ«m. NĂ« kĂ«tĂ« niĆĂ«, pĂ«rdorimi i low-code ka kohĂ« qĂ« Ă«shtĂ« bĂ«rĂ« standard. NdĂ«r mjetet e tjera low-code, mund tĂ« pĂ«rmendim mjetet pĂ«r organizimin e proceseve ETL: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Ose Oracle Apex, qĂ« shĂ«rben si njĂ« mjedis pĂ«r zhvillimin e shpejtĂ« tĂ« ndĂ«rfaqeve pĂ«r akses dhe redaktim tĂ« tĂ« dhĂ«nave. MegjithatĂ«, pĂ«rdorimi i mjeteve tĂ« zhvillimit low-code nuk Ă«shtĂ« gjithmonĂ« i ndĂ«rlidhur me ndĂ«rtimin e aplikacioneve tĂ« specializuara nĂ« njĂ« stak teknologjish komerciale me njĂ« varĂ«si tĂ« qartĂ« nga ofruesi.
Me platformat low-code, është gjithashtu e mundur të organizohet orkestrimi i flukseve të dhënash, të krijohen platforma data-science ose, për shembull, module për kontrollin e cilësisë së të dhënave.
NjĂ« nga shembujt praktikĂ« tĂ« pĂ«rvojĂ«s nĂ« pĂ«rdorimin e mjeteve tĂ« zhvillimit low-code Ă«shtĂ« bashkĂ«punimi i «Neoflex» me kompaninĂ« Mediascope, njĂ« nga liderĂ«t e tregut rus tĂ« kĂ«rkimeve tĂ« medias. NjĂ« nga detyrat e biznesit tĂ« kĂ«saj kompanie â prodhimi i tĂ« dhĂ«nave, mbi tĂ« cilat reklamuesit, platformat interneti, kanalet televizive, stacionet radio, agjencitĂ« reklamuese dhe markat marrin vendime pĂ«r blerjen e reklamave dhe planifikojnĂ« komunikimet e tyre marketingu.
KĂ«rkimet mediale janĂ« njĂ« sferĂ« biznesi me teknologji tĂ« larta. Njohja e video materialeve, mbledhja e tĂ« dhĂ«nave nga pajisjet qĂ« monitorojnĂ« shikimin, matja e aktiviteteve nĂ« burimet web â tĂ« gjitha kĂ«to nĂ«nkuptojnĂ« se kompania ka njĂ« staf tĂ« madh IT dhe njĂ« pĂ«rvojĂ« tĂ« madhe nĂ« ndĂ«rtimin e zgjidhjeve analitike. Por rritja eksponenciale e sasisĂ« sĂ« informacionit, numrit dhe llojeve tĂ« burimeve tĂ« tij, e detyron industrinĂ« e tĂ« dhĂ«nave tĂ« pĂ«rparojĂ« vazhdimisht. Zgjidhja mĂ« e thjeshtĂ« pĂ«r shkallĂ«zimin e njĂ« platforme analitike tashmĂ« funksionale Mediascope mund tĂ« kishte qenĂ« rritja e stafit IT. Por njĂ« zgjidhje shumĂ« mĂ« efikase Ă«shtĂ« pĂ«rshpejtimi i procesit tĂ« zhvillimit. NjĂ« nga hapat qĂ« çojnĂ« nĂ« kĂ«tĂ« drejtim mund tĂ« jetĂ« pĂ«rdorimi i platformave low-code.
Gjatë fillimit të projektit, kompania tashmë kishte një zgjidhje produkti funksionale. Megjithatë, realizimi i zgjidhjes në MSSQL nuk mund të përmbushte plotësisht pritshmëritë për shkallëzimin e funksionalitetit me ruajtjen e kostos së arsyeshme për modifikim.
Detyra që na pritej ishte vërtet ambicioze - «Neoflex» dhe Mediascope duhej të krijonin një zgjidhje industriale për më pak se një vit, me kushtin e daljes së MVP brenda tremujorit të parë nga data e fillimit të punës.
Si bazë për ndërtimin e platformës së re të të dhënave, e cila bazohet në llogaritjet low-code, u zgjodh staku i teknologjisë Hadoop. Standardi i ruajtjes së të dhënave u bë HDFS duke përdorur formate skedare parquet. Për aksesin në të dhënat që ndodhen në platformë, u përdor Hive, ku të gjitha vitrinat e disponueshme janë të paraqitura si tabela të jashtme. Ngarkimi i të dhënave në depo realizohej me ndihmën e Kafka dhe Apache NiFi.
Mjeti low-code në këtë koncept ishte përdorur për optimizimin e detyrës më punë intensive në ndërtimin e platformës analitike - detyrën e llogaritjes së të dhënave.
Mekanizmi kryesor për mapimin e të dhënave ishte zgjedhur si mjeti low-code Datagram. Neoflex Datagram është një mjet për zhvillimin e transformimeve dhe flukseve të të dhënave.
Duke përdorur këtë mjet, mund të kaloni pa shkruar kod në Scala «në mënyrë manuale». Kodi Scala gjenerohet automatikisht me përdorimin e qasjes Model Driven Architecture.
Një përfitim i dukshëm i këtij qasjeje është përshpejtimi i procesit të zhvillimit. Megjithatë, përveç shpejtësisë, ka edhe disa përfitime të tjera:
- Shikimi i përmbajtjes dhe strukturës së burimeve/pranuesve;
- Gjurma e origjinës së objekteve të flukseve të të dhënave deri në fusha të veçanta (lineage);
- Kryerja e pjesshme e transformimeve me shikimin e rezultateve të ndërmjetme;
- Shikimi i kodit burimor dhe rregullimi i tij para se të ekzekutohet;
- Validimi automatik i transformimeve;
- Ngarkimi automatik i të dhënave 1 me 1.
Pragu i hyrjes për zgjidhjet low-code për gjenerimin e transformimeve është mjaft i ulët: zhvilluesi duhet të dijë SQL dhe të ketë përvojë me instrumentet ETL. Megjithatë, është e rëndësishme të theksohet se gjeneratorët e transformimeve të drejtuar nga kodi nuk janë instrumente ETL në kuptimin e gjerë të kësaj fjale. Instrumentet low-code mund të mos kenë një mjedis të vetin për ekzekutimin e kodit. Kjo do të thotë se kodi i gjeneruar do të ekzekutohet në atë mjedis që ishte në klastrin para instalimit të zgjidhjes low-code. Dhe kjo, ndoshta, është një tjetër plus për low-code. Sepse paralelisht me ekipin low-code mund të punojë një ekip 'klasik' që implementon funksionalitetin, për shembull, me kodin e pastër Scala. Integrimi i përmirësimeve nga të dyja ekipet në prodhim do të jetë i thjeshtë dhe 'pa ndërprerje'.
Duket se është e rëndësishme të theksohet se përveç low-code, ka edhe zgjidhje no-code. Në thelb, këto janë gjëra të ndryshme. Low-code në një masë më të madhe i lejon zhvilluesit të ndërhyjë në kodin e gjeneruar. Në rastin e Datagram, është e mundur të shikohet dhe të redaktohet kodi i gjeneruar Scala, ndërsa no-code mund të mos ofrojë këtë mundësi. Kjo dallim është mjaft e rëndësishme jo vetëm në aspektin e fleksibilitetit të zgjidhjes, por edhe në aspektin e komoditetit dhe motivimit të punës së inxhinierëve të të dhënave.
Arkitektura e zgjidhjes
Le të përpiqemi të kuptojmë se si saktësisht instrumenti low-code ndihmon në zgjidhjen e problemeve të optimizimit të shpejtësisë së zhvillimit të funksionalitetit të llogaritjes së të dhënave. Fillimisht, le të shqyrtojmë arkitekturën funksionale të sistemit. Në këtë rast, shembujt përfaqësojnë modelin e prodhimit të të dhënave për kërkime mediale.
Burimet e të dhënave në rastin tonë janë shumë heterogjene dhe të larmishme:
- Peoplemeters (TV meters) â pajisje programore dhe harduerike qĂ« lexojnĂ« sjelljen e pĂ«rdoruesve nga anĂ«tarĂ«t e panelit televiziv â kush, kur dhe çfarĂ« kanali televiziv ka parĂ« nĂ« amvisĂ«rinĂ« qĂ« merr pjesĂ« nĂ« kĂ«rkim. Informacioni i ofruar Ă«shtĂ« njĂ« rrjedhĂ« intervalesh shikimi tĂ« ekranit tĂ« lidhura me paketĂ«n mediatike dhe produktin mediatik. TĂ« dhĂ«nat nĂ« fazĂ«n e ngarkimit nĂ« Data Lake mund tĂ« pasurohen me atribute demografike, lidhje me gjeostratĂ«n, kohĂ«zonen dhe informacion tjetĂ«r tĂ« nevojshĂ«m pĂ«r analizĂ«n e shikimit tĂ« ndonjĂ« produkti mediatik. Matjet e kryera mund tĂ« pĂ«rdoren pĂ«r analizim ose planifikimin e fushatave reklamuese, vlerĂ«simin e aktiviteteve dhe preferencave tĂ« audiencĂ«s, pĂ«rpilimin e grilave tĂ« transmetimit;
- Të dhënat mund të vijnë nga sistemet e monitorimit të transmetimit të drejtpërdrejtë dhe matjes së shikimit të përmbajtjes së burimeve video në internet;
- Instrumentet matëse në mjedisin web, përfshirë si numërues site-centric ashtu edhe user-centric. Një burim të dhënash për Data Lake mund të shërbejë një shtesë shfletuesi research bar dhe një aplikacion mobil me të integruar; VPN.
- Të dhënat gjithashtu mund të vijnë nga faqet që konsolidojnë rezultatet e plotësimit të anketave online dhe përfundimet e intervistave telefonike në kërkimet e kompanisë;
- Pasurimi i mëtejshëm i liqenit të të dhënave mund të ndodhë përmes ngarkimit të informacionit nga logët e kompanive partnere.
Implementimi as is i ngarkimit nga sistemet burimore në staging fillestar të të dhënave të papërpunuara mund të organizohet në mënyra të ndryshme. Në rastin e përdorimit të këtij qëllimi low-code, është e mundur të gjenerohet automatikisht skenari i ngarkimit bazuar në metadatën. Në këtë rast, nuk është e nevojshme të zhytemi në nivelin e zhvillimit të hartave nga burimi në destinacion. Për të realizuar ngarkimin automatik, na nevojitet të vendosim një lidhje me burimin, pas së cilës të përcaktojmë në ndërfaqen e ngarkimit listën e entiteteve që do të ngarkohen. Krijimi i strukturës së katalogeve në HDFS do të ndodhë automatikisht dhe do të korrespondosh me strukturën e ruajtjes së të dhënave në sistemin burim.
Megjithatë, në kontekstin e këtij projekti, ne vendosëm të mos përdorim këtë mundësi të platformave low-code për shkak se kompania Mediascope tashmë ka filluar punën për prodhimin e një shërbimi të ngjashëm me një kombinim Nifi + Kafka.
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet qĂ« kĂ«to instrumente nuk janĂ« tĂ« ndĂ«rkĂ«mbyeshme, por mĂ« shumĂ« pĂ«r plotĂ«suese njĂ«ri-tjetrit. Nifi dhe Kafka mund tĂ« punojnĂ« si nĂ« mĂ«nyrĂ« direkte (Nifi -> Kafka), ashtu edhe nĂ« mĂ«nyrĂ« tĂ« kundĂ«rt (Kafka -> Nifi). PĂ«r platformĂ«n e kĂ«rkimeve mediale u pĂ«rdor varianti i parĂ« i lidhjes.
Në rastin tonë, NiFi-na duhej të përpunonte lloje të ndryshme të të dhënave nga sistemet burimore dhe të dërgonte ato tek brokeri Kafka. Në të njëjtën kohë, dërgimi i mesazheve në një temë të caktuar Kafka bëhej përmes përdorimit të procesorëve PublishKafka të NiFi. Orkestrimi dhe mbështetje e këtyre pipeline-ve realizohet në një ndërfaqe vizuale. Vegla NiFi dhe përdorimi i kombinimit NiFi + Kafka gjithashtu mund të quhen një qasje low-code në zhvillim, me një prag të ulët hyrjeje në teknologjitë Big Data dhe që përshpejton procesin e zhvillimit të aplikacioneve.
Hapi tjetĂ«r nĂ« realizimin e projektit ishte tĂ« jepte njĂ« format tĂ« vetĂ«m pĂ«r nivelin semantik tĂ« tĂ« dhĂ«nave tĂ« detajuara. NĂ«se njĂ« entitet ka atribute historike, llogaritja bĂ«het nĂ« kontekstin e particionit pĂ«rkatĂ«s. NĂ«se entiteti nuk Ă«shtĂ« historik, atĂ«herĂ« mund tĂ« zgjidhet ose llogaritja e tĂ« gjithĂ« pĂ«rmbajtjes sĂ« objektit, ose plotĂ«sisht heqja e llogaritjes sĂ« kĂ«tij objekti (pĂ«r shkak tĂ« mungesĂ«s sĂ« ndryshimeve). NĂ« kĂ«tĂ« fazĂ«, gjenerohen çelĂ«sa pĂ«r tĂ« gjithĂ« entitetet. ĂelĂ«sat ruhen nĂ« regjistrat pĂ«rkatĂ«s tĂ« objekteve master Hbase, qĂ« pĂ«rmbajnĂ« pĂ«rputhjen midis çelĂ«save nĂ« platformĂ«n analitike dhe çelĂ«save nga sistemet burimore. Konsolidimi i entiteteve atomike shoqĂ«rohet me pasurimin me rezultatet e llogaritjeve analitike paraprake. Framework-u pĂ«r llogaritjen e tĂ« dhĂ«nave ishte Spark. Funksionaliteti i pĂ«rshkruar pĂ«r sjelljen e tĂ« dhĂ«nave nĂ« njĂ« semantik tĂ« unifikuar u realizua gjithashtu mbi bazĂ«n e hartimeve tĂ« veglĂ«s low-code Datagram.
Në arkitekturën e synuar, kërkohej të sigurohej akses SQL në të dhëna për përdoruesit e biznesit. Për këtë opsion, u përdor Hive. Regjistrimi i objekteve në Hive kryhet automatikisht kur aktivizohet opsioni "Regjistroni Tabelën Hive" në veglën low-code.
Menaxhimi i fluksit të llogaritjes
Datagram ka një ndërfaqe për ndërtimin e dizajneve të flukseve të punës. Aktivizimi i hartimeve mund të realizohet duke përdorur programin Oozie. Në ndërfaqen e zhvilluesit të flukseve, është e mundur të krijohen skema të ekzekutimeve paralele, sekondare ose të varura nga kushte të caktuara. Ka mbështetje për shell scripts dhe programe java. Gjithashtu është e mundur përdorimi server Apache Livy. Apache Livy përdoret për të aktivizuar aplikacione direkt nga mjedisi i zhvillimit.
Në rastin kur kompania tashmë ka një orkestrim të proceseve, është e mundur të përdoret REST API për të integruar hartimet në fluksin ekzistues. Për shembull, kishim një përvojë mjaft të suksesshme në integrimin e hartimeve në Scala në orkestra të shkruara në PLSQL dhe Kotlin. REST API i veglës low-code nënkupton qëllimet e tilla si gjenerimi i vitit të ekzekutimit mbi bazën e dizajnit të hartimit, thirrja e hartimit, thirrja e një sekuence hartimesh dhe, sigurisht, dërgimi i parametrave në URL për aktivizimin e hartimeve.
Përveç Oozie, është e mundur të organizohet fluksi i llogaritjes me mjete Airflow. Ndoshta nuk do të qëndroj gjatë në krahasimin mes Oozie dhe Airflow, por do të them se në kontekstin e punëve mbi projektin e hulumtimeve mediatike, u zgjodh Airflow. Argumentet kryesore për këtë ishin një komunitet më aktiv që zhvillon produktin dhe një ndërfaqe + API më të zhvilluar.
Airflow është gjithashtu i shkëlqyer sepse për përshkrimin e proceseve të llogaritjes përdoret Python, i cili është i preferuar nga shumë. Dhe me të vërtetë, platforma të menaxhuara me kod të hapur nuk ka shumë. Aktivizimi dhe monitorimi i ekzekutimeve të proceseve (duke përfshirë diagramin Gantt) e shton pikë në karmën e Airflow.
Formati i skedarit të konfigurimit për aktivizimin e hartimeve të zgjidhjeve low-code ishte spark-submit. Kjo ndodhi për dy arsye. Së pari, spark-submit lejon aktivizimin e drejtpërdrejt të një skedari jar nga konsola. Së dyti, ajo mund të përmbajë të gjithë informacionin e nevojshëm për konfigurimin e fluksit të punës (çka e lehtëson shkruarjen e skripteve që formojnë Dag).
Elementi më i zakonshëm i fluksit të punës Airflow në rastin tonë ishte SparkSubmitOperator.
SparkSubmitOperator lejon aktivizimin e jar-Ă«ve â hartimet e paketuar tĂ« Datagram me parametrat e inputit tĂ« formuar paraprakisht pĂ«r to.
Duhet përmendur se çdo detyrë Airflow ekzekutohet në një proces të veçantë dhe nuk di asgjë për detyrat e tjera. Si pasojë, ndërveprimi mes detyrave realizohet përmes operatoreve menaxhues, siç janë DummyOperator ose BranchPythonOperator.
Kombinimi i përdorimit të zgjidhjes low-code Datagram me unifikimin e skedarëve të konfigurimit (formues të Dag) çoi në një përshpejtim të konsiderueshëm dhe thjeshtim të procesit të zhvillimit të flukseve të ngarkesës së të dhënave.
Llogaritja e vitrinave
MehĂ«ra mĂ« intelektuale nĂ« prodhimin e tĂ« dhĂ«nave analitike Ă«shtĂ« hapin i ndĂ«rtimit tĂ« vitrinave. NĂ« kontekstin e njĂ« prej flukseve tĂ« llogaritjes sĂ« tĂ« dhĂ«nave tĂ« kompanisĂ« kĂ«rkimore, nĂ« kĂ«tĂ« hap bĂ«het pĂ«rshtatja nĂ« pĂ«rkthimin referues duke marrĂ« parasysh rregullimet pĂ«r zonat e kohĂ«s nĂ« lidhje me rrjetin e transmetimit. Po ashtu, Ă«shtĂ« e mundur njĂ« rregullim i rrjetit lokal tĂ« transmetimit (lajmet dhe reklamat lokale). NdĂ«r tĂ« tjera, nĂ« kĂ«tĂ« hap realizohet ndarja e intervaleve tĂ« shikimit tĂ« produkteve mediatike bazuar nĂ« analizĂ«n e intervaleve tĂ« shikimit. KĂ«tu ndodh gjithashtu âpeshaâ e vlerave tĂ« shikimit mbi bazĂ«n e informacionit pĂ«r rĂ«ndĂ«sinĂ« e tyre (llogaritja e koeficientit rregullues).
NjĂ« hap i veçantĂ« i pĂ«rgatitjes sĂ« vitrinave Ă«shtĂ« validimi i tĂ« dhĂ«nave. Algoritmi i validimit Ă«shtĂ« i lidhur me pĂ«rdorimin e disa modeleve shkencore matematikore. MegjithatĂ«, pĂ«rdorimi i platformave me kod tĂ« ulĂ«t lejon ndarjen e algoritmit tĂ« komplikuar nĂ« njĂ« sĂ«rĂ« mapimeve tĂ« lexueshme vizualisht. Ădo mapim realizon njĂ« detyrĂ« tĂ« ngushtĂ«. Si rezultat i kĂ«saj, Ă«shtĂ« i mundur debuguese e pĂ«rkohshme, regjistrimi dhe vizualizimi i fazave tĂ« pĂ«rgatitjes sĂ« tĂ« dhĂ«nave.
Algoritmi i validimit u vendos të disktretizohet në hapat e mëposhtëm:
- Ndërtoni regresionet e varësive të shikimit të kanaleve televizive në rajon me shikimin e të gjitha kanaleve në rajon për 60 ditë.
- Llogaritja e mbetjeve të studentizuara (devijimi i vlerave aktuale nga ato të parashikuara nga modeli regresionit) për të gjitha pikat e regresionit dhe për ditën llogaritur.
- Përzgjedhja e çiftëve anomale rajon-kanal televiziv, ku mbetja e studentizuar e ditës llogaritur tejkalon normën (të vendosur nga konfigurimi i operacionit).
- Rikthimi i mbetjes së studentizuar të rregulluar për çiftet anomale rajon-kanal televiziv për çdo përgjegjës, që shikoi kanalin në rajon, duke përcaktuar kontributin e këtij përgjegjësi (shkalla e ndryshimit të mbetjes së studentizuar) duke përjashtuar shikimin e këtij përgjegjësi nga mostrat.
- Kërkimi për kandidatë, përjashtimi i të cilëve të çon në normalizimin e mbetjes së studentizuar të ditës llogaritur.
Shembulli i mësipërm është një konfirmim i hipotezës se një inxhinier të dhënash ka shumë informacione për të mbajtur mend... Dhe, nëse ai është me të vërtetë "inxhinier", e jo "kodues", frika nga degradimi profesional nga përdorimi i mjeteve me kod të ulët duhet të largohet plotësisht.
ĂfarĂ« tjetĂ«r mund tĂ« bĂ«jĂ« low-code?
Fusha e përdorimit të mjetit low-code për përpunimin e paketave dhe rrjedhës së të dhënave pa nevojën për të shkruar kod në Scala manualisht nuk përfundon.
Përdorimi i low-code në zhvillimin e datalake-ëve për ne është bërë tashmë një standard. Mund të thuhet se zgjidhjet në stekun Hadoop përsëritin rrugën e zhvillimit të DWH klasike, të bazuara në RDBMS. Mjetet e ulta kode në stekun Hadoop mund të zgjidhin si detyrat e përpunimit të të dhënave ashtu edhe detyrat e ndërtimit të ndërfaqeve të fundit BI. Duhet të theksohet se për BI mund të njësohen jo vetëm përfaqësimi i të dhënave, por edhe redaktimi i tyre nga përdoruesit e biznesit. Ky funksionalitet shpesh përdoret nga ne në ndërtimin e platformave analitike për sektorin financiar.
Ndër të tjera, me ndihmën e low-code dhe, në veçanti, Datagram, është e mundur të zgjidhet detyra e gjurmimit të origjinës së objekteve të rrjedhës së të dhënave me atomizimin deri në fushat e veçanta (lineage). Për këtë, në mjetin low-code është implementuar lidhja me Apache Atlas dhe Cloudera Navigator. Në thelb, zhvilluesi duhet të regjistrojë një grup objektesh në fjalorët Atlas dhe të lidhet me objektet e regjistruara gjatë ndërtimit të mapimeve. Mekanizmi i gjurmimit të origjinës së të dhënave ose analiza e varësive të objekteve kurson shumë kohë nëse nevojiten ndryshime në algoritmet e llogaritjes. Për shembull, gjatë ndërtimit të raportimit financiar, kjo veçori lejon të kalojmë më lehtë periudhën e ndryshimeve të legjislacionit. Sepse, sa më cilësisht të kuptojmë varësinë ndërformale në aspektin e objekteve të nivelit të detajuar, aq më pak do të përballemi me defekte "të papritura" dhe do të reduktojmë numrin e riparimeve.
Cilësia e të Dhënave & Low-code
Një tjetër detyrë e realizuar me ndihmën e instrumentit low-code në projektin e kompanisë Mediascope ishte detyra e klasës Data Quality. Një veçori e realizimit të konvejrit të kontrollit të të dhënave për projektin e kompanisë kërkimore ishte mungesa e ndikimit në funksionimin dhe shpejtësinë e rrjedhës kryesore të përllogaritjes së të dhënave. Për mundësinë e orkestrimit nga rrjedha të pavarura të kontrollit të të dhënave, u përdor Apache Airflow, i njohur tashmë. Me përgatitjen e çdo hapi në prodhimin e të dhënave, ndodhi njëkohësisht lançimi i pjesës të veçantë të konvejrit DQ.
Një praktikë e mirë është monitorimi i cilësisë së të dhënave që nga krijimi i tyre në platformën analitike. Duke pasur informacion mbi metadatave, tashmë mund të kontrollojmë përputhshmërinë me kushtet bazë - not null, constraints, foreign keys - që kur informacioni hyn në shtresën fillestare. Ky funksionalitet është implementuar mbi bazën e hartimeve që generohet automatikisht të familjes data quality në Datagram. Kodimi automatik në këtë rast gjithashtu bazohet në metadatën e modelit. Në projektin e kompanisë Mediascope, lidhja ndodhi me metadatën e produktit Enterprise Architect.
Falë lidhjes midis instrumentit low-code dhe Enterprise Architect, u gjeneruan automatikisht kontrollet e mëposhtme:
- Kontrolli i pranisë së vlerave "null" në fushat me modifikuesin "not null";
- Kontrolli i pranisë së dyfisheve të çelësit primar;
- Kontrolli i çelësit të jashtëm të entitetit;
- Kontrolli i unikësisë së rreshtit sipas një grupi fushash.
Për kontrollime më të komplikuara mbi disponueshmërinë dhe saktësinë e të dhënave, u krijua një hartim me Scala Expression, që merr në hyrje kodin e kontrollit Spark SQL të jashtëm, të përgatitur nga analistët në Zeppelin.
Natyrisht, autogjenerimi i kontrolleve duhet të vijë hap pas hapi. Brenda projektit për të cilin po flasim, këto hapa e paraprinë:
- DQ, që janë realizuar në blloqet Zeppelin;
- DQ, të përfshira në hartim;
- DQ në formën e hartimeve masive të veçanta, që përmbajnë një grup të gjithë kontrolleve për një entitet të veçantë;
- Hartimet DQ të parametrizuar universale, që pranojnë informacion në lidhje me metadatën dhe kontrollet e biznesit.
Mund të thuhet se përparësia kryesore e krijimit të shërbimit të kontrolleve të parametrizuara është reduktimi i kohës së dorëzimit të funksionalitetit në ambientin e prodhimit. Kontrollet e reja të cilësisë mund të kalojnë përmes modelit klasik të dorëzimit të kodit përmes mjediseve të zhvillimit dhe testimit:
- Të gjitha kontrolllet e metadata gjenerohen automatikisht me ndryshimin e modelit në EA;
- Kontrollet e disponueshmërisë së të dhënave (caktimi i pranisë së ndonjë të dhëne në një moment) mund të gjenerohen mbi bazën e një udhëzuesi që ruan orarin e pritshëm të shfaqjes së një sasi të re të të dhënave në përputhje me objektet;
- Kontrollet e biznesit për saktësinë e të dhënave krijohen nga analistët në blloqe Zeppelin. Nga aty, ato dërgohen drejtpërdrejt në tabelat e konfigurimit të modulit DQ në ambientin e prodhimit.
Rreziqet e shkarkimit të drejtpërdrejtë të skripteve në prodhim janë si të tilla. Edhe në rast të një gabimi sintaksor, maksimumi që na kanoset është moszbatimi i një kontrolli, pasi rrjedha e përllogaritjes së të dhënave dhe rrjedha e fillimit të kontrolleve të cilësisë janë të ndara.
Në substancë, shërbimi DQ është përgjithmonë aktiv në ambientin e prodhimit dhe është gati të fillojë punën në momentin e shfaqjes së një sasi të re të të dhënave.
Në vend të përfundimit
Avantazhi i përdorimit të low-code është të dukshëm. Programuesit nuk kanë nevojë të zhvillojnë aplikacionin "nga fillimi". Ndërsa programuesi i çliruar nga detyra shtesë jep rezultate më shpejt. Shpejtësia, nga ana tjetër, çliron burime të tjera kohore për zgjidhjen e çështjeve të optimizimit. Prandaj, në këtë rast, mund të llogaritet që do të ketë një zgjidhje më cilësore dhe më të shpejtë.
Natyrisht, low-code është jo një panace, dhe magjia vetë nuk do të ndodhë:
- Industria low-code kalon nëpër një fazë "forcimi", dhe për momentin nuk ka standarde uniforme industriale;
- Shumë zgjidhje low-code nuk janë falas, dhe blerja e tyre duhet të jetë një hap i menduar, që duhet bërë me plotësisht besim në përfitimet financiare nga përdorimi i tyre;
- Shumë zgjidhje low-code nuk gjithmonë shkojnë mirë me GIT / SVN. Ose janë të papërshtatshme për t'u përdorur në rast të fshehjes së kodit të gjeneruar;
- Kur zgjeroni arkitekturën, mund të kërkohet rregullimi i zgjidhjes low-code - që, nga ana tjetër, provokon efektin e "pavarësisë dhe varësisë" nga ofruesi i zgjidhjes low-code.
- Niveli i duhur i sigurisë është i mundshëm, por shumë punëtor dhe i komplikuar për t'u realizuar me motorët e sistemeve low-code. Platformat low-code duhet të zgjidhen jo vetëm sipas parimit të kërkimit të përfitimeve nga përdorimi i tyre. Kur bëni zgjedhjen, duhet të pyesni për disponueshmërinë e funksionaliteteve të menaxhimit të aksesit dhe delegimit/eskalimit të të dhënave identifikuese në nivelin e gjithë peizazhit IT të organizatës.
MegjithatĂ«, nĂ«se tĂ« gjitha disavantazhet e sistemit tĂ« zgjedhur ju janĂ« tĂ« njohura, dhe pĂ«rfitimet nga pĂ«rdorimi i tij, megjithatĂ«, janĂ« nĂ« dominim tĂ« shumtĂ«, atĂ«herĂ« kaloni nĂ« low-code pa frikĂ«. Sidomos, pasi kalimi nĂ« tĂ« Ă«shtĂ« i pashmangshĂ«m â ashtu siç Ă«shtĂ« e pashmangshme çdo evolucion.
Nëse një zhvillues në një platformë low-code do të kryejë punën e tij më shpejt se dy zhvillues pa low-code, atëherë kjo i jep kompanisë një avantazh në të gjitha aspektet. Kanali i hyrjes në zgjidhjet low-code është më i ulët sesa në teknologjitë "tradicionale", dhe kjo ka një efekt pozitiv në çështjen e mungesës së kuadrove. Me përdorimin e mjeteve low-code, është e mundur të përshpejtohet ndërveprimi midis ekipet funksionale dhe të merret vendime më shpejt në lidhje me saktësinë e drejtimit të kërkimeve në data-science. Platformat e nivelit të ulët mund të jenë shkak i transformimit digjital të organizatës, për shkak se zgjidhjet e krijuara mund të jenë të kuptueshme për specialistët jo teknikë (në veçanti, përdoruesit e biznesit).
Nëse keni afate të ngushta, logjikë biznesi të ngarkuar, mungesë të ekspertizës teknologjike, dhe ju nevojitet të përshpejtoni kohën deri në treg, atëherë low-code është një nga mënyrat për të përmbushur nevojat tuaja.
Nuk duhet të mohohet rëndësia e mjeteve tradicionale të zhvillimit, megjithatë në shumë raste përdorimi i zgjidhjeve low-code është mënyra më e mirë për të rritur efikasitetin e detyrave të zgjidhura.
Burimi: habr.com
