Kedves olvasók, szép napot!
Az adatok gyűjtésére és elemzésére szolgáló informatikai platformok kiépítésének feladata előbb-utóbb minden olyan cégnél felmerül, amelynek üzleti tevékenysége intellektuálisan terhelt szolgáltatásnyújtási modellen vagy műszakilag összetett termékek létrehozásán alapul. Az elemző platformok építése összetett és időigényes feladat. Azonban minden feladat leegyszerűsíthető. Ebben a cikkben szeretném megosztani tapasztalataimat az alacsony kódszámú eszközök használatával kapcsolatban, amelyek segítségével analitikai megoldásokat hozhat létre. Ezt a tapasztalatot a Neoflex cég Big Data Solutions irányában számos projekt megvalósítása során szereztem. A Neoflex Big Data Solutions irányzata 2005 óta foglalkozik adattárházak és tavak építésével, az információfeldolgozás sebességének optimalizálásával kapcsolatos problémák megoldásával és az adatminőség-menedzsment módszertanának kidolgozásával.
Senki sem fogja tudni elkerülni a gyengén és/vagy erősen strukturált adatok tudatos felhalmozását. Talán még akkor is, ha kisvállalkozásokról beszélünk. Hiszen a vállalkozás méretezésekor egy ígéretes vállalkozó szembesül a hűségprogram kidolgozásának kérdéseivel, elemezni akarja az értékesítési pontok hatékonyságát, elgondolkozik a célzott reklámokon, és értetlenül áll a kísérő termékek iránti kereslet előtt. . Első közelítéssel a probléma „térdre” téve megoldható. De ahogy az üzlet növekszik, az analitikai platform elérése továbbra is elkerülhetetlen.
De milyen esetben fejlődhetnek az adatelemzési feladatok „Rocket Science” osztálybeli problémákká? Talán abban a pillanatban, amikor igazán nagy adatokról beszélünk.
A Rocket Science megkönnyítése érdekében darabonként megeheti az elefántot.
Minél diszkrétebbek és autonómabbak az alkalmazásai/szolgáltatásai/mikroszolgáltatásai, annál könnyebb lesz Önnek, kollégáinak és az egész vállalkozásnak megemészteni az elefántot.
Szinte minden ügyfelünk erre a posztulátumra jutott, miután a DevOps csapatok mérnöki gyakorlata alapján újjáépítette a tájat.
De még egy „külön, elefántos” diéta mellett is jó eséllyel „túltelítjük” az informatikai tájat. Ebben a pillanatban érdemes megállni, kilélegezni és oldalra nézni alacsony kódú mérnöki platform.
Sok fejlesztő megijed attól, hogy karrierje zsákutcába kerüljön, amikor az alacsony kódszámú rendszerek felhasználói felületén a közvetlen kódírástól a nyilak „húzása felé” mozdul el. De a szerszámgépek megjelenése nem a mérnökök eltűnéséhez vezetett, hanem munkájukat új szintre emelte!
Találjuk ki, miért.
A logisztika, a távközlés, a médiakutatás, a pénzügyi szektor adatelemzése mindig a következő kérdésekhez kapcsolódik:
- az automatizált elemzés sebessége;
- Kísérletek lefolytatásának képessége a fő adattermelési folyamat befolyásolása nélkül;
- Az elkészített adatok megbízhatósága;
- Nyomon követés és verziókezelés módosítása;
- Adatok származása, Adatvonal, CDC;
- Új funkciók gyors szállítása a termelési környezetbe;
- És a hírhedt: a fejlesztés és a támogatás költségei.
Azaz a mérnököknek rengeteg magas szintű feladatuk van, melyeket csak az alacsony szintű fejlesztési feladatoktól való tudatuk megtisztításával lehet kellő hatékonysággal elvégezni.
A fejlesztők új szintre lépésének előfeltétele az üzlet fejlődése és digitalizálása volt. Változik a fejlesztő értéke is: jelentős hiány van azokból a fejlesztőkből, akik el tudnak mélyedni az automatizálódó üzletág koncepcióiban.
Vonjunk analógiát az alacsony és magas szintű programozási nyelvekkel. Az alacsony szintű nyelvekről a magas szintű nyelvekre való átmenet átmenetet jelent a „közvetlen direktívák a hardver nyelvén” írásától az „az emberek nyelvén történő irányelvek” felé. Vagyis némi absztrakciós réteg hozzáadásával. Ebben az esetben az alacsony kódú platformokra való áttérés a magas szintű programozási nyelvekről egy átmenetet jelent az „embernyelvi irányelvekről” az „üzleti nyelvű irányelvekre”. Ha vannak fejlesztők, akiket elszomorít ez a tény, akkor ők talán a tömbrendező funkciókat használó Java Script megszületése óta. És ezek a funkciók természetesen szoftveres implementációval rendelkeznek, ugyanazon magas szintű programozás más eszközeivel.
Ezért az alacsony kód csak az absztrakció egy másik szintjének megjelenése.
Alkalmazott tapasztalat alacsony kód használatával
Az alacsony kód témája meglehetősen tág, de most az „alacsony kódú fogalmak” gyakorlati alkalmazásáról szeretnék beszélni egy projektünk példáján.
A Neoflex Big Data Solutions részlege inkább az üzleti pénzügyi szektorra specializálódott, adattárházak és tavak építésére, valamint különféle jelentéskészítés automatizálására. Ebben a résben az alacsony kód használata régóta szabványossá vált. Az egyéb alacsony kódú eszközök közül megemlíthetjük az ETL folyamatok szervezésére szolgáló eszközöket: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Vagy az Oracle Apex, amely az adatok elérésére és szerkesztésére szolgáló interfészek gyors fejlesztésének környezeteként működik. Az alacsony kódszámú fejlesztőeszközök használata azonban nem mindig jelenti azt, hogy egy kereskedelmi technológiai veremre kell erősen célzott alkalmazásokat építeni, amelyek egyértelműen a gyártótól függenek.
Alacsony kódú platformok segítségével megszervezheti az adatfolyamok hangszerelését, létrehozhat adattudományi platformokat vagy például modulokat az adatok minőségének ellenőrzésére.
Az alacsony kódú fejlesztőeszközök használatában szerzett tapasztalatok egyik alkalmazott példája a Neoflex és az orosz médiakutatási piac egyik vezető Mediascope együttműködése. A társaság üzleti céljai között szerepel olyan adatok előállítása, amelyek alapján a hirdetők, internetes platformok, tévécsatornák, rádiók, reklámügynökségek és márkák reklámvásárlási döntéseket hoznak, marketingkommunikációjukat megtervezik.
A médiakutatás technológiailag terhelt üzleti terület. Videósorozatok felismerése, adatgyűjtés a megtekintést elemző eszközökről, a webes erőforrásokon végzett tevékenység mérése – mindez azt jelenti, hogy a cég nagy informatikai személyzettel és óriási tapasztalattal rendelkezik az analitikai megoldások kiépítésében. Az információ mennyiségének, forrásainak számának és változatosságának exponenciális növekedése azonban folyamatos fejlődésre kényszeríti az IT-adatipart. A már működő Mediascope elemző platform skálázásának legegyszerűbb megoldása az informatikai személyzet növelése lehet. De sokkal hatékonyabb megoldás a fejlesztési folyamat felgyorsítása. Az egyik ebbe az irányba vezető lépés lehet az alacsony kódú platformok használata.
A projekt indulásakor a cég már rendelkezett működő termékmegoldással. A megoldás MSSQL-ben való megvalósítása azonban nem tudta maradéktalanul teljesíteni a skálázhatósággal szemben támasztott elvárásokat az elfogadható fejlesztési költségek fenntartása mellett.
Az előttünk álló feladat valóban ambiciózus volt – a Neoflexnek és a Mediascope-nak kevesebb mint egy év alatt kellett ipari megoldást létrehoznia, az MVP megjelenésének függvényében a kezdési dátum első negyedévében.
A Hadoop technológiai stacket választották egy új, alacsony kódszámú számítástechnikán alapuló adatplatform felépítésének alapjául. A HDFS a parkettareszelőket használó adattárolás szabványává vált. A platformon található adatok eléréséhez a Hive-t használtuk, amelyben az összes elérhető kirakat külső táblázatok formájában jelenik meg. Az adatok tárolóba való betöltése Kafka és Apache NiFi segítségével történt.
Ebben a koncepcióban a Lowe-code eszközt az analitikai platform felépítésének legmunkaigényesebb feladatának – az adatszámítási feladat – optimalizálására használták.
Az alacsony kódú Datagram eszközt választották az adatleképezés fő mechanizmusának. Neoflex Datagram transzformációk és adatfolyamok fejlesztésének eszköze.
Ezzel az eszközzel megteheti a Scala kód kézi írása nélkül. A Scala kód automatikusan generálódik a Model Driven Architecture megközelítéssel.
Ennek a megközelítésnek nyilvánvaló előnye a fejlesztési folyamat felgyorsítása. A sebesség mellett azonban a következő előnyökkel is jár:
- A források/vevők tartalmának és szerkezetének megtekintése;
- Az adatfolyam-objektumok eredetének nyomon követése az egyes mezőkre (leágazás);
- Transzformációk részleges végrehajtása köztes eredmények megtekintésével;
- A forráskód áttekintése és módosítása végrehajtás előtt;
- Transzformációk automatikus érvényesítése;
- Automatikus adatletöltés 1 az 1-ben.
Az átalakítások generálására szolgáló alacsony kódú megoldásokba való belépés akadálya meglehetősen alacsony: a fejlesztőnek ismernie kell az SQL-t, és tapasztalattal kell rendelkeznie az ETL-eszközökkel való munkavégzésben. Érdemes megemlíteni, hogy a kódvezérelt transzformációs generátorok nem ETL-eszközök a szó tág értelmében. Előfordulhat, hogy az alacsony kódú eszközöknek nincs saját kódvégrehajtási környezetük. Ez azt jelenti, hogy a generált kód a fürtben létező környezetben fut le, még az alacsony kódszámú megoldás telepítése előtt. És ez talán egy újabb plusz az alacsony kódú karmához. Mivel egy alacsony kódú csapattal párhuzamosan dolgozhat egy „klasszikus” csapat, amely például tiszta Scala kódban valósítja meg a funkcionalitást. Mindkét csapat fejlesztései egyszerűen és zökkenőmentesen állíthatók be a termelésbe.
Talán érdemes megjegyezni, hogy a low-code mellett léteznek kód nélküli megoldások is. És lényegükben ezek különböző dolgok. Az alacsony kód lehetővé teszi a fejlesztő számára, hogy jobban beavatkozzon a generált kódba. A Datagram esetében lehetőség van a generált Scala kód megtekintésére és szerkesztésére, a no-code erre nem biztos, hogy lehetőséget biztosít. Ez a különbség nem csak a megoldás rugalmassága, hanem az adatmérnökök munkájának kényelme és motivációja szempontjából is igen jelentős.
Megoldás architektúra
Próbáljuk kitalálni, hogy egy alacsony kódú eszköz pontosan hogyan segít megoldani az adatszámítási funkciók fejlesztési sebességének optimalizálásának problémáját. Először nézzük meg a rendszer funkcionális architektúráját. Példa erre az esetre a médiakutatás adattermelési modellje.
Az adatforrások esetünkben nagyon heterogének és változatosak:
- Az embermérők (TV-mérők) olyan szoftver- és hardvereszközök, amelyek leolvasják a televíziós panel válaszadóinak felhasználói viselkedését – ki, mikor és milyen tévécsatornát nézett a vizsgálatban részt vevő háztartásban. A szolgáltatott információ a médiacsomaghoz és a médiatermékhez kapcsolódó adás-nézési időközök folyama. A Data Lake-be való betöltés szakaszában lévő adatok demográfiai jellemzőkkel, geosztratifikációval, időzónával és egyéb információkkal gazdagíthatók, amelyek egy adott médiatermék televíziós nézettségének elemzéséhez szükségesek. Az elvégzett mérések felhasználhatók reklámkampányok elemzésére, tervezésére, a közönség aktivitásának, preferenciáinak felmérésére, a műsorszórási hálózat összeállítására;
- Az adatok származhatnak a televíziós adások streamelésére és az internetes videoforrás-tartalom megtekintésének mérésére szolgáló megfigyelőrendszerekből;
- Mérőeszközök webes környezetben, ideértve mind a hely-, mind a felhasználó-központú mérőket. A Data Lake adatszolgáltatója lehet egy keresősáv böngészőbővítménye és egy beépített VPN-t tartalmazó mobilalkalmazás.
- Az adatok olyan oldalakról is származhatnak, amelyek az online kérdőívek kitöltésének eredményeit és a vállalati felmérések során a telefonos interjúk eredményeit konszolidálják;
- Az adattó további gazdagítása a partnercégek naplóiból való információk letöltésével történhet.
Az as is betöltés a forrásrendszerekből a nyers adatok elsődleges állomásozásába többféleképpen is megszervezhető. Ha alacsony kódot használnak erre a célra, akkor lehetséges a betöltő szkriptek automatikus generálása metaadatok alapján. Ebben az esetben nem kell lemenni a forrás fejlesztésének szintjére a célleképezésekhez. Az automatikus betöltés megvalósításához kapcsolatot kell létesítenünk a forrással, majd a betöltési felületen meg kell határoznunk a betöltendő entitások listáját. A HDFS könyvtárszerkezete automatikusan létrejön, és megfelel a forrásrendszer adattárolási struktúrájának.
Ezzel a projekttel kapcsolatban azonban úgy döntöttünk, hogy nem használjuk az alacsony kódú platform ezen funkcióját, mivel a Mediascope cég már önállóan megkezdte a munkát egy hasonló szolgáltatás előállításán a Nifi + Kafka kombináció használatával.
Érdemes azonnal jelezni, hogy ezek az eszközök nem felcserélhetők, inkább kiegészítik egymást. A Nifi és a Kafka közvetlen (Nifi -> Kafka) és fordított (Kafka -> Nifi) kapcsolattal is működhetnek. A médiakutatási platformhoz a csomag első verzióját használták.
Esetünkben a NayFi-nek különféle típusú adatokat kellett feldolgoznia a forrásrendszerekből, és el kellett küldenie a Kafka brókernek. Ebben az esetben az üzeneteket egy adott Kafka-témához küldték el PublishKafka Nifi processzorok segítségével. Ezen csővezetékek hangszerelése és karbantartása vizuális felületen történik. A Nifi eszközt és a Nifi + Kafka kombináció használatát a fejlesztés alacsony kódú megközelítésének is nevezhetjük, amely alacsonyan akadályozza a Big Data technológiákba való belépést, és felgyorsítja az alkalmazásfejlesztési folyamatot.
A projekt megvalósításának következő lépése az volt, hogy a részletes adatokat egyetlen szemantikai rétegű formátumba hozzuk. Ha egy entitás történelmi attribútumokkal rendelkezik, a számítás a kérdéses partíció kontextusában történik. Ha az entitás nem történeti, akkor opcionálisan lehetőség van az objektum teljes tartalmának újraszámítására, vagy az objektum újraszámításának teljes elutasítására (a változtatások hiánya miatt). Ebben a szakaszban minden entitáshoz létrejönnek kulcsok. A kulcsok a mesterobjektumoknak megfelelő Hbase könyvtárakban tárolódnak, amelyek megfelelést tartalmaznak az analitikai platform kulcsai és a forrásrendszerekből származó kulcsok között. Az atomi entitások konszolidációja az analitikai adatok előzetes számítási eredményeivel való gazdagítással jár. Az adatszámítás kerete a Spark volt. Az adatok egyetlen szemantikába hozására vonatkozó leírt funkcionalitást szintén az alacsony kódú Datagram eszköz leképezései alapján valósították meg.
A célarchitektúra SQL hozzáférést igényelt az adatokhoz az üzleti felhasználók számára. Ehhez a lehetőséghez kaptárt használtak. Az objektumok automatikusan regisztrálásra kerülnek a Hive-ben, amikor engedélyezi a „Registr Hive Table” opciót az alacsony kódú eszközben.
Számítási áramlásszabályozás
A Datagram felülettel rendelkezik a munkafolyamat-tervek létrehozásához. A leképezések az Oozie ütemezővel indíthatók. A stream fejlesztői felületen lehetőség van párhuzamos, szekvenciális vagy végrehajtástól függő adattranszformációk sémák létrehozására. Támogatják a shell szkripteket és a java programokat. Lehetőség van az Apache Livy szerver használatára is. Az Apache Livy az alkalmazások közvetlenül a fejlesztői környezetből történő futtatására szolgál.
Ha a vállalatnak már van saját folyamatirányítója, akkor a REST API segítségével leképezéseket ágyazhat be egy meglévő folyamatba. Például elég sikeres tapasztalatunk volt a Scala leképezések PLSQL-ben és Kotlinban írt hangszerelőkbe való beágyazásával. Az alacsony kódú eszköz REST API-ja olyan műveleteket tartalmaz, mint a leképezési terv alapján egy végrehajtható év generálása, leképezés meghívása, leképezések sorozatának meghívása, és természetesen paraméterek átadása az URL-nek a leképezések futtatásához.
Az Oozie mellett lehetőség van számítási folyamat megszervezésére az Airflow segítségével. Talán nem fogok sokáig foglalkozni az Oozie és az Airflow összehasonlításával, csak annyit mondok, hogy egy médiakutatási projekt kapcsán a választás az Airflow mellett esett. A fő érvek ezúttal a terméket fejlesztő aktívabb közösség és a fejlettebb felület + API voltak.
A légáramlás azért is jó, mert a szeretett Pythont használja a számítási folyamatok leírására. És általában véve nincs olyan sok nyílt forráskódú munkafolyamat-kezelő platform. A folyamatok elindítása és végrehajtásának monitorozása (beleértve a Gantt-diagramot is) csak pontokat ad az Airflow karmájához.
Az alacsony kódú megoldás-leképezések elindításához használt konfigurációs fájlformátum Spark-submit lett. Ez két okból történt. Először is, a spark-submit lehetővé teszi a jar fájl közvetlen futtatását a konzolról. Másodszor, minden szükséges információt tartalmazhat a munkafolyamat konfigurálásához (ami megkönnyíti a Dag-et generáló szkriptek írását).
Az Airflow munkafolyamat leggyakoribb eleme esetünkben a SparkSubmitOperator volt.
A SparkSubmitOperator lehetővé teszi a jar futtatását – csomagolt Datagram-leképezéseket előre generált bemeneti paraméterekkel.
Érdemes megemlíteni, hogy minden Airflow feladat külön szálban fut, és nem tud semmit a többi feladatról. Ezért a feladatok közötti interakció vezérlőoperátorok, például DummyOperator vagy BranchPythonOperator segítségével történik.
Összességében a Datagram alacsony kódú megoldásának használata a konfigurációs fájlok univerzálissá tételével (Dag formálásával) együtt az adatbetöltési folyamatok fejlesztési folyamatának jelentős felgyorsulásához és egyszerűsítéséhez vezetett.
Kirakat számítás
Az analitikai adatok előállításának talán legintellektuálisabb szakasza a vitrinek építése. A kutatócég egyik adatszámítási folyamata keretében ebben a szakaszban az adatokat referencia adássá redukálják, figyelembe véve az időzónák korrekcióit, és összekapcsolják a sugárzási ráccsal. Lehetőség van a helyi műsorszóró hálózathoz való alkalmazkodásra is (helyi hírek és reklám). Ez a lépés többek között a megtekintési intervallumok elemzése alapján lebontja a médiatermékek folyamatos megtekintésének intervallumait. A megtekintési értékeket azonnal „súlyozzák” a jelentőségükre vonatkozó információk alapján (korrekciós tényező kiszámítása).
A vitrinek elkészítésének külön lépése az adatok érvényesítése. Az érvényesítési algoritmus számos matematikai tudományos modell használatát foglalja magában. Az alacsony kódszámú platform használata azonban lehetővé teszi, hogy egy összetett algoritmust több különálló, vizuálisan olvasható leképezésre bontson. Mindegyik leképezés egy szűk feladatot lát el. Ennek eredményeként lehetséges a közbenső hibakeresés, naplózás és az adat-előkészítési szakaszok megjelenítése.
Úgy döntöttek, hogy az érvényesítési algoritmust a következő részszakaszokra osztják fel:
- TV-hálózati megtekintési függőségek regresszióinak felépítése egy régióban a régió összes hálózatának megtekintésével 60 napig.
- Tanulmányozott reziduumok kiszámítása (a tényleges értékek eltérései a regressziós modell által előrejelzett értékektől) minden regressziós pontra és a számított napra.
- Válogatás anomális régió-hálózat párokból, ahol az elszámolási nap hallgatói egyenlege meghaladja a (műveleti beállítások által meghatározott) normát.
- Az anomális régió-TV hálózat párok korrigált studentizált reziduumának újraszámítása minden válaszadó esetében, aki a régióban nézte a hálózatot, meghatározva ennek a válaszadónak a hozzájárulását (a hallgatózott reziduum változásának mértékét), ha a válaszadó megtekintését kizárjuk a mintából .
- Keressen olyan jelölteket, akiknek a kizárásával a fizetésnapok hallgatói egyenlege visszaáll a normális szintre.
A fenti példa megerősíti azt a hipotézist, hogy az adatmérnöknek már túl sok minden jár a fejében... És ha ez valóban „mérnök” és nem „kódoló”, akkor a professzionális leépüléstől való félelem alacsony kódú eszközök használatakor végre vissza kell vonulnia.
Mit tehet még az alacsony kód?
Az alacsony kódszámú eszköz alkalmazási köre kötegelt és adatfolyamos adatfeldolgozáshoz anélkül, hogy manuálisan kellene kódot írni a Scalában, nem ér véget.
A low-code használata a datalake fejlesztésében már megszokottá vált nálunk. Valószínűleg kijelenthetjük, hogy a Hadoop veremre épülő megoldások a klasszikus RDBMS alapú DWH-k fejlesztési útját követik. A Hadoop veremben található alacsony kódú eszközök mind az adatfeldolgozási feladatokat, mind a végső BI-felületek felépítését képesek megoldani. Sőt, meg kell jegyezni, hogy a BI nemcsak az adatok megjelenítését, hanem azok üzleti felhasználók általi szerkesztését is jelentheti. Gyakran használjuk ezt a funkciót, amikor elemzési platformokat építünk a pénzügyi szektor számára.
Többek között az alacsony kódú és különösen a Datagram használatával megoldható az adatfolyam objektumok eredetének atomitású nyomon követése az egyes mezőkig (vonalvonalig). Ehhez az alacsony kódú eszköz az Apache Atlas és a Cloudera Navigator interfészt valósítja meg. Lényegében a fejlesztőnek regisztrálnia kell egy objektumkészletet az Atlas szótáraiban, és hivatkoznia kell a regisztrált objektumokra a leképezések elkészítésekor. Az adatok eredetének nyomon követésére vagy az objektumfüggőségek elemzésére szolgáló mechanizmus sok időt takarít meg, amikor a számítási algoritmusok fejlesztésére van szükség. Például a pénzügyi kimutatások elkészítésekor ez a funkció lehetővé teszi, hogy kényelmesebben túlélje a jogszabályi változások időszakát. Hiszen minél jobban megértjük a formák közötti függőséget egy részletrétegű objektumok kontextusában, annál kevésbé fogunk „hirtelen” hibákkal találkozni, és csökken az átdolgozások száma.
Adatminőség és alacsony kód
A Mediascope projektben az alacsony kódú eszközzel megvalósított másik feladat az adatminőség osztály feladat volt. A kutatóvállalati projekt adatellenőrzési folyamatának megvalósításának sajátossága volt, hogy a fő adatszámítási folyamat teljesítményére és sebességére nem volt hatással. A független adatellenőrzési folyamatok lebonyolításához a már ismert Apache Airflow-t használták. Mivel az adatelőállítás minden lépése készen volt, párhuzamosan elindult a DQ pipeline egy külön része is.
Jó gyakorlatnak tekinthető az adatok minőségének nyomon követése az elemzési platformon való megjelenésük pillanatától kezdve. A metaadatokkal kapcsolatos információk birtokában az alapvető feltételek betartását ellenőrizhetjük attól a pillanattól kezdve, hogy az információ bekerül az elsődleges rétegbe - nem null, megszorítások, idegen kulcsok. Ezt a funkciót a Datagram adatminőség-családjának automatikusan generált leképezései alapján valósítják meg. A kódgenerálás ebben az esetben is modell metaadatokon alapul. A Mediascope projekten a felület az Enterprise Architect termék metaadataival valósult meg.
Az alacsony kódszámú eszköz és az Enterprise Architect párosításával a következő ellenőrzéseket generáltuk automatikusan:
- A „null” értékek jelenlétének ellenőrzése a „not null” módosítóval rendelkező mezőkben;
- Az elsődleges kulcs ismétlődéseinek meglétének ellenőrzése;
- Egy entitás idegen kulcsának ellenőrzése;
- Egy karakterlánc egyediségének ellenőrzése mezőkészlet alapján.
Az adatok elérhetőségének és megbízhatóságának összetettebb ellenőrzéséhez Scala Expression leképezést hoztak létre, amely a Zeppelin elemzői által készített külső Spark SQL ellenőrző kódot veszi be.
Természetesen az ellenőrzések automatikus generálását fokozatosan kell elérni. A leírt projekt keretében ezt a következő lépések előzték meg:
- Zeppelin notebookokban megvalósított DQ;
- A leképezésbe beépített DQ;
- DQ különálló hatalmas leképezések formájában, amelyek egy különálló entitás ellenőrzéseinek egész sorozatát tartalmazzák;
- Univerzális paraméterezett DQ-leképezések, amelyek bemenetként fogadják el a metaadatokkal és az üzleti ellenőrzésekkel kapcsolatos információkat.
A paraméterezett ellenőrző szolgáltatás létrehozásának talán fő előnye a funkcionalitás termelési környezetbe való eljuttatásának csökkenése. Az új minőségellenőrzések megkerülhetik azt a klasszikus mintát, hogy a kódot fejlesztői és tesztelési környezeteken keresztül közvetetten továbbítsák:
- Minden metaadat-ellenőrzés automatikusan generálódik, amikor a modellt módosítják az EA-ban;
- Az adatok rendelkezésre állási ellenőrzései (amelyek egy adott időpontban bármely adat jelenlétét meghatározzák) egy olyan könyvtár alapján generálhatók, amely a következő adat objektumok kontextusában való megjelenésének várható időpontját tárolja;
- Az üzleti adatok érvényesítési ellenőrzéseit elemzők készítik a Zeppelin notebookokban. Innen közvetlenül a DQ modul beállítási tábláiba kerülnek az éles környezetben.
Nincs kockázata annak, hogy a szkripteket közvetlenül a termelésbe szállítják. Szintaktikai hiba esetén is maximum egy ellenőrzés elmulasztása fenyeget bennünket, mert az adatszámítási folyamat és a minőségellenőrzés indítási folyamata elválik egymástól.
Lényegében a DQ szolgáltatás folyamatosan fut az éles környezetben, és készen áll a munka megkezdésére, amint megjelenik a következő adat.
Ahelyett, hogy egy következtetés
Az alacsony kód használatának előnye nyilvánvaló. A fejlesztőknek nem kell a nulláról fejleszteniük az alkalmazást. A további feladatoktól megszabadított programozó pedig gyorsabban hoz eredményt. A sebesség pedig további időt szabadít fel az optimalizálási problémák megoldására. Ezért ebben az esetben jobb és gyorsabb megoldásra számíthat.
Természetesen az alacsony kód nem csodaszer, és a varázslat nem fog megtörténni magától:
- Az alacsony kódú ipar az „erősödés” szakaszán megy keresztül, és még nincsenek egységes ipari szabványok;
- Sok alacsony kódú megoldás nem ingyenes, vásárlásuk tudatos lépés kell, hogy legyen, amelyet teljes bizalommal kell megtenni a használatuk anyagi előnyeiben;
- Sok alacsony kódú megoldás nem mindig működik jól a GIT/SVN-nel. Vagy kényelmetlen a használatuk, ha a generált kód rejtett;
- Az architektúra bővítésekor szükség lehet a low-code megoldás finomítására – ami viszont a low-code megoldás szállítójával szembeni „kötődés és függés” hatását váltja ki.
- Megfelelő biztonsági szint lehetséges, de nagyon munkaigényes és nehéz megvalósítani az alacsony kódrendszerű motorokban. Az alacsony kódú platformokat nem csak a használatukból származó előnyök elve alapján kell választani. A választás során érdemes kérdéseket feltenni a hozzáférés-szabályozás és az azonosító adatok delegálása/kiterjesztése funkcionalitásának elérhetőségéről a szervezet teljes informatikai környezetének szintjére.
Ha azonban a választott rendszer minden hiányossága ismert, és ennek ellenére a használat előnyei dominánsak, akkor félelem nélkül térjen át a kis kódra. Sőt, a rá való áttérés elkerülhetetlen – ahogyan minden evolúció is elkerülhetetlen.
Ha egy alacsony kódú platformon egy fejlesztő gyorsabban végzi a munkáját, mint két alacsony kód nélküli fejlesztő, akkor ez minden szempontból előnyt jelent a cégnek. A low-code megoldásokba való belépési küszöb alacsonyabb, mint a „hagyományos” technológiáké, és ez pozitívan hat a személyi hiány kérdésére. Alacsony kódú eszközök használatával felgyorsítható a funkcionális csapatok közötti interakció, és gyorsabban lehet döntéseket hozni az adattudományi kutatás választott útjának helyességéről. Az alacsony szintű platformok előmozdíthatják a szervezet digitális átalakulását, mert az előállított megoldásokat a nem műszaki szakemberek (főleg az üzleti felhasználók) is megérthetik.
Ha szűk a határidők, túlterhelt üzleti logika, hiányzik a technológiai szakértelem, és fel kell gyorsítania a piacra jutás idejét, akkor az alacsony kód az egyik módja annak, hogy kielégítse igényeit.
Tagadhatatlan a hagyományos fejlesztőeszközök fontossága, de sok esetben az alacsony kódú megoldások alkalmazása a legjobb módja a megoldandó feladatok hatékonyságának növelésének.
Forrás: will.com