🥇Utilizzo del low-code nelle piattaforme analitiche

Cari lettori, buona giornata!

Il compito di costruire piattaforme IT per la raccolta e l'analisi dei dati prima o poi si pone per qualsiasi azienda la cui attività si basa su un modello di fornitura di servizi intellettualmente carico o sulla creazione di prodotti tecnicamente complessi. Costruire piattaforme analitiche è un compito complesso e dispendioso in termini di tempo. Tuttavia, qualsiasi attività può essere semplificata. In questo articolo voglio condividere la mia esperienza nell'utilizzo di strumenti low-code per creare soluzioni analitiche. Questa esperienza è stata acquisita durante l'implementazione di numerosi progetti nella direzione Big Data Solutions dell'azienda Neoflex. Dal 2005, la direzione Big Data Solutions di Neoflex si occupa delle problematiche della costruzione di data warehouse e laghi, risolvendo problemi di ottimizzazione della velocità di elaborazione delle informazioni e lavorando su una metodologia per la gestione della qualità dei dati.

Nessuno potrà evitare l’accumulo consapevole di dati debolmente e/o fortemente strutturati. Forse anche se parliamo di piccole imprese. Dopotutto, quando si espande un'impresa, un promettente imprenditore dovrà affrontare il problema dello sviluppo di un programma fedeltà, vorrà analizzare l'efficacia dei punti vendita, penserà alla pubblicità mirata e sarà perplesso dalla domanda di prodotti di accompagnamento. . In prima approssimazione il problema può essere risolto “in ginocchio”. Ma man mano che l’azienda cresce, il passaggio a una piattaforma analitica è ancora inevitabile.

Tuttavia, in quale caso le attività di analisi dei dati possono trasformarsi in problemi di classe "Rocket Science"? Forse nel momento in cui si parla di big data davvero grandi.
Per rendere più semplice la scienza missilistica, puoi mangiare l'elefante pezzo per pezzo.

Più le vostre applicazioni/servizi/microservizi sono discreti e autonomi, più facile sarà per voi, i vostri colleghi e l'intera azienda digerire l'elefante.

Quasi tutti i nostri clienti sono arrivati a questo postulato, dopo aver ricostruito il panorama sulla base delle pratiche ingegneristiche dei team DevOps.

Ma anche con una dieta “separata ed elefantiaca”, abbiamo buone possibilità di “saturazione eccessiva” del panorama IT. In questo momento vale la pena fermarsi, espirare e guardare di lato piattaforma di ingegneria a basso codice.

Molti sviluppatori sono spaventati dalla prospettiva di un vicolo cieco nella loro carriera quando passano dalla scrittura diretta del codice al “trascinamento” delle frecce nelle interfacce dell’interfaccia utente dei sistemi a basso codice. Ma l'avvento delle macchine utensili non ha portato alla scomparsa degli ingegneri, ma ha portato il loro lavoro a un nuovo livello!

Scopriamo perché.

L’analisi dei dati nel campo della logistica, dell’industria delle telecomunicazioni, della ricerca sui media, del settore finanziario è sempre associata alle seguenti domande:

Velocità di analisi automatizzata;
Capacità di condurre esperimenti senza influenzare il flusso principale di produzione dei dati;
Affidabilità dei dati preparati;
Monitoraggio delle modifiche e controllo delle versioni;
Provenienza dei dati, derivazione dei dati, CDC;
Consegna rapida di nuove funzionalità all'ambiente di produzione;
E il famigerato: il costo di sviluppo e supporto.

Cioè, gli ingegneri hanno un numero enorme di compiti di alto livello, che possono essere completati con sufficiente efficienza solo liberando la loro coscienza dai compiti di sviluppo di basso livello.

I prerequisiti affinché gli sviluppatori potessero passare a un nuovo livello erano l’evoluzione e la digitalizzazione del business. Anche il valore dello sviluppatore sta cambiando: c’è una significativa carenza di sviluppatori che possano immergersi nei concetti di business automatizzato.

Tracciamo un'analogia con i linguaggi di programmazione di basso e alto livello. Il passaggio dai linguaggi di basso livello a quelli di alto livello è un passaggio dalla scrittura di “direttive dirette nel linguaggio dell’hardware” verso “direttive nel linguaggio delle persone”. Cioè, aggiungendo un certo livello di astrazione. In questo caso, il passaggio alle piattaforme low-code dai linguaggi di programmazione di alto livello è un passaggio dalle “direttive nel linguaggio delle persone” verso le “direttive nel linguaggio degli affari”. Se ci sono sviluppatori che sono rattristati da questo fatto, forse lo sono stati dal momento in cui è nato Java Script, che utilizza funzioni di ordinamento degli array. E queste funzioni, ovviamente, hanno un'implementazione software sotto il cofano con altri mezzi della stessa programmazione di alto livello.

Pertanto, il low-code è solo l’apparenza di un altro livello di astrazione.

Esperienza applicata utilizzando low-code

L'argomento low-code è piuttosto ampio, ma ora vorrei parlare dell'applicazione pratica dei “concetti low-code” utilizzando l'esempio di uno dei nostri progetti.

La divisione Big Data Solutions di Neoflex è specializzata maggiormente nel settore finanziario delle imprese, costruendo data warehouse e laghi e automatizzando vari reporting. In questa nicchia, l'uso del low-code è diventato da tempo uno standard. Tra gli altri strumenti low-code, possiamo citare strumenti per l'organizzazione dei processi ETL: Informatica Power Center, IBM Datastage, Pentaho Data Integration. Oppure Oracle Apex, che funge da ambiente per lo sviluppo rapido di interfacce per l'accesso e la modifica dei dati. Tuttavia, l’uso di strumenti di sviluppo low-code non sempre implica la creazione di applicazioni altamente mirate su uno stack tecnologico commerciale con una chiara dipendenza dal fornitore.

Utilizzando piattaforme low-code è inoltre possibile organizzare l'orchestrazione dei flussi di dati, creare piattaforme di data science o, ad esempio, moduli per il controllo della qualità dei dati.

Uno degli esempi applicativi dell'esperienza nell'utilizzo di strumenti di sviluppo low-code è la collaborazione tra Neoflex e Mediascope, uno dei leader nel mercato russo della ricerca sui media. Uno degli obiettivi aziendali di questa azienda è la produzione di dati sulla base dei quali inserzionisti, piattaforme Internet, canali TV, stazioni radio, agenzie pubblicitarie e marchi prendono decisioni sull'acquisto di pubblicità e pianificano le loro comunicazioni di marketing.

La ricerca sui media è un'area di business tecnologicamente carica. Riconoscere sequenze video, raccogliere dati da dispositivi che analizzano la visualizzazione, misurare l'attività sulle risorse web: tutto ciò implica che l'azienda dispone di un ampio personale IT e di un'enorme esperienza nella creazione di soluzioni analitiche. Ma la crescita esponenziale della quantità di informazioni, del numero e della varietà delle loro fonti costringe il settore dei dati IT a progredire costantemente. La soluzione più semplice per ampliare la piattaforma analitica Mediascope già funzionante potrebbe essere quella di aumentare il personale IT. Ma una soluzione molto più efficace è accelerare il processo di sviluppo. Uno dei passi che portano in questa direzione potrebbe essere l’utilizzo di piattaforme low-code.

Al momento dell'avvio del progetto, l'azienda disponeva già di una soluzione di prodotto funzionante. Tuttavia, l'implementazione della soluzione in MSSQL non è riuscita a soddisfare pienamente le aspettative in termini di funzionalità di scalabilità mantenendo un costo di sviluppo accettabile.

Il compito che ci attendeva era davvero ambizioso: Neoflex e Mediascope dovevano creare una soluzione industriale in meno di un anno, soggetta al rilascio dell'MVP entro il primo trimestre dalla data di inizio.

Lo stack tecnologico Hadoop è stato scelto come base per la costruzione di una nuova piattaforma dati basata sull'elaborazione low-code. HDFS è diventato lo standard per l'archiviazione dei dati utilizzando file parquet. Per accedere ai dati presenti nella piattaforma è stato utilizzato Hive, in cui tutte le vetrine disponibili sono presentate sotto forma di tabelle esterne. Il caricamento dei dati nello spazio di archiviazione è stato implementato utilizzando Kafka e Apache NiFi.

Lo strumento Lowe-code in questo concetto è stato utilizzato per ottimizzare l'attività più laboriosa nella costruzione di una piattaforma analitica: l'attività di calcolo dei dati.

Lo strumento Datagram a basso codice è stato scelto come meccanismo principale per la mappatura dei dati. Datagramma Neoflex è uno strumento per lo sviluppo di trasformazioni e flussi di dati.
Usando questo strumento, puoi fare a meno di scrivere manualmente il codice Scala. Il codice Scala viene generato automaticamente utilizzando l'approccio Model Driven Architecture.

Un ovvio vantaggio di questo approccio è l’accelerazione del processo di sviluppo. Tuttavia, oltre alla velocità, ci sono anche i seguenti vantaggi:

Visualizzazione del contenuto e della struttura delle sorgenti/destinatari;
Tracciare l'origine degli oggetti del flusso di dati sui singoli campi (lignaggio);
Esecuzione parziale delle trasformazioni con visualizzazione dei risultati intermedi;
Revisione del codice sorgente e aggiustamento prima dell'esecuzione;
Convalida automatica delle trasformazioni;
Scarico dati automatico 1 in 1.

La barriera all'ingresso in soluzioni low-code per la generazione di trasformazioni è piuttosto bassa: lo sviluppatore deve conoscere SQL e avere esperienza di lavoro con gli strumenti ETL. Vale la pena ricordare che i generatori di trasformazioni guidate da codice non sono strumenti ETL nel senso ampio del termine. Gli strumenti a basso codice potrebbero non avere un proprio ambiente di esecuzione del codice. Cioè, il codice generato verrà eseguito nell'ambiente esistente sul cluster anche prima dell'installazione della soluzione low-code. E questo è forse un altro vantaggio del karma a basso codice. Poiché, parallelamente a un team low-code, può funzionare un team “classico” che implementa funzionalità, ad esempio, in puro codice Scala. Portare i miglioramenti di entrambi i team in produzione sarà semplice e senza soluzione di continuità.

Forse vale la pena notare che oltre al low-code esistono anche soluzioni no-code. E in fondo, queste sono cose diverse. Il low-code consente allo sviluppatore di interferire maggiormente con il codice generato. Nel caso di Datagram, è possibile visualizzare e modificare il codice Scala generato; no-code potrebbe non fornire tale opportunità. Questa differenza è molto significativa non solo in termini di flessibilità della soluzione, ma anche in termini di comfort e motivazione nel lavoro degli ingegneri dei dati.

Architettura della soluzione

Proviamo a capire esattamente come uno strumento low-code aiuta a risolvere il problema di ottimizzare la velocità di sviluppo della funzionalità di calcolo dei dati. Innanzitutto, diamo un'occhiata all'architettura funzionale del sistema. Un esempio in questo caso è il modello di produzione dei dati per la ricerca sui media.

Le fonti dati nel nostro caso sono molto eterogenee e diversificate:

I contatori di persone (misuratori TV) sono dispositivi software e hardware che leggono il comportamento degli utenti degli intervistati in un panel televisivo: chi, quando e quale canale televisivo è stato guardato nella famiglia che ha partecipato allo studio. Le informazioni fornite sono un flusso di intervalli di visione della trasmissione collegati al pacchetto multimediale e al prodotto multimediale. I dati in fase di caricamento nel Data Lake possono essere arricchiti con attributi demografici, geostratificazione, fuso orario e altre informazioni necessarie per analizzare la visione televisiva di un particolare prodotto mediale. Le misurazioni effettuate possono essere utilizzate per analizzare o pianificare campagne pubblicitarie, valutare l'attività e le preferenze del pubblico e compilare la rete di trasmissione;
I dati possono provenire da sistemi di monitoraggio delle trasmissioni televisive in streaming e di misurazione della visualizzazione dei contenuti delle risorse video su Internet;
Strumenti di misurazione nell'ambiente web, inclusi contatori sia incentrati sul sito che incentrati sull'utente. Il fornitore di dati per Data Lake può essere un componente aggiuntivo del browser della barra di ricerca e un'applicazione mobile con una VPN integrata.
I dati possono provenire anche da siti che consolidano i risultati della compilazione di questionari online e i risultati delle interviste telefoniche nelle indagini aziendali;
Un ulteriore arricchimento del data Lake può avvenire scaricando informazioni dai log delle aziende partner.

L'implementazione del caricamento così com'è dai sistemi di origine nella fase primaria dei dati grezzi può essere organizzata in vari modi. Se per questi scopi viene utilizzato il low-code, è possibile la generazione automatica di script di caricamento basati sui metadati. In questo caso, non è necessario scendere al livello di sviluppo delle mappature dall'origine alla destinazione. Per implementare il caricamento automatico, dobbiamo stabilire una connessione alla sorgente, quindi definire nell'interfaccia di caricamento l'elenco delle entità da caricare. La struttura delle directory in HDFS verrà creata automaticamente e corrisponderà alla struttura di archiviazione dei dati sul sistema di origine.

Tuttavia, nel contesto di questo progetto, abbiamo deciso di non utilizzare questa funzionalità della piattaforma low-code perché la società Mediascope ha già iniziato autonomamente a lavorare sulla produzione di un servizio simile utilizzando la combinazione Nifi + Kafka.

È bene subito precisare che questi strumenti non sono intercambiabili, ma anzi complementari. Nifi e Kafka sono in grado di funzionare sia in connessione diretta (Nifi -> Kafka) che inversa (Kafka -> Nifi). Per la piattaforma di ricerca sui media è stata utilizzata la prima versione del bundle.

Nel nostro caso, NayFi aveva bisogno di elaborare vari tipi di dati dai sistemi di origine e inviarli al broker Kafka. In questo caso, i messaggi sono stati inviati a uno specifico argomento Kafka utilizzando i processori PublishKafka Nifi. L'orchestrazione e la manutenzione di queste pipeline vengono eseguite in un'interfaccia visiva. Lo strumento Nifi e l'uso della combinazione Nifi + Kafka possono anche essere definiti un approccio allo sviluppo low-code, che presenta una bassa barriera all'ingresso nelle tecnologie Big Data e accelera il processo di sviluppo dell'applicazione.

La fase successiva nell'implementazione del progetto è stata quella di portare i dati dettagliati in un formato a livello semantico singolo. Se un'entità ha attributi storici, il calcolo viene eseguito nel contesto della partizione in questione. Se l'entità non è storica, allora è facoltativamente possibile ricalcolare l'intero contenuto dell'oggetto o rifiutarsi completamente di ricalcolare questo oggetto (a causa della mancanza di modifiche). In questa fase, vengono generate le chiavi per tutte le entità. Le chiavi sono archiviate nelle directory Hbase corrispondenti agli oggetti master, che contengono una corrispondenza tra le chiavi nella piattaforma analitica e le chiavi dei sistemi sorgente. Il consolidamento delle entità atomiche è accompagnato dall'arricchimento con i risultati del calcolo preliminare dei dati analitici. Il framework per il calcolo dei dati era Spark. La funzionalità descritta per portare i dati in un'unica semantica è stata implementata anche sulla base delle mappature dello strumento Datagram a basso codice.

L'architettura di destinazione richiedeva l'accesso SQL ai dati per gli utenti aziendali. Per questa opzione è stato utilizzato Hive. Gli oggetti vengono registrati automaticamente in Hive quando abiliti l'opzione "Registr Hive Table" nello strumento low-code.

Controllo del flusso di calcolo

Datagram dispone di un'interfaccia per la creazione di progetti di flussi di flusso di lavoro. Le mappature possono essere avviate utilizzando lo scheduler Oozie. Nell'interfaccia dello sviluppatore del flusso è possibile creare schemi per trasformazioni di dati parallele, sequenziali o dipendenti dall'esecuzione. È disponibile il supporto per script di shell e programmi Java. È anche possibile utilizzare il server Apache Livy. Apache Livy viene utilizzato per eseguire applicazioni direttamente dall'ambiente di sviluppo.

Se l'azienda dispone già di un proprio orchestratore di processi, è possibile utilizzare l'API REST per incorporare le mappature in un flusso esistente. Ad esempio, abbiamo avuto un'esperienza piuttosto positiva nell'incorporamento di mappature in Scala in orchestratori scritti in PLSQL e Kotlin. L'API REST dello strumento low-code include operazioni come la generazione di un anno eseguibile in base al progetto di mappatura, il richiamo di una mappatura, il richiamo di una sequenza di mappature e, ovviamente, il passaggio di parametri all'URL per eseguire le mappature.

Insieme a Oozie, è possibile organizzare un flusso di calcolo utilizzando Airflow. Forse non mi soffermerò a lungo sul confronto tra Oozie e Airflow, ma dirò semplicemente che nell’ambito di un progetto di ricerca sui media la scelta è caduta a favore di Airflow. Gli argomenti principali questa volta sono stati una comunità più attiva nello sviluppo del prodotto e un'interfaccia + API più sviluppate.

Airflow è utile anche perché utilizza l'amato Python per descrivere i processi di calcolo. E in generale, non esistono così tante piattaforme di gestione del flusso di lavoro open source. Avviare e monitorare l’esecuzione dei processi (incluso un diagramma di Gantt) non fa altro che aggiungere punti al karma di Airflow.

Il formato del file di configurazione per l'avvio delle mappature delle soluzioni low-code è diventato spark-submit. Ciò è accaduto per due motivi. Innanzitutto, spark-submit ti consente di eseguire direttamente un file jar dalla console. In secondo luogo, può contenere tutte le informazioni necessarie per configurare il flusso di lavoro (il che rende più semplice scrivere script che generano Dag).
L'elemento più comune del flusso di lavoro Airflow nel nostro caso era SparkSubmitOperator.

SparkSubmitOperator ti consente di eseguire jar, mappature di datagrammi pacchettizzati con parametri di input pregenerati per essi.

Vale la pena ricordare che ogni attività Airflow viene eseguita in un thread separato e non sa nulla delle altre attività. Pertanto, l'interazione tra le attività viene eseguita utilizzando operatori di controllo, come DummyOperator o BranchPythonOperator.

Nel complesso, l'utilizzo della soluzione low-code Datagram in combinazione con l'universalizzazione dei file di configurazione (formando Dag) ha portato ad una significativa accelerazione e semplificazione del processo di sviluppo dei flussi di caricamento dei dati.

Calcoli in vetrina

Forse la fase più carica dal punto di vista intellettuale nella produzione di dati analitici è la fase di costruzione delle vetrine. Nell’ambito di uno dei flussi di calcolo dei dati della società di ricerca, in questa fase i dati vengono ridotti a una trasmissione di riferimento, tenendo conto delle correzioni per i fusi orari e collegati alla rete di trasmissione. È anche possibile adattarsi alla rete di trasmissione locale (notizie e pubblicità locali). In questo passaggio vengono suddivisi, tra l'altro, gli intervalli di visione continua di prodotti multimediali sulla base dell'analisi degli intervalli di visione. Immediatamente i valori di visualizzazione vengono “ponderati” in base alle informazioni relative al loro significato (calcolo di un fattore di correzione).

Un passaggio separato nella preparazione delle vetrine è la convalida dei dati. L'algoritmo di validazione prevede l'uso di una serie di modelli scientifici matematici. Tuttavia, l'uso di una piattaforma a basso codice consente di suddividere un algoritmo complesso in una serie di mappature separate leggibili visivamente. Ciascuna delle mappature esegue un compito ristretto. Di conseguenza, sono possibili il debugging intermedio, la registrazione e la visualizzazione delle fasi di preparazione dei dati.

Si è deciso di discretizzare l’algoritmo di validazione nelle seguenti sottofasi:

Creazione di regressioni delle dipendenze di visualizzazione delle reti televisive in una regione con visualizzazione di tutte le reti nella regione per 60 giorni.
Calcolo dei residui studentizzati (deviazioni dei valori effettivi da quelli previsti dal modello di regressione) per tutti i punti di regressione e per il giorno calcolato.
Una selezione di coppie regione-rete anomale, dove il saldo studentizzato del giorno di liquidazione supera la norma (specificata dalle impostazioni dell'operazione).
Ricalcolo del residuo studentizzato corretto per coppie regione-rete televisiva anomale per ciascun intervistato che ha guardato la rete nella regione, determinando il contributo di questo intervistato (l'importo della variazione del residuo studentizzato) quando si esclude la visione di questo intervistato dal campione .
Cerca i candidati la cui esclusione riporti alla normalità il saldo studentesco della busta paga.

L'esempio sopra conferma l'ipotesi che un ingegnere informatico ha già troppe cose in mente... E, se si tratta davvero di un "ingegnere" e non di un "codificatore", allora il timore del degrado professionale quando utilizza strumenti a basso codice lo deve finalmente ritirarsi.

Cos’altro può fare il low-code?

L'ambito di applicazione di uno strumento low-code per l'elaborazione di dati in batch e in flusso senza la necessità di scrivere manualmente codice in Scala non finisce qui.

L'utilizzo del low-code nello sviluppo di datalake è già diventato per noi uno standard. Probabilmente possiamo dire che le soluzioni basate sullo stack Hadoop seguono il percorso di sviluppo dei classici DWH basati su RDBMS. Gli strumenti a basso codice sullo stack Hadoop possono risolvere sia le attività di elaborazione dei dati sia il compito di creare interfacce BI finali. Inoltre, va notato che BI può significare non solo la rappresentazione dei dati, ma anche la loro modifica da parte degli utenti aziendali. Usiamo spesso questa funzionalità quando costruiamo piattaforme analitiche per il settore finanziario.

Tra l'altro, utilizzando il low-code e, in particolare, Datagram, è possibile risolvere il problema del tracciamento dell'origine degli oggetti del flusso di dati con atomicità fino ai singoli campi (lignaggio). Per fare ciò, lo strumento low-code implementa l'interfaccia con Apache Atlas e Cloudera Navigator. In sostanza, lo sviluppatore deve registrare un insieme di oggetti nei dizionari Atlas e fare riferimento agli oggetti registrati durante la creazione delle mappature. Il meccanismo per tracciare l'origine dei dati o analizzare le dipendenze degli oggetti consente di risparmiare molto tempo quando è necessario apportare miglioramenti agli algoritmi di calcolo. Ad esempio, quando si preparano i rendiconti finanziari, questa funzionalità consente di sopravvivere più comodamente al periodo delle modifiche legislative. Dopotutto, meglio comprendiamo la dipendenza tra i moduli nel contesto degli oggetti di uno strato dettagliato, meno incontreremo difetti "improvvisi" e ridurremo il numero di rielaborazioni.

Qualità dei dati e low-code

Un'altra attività implementata dallo strumento low-code nel progetto Mediascope è stata l'attività della classe Data Quality. Una caratteristica speciale dell'implementazione della pipeline di verifica dei dati per il progetto della società di ricerca è stata la mancanza di impatto sulle prestazioni e sulla velocità del flusso di calcolo dei dati principali. Per poter orchestrare flussi di verifica dei dati indipendenti, è stato utilizzato il già noto Apache Airflow. Una volta pronta ogni fase della produzione dei dati, è stata lanciata in parallelo una parte separata della pipeline DQ.

È considerata una buona pratica monitorare la qualità dei dati dal momento della loro immissione nella piattaforma analitica. Avendo informazioni sui metadati, possiamo verificare il rispetto delle condizioni di base dal momento in cui le informazioni entrano nello strato primario - non nulli, vincoli, chiavi esterne. Questa funzionalità è implementata sulla base di mappature generate automaticamente della famiglia di qualità dei dati in Datagram. Anche la generazione del codice in questo caso si basa sui metadati del modello. Nel progetto Mediascope l'interfaccia è stata realizzata con i metadati del prodotto Enterprise Architect.

Associando lo strumento low-code a Enterprise Architect, sono stati generati automaticamente i seguenti controlli:

Verifica della presenza di valori “null” nei campi con il modificatore “not null”;
Verifica della presenza di duplicati della chiave primaria;
Controllare la chiave esterna di un'entità;
Verifica dell'unicità di una stringa in base a un insieme di campi.

Per controlli più complessi della disponibilità e dell'affidabilità dei dati, è stata creata una mappatura con Scala Expression, che prende come input un codice di controllo Spark SQL esterno preparato dagli analisti di Zeppelin.

Naturalmente, la generazione automatica degli assegni deve essere raggiunta gradualmente. Nell’ambito del progetto descritto, questo è stato preceduto dalle seguenti fasi:

DQ implementato nei notebook Zeppelin;
DQ integrato nella mappatura;
DQ sotto forma di mappature massicce separate contenenti un intero set di controlli per un'entità separata;
Mapping DQ parametrizzati universali che accettano come input informazioni sui metadati e sui controlli aziendali.

Forse il vantaggio principale della creazione di un servizio di controllo parametrizzato è la riduzione del tempo necessario per fornire funzionalità all'ambiente di produzione. I nuovi controlli di qualità possono aggirare il modello classico di consegna del codice indirettamente attraverso ambienti di sviluppo e test:

Tutti i controlli sui metadati vengono generati automaticamente quando il modello viene modificato in EA;
I controlli sulla disponibilità dei dati (che determinano la presenza di eventuali dati in un determinato momento) possono essere generati sulla base di una directory che memorizza i tempi previsti per la comparsa del successivo dato nel contesto degli oggetti;
I controlli di convalida dei dati aziendali vengono creati dagli analisti nei notebook Zeppelin. Da lì vengono inviati direttamente alle tabelle di configurazione dei moduli DQ nell'ambiente di produzione.

Non ci sono rischi legati alla spedizione diretta degli script alla produzione. Anche con un errore di sintassi, il massimo che ci minaccia è la mancata esecuzione di un controllo, perché il flusso di calcolo dei dati e il flusso di avvio del controllo di qualità sono separati l'uno dall'altro.

In sostanza, il servizio DQ è permanentemente in esecuzione nell'ambiente di produzione ed è pronto a iniziare il suo lavoro nel momento in cui viene visualizzato il successivo dato.

Invece di una conclusione

Il vantaggio di utilizzare il low-code è evidente. Gli sviluppatori non devono sviluppare l'applicazione da zero. E un programmatore libero da compiti aggiuntivi produce risultati più velocemente. La velocità, a sua volta, libera ulteriore tempo per risolvere i problemi di ottimizzazione. Pertanto, in questo caso, puoi contare su una soluzione migliore e più rapida.

Naturalmente, il low-code non è una panacea e la magia non avverrà da sola:

L’industria low-code sta attraversando una fase di “rafforzamento” e non esistono ancora standard industriali uniformi;
Molte soluzioni low-code non sono gratuite e acquistarle dovrebbe essere un passo consapevole, da compiere con piena fiducia nei vantaggi finanziari derivanti dal loro utilizzo;
Molte soluzioni a basso codice non sempre funzionano bene con GIT/SVN. Oppure sono scomodi da usare se il codice generato è nascosto;
Quando si espande l'architettura, potrebbe essere necessario perfezionare la soluzione low-code, il che, a sua volta, provoca l'effetto di "attaccamento e dipendenza" sul fornitore della soluzione low-code.
Un livello adeguato di sicurezza è possibile, ma richiede molto lavoro ed è difficile da implementare nei motori di sistema a basso codice. Le piattaforme low-code dovrebbero essere scelte non solo in base al principio di ottenere benefici dal loro utilizzo. Al momento della scelta, vale la pena porsi domande sulla disponibilità di funzionalità per il controllo degli accessi e la delega/escalation dei dati di identificazione al livello dell'intero panorama IT dell'organizzazione.

Tuttavia, se conosci tutte le carenze del sistema scelto e i vantaggi derivanti dal suo utilizzo sono tuttavia la maggioranza, passa senza paura al codice piccolo. Inoltre, il passaggio ad esso è inevitabile, proprio come è inevitabile ogni evoluzione.

Se uno sviluppatore su una piattaforma low-code svolge il suo lavoro più velocemente di due sviluppatori senza low-code, ciò dà all'azienda un vantaggio sotto tutti gli aspetti. La soglia per l’ingresso nelle soluzioni low-code è inferiore rispetto a quella nelle tecnologie “tradizionali”, e questo ha un effetto positivo sulla questione della carenza di personale. Quando si utilizzano strumenti low-code, è possibile accelerare l'interazione tra i team funzionali e prendere decisioni più rapide sulla correttezza del percorso scelto per la ricerca sulla scienza dei dati. Le piattaforme di basso livello possono guidare la trasformazione digitale di un'organizzazione perché le soluzioni prodotte possono essere comprese da specialisti non tecnici (in particolare utenti aziendali).

Se hai scadenze strette, una logica di business complessa, una mancanza di competenze tecnologiche e hai bisogno di accelerare il time-to-market, allora il low-code è un modo per soddisfare le tue esigenze.

Non si può negare l’importanza degli strumenti di sviluppo tradizionali, ma in molti casi l’utilizzo di soluzioni low-code è il modo migliore per aumentare l’efficienza delle attività da risolvere.

Fonte: habr.com

Applicazione del low-code nelle piattaforme analitiche