KÀra lÀsare, god dag!
Att bygga IT-plattformar för att samla och analysera data Àr en utmaning som sÄ gott som varje företag förr eller senare stÀlls inför, sÀrskilt de vars verksamhet baseras pÄ en intellektuellt krÀvande tjÀnstemodell eller skapandet av tekniskt komplexa produkter. Att bygga analytiska plattformar Àr en komplex och resurskrÀvande uppgift. Men alla problem kan förenklas. I den hÀr artikeln vill jag dela med mig av vÄra erfarenheter av att anvÀnda verktyg med lÄg kod för att skapa analytiska lösningar. Dessa erfarenheter har vi fÄtt genom att genomföra flera projekt inom Big Data Solutions pÄ företaget "Neoflex". Sedan 2005 har Big Data Solutions pÄ "Neoflex" arbetat med att bygga datalager och datavolymer, lösa frÄgor kring hastigheten för informationbearbetning och utveckla metodologier för datakvalitetsstyrning.
Det gÄr inte att undvika att medvetet samla svagt och/eller starkt strukturerade data. Kanske, Àven om det handlar om smÄföretag. NÀr ett lovande företag vÀxer, kommer det att stöta pÄ frÄgor kring lojalitetsprogram, analysera försÀljningsstÀllen, tÀnka pÄ riktad reklam och bekymra sig över efterfrÄgan pÄ komplementprodukter. Inledningsvis kan dessa frÄgor lösas "pÄ egen hand". Men med företagets tillvÀxt blir det oundvikligt att införa en analytisk plattform.
Under vilka omstÀndigheter kan dataanalysens utmaningar övergÄ till uppgifter av klassen "Rocket Science"? Kanske just nÀr vi pratar om verkligt stora data.
För att förenkla "Rocket Science"-uppgiften kan man Àta elefanten i bitar.
Ju mer diskreta och sjÀlvstÀndiga era applikationer/tjÀnster/mikrotjÀnster Àr, desto enklare blir det för er, era kollegor och hela företaget att bearbeta elefanten.
Denna slutsats har nÀstan alla vÄra kunder kommit fram till genom att omstrukturera landskapet baserat pÄ ingenjörsmetoder frÄn DevOps-team.
Men Àven med en "separat, elefantdiet" har vi goda chanser till "överskott" i IT-landskapet. I detta ögonblick Àr det vÀrt att stanna upp, ta ett djupt andetag och titta i riktning mot lÄgnivÄkodningsplattform.
MĂ„nga utvecklare Ă€r skrĂ€mda av möjligheten att hamna i en karriĂ€rkris nĂ€r de gĂ„r ifrĂ„n att direkt skriva kod till att âdra och slĂ€ppaâ element i UI-grĂ€nssnitt för lĂ„gkodssystem. Men introduktionen av maskiner ledde inte till en minskning av ingenjörer; tvĂ€rtom höjde den deras arbete till en ny nivĂ„!
LÄt oss gÄ igenom varför.
Dataanalys inom logistik, telekommunikationsbranschen, medieforskning och finanssektorn Àr alltid förknippad med följande frÄgor:
- Hastigheten i den automatiserade analysprocessen;
- Möjligheten att genomföra experiment utan att pÄverka huvudflödet av datakapacitet;
- Tillförlitligheten av de förberedda uppgifterna;
- Ăvervakning av förĂ€ndringar och versionering;
- Data provenance, Data lineage, CDC;
- Snabbheten i att leverera nya funktioner till produktionsmiljön;
- Och den beryktade: kostnaden för utveckling och underhÄll.
Det innebÀr att ingenjörer har en mÀngd högre nivÄuppgifter som kan utföras effektivt först nÀr de rensar tankarna frÄn lÄgnivÄ utvecklingsuppgifter.
FörutsÀttningarna för att utvecklare skulle gÄ vidare till en ny nivÄ har varit affÀrernas evolution och digitalisering. Utvecklarens vÀrde förÀndras ocksÄ: det rÄder en stor brist pÄ utvecklare som kan förstÄ kÀrnan i koncepten för automatiserad verksamhet.
LĂ„t oss dra en parallell mellan lĂ„gnivĂ„- och högnivĂ„programmeringssprĂ„k. ĂvergĂ„ngen frĂ„n lĂ„gnivĂ„sprĂ„k till högnivĂ„sprĂ„k Ă€r en övergĂ„ng frĂ„n att skriva âdirekta direktiv pĂ„ maskinsprĂ„ketâ till âdirektiv pĂ„ mĂ€nniskosprĂ„ketâ. Det handlar om att lĂ€gga till ett lager av abstraktion. I det hĂ€r fallet innebĂ€r övergĂ„ngen frĂ„n högnivĂ„ programmeringssprĂ„k till lĂ„gkodplattformar en övergĂ„ng frĂ„n âdirektiv pĂ„ mĂ€nniskosprĂ„ketâ till âdirektiv pĂ„ affĂ€rssprĂ„ketâ. Om det finns utvecklare som blir ledsna över detta faktum, kan de ha varit ledsna sedan den dag JavaScript lanserades, dĂ€r funktioner för att sortera arrayer anvĂ€nds. Dessa funktioner har givetvis en programmatisk implementation under huven med hjĂ€lp av andra medel för samma högnivĂ„programmering.
SÄledes Àr lÄgkod helt enkelt ett nytt nivÄ av abstraktion.
Praktisk erfarenhet av att anvÀnda lÄgkod
Low-code-temat Àr ganska bred, men nu skulle jag vilja berÀtta om tillÀmpningen av "low-code-koncept" genom ett exempel frÄn ett av vÄra projekt.
Big Data Solutions-avdelningen inom företaget "Neoflex" specialiserar sig i stor utstrÀckning pÄ finanssektorn, dÀr man bygger datalager och datavattendrag samt automatiserar olika rapporteringsprocesser. Inom denna nisch har anvÀndningen av low-code lÀnge blivit standard. Bland andra low-code-verktyg kan vi nÀmna verktyg för att organisera ETL-processer: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Eller Oracle Apex, som Àr en plattform för snabb utveckling av anvÀndargrÀnssnitt för datainmatning och redigering. Men anvÀndningen av low-code-utvecklingsmedel Àr inte alltid kopplad till att bygga snÀvt inriktade applikationer pÄ en kommersiell teknikstack med tydligt beroende av leverantören.
Med hjÀlp av low-code-plattformar kan man ocksÄ organisera orkestrering av datastreams, skapa datavetenskapsplattformar eller till exempel moduler för datakvalitetskontroll.
Ett exempel pÄ tillÀmpning av low-code-utvecklingsmedel Àr samarbetet mellan "Neoflex" och företaget Mediascope, en av ledarna pÄ den ryska marknaden för medieforskning. Ett av mÄlen för denna företags verksamhet Àr att producera data som annonsörer, internetplattformar, TV-kanaler, radiostationer, reklambyrÄer och varumÀrken anvÀnder för att fatta beslut om inköp av reklam och planera sina marknadsföringskommunikationer.
Mediaforskning Àr en teknologiskt krÀvande affÀrssektor. VideoigenkÀnning, insamling av data frÄn enheter som analyserar visning, mÀtning av aktivitet pÄ webbplatser - allt detta förutsÀtter att företaget har en stor IT-stab och enorm erfarenhet av att bygga analytiska lösningar. Men den exponentiella tillvÀxten av mÀngden information, antalet och mÄngfalden av dess kÀllor tvingar stÀndigt IT-industrin att utvecklas. Den enklaste lösningen för att skala den redan fungerande Mediascope-analytiska plattformen skulle kunna vara att öka antalet IT-anstÀllda. Men en mycket mer effektiv lösning Àr att pÄskynda utvecklingsprocessen. Ett av stegen mot detta kan vara anvÀndningen av low-code-plattformar.
Vid projektets start hade företaget redan en fungerande produktlösning. Men implementeringen av lösningen pÄ MSSQL kunde inte fullt ut motsvara förvÀntningarna pÄ att skala funktionaliteten samtidigt som kostnaden för modifieringarna förblev acceptabel.
Den uppgift som lĂ„g framför oss var verkligen ambitiös â Neoflex och Mediascope skulle skapa en industriell lösning pĂ„ mindre Ă€n ett Ă„r, med kravet pĂ„ att MVP skulle lanseras inom första kvartalet frĂ„n projektstart.
Som grund för att bygga den nya databasen, baserad pÄ low-code-berÀkningar, valdes teknikstacken Hadoop. Standard för datalagring blev HDFS med anvÀndning av parquet-formatfiler. För att fÄ tillgÄng till data inom plattformen anvÀndes Hive, dÀr alla tillgÀngliga datakÀllor representeras som externa tabeller. Dataöverföring till lagret genomfördes med hjÀlp av Kafka och Apache NiFi.
Low-code-verktyget i detta koncept anvĂ€ndes för att optimera den mest arbetskrĂ€vande uppgiften i byggandet av den analytiska plattformen â databerĂ€kningsuppgiften.
Huvudmekanismen för datamappning valdes att bli low-code-verktyget Datagram. Neoflex Datagram Àr ett verktyg för att utveckla transformationer och datavolymer.
Genom att anvÀnda detta verktyg kan man klara sig utan att skriva Scala-kod "för hand". Scala-koden genereras automatiskt med hjÀlp av Model Driven Architecture.
Den uppenbara fördelen med ett sÄdant tillvÀgagÄngssÀtt Àr att utvecklingsprocessen gÄr snabbare. Men förutom hastigheten finns det ocksÄ följande fördelar:
- Visning av innehÄllet och strukturen hos kÀllor/mottagare;
- SpÄrning av ursprunget av datavolymens objekt ner till individuella fÀlt (lineage);
- Delvis genomförande av transformationer med visning av mellanresultat;
- Visning av koden och dess justering innan körning;
- Automatisk validering av transformationer;
- Automatisk dataöverföring 1 till 1.
Tröskeln för att komma in i low-code-lösningar för att generera transformationer Àr ganska lÄg: en utvecklare behöver kunna SQL och ha erfarenhet av ETL-verktyg. Det bör ocksÄ nÀmnas att code-driven-generationsverktyg för transformationer inte Àr ETL-verktyg i den breda bemÀrkelsen av ordet. Low-code-verktyg kanske inte har sin egen miljö för att köra kod. Det innebÀr att den genererade koden kommer att köras i den miljö som fanns i klustret innan installationen av low-code-lösningen. Och det hÀr Àr nog ytterligare en fördel för low-code, eftersom en "klassisk" team kan arbeta parallellt med low-code-teamet för att implementera funktionalitet, exempelvis pÄ ren Scala-kod. Att dra in förbÀttringar frÄn bÄda teamen till produktion kommer att vara enkelt och "sömlöst".
Det Àr vÀrt att notera att det förutom low-code Àven finns no-code-lösningar. Och i sitt vÀsen Àr det olika saker. Low-code ger i högre grad utvecklaren möjlighet att blanda sig i den genererade koden. I fallet med Datagram Àr det möjligt att granska och redigera den genererade Scala-koden, medan no-code kanske inte ger den möjligheten. Denna skillnad Àr mycket vÀsentlig, bÄde ur synpunkt av lösningens flexibilitet och ur synpunkt av bekvÀmlighet och motivation i arbete för datatekniker.
Arkitektur för lösningen
LÄt oss försöka förstÄ hur low-code-verktyget hjÀlper till att lösa problemet med att optimera utvecklingshastigheten för databerÀkningsfunktioner. Först ska vi titta pÄ systemets funktionella arkitektur. I det hÀr fallet fungerar modellen för dataproduktion för medieforskning som exempel.
DatakÀllorna i vÄrt fall Àr mycket heterogena och varierande:
- Peoplemetris (TV-metrar) Ă€r programvaru- och hĂ„rdvaruenheter som registrerar anvĂ€ndarbeteende hos respondenter pĂ„ tv-panelen â vem, nĂ€r och vilken tv-kanal som visades i hushĂ„ll som deltar i studien. Den information som levereras Ă€r en ström av visningstider kopplade till mediepaketet och medieprodukten. Data vid inlĂ€sning till Data Lake kan berikas med demografiska attribut, kopplingar till geografiska omrĂ„den, tidszoner och annan information som Ă€r nödvĂ€ndig för att genomföra analys av tv-tittande av en viss medieprodukt. De gjorda mĂ€tningarna kan anvĂ€ndas för analys eller planering av reklamakampanjer, bedömning av publik aktivitet och preferenser, samt utarbetande av sĂ€ndningsschema;
- Data kan komma frÄn system som övervakar strömmande tv-sÀndningar och mÀter visning av innehÄll pÄ videoresurser pÄ internet;
- MÀtningsverktyg i webbmiljö, som inkluderar bÄde site-centric och user-centric mÀtare. Dataleverantörer för Data Lake kan vara webblÀsartillÀgg som research bar och mobilapplikationer med inbyggd VPN.
- Data kan ocksÄ komma frÄn plattformar som konsoliderar resultat frÄn enkÀter och slutresultat frÄn telefonintervjuer i företagets undersökningar;
- Ytterligare berikning av datalaket kan ske genom att ladda upp information frÄn loggar frÄn partnerföretag.
Implementeringen av as-is-laddning frÄn kÀllsystem till primÀr staging av rÄdata kan organiseras pÄ olika sÀtt. Vid anvÀndning av low-code för dessa ÀndamÄl Àr automatisk generation av laddningsscript möjlig baserat pÄ metadata. I detta fall Àr det inte nödvÀndigt att gÄ ner pÄ nivÄn av utveckling av source to target-mappningar. För att genomföra automatisk laddning mÄste vi etablera en anslutning till kÀllan, varefter vi i laddningsgrÀnssnittet definierar listan över entiteter som ska laddas. Skapandet av katalogstrukturen i HDFS kommer att ske automatiskt och motsvara strukturen för datalagring i kÀllsystemet.
I sammanhanget av detta projekt har vi beslutat att inte anvÀnda denna möjlighet i low-code-plattformar, eftersom företaget Mediascope redan har pÄbörjat arbetet med att skapa en liknande tjÀnst med hjÀlp av Nifi + Kafka.
Det Àr viktigt att klargöra att dessa verktyg inte Àr ömsesidigt utbytbara, utan snarare kompletterar varandra. Nifi och Kafka kan arbeta bÄde i direkt (Nifi -> Kafka) och omvÀnd (Kafka -> Nifi) koppling. För medieforskningsplattformen anvÀndes den första kopplingen.
I vÄrt fall krÀvdes det att Nifi hanterade olika datatyper frÄn kÀllsystem och skickade dem till Kafka-brokern. Meddelandena riktades till en specifik Kafka-topic genom tillÀmpning av Nifi-processorerna PublishKafka. Orkestrering och hantering av dessa pipelines sker i det visuella grÀnssnittet. Verktyget Nifi och anvÀndningen av kopplingen Nifi + Kafka kan ocksÄ kallas en lÄgkodslösning för utveckling, som har en lÄg tröskel för att komma in i Big Data-teknologier och pÄskyndar utvecklingsprocessen för applikationer.
NÀsta steg i projektets genomförande var att anpassa till en enhetlig semantisk lag av detaljerad data. I fall dÀr en entitet har historiska attribut berÀknas detta i kontexten av den aktuella partitionen. Om entiteten inte Àr historisk kan antingen en omrÀkning av hela objektets innehÄll göras, eller sÄ kan man vÀlja att helt avstÄ frÄn omrÀkningen (pÄ grund av bristen pÄ förÀndringar). I detta skede genereras nycklar för alla entiteter. Nycklarna sparas i motsvarande huvudobjektsregister i Hbase, som innehÄller överensstÀmmelse mellan nycklar i den analytiska plattformen och nycklar frÄn kÀllsystemen. Konsolidering av atomÀra entiteter Ätföljs av berikning med resultat frÄn förhandsberÀkning av analytiska data. Ramverket för databerÀkning var Spark. Den funktionalitet som beskrivits för att anpassa data till en enhetlig semantik har ocksÄ implementerats baserat pÄ mappningar av lÄgkodverktyget Datagram.
I den mÄlarkitektur som behövdes skulle SQL-Ätkomst till data sÀkerstÀllas för affÀrsanvÀndare. För detta alternativ anvÀndes Hive. Registreringen av objekt i Hive sker automatiskt nÀr alternativet "Registrera Hive-tabell" aktiveras i lÄgkodverktyget.
Hantering av berÀkningsflödet
Datagram har ett grÀnssnitt för att bygga design av arbetsflöden. KartsÀttning kan köras med hjÀlp av Oozie-schemalÀggaren. I utvecklargrÀnssnittet för arbetsflöden kan man skapa scheman för parallell, sekventiell eller villkorsbunden datatransformation. Stöd finns för shell-skript och Java-program. AnvÀndning av servern Apache Livy. Apache Livy anvÀnds för att köra applikationer direkt frÄn utvecklingsmiljön.
Om företaget redan har en egen processorkestrator kan REST API anvÀndas för att integrera kartlÀggningar i det befintliga flödet. Till exempel har vi haft ganska framgÄngsrika erfarenheter av att integrera kartlÀggningar pÄ Scala i orkestra skrivna i PLSQL och Kotlin. REST API för lÄgt kodade verktyg innebÀr operationer som att generera exekveringsÄr baserat pÄ kartlÀggningsdesign, anropa kartlÀggning, anropa sekvens av kartlÀggningar och naturligtvis överföra parametrar i URL:en för att köra kartlÀggningar.
Utöver Oozie gÄr det ocksÄ att organisera berÀkningsflödet med hjÀlp av Airflow. Jag kommer inte att gÄ in pÄ en lÄng jÀmförelse mellan Oozie och Airflow, utan jag kan bara sÀga att i kontexten av medieforskningsprojektet föll valet pÄ Airflow. HuvudskÀlen för detta var ett mer aktivt community som utvecklar produkten och ett mer avancerat grÀnssnitt + API.
Airflow Àr ocksÄ bra eftersom det anvÀnder det mÄnga Àlskar, Python, för att beskriva berÀkningsprocesser. Generellt finns det inte sÄ mÄnga plattformar för att hantera arbetsflöden med öppen kÀllkod. Att köra och övervaka processer (inklusive med Gantt-diagram) ger dessutom poÀng till Airflows rykte.
Formatet för konfigurationsfilen för att köra lÄgkod-lösningar blev spark-submit. Detta skedde av tvÄ anledningar. För det första tillÄter spark-submit att direkt köra en jar-fil frÄn konsolen. För det andra kan det innehÄlla all nödvÀndig information för att konfigurera arbetsflödet (vilket underlÀttar skrivandet av skript som formar Dag).
Den mest frekvent förekommande komponenten i vÄrt arbetsflöde i Airflow blev SparkSubmitOperator.
SparkSubmitOperator gör det möjligt att köra jar-filer â packade kartlĂ€ggningar av Datagram med förberedda ingĂ„ngsparametrar.
Det Àr vÀrt att nÀmna att varje uppgift i Airflow körs i en separat trÄd och vet ingenting om andra uppgifter. Interaktionen mellan uppgifter sker dÀrför genom styroperatörer som DummyOperator eller BranchPythonOperator.
Sammanfattningsvis av anvÀndningen av low-code-lösningen Datagram i kombination med standardiseringen av konfigurationsfiler (som bildar Dag) har lett till en betydande snabbbefrÀmjande och förenklande av utvecklingsprocessen för dataladdningsflöden.
BerÀkning av dashboards
Kanske det mest intellektuellt krÀvande steget i produktionen av analytiska data Àr steget för att bygga dashboards. I samband med ett av flödena för databerÀkning i det forskande företaget sker det pÄ detta steg en anpassning till referenstranslationen med hÀnsyn till tidszonsjusteringar kopplade till sÀndningsnÀtet. En justering för det lokala sÀndningsnÀtet (lokala nyheter och reklam) Àr ocksÄ möjlig. Bland annat utförs i detta steg en uppdelning av intervall för kontinuerlig visning av mediaprodukter baserat pÄ analys av visningsintervall. HÀr sker ocksÄ en "vÀgning" av visningsvÀrdena baserat pÄ information om deras betydelse (berÀkning av korrigeringsfaktorn).
Ett sÀrskilt steg i förberedelsen av dashboards Àr datavalidering. Valideringsalgoritmen Àr kopplad till tillÀmpningen av en rad matematiska science-modeller. Men anvÀndningen av en low-code-plattform gör det möjligt att bryta ner den komplexa algoritmen i en rad separata visuellt avlÀsbara mappningar. Varje mappning utför en smal uppgift. Detta möjliggör mellanliggande avlusning, loggning och visualisering av datberedningsstegen.
Det beslutades att diskretisera valideringsalgoritmen pÄ följande delsteg:
- Byggande av regressionsberoenden mellan TV-nÀt i regionen och tittandet pÄ alla nÀt i regionen under 60 dagar.
- BerÀkning av studentiserade rester (avvikelser av faktiska vÀrden frÄn de predikterade vÀrdena av regressionsmodellen) för alla regressionspunkter och för den berÀknade dagen.
- Uttag av anomaliska par region-TV-nÀt dÀr den studentiserade resten för den berÀknade dagen överstiger normen (angiven av operationens instÀllning).
- OmrÀkningen av det justerade studentiserade saldot för anomala par mellan region och TV-nÀtverk för varje respondent som har tittat pÄ nÀtverket i regionen, med bestÀmning av denna respondents bidrag (storleken pÄ förÀndringen av det studentiserade saldot) vid uteslutning av denna respondents tittande frÄn urvalet.
- Sökning av kandidater vars uteslutning leder till att det studentiserade saldot för berÀkningsdagen normaliseras.
Det ovanstÄende exemplet bekrÀftar hypotesen att en dataingenjör redan har alldeles för mycket att hÄlla reda pÄ⊠Och om det verkligen Àr en "ingenjör" och inte en "kodare", borde rÀdslan för professionell försÀmring vid anvÀndning av low-code-verktyg definitivt avta.
Vad mer kan low-code göra?
AnvÀndningsomrÄdet för low-code verktyg för batch- och flödesbehandling av data utan behov av att manuellt skriva kod i Scala tar inte slut.
AnvÀndningen av low-code i utvecklingen av datalakes har redan blivit en standard för oss. Man kan nog sÀga att lösningar baserade pÄ Hadoop-stacken följer utvecklingsvÀgen för klassiska DWH, baserade pÄ relationsdatabaser. Low-code-verktyg pÄ Hadoop-stacken kan hantera bÄde databehandlingsuppgifter och uppgifter för att bygga slutliga BI-grÀnssnitt. Det Àr vÀrt att notera att BI kan förstÄs som inte bara representation av data, utan ocksÄ som deras redigering av affÀrsanvÀndare. Denna funktionalitet anvÀnds ofta av oss vid uppbyggnad av analytiska plattformar för finanssektorn.
Bland annat kan man med low-code och sÀrskilt Datagram lösa uppgiften att spÄra ursprunget till objekt inom datastream med atomisk precision ner till enskilda fÀlt (lineage). För detta har low-code-verktyget implementerat en koppling till Apache Atlas och Cloudera Navigator. I praktiken mÄste utvecklaren registrera en uppsÀttning objekt i Atlas-ordsprÄken och hÀnvisa till de registrerade objekten vid skapandet av mappningar. Mekanismen för att spÄra dators ursprung eller analysera objektberoenden sparar mycket tid nÀr det behövs Àndringar i berÀkningsalgoritmer. Till exempel, vid skapandet av finansiella rapporter gör denna funktion det lÀttare att hantera perioder av lagförÀndringar. Ju bÀttre vi förstÄr interformella beroenden i detaljerade lager, desto fÀrre "plötsliga" defekter kommer vi att möta och vi kommer att minska antalet rework.
Data Quality & Low-code
En annan uppgift som implementerades med low-code-verktyget i Mediascope-projektet var en uppgift av klassen Data Quality. En sÀrskildhet i implementeringen av datakontrollpipeline för forskningsföretagets projekt var frÄnvaron av pÄverkan pÄ funktionalitet och hastighet i huvudberÀkningströmmarna. För att kunna orkestrera oberoende datakontrollflöden anvÀndes det vÀlkÀnda Apache Airflow. NÀr varje steg i datatillverkningen var klart, startades parallellt en avskild del av DQ-pipelinen.
En god praxis Ă€r att övervaka datakvaliteten frĂ„n det att de skapas pĂ„ den analytiska plattformen. Med information om metadata kan vi redan frĂ„n det ögonblick informationen nĂ„r det primĂ€ra lagret kontrollera efterlevnaden av grundlĂ€ggande villkor â not null, constraints, foreign keys. Denna funktionalitet Ă€r baserad pĂ„ automatiskt genererade mappningar av datakvalitetsfamiljen i Datagram. Kodgenereringen i detta fall grundas ocksĂ„ pĂ„ metadata-modellen. I Mediascope-projektet skedde kopplingen med produktens Enterprise Architect-metadata.
Tack vare kopplingen mellan low-code-verktyget och Enterprise Architect genererades följande kontroller automatiskt:
- Kontroll av nÀrvaron av vÀrden "null" i fÀlt med modifieraren "not null";
- Kontroll av nÀrvaron av dubbletter av primÀrnyckeln;
- Kontroll av entitetens frÀmmande nyckel;
- Kontroll av unika poster baserat pÄ ett fÀltset.
För mer komplexa kontroller av tillgÄng och verifiering av data har en mappning skapats med Scala Expression, som tar emot extern Spark SQL-kod för kontroller, förberedd av analytiker i Zeppelin.
SjÀlvklart mÄste automatgenereringen av kontroller göras gradvis. Inom ramen för det beskrivna projektet föregicks detta av följande steg:
- DQ, genomfört i Zeppelin-notebookar;
- DQ, integrerade i mappningen;
- DQ som separata massiva mappningar, som innehÄller en komplett uppsÀttning kontroller för en specifik entitet;
- Universella parametiserade DQ-mappningar som tar emot information om metadata och affÀrskontroller.
Kanske den största fördelen med att skapa en tjÀnst för parametriserade kontroller Àr den kortare tiden för att leverera funktionalitet till produktionsmiljön. Nya kvalitetskontroller kan omgÄ den klassiska kodenleveransmönster via utvecklings- och testmiljöer:
- Alla metadata kontroller genereras automatiskt vid Àndring av modellen i EA;
- TillgÄngskontroller för data (definiering av förekomsten av viss data vid en viss tidpunkt) kan genereras baserat pÄ en katalog som lagrar den förvÀntade tidsramen för nÀr nÀsta uppsÀttning data kommer att vara tillgÀnglig, sett ur objektens perspektiv;
- AffÀrskontroller av dataverifiering skapas av analytiker i Zeppelin-notebookar. De skickas direkt till instÀllningstabellerna för DQ-modulen i produktionsmiljön.
Riskerna med direkt leverans av skript till produktion finns inte. Ăven vid syntaxfel Ă€r det vĂ€rsta som kan hĂ€nda att en kontroll inte genomförs, eftersom databerĂ€kningsflödet och kvalitetskontrollflödet Ă€r separerade.
I sjÀlva verket Àr DQ-tjÀnsten stÀndigt igÄng i produktionsmiljön och redo att börja sitt arbete vid ankomsten av nÀsta datauppsÀttning.
Avslutande
Fördelarna med att anvÀnda low-code Àr uppenbara. Utvecklare behöver inte skapa applikationen "frÄn grunden". Och en programmerare som befrias frÄn extra uppgifter levererar resultat snabbare. Hastigheten frigör i sin tur extra tid för att optimera frÄgor. DÀrför kan man i detta fall rÀkna med ett mer kvalitativt och snabbt lösning.
SjÀlvklart Àr low-code inte en universal lösning, och magi kommer inte att intrÀffa av sig sjÀlv:
- Den lÄga kodindustrin genomgÄr en "förstÀrknings"-fas, och det finns fortfarande inga homogena industriella standarder;
- MÄnga low-code-lösningar Àr inte gratis, och deras inskaffande bör vara ett genomtÀnkt steg som man bör ta med fullstÀndig sÀkerhet om den ekonomiska nyttan av att anvÀnda dem;
- MÄnga low-code-lösningar fungerar inte alltid bra med GIT / SVN. Antingen Àr de obekvÀma att anvÀnda om man vill dölja den genererade koden;
- Vid utvidgning av arkitekturen kan det krĂ€vas anpassningar av low-code-lösningen â vilket Ă„ sin sida skapar en kĂ€nsla av "bindning och beroende" av leverantören av low-code-lösningen.
- En lÀmplig sÀkerhetsnivÄ Àr möjlig, men det Àr vÀldigt arbetsintensivt och komplext att implementera i low-code-systemens motorer. Low-code-plattformar bör vÀljas inte bara utifrÄn förvÀntad nytta av att anvÀnda dem. NÀr man vÀljer bör man stÀlla sig frÄgorna om tillgÄngshanteringsfunktionalitet och delegiering/eskalering av identifieringsdata pÄ hela organisationens IT-landskap.
Men om alla nackdelar med det valda systemet Ă€r kĂ€nda, och fördelarna med att anvĂ€nda det Ă€ndĂ„ dominerar, ska ni gĂ„ över till low-code utan att vara rĂ€dda. Speciellt eftersom övergĂ„ngen Ă€r oundviklig â precis som all evolution.
Om en utvecklare pÄ en low-code-plattform utför sitt arbete snabbare Àn tvÄ utvecklare utan low-code, sÄ ger det företaget ett försprÄng pÄ alla sÀtt. IntrÀdeströskeln för low-code-lösningar Àr lÀgre Àn för "traditionell" teknologi, vilket har en positiv inverkan pÄ problemet med brist pÄ arbetskraft. Genom att anvÀnda lÄgkodverktyg kan samarbetet mellan funktionella team snabbas upp, och beslut om riktigheten av den valda vÀgen i data science-forskning kan fattas snabbare. LÄgkodsplattformar kan bli en drivkraft för digital transformation av organisationen, eftersom de lösningar som skapas kan förstÄs av icke-tekniska specialister (sÀrskilt företagsanvÀndare).
Om du har tight tidsramar, komplex affÀrslogik, brist pÄ teknisk expertis och behöver snabba upp time to market, Àr low-code ett av sÀtten att tillfredsstÀlla dina behov.
Det Àr svÄrt att förneka betydelsen av traditionella utvecklingsverktyg, men i mÄnga fall Àr anvÀndningen av lÄgkods-lösningar det bÀsta sÀttet att öka effektiviteten i de uppgifter som ska lösas.
KĂ€lla: habr.com
