Hyvät lukijat, hyvää iltapäivää!
Tietojen keräämiseen ja analysointiin tarkoitettujen IT-alustojen rakentamisen tehtävä tulee ennemmin tai myöhemmin jokaiselle yritykselle, jonka liiketoiminta perustuu älyllisesti kuormitettuun palvelumalliin tai teknisesti monimutkaisten tuotteiden luomiseen. Analyyttisten alustojen rakentaminen on monimutkainen ja aikaa vievä tehtävä. Kaikki tehtävät voidaan kuitenkin yksinkertaistaa. Tässä artikkelissa haluan jakaa kokemukseni alhaisen koodin työkalujen käytöstä analyyttisten ratkaisujen luomisessa. Tämä kokemus on hankittu useiden projektien toteutuksen aikana Neoflex-yhtiön Big Data Solutions -suunnassa. Vuodesta 2005 lähtien Neoflexin Big Data Solutions -liiketoiminta-alue on käsitellyt tietovarastojen ja järvien rakentamiseen liittyviä kysymyksiä, ratkonut tiedonkäsittelyn nopeuden optimointiongelmia ja työstänyt tiedon laadunhallinnan metodologiaa.
Kukaan ei voi välttää heikosti ja/tai vahvasti jäsenneltyjen tietojen tietoista keräämistä. Ehkä vaikka puhumme pienyrityksistä. Loppujen lopuksi, kun yritystä laajennetaan, lupaava yrittäjä kohtaa kanta-asiakasohjelman kehittämisongelmia, hän haluaa analysoida myyntipisteiden tehokkuutta, ajattelee kohdennettua mainontaa ja on ymmällään mukana tulevien tuotteiden kysynnästä. . Ensimmäisen arvion mukaan ongelma voidaan ratkaista "polvella". Mutta liiketoiminnan kasvaessa analyyttisen alustan käyttäminen on edelleen väistämätöntä.
Mutta missä tapauksessa data-analytiikkatehtävät voivat kehittyä "Rocket Science" -luokan ongelmiksi? Ehkä tällä hetkellä, kun puhumme todella isosta datasta.
Rakettitieteen helpottamiseksi voit syödä norsun pala palalta.
Mitä diskreettimpiä ja itsenäisempiä sovelluksesi/palvelusi/mikropalvelusi ovat, sitä helpompi sinun, kollegojesi ja koko yrityksen on sulatella elefanttia.
Lähes kaikki asiakkaamme päätyivät tähän oletukseen, kun he olivat rakentaneet maiseman uudelleen DevOps-tiimien suunnittelukäytäntöjen perusteella.
Mutta jopa "erillisen elefanttiruokavalion" avulla meillä on hyvät mahdollisuudet "ylikyllästyä" IT-ympäristössä. Tällä hetkellä kannattaa pysähtyä, hengittää ulos ja katsoa sivulle matalan koodin suunnittelualusta.
Monet kehittäjät pelkäävät uransa umpikujaa siirtyessään koodin suoraan kirjoittamisesta "raahaamaan" nuolia matalan koodin järjestelmien käyttöliittymäliittymissä. Mutta työstökoneiden tulo ei johtanut insinöörien katoamiseen, vaan toi heidän työnsä uudelle tasolle!
Selvitetään miksi.
Tietojen analysointi logistiikan, telealan, mediatutkimuksen ja rahoitusalan alalla liittyy aina seuraaviin kysymyksiin:
- Automatisoidun analyysin nopeus;
- Kyky suorittaa kokeita vaikuttamatta päätiedon tuotantovirtaan;
- Valmisteltujen tietojen luotettavuus;
- Muutosten seuranta ja versiointi;
- Datan alkuperä, Data linja, CDC;
- Uusien ominaisuuksien nopea toimitus tuotantoympäristöön;
- Ja pahamaineinen: kehitys- ja tukikustannukset.
Eli insinööreillä on valtava määrä korkean tason tehtäviä, jotka voidaan suorittaa riittävän tehokkaasti vain puhdistamalla heidän tietoisuutensa matalan tason kehitystehtävistä.
Edellytyksenä kehittäjien siirtymiselle uudelle tasolle oli liiketoiminnan kehitys ja digitalisaatio. Myös kehittäjän arvo on muuttumassa: kehittäjistä, jotka voivat uppoutua automatisoitavan liiketoiminnan konsepteihin, on huomattava pula.
Piirretään analogia matalan ja korkean tason ohjelmointikielten kanssa. Siirtyminen matalan tason kielistä korkean tason kieliin on siirtymä "suorien ohjeiden kirjoittamisesta laitteiston kielellä" kohti "direktiivejä ihmisten kielellä". Eli lisäämällä jonkin verran abstraktiota. Tässä tapauksessa siirtyminen matalan koodin alustoihin korkean tason ohjelmointikielistä on siirtymistä "ihmisten kielellä olevista direktiiveistä" "liikekielellä oleviin direktiiveihin". Jos jotkut kehittäjät ovat surullisia tästä tosiasiasta, niin he ovat olleet surullisia ehkä siitä hetkestä lähtien, kun Java Script syntyi, joka käyttää taulukoiden lajittelutoimintoja. Ja näillä toiminnoilla on tietysti ohjelmistototeutus konepellin alla muilla saman korkean tason ohjelmoinnin keinoilla.
Siksi alhainen koodi on vain ilmentymä toisen tason abstraktio.
Sovellettu kokemus matalan koodin käytöstä
Low-code-aihe on melko laaja, mutta nyt haluaisin puhua "low-code-käsitteiden" käytännön soveltamisesta yhden projektimme esimerkin avulla.
Neoflexin Big Data Solutions -divisioona on erikoistunut enemmän talouden finanssisektorille, tietovarastojen ja järvien rakentamiseen sekä erilaisten raportoinnin automatisointiin. Tässä markkinarakossa matalan koodin käyttö on jo pitkään tullut standardiksi. Muista matalakoodityökaluista mainittakoon työkalut ETL-prosessien organisointiin: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Tai Oracle Apex, joka toimii ympäristönä tietojen käyttö- ja muokkausrajapintojen nopealle kehitykselle. Matalakoodin kehitystyökalujen käyttö ei kuitenkaan aina edellytä tarkasti kohdistettujen sovellusten rakentamista kaupalliseen teknologiapinoon, joka on selkeästi riippuvainen toimittajasta.
Low-code-alustojen avulla voit myös järjestää tietovirtojen organisoinnin, luoda datatieteen alustoja tai esimerkiksi moduuleja tiedon laadun tarkistamiseen.
Yksi sovelletuista esimerkeistä kokemuksesta matalan koodin kehitystyökalujen käytöstä on yhteistyö Neoflexin ja Mediascopen, yhden Venäjän mediatutkimusmarkkinoiden johtajista, välillä. Yksi tämän yrityksen liiketoiminnan tavoitteista on tuottaa dataa, jonka perusteella mainostajat, Internet-alustat, tv-kanavat, radioasemat, mainostoimistot ja brändit tekevät päätöksiä mainonnan ostamisesta ja suunnittelevat markkinointiviestintäänsä.
Mediatutkimus on teknologisesti kuormitettu liiketoiminta-alue. Videojaksojen tunnistaminen, tietojen kerääminen katselua analysoivista laitteista, verkkoresurssien toiminnan mittaaminen – kaikki tämä tarkoittaa, että yrityksellä on suuri IT-henkilöstö ja valtava kokemus analyyttisten ratkaisujen rakentamisesta. Mutta tiedon määrän, sen lähteiden määrän ja monimuotoisuuden räjähdysmäinen kasvu pakottaa IT-tietoteollisuuden jatkuvasti edistymään. Yksinkertaisin ratkaisu jo toimivan Mediascope-analyysialustan skaalaamiseen voisi olla IT-henkilöstön lisääminen. Mutta paljon tehokkaampi ratkaisu on nopeuttaa kehitysprosessia. Yksi tähän suuntaan vievistä askeleista voi olla matalakoodisten alustojen käyttö.
Yrityksellä oli projektin alkaessa jo toimiva tuoteratkaisu. Ratkaisun käyttöönotto MSSQL:ssä ei kuitenkaan pystynyt täysin täyttämään skaalaustoiminnallisuuden odotuksia ja säilyttämään hyväksyttävät kehityskustannukset.
Edessämme oleva tehtävä oli todella kunnianhimoinen - Neoflexin ja Mediascopen oli luotava teollinen ratkaisu alle vuodessa, edellyttäen, että MVP julkaistaan aloituspäivän ensimmäisen neljänneksen aikana.
Hadoop-teknologiapino valittiin perustaksi uuden matalakoodin laskentaan perustuvan tietoalustan rakentamiselle. HDFS:stä on tullut standardi parkettitiedostojen tallennukseen. Alustassa olevien tietojen käyttämiseen käytettiin Hivea, jossa kaikki saatavilla olevat julkisivut on esitetty ulkoisten taulukoiden muodossa. Tietojen lataaminen tallennustilaan toteutettiin Kafkan ja Apache NiFi:n avulla.
Tämän konseptin Lowe-code-työkalua käytettiin optimoimaan työvoimavaltaisin tehtävä analyyttisen alustan rakentamisessa - datalaskennan tehtävä.
Matalakooditon Datagram-työkalu valittiin tiedon kartoituksen päämekanismiksi. Neoflex Datagram on työkalu transformaatioiden ja tietovirtojen kehittämiseen.
Tämän työkalun avulla voit tehdä Scala-koodin kirjoittamatta manuaalisesti. Scala-koodi luodaan automaattisesti käyttämällä Model Driven Architecture -lähestymistapaa.
Tämän lähestymistavan ilmeinen etu on kehitysprosessin nopeuttaminen. Nopeuden lisäksi on kuitenkin myös seuraavat edut:
- Lähteiden/vastaanottimien sisällön ja rakenteen tarkastelu;
- Tietovirtaobjektien alkuperän jäljitys yksittäisiin kenttiin (linja);
- Muutosten osittainen suorittaminen välitulosten tarkastelulla;
- Lähdekoodin tarkistaminen ja sen säätäminen ennen suoritusta;
- Automaattinen muunnosten validointi;
- Automaattinen tietojen lataus 1 in 1.
Este tunkeutua matalakoodiratkaisuihin muunnosten generoimiseksi on melko alhainen: kehittäjän tulee tuntea SQL ja olla kokemusta ETL-työkalujen kanssa työskentelystä. On syytä mainita, että koodiohjatut muunnosgeneraattorit eivät ole ETL-työkaluja sanan laajassa merkityksessä. Matalakoodisilla työkaluilla ei välttämättä ole omaa koodin suoritusympäristöä. Toisin sanoen luotu koodi suoritetaan ympäristössä, joka oli olemassa klusterissa jo ennen matalan koodin ratkaisun asentamista. Ja tämä on ehkä toinen plussa matalan koodin karmalle. Koska matalan koodin tiimin rinnalla voi toimia "klassinen" tiimi, joka toteuttaa toimintoja esimerkiksi puhtaassa Scala-koodissa. Molempien tiimien parannusten tuominen tuotantoon on helppoa ja saumatonta.
On ehkä syytä huomata, että matalakoodin lisäksi on olemassa myös ei-koodiratkaisuja. Ja pohjimmiltaan nämä ovat eri asioita. Matala koodi antaa kehittäjälle mahdollisuuden puuttua luotuun koodiin enemmän. Datagramin tapauksessa on mahdollista tarkastella ja muokata luotua Scala-koodia, ilman koodia ei välttämättä tarjota tällaista mahdollisuutta. Tämä ero on erittäin merkittävä paitsi ratkaisun joustavuuden, myös mukavuuden ja motivaation kannalta tietoteknikon työssä.
Ratkaisuarkkitehtuuri
Yritetään selvittää tarkasti, kuinka matalakoodityökalu auttaa ratkaisemaan ongelman, joka liittyy tietojen laskentatoimintojen kehittämisen nopeuden optimointiin. Ensin tarkastellaan järjestelmän toiminnallista arkkitehtuuria. Esimerkkinä tässä tapauksessa on mediatutkimuksen tiedontuotantomalli.
Meidän tapauksessamme tietolähteet ovat hyvin heterogeenisia ja erilaisia:
- Ihmismittarit (TV-mittarit) ovat ohjelmisto- ja laitteistolaitteita, jotka lukevat televisiopaneelivastaajien käyttäjien käyttäytymistä - ketä, milloin ja mitä televisiota katsottiin tutkimukseen osallistuvassa taloudessa. Toimitetut tiedot ovat mediapakettiin ja mediatuotteeseen linkitettyjen lähetysten katseluvälien virta. Data Lakeen latausvaiheessa olevia tietoja voidaan rikastaa demografisilla ominaisuuksilla, geostratifikaatiolla, aikavyöhykkeellä ja muilla tiedoilla, joita tarvitaan tietyn mediatuotteen television katselun analysointiin. Mittauksilla voidaan analysoida tai suunnitella mainoskampanjoita, arvioida yleisön aktiivisuutta ja mieltymyksiä sekä koota lähetysverkostoa;
- Tiedot voivat tulla valvontajärjestelmistä televisiolähetysten suoratoistoon ja videoresurssisisällön katselun mittaamiseen Internetissä;
- Mittaustyökalut verkkoympäristössä, mukaan lukien sekä paikka- että käyttäjäkeskeiset mittarit. Data Laken tiedontarjoaja voi olla tutkimuspalkin selainlaajennus ja mobiilisovellus, jossa on sisäänrakennettu VPN.
- Tiedot voivat tulla myös sivustoilta, jotka yhdistävät verkkokyselyiden täyttötulokset ja puhelinhaastattelujen tulokset yritystutkimuksissa;
- Datajärven lisärikastuminen voi tapahtua lataamalla tietoja kumppaniyritysten lokeista.
Lähdejärjestelmistä lataamisen toteutus raakadatan ensisijaiseen vaiheitukseen voidaan järjestää eri tavoin. Jos näihin tarkoituksiin käytetään matalaa koodia, latausskriptien automaattinen luominen metatietoihin on mahdollista. Tässä tapauksessa ei tarvitse laskea lähteen kehittämistasolle kohdekartoitusten tekemiseksi. Automaattisen latauksen toteuttamiseksi meidän on muodostettava yhteys lähteeseen ja määritettävä sitten latausrajapinnassa luettelo ladattavista kokonaisuuksista. HDFS:n hakemistorakenne luodaan automaattisesti ja vastaa lähdejärjestelmän tiedontallennusrakennetta.
Tämän projektin yhteydessä päätimme kuitenkin olla käyttämättä tätä matalakoodialustan ominaisuutta, koska Mediascope-yhtiö on jo itsenäisesti aloittanut työskentelyn samanlaisen palvelun tuottamiseksi Nifi + Kafka -yhdistelmällä.
On syytä mainita välittömästi, että nämä työkalut eivät ole keskenään vaihdettavissa, vaan ne täydentävät toisiaan. Nifi ja Kafka pystyvät toimimaan sekä suorassa (Nifi -> Kafka) että käänteisessä (Kafka -> Nifi) yhteydessä. Mediatutkimusalustalle käytettiin paketin ensimmäistä versiota.
Meidän tapauksessamme NayFi:n täytyi käsitellä erityyppisiä tietoja lähdejärjestelmistä ja lähettää ne Kafka-välittäjälle. Tässä tapauksessa viestit lähetettiin tiettyyn Kafka-aiheeseen PublishKafka Nifi -prosessoreilla. Näiden putkilinjojen orkestrointi ja ylläpito suoritetaan visuaalisessa käyttöliittymässä. Nifi-työkalua ja Nifi + Kafka -yhdistelmän käyttöä voidaan kutsua myös matalakoodiiseksi lähestymistavaksi kehitykseen, jolla on alhainen este Big Data -teknologioihin pääsylle ja joka nopeuttaa sovelluskehitysprosessia.
Seuraava vaihe projektin toteutuksessa oli yksityiskohtaisten tietojen tuominen yhteen semanttiseen kerrokseen. Jos entiteetillä on historiallisia attribuutteja, laskenta suoritetaan kyseisen osion yhteydessä. Jos entiteetti ei ole historiallinen, on valinnaisesti mahdollista joko laskea uudelleen koko objektin sisältö tai kieltäytyä kokonaan laskemasta tätä objektia uudelleen (muutosten puutteen vuoksi). Tässä vaiheessa avaimet luodaan kaikille entiteeteille. Avaimet tallennetaan pääobjekteja vastaaviin Hbase-hakemistoihin, jotka sisältävät vastaavuuden analyyttisen alustan avainten ja lähdejärjestelmien avainten välillä. Atomikokonaisuuksien konsolidointiin liittyy rikastaminen analyyttisten tietojen alustavien laskelmien tuloksilla. Tietojen laskennan viitekehys oli Spark. Kuvattu toiminto datan tuomiseksi yhteen semantiikkaan toteutettiin myös matalakoodisen Datagram-työkalun kartoituksiin perustuen.
Kohdearkkitehtuuri vaati yrityskäyttäjiltä SQL-käyttöoikeuden. Hiveä käytettiin tähän vaihtoehtoon. Objektit rekisteröidään Hiveen automaattisesti, kun otat käyttöön "Rekisteröi Hive Table" -vaihtoehdon matalakoodityökalussa.
Laskentavirtauksen ohjaus
Datagramissa on käyttöliittymä työnkulkumallien luomiseen. Kartoitukset voidaan käynnistää Oozie-aikataulun avulla. Stream-kehittäjän käyttöliittymässä on mahdollista luoda malleja rinnakkaisille, peräkkäisille tai suoritusriippuvaisille datamuunnoksille. Siellä on tuki shell-skripteille ja java-ohjelmille. On myös mahdollista käyttää Apache Livy -palvelinta. Apache Livyä käytetään sovellusten ajamiseen suoraan kehitysympäristöstä.
Jos yrityksellä on jo oma prosessiorganisaattori, REST API:n avulla on mahdollista upottaa kartoituksia olemassa olevaan kulkuun. Meillä oli esimerkiksi varsin onnistunut kokemus mappausten upottamisesta Scalassa PLSQL:llä ja Kotlinilla kirjoitettuihin orkestraattoreihin. Pienen koodin työkalun REST API sisältää toimintoja, kuten suoritusvuoden luomisen kartoitussuunnitelman perusteella, kartoituksen kutsumisen, kartoitussarjan kutsumisen ja tietysti parametrien välittämisen URL-osoitteeseen kartoituksia suorittamista varten.
Oozien ohella on mahdollista järjestää laskentavirta Airflown avulla. En ehkä viivy pitkään Oozien ja Airflown vertailussa, vaan sanon vain, että mediatutkimusprojektin työskentelyn yhteydessä valinta osui Airflown hyväksi. Pääargumentit tällä kertaa olivat aktiivisempi tuotetta kehittävä yhteisö ja kehittyneempi käyttöliittymä + API.
Ilmavirta on hyvä myös siksi, että se käyttää rakastettua Pythonia kuvaamaan laskentaprosesseja. Ja yleensä, avoimen lähdekoodin työnkulun hallintaalustoja ei ole niin paljon. Prosessien käynnistäminen ja suorittamisen seuranta (mukaan lukien Gantt-kaavio) vain lisää pisteitä Airflown karmaan.
Alhaisen koodin ratkaisukartoitusten käynnistämisen määritystiedostomuodosta on tullut spark-submit. Tämä tapahtui kahdesta syystä. Ensinnäkin spark-submit antaa sinun suorittaa jar-tiedoston suoraan konsolista. Toiseksi se voi sisältää kaikki tarvittavat tiedot työnkulun määrittämiseen (mikä helpottaa Dag-komentosarjan luovien komentosarjojen kirjoittamista).
Yleisin Airflow-työnkulun elementti tapauksessamme oli SparkSubmitOperator.
SparkSubmitOperatorin avulla voit ajaa purkkeja – pakattuja Datagram-kartoituksia, joissa on valmiiksi luodut syöttöparametrit niille.
On syytä mainita, että jokainen Airflow-tehtävä suoritetaan erillisessä säikeessä, eikä se tiedä mitään muista tehtävistä. Siksi tehtävien välinen vuorovaikutus suoritetaan käyttämällä ohjausoperaattoreita, kuten DummyOperator tai BranchPythonOperator.
Kaiken kaikkiaan Datagram-matalakoodiratkaisun käyttö yhdessä konfigurointitiedostojen universaalisoinnin kanssa (muodostivat Dag-tiedoston) johti tiedonlatausvirtojen kehittämisprosessin merkittävään nopeuttamiseen ja yksinkertaistamiseen.
Esittelylaskelma
Ehkä älyllisesti kuormitetuin vaihe analyyttisen datan tuotannossa on vitriinien rakentamisvaihe. Erään tutkimusyhtiön tietolaskentavirran yhteydessä data pelkistetään tässä vaiheessa aikavyöhykekorjaukset huomioiden viitelähetykseksi ja linkitetään lähetysverkkoon. On myös mahdollista sovittaa paikallislähetysverkkoon (paikalliset uutiset ja mainonta). Tämä vaihe muun muassa purkaa mediatuotteiden jatkuvan katselun aikavälit katseluvälianalyysin perusteella. Välittömästi katseluarvot "painotetaan" niiden merkitystä koskevien tietojen perusteella (korjauskertoimen laskenta).
Erillinen vaihe esittelyjen valmistelussa on tietojen validointi. Validointialgoritmiin kuuluu useiden matemaattisten tieteen mallien käyttö. Matalakoodisen alustan käyttö mahdollistaa kuitenkin monimutkaisen algoritmin jakamisen useiksi erillisiksi visuaalisesti luettaviksi kartoituksiin. Jokainen kartoitus suorittaa kapean tehtävän. Tämän seurauksena väliaikainen virheenkorjaus, lokikirjaus ja tietojen valmisteluvaiheiden visualisointi ovat mahdollisia.
Validointialgoritmi päätettiin diskretoida seuraaviin alavaiheisiin:
- Regression rakentaminen TV-verkkojen katseluriippuvuudesta alueella katsomalla kaikkia alueen verkkoja 60 päivän ajan.
- Opiskelittujen residuaalien (todellisten arvojen poikkeamat regressiomallilla ennustetuista) laskeminen kaikille regressiopisteille ja lasketulle päivälle.
- Valikoima poikkeavia alue-verkko-pareja, joissa selvityspäivän opiskelijasaldo ylittää normin (toimintaasetusten määrittämä).
- Korjatun studentisoidun residuaalin uudelleenlaskeminen poikkeaville alue-TV-verkkopareille kullekin alueella verkkoa katsoneelle vastaajalle määrittämällä tämän vastaajan panos (studioituneen residuaalin muutoksen määrä), kun tämän vastaajan katselu jätetään pois otoksesta .
- Etsi ehdokkaita, joiden poissulkeminen palauttaa opiskeluajan palkkapäivän saldon normaaliksi.
Yllä oleva esimerkki vahvistaa hypoteesin, että tietosuunnittelijalla on jo liikaa mielessä... Ja jos tämä on todella "insinööri" eikä "kooderi", niin hän pelkää ammatin heikkenemistä käytettäessä matalan koodin työkaluja täytyy vihdoin vetäytyä.
Mitä muuta matala koodi voi tehdä?
Matalakoodisen työkalun sovellusala erä- ja stream-tiedonkäsittelyyn ilman tarvetta kirjoittaa koodia manuaalisesti Scalassa ei lopu tähän.
Matalakoodin käytöstä datalaken kehittämisessä on tullut meille jo standardi. Voimme luultavasti sanoa, että Hadoop-pinoon perustuvat ratkaisut seuraavat klassisten RDBMS-pohjaisten DWH:iden kehityspolkua. Hadoop-pinon matalakoodityökalut voivat ratkaista sekä tietojenkäsittelytehtävät että lopullisten BI-rajapintojen rakentamisen. Lisäksi on huomattava, että BI voi tarkoittaa paitsi tietojen esittämistä, myös sen muokkaamista yrityskäyttäjien toimesta. Käytämme tätä toimintoa usein rakentaessamme analyyttisiä alustoja finanssisektorille.
Muun muassa matalan koodin ja erityisesti Datagrammin avulla on mahdollista ratkaista tietovirtaobjektien alkuperän jäljittämisongelma atomisuudella yksittäisiin kenttiin (linjaan). Tätä varten matalakoodityökalu toteuttaa käyttöliittymän Apache Atlasin ja Cloudera Navigatoriin. Pohjimmiltaan kehittäjän on rekisteröitävä joukko objekteja Atlas-sanakirjoihin ja viitattava rekisteröityihin objekteihin luodessaan kartoituksia. Tietojen alkuperän seuranta- tai objektiriippuvuuksien analysointimekanismi säästää paljon aikaa, kun laskenta-algoritmeihin on tehtävä parannuksia. Esimerkiksi tilinpäätöstä laadittaessa tämän ominaisuuden avulla voit selviytyä mukavammin lainsäädännöllisten muutosten ajasta. Loppujen lopuksi, mitä paremmin ymmärrämme muotojen välisen riippuvuuden yksityiskohtaisen kerroksen kohteiden yhteydessä, sitä vähemmän kohtaamme "äkillisiä" vikoja ja vähennämme uusien työstöjen määrää.
Tietojen laatu ja alhainen koodi
Toinen Mediascope-projektin matalakoodityökalulla toteutettu tehtävä oli Data Quality -luokkatehtävä. Tutkimusyhtiöprojektin tiedonvarmennusputkilinjan toteutuksen erityispiirre oli vaikutuksen puute päätietolaskennan virran suorituskykyyn ja nopeuteen. Riippumattomien tietojen varmennusvirtojen ohjaamiseksi käytettiin jo tuttua Apache Airflowa. Kun datatuotannon jokainen vaihe oli valmis, erillinen osa DQ-putkista otettiin käyttöön rinnakkain.
Hyvänä käytäntönä pidetään tietojen laadun seurantaa siitä hetkestä lähtien, kun se on syntynyt analyyttisella alustalla. Kun meillä on tietoa metatiedoista, voimme tarkistaa perusehtojen noudattamisen siitä hetkestä lähtien, kun tiedot saapuvat ensisijaiseen kerrokseen - ei nollaa, rajoituksia, vierasavaimia. Tämä toiminto on toteutettu Datagramissa automaattisesti luotujen tietojen laatuperheen kartoitusten perusteella. Tässä tapauksessa koodin luominen perustuu myös mallin metatietoihin. Mediascope-projektissa käyttöliittymä toteutettiin Enterprise Architect -tuotteen metatiedoilla.
Yhdistämällä matalakoodityökalu Enterprise Architectin kanssa seuraavat tarkistukset luotiin automaattisesti:
- Tarkista "nolla"-arvojen olemassaolo kentissä "ei tyhjä" -muuntimella;
- Ensisijaisen avaimen kaksoiskappaleiden olemassaolon tarkistaminen;
- entiteetin vierasavaimen tarkistaminen;
- Merkkijonon ainutlaatuisuuden tarkistaminen kenttäjoukon perusteella.
Monimutkaisempia tietojen saatavuuden ja luotettavuuden tarkistuksia varten luotiin kartoitus Scala Expressionilla, joka ottaa syötteenä ulkoisen Spark SQL -tarkistuskoodin, jonka Zeppelinin analyytikot ovat valmistaneet.
Tietenkin automaattinen tarkastusten luominen on saavutettava asteittain. Kuvatun projektin puitteissa tätä edelsi seuraavat vaiheet:
- DQ toteutettu Zeppelin-kannettavissa;
- DQ sisäänrakennettu kartoitukseen;
- DQ erillisten massiivisten kartoitusten muodossa, jotka sisältävät kokonaisen joukon tarkistuksia erilliselle kokonaisuudelle;
- Universaalit parametroidut DQ-kartoitukset, jotka hyväksyvät tiedot metatiedoista ja liiketoiminnan tarkistuksista syötteenä.
Parametrisoidun tarkistuspalvelun luomisen ehkä tärkein etu on toiminnallisuuden tuotantoympäristöön toimittamiseen kuluvan ajan lyhentäminen. Uudet laaduntarkistukset voivat ohittaa perinteisen koodin toimittamisen epäsuorasti kehitys- ja testausympäristöjen kautta:
- Kaikki metatietojen tarkistukset luodaan automaattisesti, kun mallia muutetaan EA:ssa;
- Tiedon saatavuuden tarkistukset (jotka määrittävät minkä tahansa datan olemassaolon tiettynä ajankohtana) voidaan generoida hakemiston perusteella, joka tallentaa seuraavan datan esiintymisen odotetun ajoituksen objektien kontekstissa;
- Analyytikot luovat liiketoimintatietojen validointitarkistuksia Zeppelin-kannettavissa. Sieltä ne lähetetään suoraan tuotantoympäristön DQ-moduulin asetustaulukoihin.
Ei ole olemassa riskejä siitä, että skriptit toimitetaan suoraan tuotantoon. Syntaksivirheessäkin meitä uhkaa korkeintaan yhden tarkistuksen jättäminen tekemättä, koska datalaskentavirta ja laaduntarkistuksen käynnistysvirta ovat erillään toisistaan.
Pohjimmiltaan DQ-palvelu on jatkuvasti käynnissä tuotantoympäristössä ja on valmis aloittamaan työnsä heti seuraavan datan ilmestyessä.
Sen sijaan johtopäätös
Matalakoodin käytön etu on ilmeinen. Kehittäjien ei tarvitse kehittää sovellusta tyhjästä. Ja lisätehtävistä vapautettu ohjelmoija tuottaa tuloksia nopeammin. Nopeus puolestaan vapauttaa lisää aikaa optimointiongelmien ratkaisemiseen. Siksi tässä tapauksessa voit luottaa parempaan ja nopeampaan ratkaisuun.
Matala koodi ei tietenkään ole ihmelääke, eikä taikuutta tapahdu itsestään:
- Low-code-teollisuus käy läpi "vahvistumisen" vaihetta, eikä yhtenäisiä teollisia standardeja ole vielä olemassa;
- Monet matalakoodiratkaisut eivät ole ilmaisia, ja niiden ostamisen tulee olla tietoinen askel, joka tulee tehdä täysin luottaen niiden käytön taloudellisiin hyötyihin;
- Monet matalan koodin ratkaisut eivät aina toimi hyvin GIT/SVN:n kanssa. Tai ne ovat epämukavia käyttää, jos luotu koodi on piilotettu;
- Arkkitehtuuria laajennettaessa voi olla tarpeen jalostaa matalakoodiratkaisua - mikä puolestaan saa aikaan "kiinnittymisen ja riippuvuuden" vaikutuksen matalan koodin ratkaisun toimittajaan.
- Riittävä turvallisuustaso on mahdollinen, mutta se on erittäin työvoimavaltaista ja vaikeasti toteutettavissa matalan koodin järjestelmämoottoreissa. Low-code-alustoja ei tulisi valita pelkästään sen periaatteen perusteella, että niiden käytöstä haetaan hyötyä. Valinnassa kannattaa kysyä toiminnallisuuden saatavuudesta kulunvalvontaan ja tunnistustietojen delegointiin/eskalointiin organisaation koko IT-ympäristön tasolle.
Jos kuitenkin tiedät valitun järjestelmän kaikki puutteet ja sen käytön edut ovat kuitenkin hallitsevassa enemmistössä, siirry pieneen koodiin ilman pelkoa. Lisäksi siirtyminen siihen on väistämätöntä - aivan kuten mikä tahansa kehitys on väistämätöntä.
Jos yksi kehittäjä matalan koodin alustalla tekee työnsä nopeammin kuin kaksi kehittäjää ilman matalaa koodia, tämä antaa yritykselle etumatkan kaikilta osin. Kynnys päästä matalan koodin ratkaisuihin on matalampi kuin "perinteisissä" teknologioissa, ja tällä on positiivinen vaikutus henkilöstöpulaan. Matalakoodityökaluja käyttämällä voidaan nopeuttaa toimivien tiimien välistä vuorovaikutusta ja tehdä nopeammin päätöksiä valitun datatieteen tutkimuspolun oikeellisuudesta. Matalan tason alustat voivat ohjata organisaation digitaalista muutosta, koska ei-tekniset asiantuntijat (erityisesti yrityskäyttäjät) ymmärtävät tuotetut ratkaisut.
Jos sinulla on tiukat määräajat, kuormitettu liiketoimintalogiikka, teknologisen asiantuntemuksen puute ja sinun on nopeutettava markkinoille pääsyä, alhainen koodi on yksi tapa vastata tarpeisiisi.
Perinteisten kehitystyökalujen tärkeyttä ei voi kiistää, mutta monissa tapauksissa matalakoodiratkaisujen käyttö on paras tapa tehostaa ratkaistavia tehtäviä.
Lähde: will.com